链路追踪实战：一次慢请求是怎么在多服务之间被定位出来的

单服务时代，慢请求排查通常还比较直接：看应用日志、看数据库慢查询、看几张监控图，大多就能逐步收缩问题范围。但一旦请求会经过网关、鉴权服务、业务服务、缓存、数据库和多个下游服务，排查难度就会急剧上升。你明明知道“这个请求很慢”，却不知道时间到底耗在哪一跳。

链路追踪最核心的价值，就是把一次请求在多个服务之间的传播路径、耗时分布和异常节点重新拼起来，让原本割裂的局部日志和局部指标，重新变成一个完整过程。

为什么慢请求在多服务系统里特别难查

因为每个服务通常都只能看到自己的一小段。

网关能看到进入时间，用户服务能看到自己处理时间，订单服务能看到数据库访问时间，但如果没有统一链路标识和上下游关联，你很难把这些局部信息串成一条完整路径。结果就是每一层都觉得“我这里没那么慢”，但总体请求就是很慢。

所以多服务排查最难的地方，往往不是没有数据，而是数据彼此断开。

链路追踪会把一次请求拆成多个 span，每个 span 代表调用链上的一段工作，例如网关接收请求、某个服务处理、某次 RPC 调用、某次数据库访问。

这些 span 会通过 trace id 串在一起，于是你就能看到。

这让“请求慢”从模糊感受变成了可拆解的路径问题。

通常过程会像这样。

先从监控里发现某个接口 P99 延迟升高，再进入 tracing 系统抽样查看慢请求。你会看到这次请求一共经过了五段，其中网关耗时很短，业务服务本身也不算慢，但某个下游 RPC 调用占了总耗时的 70%。继续展开那个 span，又会发现它内部又卡在数据库查询或者另一个服务调用上。

这样一来，原本笼统的“接口慢”就能快速被压缩成“某一跳慢”。

因为 tracing 更擅长路径还原，不擅长看整体趋势，也不一定包含所有细节上下文。

如果你只靠 tracing，可能知道某一跳慢，但不知道这是普遍问题还是个别样本；也可能知道某次调用报错了，但具体参数、业务状态和异常堆栈还得回到日志里看。所以 tracing 的最佳位置，通常是连接 metrics 和 logs 的中间桥梁。

一个常见误区是部署了 tracing 系统，却没有把关键边界打点打好，导致 trace 虽然存在，但只能看到几个大块，定位仍然不够细。

另一个误区是采样策略完全不考虑成本和价值，最后不是采太少看不到关键问题，就是采太多造成存储和性能压力。

所以 tracing 不是装上就结束，它同样需要围绕排障目标持续优化。

试着用脑海里的系统画一条最常见的用户请求链路，至少包含。

然后问自己：如果这条链路今天变慢，我最快能知道哪一跳出了问题吗。如果不能，那就说明你已经非常需要 tracing 这类能力了。

链路追踪的价值，在于把多服务系统里原本割裂的数据重新组织成完整请求路径。它让慢请求排查从“每层各查各的”变成“沿着同一条请求链逐步压缩范围”。在复杂系统里，trace 不是锦上添花，而是连接全局指标和局部日志的重要桥梁。