目前我们大部分业务都接入了服务化，在过去将近一年的时间里，我们踩了很多坑，也出现了几次生产事故，同时，从某种意义上讲，我们也做了某些「微创新」，使得架构更适合我们团队的实际情况。从目前的结果来看，基本达成了预定目标；
技术选型
在前期技术选型的时候，我们调研了Dubbo和Spring Cloud，主要从以下这些方面考虑各自的优缺点；最终选择以Dubbo为基础技术框架：
- 社区支持
- 生态建设
- 服务治理
- 服务监控
- 与现有系统的集成
- 代码迁移成本
- 团队的流程
- 运维成本
- 团队的经验
- 学习成本
服务化SDK
考虑到当时Dubbo刚开始进入Apache孵化器，也方便我们以后升级；我们提供了封装Dubbo的服务化SDK给开发团队使用。我们扩展了如下功能:
- 启动完成标示，单个JVM中确保所有服务启动完成而且在注册中心注册
- 集成Apollo ，开发团队不用关心基础组件配置信息
- 集成监控，保证服务化后项目必须接入监控
- 集成限流降级系统，确保所有的provider必须接入流降级功能
- 定向指定服务节点，测试环境中多项目测试的情况下，可以对运行中的服务动态指定provider工作节点 。(我们也注意到官方在2.7版本的tag feature提供了类似的功能)
监控系统
系统架构服务化后，服务间调用关系错综复杂，出现问题很难定位。所以监控系统极为重要；而且我们一致认为投入生产前必须有全链路监控。为了快速上线，我们在Dubbo官方提供的监控系统dubbo-monitor和zipkin基础上做了部分改造：
- dubbo-monitor官方的方案是将监控数据持久化到磁盘。我们考虑到数据保存到磁盘不方便查询，而且多个节点之间共享磁盘不是一个好的方案。所以，我们将数据持久化到MySql。
- 配置信息接入Apollo 。
- 接入我们现有的报警系统；将监控数据实时上报到我们的报警系统 。
- zipkin的链路跟踪信息接入我们的日志系统
- 打通全链路监控,从web系统到最后端基础服务调用关系
限流降级
我们采用阿里开源的Sentinel作为限流降级组件。Sentinel官方提供了与Dubbo集成的适配器，可以最快的速度投入生产使用。但是，由于Sentinel官方默认的限流降级规则是存储在节点内存中的，节点重启后规则会丢失。所以，团队根据官方提供Apollo的Datasource做了少许改造，使得规则可以持久化到Apollo 。
服务拆分
服务拆分是服务化改造的重点。 通常大家都会根据领域来拆分，而领域的划分可大可小没有一个绝对的标准。拆分太细，服务众多，运维成本较高；拆分太粗发挥不了服务化的优势，因此在服务拆分的时候要根据团队当前的实际情况而定。我们团队在具体执行的过程中采用了领域+上/下层服务的方式拆分。我们各个开发团队的划分就是按照领域划分的，而每个团队都会有底层服务(会提供接口给其它团队)和上层服务(为个自业务服务)；所以，原则上每个团队两个服务，一个底层服务，另一个是上层服务；针对部分关键服务(比如，详情页，订单，支付等..) 有独立的服务 。真正做到独立开发，独立测试，独立发布，独立运维。
流程规范
DevOps
服务化后开发人员的智能发生了变化 :
- 开发团队的处警方式有被动告知转变为主动处理，系统的运行状态不仅仅依赖SA，更多依靠开发团队主动关注，SA更多关注系统级别的指标，开发人员必须关注系统，业务等各种指标；以最快的速度对系统的异常作出响应。
- 测试任务更多依赖开发人员完成，专职测试人员更多关注自动化和质量。
- 上线发布不再由SA直接参与，SA负责提供发布/回滚工具，在质量达标后由开发团队独立完成 。
上线流程
- 效率；之前上线涉及多个团队，依赖Jar包过多，上线过程经常遇到代码冲突，包依赖冲突等问题；排查问题涉及多个团队，耗时长，效率低。服务化后每次上线只涉及自己团队成员，不再有代码冲突和包冲突的问题，效率得到了很大的提升 。
- CI/CD流程的建立；我们在服务化推进的过程中同时建立了初步的CI/CD流程 。
- 自动化测试；服务化后上线频率更高，为了保证质量我们开始建立了自动化测试系统。
编码规范增加如下内容:
- 事务处理
- SQL中多表join
- 引用的传递
- 限流异常的处理
- 超时异常处理
- 单元测试规范
发布系统
- 流量切换方式；服务化之前我们大部分应用都是web应用；系统发布过程中流量的切换是通过Nginx完成的。服务化后流量切换需要依赖服务发现(我们用Zookeeper作为Dubbo服务发现的组件)组件完成；因此我们增加了流量切换组件 。
- 回滚方式：服务化后系统上线频率变高；同时意味着回滚的频率也会变高。考虑到回滚应用的时候如果需要回滚配置必须手工完成，这样效率并不高。因此，我们根据利用Apollo的OpenAPI真正做到了一键回滚。
后续
接下来，我们会聚焦如下方面：
- 分库分表
- 前/中台战略
- 容器化
- 自动化测试的加强
- 监控系统的加强，缩短问题排查的时间
总结
给出一个「可落地的方案」能真正体现一个架构师实力；架构师遇到的很多问题都不是技术问题，只是用技术手段解决业务问题，流程问题，质量问题。架构师给出的每一个方案，必须立足于团队的实际情况，实际情况包括但不限于：成本，时间，团队能力，等。而且时刻关注执行结果；如果没有到达预期效果或者在执行过程中偏离方向，尽快根据团队实际情况调整方案。总之，所有的方案都是冲着三个目标 效率，质量，成本 。