在微服务架构中，一个前端请求可能穿越多个服务、访问数据库和消息队列，形成一条复杂的调用链。当某个环节出现延迟或报错，如果没有链路追踪，定位问题无异于大海捞针。分布式链路追踪 就是解决这一痛点的标准方案——它在请求经过的每个节点生成并传递追踪标识（Trace ID），将离散的调用记录串联为完整的调用链。
Spring Cloud 生态中，Zipkin 和 SkyWalking 是两款最主流的实现，一个轻量级、与 Spring 深度集成，另一个功能全面、无侵入性极强。
16.7.1 Zipkin：经典的 HTTP 上报式追踪
Zipkin 由 Twitter 开源，严格遵循 Google Dapper 论文的设计，通过 Span 和 Trace 构建调用树，默认采用 HTTP 协议将采集到的链路数据上报到 Zipkin 服务端。整体架构如下：
┌─────────┐ ┌─────────┐ ┌─────────┐
│ 服务 A │ │ 服务 B │ │ 服务 C │
│ Sleuth │ │ Sleuth │ │ Sleuth │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
└────────────┼────────────┘ ← HTTP 上报
▼
┌──────────────┐
│ Zipkin 服务 │
└──────┬───────┘
▼
┌──────────────┐
│ 存储层/UI │ (内存、MySQL、Elasticsearch)
└──────────────┘1. 快速集成
在 Spring Boot 2.x / 3.x 中，只需引入 spring-cloud-starter-sleuth 和 spring-cloud-sleuth-zipkin：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-sleuth-zipkin</artifactId>
</dependency>配置 application.yml：
spring:
sleuth:
sampler:
probability: 1.0 # 采样率，1.0 表示全量采集（开发/测试环境）
zipkin:
base-url: http://localhost:9411 # Zipkin 服务端地址
sender:
type: web # 默认 HTTP 上报引入依赖后，Sleuth 会自动为你的日志注入 Trace ID 和 Span ID，并在没有任何代码改动的情况下，拦截 RestTemplate、WebClient 以及 Feign 调用，生成追踪数据。如果你使用 RabbitMQ 或 Kafka 异步上报，只需更换 sender 类型，进一步提高上报可靠性。
2. Zipkin 服务端部署
最简单的启动方式是通过 Docker：
docker run -d -p 9411:9411 openzipkin/zipkin生产环境中建议挂载持久化后端（如 Elasticsearch），否则重启后数据丢失：
docker run -d -p 9411:9411 \
-e STORAGE_TYPE=elasticsearch \
-e ES_HOSTS=http://es-node:9200 \
openzipkin/zipkin访问 http://localhost:9411 即可看到直观的调用链依赖图、请求耗时分布和单次请求的完整细节。
3. Zipkin 的优缺点
- 优点：与 Spring Cloud Sleuth 无缝集成，使用简单；UI 直观，支持按服务、耗时过滤；社区成熟，资料丰富。
- 缺点：Sleuth 在 Spring Boot 3.x 中已被 Micrometer Tracing 取代，迁移成本渐增；采样和传输对性能有一定影响；存储和查询能力严重依赖外部存储（ES/MySQL），大规模集群下需精心调优。
注意：Spring Boot 3 + Spring Cloud 2022.0.x 已弃用 Sleuth，改用 Micrometer Tracing 作为统一追踪门面。此时集成 Zipkin 需引入
micrometer-tracing-bridge-brave和zipkin-reporter-brave，原理与配置类似，本文不再细述。
16.7.2 SkyWalking：零侵入的 APM 利器
Apache SkyWalking 是另一款广受欢迎的分布式追踪与性能监控工具。它与 Zipkin 最大的区别在于：代理级字节码增强，真正做到了零代码侵入。
SkyWalking 的架构分为探针（Agent）、后端（OAP Server）和 UI 三部分：
┌──────────────────────────────┐
│ 应用服务 (Java Agent 挂载) │
│ 自动埋点，采集指标和链路数据 │
└──────────────┬───────────────┘
│ gRPC 上报
▼
┌──────────────────────────────┐
│ SkyWalking OAP 服务集群 │
│ (分析、聚合、存储) │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ SkyWalking Rocketbot UI │
│ 拓扑图、追踪、指标仪表盘 │
└──────────────────────────────┘1. 快速上手
下载 SkyWalking APM 发行包，或使用 Docker 一键启动后端：
# 启动 OAP 与 UI
docker run -d --name oap -p 12800:12800 -p 11800:11800 apache/skywalking-oap-server:9.7.0
docker run -d --name ui -p 8080:8080 --link oap:eureka apache/skywalking-ui:9.7.0应用则通过 Java Agent 挂载探针，无需添加任何依赖或修改代码：
java -javaagent:/path/to/skywalking-agent.jar \
-DSW_AGENT_NAME=order-service \
-DSW_AGENT_COLLECTOR_BACKEND_SERVICES=oap-server:11800 \
-jar order-service.jar在启动日志中看到 “SkyWalking agent started successfully”，即表示探针已经注入，你可以在 UI 上看到自动生成的全局拓扑和调用链路。
2. 高级集成能力
SkyWalking 不仅仅追踪 HTTP 调用，还自动涵盖了数据库访问、缓存操作、消息队列消费、线程池提交等几十种常见组件。对于 Spring 生态，它还提供了：
- 与 Spring Cloud Gateway 集成：自动识别网关入口，生成完整的客户端到后端调用链。
- 日志与追踪联动：通过在
logback.xml或log4j2中配置traceId模式，将 SkyWalking 的 Trace ID 打印到业务日志中，实现“代码—链路—日志”无缝关联。 - 熔断、低慢点自动检测：内置告警规则，直接发送到钉钉、Slack、微信等。
如果你仍希望程序内显式创建自定义 Span，可以引入可选的 toolkit：
<dependency>
<groupId>org.apache.skywalking</groupId>
<artifactId>apm-toolkit-trace</artifactId>
</dependency>然后使用 @Trace 注解标记需要追踪的方法。
3. SkyWalking 的优缺点
- 优点：完全无侵入，影响现有代码为零；链路与性能指标一体化展示（QPS、响应时间、错误率）；丰富的中件间自动探测；内置拓扑发现与告警功能。
- 缺点：架构相对重量级，需要独立部署 OAP 集群和存储（Elasticsearch、MySQL 等）；Java Agent 对应用启动速度有一定影响；部分高级功能（如指标 API）学习曲线略陡。
16.7.3 Zipkin vs SkyWalking：如何选择
| 维度 | Zipkin + Sleuth | SkyWalking |
|------|-----------------|------------|
| 侵入性 | 需要引入依赖，但代码几乎无感知 | 完全无侵入，仅需启动参数 |
| 功能丰富度 | 专注于追踪，需结合其他监控 | 追踪、指标、告警一体化 |
| 部署复杂度 | 简单，一个进程即可 | 需要 OAP + 存储 + UI |
| 性能开销 | 采样可控，开销较低 | Agent 字节码增强，有一定开销 |
| 报表与拓扑 | 基础依赖图、耗时分析 | 完整的服务拓扑、慢端点、性能仪表盘 |
| 适用场景 | 中小规模、快速验证、对追踪要求纯粹 | 中大规模生产集群、需要全栈观测 |
并非二选一，部分团队甚至同时部署：用 SkyWalking 做整体性能监控与拓扑发现，用 Zipkin 做特定链路的深度分析。不过大多数情况下，选择其中一个并针对项目规模和运维能力微调即可。
16.7.4 实践建议
- 采样率控制：无论 Zipkin 还是 SkyWalking，生产环境务必设置合理的采样率（如 10%~30%），避免海量数据淹没存储。
- 存储选型：链路数据存储强烈推荐 Elasticsearch，查询性能与扩展性远优于 MySQL；测试环境可以用内存或 H2。
- 日志与链路关联：在日志格式中添加
[%X{traceId},%X{spanId}]（Sleuth）或%tid（SkyWalking），让排查过程效率翻倍。 - 整合告警体系：即使是 Zipkin，也可以结合 Prometheus + Grafana 做异常指标告警；SkyWalking 则可直接使用 Webhook 告警。
- 与微服务网关协同：将 Spring Cloud Gateway 或 Nginx 生成的 Trace ID 透传至后端，确保一次完整的客户端到后端链路可观测。
最终，分布式链路追踪不是为了“收集数据”，而是为了 降低排查问题的认知负荷。当你能够在一个仪表盘上，从用户点击一路追踪到数据库 SQL，再结合日志上下文定位具体异常——微服务的可观测性才真正站稳了脚跟。