【原】Dubbo 多版本号过渡

之前发过一篇因为接口规范的问题导致其它端出现服务不可用的文章（http://www.cnblogs.com/zdd-java/p/8612763.html），然而最近在查阅了dubbo官方指南文档才知道其实可以通过多版本号解决前面那个问题,经过自己在本地测试后总结如下。

---

官方原内容如下：

当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。

可以按照以下的步骤进行版本迁移：

1. 在低压力时间段，先升级一半提供者为新版本
2. 再将所有消费者升级为新版本
3. 然后将剩下的一半提供者升级为新版本

---

老版本服务提供者配置：

<dubbo:service interface="com.foo.BarService" version="1.0.0" />

新版本服务提供者配置：

<dubbo:service interface="com.foo.BarService" version="2.0.0" />

老版本服务消费者配置：

<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />

新版本服务消费者配置：

<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />

如果不需要区分版本，可以按照以下的方式配置 1：

<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />

---

验证过程：

　　#启动2个服务提供者分别为s1,s2，这2个服务都注册到本地的zk上。其中s1保留旧版本也就是 1.0，s2是升级后的版本也就是 2.0。

s2服务

#2.0版本返回的类型是String。

---

s1服务

#1.0版本还是返回的类型是boolean。

当上面2个服务都成功启动后开始从消费方发起对不同版本的模拟调用。

调用方：

#先从1.0版本开始调用，由于提供方1.0版本所提供的接口中返回的基本数据类型是boolean，所以进行测试后能正常响应。

#如下图所示,故意把消费者这边版本升级到2.0,在启动消费者的时候会订阅2.0版本的服务, 但由于2.0版本返回的是String,所以测试的时候会报类型错误。

#错误如下

总结：

　　 当需要升级接口版本的时候考虑到其它消费者没来得及升级的情况下需要兼容共存,这时候就可以将一半的提供方服务升级一个版本过渡,例如双节点,先部署一个升级版本后的服务上去。同理需要调用这个服务的消费者也一样升级对应的版本,其它消费者依旧采用旧版本。