服务化架构升级实践

目前我们大部分业务都接入了服务化,在过去将近一年的时间里,我们踩了很多坑,也出现了几次生产事故,同时,从某种意义上讲,我们也做了某些「微创新」,使得架构更适合我们团队的实际情况。从目前的结果来看,基本达成了预定目标;

技术选型

在前期技术选型的时候,我们调研了DubboSpring Cloud,主要从以下这些方面考虑各自的优缺点;最终选择以Dubbo为基础技术框架:

  1. 社区支持
  2. 生态建设
  3. 服务治理
  4. 服务监控
  5. 与现有系统的集成
  6. 代码迁移成本
  7. 团队的流程
  8. 运维成本
  9. 团队的经验
  10. 学习成本

服务化SDK

考虑到当时Dubbo刚开始进入Apache孵化器,也方便我们以后升级;我们提供了封装Dubbo的服务化SDK给开发团队使用。我们扩展了如下功能:

  1. 启动完成标示,单个JVM中确保所有服务启动完成而且在注册中心注册
  2. 集成Apollo ,开发团队不用关心基础组件配置信息
  3. 集成监控,保证服务化后项目必须接入监控
  4. 集成限流降级系统,确保所有的provider必须接入流降级功能
  5. 定向指定服务节点,测试环境中多项目测试的情况下,可以对运行中的服务动态指定provider工作节点 。(我们也注意到官方在2.7版本的tag feature提供了类似的功能)

监控系统

系统架构服务化后,服务间调用关系错综复杂,出现问题很难定位。所以监控系统极为重要;而且我们一致认为投入生产前必须有全链路监控。为了快速上线,我们在Dubbo官方提供的监控系统dubbo-monitorzipkin基础上做了部分改造:

  1. dubbo-monitor官方的方案是将监控数据持久化到磁盘。我们考虑到数据保存到磁盘不方便查询,而且多个节点之间共享磁盘不是一个好的方案。所以,我们将数据持久化到MySql。
  2. 配置信息接入Apollo
  3. 接入我们现有的报警系统;将监控数据实时上报到我们的报警系统 。
  4. zipkin的链路跟踪信息接入我们的日志系统
  5. 打通全链路监控,从web系统到最后端基础服务调用关系

限流降级

我们采用阿里开源的Sentinel作为限流降级组件。Sentinel官方提供了与Dubbo集成的适配器,可以最快的速度投入生产使用。但是,由于Sentinel官方默认的限流降级规则是存储在节点内存中的,节点重启后规则会丢失。所以,团队根据官方提供Apollo的Datasource做了少许改造,使得规则可以持久化到Apollo

服务拆分

服务拆分是服务化改造的重点。 通常大家都会根据领域来拆分,而领域的划分可大可小没有一个绝对的标准。拆分太细,服务众多,运维成本较高;拆分太粗发挥不了服务化的优势,因此在服务拆分的时候要根据团队当前的实际情况而定。我们团队在具体执行的过程中采用了领域+上/下层服务的方式拆分。我们各个开发团队的划分就是按照领域划分的,而每个团队都会有底层服务(会提供接口给其它团队)和上层服务(为个自业务服务);所以,原则上每个团队两个服务,一个底层服务,另一个是上层服务;针对部分关键服务(比如,详情页,订单,支付等..) 有独立的服务 。真正做到独立开发,独立测试,独立发布,独立运维。

流程规范

DevOps

服务化后开发人员的智能发生了变化 :

  1. 开发团队的处警方式有被动告知转变为主动处理,系统的运行状态不仅仅依赖SA,更多依靠开发团队主动关注,SA更多关注系统级别的指标,开发人员必须关注系统,业务等各种指标;以最快的速度对系统的异常作出响应。
  2. 测试任务更多依赖开发人员完成,专职测试人员更多关注自动化和质量。
  3. 上线发布不再由SA直接参与,SA负责提供发布/回滚工具,在质量达标后由开发团队独立完成 。

上线流程

  1. 效率;之前上线涉及多个团队,依赖Jar包过多,上线过程经常遇到代码冲突,包依赖冲突等问题;排查问题涉及多个团队,耗时长,效率低。服务化后每次上线只涉及自己团队成员,不再有代码冲突和包冲突的问题,效率得到了很大的提升 。
  2. CI/CD流程的建立;我们在服务化推进的过程中同时建立了初步的CI/CD流程 。
  3. 自动化测试;服务化后上线频率更高,为了保证质量我们开始建立了自动化测试系统。

编码规范增加如下内容:

  • 事务处理
  • SQL中多表join
  • 引用的传递
  • 限流异常的处理
  • 超时异常处理
  • 单元测试规范

发布系统

  1. 流量切换方式;服务化之前我们大部分应用都是web应用;系统发布过程中流量的切换是通过Nginx完成的。服务化后流量切换需要依赖服务发现(我们用Zookeeper作为Dubbo服务发现的组件)组件完成;因此我们增加了流量切换组件 。
  2. 回滚方式:服务化后系统上线频率变高;同时意味着回滚的频率也会变高。考虑到回滚应用的时候如果需要回滚配置必须手工完成,这样效率并不高。因此,我们根据利用Apollo的OpenAPI真正做到了一键回滚。

后续

接下来,我们会聚焦如下方面:

  • 分库分表
  • 前/中台战略
  • 容器化
  • 自动化测试的加强
  • 监控系统的加强,缩短问题排查的时间

总结

给出一个「可落地的方案」能真正体现一个架构师实力;架构师遇到的很多问题都不是技术问题,只是用技术手段解决业务问题,流程问题,质量问题。架构师给出的每一个方案,必须立足于团队的实际情况,实际情况包括但不限于:成本,时间,团队能力,等。而且时刻关注执行结果;如果没有到达预期效果或者在执行过程中偏离方向,尽快根据团队实际情况调整方案。总之,所有的方案都是冲着三个目标 效率质量成本

yhzhu wechat
欢迎您扫一扫上面的微信公众号,联系我