微服务治理之三维度检测措施

窃以为DevOps平台的下半场是架构治理平台，如何回答好微服务架构治理的难题，实现架构治理的数字化，是最近一段时间在思考的问题。最近学习了一下李鑫老师的《微服务治理》一书，以下是整理的读书笔记，主要关注于检测，而不是常见的微服务管控，供读者参考。

目标：

找出重要的服务和接口，进行分级保障

分析单个微服务的架构设计的合理性，

梳理整体架构短板，优化架构体系

如果你不能度量它，你就无法改进它。架构是在不断演进的，也是在不断腐化的。

微服务治理中最基本也是最重要的部分，是针对微服务进行度量检测。通过对线上数据的全面分析和评估，来了解线上微服务运行的真实情况，为微服务治理提供真实、有效的量化数据，并通过预设的指标、阈值、门禁等举措来落地数字化治理。

检测手段：

从服务-接口-链路三个维度进行分析，可以有如下的几种检测手段，

集中调用检测指调用该服务的上级服务的数量（扇入 Fan-in），是微服务治理的基本指标。从普遍意义来说，如果服务A被10个其它服务调用，服务B只被1个其他服务调用，那么微服务A的重要性大概率高于服务B。当然，也要考虑服务在业务域中的重要级定义。如果某服务的上级服务数量多，则出现故障时影响面大，应当被定义更高的运维等级，提供更好的资源配置和更高的监控告警级别。

微服务扇出检测（Fan-Out），即获得该微服务所调用的外部服务的数量。数量越大，表明该微服务的外部依赖越大。通过该项检测让我们考虑该微服务对外耦合度的必要性，对微服务拆分进行优化。

接口数量检测，从服务层面列举每个服务有多少个对外接口是微服务架构治理中的基础指标，通常平均每个服务对外提供的接口数量在8个~60个是业界认为比较合适的范围，数量太少意味微服务拆分太零散，数量太多意味微服务变成‘单体应用’，需要进行更合理的划分。

闭环检测，虽然微服务集群的服务数量众多，但服务是根据业务分层的，因此理想的服务调用拓扑关系应该是分层并最终形成一个有向无环图(DAG),如果调用关系中存在反向依赖，需要进行优化。

来源：lvshen_9

在代码层面，当两个类之间出现循环依赖时，可以通过IDE或者Sonar扫描的方式来比较容易地探测到这个问题。而在众多的微服务中，如果出现了这种情况，则需要借助调用链分析来解决这个问题。

服务时延毛刺检测，也就是调用耗时分布统计，以每分钟所有调用请求的平均延时（或者95、99百分位延时）来得到调用耗时分时分布图，进而确定毛刺发生的时点，并进一步结合应用日志等信息，确定毛刺发生的根因。

冗余服务（或版本）检测，随着架构的变迁，服务之间的调用关系也在不断变化，有些微服务不再存在调用关系，在微服务整体调用关系图上，这些微服务不再有与其它服务的连线。通过定期关系扫描可找出这类“孤点”，对其进行下线处理，以释放资源。

热点接口检测是微服务治理中的指标之一。将被调用次数靠前的top N接口找出来分析其原因，有助于把握整体的微服务特征。热点接口可能给我们提供以下线索：1. 接口是否被不合理地重复调用。2. 技术类接口的高频调用是否可以通过优化框架来避免。3. 热点接口成功率和耗时是否控制在合理范围（需要结合线上更多信息）。

冷接口，或者冗余接口检测， 同上。

连续时段突变分析， 首先是基于调用量的时序分析，如每分钟/每小时调用次数变化TOP图表，第一时间发现有预谋的灰产行动的前值行为。其次，也可以基于服务调用耗时做分钟级别的连续耗时突变分析，形成每分钟调用耗时变化TOP图表。根据多个连续时间窗口的变化率指标，结合阈值进行自动判断，并发出告警信息。

最长调用链检测是微服务治理中的常用手段，因为整体稳定性是各相关节点稳定性的乘积，因此涉及的节点越多，稳定性越差。按照微服务治理中的常用思路，将这些长调用链找出来，重点分析排在头部的调用链的必要性和合理性，看能否对调用链长度进行缩减和优化。

重复调用探测是微服务设计中坏味道探测的一个手段。重复调用分为三类：第一类是循环调用，典型得如在for循环中进行数据库读写或者外部接口的同步调用。这些都会导致接口性能的下降。第二类是递归调用。分两类场景：本地递归和跨服务递归。跨服务递归会埋下资源隐患，因递归深度的不确定性，导致服务间通讯链接的资源消耗存在不确定性，可能导致TCP通讯故障。第三类是未合理设置缓存。如获取用户信息操作，用户信息在一定时间内不会变化，且高频用户数量较少，通过合理设置本地缓存是提高响应速度、降低服务间调用次数的有效措施。

长耗时链路检测是微服务治理中的常规检测项目。将执行时间最长的Top N链路找出来分析根因，有助于找出性能瓶颈并提供针对性的优化建议。在该部分的分析中，我们期待回答两个问题：链路的整体耗时情况；哪些接口执行慢，这些慢接口被执行了多少次。

冗余代码检测 ，将动态调用链和静态调用链结合进行冗余代码的排查。通过将动态调用链的数据叠加在静态调用链上，获取到哪些链路在线上已不再调用，该部分代码可以进一步分析是否可以界定为冗余代码并及时消除。经典案例就是骑士资本当年部署时无意间打开了一个开关，然后触发了一段冗余代码，直接把自己搞倒闭了。感兴趣的同学可以搜索一下这个故事。