服务化准备工作

在决定进行服务化时，我们做了一些必要的准备工作；从服务治理，链路跟踪，监控以及报警方面到代码层面，运维，流程等多个方面做了相应的调整

整体架构

我们的服务化是在dubbo的基础上进行的，首先适配了服务化需要的相关组件，包括配置中心，链路跟踪，监控，服务治理等，整体架构如图所示

• 配置中心: Apollo
• 链路跟踪: Zipkin, Kafka, ES
• 服务治理: dubbo官方的dubbo-admin
• 服务监控: dubbo官方的dubbo-monitor

准备工作

服务化SDK

我们提供了服务化SDK给业务团队使用；SDK自定义了xsd文件继承了dubbo的xml标签，在此基础上集成了apollo配置；这样业务团队在使用的过程中对一些系统配置不需要关注，比如注册中心，启用监控，启用链路跟踪等 .

代码改造

1. 分离Service的API接口到独立的Jar包
2. 检查接口的输入输出参数是否实现了Serializable接口
3. 是否使用了接口参数在方法内部修改后的值，代码如下:

   /*服务端*/
   public boolean call(List<String> list){
           list.add("b");
           
           return true
   }
   
   /*客户端*/ 
   List<String> list = new ArrayList();
   service.call(list);
   list.get(0)

   这个代码在同一个JVM是没有问题，但RPC调用并不能返还预期的结果；
4. 本地事务改造为分布式事务
5. 确保所有的单元测试通过

日志输出增加链路跟踪信息

每条输出日志包括了zipkin的span id,这样每条日志都能清楚的跟踪到从整个调用链；

监控系统

dubbo-monitor对接现有的报警系统，将采集到监控数据上报到现有报警系统,做到实时报警

发布系统

dubbo的服务在正常停止的过程中不再接受新的请求,但是启动后在注册中心完成注册马上开始接受新的请求；我们希望启动后由发布系统控制什么时候开始接受新请求；

版本控制

服务化后对所有的依赖必须基于强版本，所以对每一个发布的服务都提供了强版本策略，而且正常情况下保证每个新版本必须兼容旧版本；版本路线如图所示:

流程控制

改造现有的流程控制系统，做到每个团队可以独立开发，独立测试，独立部署，独立上线以及独立回滚; 而且保证CI, CD能正常工作,所有流程能自动完成;

服务拆分

首先拆分出基础服务,包括地址服务，推送服务，图片服务，等与业务无关的服务；其次按照业务领域进行拆分，包括订单，用户中心，支付等

后续

• 服务安全
• 物理分组
• 多维度监控
• 等…