关于云计算:基础篇丨链路追踪Tracing其实很简单

一、分布式链路追踪的起源

当周末躺在被窝里，点外卖时；双 11 的零点，疯狂提交订单时；假期和基友激情开黑，五杀超神…在这个精彩纷呈的互联网世界里，这些利用背地又暗藏着什么？每一次点击行为在 IT 世界里会流经哪些节点，调用哪些服务，带来哪些变动？这所有庞杂且精细，超出了人力摸索的边界，而分布式链路追踪就是追溯申请在 IT 零碎间流转门路与状态的一门技术。接下来，让咱们通过对分布式链路追踪的来理解这个 IT 世界！

说到分布式链路追踪，就绕不开分布式系统与微服务的衰亡。晚期 IT 零碎非常简单，简直所有程序都运行在同一个节点，相互之间也没有什么依赖。但随着硬件技术突飞猛进，硬件老本大幅降落，软件复杂度却越来越高。繁多零碎性能无奈满足简单的数据计算工作，而软件逻辑的复杂性也导致保护老本大幅回升。另外，单节点的可靠性也难以保障，不可避免的会偶然呈现宕机等行为，影响软件的可用性。“性能、可维护性和可用性”这三大因素促使了分布式系统与微服务的诞生。

为了解决上述问题，人们很天然想到：既然一个硬件节点无奈很好的运行软件，那能不能够通过多个节点来共同完成？并且为不同节点分派不同工作去提高效率。就好比通过不同角色分工协同的汽车生产流水线，分布式系统与微服务的理念亦是如此，如下图所示。

分布式系统与微服务自诞生就被广泛应用，次要得益于以下劣势：

• 扩展性

分布式系统人造具备“按需扩大”的能力，比方双 11 大促前通过增加机器实现疾速程度扩容，大促完结后开释机器，充分利用云计算的分时复用能力，节约老本。利用微服务，还能够实现按需精准扩容，比方登录服务扩容 10 倍，下单服务扩容 3 倍，最大化的节俭资源。

• 可靠性

分布式系统能够无效抵制“单点危险”，不会因为某一个节点的故障，影响整体的服务可用性。联合流量调度、离群实例摘除和弹性扩容等技术，甚至能够实现故障自愈。

• 可维护性

分布式系统可维护性更强，一方面咱们将一个简单服务拆分成多个简略的微服务，每个微服务的逻辑都更加清晰、更易了解。就好比咱们写代码，将一个几百行的简单函数重形成若干个简略函数，代码可读性就会直线回升。另一方面，一些通用的微服务能够被高度复用，无需反复开发和保护，比方你在开发一个电商 APP，能够间接调用第三方提供的领取、物流等服务接口，整体开发和保护效率将大幅晋升。

尽管分布式系统与微服务具备十分显著劣势，但凡事无利必有弊，它们在无效解决原有问题根底上，也为零碎开发和运维带来了新挑战，次要包含以下几点：

• 模糊性

随着零碎的分布式水平越来越高，异样表象与根因之间的逻辑联系变得更加含糊，问题诊断的难度急剧回升。比方 A、B 两个服务共享同一个数据库实例，当 A 服务在压测期间，大量占用数据库的服务端连贯和计算资源，会导致 B 服务呈现连贯超时或响应变慢等问题。如果 B 服务是通过 C 服务间接依赖该数据库实例，问题的定位就会变得更加艰难。

• 不统一

尽管分布式应用从总体上变的更加牢靠，然而每一个独立节点的状态却难以保障。导致这种不统一的起因有很多，比方前文提到的单机故障这种预期外的不统一，或者利用 Owner 执行分批公布或流量灰度时导致的预期内行为不统一。这种不一致性导致咱们难以确定一个用户申请在零碎内的精确执行门路与行为逻辑，可能引发不可预知的逻辑劫难。

• 去中心化

当你的零碎领有上千个微服务镜像运行在数百台机器实例上，你该如何梳理它们之间的依赖关系，又该如何找到外围业务的要害执行门路？特地是在分布式的场景下，你没有一个中心化的节点（Master）来保留每个服务之间的依赖与调度状态，每个独立节点都在自行其是，无奈分辨本人在整个零碎中的地位，只能“盲人摸象、管中窥豹”，不足全局视图。

分布式系统与微服务带来的新挑战无疑让人头痛，但也带来了新技术的倒退契机，科技的倒退总是这样周而复始，螺旋式回升。它们带来的新问题，促使了分布式链路追踪的诞生，使你可能无效的察看全局，追踪流量。咱们将在下个章节理解分布式链路追踪的诞生历程与核心理念。

二、分布式链路追踪的诞生

为了应答分布式环境下的不统一、模糊性等前文提到的各类问题问题，人们试图通过申请粒度的轨迹追踪与数据透传，实现节点间的确定性关联，分布式链路追踪技术也由此诞生。

里程碑事件：Google Dapper

分布式链路追踪诞生的标志性事件就是 Google Dapper 论文的发表。2010 年 4 月，Benjamin H. Sigelman 等人在 Google Technical Report 上发表了《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，揭开了分布式链路追踪的技术大幕，开启了一段全新技术浪潮。

Dapper 首先明确了分布式链路追踪的两个指标：任意部署和继续监测。进而给出了三个具体的设计准则：

• 低开销：确保外围零碎不会因为额定的性能开销回绝应用。
• 利用级通明：对利用开发通明，无需开发人员的帮助，升高接入门槛，进步迭代效率。
• 可扩大：在将来相当长一段时间内，随着业务的高速倒退，依然能够无效运行。

上面几张图展现了 Dapper 对链路透传、调用链构造和数据采集流程的形容，咱们将在后续章节具体开展介绍，对 Dapper 感兴趣的同学倡议间接浏览原作。

Dapper 论文有两个重要的意义，一是具体论述了分布式链路追踪的设计理念，为起初的实现者提供了重要的理论指导；二是通过 Dapper 在 Google 生产环境的大规模落地实际，证实了分布式链路追踪技术的企业级价值，为分布式链路追踪的推广作出了不可磨灭的奉献。

基本原理

分布式链路追踪并不是无中生有、凭空诞生的新概念，而是轨迹追踪在 IT 畛域的又一次胜利使用。轨迹追踪理念早已被广泛应用于社会生存方方面面，比方物流订单追踪。一个快递包裹在发件站被赋予快递单号，沿途直达节点会记录该快递达到工夫等信息，而用户通过快递单号就能够查问本人的包裹路径了哪些站点，耗时多久，是否存在滞留或丢件状况。下表比照了物流追踪与链路追踪的关联与差异性，以便大家了解。

分布式链路追踪的基本原理就是在分布式应用的接口办法上设置一些观察点（相似快递中转站记录点），而后在入口节点给每个申请调配一个全局惟一的标识 TraceId（相似快递单号），当申请流经这些观察点时就会记录一行对应的链路日志（蕴含链路惟一标识，接口名称，工夫戳，主机信息等）。最初通过 TraceId 将一次申请的所有链路日志进行组装，就能够还原出该次申请的链路轨迹，如下图所示。

分布式链路追踪实现申请回溯的关键点有两个：一是低成本、高质量的观察点设置，也就是链路插桩，确保咱们追踪的信息足够丰盛，可能疾速定位异样根因；二是保障链路上下文在不同环境下都可能残缺透传，避免出现上下文失落导致的断链景象。对于链路插桩和上下文透传的具体内容咱们将在实战篇进行具体介绍。上面，咱们来看一个高速公路例子，进一步加深对链路追踪实现原理的意识。

一辆汽车飞驰在高速公路上

小明、小红、小玉打算在“五一”期间去自驾游，他们的游览路线各不相同。如果咱们想追踪他们的行程轨迹与工夫该如何实现？

可能你会倡议在每辆车上装置一个追踪器。的确，这是一种卓有成效的办法。但当出行车辆扩大到全国数以十亿计的规模，装置追踪器老本就会很高。此时咱们换个角度思考，高速公路的路线是固定的，每隔一段距离就会有一个收费站，如果咱们在每个收费站上装置监控，记录车辆在每个收费站的轨迹与工夫，就能够很经济的实现车辆轨迹与行驶工夫的追踪。最终，咱们失去了如下行程记录：

如果咱们将每个游客替换为服务申请，收费站替换为服务接口，那咱们就能够失去每次申请在分布式系统中的调用轨迹与状态，这就是分布式链路追踪的含意。

根底术语

尽管分布式链路追踪的实现形式多种多样，不同开源或商业化产品都有本人的数据模型和定义。然而依然有一些根底术语在业界具备宽泛的共识，以 OpenTracing 为例。

Trace

一条 Trace 代表一次入口申请在 IT 零碎内的残缺调用轨迹及其关联数据汇合。其中，全局惟一的链路标识 TraceId，是最具代表的一个属性。通过 TraceId 咱们能力将同一个申请扩散在不同节点的链路数据精确的关联起来，实现申请粒度的“确定性关联”价值。这也是 Trace 区别于 Metrics、Log 其余两类可观测技术的要害属性。

Span

光有 TraceId 还不够，申请在每一跳的接口办法上执行了什么动作，耗时多久，执行状态是胜利还是失败？承载这些信息的根底对象就是 Span。通常一个残缺的 Span 具备如下属性：

• Operation Name：形容了以后接口的行为语义，比方 /api/createOrder 代表执行了一次创立订单的动作。
• SpanId/ParentSpanId：接口调用的层级标识，用于还原 Trace 外部的档次调用关系。
• Start/FinishTime：接口调用的开始和完结工夫，二者相减就是该次调用的耗时。
• StatusCode：响应状态，标识当次调用是胜利或失败。
• Tags & Events：调用附加信息，详见上面的形容。

Tags

SpanName 的形容通常是高度形象的，仅仅答复这个接口是做什么的。如果须要进一步记录申请的行为特色，能够应用 Tags 来扩大语义。Tags 是一组由 {Key:Value} 组成的键值对汇合，形容这一次接口调用的具体属性，比方将 UserType 增加到 Tags 中，就能够察看某一类用户（比方 VIP 用户）的链路行为状态。如果将设施类型加到 Tags 中，能够比照不同设施的性能差别。

因为 Tags 只反对结构化的 KV 键值对，因而，它能够作为标签增加到聚合后的链路指标中，无效晋升监控告警的数据精度。更精确的答复异样或性能问题产生的起因，比方集中在某个地区、设施或版本。

Logs

Tags 会随着链路上下文主动向上游透传，如果心愿记录一些不须要透传的事件信息，能够应用 Logs 字段。每个 Span 都能够进行屡次 Logs 操作，但每个 Logs 对象都须要带有一个工夫戳，Logs 的内容能够是非结构化的简单对象。为了节省成本，个别不会对 Logs 字段建设索引，也不反对 Logs 的查问或统计，仅仅作为附加信息关联在调用链上，用于单申请诊断。

下图展现了一个 OpenTracing 的 Span 示例，不同开源实现的链路模型咱们将在后续章节再开展介绍。

分布式链路追踪曾经被广泛应用于中大型企业的 IT 运维畛域，为分布式应用的性能诊断与稳定性保障提供了无效的帮忙。此外，分布式链路追踪的开源和商业化生态也倒退迅猛，大量独立服务商或云厂商纷纷跟进，独特推动了分布式链路追踪技术的崛起。

三、分布式链路追踪的利用

广义上分布式链路追踪（Tracing）是指跟踪申请在分布式系统中的流转门路与状态，主要用途是帮助开发运维人员进行故障诊断、容量预估、性能瓶颈剖析与调用链路梳理等工作。技术实现上蕴含了数据埋点、采集、存储、剖析、可视化等环节，造成了一套残缺的技术体系。

而更狭义的分布式链路追踪，则涵盖了由数据透传能力衍生的生态系统，比方全链路压测、微服务流量路由、业务场景链路拆分等。咱们能够为调用链路赋予业务语义，也能够将一次调用生命周期内的所有数据进行关联整合，不再局限于链路数据自身。

由此可见，分布式链路追踪的利用场景广大，后劲微小，它的外围属性就是“关联”。然而，分布式链路追踪（Tracing）绝对于统计指标（Metrics）和利用日志（Logging）来说更加难以了解，不容易使用，更难用好。接下来，咱们通过一个活泼形象的例子，理解下分布式链路追踪的经典用法，加深对它的技术实质的把握。

游客、收费站和交通局

分布式链路追踪的用法有很多，但最经典、最罕用的有三种，还是以上一节的高速公路为例，不同角色对应着不同的用法。

• 游客，只关怀本身的行程路线，须要途经哪些收费站点？行驶工夫有多长？沿途是否有拥挤或危险路段等。
• 收费站，只关怀本身站点的状态，比方站点吞吐量、均匀过闸工夫等，以便于提前安顿检票口值班人数。
• 交通局，会将所有的出行记录汇总，提前估算整个高速公路网的出行流量、易拥挤路段、事变多发路段等，以便于提前畅通或加固问题路段，并给出正当的倡议出行路线，有时还须要提前制订车辆限流策略等。

分布式链路追踪的利用和行程轨迹追踪相似，游客关怀的是单次申请的轨迹回溯，收费站关注的是服务接口维度的汇总统计，旅游局则相似全局链路拓扑梳理。

单申请轨迹回溯单

申请轨迹回溯是分布式链路追踪最根底的性能，它记录了一次申请通过的所有服务节点以及对应的节点状态信息（接口名称、耗时、状态码等），这就好比记录了游客自驾游时通过的所有收费站，以及沿途的路况与行驶工夫等信息。

单申请轨迹回溯是诊断特定申请异样 / 超时起因的无效伎俩，能够疾速定位异样节点（拥挤的收费站）。比拟成熟的 Tracing 产品（比方阿里云的利用实时监控服务 ARMS）除了根底的链路数据外，还会记录申请出入参、本地办法栈、关联 SQL 与异样堆栈等信息。这些细节信息就好比车辆的型号大小、驾驶员驾龄、是否醉酒、沿途每一路段的具体路况等，当调用不合乎预期（行程异样）时，就能够精准的定位根因，如下图所示：

ARMS：https://help.aliyun.com/document_detail/64995.html

服务监控

如果你是收费站的站长，你会关注哪些信息？收费站的车辆吞吐量？均匀的过闸工夫？车辆的起源与去向？同理，每一个服务节点，将途经的所有调用信息汇总后，就能够失去以后服务接口的吞吐量、耗时、起源与去向等统计指标。这些指标能够帮忙咱们疾速辨认以后服务的衰弱状态。在理论生产零碎中，还能够与告警零碎联合，实现危险的疾速辨认与解决，升高业务损失。

链路拓扑

如果你是交通局的局长，你可能会关注全国高速公路网的整体运行状态，有哪些易拥挤或事变多发路段与站点，如何确保春运高峰期外围路段运行通顺，不会呈现重大交通瘫痪事件等等。此时，你须要对所有的车辆行程轨迹进行汇总剖析。

同理，链路拓扑就是将全局或某一入口服务的所有调用链路进行汇总，聚合为链路拓扑大图，进而剖析以后链路的性能瓶颈点、易故障点等，提前进行性能优化或危险防控，还能够依据历史流量来领导将来（比方双 11 大促）的容量评估。

分布式链路追踪的倒退现状

截止到 2021 年，分布式链路追踪（Tracing）曾经成为支流软件架构不可或缺的根底技术之一，它与指标（Metrics）、日志（Logging）并称为可观测畛域的“三驾马车”，它们三者之间的关系如下图所示：

随着 Kubenetes 容器技术与云计算的遍及，将来的软件架构会更加趋势分布式云、微服务化的方向，软件开发、部署老本将大幅降落，然而系统维护和问题诊断的难度却急剧回升。因而，分布式链路追踪以及由它提供的“确定性关联”价值将更加凸显，如下图所示：

Tracing 在开源社区也颇受青睐，领有着旺盛的生命力，支流的开源规范包含 OpenTelemetry、OpenTracing、OpenCensus 和国内应用较多的 SkyWalking。其余影响力较强的实现还包含 Jaeger、Zipkin、Pinpoint 等，如下图所示。

在商业化畛域，Tracing 与 APM（Application Performance Mornitoring）亲密绑定，绝大部分厂商会面向利用视角提供更加全面、易用的 APM 服务，而不仅仅是 Tracing 服务。参考 2021 年 Gartner 评测机构给出的 APM 魔力象限，能够大抵评估各大厂商的 APM 与 Tracing 产品能力，如下图所示。

截止 2021 年，阿里巴巴 98% 的 Java 利用（上万级别）均已接入外部自研的分布式链路追踪零碎 EagleEye；阿里云上有近万家企业在继续应用 ARMS 提供的分布式链路追踪服务。而从整个业界来看，无论是谷歌、亚马逊这样的国内大厂，还是新兴的互联网公司，或是传统企业，都在大规模接入和利用分布式链路追踪技术，Tracing 生态正在蓬勃发展。

四、分布式链路追踪的挑战与限度

作为一门“新”技术，分布式链路追踪的技术演进史并不算长，仅有十数年。目前，它仍处于一直被摸索、疾速迭代的周期。为了更好的理解与利用分布式链路追踪技术，咱们来看下它目前面临的几项要害挑战与限度。

要害挑战与应答

分布式链路追踪技术从诞生到大规模利用，两头经验了一段较长的蛰伏期，直到近几年才逐步被大家宽泛承受和认可。影响其疾速推广的要害挑战包含如下几点：

• 后期建设老本高

无论是在不同组件接口上进行插桩埋点，还是保障链路上下文可能正确流传，亦或是搭建一套稳固牢靠的链路数据后端解决零碎，都不是一件易事，须要投入大量的研发人力。

• 数据处理老本高

因为链路数据与申请流量成正比，每一次申请都会记录相应的链路日志，当零碎流量爆炸式增长，相应的链路数据生成、采集、解决、存储、查问的老本也会急剧回升，带来微小的 IT 资源开销。

• 价值没有失去广泛认可

根底的链路数据仅仅表白了接口间的调用依赖，没有开释足够的业务价值，难以失去领导和共事们的全力支持。

• 链路规范不对立

分布式链路追踪倒退后期没有对立的业界规范，各家厂商百花齐放，尽管肯定水平上促成 Tracing 技术的多元化摸索，但也为链路交融、迁徙和推广带来了微小的挑战。

当然，挑战同样也是时机，为了应答上述问题，分布式链路追踪近几年实现了如下技术冲破。

• 无侵入探针 + 一体化解决方案

相似 JavaAgent 的探针插桩技术，实现了 0 代码入侵，0 革新老本的链路主动埋点，而相似 SkyWalking 的开源实现还提供了端到端的一体化解决方案，从链路数据生成到最初的可视化，中小企业能够疾速搭建并享受到分布式链路追踪技术的价值，大幅升高了 Tracing 的后期建设老本和接入门槛。

• 链路采样 + 边缘计算

链路采样策略，例如固定比例采样、限流采样、错慢全采、自定义标签采样等，能够大幅升高链路数据的传输、解决、存储老本；联合用户网络内的指标聚合，长文本编码 / 压缩等边缘计算技术，能够正当管制分布式链路追踪的数据老本，保障链路零碎继续衰弱运行。

• 关联剖析 + 立体化可观测

单条链路的价值难以凸显，然而基于成千上万条链路的聚合 / 关联剖析却能疾速定位，导致系统异样的关键因素，比方版本、地区、用户类型等。同时，联合业务、容器、基础设施等其余层面的可观测数据，建设一套端到端、立体化的可观测体系，可能更加无效地开释分布式链路追踪的技术价值。

• 开源规范趋势对立

自从 2019 年 OpenTelemetry 开源立项，失去了两大支流开源实现 OpenTracing 和 OpenCensus 的大力支持，开启了可观测性的新时代。尽管，目前 OpenTelemetry 仅在 Tracing 畛域领有比较完善的技术标准，Metrics 和 Logging 仍在摸索阶段，然而可观测性“三驾马车”交融一统的趋势曾经势不可挡。将来基于对立欠缺的可观测数据规范，分布式链路追踪的“确定性关联”将失去更加宽泛的利用。

现阶段能力限度

分布式链路追踪现有的模型设计与实现，能够无效满足许多经典场景的分布式诊断诉求。然而，依然有大量场景超出了现阶段分布式链路追踪的能力领域，须要咱们去摸索更好的计划。

树形 YES！图形 NO！

前文介绍了分布式链路追踪是通过 ParentSpanId 和 SpanId 来标识依赖关系，从而精确还原链路层级与程序。然而，每个 Span 有且仅有一个 ParentSpanId，这就限度了所有链路状态只能是单个父节点的树形构造，而不能是多个父节点的图形构造。

某些零碎为了提供反复调用的效率，会将屡次 RPC 调用打包成一次 RPC 调用合并发送，这种入度大于 1 的图形构造，就无奈通过调用链实在还原调用状态，而是会被拆成多条调用链，如下图所示：

人工插桩 YES！智能插桩 NO！

无论是 SDK 或是 Agent 模式，目前工业界的链路插桩次要是依赖人工发现插桩点并实现插桩过程，很难通过算法自适应的实现插桩点的智能发现。然而，学术界在这方面曾经进行了一些有意思的摸索，尽管在性能开销、平安等方面还不够成熟，然而值得关注。

2019 年波士顿大学发表了一篇钻研智能插桩的文章，他们实现的 Pythia 原型零碎针对性能进化问题，能够主动发现更有价值的外部插桩点。例如，咱们在申请一个存储系统时，可能会间接命中缓存疾速返回后果，也可能未命中缓存导致加载磁盘破费了较多工夫。咱们仅在 RPC 层面进行插桩，只能看到申请耗时高下起伏，出现一种双峰式的散布，但无奈确认根因是什么。Pythia 通过比对剖析不同的链路数据，会主动发现影响性能的潜在插桩点，比方慢申请可能会额定调用一次 fetchFromDisk 办法，从而更清晰的解释影响申请耗时的根因，如下图所示。

分布式链路追踪的能力限度远不止以上两种场景，在离线剖析、机器学习等多个畛域也期待咱们去摸索攻克。咱们既要充分发挥现有的分布式链路追踪技术价值，解决当下的企业运维艰难；同时也要把视线放宽，在将来更多的畛域中去拓展分布式链路追踪的边界。

作者：涯海

原文链接

本文为阿里云原创内容，未经容许不得转载。