一、改造范围与组件覆盖策略
在 Spring Cloud 微服务项目中落地 Sleuth + Zipkin 链路追踪，首先需要梳理每个服务涉及的技术组件，再按组件类型选择对应的 Brave 插件。Brave 库对常见组件的支持情况如下：| 组件 | 支持方式 | 依赖 ||------|---------|------|| SpringMVC / Feign / Logback | 自动配置，引入 Sleuth + Zipkin 依赖即可 | spring-cloud-starter-sleuth + spring-cloud-starter-zipkin || Spring Cloud Gateway | 原生支持（基于 WebFlux instrument/web 模块） | 同上 || MySQL 8 | Brave 插件拦截 SQL | brave-instrumentation-mysql8 || MySQL 6 | Brave 插件 | brave-instrumentation-mysql6 || MongoDB | Brave 插件，通过 CommandListener 拦截 | brave-instrumentation-mongodb || RabbitMQ | Brave 原生支持，通过 spring.sleuth.messaging.rabbit 配置开启 | spring-cloud-starter-stream-rabbit || Redis（Jedis 客户端） | Brave 暂不支持 Jedis，需通过 OpenTracing 桥接 | brave-opentracing + opentracing-redis-jedis3 + opentracing-redis-spring-data || Redis（Lettuce 客户端） | Sleuth instrument/redis 模块原生支持 | 自动配置 |关键决策点 ：Redis 客户端的选择直接影响集成方案。如果项目使用 Jedis，需要引入 OpenTracing 桥接层（brave-opentracing），通过 TracingRedisConnectionFactory 包装原有连接工厂来拦截操作；如果使用 Lettuce，Sleuth 原生支持，无需额外配置。---## 二、MySQL 链路追踪的关键配置MySQL 链路追踪通过 TracingQueryInterceptor 拦截 SQL 请求实现。配置时需要在 JDBC URL 中显式指定三个参数：yamlspring: datasource: url: jdbc:mysql://127.0.0.1:3306/db?queryInterceptors=brave.mysql8.TracingQueryInterceptor&exceptionInterceptors=brave.mysql8.TracingExceptionInterceptor&zipkinServiceName=mysql-service-name- queryInterceptors：指定 SQL 查询拦截器，用于记录每次 SQL 执行的 Span- exceptionInterceptors：指定异常拦截器，用于记录 SQL 执行异常- zipkinServiceName：该 MySQL 实例在 Zipkin UI 中显示的服务名，建议按业务命名（如 mall-db、shadow-db），方便区分主库和影子库注意需要根据 MySQL 驱动版本选择对应插件：MySQL 8 用 brave-instrumentation-mysql8，MySQL 6 用 brave-instrumentation-mysql6。---## 三、Redis（Jedis）链路追踪的桥接方案由于 Brave 不直接支持 Jedis，需要通过 OpenTracing 标准桥接：1. 引入 brave-opentracing（Brave 对 OpenTracing 的实现）2. 引入 opentracing-redis-jedis3 和 opentracing-redis-spring-data3. 创建配置类，用 TracingRedisConnectionFactory 包装原有的 JedisConnectionFactory，并通过 TracingConfiguration 设置扩展 Tag（如 Redis 服务器地址）这里的设计模式是：OpenTracing 是通用标准（类似 JDBC），Brave 是其具体实现（类似 MySQL Driver），opentracing-redis-jedis3 是针对 Jedis 的 OpenTracing 适配层。三者组合才能将 Redis 操作的链路数据写入 Zipkin。---## 四、MongoDB 链路追踪的配置方式MongoDB 通过 MongoDBTracing.create(Tracing.current()).commandListener() 创建 CommandListener，再注入到 MongoClientSettings 中。需要创建自定义配置类，手动构建 MongoClient Bean 并注册监听器，替换 Spring Boot 自动配置的默认客户端。---## 五、RabbitMQ 链路追踪的配置RabbitMQ 链路追踪通过 Spring Cloud Sleuth 的 messaging 模块实现，只需在配置文件中开启：yamlspring: sleuth: messaging: rabbit: enabled: true remote-service-name: rabbitmq # Zipkin 中显示的 RabbitMQ 服务名生产者和消费者均需要添加此配置，Sleuth 会自动在消息头中注入和提取 Trace 上下文，实现跨消息队列的链路追踪。---## 六、采样率配置所有服务的 Sleuth 采样配置需要统一设置：yamlspring: sleuth: sampler: probability: 1.0 # 采样率，1.0 表示 100% 采样，生产环境建议降低（如 0.1） rate: 10000 # 每秒最多采集 10000 条 Trace，防止高并发下采集量过大生产环境中，100% 采样会带来额外的性能开销和存储压力，建议根据实际 TPS 调整采样率。压测期间可临时调高采样率以获取更完整的链路数据。---## 七、生产环境架构：Kafka 削峰 + ES 存储直接将链路数据通过 HTTP 推送到 Zipkin Server 在高并发下存在两个风险：链路数据采集影响业务性能；Zipkin Server 成为单点瓶颈。生产环境推荐架构：各服务 → Kafka → Zipkin Server → ElasticSearch → Zipkin UI / Kibana 各服务将链路日志推送到 Kafka（通过 spring.zipkin.sender.type: kafka 配置），Zipkin Server 监听 Kafka Topic，拉取消息后写入 ElasticSearch。Kafka 在这里承担两个作用：削峰（高并发下缓冲链路数据，避免直接压垮 Zipkin Server）和解耦（各服务不直接依赖 Zipkin Server 的可用性）。服务端配置示例：yamlspring: zipkin: sender: type: kafka kafka: topic: zipkin kafka: bootstrap-servers: kafka:9092Zipkin Server 启动时通过环境变量指定 Kafka 地址和 ES 存储：bashdocker run -d \ -e KAFKA_BOOTSTRAP_SERVERS=192.168.3.58:9092 \ -e STORAGE_TYPE=elasticsearch \ -e ES_HOSTS=http://192.168.3.58:9200 \ -p 9411:9411 openzipkin/zipkin---## 八、多服务改造的依赖组合规律不同服务根据其使用的组件，引入对应的依赖组合：- 纯 Gateway 服务 ：Sleuth + Zipkin（原生支持 WebFlux）- 认证服务（Redis + MySQL） ：Sleuth + Zipkin + brave-instrumentation-mysql8（Redis 使用 Lettuce 时无需额外依赖）- 业务服务（MySQL + Redis/Jedis + MongoDB） ：Sleuth + Zipkin + brave-instrumentation-mysql8 + brave-instrumentation-mongodb + brave-opentracing + opentracing-redis-jedis3 + opentracing-redis-spring-data改造完成后，在 Zipkin UI 中可以看到每个请求经过的完整调用链，包括各服务间调用耗时、数据库查询耗时、缓存访问耗时，以及服务间的拓扑依赖关系图。Sleuth+Zipkin 链路追踪落地实战：五类组件的集成方案与生产环境架构设计