分布式追踪的起源

自从微服务的兴起开始，整个系统架构开始变得极为庞大和复杂，但是服务之间的调用关系，调用消耗时间等等信息却依然是半黑盒的状态。为了能够将调用的链路进行串联，将系统的各种指标数据展示出来以使得系统的链路更加透明便于排查故障，分布式追踪便应运而生。

分布式追踪的起源有一个比较普遍的说法是源自 Google2010 年发表的论文Dapper, a Large-Scale Distributed Systems Tracing Infrastructure，然而实际上更早之前就有一些大公司内部已经有了类似的组件在使用了，只是不为人所知。当然即便如此，作为最早的系统性的论述分布式追踪的论文，它有着非同寻常的影响了，可以说是很多分布式追踪的实现参考。

百花齐放的分布式追踪

Zipkin

Zipkin最初是由 Twitter 开发并与 2012 年开源的一款开源追踪系统。Zipkin 的使用非常广泛，影响了很多的后来人。他的传输头为X-B3

Skywalking

Skywalking是由国人开发，并且在后续捐赠给了 Apache 基金会的一个开源项目。现在是 Apache 基金会的顶级项目。

Pinpoint

Pinpoint由 Naver 在 2012 年开发，并于 2015 年开源。Pinpoint 适用于 java，php 和 python。

Jaeger

Jaeger最早是由 Uber 开发并于 2017 年开源，后续捐赠给了 CNCF 基金会。

OpenCensus

OpenCensus由 Google 发起，最初是 Google 内部追踪平台，后开源。

OpenTracing

OpenTracing由 CNCF 托管，具备较为完善的 instrumentation 库。

简单的盘点一下就能发现在这段时期出现了许多耳熟能详的分布式追踪开源项目，而且这些项目往往都有不少的使用者。

OpenCensus 与 OpenTracing

在上述的项目中有两个项目较为特殊：其一是 OpenTracing，他制定了一套无关平台的统一的 Trace 的标准，后续的很多项目例如 Jaeger 等都是基于此协议，因此他在当时的 Trace 标准领域具有不小影响力；其二是 OpenCensus，他背靠 Google，并且它不仅仅实现了 Trace，还包括了 Metrics，并且他包含了一系列诸如 Agent 和 Collector 的方案，可以说是相当完备。

在当时这两大流派可以说是互相有一大票的追随者，一边是以 Google 和微软领衔的 OpenCensus，一边是众多开源项目和厂商使用的 OpenTracing，两者可以说是各有优劣，各领风骚。直到有一天...

Opentelemetry 的诞生

再经过了一段时间的发展后 OpenCensus 与 OpenTracing 为了将两者的优点进行整合，宣布将进行合并，两者的合并就是后来赫赫有名的Opentelemetry

Opentelemetry 可以说是含着金汤匙出生：OpenTracing 支持，OpenCensus 支持，刚开始就自带经验丰富的的社区人员，同时背后也有互联网巨头的支持。

Opentelemetry 的目标

Opentelemetry 旨在构建包含 Trace，metrics 和 Logging 的分布式追踪方案，它提供了统一的标准，提供了 Java Agent 解决方案，提供了 Collector 的实现等等，后续的系列文章中我会将这些一一进行介绍。

、

总结

这是我的 Opentelemetry 系列文章的第一篇，主要是介绍一些分布式追踪的往事和 Opentelemetry 诞生的历史。后续我会从 Opentelemetry 的相关使用，原理，体系来发布一系列文章，敬请期待。

参考文章

[1] https://www.cncf.io/blog/2019/05/21/a-brief-history-of-opentelemetry-so-far/

[2] https://www.cncf.io/blog/2021/08/26/opentelemetry-becomes-a-cncf-incubating-project/

[3] Dapper, a Large-Scale Distributed Systems Tracing Infrastructure

[4] https://bigbully.github.io/Dapper-translation/

[5] https://developers.redhat.com/blog/2019/05/01/a-guide-to-the-open-source-distributed-tracing-landscape