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

by

• Daniel Bryant

摘要：

在观测分布式系统和微服务时，分布式跟踪已经成为一个越来越重要的组件。本文在总体上介绍了这项技术，内容包括：Google Dapper关于请求跟踪的论文；Zipkin和OpenTracing项目以及新的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