📚 课程目录第1章 Trace聚合基础概念

第1章 Trace聚合基础概念

排查目标： 理解分布式trace的基本构成（span/trace），掌握聚合的核心目的——在复杂调用网络中快速锁定异常调用链，为后续的根因定位与热修复补丁制作奠定数据基础。

1.1 现象识别：为何需要Trace聚合？

在微服务架构中，一个用户请求往往需要跨越数十个服务实例。当线上出现“支付超时”、“订单创建失败”等现象时，分散在各个服务日志中的片段时间点无法直接拼出完整调用顺序。如果不进行聚合，排查人员面对的是割裂的、无序的“局部快照”，难以判断异常发生的真实位置。

1.2 数据采集：Trace与Span的定义

分布式追踪系统通过两个核心数据结构描述一次完整请求链路：Trace 和 Span。

概念	定义	类比（线上问题排查）
Trace	代表一个完整的请求端到端路径，从网关收到请求到返回最终结果，贯穿所有参与的服务和组件。	一次完整的“犯罪过程”回放，包含所有线索。
Span	Trace中的最小工作单元，代表某个服务内的一段具体操作（如RPC调用、数据库查询、业务逻辑处理），记录了开始/结束时间、状态和元数据。	犯罪过程中的“单步动作”，例如“调用了支付服务”或“查询了用户余额表”。
Span Context	包含Trace ID和Span ID的上下文对象，负责在服务调用间传递，保证同一个Trace内的Spans能被正确关联。	案件编号和指纹，用于串联不同位置的证据。

排查规则： 判断一个Trace是否完整，看其是否包含从入口层（如Nginx/网关）到数据层（如MySQL/Redis）的Span。缺少任意一层，都可能导致“调用中断”假象。

Span与Trace的关系：

每个Trace有且只有一个根Span（Root Span）。
根Span内部或之后可以创建子Span（Child Span），形成树形结构。
聚合过程就是将分散在不同服务节点上的、同一Trace ID的Spans，按父子关系和时序重新组装成一棵完整的调用树。

1.3 核心结构：聚合的目的

聚合分布式trace的主要目的体现在以下三个维度，直接服务于问题排查。

目的	排查场景	聚合前后的变化
快速定位异常调用链	从上万个请求中找出那个“P99延迟超标”的调用路径。	聚合前：多个服务日志，分散时间戳。聚合后：一条完整调用链，明确哪个Span耗时异常。
识别依赖与故障扩散	接口A超时，是因为A本身慢，还是下游服务B或C的响应慢导致阻塞。	聚合前：只知道A慢。聚合后：发现A的Span中等待下游响应的部分耗时最长，明确问题在下游。
支持回放与复现	判断某次异常回滚操作的具体执行栈。	聚合前：只知道业务规则变更了。聚合后：通过回放trace可以看到代码执行的精确顺序和参数状态。

判断规则： 如果一根完整的Trace树中，有一个Span状态为ERROR，但其父Span状态为SUCCESS（或未捕获），说明该异常被业务代码“吞掉”而未向上传播。这也是线上问题排查中经常被遗漏的情况。

1.4 Trace聚合的基础结构（内联SVG）

下图展示了一个用户请求在三个服务（网关、用户服务、订单服务）间传播时，Span如何组织成Trace树，以及聚合引擎如何将分散的Span合并为完整调用链。

1.5 聚合在问题排查中的故障树应用

在一次典型的“订单接口响应慢”问题排查中，聚合后的Trace树可以快速构建故障树如下：

现象：创建订单接口（/order/create）平均响应时间从200ms上升到5s
 |
 +-- 排查入口：过滤所有Trace ID，聚合耗时>4s的调用链
      |
      +-- 问题1：网关层Root Span耗时5.2s（异常）
      |    |
      |    +-- Span_A（用户服务getUser）耗时10ms（正常）
      |    |
      |    +-- Span_B（用户服务queryBalance）耗时4.8s（异常节点）
      |    |    |
      |    |    +-- 子Span_C（调用MySQL：select * from account_balance）耗时4.8s（根因）
      |    |    |    |
      |    |    |    +-- 根因判断：MySQL查询未命中索引，锁等待严重
      |    |    |
      |    |    +-- Span_D（调用Redis缓存）未返回（缓存击穿）
      |    |
      |    +-- Span_E（订单服务create）耗时300ms（正常，但受上游阻塞影响）
      |
      +-- 结论：需要紧急修复MySQL慢SQL或添加缓存兜底逻辑

排查实战建议： 在搭建trace聚合系统时，优先保证Trace ID传递的完整性。如果某个服务收到请求但没有Trace ID，该Span将无法被聚合，形成“孤立Span”，这就是调用链断裂的最常见原因。可以使用排查表检查：每个RPC调用的HTTP header或gRPC metadata是否都正确传递了trace_id和span_id。