Spring Cloud Sleuth 如何重命名X-B3-TraceId头实现X-Request-Id跨服务链路追踪

完全可以实现和原有Node服务请求标识体系的打通，不需要完全重构Sleuth的原生链路逻辑，通过配置+自定义拦截器的组合方式，即可同时满足出站请求携带指定头、入站请求读取指定头映射为TraceId的需求，具体落地逻辑如下：

核心实现路径 #

• 入站请求读取适配
  编写优先级高于Sleuth原生链路解析逻辑的HTTP入站过滤器：
  • 从入站请求中读取X-Request-Id头的数值
  • 对读取到的值做格式兼容处理（满足Sleuth对TraceId的16/32位十六进制格式要求，比如将Node服务生成的带横杠UUID格式做去横杠转换，避免Sleuth因格式不合法丢弃链路上下文）
  • 将兼容后的数值直接设置为当前链路的TraceId，写入Sleuth的链路上下文；如果头值不存在，则由Sleuth自动生成新的TraceId即可。
• 出站请求头映射适配
  针对所有Java服务的出站HTTP客户端（RestTemplate、WebClient、OpenFeign等）自定义统一拦截逻辑：
  • 拦截Sleuth默认自动写入的X-B3-TraceId、X-B3-SpanId等原生B3协议请求头，直接从出站请求元数据中移除
  • 读取当前链路上下文中的TraceId值，写入X-Request-Id请求头，随请求发送给下游服务。

落地注意事项 #

• 如果使用的是Spring Cloud Sleuth 2.x~3.0.x版本，可通过自定义TraceExtractor、HttpRequestInterceptor的Bean完成上述映射逻辑，不需要修改Sleuth内部的链路存储、Span生成逻辑。
• 如果使用的是2020年后整合Micrometer Tracing的高版本Spring Cloud，可通过自定义PropagationReceiver、PropagationSender的实现替换默认的B3协议传播逻辑，减少重复代码量。
• 不需要完全关闭Sleuth的链路上下文能力，仅做对外请求头的映射转换即可，内部的SpanId生成、采样、日志埋点等能力可以完全保留，不影响Java服务内部的全链路追踪效果。

内容的提问来源于stack exchange，提问作者Pravesh Jain