基础篇丨链路追踪（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：调用附加信息，详见下面的形貌。
  

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 方法，从而更清楚的解释影响请求耗时的根因，如下图所示。

分布式链路追踪的能力限制远不止以上两种场景，在离线分析、呆板学习等多个领域也等待我们去探索攻克。我们既要充分发挥现有的分布式链路追踪技能价值，解决当下的企业运维困难；同时也要把视野放宽，在未来更多的领域中去拓展分布式链路追踪的边界。
五、预报

在完整先容分布式链路追踪的宿世今生以及基础概念之后，在接下来的章节我们将通过实际使用场景，详细先容分布式链路追踪的基础用法，包罗：

• 请求轨迹回溯
  
• 多维链路筛选
  
• 链路实时分析、监控与告警
  
• 链路拓扑
  

更多内容，敬请期待！
点击此处了解更多产品体验

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。