📚 课程目录第2章分布式追踪基础

2. 分布式追踪基础：Trace、Span、SpanContext 的核心概念，以及 OpenTelemetry 标准在追踪中的角色

在微服务架构中，一次用户请求往往跨越数十甚至上百个服务节点。分布式追踪的核心目标，就是为这种跨进程、跨网络的请求建立一条完整的调用链路，从而在故障发生时能够快速定位瓶颈或错误源头。理解 Trace、Span、SpanContext 这三个基础概念，是掌握分布式追踪的起点。

2.1 三大核心概念

概念	定义	类比（一次电商下单）
Trace	代表一次完整的请求或事务在分布式系统中的全生命周期。由一组具有相同 TraceID 的 Span 组成的有向无环图（DAG）。	用户从点击“提交订单”到收到“下单成功”的整个过程。
Span	Trace 中的最小工作单元，代表一个单一操作（如一次 RPC 调用、一次数据库查询）。每个 Span 记录操作名称、开始/结束时间戳、状态、以及可选的标签（Tags）和日志（Events）。	订单服务调用库存服务扣减库存的这一次具体操作。
SpanContext	Span 的上下文信息载体，用于在进程间传递追踪状态。核心字段包括 TraceID、SpanID、以及可选的 Baggage（自定义键值对）。	快递包裹上的运单号（TraceID）和当前分拣站编号（SpanID），以及附带的“加急”标签（Baggage）。

SRE 实战要点： 在故障排查中，Trace 提供了“全景图”，Span 提供了“单步耗时”，而 SpanContext 是连接所有 Span 的“隐形线”。如果 SpanContext 传递失败（例如 HTTP Header 丢失），Trace 就会断裂，导致无法串联完整链路。

2.2 Trace 与 Span 的层级关系

一个 Trace 由多个 Span 构成，Span 之间通过父子关系（Parent-Child）或因果关系（Follows-From）形成树状结构。根 Span（Root Span）是整个 Trace 的起点，没有父 Span。

2.3 SpanContext 的传播机制

SpanContext 的跨进程传播是分布式追踪的基石。在微服务中，通常通过 HTTP Headers 或 gRPC Metadata 进行传递。以 W3C Trace-Context 标准为例，传播字段如下：

traceparent：携带 TraceID、SpanID 和 TraceFlags（如采样标记）。格式：00-{trace-id}-{parent-span-id}-{trace-flags}。
tracestate：携带供应商特定的扩展信息，用于兼容不同追踪系统。

代码示例： 手动注入与提取 SpanContext（伪代码）

// 服务 A：发起 HTTP 请求前注入 SpanContext
Span currentSpan = tracer.getCurrentSpan();
SpanContext ctx = currentSpan.getSpanContext();
HttpHeaders headers = new HttpHeaders();
// 将 TraceID 和 SpanID 写入 HTTP Header
headers.set("traceparent", String.format("00-%s-%s-01", ctx.getTraceId(), ctx.getSpanId()));
// 发送请求
httpClient.post("http://service-b/api", headers, body);

// 服务 B：接收请求时提取 SpanContext
String traceparent = request.getHeader("traceparent");
// 解析 traceparent 字符串，重建 SpanContext
SpanContext extractedCtx = W3CTraceContextPropagator.extract(traceparent);
// 基于提取的 SpanContext 创建子 Span
Span childSpan = tracer.spanBuilder("process-order")
    .setParent(extractedCtx)
    .startSpan();

2.4 OpenTelemetry 在追踪中的角色

OpenTelemetry（OTel）是 CNCF 旗下的可观测性标准，旨在统一指标、日志、追踪的数据采集规范。在分布式追踪领域，OTel 扮演了以下关键角色：

角色	说明	对 SRE 的价值
API 标准	定义 Tracer、Span、SpanContext 等接口，语言无关。	一次学习，多语言复用；降低团队认知成本。
SDK 实现	提供 Java、Go、Python 等语言的官方 SDK，负责 Span 的创建、采样、导出。	开箱即用，无需自研追踪库；支持动态采样策略。
传播协议	内置 W3C Trace-Context 和 Baggage 传播器，确保跨服务链路不中断。	消除供应商锁定；与 Istio、Envoy 等 Sidecar 原生兼容。
导出器（Exporter）	将 Span 数据发送到 Jaeger、Zipkin、Grafana Tempo 等后端。	灵活选择存储和可视化平台；支持 OTLP 协议统一出口。

避坑指南： 很多团队在引入 OTel 时，只关注 SDK 接入，却忽略了 传播协议的一致性。如果服务 A 使用 OTel，服务 B 使用 Jaeger 原生 SDK，且未配置统一的传播器，SpanContext 将无法跨服务传递，导致 Trace 断裂。务必在组织内统一传播协议（推荐 W3C Trace-Context）。

2.5 OpenTelemetry 追踪架构总览

下图展示了 OTel 在微服务追踪中的完整数据流：从应用代码埋点，到 SDK 处理，再到后端存储与可视化。

2.6 本章小结

Trace 是请求的全景图，Span 是单步操作，SpanContext 是跨进程传递的“信使”。
SpanContext 的传播必须依赖统一标准（如 W3C Trace-Context），否则链路断裂是微服务故障排查中的常见痛点。
OpenTelemetry 通过 API、SDK、传播协议、导出器四层架构，为分布式追踪提供了厂商中立的标准化方案，是 SRE 构建可观测性基础设施的首选。
在 MTTR 复盘口径中，完整的 Trace 数据是计算“故障影响范围”和“根因定位耗时”的原始依据。没有标准化的追踪基础，复盘将沦为“盲人摸象”。