微服务如何传递分布式跟踪上下文？

跟踪上下文包含traceId、spanId、parentSpanId和采样标记；通过HTTP头或消息属性传递，常用Traceparent、b3等格式；利用OpenTelemetry、Sleuth等工具自动注入提取，结合W3C标准和中间件透传，实现跨服务全链路追踪。

在微服务架构中，一次用户请求往往会经过多个服务节点。为了完整追踪请求路径、分析性能瓶颈或排查问题，需要将跟踪上下文（如 traceId、spanId 等）在服务间传递。实现这一目标的关键在于统一的上下文传播机制。

跟踪上下文包含哪些信息？

分布式跟踪上下文通常包括以下核心字段：

• traceId：标识一次全局请求链路，所有相关服务共享同一个 traceId
• spanId：表示当前操作的唯一标识，每个服务生成自己的 spanId
• parentSpanId：标识调用来源的 span，用于构建调用树结构
• 采样标记（sampling）：指示是否对该请求进行跟踪采样

如何在服务间传递上下文？

主流做法是通过 HTTP 请求头或消息属性传递跟踪信息，确保跨进程传播一致性。

• 在发起远程调用前，从当前上下文中提取跟踪数据，注入到请求头中
• 接收方服务解析请求头，恢复上下文，并创建新的 span 继续跟踪
• 常用标准头部格式包括：Traceparent（W3C Trace Context）、x-request-id、b3（Zipkin/B3 Propagation）等

编程层面如何自动传播？

手动传递上下文容易出错，推荐使用框架或库自动处理。

• 使用 OpenTelemetry 或 Jaeger SDK，它们提供拦截器/中间件自动注入和提取上下文
• 在 Spring Cloud 应用中，Sleuth 可与 Zipkin 集成，自动管理跟踪上下文传播
• gRPC 和 REST 客户端可通过客户端拦截器实现透明传递
• 异步消息场景下，在发送消息前将上下文写入消息头，消费者端读取并恢复

跨语言和服务边界的兼容性

不同技术栈的服务可能使用不同的跟踪实现，需保证协议一致。

• 采用 W3C Trace Context 标准可提升多语言系统的互操作性
• 网关或边车代理（如 Istio）可在入口处生成 traceId 并注入，减轻应用负担
• 确保中间件（如 Kafka、RabbitMQ）支持上下文透传，避免断链

基本上就这些。只要统一规范、借助工具自动传播，就能实现全链路跟踪上下文的无缝传递。关键是标准化头部格式并在整个系统中保持一致。不复杂但容易忽略细节。