#链路追踪概述

一个用户在下单时遇到了问题：页面一直转圈，最终返回「服务暂不可用」。问题是，这个下单请求经过了 API 网关 → 认证服务 → 用户服务 → 订单服务 → 库存服务 → 支付服务 → 物流服务，整整 7 个节点。用户想知道「卡在哪了」，但日志分散在 7 台机器上，你甚至不知道该从哪里开始排查。

这就是微服务架构下最经典的困境：故障定位难。

链路追踪（Distributed Tracing）就是为了解决这个问题。它记录一次请求从入口到出口的完整路径，让你在任何服务、任何节点上，都能回答同一个问题：「这个请求是怎么走到这里的？每一步花了多长时间？」

#为什么微服务需要链路追踪

在单体架构中，请求的执行路径是单进程的。如果出现问题，堆栈跟踪就能告诉你完整的调用链。但微服务架构把这个能力彻底打破了：

调用链路从进程内变成了进程间。一次用户下单请求，在代码层面可能涉及 7 个进程的交互。每个进程只看到自己被调用了什么、调用了什么下游服务，完全没有全局视图。

日志分散且无法关联。每个服务只记录自己的日志。当你想查一个完整请求的日志时，你需要先知道 TraceID，然后分别登录 7 台机器 grep——如果日志没有 TraceID，那根本没法串联。

故障传播不可见。服务 A 依赖服务 B，服务 B 依赖服务 C。如果 C 变慢了，B 会等待超时，A 会收到错误。但 A 的日志只显示「调用 B 超时」，看不到 C 的问题。

flowchart TB
    subgraph Gateway["API 网关"]
        GW["请求入口"]
    end

    subgraph Core["核心服务"]
        AS["认证服务"]
        US["用户服务"]
        OS["订单服务"]
        IS["库存服务"]
        PS["支付服务"]
        LS["物流服务"]
    end

    GW --> AS
    AS --> US
    AS --> OS
    OS --> IS
    OS --> PS
    PS --> LS

    style GW fill:#4a90d9,color:#fff
    style OS fill:#f5a623,color:#fff
    style IS fill:#e74c3c,color:#fff

    Note over IS: 库存服务慢查询<br/>延迟 3s

    LS -.-> Note over IS

在这个场景中，用户看到的是「下单失败」，但真正的问题是「库存服务的慢查询拖累了整个链路」。没有链路追踪，这个问题至少需要半小时才能定位。

#链路追踪的核心价值

链路追踪解决三个核心问题：

一、请求路径可视化。每个请求在系统中走过的路径，都以 Trace 的形式完整记录。你可以看到请求经过了哪些服务、每个服务的耗时占比、调用顺序是否合理。

二、延迟瓶颈定位。通过 Waterfall 图（瀑布图），可以直观看到每个 Span 的耗时，找出木桶效应中的那块短板。在一个典型的慢请求中，80% 的耗时往往集中在 1-2 个 Span 上。

三、错误传播追踪。当一个服务报错时，可以通过 Trace 追溯这个错误是从哪里产生的、传播路径是什么、最终在哪一层被用户感知。

#与其他可观测数据的区别

链路追踪不是日志，不是指标，它是第三种独立的数据形态。

指标的局限性在于它只看结果（延迟高/低），链路能看到过程（为什么会高）。日志的局限性在于它是离散的，没有请求级别的上下文。链路将两者连接起来——链路中有 Span 的耗时（类似指标），有错误信息（类似日志），还能关联到原始日志（通过 TraceID）。

#关键术语

#技术选型全景

链路追踪领域有多个活跃的开源和商业项目：

推荐选择路径：优先考虑 OpenTelemetry 生态（Jaeger / Tempo），因为数据采集层与后端存储解耦，未来更换成本最低。

#质量判断标准

读完本节后，你应该能够回答：

1. 为什么单体架构下「堆栈跟踪」可以解决定位问题，而微服务架构下不行？
2. 链路追踪解决的三个核心问题分别是什么？每个问题用其他可观测数据能解决到什么程度？
3. Trace 和 Span 的关系是什么？类比到现实的什么场景最恰当？
4. 链路追踪的 Waterfall 图（瀑布图）为什么对定位延迟瓶颈特别有效？
5. 在技术选型时，为什么推荐优先考虑 OpenTelemetry 生态？