基础篇丨链路追踪（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 将一次恳求的一切链路日志进行拼装，就能够复原出该次恳求的链路轨道，如下图所示。

散布式链路追寻完成恳求回溯的要害点有两个：一是低本钱、高质量的调查点设置，也便是链路插桩，保证咱们追寻的信息足够丰富，能够快速定位反常根因；二是保证链路上下文在不同环境下都能够完好透传，避免呈现上下文丢掉导致的断链现象。关于链路插桩和上下文透传的具体内容咱们将在实战篇进行具体介绍。下面，咱们来看一个高速公路比方，进一步加深对链路追寻完成原理的认识。

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

小明、小红、小玉计划在“五一”期间去自驾游，他们的旅游道路各不相同。假如咱们想追寻他们的行程轨道与时刻该怎么完成？

或许你会建议在每辆车上装置一个追寻器。的确，这是一种行之有用的办法。但当出行车辆扩展到全国数以十亿计的规模，装置追寻器本钱就会很高。此刻咱们换个视点考虑，高速公路的道路是固定的，每隔一段间隔就会有一个收费站，假如咱们在每个收费站上装置监控，记载车辆在每个收费站的轨道与时刻，就能够很经济的完成车辆轨道与行进时刻的追寻。最终，咱们得到了如下行程记载：

游客	行程道路	行进间隔	行进时刻
小明	北京 -> 石家庄 -> 郑州 -> 西安	1140 公里	13 小时 34 分钟
小红	北京 -> 天津 -> 济南 -> 南京 -> 杭州	1280 公里	14 小时 33 分钟
小玉	北京 -> 天津 -> 济南 -> 南京 -> 上海	1234 公里	13 小时 53 分钟

假如咱们将每个游客替换为服务恳求，收费站替换为服务接口，那咱们就能够得到每次恳求在散布式体系中的调用轨道与状况，这便是散布式链路追寻的含义。

根底术语

尽管散布式链路追寻的完成方式多种多样，不同开源或商业化产品都有自己的数据模型和界说。可是仍然有一些根底术语在业界具有广泛的共识，以 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：调用附加信息，详见下面的描绘。

Logs

Tags 会跟着链路上下文主动向下游透传，假如期望记载一些不需求透传的事情信息，能够运用 Logs 字段。每个 Span 都能够进行多次 Logs 操作，但每个 Logs 目标都需求带有一个时刻戳，Logs 的内容能够对错结构化的杂乱目标。为了节约本钱，一般不会对 Logs 字段建立索引，也不支撑 Logs 的查询或核算，只是作为附加信息相关在调用链上，用于单恳求确诊。

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

散布式链路追寻现已被广泛运用于中大型企业的 IT 运维范畴，为散布式运用的功能确诊与安稳性保障供给了有用的协助。此外，散布式链路追寻的开源和商业化生态也开展迅猛，许多独立服务商或云厂商纷繁跟进，一起推动了散布式链路追寻技能的崛起。

三、散布式链路追寻的运用

狭义上散布式链路追寻（Tracing）是指跟踪恳求在散布式体系中的流通途径与状况，主要用途是协助开发运维人员进行毛病确诊、容量预估、功能瓶颈剖析与调用链路整理等作业。技能完成上包含了数据埋点、收集、存储、剖析、可视化等环节，形成了一套完好的技能体系。

而更广义的散布式链路追寻，则涵盖了由数据透传才干衍生的生态体系，比方全链路压测、微服务流量路由、事务场景链路拆分等。咱们能够为调用链路赋予事务语义，也能够将一次调用生命周期内的一切数据进行相关整合，不再局限于链路数据本身。

由此可见，散布式链路追寻的运用场景广阔，潜力巨大，它的中心特点便是“相关”。可是，散布式链路追寻（Tracing）相对于核算目标（Metrics）和运用日志（Logging）来说更加难以理解，不容易运用，更难用好。接下来，咱们经过一个生动形象的比方，了解下散布式链路追寻的经典用法，加深对它的技能本质的把握。

游客、收费站和交通局

散布式链路追寻的用法有许多，但最经典、最常用的有三种，仍是以上一节的高速公路为例，不同角色对应着不同的用法。

游客，只关怀本身的行程道路，需求途经哪些收费站点？行进时刻有多长？沿途是否有拥堵或危险路段等。
收费站，只关怀本身站点的状况，比方站点吞吐量、均匀过闸时刻等，以便于提早组织检票口值班人数。
交通局，会将一切的出行记载汇总，提早估算整个高速公路网的出行流量、易拥堵路段、事故多发路段等，以便于提早疏通或加固问题路段，并给出合理的建议出行道路，有时还需求提早制定车辆限流战略等。

散布式链路追寻的运用和行程轨道追寻相似，游客关怀的是单次恳求的轨道回溯，收费站重视的是服务接口维度的汇总核算，旅游局则相似大局链路拓扑整理。

单恳求轨道回溯

单恳求轨道回溯是散布式链路追寻最根底的功能，它记载了一次恳求经过的一切服务节点以及对应的节点状况信息（接口称号、耗时、状况码等），这就比方记载了游客自驾游时经过的一切收费站，以及沿途的路况与行进时刻等信息。单恳求轨道回溯是确诊特定恳求反常/超时原因的有用手法，能够快速定位反常节点（拥堵的收费站）。

比较老练的 Tracing 产品（比方阿里云的运用实时监控服务ARMS）除了根底的链路数据外，还会记载恳求收支参、本地办法栈、相关 SQL 与反常仓库等信息。这些细节信息就比方车辆的类型大小、驾驶员驾龄、是否醉酒、沿途每一路段的具体路况等，当调用不符合预期（行程反常）时，就能够精准的定位根因，如下图所示：

ARMS：

help.aliyun.com/document_de…

服务监控

假如你是收费站的站长，你会重视哪些信息？收费站的车辆吞吐量？均匀的过闸时刻？车辆的来历与去向？同理，每一个服务节点，将途经的一切调用信息汇总后，就能够得到当时服务接口的吞吐量、耗时、来历与去向等核算目标。这些目标能够协助咱们快速识别当时服务的健康状况。在实际出产体系中，还能够与告警体系结合，完成危险的快速识别与处理，降低事务损失。

链路拓扑

假如你是交通局的局长，你或许会重视全国高速公路网的整体工作状况，有哪些易拥堵或事故多发路段与站点，怎么保证春运高峰期中心路段工作晓畅，不会呈现严重交通瘫痪事情等等。此刻，你需求对一切的车辆行程轨道进行汇总剖析。

同理，链路拓扑便是将大局或某一进口服务的一切调用链路进行汇总，聚合为链路拓扑大图，从而剖析当时链路的功能瓶颈点、易毛病点等，提早进行功能优化或危险防控，还能够根据历史流量来辅导未来（比方双 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 办法，从而更明晰的解说影响恳求耗时的根因，如下图所示。

散布式链路追寻的才干约束远不止以上两种场景，在离线剖析、机器学习等多个范畴也等待咱们去探究霸占。咱们既要充分发挥现有的散布式链路追寻技能价值，处理当下的企业运维困难；同时也要把视界放宽，在未来更多的范畴中去拓展散布式链路追寻的边界。

五、预告

在完好介绍散布式链路追寻的前世今生以及根底概念之后，在接下来的章节咱们将经过实际运用场景，具体介绍散布式链路追寻的根底用法，包含：

恳求轨道回溯
多维链路挑选
链路实时剖析、监控与告警
链路拓扑

基础篇丨链路追踪（Tracing）其实很简单