分布式链路追踪：Jaeger 落地实践
为什么需要分布式追踪 微服务架构下，一个用户请求往往要穿越多个服务。当某个接口耗时从 200ms 飙升到 2s 时，日志散落在 N 台机器上，你很难判断瓶颈在哪一层——是网关转发慢、下游 DB 查询慢、还是某个服务间调用排队？ 分布式追踪（Distributed Tracing）解决的就是这个问题：它为每个请求生成一个全局唯一的 Trace ID，在服务间透传，最终在 UI 上画出一条完整的调用链路树，让每一段耗时一目了然。 Jaeger（发音类似"耶格"）由 Uber 开源，现为 CNCF 毕业项目。本文基于 Jaeger v1.60+ 和 OpenTelemetry SDK 进行实践。官方文档 分布式追踪核心概念 Trace 一个 Trace 代表一次完整的分布式请求链路，由唯一的 128-bit Trace ID 标识。它是一棵由多个 Span 组成的树形结构： Trace (TraceID: a1b2c3...) ├── Span: HTTP GET /api/orders [gateway] │ ├── Span: RPC GetUser [user-service] │ │ └── Span: SELECT * FROM users [mysql] │ └── Span: RPC GetOrderList [order-service] │ └── Span: Redis GET [redis] Span Span 是追踪的最小单元，记录一次操作的开始和结束。关键字段：...