1. 链路追踪概述
1.1 分布式系统面临的挑战
随着单体应用向微服务架构演进，一个用户请求往往需要跨越多个服务节点、中间件和数据库才能完成。这种架构带来了弹性伸缩、独立部署等优势，但也引入了前所未有的可观测性难题。
| 挑战维度 | 具体表现 | 典型后果 |
|---|---|---|
| 调用拓扑复杂 | 一次请求可能经过 10+ 个服务，依赖关系网状交织 | 故障定位如同大海捞针 |
| 性能瓶颈难定位 | 单个服务延迟增加 50ms，整体响应可能恶化到秒级 | 无法快速识别慢节点 |
| 错误传播不可见 | 下游服务抛异常，上游仅收到 500 状态码 | 丢失根因上下文 |
| 日志/指标割裂 | 每个服务独立记录日志，缺乏全局 RequestID 串联 | 排障时需要人工拼接散落日志 |
| 分布式事务一致性 | 跨服务调用失败后，部分节点已写入数据 | 数据不一致难以回滚 |
核心痛点：在分布式环境中，传统的单机监控（CPU、内存、日志）无法回答“这个请求到底经历了什么？”——链路追踪正是为解决此问题而生。
1.2 链路追踪的核心价值
链路追踪（Distributed Tracing）通过为每个请求注入全局唯一的 TraceID，并记录请求经过的每一个服务节点（Span），从而构建出完整的调用链路视图。其核心价值体现在四个方面：
- 故障快速定位：通过 TraceID 一键检索全链路日志，直接定位到异常 Span 所在的服务与方法。
- 性能瓶颈分析：可视化展示每个 Span 的耗时分布，快速识别慢调用、数据库慢查询、网络延迟等。
- 依赖关系梳理：自动生成服务拓扑图，清晰展示服务间的调用频率、成功率、延迟等指标。
- 容量规划依据：基于链路中的流量数据，准确评估各服务的真实负载，指导扩缩容决策。
1.3 OpenTracing 与 OpenTelemetry 标准简介
早期链路追踪领域存在 Jaeger、Zipkin、SkyWalking 等多种实现，API 互不兼容，导致厂商锁定严重。为解决标准化问题，社区先后推出了 OpenTracing 和 OpenTelemetry 两代标准。
1.3.1 OpenTracing（第一代标准）
OpenTracing 于 2016 年由 CNCF 孵化，定义了一套厂商中立的 API 规范，核心概念包括：
- Trace： 代表一次完整的请求链路，由多个 Span 组成。
- Span： 链路中的基本工作单元，记录一个操作（如 HTTP 调用、数据库查询）的开始时间、结束时间、标签和日志。
- SpanContext： 跨进程传递的追踪上下文，包含 TraceID、SpanID 和 Baggage（用户自定义键值对）。
局限：OpenTracing 仅定义了 API 规范，未涵盖指标和日志的采集，导致开发者仍需集成多个 SDK 才能实现完整的可观测性。
1.3.2 OpenTelemetry（第二代统一标准）
OpenTelemetry（简称 OTel）于 2019 年由 OpenTracing 与 OpenCensus 合并而成，目标是成为可观测性领域的“一次埋点，随处分析”的统一标准。其核心特性如下：
| 维度 | OpenTracing | OpenTelemetry |
|---|---|---|
| 覆盖范围 | 仅链路追踪 | 链路 + 指标 + 日志（三大信号） |
| API 设计 | 接口较抽象，学习曲线陡 | 更贴近开发者直觉，提供自动埋点 |
| 数据导出 | 需额外适配器 | 原生支持 OTLP 协议，可导出到 Jaeger/Prometheus 等 |
| Go 生态 | opentracing-go 库已停止更新 | go.opentelemetry.io/otel 为官方推荐 |
| 社区活跃度 | 维护模式 | CNCF 毕业项目，主流云厂商均支持 |
课程选型说明：本课程所有实战案例均基于 OpenTelemetry Go SDK（go.opentelemetry.io/otel），因为它是当前社区最活跃、云原生生态支持最完善的标准。OpenTracing 仅作为历史背景了解，不再用于新项目开发。
1.4 本章小结
- 分布式系统面临调用拓扑复杂、性能瓶颈难定位、错误传播不可见等核心挑战。
- 链路追踪通过 TraceID 串联全链路 Span，实现故障定位、性能分析、依赖梳理和容量规划四大价值。
- OpenTracing 定义了第一代链路追踪 API 标准，但已被 OpenTelemetry 取代。
- OpenTelemetry 统一了 Trace、Metrics、Logs 三大信号，是 Go 语言链路追踪的推荐标准。