链路追踪：Micrometer Tracing 与 Zipkin 接入思路
一次下单请求会穿过网关、订单、库存、账户等多个服务，每个服务都打印自己的日志。出问题时，要在这堆日志里把"同一次请求"的碎片拼起来，靠的是链路追踪：为请求生成全局唯一的 traceId，每经过一个服务再细分 span，再把这些数据收集起来还原整条调用链。本章介绍当前官方技术栈（Micrometer Tracing + Zipkin）与接入思路。
先厘清组件关系
旧方案 Sleuth 已停止演进，从 Spring Cloud 2021.0.2 起官方改为 Micrometer Tracing（micrometer 生态）统一埋点，通过桥接实现与具体追踪系统解耦：Brave 桥接（Zipkin 系）或 OpenTelemetry 桥接。本教程基于第 01 章版本锚点（Spring Cloud 2025.0.x），使用 Brave + Zipkin 组合。链路数据分为三层：埋点（应用内产生 span）、上报（把 span 发给收集端）、展示（Zipkin UI 聚合与检索）。Micrometer Tracing 负责前两层中的应用侧部分。
接入步骤总览
按四步接入，每步都可在本地验证：
- 第一步，准备 Zipkin 服务端：从官方发布页下载 zipkin 的可执行 jar（或用官方镜像），java -jar zipkin.jar 启动，默认端口 9411，浏览器打开即 UI；
- 第二步，在工程中加入 Brave 桥接依赖（版本由 Boot/Cloud 依赖管理统一定制）；
- 第三步，配置采样率与 Zipkin 上报地址；
- 第四步，发起一次跨服务调用，在 Zipkin UI 中检索 traceId 观察链路。
依赖与配置示例
需要接入追踪的每个服务（网关、order-service、user-service 等）都加入同一桥接：
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-tracing-bridge-brave</artifactId>
</dependency>
management:
tracing:
sampling:
probability: 1.0 # 采样率：1.0 全量，生产可降到 0.1 或按流量设计
zipkin:
tracing:
endpoint: http://localhost:9411/api/v2/spans
采样率是成本与可观测性的平衡点：全量上报在低流量环境没问题，高流量系统通常只采样一部分，并用"错误请求必采样"之类的策略保证故障现场不丢，具体采样策略以官方文档为准。
埋点与传播是自动的
接入后，Spring 管理的 HTTP 组件会自动完成两件事：生成/续传 traceId 与 spanId；通过请求头（Brave 使用 b3 系列头，OTel 使用 traceparent）在服务间传播上下文。OpenFeign、RestTemplate、Spring Cloud Gateway 的转发都自动带上了追踪上下文，因此只要所有服务都接同一桥接，一条跨服务链路会自动串起来，这也是链路追踪"接入成本低"的原因。自定义的 HTTP 客户端或异步线程如果不走 Spring 管理的组件，需要手动传播上下文（第 22 章展开）。
日志关联：让日志也带上 traceId
链路数据要与日志对上才有排障价值。Micrometer Tracing 会把 traceId/spanId 写入日志的 MDC，把日志格式加上对应占位符（形如 [%X{traceId:-},%X{spanId:-}]），就能按 traceId 在日志平台聚合一次请求的全部分散日志；具体 MDC key 与配置以当前版本文档为准。日志聚合 + 链路 UI 双管齐下，是微服务排障的标准姿势。
在 Zipkin 里看什么
Zipkin UI 的主要入口是搜索页：按服务名、耗时、标签检索 trace。点击一条 trace 可以看到时间轴：每个 span 一行，标注了服务、操作与耗时，慢在哪一段一目了然；依赖关系页还能画出服务间的调用拓扑。验证接入是否成功的最快方法是：跑一次 order-service 调 user-service 的请求，回 UI 检索该 trace，确认两个服务、两个 span 都在。
常见坑
一是只有部分服务接入，链路在未接入处断裂，表现为 traceId 变化或 span 缺失——接入要覆盖网关与所有参与调用的服务；二是采样率不一致导致上下游一个采样一个不采，trace 不完整；三是上报地址不通（9411 被防火墙拦）或上报积压影响业务线程，生产上要给上报链路留足容量。
小结
链路追踪 = 统一埋点（Micrometer Tracing）+ 上下文传播（自动 Header 传递）+ 收集展示（Zipkin）。接入思路清晰、成本低，关键在于覆盖面与采样策略。它解决"请求从哪来到哪去"，分布式事务则解决"跨服务数据一致"，下一章进入 Seata。