0%

服务化准备工作

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

整体架构

我们的服务化是在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. 是否使用了接口参数在方法内部修改后的值,代码如下:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    /*服务端*/
    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能正常工作,所有流程能自动完成;

服务拆分

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

后续

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