共计 4494 个字符，预计需要花费 12 分钟才能阅读完成。
作者：涯海
最近一年，小玉所在的业务部门发动了轰轰烈烈的微服务化静止，大量业务中台利用被拆分成更细粒度的微服务利用。为了迎接行将到来的双十一大促重保流动，小玉的主管让她在一周内梳理出订单核心的全局要害上下游依赖，提前拉通各方对齐重保计划。这个工作可愁坏了小玉，平时她只与间接上下游业务方打交道，当初要梳理出订单核心残缺的依赖门路，头发愁掉了一大把依然不晓得该如何下手。无奈之下，小玉再次求助于万能的小明。
针对小玉的问题，小明提出了一个想法，首先调用链能够追踪一次申请的残缺调用门路，然而单条调用链无奈反映出所有的调用分支，也无奈通过流量大小体现出依赖的强弱，而逐条剖析调用链的老本又太高。那么，是否能够通过程序将一批具备雷同特色（比方通过某个利用，或者调用了某个接口）的调用链聚合成一颗树，通过剖析这棵树的状态与流量，就能够疾速梳理出要害节点与依赖门路，而这就是链路拓扑性能的雏形。
如上图所示，入口利用 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 申请出入参，或者是所在机器的环境标签。在这方面，开源社区不足相应的规范，而各大厂商的商业化实现差别也比拟大。
综上所述，不同聚合维度生成的链路拓扑具备不同功能定位与个性，如下表所示：
03 链路拓扑生成形式
为了最大水平的保留链路数据的端到端关联信息，链路拓扑通常是基于调用链明细数据间接聚合生成，而不是基于指标数据的二次聚合。仔细的读者可能会发现这里暗藏着一个颇具挑战的技术难题，就是如何均衡海量链路数据聚合的实时性、准确性与灵活性。现实状况下，咱们心愿基于符合条件的全量调用链明细数据疾速生成最实在的链路拓扑，实现“又快又准又灵便”。但在理论利用中，鱼与熊掌不可兼得，咱们只能在“快”、“准”、“灵便”之间进行抉择，也因而衍生出了不同的链路拓扑生成流派。
（一）实时聚合
实时聚合是依据用户指定查问条件，动静筛选调用链并生成拓扑图的一种形式。这种形式的益处是实时性较高，应用非常灵活，能够指定任意条件，比方查看大于 3S 的调用链生成的拓扑，或者仅蕴含异样调用的拓扑。毛病是当满足条件的调用链明细数据量超过肯定阈值后，可能会打爆实时聚合计算节点，因而，通过会设定一个聚合条数下限，比方 5 千条，就义肯定的数据精确度，换来极高的灵便度与实时性。
（二）离线聚合
离线聚合是依据一组当时定义好的聚合规定，周期性生成拓扑数据的一种形式。例如不蕴含任何筛选条件的利用、接口这种根底拓扑数据就能够通过离线聚合生成。这种聚合形式的益处是能够利用离线计算的程度扩展性，撑持海量链路数据的聚合计算，生成后果会更加精确。毛病是实时性较差，聚合规定变更到新拓扑生成的周期较长。离线聚合通常用于全局拓扑数据的准确计算。
（三）预聚合
预聚合是一种实践上可行的拓扑生成形式，它的思路是从入口节点开始，一直向下透传全链路的残缺调用门路信息，并在端侧生成相应的预聚合指标。不思考透传信息的长度限度与端侧预聚合开销，这种形式的益处就是节俭了在服务端将明细数据转化为拓扑数据的过程，实现又快又准的指标。然而缺点就是不反对自定义规定，否则透传与预聚合的开销会直线回升，影响业务过程的性能与稳定性。预聚合的原理示意图如下所示。
04 3D 拓扑
流量与资源是一对“好兄弟”，二者密切相关。流量影响着资源分配，而资源反过来又束缚着流量状态。大部分流量异样归根结底是资源配额有余或调配不合理导致的，比方峰值流量霎时耗尽资源，或者流量不均导致的“热点”等。咱们在定位流量异样根因的过程中，往往须要联合绝对应的资源状态进行剖析；反过来，当一个资源节点出现异常时，咱们也心愿晓得它会影响其上运行的哪些流量？因而，在代表流量的链路拓扑上，关联绝对应的资源数据，造成更加残缺的 3D 拓扑，貌似是个不错的抉择。
如下图所示，3D 拓扑不仅蕴含 PaaS 层的利用、接口流量节点状态与依赖，还能够下钻查看绝对应的 IaaS 层过程、实例等资源状态。3D 拓扑为流量与资源建设了一个连贯，帮忙咱们更直观的定位资源瓶颈引发的流量异样问题。
3D 拓扑以一种奇妙的形式传递了更多的信息，然而它也有一个十分致命的缺点，就是信息密度过于集中。在简单拓扑环境下，体现可能还不如 2D 拓扑来的直观，大大降低了它的实用价值。如下图所示，当实例规模达到数百，接口数量达到上千时，3D 拓扑交互上的复杂性显著升高了诊断排查的效率，更多用于大屏展现。
为了升高 3D 拓扑的交互老本，一种可能的思路是联合智能诊断技术，主动突出异样链路，精准收敛展现数据范畴。不过，这对于技术与产品的要求较高，实用性还有待大量实在生产环境的测验。
