3. 链路追踪基础：OpenTelemetry标准、Trace/Span/Context概念、分布式上下文传播机制

在Saga压测场景中，一次完整的分布式事务可能跨越多个微服务、数据库和消息队列。当故障发生时，传统的日志聚合方式难以将散落在各节点的调用片段串联起来。链路追踪（Distributed Tracing）正是解决这一问题的核心手段，而OpenTelemetry已成为该领域的事实标准。

3.1 OpenTelemetry标准概述

OpenTelemetry（简称OTel）是由CNCF孵化的可观测性框架，统一了数据采集、处理和导出规范。它合并了OpenTracing和OpenCensus两大项目，提供一套与厂商无关的API和SDK。

3.2 Trace / Span / Context 核心概念

链路追踪的三个核心抽象构成了追踪数据的骨架。理解它们之间的关系是定位Saga故障的前提。

3.2.1 Trace（追踪）

Trace代表一次完整的请求或事务在分布式系统中的全貌。它由一组具有相同TraceID的Span组成，逻辑上构成一个有向无环图（DAG）。在Saga场景中，一个Trace对应一次完整的Saga事务执行流程。

3.2.2 Span（跨度）

Span是追踪的最小工作单元，描述一个特定操作（如“调用订单服务”、“更新数据库”、“发送补偿消息”）。每个Span包含：

• SpanID：全局唯一标识
• ParentSpanID：父Span标识，用于构建父子关系
• OperationName：操作名称（如 saga.bookInventory）
• StartTime / EndTime：开始与结束时间戳
• Attributes：键值对标签（如 orderId=12345）
• Events：带时间戳的事件记录（如异常堆栈）
• Status：成功/错误状态码

3.2.3 Context（上下文）

Context是跨进程传递的追踪元数据载体，包含TraceID、SpanID、Baggage等关键信息。它确保下游服务能够将当前Span正确关联到上游的Trace中。

3.3 分布式上下文传播机制

上下文传播（Context Propagation）是链路追踪的“神经系统”。它确保当请求从一个服务传递到另一个服务时，TraceID和SpanID能够被正确携带，从而在全局视角下重建调用链。

3.3.1 传播协议

OpenTelemetry默认采用W3C TraceContext标准，通过HTTP头或gRPC元数据传递上下文信息：

3.3.2 传播流程

1. 注入（Inject）：上游服务在发起远程调用前，将当前Context序列化并写入请求头。
2. 提取（Extract）：下游服务收到请求后，从请求头中反序列化出Context，并创建新的子Span。
3. 关联（Associate）：子Span通过ParentSpanID指向父Span，形成完整的调用链。

3.4 在Saga压测中的关键作用

将上述基础概念映射到Saga压测场景，链路追踪的价值体现在三个层面：

• 事务完整性验证：通过Trace确认Saga的每个步骤（正向操作+补偿操作）是否按预期执行，补偿链路是否完整。
• 性能瓶颈定位：通过Span的耗时分布，快速识别是哪个微服务、数据库或消息队列成为压测瓶颈。
• 故障根因分析：当Saga事务失败时，通过Context携带的Baggage（如订单ID、用户ID）和Span Events（如异常堆栈），精准定位失败节点和原因。