1000万云上开发者，全栈云产品0元试用：点击 免费试用 ，即刻开启云上实践之旅！

(相关资料图)

作者：涯海

最近一年，小玉所在的业务部门发起了轰轰烈烈的微服务化运动，大量业务中台应用被拆分成更细粒度的微服务应用。为了迎接即将到来的双十一大促重保活动，小玉的主管让她在一周内梳理出订单中心的全局关键上下游依赖，提前拉通各方对齐重保方案。这个任务可愁坏了小玉，平时她只与直接上下游业务方打交道，现在要梳理出订单中心完整的依赖路径，头发愁掉了一大把仍然不知道该如何下手。无奈之下，小玉再次求助于万能的小明。

针对小玉的问题，小明提出了一个想法，首先调用链可以追踪一次请求的完整调用路径，但是单条调用链无法反映出所有的调用分支，也无法通过流量大小体现出依赖的强弱，而逐条分析调用链的成本又太高。那么，是否可以通过程序将一批具有相同特征（比如经过某个应用，或者调用了某个接口）的调用链聚合成一颗树，通过分析这棵树的形态与流量，就可以快速梳理出关键节点与依赖路径，而这就是链路拓扑功能的雏形。

如上图所示，入口应用 A 依赖了多个不同深度的下游应用，并且每次调用的路径并不相同。为了梳理出应用 A 的完整调用依赖，可以将多条调用链聚合成一棵树，从根节点到叶子节点的每条路径都代表着一种流量流转路径，而节点的状态反映了流量的特征，比如次数、耗时、错误率等。 通过调用链聚合，综合分析端到端流量路径与状态的方法就是链路拓扑。 链路拓扑与调用链的关系就好比样本集与离散样本点，前者反映了整体的分布情况，可以有效避免单个样本随机性对评估结果的影响。

01 链路拓扑的经典应用场景

链路拓扑最核心的价值，就是通过分析节点间依赖路径与状态，提供强弱依赖梳理、瓶颈点分析、影响面分析、故障传播链分析等能力，下面我们来深入了解下这些经典用法。

（一）强弱依赖梳理

链路拓扑最典型、最被人熟知的应用场景就是依赖梳理，特别是在一个大型分布式系统中，数以万计的应用间依赖关系复杂到令运维同学怀疑人生。下图展示了 2012 年的淘宝核心链路应用拓扑，密密麻麻如蛛网般的依赖关系已经远远超出了人工梳理的范畴，而这种情况在微服务迅猛发展的当下并不少见。

在复杂业务环境中，不仅需要梳理出依赖关系图，还需要识别哪些是影响核心业务的强依赖，哪些是“无伤大雅”的弱依赖。针对强依赖要投入更多的人力与资源，建立更加完善的保障体系，比如电话告警，联合压测等。针对弱依赖，可以考虑是否能够移除，或者建立次一级的保障措施。

区分强弱依赖的方式主要有以下几种：

根据流量大小进行区分 。这是一种简单粗暴的区分方式，大于一定流量阈值或比例的就识别为强依赖，否则视为弱依赖。这种判断方式的好处是简单清晰，可以由链路追踪平台自动识别，无需人力干预。缺点是不够准确，一些特殊的关键依赖虽然流量不大，但是却会直接影响业务的稳定性。 根据同步/异步调用类型进行区分 。这种区分方式的好处也是简单、易操作，减少了异步非阻塞（如消息）调用的干扰。缺点是在同步调用为主的业务中筛选效果不佳，而在异步调用为主的业务（红包、热点推送）可能造成误判。 人工标注 。鉴于业务的差异性，由业务 Owner 对自身依赖的直接下游的强弱性进行人工标注识别，可靠性会更高。但是这种方式对于人员经验和时间成本要求很高，并且无法自适应业务的变化。 半人工标注 。首先由链路追踪平台根据流量大小、同步/异步进行初步的强弱依赖识别，再通过有经验的同学进行人工标注修正。这样既节省了人力成本，也能有限度的自适应未来的业务变化。

强弱依赖梳理是相对低频的工作，通常发生在在大促或重保活动准备阶段、新应用上线或老应用下线、上云搬站等场景。比如阿里在每年双十一大促前，都会梳理核心业务的强弱依赖，并与往年进行对比，以便更好的进行针对性保障。

（二）瓶颈点/影响面分析

链路拓扑在问题诊断领域最常见的用法就是瓶颈点分析与影响面分析。前者是从当前节点向下游寻找导致问题发生的原因，主要用于问题定位；而后者是从问题节点向上游分析被影响的范围，主要用于业务风险定级。

接下来，我们通过一个数据库异常的案例，对比下这两种用法与视角的区别，如下图所示。

某天上午，应用 A 的管理员收到用户反馈服务响应超时，通过查看链路拓扑状态，发现 A 应用依赖的 D 应用接口变慢，而 D 应用调用数据库接口也出现异常。因此，小 A 通知小 D 即刻排查数据库连接等状态，尽快恢复可用性。这就是一个瓶颈点分析的过程。 由于小 D 业务不熟练，半小时过去了还没有完成有效的恢复动作，并且触发了数据库服务端异常。负责 DB 运维的同学收到数据库服务端告警后，通过链路拓扑向上回溯业务影响面，发现直接依赖的 D、E 两个应用均出现了大量慢 SQL，并导致间接依赖的应用 A、B 出现不同程度的服务响应超时。果断执行了数据库扩容，最终恢复了全部应用的正常访问。这就是通过影响面分析，辅助运维决策的过程。

瓶颈点与影响面分析主要是基于一段时间内的静态拓扑数据，并没有体现时间变化对拓扑节点状态的影响，无法回溯故障传播的过程。如上图右侧所示，如果只看这一张拓扑，我们难以判断出导致数据库服务端异常的应用到底是 D 还是 E。那么，是否能够动态回放链路拓扑的变化，更直观的分析问题源与传播趋势？答案无疑是肯定的，请看下文介绍。

（三）故障传播链分析

抛开时间的维度，问题源与影响面的边界并不是很清晰。一个被影响方可能会成为新的问题源，引发更大的故障。因此，为了能够更加真实的还原故障演变过程，我们需要观察并对比一组时间线连续的静态链路拓扑快照集，通过不同快照之间节点状态的变化还原故障传播链。这就好比通过监控视频还原凶案发生过程，要比单独的一张照片更加可靠。

以上一小节的数据库故障为例，一开始应用 D 由于请求缓存未命中，从而大量请求数据库导致慢 SQL，进而影响上游应用也出现响应超时。随着情况继续恶化，数据库服务端也开始过载，进而影响了应用 E 的正常调用。最后，应用 A、B 均出现大量响应超时，API 网关由于连接不足开始拒绝访问，引发更大面积的服务不可用。

在真实生产环境中，拓扑依赖与故障传播的过程可能会更加复杂，为了简化分析过程，可以根据一定规则将节点状态提取为各类异常事件，观察不同时刻的异常事件数量也可以辅助判断故障发生、传播与恢复的过程，如下图所示。

02 链路拓扑聚合维度

链路拓扑的聚合维度决定着拓扑节点的类型，面向不同的用户角色，提供了差异化的分析视角。在实际应用中，最典型的三种链路拓扑聚合维度分别是应用、接口与自定义维度，分别对应着应用拓扑、接口拓扑和业务拓扑。

应用拓扑 ， 顾名思义就是根据应用名称进行链路聚合，反映了应用间的依赖关系与总体流量状态。由于数据聚合粒度较粗，局部异常会被平均值掩盖，不适合精细化的问题诊断，更适合全局依赖梳理与重大故障定界，用户角色偏向于 PE 运维或 SRE 稳定性负责人。 接口拓扑 ， 是在服务接口这一维度进行的链路聚合，相比于应用拓扑更贴近研发视角，因为日常迭代的对象通常是某个具体的服务接口，无论是新接口上线、老接口下线或核心接口重保，接口粒度的链路拓扑更符合研发测试流程与职责划分习惯。应用与接口都是链路追踪领域的基础对象，对应的拓扑可以由链路追踪平台自动生成，无需过多的人工干预，使用起来较为方便。 业务拓扑 ， 是根据自定义维度聚合生成的偏业务视角的链路拓扑，通常比接口维度要更深一级，比如某个下单接口可以根据商品类目维度进一步细分为女装或家电，如下图所示。业务拓扑一般无法由链路追踪平台自动生成，需要用户结合业务特性定制聚合规则。此外，自定义维度的来源比较广泛，可以是手动添加的 Attributes 自定义标签，也可以是 HTTP 请求出入参，或者是所在机器的环境标签。在这方面，开源社区缺乏相应的标准，而各大厂商的商业化实现差异也比较大。

剩余60%，完整内容请点击下方链接查看：

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。