【架构】学习余额宝背后的服务治理架构

说明：内容主要裁剪自《干货：36页PPT详解余额宝背后的服务治理架构》--作者简介：天弘基金移动平台团队任技术总监兼首席架构师，主要负责天弘移动直销平台的整体技术架构和技术团队管理。查看原文

感悟：通过用心学习大神分享的经验和实践，基本可以对余额宝背后的服务治理架构有比较深入的了解，里面提到的一些最佳实践可以借鉴到我们自己实际的项目中。大道至简，学以致用，才是王道。

一. 服务化架构演变

二. 业务中台是什么？

三. 服务化的冲击及挑战

分布式事务

四. 三位一体服务治理

五. 服务度量体系

1. 全生命周期度量指标获取

2. 服务治理度量及分析体系

六. 服务线上治理

1. 服务限流

2. 集群容错

3. 服务降级，熔断

4. 容量规划

5. 故障定界定位

6. 服务生命周期管理

7. 服务整体架构治理

七. 研发协同治理

1. 服务化背景下的团队协同最佳实践

2. 协同度量及治理

3. 开发治理

4. 测试质量治理

5. 分布式调试能力构建

服务化架构演变

前后经历了3个阶段：

典型的单体+竖井架构，复用性及可扩展性都差。
随着业务的快速发展及多端适配需求增多，两层架构下的前台业务服务层还是太重，无法支撑业务的快速变更，这时候将其继续拆分，将业务域的通用服务继续下层出新的业务中台层，这就形成了现在的三层服务化分层架构。
在目前的三层服务分层架构下，通用服务被不断下沉，所以越底层的服务被抽象度越高，也更通用、更静态，不会经常改变；越靠近前端的服务越贴近业务，越不稳定，会随着业务的快速变化而不断改变，客观上也必须保持更轻的体态。

【关键词：单体，烟囱，服务分层，前台，业务中台，通用后台】

业务中台是什么？

为什么会形成业务中台这样一个服务层呢？

本质上还是和业务的发展息息相关，业务的快速发展会驱使你不断的对服务进行拆分，并将通用服务不断下沉，只有这样，才能将服务拆的更小，而服务粒度越小，可组装性越好。只有这样，我们才可以根据不同的业务形态，通过服务组装和聚合的方式快速构建出前端应用，从而实现更快的开发速度，以支持业务的快速迭代及试错。

服务化架构的分层质量对业务中台的形成就有很重要的意义。如何进行更好、边界更清晰的服务分层，会直接影响到能否成功长出业务中台这个分层形态。
康威定律：组织的协同及管理模式必须与所采用的系统架构相匹配。
要最终推动业务中台这样的服务分层的诞生，业务驱动、服务分层、通用服务下沉、组织拆分都是必不可少的因素。

启示：如果你的业务形态比较单一，发展相对静态的话，就不会有那么强烈的服务分层和拆分的需求，自然就长不出所谓的“业务中台”的服务分层。所以，业务中台的建设要顺其自然，强扭的瓜不甜，企业需要根据自己的业务特征来判断是否需要建设业务中台。

【关键词：业务驱动，服务分层，快速试错，组织架构匹配】

服务化的冲击及挑战

架构的变更带来的影响是全方位的，影响的绝不仅仅只是应用系统，它会对整个研发体系，包括开发、运维、团队组织、协同都带来冲击，你必须构建起一整套从线下到线上的新的能力体系来支撑这套新的架构。

启示：很多团队没能构建起这套能力体系，直接在服务化的“反噬”下，倒在了路上，看不到服务化带来的“曙光”。

思考：集群环境中故障的定界定位：你如何快速定位问题出在哪？整个集群的调用关系是什么样的，如何梳理？合理不合理？整个集群的性能瓶颈在哪？这些都是运维要直面的问题。对研发来说，挑战也不少。团队被拆分了，团队之间如何高效的协作？系统被拆分了，功能被分散到远程节点，如何做调试？分布式架构下的数据一致性如何保障？等等…

【关键词：运维困局，开发困局】

分布式事务

启示：最终一致性的保障一定是“对账、对账、对账”！这是最传统，也是最可靠的最终防线，这也是金融公司的基础能力。

三位一体服务治理

【管理-度量-管控】在这套体系中，针对服务的度量是进行服务管控和管理的前提和基础，只有看得到，才能管得到，必须先解决“看”的问题，才能解决“管”的问题。

服务度量体系

全生命周期度量指标获取

不管采用何种协作模式，都可以从其相关的过程管理系统中抽取出相关的过程指标事件，比如一个任务什么时候完成设计、什么时候开始进入开发、什么时候完成开发…等等，这也是一大类很重要的治理度量指标。

【关键词：持续交付，DevOps, 敏捷持续集成，线下+线上】

服务治理度量及分析体系

治理决策和管控指令就是微服务度量及分析体系的最终产出物。

服务线上治理

服务限流

构建服务限流能力的难点，一是标准化，二是体系化。

大公司往往就是依靠体系的力量去构建起护城河，从而去碾压没有体系能力的小公司。

启示：限流一大原则是限流动作尽量前置，毕竟被限制的流量注定要被“抛弃”，越早处理越好，免得无谓的消耗资源。

【关键词：单机限流，集群限流，标准化，体系化】

集群容错

不管你决定使用哪种集群容错策略，一定要注意控制重试的次数，尤其是线上负载已经很高的时候，如果重试次数太多，一方面会推高服务被调用方的负载及并发，另外一方面会导致服务调用方的调用延时增长，双重因素叠加之下，最终极可能导致“服务雪崩”、集群被“击穿”。

启示：在使用集群容错的时候，一定要设置最大重试次数。

服务降级，熔断

一般在线上动用服务降级手段时，都是线上比较危急的时候，生死存亡了，这时候留给你思考和反应的时间不多，所以在使用服务降级之前一定要做好预案，提前梳理出核心业务链路和非核心业务链路，然后通过降级开关一键把部分或所有非核心链路降级，这样才能“救命”。

服务降级也有很多手段可以使用，包括：

容错降级
静态返回值降级
Mock降级
备用服务降级

构建服务降级能力也和限流机制类似，同样需要坚持标准化和体系化。

【关键词：标准化，体系化，预案】

容量规划

容量规划有两种形式：一种是容量预估，另一种是性能压测。

全链路压测的前提是单点压测，需要先把单点压测能力做好，才能做全链路压测。
在压测的时候，由于流量是模拟的，数据也是“伪造”的，所以一定要做好隔离，各种各样的隔离，尤其是数据的隔离。
在线性能压测是个“苦活”，需要提前发公告、全员戒备、时刻关注监控指标、有时候还要通宵搞，总结起来就是：智力密集型+劳动密集型+人肉密集型。

【关键词：容量预估，依赖关系，数据准备，数据隔离，支持体系】

故障定界定位

分布式环境下的故障定界定位，最有效的工具就是动态调用链路跟踪。使用开源的Zipkin，SkyWalking、PinPoint、CAT，还是使用商用的听云、AppDynamic或NewRelic等等。

动态调用链要用的好一定是需要和监控大盘相结合：

我们有一个单位时间段内异常最多服务的TopN排序列表，点击列表上的任何一个服务，会打开这个服务这个时间段内所有异常的列表，再点击列表上的每一个异常，就会打开这个异常所属调用链，进行故障分析。
可以利用监控大盘，监控大盘上有很多“毛刺”，这些都是系统的一些异常点，点击任何一个“毛刺”，会将“毛刺”所在时间段内的请求以“散点”的形式列出（可能会基于请求数量做抽样），“散点”的颜色代表了不同的状态，有的成功，有的失败。点击任何一个“散点”，就可以进入这个请求对应的调用链。
针对核心服务的异常有专门的监控表格，会列出最近发生的核心链路服务上的异常，点击这上面的任何一个异常，也可以进入对应的调用链。

【关键词：可视化，局部和全局，2/8原则】

服务生命周期管理

目前使用蚂蚁金融云提供的SOFA分布式服务框架，针对服务的线上生命周期管控的能力也是基于蚂蚁金融云的能力来构建的，蚂蚁金融云在它的云上弹性计算资源的基础上，通过整合资源编排及资源调度的能力，构建了微服务的综合管控平台。，通过这个平台，可以比较方便的进行服务的上线、下线、扩容、缩容等操作。

服务整体架构治理

服务是分层的，好的服务调用关系一定也是分层的，层层往下推进，最终形成一个有向无环图（DAG）。

对调用关系图进行闭环检测，如果检测到如图上G点到B点这样的回环调用的话，说明调用关系有问题，需要进行优化。这种回环调用也许现在无感，但难保未来哪天就会由于一条旁路逻辑导致死循环。
从调用关系上来说，它是被依赖最多的节点，自然是最重要的节点，作为枢纽节点，在运维等级上需要重点保障。当然，实际应用中，我们还会加上调用量这个权重来综合判定服务节点的重要性。
可能有些服务节点再也不会有调用关系了，比如图上绿色的L节点，这些节点再不会去调用别的服务节点，别的服务节点也不会来调用它。这类被找出来的“孤零零”的节点，可以考虑对它进行下线处理，以释放资源。

研发协同治理

服务化背景下的团队协同最佳实践

在每期工作量评估时，一般会预留一些工作量buffer，以应对临时性的需求，这类需求不受版本约束，按需发布。如果这个迭代周期内没有紧急需求，我们会从backlog中捞一些架构优化的需求来填补这些buffer。
为什么会持续有一些架构优化的活呢？因为经常有一些紧急需求，使用正常开发方案可能无法如期上线，但业务又要的比较急，必须用一些应急性的临时方案先上线使用。

协同度量及治理

每个迭代持续的进行精益看板的数据分析和度量，并通过治理策略进行不断的改进优化，可以让我们的研发协同越来越顺畅。

【关键词：精益看板，指标度量，持续优化】

开发治理

针对代码质量的管理，常规的做法除了代码的codereview外，一般还会使用Checkstyle，FindBugs，Jtest这类静态代码扫描工具来做代码的缺陷扫描。
汇总个人的质量综合评估报告，可以获得针对团队的开发质量综合评估报告。这两个报告本质上就是个人及团队的研发质量“画像”，完全可以作为个人及团队KPI考核的重要参考。

测试质量治理

两大核心诉求：一是提高测试的覆盖度，具体说就是提高需求覆盖度、代码覆盖度、页面覆盖度；二是降低测试用例的维护成本。

需求覆盖度：可以通过服务这个维度来对需求及测试用例进行关联，找出每个需求所对应的单元测试用例、自动化测试用例、手工测试用例，还可以把多个开发迭代周期的这些指标进行时间维度的纵比，以得出需求覆盖度的变化趋势。
代码覆盖度：有很多的工具帮我们来做，比如contest或者JaCoCo这类的工具，这里不再赘述。
页面覆盖度：可以将每次集成测试中调用的页面以日志的形式记录下来，再通过日志的聚合分析，结合工程源码的扫描，两厢一比较，就可以统计出哪些页面是没有被覆盖到的。
测试用例的维护成本分两块，一块是新增用例的维护成本，这个比较好度量；比较麻烦的是存量测试用例的变更度度量，我们采用相似度匹配算法，先算出存量测试用例前后两个版本代码的相似度，再换算成变更度。

【关键词：覆盖度，用例维护成本】

分布式调试能力构建

利用分布式服务框架提供的过滤器机制，开发了一个Mock过滤器，通过Mock数据文件来详细定义要被mock的服务的名称、入参及出参。这样，当请求过来时，将服务名及入参和mock数据中的定义进行比对，结果吻合，就直接将mock数据文件中的出参反序列化后作为服务的调用结果直接返回，同时远程调用的所有后续操作被终止。
基于服务框架的过滤器机制开发了“在线数据抓取过滤器”，它可以将指定的服务请求的入参和返回结果都抓取下来，直接写成mock数据文件。通过抓取方式获得的mock数据文件，往往有更好的数据质量，毕竟反映的是更加真实的业务场景。不过，这里还有一个合规性的问题，一定要做好数据脱敏的处理工作。对于我们，目前只在测试环境中进行数据抓取操作。
综合调测能力是综合P2P直连和Mock两种方式来共同构建的。在项目迭代的早期，前端团队和服务端团队，中台开发团队和后台开发团队会先定义接口，再基于接口直接生成mock文件，这样大家就可以并行开发。开始时，服务都没有开发出来，mock比例是最高的；随着迭代的进行，服务被不断开发出来，并部署到线上，这时，P2P直连调测的比例会上升，Mock的比例会下降；一直到集成测试时，只剩下P2P直连的模式，没有mock了。

【关键词：调试能力，Mock，综合调试】