分布式追踪详解：Trace、Span 与上下文传播的工作原理
分布式追踪通过 Trace 与 Span 记录请求在微服务间的完整流转路径，是微服务排障的核心技术。本文讲透 Trace ID、Span、埋点、上下文传播、采样等核心概念，以及如何用观测云落地分布式追踪。
分布式追踪是一种记录请求在分布式系统中完整流转路径的技术：请求每经过一个环节就产生一个 Span，所有 Span 由同一个 Trace ID 串联成调用树——在单体架构里，看本地日志就够；而在微服务架构里，只有分布式追踪能回答「这个请求为什么慢、错误是从哪个服务冒出来的」。
核心要点速览
- Trace = 一次请求的完整旅程；Span = 旅程中的一个环节（一次调用、一条 SQL）；
- Trace ID 全局唯一，Span 之间通过父子关系构成调用树；
- 上下文传播（Context Propagation）是跨进程串联 Trace 的关键机制；
- 全量采集成本高昂，生产环境通常配合采样策略。
为什么需要分布式追踪？
微服务架构下，一个用户请求可能依次经过网关、鉴权服务、订单服务、库存服务、数据库与消息队列。当用户投诉「下单很慢」时：
- 看每个服务自己的日志：都正常，因为每个环节只慢了 100ms；
- 看接口总耗时：2 秒，但不知道耗在哪。
这就是分布式追踪要解决的问题——局部正常 ≠ 全局正常，只有完整的调用链视角才能暴露累积延迟与跨服务错误传播。
分布式追踪是如何工作的？
以一次下单请求为例：
- 请求到达入口服务，探针生成全局唯一的 Trace ID 和第一个 Span；
- 入口服务调用订单服务时，把 Trace ID 与当前 Span ID 通过 HTTP 头（如
traceparent）传递下去——这就是上下文传播； - 每个下游服务基于收到的上下文创建子 Span，记录自己的操作名、起止时间、状态与属性；
- 所有 Span 上报到后端，按 Trace ID 组装成调用树，用瀑布图/火焰图呈现。
分布式追踪的核心概念
Trace 与 Trace ID
Trace 是一次请求的完整记录；Trace ID 是其全局唯一标识，也是串联日志、指标的关键字段——在日志中注入 Trace ID 后，链路和日志就能互相跳转。
Span
Span 是 Trace 的基本单元，包含：操作名（如 GET /orders）、开始与结束时间、状态（OK/ERROR）、父子关系。一个 Span 代表一个工作单元：一次 HTTP 调用、一条 SQL、一个内部函数。
埋点（Instrumentation）
让应用产生 Span 的过程。分两类：自动埋点（Java Agent、eBPF，零代码改动）与手动埋点（用 SDK 为关键业务逻辑补充 Span）。
Span 属性（Attributes）与事件
属性是附加在 Span 上的键值对（如 http.status_code=200、db.statement=...），是后续检索与分析的维度；Span 事件记录 Span 生命周期中的时间点信息（如异常抛出）。
上下文传播
把 Trace 上下文（traceparent/tracestate 或 B3 头）跨进程传递的机制。异步场景（消息队列）同样需要在消息头中携带上下文，否则链路会断。断链是落地分布式追踪最常见的坑，详见《OpenTelemetry 上下文传播》。
采样（Sampling）
全量采集所有请求的 Trace 在流量大时成本不可接受。采样策略（头部采样、尾部采样）在「保留代表性数据」与「控制成本」之间取得平衡，详见《OpenTelemetry 采样详解》。
后端分析平台
Span 数据的存储与分析端：提供服务拓扑、链路检索、耗时分析。观测云 APM 即承担这一角色。
分布式追踪对可观测性的意义
链路数据把「点状」的日志和指标组织成「线状」的请求故事：指标告诉你错误率升高，链路告诉你是哪个依赖引入的，日志告诉你具体报了什么错。三者以 Trace ID 为纽带形成排障闭环。
生态与标准
当前事实标准是 OpenTelemetry（CNCF 项目，统一了 OpenTracing 与 OpenCensus），其 OTLP 协议已成为链路数据交换的通用语言；Jaeger、Zipkin、SkyWalking 等老牌工具的数据也都可以通过 DataKit 接入观测云。eBPF 则提供了零侵入的链路采集新路径。
观测云落地：从埋点到排障闭环
- 接入：Java/Go/Python/Node.js 等应用通过 OTel SDK 或 DDTrace 探针埋点，数据上报到 DataKit 的 OTLP 接收端（4317/4318）；
- 查看：APM 模块提供服务拓扑、服务清单、链路检索与火焰图详情，错误 Span 自动标红；
- 关联：日志配置注入
trace_id后，链路详情页可直接跳转同请求的日志；RUM 打通后实现浏览器端到数据库端的全程追踪； - 告警：监控器按服务/接口维度检测错误率与延迟，异常自动通知；
- 成本：通过采样策略与存储策略控制链路数据成本。
常见问题（FAQ）
Q：异步消息（Kafka）场景链路会断吗？ 会断如果不在消息头中注入上下文。主流探针对 Kafka/RocketMQ 等都有自动传播支持，观测云可正常呈现跨 MQ 的完整链路。
Q：老系统没法改代码能做链路追踪吗？ 两条路：Java 等语言用 Agent 自动埋点（零代码）；或者用 eBPF 方案在内核层采集服务间调用（覆盖度略低于埋点但零侵入）。
Q：采样会不会漏掉关键的出错请求？ 尾部采样策略可以先缓存再决策，优先保留错误与高延迟的 Trace；头部采样则按比例随机。观测云支持灵活配置。
Q：分布式追踪和服务网格（Istio）的追踪有什么区别？ 服务网格追踪在网络代理层生成 Span，零应用侵入但缺少应用内部细节；埋点追踪包含应用内部逻辑。两者可互补使用。
系列阅读
- 上一篇：《什么是 APM》
- 下一篇：《理解高基数问题》
- 相关：《Jaeger 分布式追踪实战》 · 《eBPF 可观测性》 · 《返回索引》
