裴华：拍拍信在微服务化过程中的思考与实践

裴华：拍拍信在微服务化过程中的思考与实践

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

但面对微服务改造依旧会有不理解的老板和同事们，今天小编就跟大家一起听拍拍信技术vp裴华讲课。10月22日在Spring Cloud 中国社区以主题为《进击的微服务架构》的周年活动-上海站活动现场，拍拍信技术vp裴华进行了如下分享：

微服务改造演进的概述

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

• 松耦合

• 独立发布

• 快速迭代

• 故障隔离

• 增加重用

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

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

原来简单的本地调用都变为网络调用，调用时效，异常处理等机制更加复杂；原来一个工程可以完成的事情，需要若干个工程的协作，每增加一个工程，对应的版本管理，主干合并等一系列工作增加，会增加维护成本，对于体系自动化的要求很高；

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

另外绝大部分公司都会有不少老系统，而且这些老系统承载了公司一定的业务。在进行技术体系演进和改造的过程中，必然遇到如何兼容性的问题，拍拍信自然也是如此，在微服务演进的过程中如何支持老的非微服务系统，使得系统平稳过渡演进，支持业务发展也是重中之重。

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

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

• 服务中间件

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

• 每个阶段的产出必须要能够被呈现（难）

• 架构的整体改变都可能影响很大

• 合理切分上线功能

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

• 合理规划设计

• 测试：功能、性能、异常

• 提前演练

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

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

• 轻量级，和现有Spring开发体系结合紧密，学习曲线平滑；

• 社区生态体系完善，有足够的开源体系可以支持或者可供二次开发和其他开源软件整合便捷；

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

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

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

• 思路的扭转

• 学习（自驱和被动）

• 提升（给未来的发展铺路）

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

• 中间件的支持（网关）

• 发布系统支持

• 微服务调用和httpclient接口同时支持

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

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

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

• 项目开发完成不是终点，产品业务能否长久生存靠监控

• 系统未成先想监控

• 监控必须确保多个维度，想得越全越靠谱

• 监控的维度尽可能保持一定交叉覆盖度

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

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

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

• head & query传参

• 基于数据库加载路由表信息

• 基于数据库加载路由规则信息信息

• 入参透传、入参转换、json入参转换

• 下游入参的groovy脚本执行支持出参的groovy脚本执行支持

• 出参透传、出参映射（json映射）

• 用户IP白名单

• 用户调用次数限量

• 全局静态URI黑名单

• 动态上线api、下线api

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

监控系统

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

l 拍拍信监控系统

• Metris业务打点

• PinPoint调用监控

完整的发布系统

• 支持微服务和微服务

• 

集成Apollo配置系统

• 支持yml本地开发配置，服务端统一读取Apollo配置中心

• 和发布系统整合，支持配置灰度发布

本期对微服务的分享就到这里啦，咱们下期见，欢迎大家联系探讨。

老板说一个赞5毛钱，一条留言1块钱(✿◡‿◡)