微服务链路风险分析

链路风险分析就是从链路通信的历史数据出发，分析出链路当前存在的风险，减少链路通信的隐患，提高系统的整体稳定性。链路风险分析可以解决的问题域很多，如超时时间设置是否合理、重试次数设置是否合理、服务 SLA 指标设置是否合理、服务的强弱依赖关系是否符合预期等，服务通信相关的一大部分故障是由于链路风险导致，可以通过链路风险分析的方式提前发现和解决，避免故障的发生。

一、超时和 SLA 风险

客户端访问服务端的超时时间配置，和实际访问情况不符，是非常常见的一种链路风险。上游服务的超时配置过小，会导致一些本来可以正常返回的请求超时，影响服务的 SLA 和正常的服务体验；超时配置过大，会导致下游服务故障时上游服务超时等待的时间太长，严重时会把整个系统拖垮。因此，超时设置直接关系到系统的稳定性，需要有相应的机制指导服务的超时设置，并及时发现线上系统中的超时配置隐患。

超时配置风险主要有两种：一种是超时时间和实际不相符；还有一种是上下游的超时设置不匹配，比如有 A、B、C 3 个服务，服务 A 访问服务 B，服务 B 访问服务 C，但实际业务中经常会遇到服务 A 访问服务 B 的超时时间比服务 B 访问服务 C 的超时时间小的情况。

二、强弱依赖或重试风险

微服务之间通信，如果该链路通信失败会导致整个请求处理失败，一般将这两个微服务之间的关系称之为强依赖，反之称之为弱依赖。我们可以基于服务的强弱依赖关系，进行降级、熔断等处理。

强弱依赖服务风险，是指链路通信之间的关系和预期不符。比如，服务 A 调用服务 B 的链路是弱依赖，但随着需求迭代业务逻辑发生变化，可能不经意间服务 A 调用服务 B 的链路实际上变成了强依赖，但大家仍然按照之前的先验知识，把它当成弱依赖，这就是一个很大的风险点。特别是链路故障时，基于弱依赖的前提进行降级等操作时，就可能会酿成悲剧，导致整个系统不可用。因此需要有相应的机制，定期检测出当前链路关系的风险点。

三、集群或拓扑风险

集群或拓扑风险是风险分析的一个主要来源。比如，某线上集群的一些机器因为保修临时下线一段时间，但机器修复好之后遗漏挂载，导致部分机器白白闲置；服务 A 调用服务 B 本来是同机房调用，由于故障或者流量切换演练等原因临时将调用关系切换到调用其他机房的服务 B 服务，但事后没有切回来，导致服务 A 调用服务 B 一直是跨机房访问，影响用户体验和系统稳定性；某服务 S 线上部署时没有考虑到地理位置因素，将过多的服务节点部署到同一个交换机下，交换机故障时导致服务同时有多个节点不可用，可用节点数不足导致服务雪崩。

四、链路调用风险

链路实时拓扑数据是一个宝藏，可以从中慢慢挖掘出链路调用层面的很多风险。比如，当前服务调用超过 20 个下游服务，扇出过大，不太符合微服务的设计准则，可以考虑是否有必要进行进一步的拆分。

微服务架构中，单个请求的链路特别长时，会带来一定的性能问题，因此可以从全局链路拓扑中将 TOP10 长的链路，或者链路深度超过 6 的链路列出来，反馈给业务人员，看看是否有必要进行架构层面的调整。

微服务拆分和设计过程中，建议不要出现两个微服务相互依赖的场景，可以通过链路拓扑图查找当前是否存在成环的链路，如果成环，说明服务之间产生了相互依赖，可以将类似风险反馈给业务人员进行整改。

链路风险分析是发现风险并对风险进行抽象和建立自动化检测机制的过程，本质上是对稳定性风险进行精细化管理的系统性工程，需要长期持续地建设下去。

发现风险是链路风险分析的第一步，为了能够持续发现系统新的风险，建议将风险分析和稳定性反模式结合起来：①根据系统中出现的重大故障，以及之前积累的容易出现故障的一些典型问题，梳理出稳定性反模式，也就是稳定性实践中容易犯的，不应该出现的一些模式；②判断这些反模式是否能通过自动化的方式检测出来。

同时为了方便新增风险的检测，可以建立一个完善的风险分析框架，具体包含风险现状、风险改进闭环、风险报告、风险自动通知机制等，新增的风险分析就直接基于框架开发，相当于增加个插件，可以大大提高风险分析的效率。