Trace 与 Span

微服务时代的难题

指标能告诉我们「支付接口 P95 变慢了」，日志能告诉我们「某个订单处理失败了」，但在微服务架构中，一次请求可能经过 API 网关、订单服务、支付服务、库存服务、消息队列和数据库。

链路追踪要回答的问题是：这次请求到底卡在哪里？

基本模型

• Trace：一次完整请求的全局轨迹。
• Span：请求中的一个操作，例如调用订单服务、查询数据库、发送消息。

一个 trace 由多个 span 组成：

每个 span 要记录什么

• 开始时间、结束时间。
• 服务名、操作名。
• 父 span（树形结构）。
• 状态和错误信息。

为什么用树形结构

Span 不是平铺的，而是树形的：

Trace
├── API Gateway (根 span)
│   ├── Order Service
│   │   ├── Payment Service
│   │   └── MySQL query
│   └── MQ publish

树形结构能还原调用层级：谁调用了谁、每层花了多少时间。

一句话

Trace 是一次完整请求的全局轨迹，Span 是其中的一个操作。树形 span 结构让你一眼看到请求卡在哪一层——这就是排障的突破口。

上一章节

链路追踪

下一章节

上下文传播