要实现spring cloud sleuth的链路追踪，需按以下步骤操作：1. 引入依赖开启基础追踪能力；2. 查看日志中的traceid和spanid用于识别请求链路；3. 实现跨服务链路追踪确保上下文自动透传；4. 可选配合zipkin进行可视化展示。通过这些步骤可提升微服务架构下的问题排查与性能优化能力。
在微服务架构下，一个请求往往会经过多个服务的协作处理。要排查问题、优化性能，链路追踪就成了必不可少的能力。Spring Cloud Sleuth 是 Spring 提供的一套轻量级分布式链路追踪方案，它可以自动为每个请求生成唯一标识，并记录调用链中的各个阶段。下面我们就来看看如何一步步实现它。
1. 引入依赖，开启基础追踪能力
要在项目中使用 Sleuth，首先得引入相关依赖。如果你使用的是 Spring Boot 2.6 或更高版本，可以直接添加如下依赖：
org.springframework.cloud spring-cloud-starter-sleuth
添加完成后，Sleuth 就会自动生效了。你不需要额外写任何代码，它会在日志中输出 traceId 和 spanId，帮助你识别每一次请求的完整链路。
注意：Sleuth 默认不会把数据上报到外部系统，只负责生成和传递链路信息。如果想做可视化展示，还需要配合 Zipkin 等工具。
2. 查看日志中的 traceId 和 spanId
Sleuth 的核心功能之一就是在每次请求开始时生成一个唯一的 traceId，并在每个操作单元（比如一次 HTTP 请求或方法调用）中生成一个 spanId。这些信息会自动打印在你的日志里。
比如你在控制台看到这样的日志：
[order-service,8e95b7a4d0f5c3a0,8e95b7a4d0f5c3a0,true] ...
这里的字段含义分别是：
- 应用名称（order-service）
- traceId（8e95b7a...）
- spanId（同样值，表示这是第一个 span）
- 是否导出（true 表示该 trace 会被上报）
这样你就可以通过日志来追踪整个调用链了。如果你使用 ELK 或者类似的日志分析系统，可以基于 traceId 把所有相关日志聚合在一起。
3. 实现跨服务链路追踪
Sleuth 的一大优势是能自动将链路信息透传到下游服务。也就是说，当你从 A 服务调用 B 服务时，Sleuth 会自动把当前的 traceId 和 spanId 放到 HTTP 请求头中，B 服务接收到后就能继续沿用这条链路。
目前支持自动注入的场景包括：
- 使用 RestTemplate 发起的请求
- Feign 客户端调用
- Spring WebFlux 的 WebClient
- 消息中间件如 RabbitMQ、Kafka（需要配合 Sleuth Stream）
如果你自己封装了远程调用逻辑，就需要手动设置请求头，例如：
HttpHeaders headers = new HttpHeaders(); sleuthTracer.getCurrentSpan().context().forEach((key, value) -> headers.set(key, value));
这样才能保证链路不中断。
4. 配合 Zipkin 做可视化展示（可选）
虽然 Sleuth 能提供完整的链路数据，但直接看日志还是不够直观。你可以把它和 Zipkin 结合起来，实现图形化展示。
步骤大致如下：
- 启动 Zipkin Server（可以用官方 Docker 镜像快速部署）
- 添加 Zipkin 依赖：
org.springframework.cloud spring-cloud-sleuth-zipkin
- 在配置文件中指定 Zipkin 地址：
spring:
zipkin:
base-url: http://localhost:9411这样，Sleuth 会自动将 span 数据发送给 Zipkin，你就可以通过 Zipkin 的 Web 页面查看请求的完整调用路径、耗时分布等信息。
基本上就这些。Spring Cloud Sleuth 的使用并不复杂，但确实能大大提升微服务下的可观测性。只要注意日志收集方式和上下游服务之间的上下文传递，就能轻松实现全链路追踪。
