面对微服务的N种坑，我们需要构建综合的微服务治理能力
这几年微服务的热度持续居高不下，企业纷纷向微服务架构转型。但在微服务落地时，大家更多是在技术架构层面发力，以为所谓的微服务化就是简单的引入一套微服务框架，却忽略了微服务架构带来的影响是全方位的，它会对整个研发体系，包括开发、运维、团队组织、研发协同都带来冲击。企业必须围绕微服务架构构建起一整套以服务治理为核心、从线下到线上的新的能力体系来支撑这套新架构。构建起这套能力体系的团队将享受微服务带来的“光明”，而未能构建起这套能力体系的团队却会遭到微服务的“反噬”，团队研发效率和质量不升反降，转型之路备受质疑。
怎样消除微服务架构的负面影响呢？
你有这样的困惑吗？
下面我们针对研发提效、故障根因分析、业务风险稽核介绍几种消除微服务架构负面影响的应对策略。
研发提效
微服务架构下，单体系统被拆成了不同的应用集群和服务集群，由不同的团队负责。曾经的本地调用变成分布式调用，中间增加了序列化、路由、负载均衡等一系列新的技术栈。整个环境变得很零散，我们很难得到一个既稳定又能快速响应的外部环境。联调一个业务功能，需要协调一堆的人，构建一整套的环境，成本非常高，调测成了研发的一大痛点
这里介绍一种综合利用服务mock及直连调测来构建的综合调测能力。
如图1所示，通过配置开关开启调测模式后，采用本地服务优先机制。即如果这个服务本地有则直接本地调用；如果没有，判断在直连调测中是否定义了这个服务的IP地址。如果有，绕过路由和负载均衡策略直接发起远程调用；如果没有，继续判断是否定义了服务的mock数据。如果定义了，执行mock调用；如果没有，就采用正常的分布式调用模式。
图1 微服务调测能力串联组合
在迭代开发的早期阶段，只是定义了大家遵循的服务接口，还没有接口的具体实现， mock能力会被频繁的使用，服务直连调测的比例比较低。随着开发工作的逐步推进，服务不断被开发出来并部署到环境中，这时mock的比例会逐步降低，直连调测的比例逐步增高。开发完成时，已经没有被mock的服务了，所有的服务都是部署到环境中的真实服务，此时的调用方式要么是直连调测，要么是正常的分布式调用，如图2所示。
图2 项目各个阶段灵活组合使用各调测手段
故障根因分析
在微服务离散化的架构下做故障根因分析是很困难的，APM调用链跟踪只能告诉你在哪个地方出问题了，却无法指出引起这个问题的根本原因是什么。
服务和服务之间除了存在直接的调用关系外，还可以通过所调用的资源或所依赖的主机、网络环境或配置信息来发生关联。比如两个服务共同调用某一个数据库表，或者两个不同服务的实例共享同一台物理服务器、受同一个降级开关的控制等等。通过服务调用关系、资源调用关系、环境依赖关系这三种关联关系可构建起一个围绕服务的立体关系网络，如图3所示。
图3 服务和资源之间的立体关系网络拓扑
故障往往沿着这个关系网络进行传导，如图4所示。服务器的磁盘IO异常会影响安装在其上的数据库服务，导致查询变慢；数据库服务的“劣化”又导致调用它的服务A的调用耗时变长，故障继续向上传导，最终使得大量的来自服务B的调用操作被阻塞。
图4 故障基于关系网络的传导
从这个例子可以看出故障沿着关系网络传导，并且大多是从底层资源往顶层资源传导，从被调用方向调用方传导。
除了人为失误或流程失当导致的故障之外的其它任何故障都可以套入到这个故障传导模型中。因此，可以基于以上的关系网络传导原理来构建针对线上故障的根因分析能力。
以某个包含异常的节点为起点，顺着调用方向或者依赖方向进行逐级查找，一直找到无异常的正常节点为止，或者只有进入线，没有出去线的节点为止。这样就可以找出连续包含异常指标的子网络，这个子网络的末梢节点，大概率就是故障传导链条的起点，该起点上的异常指标也就是所谓的故障“根因”。如果这个根因指标是一个应用异常，还要看它有没有记录异常堆栈，如果有，则查找最后一个异常（通常为真正的故障原因）。当然，这只是最基本的算法，实际应用中，往往还要结合故障的种类、故障严重等级权重、故障发生的时间顺序来提高查找的精度或做最终根因判定。
业务风险稽核
分布式架构的复杂度迟早会超出个人的理解能力，虽然能够通过调用关系网络的梳理进行局部的调用关系优化和核心服务识别，但当整个体系庞大到一定程度，就不可能再有一个人对整个业务链路上的所有细节都很清楚，毕竟“人力有穷时”。而微服务化架构更是加剧了复杂度的膨胀，让我们对整个体系的业务逻辑合理性的把控越来越困难。现在电商不时出现的由于运营配置失误，以每件1元的价格售出几万件电器，或者由于将实物奖品配置成电子卡券而使得用户可以重复领取等导致企业大量资损的“黑天鹅”事件，就是对业务前后逻辑掌控不一致，把关不严导致的。
那么，是否有一种方法和机制，让我们不再纠结于服务调用关系的复杂性，绕过它，通过某种手段来及时验证并找出服务集群整体业务逻辑的风险呢？
当然有！
再复杂的系统，终究也是为了完成某项业务，总是要将输入的请求转化成最终的业务结果。无论过程如何复杂，通过对核心业务服务的前置初始请求和后置的最终输出的把关，即可在“头”、“尾”处校验并把控分布式系统的整体风险。也就是说，分布式业务架构的准确性和合理性可以通过对核心环节的输入输出数据的稽核来进行把控。图5就是微服务架构下数据稽核体系的整体架构图。
图5 微服务架构下数据稽核体系的整体架构图
数据稽核主要使用了如下两种思想：
变换视角
这主要应用于（准）实时稽核业务上。从不同的视角看同一件事物总能获得一些不同的结论。例如一个订单拆单的逻辑问题会直接体现在物流成本校对环节上。因此，可以在物流成本校对时增加旁路逻辑来验证订单拆单逻辑的准确性和合理性。
聚沙成塔
离线稽核是数据稽核的“精髓”和重点，体现了“聚沙成塔”的哲学思维。通过离线场景的数据汇总来放大实时业务场景的隐性风险，并将之捕获。离线稽核一般从各个业务系统、服务对应的数据库或其他存储（文件、MQ、数仓）中进行数据拉取，按预先定义的稽核策略进行数据的汇聚，计算，并分析与正常总量的偏差，一旦发现异常，及时发出风险告警。
通关秘籍来啦！
以上总结了企业引入微服务架构后所面临的一些典型问题及应对策略。但现实中， 我们所遇到的坑远不止这些，在服务的性能度量、容量规划、健康度评估、稳定性保障、团队高效协同等等方面都可能遭遇一系列的“深坑”。毫不夸张的说，缺乏微服务的治理能力，是企业将微服务架构用好的最大拦路虎。
我从2006年接触服务治理概念至今的十余年时间里，在金融、电信、导航、航空、电商等行业中开展了大量服务化和服务治理相关的设计及开发工作。尤其是在华为，作为项目的总架构师，全程领导了治理项目及配套的研发工具套件集的架构设计和开发落地。这让我收获了非常多的经验和教训，并形成了个人面向微服务治理领域的完整技术体系。从2017年起，我在QCon、ArchSummit等技术大会及线下技术沙龙上做了一系列关于服务化和服务治理的技术分享与交流，也给一些企业提供服务治理的咨询。分享的过程中，我发现大家面对微服务治理有很多共性的问题和误解。微服务治理是一个完整的体系，不只是技术和经验的拼凑，要说清楚微服务治理，应该展现完整的体系全貌，但目前市面上还没有系统讨论微服务治理的专业书籍。2018年底我决定自己写一本关于微服务治理的书，从微服务的度量、管控、管理这3个维度入手，构建一个覆盖微服务线上、线下的广义的治理体系，同时将我的技术“世界观”和经验融入其中。
经过近一年半的反复打磨，本书终于问世，希望这本书能够给仍在（微）服务治理迷局中夺路狂奔的技术人员和技术管理者一点启发和指引。
在本书的第一、二两章中，我将全面阐述服务治理的发展历程，以及“大平台、微服务”架构下服务治理的难点及特点。在此基础上，提出由微服务的度量、管控及管理构建起一个三位一体的闭环体系来综合解决微服务全生命周期的现实治理需求。并阐述治理体系所涉及的相关细分领域及技术能力。
在第三、四两章中，重点介绍微服务的线上治理能力。通过微服务治理的度量指标体系及指标采集、存储、分析手段构建微服务度量能力，并在此基础上进行微服务的健康度分析、故障定界定位、容量规划、根因分析、趋势预测等来构建针对微服务的“看”的能力。通过限流、降级、容错、弹性伸缩、安全管控等管控手段来构建微服务的“管”的能力。同时通过应急预案、故障演练、混沌工程等稳定性能力建设来提升线上微服务的可靠性。
第五章将介绍通过APM及动态调用链跟踪来提升微服务的监控及度量能力。
第六章是微服务深度治理能力构建，将微服务的治理延升到架构、开发、测试、运维、团队协同等各个领域，从而实现微服务架构在组织中从“用的了”到“用的好”的提升。同时将服务治理能力反哺给业务，实现技术和业务的良性互动。
本书的七、八、九章是实践部分。通过一个指标采集、传输、存储、分析度量的完整演示实例来引导读者深入理解微服务治理的度量能力构建。
本书已在京东和当当上架，以下是出版社制作的宣传页，感兴趣的同学可以通过扫描下方二维码或者在这两个网站上自行搜索“微服务治理”关注一下！
作者简介： 目前在金融行业负责基金直销平台的整体技术架构和技术团队管理；在此之前，在华为的中间件技术团队，任六级技术专家，主导了多款华为软件的云计算产品的规划、设计、构建及落地工作，包括APaaS、ASPaaS、服务治理平台、分布式服务调测框架等几款产品；更早之前，在当当网的运作产品中心做技术负责人，主要负责电商中后台的仓储、物流、客服等系统的重构优化及技术管理工作。