Spring Cloud 微服务 · 第8节 · 链路追踪：Micrometer Tracing + Zipkin

七

链路追踪：Micrometer Tracing + Zipkin

Distributed Tracing

第五个问题：一个请求经过 5 个服务，哪一步慢了？用户反馈"下单页面卡了 8 秒"，你查日志：网关日志在、订单服务日志在、用户服务日志在……但你不知道这 8 秒花在哪一跳。链路追踪就是给每个请求发一张"通行证"（TraceId），经过每个服务都盖个章，最后串起来一张图，哪一跳慢一目了然。

论Spring Boot 3 之后用什么

老教程讲 Sleuth + Zipkin，Sleuth 在 Spring Boot 3 里已经停了。现在官方推荐 Micrometer Tracing，底层对接 OpenTelemetry，导出到 Zipkin、Jaeger 或 SkyWalking。

三个术语：TraceId（一次请求的唯一 ID）、SpanId（一跳的 ID，一个请求多个 Span 串成树）、ParentId（上一跳是谁）。日志里把 TraceId 打出来，就能把分散在各服务的日志串成一条线。

pom.xml 加 Micrometer Tracing + Zipkin 依赖

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-tracing-bridge-otel</artifactId>
</dependency>
<dependency>
    <groupId>io.opentelemetry</groupId>
    <artifactId>opentelemetry-exporter-zipkin</artifactId>
</dependency>

application.yml：采样率 100%（学习阶段全采，生产别这么干），上报到 Zipkin

management:
  tracing:
    sampling:
      probability: 1.0   # 1.0 = 全部采样；生产建议 0.1 只采 10%，省存储
  zipkin:
    tracing:
      endpoint: http://localhost:9411/api/v2/spans  # Zipkin 地址

logback 里把 TraceId 打进日志（logback-spring.xml 片段）

<pattern>
    %d{HH:mm:ss.SSS} [%thread] %-5level [%X{traceId:-},%X{spanId:-}] %logger{36} - %msg%n
</pattern>
<!-- 日志里就会显示 [abc123,span1]，拿 traceId 去 Zipkin 上一搜就能看到整条链路 -->

论导出到 Zipkin 还是 Jaeger

Micrometer Tracing 是中立的，换后端只改导出器和 endpoint：Zipkin 轻量、上手快，学习首选；Jaeger 是 CNCF 毕业项目，和 Kubernetes、OpenTelemetry 生态结合更紧，大厂用得多。配置上把 endpoint 从 localhost:9411（Zipkin）换成 Jaeger 的 OTLP 地址（默认 4317/4318）即可，具体地址和端口以你所用版本官网为准。

实战：一个慢请求怎么定位

假设用户反馈"下单接口要 8 秒"。没有链路追踪时，你得挨个服务翻日志猜。有了 TraceId：

第一步：拿 TraceId

从网关日志或响应头里找到这次请求的 TraceId。

大白话：拿到这单的"运单号"。

第二步：去 Zipkin 搜

在 Zipkin 控制台输入 TraceId，出来一张调用图：网关 → order-service → user-service → DB，每一跳耗时都标着。

大白话：运单号一查，看到这单在"用户服务"那跳停了 7 秒——问题就在那。

第三步：定位具体慢在哪

点进那个 Span，看是 SQL 慢还是外部调用慢，针对性优化。

解析：链路追踪把"分布式黑盒"变成了"透明的流水线"，哪站慢一目了然。

采样率别开 100% 上生产

学习阶段把 probability 设成 1.0 是为了全看到。生产环境请求量大，100% 采样会把 Zipkin 存储打爆、链路数据自己也拖慢系统。生产一般采 1%~10%，出问题时再临时调高。

← 返回总览 Spring Cloud 微服务总览下一节：消息驱动：Spring Cloud Stream →