SpringCloud链路追踪配置全攻略

小伙伴们有没有觉得学习文章很有意思？有意思就对了！今天就给大家带来《Spring Cloud链路追踪完整配置教程》，以下内容将会涉及到，若是在学习中对其中部分知识点有疑问，或许看了本文就能帮到你！

要实现Spring Cloud微服务的链路追踪，核心是引入Sleuth和Zipkin。1. 在每个微服务中添加Sleuth和Zipkin依赖；2. 配置application.yml，设置服务名、Zipkin地址、采样率等关键参数；3. Sleuth自动埋点并传播Trace ID和Span ID，覆盖HTTP、消息队列等常见组件；4. 对异步任务或非Spring组件手动包装线程池或使用Tracer API管理Span；5. 选择数据存储方案时，开发环境可用内存，生产环境推荐Elasticsearch或Cassandra；6. 采样策略可采用固定概率、基于规则、错误全采样等方式，并通过异步发送、动态调整采样率优化性能。整个过程确保链路ID正确传递、追踪数据高效采集与分析。

在Spring Cloud微服务架构里，要实现完整的链路追踪，核心就是让每个请求在穿越不同服务时，能带上一个唯一的标识符（Trace ID）以及当前操作的上下文（Span ID）。这套机制能让你清晰地看到一个用户请求从前端到后端，再到各个微服务，乃至数据库的完整调用路径和耗时，是排查分布式系统问题、优化性能的“透视眼”。我们通常会借助Spring Cloud Sleuth来自动完成大部分的埋点工作，再将这些追踪数据发送给一个收集器和可视化工具，比如Zipkin。

解决方案

要构建一套完整的Spring Cloud微服务链路追踪方案，我们主要围绕Sleuth和Zipkin进行配置。

首先，在每个需要追踪的微服务中，引入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或application.properties中进行配置。

spring:
  application:
    name: your-service-name # 非常重要，Zipkin会用这个名字来标识服务
  zipkin:
    base-url: http://localhost:9411 # Zipkin Server的地址
    sender:
      type: web # 默认通过HTTP发送，也可以配置成kafka或rabbit
  sleuth:
    sampler:
      probability: 1.0 # 采样率，1.0表示100%采样，生产环境建议调低
    # trace-id-128: true # 启用128位Trace ID，默认为false，即64位
    # propagation-keys: custom-header # 如果有自定义的上下文传播需求，可以在这里添加

这个配置里，spring.application.name至关重要，它会作为服务名在Zipkin界面中展示。spring.zipkin.base-url指向你部署的Zipkin服务器地址。spring.sleuth.sampler.probability是采样率，开发环境可以设为1.0，生产环境为了降低性能开销和存储压力，通常会设置一个较低的值，比如0.1（10%）。

当这些配置完成后，Sleuth会自动对Spring MVC控制器、RestTemplate、Feign客户端、Spring Cloud Gateway、Spring Cloud Stream等组件进行自动化埋点。这意味着你的HTTP请求、消息队列消息、RPC调用等都会被Sleuth自动拦截并注入Trace ID和Span ID，并在请求结束后将追踪数据发送到Zipkin。

如果你的服务间通信还涉及到其他非Spring组件，或者有自定义的线程池、异步任务，Sleuth的自动传播可能无法覆盖，这时就需要手动介入，利用Sleuth提供的API来确保上下文的传递。但对于大部分基于Spring Cloud构建的微服务，上述配置已经能覆盖绝大部分场景了。

如何选择合适的链路追踪工具与数据存储方案？

选择链路追踪工具，其实更多是选择一套生态和理念。Spring Cloud Sleuth在Spring生态里几乎是“御用”的存在，因为它深度集成Spring的各种组件，开箱即用，配置起来非常顺手。它的底层是基于Brave库，这个库兼容OpenTracing和OpenCensus（现在都合并到OpenTelemetry了）。所以，如果你的技术栈以Java和Spring为主，Sleuth无疑是上手最快的选择。它能让你在几乎不修改业务代码的前提下，就具备链路追踪能力。

但如果你的微服务架构是多语言混合的，比如有Java、Python、Go等服务，那么OpenTelemetry（简称OTel）会是更长远、更灵活的选择。OTel是一个CNCF项目，旨在提供一套标准的API、SDK和数据格式，用于收集遥测数据（包括追踪、指标、日志）。它的优势在于厂商无关性，你收集到的数据可以发送给Zipkin、Jaeger、Datadog、New Relic等任何支持OTel协议的后端。虽然在Spring Boot应用中引入OTel需要一些额外的配置（比如使用OpenTelemetry Spring Boot Starter），但从长远来看，它的通用性和未来发展潜力更大。

至于数据存储方案，这取决于你的规模和需求。

• Zipkin自带的内存存储： 适合开发、测试环境，或者小型项目。部署简单，数据不持久化，重启即丢失。
• Zipkin + Elasticsearch/Cassandra： 这是生产环境常用的组合。Zipkin支持将追踪数据存储到Elasticsearch或Cassandra。Elasticsearch的查询能力强大，适合快速检索和分析；Cassandra则适合海量数据的写入和存储。选择哪个，看你团队对哪种数据库更熟悉，以及数据量级。Elasticsearch在查询灵活性上通常更胜一筹。
• Jaeger + Elasticsearch/Cassandra/Kafka： 如果你选择了Jaeger作为追踪后端（它也支持OTel），它的存储选项和Zipkin类似，也支持Elasticsearch和Cassandra。Jaeger在UI上可能比Zipkin更侧重于分布式系统的根因分析。

我个人的看法是，对于纯Spring Cloud项目，Sleuth + Zipkin的组合是最佳起点，简单高效。当业务规模扩大，或者需要支持多语言时，再考虑迁移到OpenTelemetry + Jaeger/Elasticsearch的方案。数据存储方面，Elasticsearch几乎是标配，它能让你对追踪数据进行更复杂的聚合和分析。

在复杂微服务架构中，如何确保链路ID的正确传递与保持？

在复杂微服务架构里，确保链路ID的正确传递与保持，是实现完整链路追踪的关键挑战。Sleuth已经为我们做了大量工作，但总有些“角落”需要我们特别留意。

Sleuth的自动化能力非常强大，它通过AOP（面向切面编程）和各种Spring组件的集成点，在请求进入和离开服务时自动注入和提取Trace ID和Span ID。例如，当你使用RestTemplate或FeignClient发起HTTP调用时，Sleuth会自动在HTTP请求头中加入X-B3-TraceId、X-B3-SpanId等B3协议相关的头信息。同样，Spring Cloud Stream在发送和接收消息时，也会将这些上下文信息放入消息头。

然而，自动化并非万能。最常见的上下文丢失场景发生在：

1. 自定义线程池/异步任务： 如果你在服务内部使用了ExecutorService、CompletableFuture，或者自己创建了新的线程来执行异步任务，而没有正确地传递Sleuth的上下文，那么这些新线程中产生的日志和操作将无法关联到原始的链路。这是因为Sleuth的上下文是基于ThreadLocal存储的，新线程不会自动继承父线程的ThreadLocal。
2. 非Spring管理组件的集成： 比如你直接使用了Netty、或者一些自定义的RPC框架，它们可能不被Sleuth默认的AOP切面所覆盖。

为了解决这些问题，我们需要：

• 包装异步执行器： Sleuth提供了工具类来包装Executor、ExecutorService、Runnable和Callable，确保链路上下文的传递。例如，你可以使用Tracing.currentTracer().currentSpan().wrap(Runnable)或TraceRunnable、TraceCallable。更推荐的做法是，如果你自定义了ExecutorService，可以通过Sleuth提供的LazyTraceExecutor来包装它，或者确保你的Spring Boot版本足够新，它可能会自动为你处理一些常见的线程池。

  // 示例：包装自定义线程池
  @Configuration
  public class ThreadPoolConfig {
      @Bean
      public ExecutorService myExecutorService(BeanFactory beanFactory) {
          ThreadPoolExecutor executor = new ThreadPoolExecutor(
              2, 5, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<>(100)
          );
          // 使用LazyTraceExecutor包装，确保Sleuth上下文传递
          return new LazyTraceExecutor(beanFactory, executor);
      }
  }

• 手动管理Span： 对于那些Sleuth无法自动处理的边界情况，你可以通过Sleuth提供的Tracer API手动创建和管理Span。这通常涉及到获取当前Span、创建新的子Span、在Span中添加标签（tags）、以及关闭Span。

  // 示例：手动创建和管理Span
  @Autowired
  private Tracer tracer;
  
  public void doSomeCustomOperation() {
      Span newSpan = tracer.nextSpan().name("custom-operation").start();
      try (Tracer.SpanInScope ws = tracer.withSpanInScope(newSpan)) {
          // 在这里执行你的业务逻辑
          newSpan.tag("result", "success");
      } catch (Exception e) {
          newSpan.error(e);
          throw e;
      } finally {
          newSpan.end();
      }
  }

  这种手动方式虽然增加了代码量，但能确保在任何复杂场景下链路的完整性。

• 统一网关： 在API Gateway层（如Spring Cloud Gateway或Zuul）配置链路追踪，可以作为所有外部请求的入口点，确保Trace ID在进入微服务集群前就被生成并传递下去。Gateway本身也会被Sleuth自动追踪。

总而言之，大部分情况Sleuth能搞定，但对于异步任务和非Spring托管的组件，需要我们介入，通过包装或手动API来“扶持”上下文的传递。这是一个经验活，通常在测试阶段就能发现哪些地方的链路“断”了。

链路追踪数据采样策略与性能优化有哪些考量？

链路追踪虽然功能强大，但它不是没有代价的。每一次的追踪数据收集、发送和存储都会带来额外的性能开销。因此，在生产环境中，合理的数据采样策略和性能优化就显得尤为重要。

采样策略：

1. 固定概率采样（spring.sleuth.sampler.probability）： 这是最常用也最简单的策略。你设置一个0到1之间的浮点数，比如0.01，表示只有1%的请求会被追踪。优点是简单易懂，缺点是对所有请求一视同仁，可能导致某些重要的、但发生频率低的请求（如错误请求）被漏掉。
2. 基于规则的采样： 更高级的采样策略，比如根据HTTP路径、请求头、用户ID等条件来决定是否采样。例如，只追踪对/api/v1/critical-path的请求，或者只追踪包含特定用户ID的请求。Sleuth本身提供了PercentageBasedSampler和RateLimitingSampler，你也可以实现Sampler接口来定制自己的采样逻辑。
3. 错误请求全采样： 这是一种非常实用的策略。无论整体采样率多低，只要请求最终导致了错误（HTTP 5xx、异常），就应该被全量追踪。这样可以确保在问题发生时，你有足够的上下文来分析。这通常需要结合自定义的Sleuth配置或Spring AOP来实现。
4. 动态采样： 随着系统负载的变化，动态调整采样率。例如，在系统负载高时降低采样率，在负载低时提高采样率。这通常需要一个外部的控制平面来协调。

性能优化考量：

1. 降低采样率： 这是最直接有效的优化手段。生产环境通常将采样率设置为0.01到0.1之间，甚至更低。这能显著减少发送到Zipkin的数据量，从而降低网络IO和Zipkin服务器的存储压力。
2. 异步发送数据： Sleuth默认通过HTTP同步发送追踪数据到Zipkin。在高并发场景下，这可能会成为瓶颈。将spring.zipkin.sender.type配置为kafka或rabbit，让追踪数据通过消息队列异步发送，可以大大降低对业务请求响应时间的影响。服务只需要将数据发送到消息队列，然后由Zipkin消费者从队列中拉取，这解耦了业务服务和Zipkin服务器的直接依赖。

   spring:
     zipkin:
       sender:
         type: kafka # 或 rabbit
     sleuth:
       messaging:
         kafka:
           enabled: true # 如果使用Kafka

3. Zipkin服务器性能： Zipkin服务器本身也需要足够的资源来处理接收到的追踪数据。如果数据量大，需要为Zipkin分配足够的CPU、内存，并选择合适的后端存储（如Elasticsearch集群）。Zipkin的存储后端性能直接决定了你能够存储和查询多少追踪数据。
4. 避免过度标记： 在Span中添加过多的自定义标签（tags）会增加数据量。虽然标签对于过滤和分析很有用，但要避免添加冗余或不必要的标签。只添加那些对问题诊断和性能分析真正有价值的信息。
5. 链路追踪与日志集成： 确保你的日志系统能输出Trace ID和Span ID。这样，即使某个请求没有被全量追踪，你也可以通过日志中的Trace ID来关联不同服务间的日志，进行初步的问题定位。常见的日志框架（如Logback、Log4j2）通过MDC（Mapped Diagnostic Context）可以轻松集成Sleuth的Trace ID和Span ID。

我的经验是，起步阶段可以先用较低的采样率，并使用异步发送。然后，根据实际的系统负载、Zipkin服务器的资源消耗以及运维团队对可观测性的需求，逐步调整采样率。在关键业务路径上，可能需要更高的采样率，甚至全量追踪，而对于不那么重要的后台任务，可以考虑更低的采样率。性能和可观测性之间，总是一个需要权衡的艺术。

到这里，我们也就讲完了《SpringCloud链路追踪配置全攻略》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！