链路追踪详解（三）：分布式链路追踪标准的演进

Google Dapper

Twitter Zipkin

Uber Jaeger

OpenTracing 和 OpenCensus

OpenTelemetry

小结

分布式链路追踪是现代云计算和微服务架构中一个关键技术，可以让开发者和运维团队理解和监控服务请求在复杂系统中的完整流转路径。分布式链路追踪技术的发展经历了从早期的专有解决方案到现代的开源和标准化的过程，本文讲解一下分布式链路追踪标准的演进过程。

Google Dapper

Google 于 2010 年发布的题为《Dapper，a Large-Scale Distributed Systems Tracing Infrastructure》的论文，是分布式链路追踪的一个重要里程碑。这篇论文详细描述了 Google 内部使用的分布式追踪系统的设计和实现方法。Dapper 的目标是提供低开销、应用级的链路追踪系统，能够收集请求在分布式系统的流转数据。该系统的设计和实现方式为后来的分布式追踪技术奠定了基础。

Dapper 的核心概念包括：

Span：表示一个操作或函数调用的时间跨度。
Trace：由多个 span 组成，代表一个请求的完整生命周期。
Sampling：为了降低数据收集的开销，Dapper 采用了抽样技术，只追踪一部分请求。

Twitter Zipkin

受到 Dapper 的启发，Twitter 开发了自己的分布式追踪系统 Zipkin。Zipkin 是第一个被广泛采用的开源的分布式链路追踪系统，提供了数据收集、存储和查询的功能，以及友好的 ui 界面来展示追踪信息。

Zipkin 的架构包括：

Collector：负责接收各服务发送的追踪数据。
Storage：追踪数据的存储系统，可以是 SQL 数据库、Cassandra 或 Elasticsearch。
API：提供数据查询的接口。
Web UI：用于展示追踪信息的系统。

Zipkin 的开源特性使其在社区中迅速流行，许多公司开始使用并贡献代码。

Uber Jaeger

Uber 在内部面临与 Twitter 类似的问题，于是开发了自己的链路追踪系统 Jaeger。Jaeger 在设计上受到了 Dapper 和 Zipkin 的启发，并引入了一些新的特性和概念，比如：

自适应采样：可以动态调整采样率，以在性能和数据质量之间取得平衡。
高级查询功能：提供了更加强大和灵活的查询能力。
端到端追踪：跟踪请求从开始到结束的完整路径。

Jaeger 后来也被开源，并且成为云原生计算基金会（CNCF）的托管项目。Jaeger 的加入进一步加强了分布式链路追踪技术在云原生生态系统中的地位，并得到了更广泛的社区支持。成为了该领域的重要项目。

OpenTracing 和 OpenCensus

随着分布式链路追踪技术的日益流行，有一个问题也日益突出：不同的链路追踪系统和工具之间缺乏兼容性，如果使用了一个链路追踪系统，就很难切换到另一个了。为了解决这个问题，产生了两个重要的项目：OpenTracing 和 OpenCensus。

OpenTracing 旨在提供一套统一的、厂商无关的链路追踪 API 和规范，定义了一套标准的接口，允许开发者在不同的链路追踪系统之间切换而无需修改代码。OpenTracing 的目标是成为链路追踪数据的中间层，让链路追踪工具的选择成为运行时决策而不是设计时决策。OpenTracing 包括了 API 规范、实现该规范的框架和库以及项目文档。

OpenCensus 是由 Google 发起的项目，与 OpenTracing 类似的是都支持 Trace。但相比 OpenTracing 增加了更多的功能，包括新增了对 Metrics 的支持，不仅制定了规范还实现了 Agent 和 Collector。

虽然 OpenTracing 和 OpenCensus 有着相似的目标，但它们在实现方式和社区支持上存在差异，这也导致了一定程度的分裂。

OpenTelemetry

为了解决 OpenTracing 和 OpenCensus 之间的分歧并统一标准，两个项目合并成为了 OpenTelemetry 项目。OpenTelemetry 旨在建立一个全面的可观测性工具集，包括了 Metrics、Tracing、Logs 和日志收集功能。OpenTelemetry 与厂商、平台无关，不提供后端服务。用户可根据自己的需求将数据导出到不同后端，例如 Prometheus、Zipkin、Jaeger 和各云厂商的可观测服务。

OpenTelemetry的关键特性包括：