8.6 统一标准：OpenTelemetry 核心概念与全链路追踪实现

1. 引言：追踪系统的“巴别塔”

在微服务架构中，一个用户请求可能经过 10+ 个服务。当请求变慢时，如何定位瓶颈？

分布式追踪（Distributed Tracing）应运而生。它记录请求在服务间的完整调用路径，就像给请求贴上了“GPS 追踪器”。

但问题来了：每个厂商都有自己的追踪系统：

Jaeger（Uber 开源）
Zipkin（Twitter 开源）
SkyWalking（Apache 项目）
Datadog APM（商业产品）

应用需要集成不同的 SDK，数据格式不统一，无法互通。

OpenTelemetry（OTel）的出现，统一了可观测性的数据标准。

2. OpenTelemetry 核心概念

2.1 什么是 OpenTelemetry？

OpenTelemetry 是 CNCF 项目，旨在：

统一标准：定义 Metrics、Logs、Traces 的统一数据模型
厂商中立：不绑定任何后端系统
自动采集：通过 Agent 自动采集，无需修改代码

2.2 三大支柱

Traces：分布式追踪
Metrics：指标（替代 Prometheus 客户端）
Logs：日志（未来支持）

2.3 架构组成

OpenTelemetry SDK：应用集成 SDK，生成遥测数据
OpenTelemetry Collector：接收、处理、导出数据
Backend：Jaeger、Prometheus、Loki 等

3. 核心概念：Trace、Span、Context

3.1 Trace（追踪）

一个 Trace 代表一个完整的请求生命周期。

示例：

用户请求 -> Gateway -> Auth -> Order -> Payment -> Notification

这是一个完整的 Trace。

3.2 Span（跨度）

Span 是 Trace 中的一个操作单元。

示例：

Trace: 用户下单请求 ├─ Span 1: Gateway 处理 (100ms) │ ├─ Span 1.1: 路由到 Order 服务 (10ms) │ └─ Span 1.2: 验证 Token (20ms) ├─ Span 2: Order 服务处理 (200ms) │ ├─ Span 2.1: 查询数据库 (50ms) │ └─ Span 2.2: 调用 Payment 服务 (100ms) └─ Span 3: Payment 服务处理 (150ms)

3.3 Context（上下文）

Context 携带 Trace ID 和 Span ID，在服务间传递。

HTTP 头传递：

X-Trace-Id: abc123 X-Span-Id: def456

4. 实战：Java 应用集成 OpenTelemetry

4.1 添加依赖

<dependencies><dependency><groupId>io.opentelemetry</groupId><artifactId>opentelemetry-api</artifactId><version>1.28.0</version></dependency><dependency><groupId>io.opentelemetry</groupId><artifactId>opentelemetry-sdk</artifactId><version