解决dubbo多版本并存的一个思路

以Dubbo做为微服务框架背景，分析多版本代码如何并存？SpringCloud在思路上是相同的

目标：一个接口有不一样的实现或者接口实现升级时不兼容

有几个重要的核心点概念

1. 单个服务节点内提供一个接口的多个版本的服务；
2. 单个服务节点内一个接口只听过一个版本的服务；
3. 一个服务在集群环境下会有多个服务节点并存；
4. 在集群内不一样服务组下的服务相互发现不了；

方案一

分组提供不一样类型的服务，接口有不一样的实现

在集群中有两个分组的服务，假设正式服务组和试用服务组，即：prod-ok\prod-test。

开发过程当中能够经过Git的branch上规划两个分支各自独立维护和部署，消费者根据业务场景调用对应版本的API服务。在消费者端同时引入两个分组的接口，就能够在代码内进行动态的控制分发。

方案二

分版本提供服务，代码升级不兼容的状况

同一个接口在同一个组里有不一样的实现，并同时启动两个或以上（注意bean的名字得不一样）；消费者同时注册多个版本的service，在代码内部实现动态区分。

<dubbo:service interface="com.xxxx.rent.service.IDemoService" ref="iDemoService4" version="2.4.4"/>
<dubbo:service interface="com.xxxx.rent.service.IDemoService" ref="iDemoService5" version="2.4.5"/>

能够经过配置version="*"达到随机选择不一样版本服务

<dubbo:reference id="iDemoService5" interface="com.xxxx.rent.service.IDemoService" version="*"/>

回顾

咱们软件开发过程当中会有多个环境，基本能够涵盖为这几种：local\dev\qa\pre\prod。不少公司应该都是经过不一样环境进行物理层面的隔离，也就致使Dubbo的Group功能都用不到。有些小公司资源也有限可能会选择dev\qa\pre集群部署在一个环境了，用group去区分调用。

上面两个方式核心点是在消费者端同时冗余多个版本的服务，经过dubbo的group或version来区分，后者的维护成本相对低些。

设想，一种思路

dubbo://xxx.20.xx.57:20880/com.xxxx.rent.service.IDemoService2?anyhost=true&application=rent&default.export=true&default.register=true&default.timeout=10000&dubbo=2.5.3&export=true&interface=com.xxxx.rent.service.IDemoService&methods=searchInfoById,searchDemoInfoListByIds,removeDemo,modifyByDemo,createNew&pid=19626&revision=2.4.3-SNAPSHOT&side=provider×tamp=1550735642003&version=2.4.5

查看dubbo访问日志能够发现每次请求都是带有版本的参数version=2.4.5，能够改造代码实现调用时动态获取版本号。

写的很差，欢迎吐槽。

---

做者：MR.TS

他的博客：Owen Blog