2017 年 10 月 22 日，又拍云 Open Talk 联合 Spring Cloud 中国社区成功举办了“进击的微服务实战派上海站”。拍拍信技术 VP 裴华作了《拍拍信在微服务化过程中的思考和实践》，以下是分享实录：

技术改造如同徒步沙漠，怀揣着对技术的向往开始一段征程，然过程的艰辛让技术同学们痛并快乐着，补不完的bug，填不完的坑，但他们始终持续挑战！

一、微服务改造演进的概述

微服务是业内近年业内很火的流行词，迁移到微服务架构，大多强调这些好处：

• 松耦合
• 独立发布
• 快速迭代
• 故障隔离
• 增加重用

经过服务的拆分，将复杂到难以移动的单体应用，拆分为多个可以独立部署的服务，单个服务的复杂性远远小于整体，这样不同服务的开发者可以并行开发，从而提高开发效率；因为服务的细粒度，可以分配到具体的个人让他负责，随着业务的增长对服务做定向扩容；同时因为服务的隔离性，可以隔离故障，提高整体的稳定性。

但是微服务也不是万金良药，过渡或者不合理的拆分会造成整体系统的复杂性增加： 

1. 原来简单的本地调用都变为网络调用，调用时效，异常处理等机制更加复杂；

2.  原来一个工程可以完成的事情，需要若干个工程的协作，每增加一个工程，对应的版本管理，主干合并等一系列工作增加，会增加维护成本，对于体系自动化的要求很高；

3.  服务依赖复杂，增加服务治理的难度。因此如何合理规划微服务就成为了技术演进过程中重要的思考项。

二、微服务演进改造的实施过程中要点

1. 微服务改造需要实现的是整套完整体系（Spring Cloud生态体系）

• 服务中间件
• 网关系统
• 管理系统
• 监控体系
• 配置系统
• 发布系统

2. 体系必须逐步迭代完善，从小到大，从简到繁

• 每个阶段的产出必须要能够被呈现（难）
• 架构的整体改变都可能影响很大
• 合理切分上线功能

3. 服务切换必须不能影响业务

• 合理规划设计
• 测试：功能、性能、异常
• 提前演练

三、拍拍信在微服务实践路上的典型问题

1.  选型：

市面上常见的框架：dubbo/dubbox，为什么选择Spring Cloud？对比其他中间件，Spring Cloud的优势有：

• 轻量级，和现有Spring开发体系结合紧密，学习曲线平滑；
• 社区生态体系完善，有足够的开源体系可以支持或者可供二次开发和其他开源软件整合便捷；

重点考虑：便捷、成本低、体系全！

2. 微服务和非微服务的兼容与过渡：

人：实施依靠人的驱动，因此人的因素是很重要的

• 思路的扭转
• 学习（自驱和被动）
• 提升（给未来的发展铺路）

事：从实施过渡过程来讲，需要依赖以下的事情完成

• 中间件的支持（网关）
• 发布系统支持
• 微服务调用和httpclient接口同时支持

当然，这样做也导致了一些缺陷的存在，短期无法完全克服：链路关系没法完全打通；记账体系不一致。

3. 控制微服务拆分的粒度：

拆分的原则不要为了拆而拆，一个工程拆成100多个子项目见过么？不确定的可以先作为组件包，独立出来服务的逻辑要独立。

4.  监控

要有监控的不是系统，而是生命线一样的心态。

• 项目开发完成不是终点，产品业务能否长久生存靠监控
• 系统未成先想监控
• 监控必须确保多个维度，想得越全越靠谱
• 监控的维度尽可能保持一定交叉覆盖度

四、拍拍信微服务实践情况展示

1. 脚手架用来作为微服务开发的基础组件

2. 依赖于Zuul实现拍拍信网关系统

• head & query传参
• 基于数据库加载路由表信息
• 基于数据库加载路由规则信息信息
• 入参透传、入参转换、json入参转换
• 下游入参的groovy脚本执行支持出参的groovy脚本执行支持
• 出参透传、出参映射（json映射）
• 用户IP白名单
• 用户调用次数限量
• 全局静态URI黑名单
• 动态上线api、下线api

3. 完整的整体微服务管理体系

4. 监控系统

ELK用于支持原有系统和运维日志体系

l 拍拍信监控系统

• Metris业务打点
• PinPoint调用监控

5. 完整的发布系统

• 支持微服务和微服务
• 支持灰度

6. 集成Apollo配置系统

• 支持yml本地开发配置，服务端统一读取Apollo配置中心
• 和发布系统整合，支持配置灰度发布