---
tags: [microservice, distributed-tracing, opentelemetry, jaeger, skywalking]
create time: 2026-05-05 14:30
---

# 分布式链路追踪

## 概述

单个服务的日志只能告诉你局部信息。分布式链路追踪将一次请求跨越多个服务的完整调用链串起来，形成全局视图。

> [!question] 定位问题的困难
> 用户反映下单慢，你的系统由订单、支付、库存、会员 4 个服务串联而成。没有工具的情况下，你要怎么知道是哪个服务拖慢了整体响应时间？

## 核心概念

```mermaid
flowchart TB
    Req["请求 trace_id=abc123"] --> Span1["Span #1 API Gateway 5ms"]
    Span1 --> Span2["Span #2 Order Service 70ms"]
    Span1 --> Span3["Span #3 User Service 15ms"]
    Span2 --> Span4["Span #4 Inventory DB Query 60ms"]

    style Span2 fill:#ff9999
    style Span4 fill:#ffcc99
```

| 概念 | 说明 |
|------|------|
| **Trace** | 一次完整请求的调用链，由一个唯一的 `trace_id` 标识 |
| **Span** | 链路中的一个执行片段（如一次 HTTP 调用、一次 SQL 查询），有独立的 `span_id` |
| **Parent-Child** | Span 之间通过 `parent_span_id` 建立父子关系，形成树状结构 |
| **Context Propagation** | 通过 Header 传递 `trace_id`/`span_id`，贯穿整条链路 |
| **Sampling** | 不是每条请求都采样，按比例或策略选择，降低存储开销 |

### Trace/Span 数据结构

```json
{
  "traceId": "abc123def456...",
  "spans": [
    {
      "spanId": "span-001",
      "parentId": null,
      "operationName": "POST /orders",
      "startTime": "2026-05-05T10:00:00.000Z",
      "durationMs": 120,
      "tags": {
        "http.method": "POST",
        "http.url": "/api/orders",
        "http.status_code": 200
      },
      "logs": [
        {
          "timestamp": "2026-05-05T10:00:00.050Z",
          "fields": [{"key": "event", "value": "order.created"}]
        }
      ]
    },
    {
      "spanId": "span-002",
      "parentId": "span-001",
      "operationName": "GetUserById (gRPC)",
      "startTime": "2026-05-05T10:00:00.010Z",
      "durationMs": 15,
      "tags": {
        "rpc.system": "grpc",
        "rpc.service": "UserService",
        "rpc.method": "GetUser"
      }
    }
  ]
}
```

## 上下文传播 (Context Propagation)

`trace_id` 如何从上游服务传递到下游？核心原则：**调用者创建上下文 → 被调者提取上下文 → 在自身链路中继续使用并透传到更下游**。

### W3C Trace Context 标准

这是业界事实标准（[W3C Recommendation](https://www.w3.org/TR/trace-context/)），被 OpenTelemetry、Jaeger、SkyWalking 全部支持。

```json
// HTTP Header 中实际传递的字段
{
  "traceparent": "00-abc123def456...-789ghi012jkl-01",
  "tracestate":   "congo=t61rcWkgMzE,vendor=value"
}
```

| 字段 | 格式 | 说明 |
|------|------|------|
| `version` | 2 字符十六进制 | 版本号，目前固定 `00` |
| `trace_id` | 32 字符十六进制 | 128-bit 全局唯一标识，建议用 ULID / Snowflake 生成 |
| `span_id` | 16 字符十六进制 | 64-bit 本段 span 的唯一标识 |
| `flags` | 2 字符十六进制 | 目前仅 `01` 表示已采样 |

**`tracestate`**：供厂商扩展使用，例如用于在多家 tracing 系统间同步采样决策或路由信息。多个厂商以逗号分隔。

### HTTP 场景：中间件自动注入与提取

```go
// OpenTelemetry SDK 自动处理 context 注入和提取
func Middleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // ① 从入站请求提取 trace context（如果请求中没有 traceparent，会生成新的 trace）
        ctx := propagator.Extract(r.Context(), headerReader{r.Header})

        // ② 在当前服务内创建新 span
        ctx, span := tracer.Start(ctx, "handleOrder")
        defer span.End()

        // ③ 将 trace context 注入到出站请求 —— 关键一步
        r = r.WithContext(ctx)
        propagator.Inject(ctx, headerWriter{r.Header})

        next.ServeHTTP(w, r)
    })
}
```

```mermaid
sequenceDiagram
    participant C as Client
    participant A as Service A
    participant B as Service B

    C->>A: GET /api/order\ntraceparent=00-abc...
    Note over A: Extract create Span A
    A->>B: POST /inventory\nInject traceparent
    Note over B: Extract create Span B
    B-->>A: Response
    A-->>C: Response
```

### gRPC 场景：Metadata 透传

gRPC 基于 HTTP/2，传播方式类似，但使用的是 **gRPC Metadata** 而非 HTTP Headers（gRPC 库内部会将 metadata 转为 HTTP Header）。

```go
// === 调用方：自动从 context 提取 trace 信息写入 metadata ===
ctx, span := tracer.Start(parentCtx, "callUserService")
defer span.End()

// otelgrpc.Interceptor 会自动完成 Inject，无需手动处理
conn, err := grpc.DialContext(ctx, "user-service:9090",
    grpc.WithTransportCredentials(insecure.NewCredentials()),
    grpc.WithStatsHandler(otelgrpc.NewClientHandler()), // 自动注入
)
client := userpb.NewUserServiceClient(conn)
resp, err := client.GetUser(ctx, &userpb.GetRequest{Id: "123"})

// === 被调方：拦截器自动完成 Extract ===
server := pb.NewUserServiceServerImpl()
grpc.NewServer(
    grpc.StatsHandler(otelgrpc.NewServerHandler()), // 自动提取
).Serve(listener)
```

> [!note] 为什么不直接用 HTTP Headers？
> gRPC 对 metadata key 有严格的大小写规范——全部小写且不支持连字符。因此 `traceparent` 这样的 Header 名无法直接映射到 gRPC Metadata，各 tracing SDK 内部做了适配层，开发者只需关注 `context`，不需要手动操作 metadata。

### MQ 场景：消息属性透传

消息队列没有标准化的上下文传播协议，需要**在消息属性中手动携带 trace 信息**。OpenTelemetry 提供了标准的 attribute 命名约定。

```go
// === RocketMQ 生产者：注入 trace context ===
msg := rocketmq.NewMessage("order-created", payload)

// 标准 OTel 属性名
msg.WithProperty(semconv.RPCSystemKey, "rocketmq")
msg.WithProperty(semconv.MessagingSystemKey, "rocketmq")
msg.WithProperty(semconv.HTTPFlavorKey, "1.1")

// 手动注入 trace_id 和 span_id
if sc, ok := trace.SpanFromContext(ctx).SpanContext(); ok && sc.IsValid() {
    msg.WithProperty("traceparent", fmt.Sprintf(
        "00-%s-%s-01", sc.TraceID().String(), sc.SpanID().String(),
    ))
}

producer.SendSync(msg)

// === RocketMQ 消费者：恢复 trace context ===
consumer.Receive(func(ctx context.Context, messages ...*rocketmq.Message) error {
    for _, msg := range messages {
        // 从消息属性中提取 traceparent
        tp := msg.GetProperty("traceparent")
        if tp != "" {
            ctx = propagator.Extract(ctx, textmap.Reader(func(k string) string {
                return tp // 模拟 header reader
            }))
        } else {
            // 补偿策略：如果上游没带 trace 信息，作为新 trace 起点
            ctx = trace.ContextWithRemoteSpanContext(ctx,
                trace.NewSpanContext(trace.SpanContextConfig{
                    TraceID: generateFallbackTraceID(),
                    Remote:  true,
                }),
            )
        }

        _, span := tracer.Start(ctx, "processOrderCreated",
            trace.WithSpanKind(trace.SpanKindConsumer))
        span.SetAttributes(
            semconv.MessagingSystemKey, "rocketmq",
            semconv.MessagingDestinationKey, msg.Topic,
            semconv.MessagingMessageIDKey, msg.MsgID,
        )

        doProcess(ctx, msg.Body)
        span.End()
    }
    return nil
}, rocketmq.ConsumeFunc())
```

> [!tip] 补偿策略：异步解耦时可能出现"上游未传 trace"的情况
> 
> 当 MQ 消息来自非追踪系统或上游漏传了 trace_id 时，消费者应作为 **新 Trace 的根 Span** 启动，而不是丢弃消息。同时通过属性标记 `messaging.message.is_remote=true` 标明这是一个远程关联点。

### 同步并发：Goroutine 间的 Context 传播

Go 的 `context.Context` 是协程安全的，子 Goroutine 直接使用父级 context 即可自动继承 trace。关键在于**不能丢失 context 引用**。

```go
func handleOrder(ctx context.Context, w http.ResponseWriter, r *http.Request) {
    _, span := tracer.Start(ctx, "handleOrder")
    defer span.End()

    // ✅ 正确：直接传入同一 context，子 goroutine 自动继承 trace
    var wg sync.WaitGroup
    for _, item := range order.Items {
        wg.Add(1)
        go func(item OrderItem) {
            defer wg.Done()
            processItem(ctx, item) // ctx 携带 trace context
        }(item)
    }
    wg.Wait()

    // ❌ 错误：创建了无父 context 的新 context，trace 断裂
    // go func() {
    //     _, childSpan := tracer.Start(context.Background(), "processItem")
    //     ...
    // }()
}
```

```mermaid
flowchart TB
    subgraph Main["主 Goroutine"]
        S0["Span #1 handleOrder"]
        S0 --> S1["Span #2 proc Item A"]
        S0 --> S2["Span #3 proc Item B"]
        S0 --> S3["Span #4 proc Item C"]
    end

    style S0 fill:#bbddff
    style S1 fill:#ccf2ff
    style S2 fill:#ccf2ff
    style S3 fill:#ccf2ff
```

> [!warning] 常见陷阱
> 
> 1. **忘记传入 context**：用 `context.Background()` 或 `context.TODO()` 启动了 Goroutine，导致 trace 断裂。
> 2. **超时覆盖**：子 Goroutine 中设置了独立的 `context.WithTimeout` 但没有保留父级的 deadline，导致整体超时无效。
> 3. **recover 后丢失 context**：`defer recover()` 中如果有错误上报逻辑，仍需持有原始 context。

### 额外负载：Baggage 机制

除了 trace/span 信息，有时需要在链路间传递**业务标签**（如用户 ID、租户 ID、A/B 测试分组），这通过 **Baggage** 实现。

```go
// === 入口服务：设置 baggage ===
baggage, _ := baggage.New(baggage.Pair("user.id", "u-12345"),
                           baggage.Pair("tenant", "acme-corp"))
ctx = propagator.Inject(ctx, baggageInjector{baggage})

// === 中间任意服务：读取 baggage ===
baggage = baggage.FromContext(ctx)
userID, _ := baggage.Value("user.id")
// userID == "u-12345"

// === 下游服务：也能读到同样的 baggage ===
```

| 特性 | Baggage | Span Attributes |
|------|---------|----------------|
| 传播范围 | 沿整条链路传递给所有下游 | 仅记录在本地 Span 中，不传播 |
| 大小限制 | 总计 512 字节（防止 Header 膨胀） | 无限制 |
| 典型用途 | 用户 ID、租户、环境标记 | 状态码、耗时、SQL 语句等遥测数据 |
| 是否计入 Span Duration | 否 | 否 |

> [!caution] Baggage 安全须知
> 
> Baggage 会被编码为 HTTP Header 随每个请求传播，**绝不能包含敏感信息**（密码、Token、PII）。默认 512 字节上限也意味着不适合传递大量数据。如需传递大对象，请改为通过 `span.RecordError()` 或独立日志存储。

### 边界的判断：何时创建新 Trace

并非所有场景都需要延续上游 trace。以下情况应考虑开启新 trace：

```mermaid
quadrantChart
    title 跨系统调用：是否延续 Trace?
    x-axis Low Coupling --> High Coupling
    y-axis New Trace --> Continue Trace
    "健康检查 / Scrape": [0.2, 0.15]
    "定时任务 / Cron": [0.15, 0.1]
    "MQ 消息异步解耦": [0.4, 0.7]
    "正常 HTTP/gRPC 请求": [0.85, 0.9]
    "第三方回调": [0.5, 0.25]
    "消息积压重新消费": [0.3, 0.3]
```

| 场景 | 行为 | 说明 |
|------|------|------|
| 正常 HTTP / gRPC / MQ 请求 | 延续上游 trace_id | 标准流程，Extract → Continue |
| 健康检查 / Prometheus scrape | 新建 trace | 可标记 `tracestate` 为 healthcheck |
| 定时任务 / Cron job | 新建 trace | 无上游 context，天然无父 span |
| 消息积压重新消费（跨越数天） | 新 trace + baggage 引用原 trace_id | 保留追溯关联 |
| 第三方回调（外部系统主动推送） | 新建 trace，通过 callback_id 间接关联 | 无法 Extract，只能新建 |
| 伪造 traceparent | 验证格式合法性，非法则忽略并新建 | 记录告警，防止注入攻击 |

**决策流程：**

```mermaid
flowchart LR
    Incoming["Incoming Request"] --> HasTrace{"是否有有效 traceparent"}
    HasTrace -->|"是"| Extract["Extract 并继续"]
    HasTrace -->|"否"| NewTrace["创建新 trace"]

    Extract --> Valid{"格式合法"}
    Valid -->|"是"| Continue["延续 trace"]
    Valid -->|"否"| LogWarn["记录告警丢弃伪造 context"]
    LogWarn --> NewTrace

    NewTrace --> MarkBaggage["可选 baggage 携带原 trace_id 作引用"]
    MarkBaggage --> StartRoot["启动根 Span"]
```

## 主流方案对比

### 方案全景图

```mermaid
quadrantChart
    title 三大追踪方案特性对比
    x-axis Low Invasiveness --> High Flexibility
    y-axis All-in-one APM --> Modular Components
    "SkyWalking": [0.25, 0.75]
    "OpenTelemetry": [0.75, 0.85]
    "Jaeger": [0.6, 0.35]
```

| 方案 | 协议 | 存储后端 | 侵入程度 | 特色能力 |
|------|------|---------|---------|---------|
| **OpenTelemetry** | OTLP | Prometheus/Jaeger/Zipkin | SDK + Auto-Instrumentation | CNCF 标准，厂商中立，未来趋势 |
| **Jaeger** | Jaeger native | Cassandra/Elasticsearch | Agent / SDK | Uber 开源，UI 友好，支持业务 Tags |
| **SkyWalking** | SkyWalking | MySQL/Elasticsearch/ES | 零侵入 Java Agent | 国产，中文文档完善，APM 一体 |

### 演进路线：从单体到 OTel

```mermaid
flowchart LR
    subgraph Phase1["Phase 1 无 Tracing"]
        P1["各服务独立日志\n排查靠翻日志和SSH"]
    end

    subgraph Phase2["Phase 2 Jaeger/SkyWalking 自研"]
        P2["特定语言适配\n链路覆盖不全"]
    end

    subgraph Phase3["Phase 3 OpenTelemetry 统一"]
        P3["SDK 统一\nAuto-Instrumentation\nCollector 收集"]
    end

    P1 ==> P2 ==> P3

    note["推荐目标 OTel Collector 灵活后端\n不锁死任何组件按需替换"]
    note -.-> P3
```

> [!tip] 选型建议
> 新项目优先选 **OpenTelemetry**——它是行业标准，未来会被所有工具支持。如果团队需要开箱即用的 APM，**SkyWalking** 的 Java Agent 零侵入方案是快速上手的最佳选择。

## OpenTelemetry Go 实战

```go
// 初始化 TracerProvider
provider := sdktrace.NewTracerProvider(
    sdktrace.WithBatcherExporter(exporter), // 异步批量上报，不阻塞
)
defer provider.Shutdown(context.Background())

tracer := provider.Tracer("order-service")

func handleOrder(w http.ResponseWriter, r *http.Request) {
    ctx, span := tracer.Start(r.Context(), "handleOrder")
    defer span.End()

    // 设置丰富的属性，方便查询和过滤
    span.SetAttributes(
        attribute.String("http.method", r.Method),
        attribute.Int("http.status_code", http.StatusOK),
        attribute.String("user.id", getUserID(r)),
    )

    // 调用下游服务（trace context 自动传播）
    resp, err := callInventoryService(ctx)
    if err != nil {
        span.RecordError(err)
        span.SetStatus(codes.Error, err.Error())
        w.WriteHeader(http.StatusBadGateway)
        return
    }
    w.Write(resp.Body)
}
```

## 采样策略

> [!question] 为什么需要采样？
> 假设日活 100 万用户，每个用户产生 10 次请求 = 每天 1 千万条 Trace。如果全部存储，按每条 Span 平均 500 bytes 算，单张表一天就是 **数 GB**。采样不是偷懒，是**用可控的成本换取可观测性**。

### 采样算法

OpenTelemetry 提供了两种内置采样器：

```go
// 静态采样：简单粗暴，适合开发环境
alwaysOn := sdktrace.AlwaysSample()       // 100% 采集
alwaysOff := sdktrace.NeverSample()       // 0% 采集（但仍在 SDK 内创建 span）

// 动态采样：根据链路状态智能决策 ⭐ 推荐生产使用
dynamic := sampler.TraceIDRatioBased(0.1) // 10% 随机采样
```

实际项目中通常组合使用 **Parent-Based 分层采样**，确保父子链路一致性：

```go
provider := sdktrace.NewTracerProvider(
    // Parent-based: 父级已采样则子级必采样，反之亦然
    sdktrace.WithSampler(
        sdktrace.ParentBased(
            sdktrace.TraceIDRatioBased(0.1), // 无父 trace 时默认 10%
        ),
    ),
    sdktrace.WithBatcherExporter(exporter),
)
```

### 错误优先采样

```go
type errorPrioritySampler struct {
    baseRate float64 // 基础采样率
}

func (s *errorPrioritySampler) ShouldSample(params sampling.Parameters) sampling.Result {
    ctx := params.SpanContext.Context
    // 检查当前 span 是否已有 error status
    if sc, ok := trace.SpanFromContext(ctx).SpanContext(); ok {
        attrs := sc.Attributes()
        for _, attr := range attrs {
            if attr.Key == "error" && attr.Value.AsBool() {
                return sampling.Result{
                    Decision:  sampling.RecordAndSample, // 100% 采样错误请求
                    Attributes: []attribute.KeyValue{},
                }
            }
        }
    }
    // 非错误请求走基础采样率
    rate := rand.Float64()
    decision := sampling.Drop
    if rate < s.baseRate {
        decision = sampling.RecordAndSample
    }
    return sampling.Result{Decision: decision}
}
```

```mermaid
flowchart LR
    AllReq["全部请求"] --> Sampler{"采样决策"}
    Sampler -->|"有error"| CheckError{"错误标记"}
    CheckError -->|"是"| Core["核心链路全量采集"]
    CheckError -->|"否"| Prob["概率采样"]
    Sampler -->|"无parent"| Prob
    Prob -->|"命中"| Core
    Prob -->|"未命中"| Drop["丢弃"]

    Core --> Storage["Trace 存储"]
    Drop --> Log["非采样请求仅记录计数"]
```

| 环境 | 采样率 | 理由 |
|------|--------|------|
| **开发 / 测试** | 100% | 方便调试，无存储压力 |
| **生产 - 核心链路** | 100% | 下单、支付等关键路径必须全量 |
| **生产 - 普通路径** | 5~10% | 平衡成本和覆盖率 |
| **生产 - 错误链路** | 100% | 出错时的请求优先保留 |

> [!note] 基于错误的智能采样
>
> 高级做法：**正常路径低采样，一旦检测到错误立即提升当前请求的采样率**。这样既省了存储，又能在出问题时有足够的数据回溯。

### 采样对应用的影响

```mermaid
flowchart LR
    subgraph Sampled["被采样的请求比例十百分比"]
        S1["完整 Span 数据"]
        S2["完整日志关联"]
        S3["存储到后端"]
    end

    subgraph Dropped["未被采样的请求比例九十百分比"]
        D1["SDK 内仍创建 Span"]
        D2["不影响业务逻辑"]
        D3["上报时直接跳过 Export"]
    end

    Note["采样不等于不执行\n采样只影响上报不影响业务"]
    Note --> Sampled
    Note --> Dropped
```

> [!warning] 常见误区
>
> 1. **"采样后 span 就不创建了"** → 错！SDK 内部仍然创建和记录 span，只是在 `Exporter` 阶段跳过网络上报。
> 2. **"采样会导致链路断裂"** → 配合 `ParentBased` 可以保证：只要链路上有一条被采样，整条链路的 span 都会被保留。
> 3. **"统计 P99 会有偏差"** → 正确。低采样率下 P99 估计值会偏低，需用统计学方法做补偿估计。

## 渐进式落地路线

> [!tip] 不要试图一开始就采集全部 Span
> 
> 1. **第一步**：先接 Tracing，覆盖核心链路（下单、支付），rate=100%
> 2. **第二步**：加入 Metrics 监控（Prometheus + Grafana）
> 3. **第三步**：集中 Logging（Loki / ELK），与 trace_id 关联
> 4. **第四步**：全量上 OpenTelemetry Collector，统一管理

## 关联笔记

- [[02-服务治理/01-API网关]] — API Gateway 可以在入口处注入 trace_id
- [[04-可观测性/03-链路追踪]] — 更详细的链路追踪设计方法论
- [[02-服务治理/07-配置管理]] — 配置中心的动态刷新可以联动调整采样率