上回说到，我们把架构体系的工程剥离了出来，由原来的一个大工程，分成了9个自工程，把springMVC和dubbo都分别拆了出来，目前架构其实清晰多了。
我们就按照这个思路，继续往前跑，dubbo的api我们放到了自己的git私服上，然后出现了一个问题，就是版本迭代有时候要升级接口参数，但往往因为通知不到位，会出现其他接口报错。以前我在上一家公司的做法是：
1.先用dubbo-monitor查一下调用方
2.挨个通知调用方我的接口要升级了
3.期间我会同时允许亮哥版本同时存在
4.调用方从我的1.0版本升级到2.0版本的时候，我开始观察1.0版本接口的流量
5.确认没有流量的情况下，我会下掉api及dubbo服务。
但是问题来了，我发现从0-1建立这样的一个制度，并完全让大伙执行下去的难度很大，这主要由两方面决定的。一个是公司人员对dubbo的熟悉程度并不够，其次是，本身能力并不强，在执行方面也会出现各种问题。因此，我开始考虑通过技术方式改变这种问题。
当时我想到的，dubbo的接口升级，如果是加字段的话，消费者即便不更新也不会受影响，因此我尝试了dubbox提供的kyro序列化方式（dubbo默认的序列化是hession2）的方式来解决，测试了一下没问题，就匆匆上线了。结果上线没多久，有坑了，添加一个基础类型字段是没问题，但如果增加一个class，或者list就报错了。因此，这个方式验证失败。
接下来，我去尝试json的序列化方式，结果发现也存在对象套用对象的坑在里头，遂放弃。
这时，架构师和我提了个概念，我们可以考虑spring cloud的微服务的方式去解决这块的问题，通过http的方式访问，能绕开序列化的问题。但因为当时技术部只有10多个人，我们连dubbo都没掌握完全，更不敢尝试新的框架。另外一点是，当时我也打听了一下，杭州没有哪家成熟的互联网公司是用spring cloud在做微服务的，因此，不敢做第一个吃螃蟹的人啊。所以这块，就硬着头皮让大伙按照规矩，修改接口及时通知的策略执行，其实后面有好多次事故都是因为这步骤没有执行到位，直到spring cloud服务体系切换完毕的时候，才能种根治了这个问题。（那都是2年后的事儿了）
dubbo这的问题，我印象中好像也就这么多了，因为公司小，version的概念我们用不上，一般不推荐修改接口，而是新追加接口来完成功能的进化，但带来的就是服务化内部的代码复杂度很高，一个dubbo服务要同时维护着好几个接口，这是缺点。dubbo就这么一直陪着我们到2018年中旬，
网友评论