微服务之间如何传递 trace

HTTP 场景#

标准做法是放在请求头里，通常是 W3C Trace Context：

• traceparent
• tracestate
• 可选 baggage

流程是：

1. 服务 A 收到请求，创建或继续一个 trace
2. 服务 A 调服务 B 前，把当前 trace context 注入到 HTTP header
3. 服务 B 收到请求后，从 header 提取 trace context
4. 服务 B 基于这个 context 创建自己的 span

这样 A 和 B 的 span 就会落到同一个 trace 里。

所以一般不需要你在接口 JSON 里专门加：

1
{
2
  "traceId": "..."
3
}

除非你有业务上的特殊需求。对 tracing 本身来说，不该这么做，原因是：

• 污染业务接口契约
• 容易和真实 OTel 上下文不一致
• 标准库/中间件已经能自动处理 header

HTTP 里通常像这样：

• 服务端：Extract（从入站 header 恢复上下文）
• 客户端：Inject（把上下文写入出站 header）

Go + OpenTelemetry 的服务端提取示例：

1
// 服务端：从入站请求 header 中提取上下文，再基于它创建 span
2
ctx := otel.GetTextMapPropagator().Extract(
3
  r.Context(),
4
  propagation.HeaderCarrier(r.Header),
5
)
6
ctx, span := tracer.Start(ctx, "handle-request")
7
defer span.End()

客户端注入示例：

1
// 客户端：把当前上下文注入到出站请求 header
2
req := httptest.NewRequest("GET", "http://service-b/api", nil)
3
otel.GetTextMapPropagator().Inject(
4
  ctx,
5
  propagation.HeaderCarrier(req.Header),
6
)

gRPC 与消息队列#

gRPC 也是一样，只是不是 HTTP header，而是 gRPC metadata。原理完全相同：

• client interceptor 注入
• server interceptor 提取

消息队列也类似，通常放在消息 header / metadata 里，不放消息 body。

实务建议#

• HTTP：用 traceparent 这些标准 header
• gRPC：用 metadata
• MQ/Kafka：用 message headers
• 不要把 trace id 做成业务接口字段，除非只是为了调试展示
• 可以额外返回一个 X-Trace-ID 给前端或调用方排查问题，但这只是便于观察，不是主链路传播的标准方式

相关概念见 OpenTelemetry 与链路追踪笔记。