微服务链路追踪：看清请求的完整路径

可视化演示

展示Trace/Span瀑布图、上下文跨进程传递机制及采样策略与性能开销权衡。

1. 追踪基础：从物流单号到 Trace 与 Span

你在网上买了一盒咖啡豆，打开物流 App，能看到“已下单、仓库已打包、干线运输中、已到本地网点、派送中、已签收”一整条时间线。这条时间线的背后，是包裹每经过一个中转站就被扫描枪记录一次。把所有这些“中转记录”串起来，你就知道这盒咖啡豆此刻在哪、经过了哪些地方。微服务里的链路追踪，做的就是同样的事——只不过“包裹”是用户的请求，“中转站”是后台一个个微服务。

一个用户请求进入系统后，通常会经过 API 网关、用户服务、订单服务、库存服务等多个节点。追踪系统把这整段旅程定义为一个 Trace（链路），把其中每一个服务处理的一小段定义为 Span（片段）。Span 之间不是孤立的：服务 A 调用了服务 B，那么 B 的 Span 就是 A 的 Span 的子节点，这种父子关系把所有 Span 组织成一棵“调用树”。

以最常见的追踪语义为例，一个 Span 至少包含六类信息：全局链路 ID（traceId）、当前片段 ID（spanId）、父片段 ID（parentSpanId）、开始与结束时间戳、以及随附的属性标签。写成一个结构就是：

每个 Span 都像物流系统里的一次“扫描记录”：单号是谁、上一站是哪、几时几分进的站、到了哪个站点。当客服想查一单快递为什么延误，只要按物流单号把所有扫描记录按时间排开，堵在哪一目了然——链路追踪就是给工程师的那张“物流全程地图”。

2. 上下文传播：让物流面单一路随行

物流包裹能一单到底，靠的是贴在包裹上的面单。包裹每到一个中转站，分拣员不需要重新贴一张新单，只要扫面单上的条码，就知道它从哪来、要往哪去。面单必须跟着包裹走，这是物流系统能串起来的前提。在微服务链路里，这份“面单”就是追踪上下文（Trace Context）。

如果每个服务各自生成一套编号，链路就断了。所以 Trace ID 必须在请求入口（如 API 网关）统一生成，然后通过 HTTP 请求头等方式传递给下游。目前业界最通用的是 W3C 的 traceparent 标准，它规定了上下文在跨服务调用时的传递格式。

一个标准的 traceparent 头包含四个字段，以短横线分隔。不同语言的框架（如 Spring Cloud 的 Sleuth、Go 的 otel 中间件）都会自动完成“从请求头读取上下文、调用下游时注入上下文”这两个动作，业务代码基本无感。在进程内部，上下文常存放在 ThreadLocal 中，线程池场景需要显式传参或用装饰器传递。

面单上那一串条码，就是 Trace ID 的化身。只要面单不丢、每一站都扫码，快件的轨迹就连得起来。链路追踪也一样——只要每个服务都诚实地把 traceparent 往下传，整条调用链就能从入口连到末端。

3. 采样策略：不为每个包裹都全程录像

快递公司不会给每件包裹都配一个全程跟拍的摄像师，那样成本会高到破产。现实做法基本是：普通包裹抽查录像，贵重或已出问题的包裹才申请全程重点跟拍。微服务的高峰流量同样如此——每秒几千上万个请求，如果每个请求的 Trace 都完整落库，存储和传输开销会迅速爆炸。

采样（Sampling）就是为了在“数据完整度”和“成本”之间做取舍。常见策略有三种：全量采样适合低流量或关键链路；固定比例采样按设定概率随机抽取，实现简单；动态采样则根据系统状态自动调整采样率。

头部采样（Head-based）在请求入口就决定“这单要不要全程录像”，采样信号通过 flags 位传给下游，各服务不再单独决策，避免“上下游各采一半”导致链路断裂。更聪明的做法是动态调整采样率：当一个窗口内请求量暴增时，自动降低采样率以保护存储；当错误率升高时，自动提高采样率以便收集足够多的故障样本。

采样就像快递公司的那套“抽查+重点跟拍”策略：平时 10% 的包裹有录像就够了，一旦配送异常率飙升，立刻把抽查比例提到 100%，把每个异常包裹的全程轨迹都留下。这套机制让追踪系统既省钱，又不至于在关键时刻“瞎眼”。

4. OpenTelemetry：行业统一面单标准

以前不同快递公司各自印刷自己的面单，A 家的单号拿到 B 家去查，B 家系统根本不认识。后来行业统一了面单标准（如条码格式），不同公司之间才能互通互认。微服务世界也走过同样的弯路：早期有 Zipkin、Jaeger、SkyWalking 等多种追踪实现，各用各的数据格式，接入方被厂商绑定。

OpenTelemetry（简称 OTel）是 CNCF 主推的可观测性标准，已成为事实上的“统一面单”。它提供一套中立的 API、SDK 和数据模型，让应用只需面向 OTel 埋点，就能把 Trace 数据导出到任何兼容的后端（如 Jaeger、Datadog、自建 Collector）。

OTel 的设计核心是 API 与 SDK 分离：API 定义“往面单上写哪些格子”，SDK 负责“把面单送到转运中心”（通过 Exporter 导出到后端）。接入方式有两种——自动埋点通过语言 Agent 或中间件拦截库自动生成 Span，适合快速覆盖；手动埋点则在关键业务代码中显式创建 Span，适合标记业务语义。

有了 OTel 这张“行业标准面单”，你不再关心后端是哪个快递公司——面单格式统一了，想换数据平台，只改 Exporter 配置即可，业务代码一行都不用动。

5. Baggage 透传：面单上的备注栏

快递面单上除了条码，还有一小块“备注栏”：客户会写“易碎品，请轻放”“到货放驿站”“货到付款”。这些备注不参与分拣路由，但每一站的工作人员都能看到，并据此调整处理方式。链路追踪里也有这么一块“备注栏”，叫作 Baggage。

Baggage 是 W3C 标准中与 traceparent 并列的另一个头（baggage），它允许调用链上传递一组键值对，比如 userId、灰度版本号、请求来源渠道。与 Span 属性不同，Span 的标签只属于单个 Span，而 Baggage 会附着在 Trace 上下文上，一路透传给所有下游服务。

一个典型 baggage 头长这样：userId=9527; grayVersion=v2; channel=mobile。下游服务可以直接读取这些字段做业务逻辑，例如灰度发布时代理层据此把请求路由到灰度机器。使用 Baggage 要克制：它会被复制到每个下游 Span 上，如果塞入大字段（如完整请求体），会让每条 Trace 都膨胀数倍。

备注栏写什么、写多少，直接决定各站点工作人员要额外读多少信息。聪明的做法是只写“影响处理动作的关键备注”，Baggage 也同理：只透传必要的业务标识，别把整页合同贴面单上。

6. 关联排障：轨迹、通话与监控录像齐上阵

客服查一个“已签收但用户没收到”的投诉时，会同时看三样东西：物流轨迹、快递员通话记录、签收底单照片。只看其中任何一样都很难定责，但三者拼在一起，基本就能还原真相。可观测性世界的“三样东西”，就是指标（Metric）、日志（Log）和链路（Trace）。

Trace 擅长回答“是哪一跳慢”，但它不擅长回答“这个服务整体是不是在变慢”——这需要指标；而“那一跳上到底发生了什么错误”——这需要日志。把三者关联起来的粘合剂，正是 Trace ID：日志中打印 trace_id 和 span_id，查询单条 Trace 时即可关联出该 Span 覆盖的时间段内的所有日志。

通用的排障工作流是：先看 RED 指标确认异常是否真实存在——Rate（请求速率）、Errors（错误率）、Duration（平均耗时）；接着进 Trace 瀑布图找到耗时最宽的 Span；最后点开这个 Span 关联的日志，看到具体堆栈。整个过程如同“指着一份物流轨迹上最久的一站，再调出那个仓库的监控录像”。

这套“指标发现面、Trace 定位点、日志看清根因”的组合拳，就是现代可观测性工程的核心打法。别再一个人翻十几个服务的日志了——先让 RED 指出方向，再用 Trace 下钻到那一站，最后让日志说清真相。

AI 应用场景

Python 演示

import time span_seq = 0  def next_id():    global span_seq    span_seq += 1    return f"span{span_seq}"  class Span:    def __init__(self, name, parent_id=None, trace_id=None):        self.name = name        self.span_id = next_id()        self.trace_id = trace_id or self.span_id        self.parent_id = parent_id        self.start = time.time()        self.end = None        self.children = []        self.attributes = {}     def finish(self):        self.end = time.time()     def duration_ms(self):        if not self.end:            return 0.0        return (self.end - self.start) * 1000     def report(self, depth=0):        indent = "  " * depth        print(f"{indent}span={self.name} id={self.span_id} trace={self.trace_id} "              f"cost={self.duration_ms():.2f}ms")        for child in self.children:            child.report(depth + 1)  class Tracer:    def __init__(self, sample_rate=0.8):        self.sample_rate = sample_rate        self.sampled_count = 0     def should_sample(self, trace_id):        return int(trace_id, 16) % 100 < self.sample_rate * 100     def start_root(self, name, trace_id):        if not self.should_sample(trace_id):            return None        root = Span(name, trace_id=trace_id)        self.sampled_count += 1        return root  def call_service(parent, name, seconds):    span = Span(name, parent_id=parent.span_id, trace_id=parent.trace_id)    time.sleep(seconds)    span.finish()    parent.children.append(span)    return span  def main():    total = 5    tracer = Tracer(sample_rate=0.8)    for i in range(1, total + 1):        trace_id = f"f{i}000"        root = tracer.start_root(f"req-{i}", trace_id)        if root is None:            print(f"req-{i} trace={trace_id} not sampled")            continue        gateway = call_service(root, "gateway", 0.005)        user = call_service(gateway, "user-service", 0.008)        order = call_service(gateway, "order-service", 0.006)        root.finish()        root.report()        print("---")    print(f"sampled {tracer.sampled_count}/{total} "          f"rate={tracer.sampled_count / total:.0%}")  if __name__ == "__main__":    main()

1. def should_sample(self, trace_id):头部采样判决：对 trace_id 的十六进制值取余 100，决定这条链路是否留存。
2. root = Span(name, trace_id=trace_id)入口创建根 Span，trace_id 全链路唯一。
3. span = Span(name, parent_id=parent.span_id, trace_id=parent.trace_id)下游 Span 必须继承父 Span 的 trace_id，并记录 parent_id。
4. parent.children.append(span)把子 Span 挂到父 Span 的 children 下，形成调用树。
5. call_service(gateway, "user-service", 0.008)模拟一次服务调用，用 sleep 模拟耗时。
6. root.report()递归打印整棵调用树，让工程师“一眼看清”整条 Trace。
7. tracer = Tracer(sample_rate=0.8)设定 80% 采样率，样本越多存储成本越高，需要权衡。

常见误区

面试题