链路追踪详解(三):分布式链路追踪标准的演进

目录

[Google Dapper](#Google Dapper)

[Twitter Zipkin](#Twitter Zipkin)

[Uber Jaeger](#Uber Jaeger)

[OpenTracing 和 OpenCensus](#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的关键特性包括:

  • 统一的 API 和 SDK:定义了 Metrics、Tracing、Logs 几种类型的标准,并提供了相关的适配了各种语言的 SDK
  • 多语言支持:支持多种编程语言和框架。
  • 可插拔架构:可以轻松地将数据导出到不同的后端分析工具。

OpenTelemetry 的目标是成为分布式链路追踪和监控的事实标准,通过提供一个全面的解决方案,试图适应不断发展的分布式系统的需求。

小结

从 Dapper 到 OpenTelemetry,分布式链路追踪技术经经历了从专有到开源,再到标准化的过程。这一过程反映了行业对于系统可观测性的不断追求,OpenTelemetry 作为分布式链路追踪的事实标准,代表了这个领域未来的技术方向。

相关推荐
字节程序员18 分钟前
Jmeter分布式压力测试
分布式·jmeter·压力测试
颜淡慕潇28 分钟前
【K8S问题系列 |19 】如何解决 Pod 无法挂载 PVC问题
后端·云原生·容器·kubernetes
ProtonBase34 分钟前
如何从 0 到 1 ,打造全新一代分布式数据架构
java·网络·数据库·数据仓库·分布式·云原生·架构
时时刻刻看着自己的心38 分钟前
clickhouse分布式表插入数据不用带ON CLUSTER
分布式·clickhouse
向前看-8 小时前
验证码机制
前端·后端
Data跳动9 小时前
Spark内存都消耗在哪里了?
大数据·分布式·spark
超爱吃士力架9 小时前
邀请逻辑
java·linux·后端
Java程序之猿11 小时前
微服务分布式(一、项目初始化)
分布式·微服务·架构
来一杯龙舌兰11 小时前
【RabbitMQ】RabbitMQ保证消息不丢失的N种策略的思想总结
分布式·rabbitmq·ruby·持久化·ack·消息确认
AskHarries11 小时前
Spring Cloud OpenFeign快速入门demo
spring boot·后端