使用篇丨链路追踪（Tracing）其实很简单：请求轨迹回溯与多维链路筛选

在日常生活中，我们可能都经历过以下场景：去医院看病就诊，但预约页面迟迟无法打开；新款手机发布日促销秒杀，下单页面一直卡住转菊花；游戏大版本更新，在线人数过多，导致人物一直在“漂移”。这些问题令产品体验变得非常差，有耐心的同学还会吐槽几句，没耐心的同学早已转身离开。试想一下，作为该系统开发/运维人员，又该如何避免此类问题发生，或者快速定位止损？

关键路径与多条链路对比

本章我们将以业务 Owner（小帅）的视角，逐步了解分布式链路追踪的各种基础用法：小到单次用户请求的异常根因诊断，大到全局系统的强弱依赖梳理，分布式链路追踪都能给予确定性答案。

小帅作为一家电商公司订单中心的业务 Owner，核心 KPI 就是保障创建订单 createOrder 接口的可用性，如响应时延低于 3s，成功率大于 99.9%。一旦该接口可用性出现问题，会直接影响用户下单行为，造成业务资损，进而影响小帅的绩效和年终奖。

但创建订单接口直接或间接依赖多个其他系统服务，如资金、地址、优惠、安全等。一旦某个下游系统服务可用性出现问题，也会造成创建订单失败或超时。为此，小帅特别头痛，每当创建订单接口不可用时，小帅都非常心急，却不知该如何定位根因，只能拉上所有下游接口负责人一起评估，不仅费时费力，低效排查也造成业务损失进一步扩大，经常被老板痛骂。

当小美了解这个情况后，推荐接入分布式链路追踪系统，并通过一系列故障应急案例，指导如何利用 Tracing 定位问题，梳理风险，提前预警，切实提高了订单中心的可用性。小帅经常会遇到各种用户反馈的创建订单超时问题，以往对此类问题颇有些束手无策。不过，接入分布式链路追踪系统后，通过调用链准确回溯超时请求的调用轨迹，小帅就可以轻松定位耗时最长的接口信息，如下图所示，A 接口超时的主要原因是调用 D 接口导致的。

但如果是下面这种情况，A 调用 B，B 又调用 C。那么，导致 A 接口超时的根因到底是 B 接口，还是 C 接口呢？

为了区分真正影响用户体验的 Span 耗时，我们先来了解一下关键路径的概念。

关键路径

如果一次 Span 调用有 t 段耗时在关键路径上，那么去掉这 t 段耗时，整条链路的总体耗时也会相应的缩短 t 段时间。仍以上面那条链路为例，灰色部分表示关键路径，缩短任意关键路径上的耗时都可以减少整体耗时。此时，我们可以判断 A 接口超时的主要原因是 C 接口导致的。

再来看另一种情况，如果 A 接口同一时间并行调用 B、C、D、E 接口，那么耗时最长的 D 接口就成为关键路径，如下图所示。

但是，如果我们将 D 接口耗时减少 t1+t2 两段时间，整体耗时却只减少了 t1 段时间，因为，当 D 接口耗时小于 B 接口时，D 接口就不再是关键路径，而是由 B 接口取代。这就好像主要矛盾被大幅缓解后，次要矛盾就变成了主要矛盾。

综上所述，我们在做耗时性能分析时，应该首先识别出关键路径，然后再做针对性的优化。对于非关键路径上的耗时优化不会对最终的用户体验产生价值。

多条链路对比

单条调用链路只能用来分析各个接口的绝对耗时，而无法得知每个接口的耗时变化情况。但是，绝对耗时长不代表这个接口就一定有问题，比如数据存储接口耗时通常要比单纯的计算接口耗时要长，这种长耗时是合理的，无需特别关注。

因此，在诊断性能退化问题时，我们更应该关注相对耗时的变化。比如获取同一个接口在耗时异常时段与正常时段的多条链路进行比对，从而发现导致性能退化的原因。下图展示了 A 接口的两条不同链路，我们可以清楚的看到，虽然第一条链路的 B 接口耗时要比 C 接口耗时长，但是导致 A 接口整体耗时从 2.6s 涨到 3.6s 的原因，其实是 C 接口的相对耗时变长了 1s，而 B 接口的相对耗时几乎不变。因此，当 A 接口的响应时延超过 3s，不满足可用性要求时，我们应该