微服务治理-链路追踪

链路追踪（Distributed Tracing）是微服务可观测性（Observability）的核心能力之一，用于在分布式系统中还原一次请求的完整调用路径，并定位性能瓶颈与故障点。

一、介绍

1.1 为什么需要链路追踪？

在单体应用中：一次请求在同一个进程内完成，只需要

• 打日志
• 打断点
• 其他调试
  即可定位问题。

但在微服务架构中：

Client
  ↓
API Gateway
  ↓
User Service
  ↓
Order Service
  ↓
Payment Service
  ↓
Inventory Service
  ↓
DB / MQ

一次请求变成：

跨进程 + 跨机器 + 跨网络

1.2 典型问题

问题1：不知道慢在哪里

比如 ：接口很慢

但系统里有：Gateway、User、、Order…

你无法判断：到底慢在谁？

问题2：日志分散

如： Gateway logs User logs Order logs Payment logs

每个服务都有日志,但它们之间没有关联关系。

问题3：无法串联一次请求

无法确认日志是不是同一个请求？

1.3 链路追踪要解决什么问题？

把一次请求在多个微服务中的完整路径“串起来”

核心能力：

• 请求路径可视化
• 性能瓶颈定位
• 服务依赖分析
• 故障快速定位

二、原理

2.1 核心概念

链路追踪有三个核心概念：

1.Trace（一次完整请求）

Trace = 一次完整请求生命周期

例如：

用户点击下单按钮 = 1个 Trace

2. Span（一次调用）

Span 表示：

一次服务调用 / 一个方法执行

例如：

Gateway → UserService = 1 Span

UserService → OrderService = 1 Span

3. TraceID（全局唯一ID）

用于串联所有服务：

TraceID: 8f3a21

所有日志都带这个 ID。

2.2 调用链结构

Trace (请求A)
│
├── Span1: Gateway
│     ├── Span1.1: Auth
│
├── Span2: User Service
│     ├── DB Query
│
├── Span3: Order Service
│
└── Span4: Payment Service

2.3 TraceID 传递机制

关键点：

TraceID 必须跨服务传递

HTTP Header 传递

X-Trace-Id: 8f3a21

调用流程

Client
  ↓ (生成 TraceID)
Gateway
  ↓ (透传 TraceID)
User Service
  ↓ (继续透传)
Order Service
  ↓
Payment Service

2.4 Span 结构

每个 Span 包含：

{
  "traceId": "8f3a21",
  "spanId": "a1",
  "parentSpanId": "a0",
  "service": "user-service",
  "operation": "getUser",
  "startTime": 100,
  "endTime": 115,
  "duration": 15
}

2.5 数据上报模型

链路追踪通常是：

异步上报

流程：

Service
  ↓
Collector
  ↓
Storage
  ↓
UI（Jaeger / Zipkin）

2.6 典型系统架构

Client
  ↓
API Gateway
  ↓
Microservices
  ↓
OpenTelemetry SDK
  ↓
Collector
  ↓
Jaeger / Zipkin / Tempo

三、实现

OpenTelemetry（OTel）

核心能力

• 自动生成 Trace / Span
• 自动采集 HTTP / DB / RPC
• 自动上报

四、最佳实践

4.1 必须全链路 TraceID 透传

所有：

• HTTP
• RPC
• MQ

都必须带：

TraceID

4.2 不要只靠日志排查问题

4.3 采样（Sampling）

生产环境不能全量记录

4.4 Trace + Metrics + Logs 三位一体

Logs（发生了什么）
Metrics（系统健康）
Traces（请求路径）

4.5 慢请求定位策略

Trace分析：

找最长 Span