一文详解｜Go 分布式链路追踪实现原理

在分布式、微服务架构下，应用一个请求往往贯穿多个分布式服务，这给应用的故障排查、性能优化带来新的挑战。分布式链路追踪作为解决分布式应用可观测问题的重要技术，愈发成为分布式应用不可缺少的基础设施。本文将详细介绍分布式链路的核心概念、架构原理和相关开源标准协议，并分享我们在实现无侵入 Go 采集 Sdk 方面的一些实践。

---

为什么需要分布式链路追踪系统

微服务架构给运维、排障带来新挑战

在分布式架构下，当用户从浏览器客户端发起一个请求时，后端处理逻辑往往贯穿多个分布式服务，这时会浮现很多问题，比如：

1. 请求整体耗时较长，具体慢在哪个服务？
2. 请求过程中出错了，具体是哪个服务报错？
3. 某个服务的请求量如何，接口成功率如何？

回答这些问题变得不是那么简单，我们不仅仅需要知道某一个服务的接口处理统计数据，还需要了解两个服务之间的接口调用依赖关系，只有建立起整个请求在多个服务间的时空顺序，才能更好的帮助我们理解和定位问题，而这，正是分布式链路追踪系统可以解决的。

分布式链路追踪系统如何帮助我们

分布式链路追踪技术的核心思想：在用户一次分布式请求服务的调⽤过程中，将请求在所有子系统间的调用过程和时空关系追踪记录下来，还原成调用链路集中展示，信息包括各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。

如上图所示，通过分布式链路追踪构建出完整的请求链路后，可以很直观地看到请求耗时主要耗费在哪个服务环节，帮助我们更快速聚焦问题。

同时，还可以对采集的链路数据做进一步的分析，从而可以建立整个系统各服务间的依赖关系、以及流量情况，帮助我们更好地排查系统的循环依赖、热点服务等问题。

分布式链路追踪系统架构概览

核心概念

在分布式链路追踪系统中，最核心的概念，便是链路追踪的数据模型定义，主要包括 Trace 和 Span。

其中，Trace 是一个逻辑概念，表示一次（分布式）请求经过的所有局部操作（Span）构成的一条完整的有向无环图，其中所有的 Span 的 TraceId 相同。

Span 则是真实的数据实体模型，表示一次(分布式)请求过程的一个步骤或操作，代表系统中一个逻辑运行单元，Span 之间通过嵌套或者顺序排列建立因果关系。Span 数据在采集端生成，之后上报到服务端，做进一步的处理。其包含如下关键属性：

• Name：操作名称，如一个 RPC 方法的名称，一个函数名
• StartTime/EndTime：起始时间和结束时间，操作的生命周期
• ParentSpanId：父级 Span 的 ID
• Attributes：属性，一组 键值对构成的集合
• Event：操作期间发生的事件
• SpanContext：Span 上下文内容，通常用于在 Span 间传播，其核心字段包括 TraceId、SpanId

一般架构

分布式链路追踪系统的核心任务是：围绕 Span 的生成、传播、采集、处理、存储、可视化、分析，构建分布式链路追踪系统。其一般的架构如下如所示：

• 我们看到，在应用端需要通过侵入或者非侵入的方式，注入 Tracing Sdk，以跟踪、生成、传播和上报请求调用链路数据；
• Collect agent 一般是在靠近应用侧的一个边缘计算层，主要用于提高 Tracing Sdk 的写性能，和减少 back-end 的计算压力；
• 采集的链路跟踪数据上报到后端时，首先经过 Gateway 做一个鉴权，之后进入 kafka 这样的 MQ 进行消息的缓冲存储；
• 在数据写入存储层之前，我们可能需要对消息队列中的数据做一些清洗和分析的操作，清洗是为了规范和适配不同的数据源上报的数据，分析通常是为了支持更高级的业务功能，比如流量统计、错误分析等，这部分通常采用flink这类的流处理框架来完成；
• 存储层会是服务端设计选型的一个重点，要考虑数据量级和查询场景的特点来设计选型，通常的选择包括使用 Elasticsearch、Cassandra、或 Clickhouse 这类开源产品；
• 流处理分析后的结果，一方面作为存储持久化下来，另一方面也会进入告警系统，以主动发现问题来通知用户，如错误率超过指定阈值发出告警通知这样的需求等。

刚才讲的，是一个通用的架构，我们并没有涉及每个模块的细节，尤其是服务端，每个模块细讲起来都要很花些功夫，受篇幅所限，我们把注意力集中到靠近应用侧的 Tracing Sdk，重点看看在应用侧具体是如何实现链路数据的跟踪和采集的。

协议标准和开源实现

刚才我们提到 Tracing Sdk，其实这只是一个概念，具体到实现，选择可能会非常多，这其中的原因，主要是因为：

1. 不同的编程语言的应用，可能采用不同技术原理来实现对调用链的跟踪
2. 不同的链路追踪后端，可能采用不同的数据传输协议

当前，流行的链路追踪后端，比如 Zipin、Jaeger、PinPoint、Skywalking、Erda，都有供应用集成的 sdk，导致我们在切换后端时应用侧可能也需要做较大的调整。

社区也出现过不同的协议，试图解决采集侧的这种乱象，比如 OpenTracing、OpenCensus 协议，这两个协议也分别有一些大厂跟进支持，但最近几年，这两者已经走向了融合统一，产生了一个新的标准 OpenTelemetry，这两年发展迅猛，已经逐渐成为行业标准。

OpenTelemetry 定义了数据采集的标准 api，并提供了一组针对多语言的开箱即用的 sdk 实现工具，这样，应用只需要与 OpenTelemetry 核心 api 包强耦合，不需要与特定的实现强耦合。

应用侧调用链跟踪实现方案概览

应用侧核心任务

应用侧围绕 Span，有三个核心任务要完成：

1. 生成 Span：操作开始构建 Span 并填充 StartTime，操作完成时填充 EndTime 信息，期间可追加 Attributes、Event 等
2. 传播 Span：进程内通过 context.Context、进程间通过请求的 header 作为 SpanContext 的载体，传播的核心信息是 TraceId 和 ParentSpanId
3. 上报 Span：生成的 Span 通过 tracing exporter 发送给 collect agent / back-end server

要实现 Span 的生成和传播，要求我们能够拦截应用的关键操作（函数）过程，并添加 Span 相关的逻辑。实现这个目的会有很多方法，不过，在罗列这些方法之前，我们先看看在 OpenTelemetry 提供的 go sdk 中是如何做的。

基于 OTEL 库实现调用拦截

OpenTelemetry 的 go sdk 实现调用链拦截的基本思路是：基于 AOP 的思想，采用装饰器模式，通过包装替换目标包（如 net/h