Spring Cloud 链路追踪：一个 Trace ID 串联所有服务

回顾：分布式调用的可观测性盲区

前面八篇，我们搭起了一套完整的微服务体系：

Gateway → order-service → payment-service

这条链路在正常时很顺畅，但如果线上出现一个请求耗时 3 秒，或者直接返回了 500，怎么排查？

你打开 order-service 的日志，看到它调了 payment-service。打开 payment-service 的日志，发现它在等某个第三方接口。但你怎么确定这两个服务的日志属于同一个请求？如果一个请求经过 5 个服务，手动串日志几乎是不可完成的任务。

这就是分布式系统特有的问题：单体应用报一个错，你一眼就能顺藤摸瓜；微服务里，藤被切成了好几段，散落在不同的机器上。

链路追踪就是重新把这根藤接上。

链路追踪解决什么

链路追踪给每一个进入系统的请求分配一个全局唯一的 Trace ID。这个 ID 沿着调用链一路透传：Gateway → order-service → payment-service，不管经过多少个节点，同一个 Trace ID 贯穿始终。

每个服务内部的一次调用被记录为一个 Span，包含以下信息：

调了哪个服务、哪个接口
什么时候开始、什么时候结束（耗时）
成功还是失败

最后所有 Span 发送到 Zipkin，按 Trace ID 聚合，形成一张完整的调用拓扑图。你拿着 Trace ID 去 Zipkin 一搜，整个请求的生命周期一目了然。

核心组件介绍

这个体系里三个组件的分工：

组件	角色	作用
Micrometer	指标采集标准	定义 Tracing 的抽象层，与具体实现解耦
Brave	追踪实现	生成 Trace ID / Span ID，管理上下文传递
Zipkin	存储与可视化	接收并存储所有 Span，提供 UI 查看调用链

三者协作流程：

请求进入 → Brave 生成 Trace ID → 通过 HTTP Header 往下游透传
          → 各服务 Brave 上报 Span → Zipkin Server 聚合存储
          → 你打开 Zipkin UI，搜索 Trace ID → 看到完整调用链

动手：全链路追踪接入

Zipkin Server

在 docker-compose.yml 中添加：

zipkin:
  image: openzipkin/zipkin:latest
  container_name: zipkin
  ports:
    - "9411:9411"

启动后访问 http://localhost:9411 进入 Zipkin UI。

各服务引入依赖

gateway-service、order-service、payment-service 都需要加入：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-tracing-bridge-brave</artifactId>
</dependency>
<dependency>
    <groupId>io.zipkin.reporter2</groupId>
    <artifactId>zipkin-reporter-brave</artifactId>
</dependency>

配置

在每个服务的 application.yml 中添加：

management:
  tracing:
    sampling:
      probability: 1.0
  zipkin:
    tracing:
      endpoint: http://localhost:9411/api/v2/spans

sampling.probability: 1.0 表示每条请求都采样。生产环境可以调低（比如 0.1 只采 10%），避免追踪数据量过大。

Gateway 的特殊配置

Gateway 需要确认 Tracing 的头能正确透传。实际上，Micrometer Tracing 会自动处理 HTTP Header 的注入和提取——请求到达 Gateway 时分配 Trace ID，向下游发起调用时通过 X-B3-TraceId 和 X-B3-SpanId Header 透传。

你不需要写一行透传代码。这就是 Micrometer 抽象层的好处：框架层面已经把所有事情做了。

Zipkin 控制台

全部服务启动后，发几个请求：

curl http://localhost:8080/order

打开 Zipkin UI → 点击「Run Query」→ 能看到最近的 Trace 列表，每个 Trace 展开后显示完整的调用链：

 gateway-service [1ms]
  └── order-service [5ms]
       └── payment-service [3ms]

点击某个 Span，能看到：服务名、方法名、开始时间、耗时、HTTP 状态码。

你可以按耗时排序，找到最慢的调用，然后点进去看是哪一跳拖了后腿。这在排查线上性能问题时价值巨大。

小结与下篇预告

这一篇我们打开了微服务的可观测性窗口：

理解分布式调用排查的核心痛点——日志散落、请求关联断裂
Trace ID 串联全链路，Span 记录单次调用详情
Micrometer + Brave + Zipkin 的分工协作模型
动手：一行透传代码不写，引入依赖 + 配置 endpoint，Trace ID 自动流转
Zipkin UI 查看调用拓扑与各跳耗时

至此，Spring Cloud 全系列的技术组件已经全部讲完。下一篇是系列的最后一篇——我们把这些组件串联成一张完整的架构全景图，并给出一个面试中可以用的回答框架。