以 Dapper、Zipkin 和 LightStep [x]PM 为例阐述分布式跟踪的过去、现在和未来

核心要点

• 在观测分布式系统和微服务时，分布式跟踪已经成为一个越来越重要的组件。现在有一些流行的开源标准和框架，比如 OpenTracing API 和 OpenZipkin；
• 分布式跟踪的基本理念是非常简单直接的：在系统中，特定请求的转折点必须要识别出来并且要检测。所有的跟踪数据需要协调和整理，为请求提供一个有意义的流视图；
• 请求跟踪在理念上类似于应用性能管理（Application Performance Management，APM），这两个生态系统都面临一个挑战，那就是不断增长的大规模系统所生成的大量数据；
• Google 在实现其分布式监控系统 Dapper 时解决了这个问题，他们采取的方式是采样跟踪，一般是 1000 个请求中采样 1 个请求，但是现代的商业跟踪产品都宣称能够分析 100% 的请求。

在观测分布式系统和微服务时，分布式跟踪成为一个越来越重要的组件。本文将会介绍该技术，让读者对其有一个整体的了解，首先我们会探讨一下 Google 的 Dapper 请求跟踪论文，该论文反过来促成了 Zipkin 和 OpenTracing 项目的创建，随后我们会与 Ben Sigelman 讨论一下请求跟踪的未来，他是新的 LightStep [x]PM 跟踪系统的创建者。

正如最初的 Dapper 论文所述，现代互联网服务通常实现为复杂的大规模系统，比如采用流行的微服务架构模式。应用是由一组服务组合起来的，这些服务可能是由不同的团队开发的，而且可能采用不同的编程语言。在 Google 这种级别，应用会跨越多个基础设施的上千台机器，即便是相对较小的云计算用例，推荐的做法也是使用跨地域的“availability zone”和“region”运行服务的多个版本。在这种复杂的系统和环境中，能够辅助我们理解系统的行为、帮助调试和排查性能问题的工具是非常有价值的。

分布式跟踪的基本理念是非常简单直接的：在系统、应用、网络以及中间件中，请求（一般是用户发起的）路径上的每个转折点，甚至可以说每个点必须要识别并检测（instrument）。这些点有着特殊的意义，因为它们通常代表了执行流上的分支，比如使用多个线程并行处理、进行异步计算或者发起进程外的网络调用。这些独立生成的跟踪数据必须要收集、协调和整理，在系统范围内为请求提供一个有意义的流视图。 Cindy Sridharan 提供了一个非常有用的指南，该指南探讨了请求跟踪的基本原理，并将这项技术应用于现代监控和“可观察性（observability）”的两大支柱之中：日志和指标收集。

剖析Trace

按照云原生计算基金会（Cloud Native Computing Foundation，CNCF）的 OpenTracing API 项目的定义， trace 能够告诉我们事务或工作流在整个系统的传播过程中经历的所有事情。在 OpenTracing 和 Dapper 中，trace 是由“span”所组成的一个有向无环图（directed acyclic graph，DAG），在有些工具中“span”也被称为“segment”，比如在 AWS X-Ray 中。span 是一个带有名称和计时的操作，它代表了 trace 中一个持续的工作片段。被检测的组件还可以将额外的上下文注释（元数据或“ baggage ”）添加到 span 中，例如，应用开发人员可能会使用一个跟踪 SDK 添加任意的 key-value 条目到当前的 span 中。需要注意的是，添加注释数据会带来内在的侵入性：添加注释的组件必须要感知跟踪框架的存在性。

Trace 数据一般会“按照不同的频道（out of band）”进行收集，并写入到本地数据文件中（由 agent 或 daemon 来生成），然后通过单独的网络进程拉取到中心化的存储中，这与当前日志和指标收集的做法非常类似。Trace 数据不会添加到请求本身上，因为这样能够保持请求的大小和语义不发生变化，本地存储的数据会在方便的时候被拉取到出来。

当请求初始化的时候，将会生成一个“parent” span，该 span 可以与多个“child” span 建立具有因果关系和临时的关联。图 1 来源于 OpenTracing 的文档，以可视化的方式展现了一个请求流中一系列的 span 及其关联关系。这种类型的可视化会添加一些上下文信息，包括时间、服务调用的层级以及进程 / 任务执行的串行或并行性。这种视图能够突出显示系统的关键路径，并且为我们提供了一个起点，让我们识别瓶颈以及需要提升的地方。很多分布式跟踪系统还提供了 API 或 UI，实现对 span 细节的进一步“钻取”。

图1 按照请求的生命线，以一系列span 的形式可视化基本的跟踪（图片来源于 OpenTracing 文档）

实现分布式跟踪所面临的挑战

在历史上，为各种类型的分布式系统实现分布式跟踪会面临很多挑战。例如，使用多种编程语言实现的微服务架构可能并没有共享通用的检测点。Google 和 Twitter 分别创建了 Dapper 和 Zipkin 来实现跟踪，这相对较为简单，因为它们大多数的跨进程（跨服务）通信是通过同质的 RPC 框架完成的，Google 创建了 Stubby （它的一个开源变种就是 gRPC ），Twitter 则创建了 Finagle 。

Dapper 论文明确跟踪的价值只能通过如下的方式才能体现出来：（1）广泛部署，也就是系统的所有组成部分都要纳入检测，不能出现“黑点（dark）”；（2）持续监控，也就是系统必须要一直处于监控之中，因为感兴趣的异常事件通常难以再现。

“service mesh”网络代理的流行程度正在不断上升，比如 Envoy 、 Linkerd 和 Conduit （以及关联的控制层，如 Istio ），它们可能会推进多类型分布式系统中跟踪功能的采用，因为它们能够提供缺失的通用检测点。Sridharan 在它的 Medium 博客文章中详细讨论了可见性的问题：

“Lyft 为所有的应用提供了跟踪支持，通过采用service mesh 模式[使用Envoy 代理]，无需更改一行代码。Service mesh 能够帮助实现可见性，这是通过在mesh 级别实现跟踪和状态收集做到的，它允许我们将单个服务视为黑盒，但是依然能够在整个mesh 级别实现非常棒的可见性”;

对速度的需求：请求跟踪与APM

Web 页面的加载速度会极大地影响用户的行为和转变。Google 使用其搜索引擎运行了一个延迟实验，他们发现如果将结果页面的展现增加100 到400 毫秒的延迟，将会显著影响用户执行搜索的次数。Greg Linden 提到，在2006 年Amazon.com 运行了一个实验，如果页面加载的延迟增加100 毫秒，将会造成收入的大幅下降。尽管理解整个系统中Web 请求的流程非常具有挑战性，但是识别和消除性能瓶颈会带来显著的商业收益。

请求跟踪的理念类似于应用性能监控（Application Performance Management，APM），它们都与监控有关，并且都关系到软件应用的性能和可用性的管理。APM 的目标在于探查和诊断复杂应用的性能问题，达到预期的服务等级协议（Service Level Agreement，SLA）。现代软件架构的分布式特性在不断增加，APM 工具也进行了适配以监控（可视化）这种类型的软件。图2 展现了开源的 Pinpoint APM 工具的可视化界面，类似的视图在商业工具中也能见到，比如 Dynatrace APM 和 New Relic APM 。

图2 现代APM 工具中的跟踪（图片来源 Pinpoint APM GitHub 仓库）

在请求跟踪和 APM 领域都面临一项挑战，那就是大规模系统不断生成的大量数据。AWS 云架构战略（Cloud Architecture Strategy）的 VP Adrian Cockcroft 说到，公有云能够让大众更容易地使用强大且可扩展的基础设施和服务，但是监控系统必须要比被监控的系统 更加可用（也要更加可扩展）。Google 在实现Dapper 时通过采样跟踪解决了这个问题，一般是1000 个请求中采样1 个请求，他们发现通过这种比例依然能够生成有意义的观察结果。很多的工程师和思想领袖都在从事该领域的工作，包括可观察性平台Honeycomb 的CEO Charity Majors ，他们都相信监控数据的采样是非常重要的：

这非常简单：如果你不采样的话，就无法扩展。如果你认为这是一种有争议的说法的话，那么说明你还没有真正处理过大规模的可观察性，或者你之前做得非常糟糕和浪费。

InfoQ 最近参加了在美国奥斯汀举行的 CNCF CloudNativeCon ，并与 Ben Sigelman 进行了交流，他是 Dapper 论文的作者之一，同时也是 LightStep 的 CEO 和联合创始人，他最近宣布了一个新的商用跟踪平台“LightStep [x]PM”。Sigelman 讨论了LightStep 的非传统架构（它会在本地安装的agent 上使用机器学习技术），允许分析100.0% 的事务数据，而不是Dapper 所实现的0.01%：

“我们过去和现在依然构建的工具对长期的性能分析是非常重要的，但是为了应对被监控系统的规模，Dapper 只会中心化地记录0.01% 的性能数据，这意味着在特定的使用场景下，它是难以应对的，比如实时的事件响应（‘也就是最紧急的’）”。

LightStep 在过去的 18 个月中已经与很多客户合作过，包括 Lyft（使用 Envoy 代理作为集成点）、Twilio、GitHub 和 DigitalOcean，业已证明他们的方案能够处理大量的数据：

“Lyft 给我们发送了大量的数据，LightStep 每天分析 100,000,000,000 个微服务调用。乍一看上去，这是数据全是噪音，没有什么有用的信息：大量的数据混杂在一起并且不相关，但是通过全盘考虑，LightStep 能够衡量出性能是如何影响 Lyft 的不同方面的，然后使用端到端的跟踪展现问题和异常情况，这种跟踪能够从移动应用一直延伸到微服务技术栈的底部。”

LightStep [x]PM 目前可以作为 SaaS 平台来使用。Sigelman 想要强调的是，尽管可以分析 100% 的请求，但是在本地安装的 agent 所收集的数据并不会全部传送到中心化的平台中。Sigelman 将这个产品视为”新一代的 APM“工具，如果用户正在寻找针对复杂分布式应用的性能监控和自动分析的工具的话，那么它可以为用户带来价值。

结论

在分布式系统中，响应延迟可能会带来严重的商业影响，但是理解复杂系统中的请求流并识别瓶颈也是很有挑战性的任务。通过使用分布式跟踪，再结合其他的技术，如日志和监控指标，能够了解分布式应用的内部状况，这些应用可能是采用微服务的架构模式创建的。在分布式跟踪领域，开放的标准和工具正在不断组合，比如 OpenTracing API 和 OpenZipkin，商业的工具也在涌现，可能会与现有的 APM 供应商产生竞争。在为现代互联网服务实现分布式跟踪时，会面临一些挑战，比如处理大量的跟踪数据并生成有意义的输出，但是开源的生态系统和供应商正在应对这些挑战。

关于作者

Daniel Bryant 一直在组织内部和技术方面引领变化。他目前的工作包括通过引入更好的需求收集和计划技术推进企业内部的敏捷性，关注于敏捷开发中的架构关联性，并且搭建持续集成 / 交付环境。Daniel 现在的技术专长是“DevOps”工具、云 / 容器平台和微服务实现。他还是伦敦 Java 社区（LJC）的领导者，参与多个开源项目，为 InfoQ、DZone 和 Voxxed 这样的技术网站撰写文章，并且经常在 QCon、JavaOne 和 Devoxx 这样的国际会议上发表演讲。

查看英文原文： Distributed Tracing: Exploring the Past, Present and Future with Dapper, Zipkin and LightStep [x]PM