如何统一服务调用框架?


转载本文需注明出处:微信公众号EAWorld,违者必究。

引言:

目前在Java 微服务领域Spring Cloud 和Dubbo体系都被普遍使用。不一样的用户会根据项目的须要选择合适的架构。可是在有些跨系统的场景下会涉及到两种体系间的混合调用。怎么作到较小修改就支持Spring Cloud和Dubbo两种体系的混合调用?本文将介绍一下咱们在较小修改状况下统一Spring CLoud和Dubbo服务调用框架。

目前Spring Cloud和Dubbo体系发展都比较成熟,很多客户已有一些采用它们开发的系统。好的微服务开发平台须要支持这两种体系。统一开发体验和下降开发复杂度的同时,保留两种体系各自的优点。

spring

现有企业IT架构api

服务调用场景安全


IT企业根据不一样系统有不一样的现状和技术发展路线。针对新系统,采用优先经常使用的Spring Coud应用调用Spring Cloud应用或Dubbo应用调用Dubbo应用。

可是针对已有系统进行架构调整改造,即若有系统A是Spring Cloud体系,想新增或者改造一些服务为Dubbo形式,反之亦然,就会出现二、4的混合服务调用场景,这类场景主要是经过兼容来保证平滑升级过分。



基于使用场景推论,原有系统多是Spring Cloud或者是Dubbo,因此服务注册中心须要支持Eureka和Zookeeper,调用协议须要支持Http(Restful)或RPC协议。

运行逻辑能够拆分如下几段:
 微信

  1. 服务提供方能够根据配置项,将具体服务对外提供为Spring Cloud(Restful)和Dubbo(RPC)协议服务
  2. 服务提供方根据提供的服务协议类型,转换为对应的服务契约,注册到Eureka和Zookeeper
  3. 服务消费方从Eureka和Zookeeper中获取服务注册信息,根据服务契约解析
  4. 服务消费方根据配置项、获取的服务契约,调用服务提供方的服务


 

  • 采用统一声明式调用方式使得开发人员比较容易开发应用,调用实现经过服务类型区分,分别采用Feign,Dubbo采用自带实现,这样能够有效支持已有系统调用,下降学习成本。
  • 独立注解能够统一规范开发,控制平台调用规则处理须要提供和消费的接口。
  • 服务类型控制应用是服务提供方仍是服务消费方,能够在同一应用中支持服务双体系和消费双体系。
  • 灵活配置的服务体系规则,便于根据须要调整服务体系,如应用整体为Spring Cloud,新增提供和消费服务都是Dubbo,能够在原有的配置中,增长这些新服务为Dubbo体系规则便可。


定义期决定运行的过程架构


服务类型是针对具体的服务提供类型为Spring Cloud(Restful)服务仍是Dubbo(RPC)服务,提供对应的服务契约(完整的服务描述Swagger)。

注册中心类型就是基于启动依赖和配置项,决定链接的注册中心具体为Eureka仍是Zookeeper,提供对应的服务发布格式(注册中心存储的服务格式)。


服务类型决定应用、包、接口类型定义的优先级依次递增,即若是都有配置时,以接口配置为准。服务类型的切换,能够经过配置文件的修改调整,无需调整代码。

服务提供和服务调用的关键逻辑:

1. 根据配置,扫描EOSService接口。
2. 判断服务提供类型,包含多层级优先级判断,肯定服务提供类型。
a ) Dubbo类型:仿照Dubbo自己服务发布的形式,注册Dubbo bean实例
b ) Spring Cloud类型:根据约定发布对应Restful服务(由于为方便开发采用声明式调用,因此须要平台约定如url、type等规则)
3. 判断服务调用类型,包含多层级优先级判断,肯定服务调用方式。
a ) Dubbo类型:仿照Dubbo自己服务发布的形式,注册Dubbo bean实例
b ) Spring Cloud类型:根据约定注册Feign bean。调用时,经过Feign调用服务。app

 

注册中心根据如上依赖项决定,启动bean加载不一样。不一样的注册中心保留的服务发布时机和格式有不一样。框架


同体系的注册中心由于须要对接已有系统,因此服务发布格式都延用同体系内容,如Spring Cloud服务发布到Eureka,和Dubbo服务发布到Zookeeper中的服务格式同原有系统其余服务,不作特殊处理。

服务发布和服务获取的关键逻辑:

1. 根据依赖项,启动不一样注册中心初始化过程。
2. 判断注册中心类型,替换服务注册实例。
a ) Zookeeper类型:启动Zookeeper注册和监听实例,根据服务提供类型,组织服务发布格式到Zookeeper节点(具体格式后面有示例)。
b ) Eureka类型:Spring Cloud同原有,Dubbo服务经过异步扫描,放置到对应的扩展属性。
3. 判断注册中心类型,替换服务实例获取方式。
a ) Zookeeper类型:启动Zookeeper注册和监听实例,根据服务提供类型,从 Zookeeper节点获取并解析服务格式(具体格式后面有示例)。
b ) Eureka类型:Spring Cloud同原有,Dubbo服务经过监听Eureka 扩展属性。



Spring Cloud服务的发布格式在Zookeeper中存储如上图,在Zookeeper中新增/spring-cloud-service目录,记录Spring Cloud服务访问所须要的要素。



["dubbo://172.20.10.7:20882/com.primeton.eos.demo.sdk.server.core.api.DubboService?anyhost=true&application=provider&bean.name=ServiceBean:dubboServiceController:com.primeton.eos.demo.sdk.server.core.api.DubboService&default.deprecated=false&default.dynamic=false&default.register=true&default.timeout=1000&deprecated=false&dubbo=2.0.2&dynamic=false&generic=false&interface=com.primeton.eos.demo.sdk.server.core.api.DubboService&methods=addUserPost,addUser&pid=46073®ister=true&release=2.7.1&side=provider×tamp=1573006719825"]

9002
61441


Dubbo服务的发布格式在Eureka中存储如上图,将完整的Dubbo服务所须要的要素所有存储到metadata中。

异步

开发使用示例ide


关键时序处理链路示例微服务


实际运行过程,根据服务的具体配置项和注册中心有相应的差别。



【小结】统一调用框架就是怎么支持各类混合服务调用的场景,又能统一一种开发体验,根据须要灵活调整实际服务类型。框架解决的问题是开发期统一简单,运行期灵活多变,保证服务稳定。实现时须要约束服务类型规则和注册中心依赖形式,同时定义配套提供和调用规则。如定义Spring Cloud的服务地址规则。

【后记】在方案实现中遇到如下几类问题:



因具体问题与Spring Cloud、Dubbo和第三方具体jar版本有关,只能具体问题具体解决。
 

  • Jar版本冲突通常采用调整或锁定jar版本。
  • Bean冲突通常修改Bean的配置或者名称。
  • 配置项冲突须要自定义配置项处理过程,经过参数或启动脚本设置。


关于做者:零零九,现任普元金融资深工程师,主要负责微服务平台和流程平台设计与开发,前后参与公司EOS、BPS的产品开发和客户定制。持续关注应用安全和NLP。

关于EAWorld:微服务,DevOps,数据治理,移动架构原创技术分享。长按二维码关注!

相关文章
相关标签/搜索