前后端多语言跨云部署，全链路追踪到底有多难？

Posted 2021-10-13 阿里系统软件技术

链路追踪能覆盖全部关联 IT 系统，能够完整记录用户行为在系统间调用路径与状态的最佳实践方案。完整的全链路追踪可以为业务带来三大核心价值：端到端问题诊断，系统间依赖梳理，自定义标记透传。

作者｜涯海

全链路追踪的价值

链路追踪的价值在于“关联”，终端用户、后端应用、云端组件（数据库、消息等）共同构成了链路追踪的轨迹拓扑大图。这张拓扑覆盖的范围越广，链路追踪能够发挥的价值就越大。而全链路追踪就是覆盖全部关联 IT 系统，能够完整记录用户行为在系统间调用路径与状态的最佳实践方案。

完整的全链路追踪可以为业务带来三大核心价值：端到端问题诊断，系统间依赖梳理，自定义标记透传。

• 端到端问题诊断：VIP 客户下单失败，内测用户请求超时，许多终端用户的体验问题，追根溯源就是由于后端应用或云端组件异常导致的。而全链路追踪是解决端到端问题最有效的手段，没有之一。
• 系统间依赖梳理：新业务上线，老业务裁撤，机房搬迁/架构升级，IT 系统间的依赖关系错综复杂，已经超出了人工梳理的能力范畴，基于全链路追踪的拓扑发现，使得上述场景决策更加敏捷、可信。
• 自定义标记透传：全链路压测，用户级灰度，订单追溯，流量隔离。基于自定义标记的分级处理&数据关联，已经衍生出了一个繁荣的全链路生态。然而，一旦发生数据断链、标记丢失，也将引发不可预知的逻辑灾难。

全链路追踪的挑战与方案

全链路追踪的价值与覆盖的范围成正比，它的挑战也同样如此。为了最大程度地确保链路完整性，无论是前端应用还是云端组件，无论是 Java 语言还是 Go 语言，无论是公有云还是自建机房，都需要遵循同一套链路规范，并实现数据互联互通。多语言协议栈统一、前/后/云（多）端联动、跨云数据融合是实现全链路追踪的三大挑战，如下图所示：

1、多语言协议栈统一

在云原生时代，多语言应用架构越来越普遍，利用不同语言特性，实现最佳的性能和研发体验成为一种趋势。但是，不同语言的成熟度差异，使得全链路追踪无法做到完全的能力一致。目前业界的主流做法是，先保证远程调用协议层格式统一，多语言应用内部自行实现调用拦截与上下文透传，这样可以确保基础的链路数据完整。

但是，绝大部分线上问题无法仅通过链路追踪的基础能力就能够有效定位并解决，线上系统的复杂性决定了一款优秀的 Trace 产品必须提供更加全面、有效的数据诊断能力，比如代码级诊断、内存分析、线程池分析、无损统计等等。充分利用不同语言提供的诊断接口，最大化的释放多语言产品能力是 Trace 能够不断向前发展的基础。

• 透传协议标准化：全链路所有应用需要遵循同一套协议透传标准，保证链路上下文在不同语言应用间能够完整透传，不会出现断链或上下文缺失的问题。目前主流的开源透传协议包括 Jaeger、SkyWalking、ZipKin 等。
• 最大化释放多语言产品能力：链路追踪除了最基础的调用链功能外，逐步衍生出了应用/服务监控，方法栈追踪，性能剖析等高阶能力。但是不同语言的成熟度导致产品能力差异较大，比如 Java 探针可以基于 JVMTI 实现很多高阶的边缘侧诊断。优秀的全链路追踪方案会最大化的释放每种语言的差异化技术红利，而不是一味的追求趋同平庸。感兴趣的同学可以阅读文章《开源自建/托管与商业化自研 Trace，如何选择》。

2、前后云（多）端联动

目前开源的链路追踪实现主要集中于后端业务应用层，在用户终端和云端组件（如云数据库）侧缺乏有效的埋点手段。主要原因是后两者通常由云服务商或三方厂商提供服务，依赖于厂商对于开源的兼容适配性是否友好。而业务方很难直接介入开发。

上述情况的直接影响是前端页面响应慢，很难直接定位到后端哪个应用或服务导致的，无法明确给出确定性的根因。同理，云端组件的异常也难以直接与业务应用异常划等号，特别是多个应用共享同一个数据库实例等场景下，需要更加迂回的手段进行验证，排查效率十分低下。

为了解决此类问题，首先需要云服务商更好的支持开源链路标准，添加核心方法埋点，并支持开源协议栈透传与数据回流（如阿里云 ARMS 前端监控支持 Jaeger 协议透传与方法栈追踪）。

其次，由于不同系统可能因为归属等问题，无法完成全链路协议栈统一，为了实现多端联动，需要由 Trace 系统提供异构协议栈的打通方案。

异构协议栈打通

为了实现异构协议栈（Jaeger、SkyWalking、Zipkin）的打通，Trace 系统需要支持两项能力：一是协议栈转换与动态配置，比如前端向下透传了 Jaeger 协议，新接入的下游外部系统使用的则是 ZipKin B3 协议。在两者之间的 Node.js 应用可以接收 Jaeger 协议并向下透传 ZipKin 协议，保证全链路标记透传完整性。二是服务端数据格式转换，可以将上报的不同数据格式转换成统一格式进行存储，或者在查询侧进行兼容。前者维护成本相对较小，后者兼容性成本更高，但相对更灵活。

3、跨云数据融合

很多大型企业，出于稳定性或数据安全等因素考虑，选择了多云部署，比如国内系统部署在阿里云，海外系统部署在 AWS 云，涉及企业内部敏感数据的系统部署在自建机房等。多云部署已经成为了一种典型的云上部署架构，但是不同环境的网络隔离，以及基础设施的差异性，也为运维人员带来了巨大的挑战。

由于云环境间仅能通过公网通信，为了实现多云部署架构下的链路完整性，可以采用链路数据跨云上报、跨云查询等方式。无论哪种方式，目标都是实现多云数据统一可见，通过完整链路数据快速定位或分析问题。

跨云上报

链路数据跨云上报的实现难度相对较低，便于维护管理，是目前云厂商采用的主流做法，比如阿里云 ARMS 就是通过跨云数据上报实现的多云数据融合。

跨云上报的优点是部署成本低，一套服务端便于维护；缺点是跨云传输会占用公网带宽，公网流量费用和稳定性是重要限制条件。跨云上报比较适合一主多从架构，绝大部分节点部署在一个云环境内，其他云/自建机房仅占少量业务流量，比如某企业 toC 业务部署在阿x云，企业内部应用部署在自建机房，就比较适合跨云上报的方式，如下图所示。

跨云查询

跨云查询是指原始链路数据保存在当前云网络内，将一次用户查询分别下发，再将查询结果聚合进行统一处理，减少公网传输成本。

跨云查询的优点就是跨网传输数据量小，特别是链路数据的实际查询量通常不到原始数据量的万分之一，可以极大地节省公网带宽。缺点是需要部署多个数据处理终端，不支持分位数、全局 TopN 等复杂计算。比较适合多主架构，简单的链路拼接、max/min/avg 统计都可以支持。

跨云查询实现有两种模式，一种是在云网络内部搭建一套集中式的数据处理终端，并通过内网专线打通用户网络，可以同时处理多个用户的数据；另一种是为每个用户单独搭建一套 VPC 内的数据处理终端。前者维护成本低，容量弹性更大；后者数据隔离性更好。

其他方式

除了上述两种方案，在实际应用中还可以采用混合模式或仅透传模式。

混合模式是指将统计数据通过公网统一上报，进行集中处理（数据量小，精度要求高），而链路数据采用跨云查询方式进行检索（数据量大，查询频率低）。

仅透传模式是指每个云环境之间仅保证链路上下文能够完整透传，链路数据的存储与查询独立实现。这种模式的好处就是实现成本极低，每朵云之间仅需要遵循同一套透传协议，具体的实现方案可以完全独立。通过同一个 TraceId 或应用名进行人工串联，比较适合存量系统的快速融合，改造成本最小。

全链路追踪接入实践

前文详细介绍了全链路追踪在各种场景下面临的挑战与应对方案，接下来以阿里云 ARMS 为例，介绍一下如何从 0 到 1 构建一套贯穿前端、网关、服务端、容器和云组件的完整可观测系统。

• Header 透传格式：统一采用 Jaeger 格式，Key 为 uber-trace-id， Value 为 {trace-id}:{span-id}:{parent-span-id}:{flags} 。
• 前端接入：可以采用 CDN（Script 注入）或 NPM 两种低代码接入方式，支持 Web/H5、Weex 和各类小程序场景。
• 后端接入：
• • Java 应用推荐优先使用 ARMS Agent，无侵入式埋点无需代码改造，支持边缘诊断、无损统计、精准采样等高阶功能。用户自定义方法可以通过 OpenTelemetry SDK 主动埋点。
• • 非 Java 应用推荐通过 Jaeger 接入，并将数据上报至 ARMS Endpoint，ARMS 会兼容多语言应用间的链路透传与展示。

阿里云 ARMS 目前的全链路追踪方案是基于 Jaeger 协议，正在开发 SkyWalking 协议，以便支持 SkyWalking 自建用户的无损迁移。前端、Java 应用与非 Java 应用全链路追踪的调用链效果如下图所示：

1、前端接入实践

ARMS 前端监控支持 Web/H5、Weex、支付宝和微信小程序等，本文以 Web 应用通过 CDN 方式接入 ARMS 前端监控为例，简要说明接入流程，详细接入指南参考 ARMS 前端监控官网文档。

1. 登录 ARMS 控制台，在左侧导航栏中单击接入中心，点击选择前端 Web/H5 接入。
2. 输入应用名称，点击创建；勾选SDK扩展配置项区域需要的选项，快捷生成待插入页面的BI探针代码。
3. 选择异步加载，复制下面代码并粘贴至页面html中** **元素内部的第一行，然后重启应用。

<script>
!(function(c,b,d,a){c[a]||(c[a]={});c[a].config={pid:"xxx",imgUrl:"https://arms-retcode.aliyuncs.com/r.png?", 
enableLinkTrace: true, linkType: \'tracing\'};
with(b)with(body)with(insertBefore(createElement("script"),firstChild))setAttribute("crossorigin","",src=d)
})(window,document,"https://retcode.alicdn.com/retcode/bl.js","__bl");
</script>

为了实现前后端链路打通，上述探针代码中必须包含以下两个参数：

1. enableLinkTrace:true // 表示开启前端链路追踪功能
2. linkType: \'tracing\' // 表示生成 Jaeger 协议格式的链路数据，Hearder 允许 uber-trace-id 透传

另外，如果 API 与当前应用非同源，还需要添加 enableApiCors: true 这个参数，并且后端服务器也需要支持跨域请求及自定义header 值，详情参考前后端链路关联文档。如需验证前后端链路追踪配置是否生效，可以打开控制台查看对应 API 请求的 Request Headers 中是否有 uber-trace-id 这个标识。

2、Java 应用接入实践

Java 应用推荐接入 ARMS JavaAgent，无侵入式探针开箱即用，无需修改业务代码，详细接入指南参考 ARMS 应用监控官网文档。

1. 登录 ARMS 控制台，在左侧导航栏中单击接入中心，点击选择后端 Java 接入。
2. 根据需要选择手动安装、脚本安装和容器服务安装任意方式。
3. 根据操作指南确保探针下载并解压至本地，正确配置 appName、LicenseKey 和 javaagent 启动参数后，重启应用。

3、非 Java 应用接入实践

非 Java 应用可以通过开源 SDK（比如 Jaeger）将数据上报至 ARMS 接入点，详细接入指南参考 ARMS 应用监控官网文档。

1. 登录 ARMS 控制台，在左侧导航栏中单击接入中心，点击选择后端 Go/C++/.NET/Node.js 等接入方式。
2. 根据操作指南替换接入点 ，配置完成后重启应用。

全链路追踪只是开始，不是结束

从 2010 年谷歌发表 Dapper 论文开始，链路追踪已经发展了十多年。但是关于链路追踪的书籍或深度文章一直都比较少，大部分博客只是简单介绍一些开源的概念或 QuickStart，一个大型企业如何建设一套真正可用、好用、易用的链路追踪系统，需要填哪些坑，避哪些雷，很难找到比较系统、全面的答案。

全链路追踪接入只是 Tracing 的起点，选择适合自身业务架构的方案，可以避免一些弯路。但链路追踪不仅仅只是看看调用链和服务监控，如何向上赋能业务，衍生至业务可观测领域辅助业务决策？如何向下与基础设施可观测联动，提前发现资源类风险？后面还有很多的工作要做，期待更多同学一起加入分享。

相关链接：
1、 ARMS 前端监控官网文档：https://help.aliyun.com/document_detail/106086.html?spm=ata.21736010.0.0.5d3a7f117o1Lty
2、 前后端链路关联文档：https://help.aliyun.com/document_detail/91409.html#title-6rx-0lb-p1o
3、ARMS 应用监控官网文档：https://help.aliyun.com/document_detail/97924.html
4、ARMS 应用监控官网文档：https://help.aliyun.com/document_detail/118912.html
5、ARMS 控制台：
https://arms.console.aliyun.com/?spm=ata.21736010.0.0.5d3a7f117o1Lty
6、开源自建/托管与商业化自研 Trace，如何选择？：
https://mp.weixin.qq.com/s?spm=a2c6h.12873639.0.0.2ff66234Viwi2h&__biz=MzIzOTU0NTQ0MA==&mid=2247504737&idx=1&sn=2de2fb0e0656c702fa4d2546a9cdd2e5&scene=21#wechat_redirect

点击下方链接，立即体验链路追踪！
https://www.aliyun.com/product/xtrace?spm=5176.8140086.J_8058803260.58.4da02c90QhBtVo

快速分析和诊断分布式应用架构下的性能瓶颈，提高微服务时代下的开发诊断效率。

Node.js 应用全链路追踪技术——[全链路信息获取]

全链路追踪技术的两个核心要素分别是 全链路信息获取 和 全链路信息存储展示。

Node.js 应用也不例外，这里将分成两篇文章进行介绍；第一篇介绍 Node.js 应用全链路信息获取， 第二篇介绍 Node.js 应用全链路信息存储展示。

一、Node.js 应用全链路追踪系统

目前行业内， 不考虑 Serverless 的情况下，主流的 Node.js 架构设计主要有以下两种方案：

• 通用架构：只做 ssr 和 bff，不做服务器和微服务；

• 全场景架构：包含 ssr、bff、服务器、微服务。

上述两种方案对应的架构说明图如下图所示：

在上述两种通用架构中，nodejs 都会面临一个问题，那就是：

在请求链路越来越长，调用服务越来越多，其中还包含各种微服务调用的情况下，出现了以下诉求：

• 如何在请求发生异常时快速定义问题所在；

• 如何在请求响应慢的时候快速找出慢的原因；

• 如何通过日志文件快速定位问题的根本原因。

我们要解决上述诉求，就需要有一种技术，将每个请求的关键信息聚合起来，并且将所有请求链路串联起来。让我们可以知道一个请求中包含了几次服务、微服务请求的调用，某次服务、微服务调用在哪个请求的上下文。

这种技术，就是Node.js应用全链路追踪。它是 Node.js 在涉及到复杂服务端业务场景中，必不可少的技术保障。

综上，我们需要Node.js应用全链路追踪，说完为什么需要后，下面将介绍如何做Node.js应用的全链路信息获取。

二、全链路信息获取

全链路信息获取，是全链路追踪技术中最重要的一环。只有打通了全链路信息获取，才会有后续的存储展示流程。

对于多线程语言如 Java 、 Python 来说，做全链路信息获取有线程上下文如 ThreadLocal 这种利器相助。而对于Node.js来说，由于单线程和基于IO回调的方式来完成异步操作，所以在全链路信息获取上存在天然获取难度大的问题。那么如何解决这个问题呢？

三、业界方案

由于 Node.js 单线程，非阻塞 IO 的设计思想。在全链路信息获取上，到目前为止，主要有以下 4 种方案：

• domain: node api；

• zone.js: Angular 社区产物；

• 显式传递：手动传递、中间件挂载；

• Async Hooks：node api；

而上述 4 个方案中，  domain 由于存在严重的内存泄漏，已经被废弃了；zone.js 实现方式非常暴力、API比较晦涩、最关键的缺点是 monkey patch 只能 mock api ，不能 mock language；显式传递又过于繁琐和具有侵入性；综合比较下来，效果最好的方案就是第四种方案，这种方案有如下优点：

• node 8.x 新加的一个核心模块，Node 官方维护者也在使用，不存在内存泄漏；

• 非常适合实现隐式的链路跟踪，入侵小，目前隐式跟踪的最优解；

• 提供了 API 来追踪 node 中异步资源的生命周期；

• 借助 async_hook 实现上下文的关联关系；

优点说完了，下面我们就来介绍如何通过 Async Hooks 来获取全链路信息。

四、Async Hooks【异步钩子】

4.1  Async Hooks 概念

Async Hooks 是 Node.js v8.x 版本新增加的一个核心模块，它提供了 API 用来追踪 Node.js 中异步资源的生命周期，可帮助我们正确追踪异步调用的处理逻辑及关系。在代码中，只需要写 import asyncHook from \'async_hooks\' 即可引入 async_hooks 模块。

一句话概括：async_hooks 用来追踪 Node.js 中异步资源的生命周期。

目前 Node.js 的稳定版本是 v14.17.0 。我们通过一张图看下 Async Hooks 不同版本的 api 差异。如下图所示：

从图中可以看到该 api 变动较大。这是因为从 8 版本到 14 版本，async_hooks 依旧还是 Stability: 1 - Experimental

但是没关系，要相信官方团队，这里我们的全链路信息获取方案是基于 Node v9.x 版本 api 实现的。对于 Async Hooks api 介绍和基本使用， 大家可以阅读官方文档，下文会阐述对核心知识的理解。

下面我们将系统介绍基于 Async Hooks 的全链路信息获取方案的设计和实现，下文统称为 zone-context 。

4.2  理解 async_hooks 核心知识

在介绍 zone-context 之前，要对 async_hooks 的核心知识有正确的理解，这里做了一个总结，有如下6点：

• 每一个函数(不论异步还是同步)都会提供一个上下文， 我们称之为 async scope ，这个认知对理解 async_hooks 非常重要；

• 每一个 async scope 中都有一个 asyncId ,它是当前 async scope 的标志，同一个的 async scope 中 asyncId 必然相同，每个异步资源在创建时， asyncId 自动递增，全局唯一；

• 每一个 async scope 中都有一个 triggerAsyncId ，用来表示当前函数是由哪个 async scope 触发生成的；

• 通过 asyncId 和 triggerAsyncId 我们可以追踪整个异步的调用关系及链路，这个是全链路追踪的核心；

• 通过 async_hooks.createHook 函数来注册关于每个异步资源在生命周期中发生的 init 等相关事件的监听函数；

• 同一个 async scope 可能会被调用及执行多次，不管执行多少次，其 asyncId 必然相同，通过监听函数，我们很方便追踪其执行的次数、时间以及上下文关系。

上述6点知识对于理解 async_hooks 是非常重要的。正是因为这些特性，才使得 async_hooks 能够优秀的完成Node.js 应用全链路信息获取。

到这里，下面就要介绍 zone-context 的设计和实现了，请和我一起往下看。

五、zone-context

5.1  架构设计

整体架构设计如下图所示：

核心逻辑如下：异步资源（调用）创建后，会被 async_hooks 监听到。监听到后，对获取到的异步资源信息进行处理加工，整合成需要的数据结构，整合后，将数据存储到 invoke tree 中。在异步资源结束时，触发 gc 操作，对 invoke tree 中不再有用的数据进行删除回收。

从上述核心逻辑中，我们可以知道，此架构设计需要实现以下三个功能：

• 异步资源（调用）监听

• invoke tree

• gc

下面开始逐个介绍上述三个功能的实现。

5.2  异步资源（调用）监听

如何做到监听异步调用呢？

这里用到了 async_hooks （追踪 Node.js 异步资源的生命周期）代码实现如下：

asyncHook
  .createHook({
    init(asyncId, type, triggerAsyncId) {
      // 异步资源创建（调用）时触发该事件
    },
  })
  .enable()

是不是发现此功能实现非常简单，是的哦，就可以对所有异步操作进行追踪了。

介绍完异步调用监听，下面将介绍 invoke tree 的实现。

5.3 invoke tree 设计和异步调用监听结合

5.3.1 设计

invoke tree 整体设计思路如下图所示：

具体代码如下：

interface ITree {  [key: string]: {    // 调用链路上第一个异步资源asyncId    rootId: number    // 异步资源的triggerAsyncId    pid: number    // 异步资源中所包含的异步资源asyncId    children: Array<number>  }} const invokeTree: ITree = {}

创建一个大的对象 invokeTree， 每一个属性代表一个异步资源的完整调用链路。属性的key和value代表含义如下：

• 属性的 key 是代表这个异步资源的 asyncId。

• 属性的 value 是代表这个异步资源经过的所有链路信息聚合对象，该对象中的各属性含义请看上面代码中的注释进行理解。

通过这种设计，就能拿到任何一个异步资源在整个请求链路中的关键信息。收集根节点上下文。

5.3.2 和异步调用监听结合

虽然 invoke tree 设计好了。但是如何在 异步调用监听的 init 事件中，将 asyncId 、 triggerAsyncId 和 invokeTree 关联起来呢？

代码如下：

asyncHook
  .createHook({
    init(asyncId, type, triggerAsyncId) {
      // 寻找父节点
      const parent = invokeTree[triggerAsyncId]
      if (parent) {
        invokeTree[asyncId] = {
          pid: triggerAsyncId,
          rootId: parent.rootId,
          children: [],
        }
        // 将当前节点asyncId值保存到父节点的children数组中
        invokeTree[triggerAsyncId].children.push(asyncId)
      }
    }
  })
  .enable()

大家看上面代码，整个代码大致有以下几个步骤：

1. 当监听到异步调用的时候，会先去 invokeTree 对象中查找是否含有 key 为 triggerAsyncId 的属性；

2. 有的话，说明该异步调用在该追踪链路中，则进行存储操作，将 asyncId 当成 key ， 属性值是一个对象，包含三个属性，分别是 pid、rootId、children ， 具体含义上文已说过；

3. 没有的话，说明该异步调用不在该追踪链路中。则不进行任何操作，如把数据存入 invokeTree 对象；

4. 将当前异步调用 asyncId 存入到 invokeTree 中 key 为 triggerAsyncId 的 children 属性中。

至此，invoke tree 的设计、和异步调用监听如何结合，已经介绍完了。下面将介绍 gc 功能的设计和实现。

5.4 gc

5.4.1 目的

我们知道，异步调用次数是非常多的，如果不做 gc 操作，那么 invoke tree 会越来越大，node应用的内存会被这些数据慢慢占满，所以需要对 invoke tree 进行垃圾回收。

5.4.2 设计

gc 的设计思想主要如下：当异步资源结束的时候，触发垃圾回收，寻找此异步资源触发的所有异步资源，然后按照此逻辑递归查找，直到找出所有可回收的异步资源。

话不多说，直接上代码， gc 代码如下：

interface IRoot {
  [key: string]: Object
}

// 收集根节点上下文
const root: IRoot = {}

function gc(rootId: number) {
  if (!root[rootId]) {
    return
  }

  // 递归收集所有节点id
  const collectionAllNodeId = (rootId: number) => {
    const {children} = invokeTree[rootId]
    let allNodeId = [...children]
    for (let id of children) {
      // 去重
      allNodeId = [...allNodeId, ...collectionAllNodeId(id)]
    }
    return allNodeId
  }

  const allNodes = collectionAllNodeId(rootId)

  for (let id of allNodes) {
    delete invokeTree[id]
  }

  delete invokeTree[rootId]
  delete root[rootId]
}

gc 核心逻辑：用 collectionAllNodeId 递归查找所有可回收的异步资源（ id ）。然后再删除 invokeTree 中以这些 id 为 key 的属性。最后删除根节点。

root 其实是我们对某个异步调用进行监听时，设置的一个根节点对象，这个节点对象可以手动传入一些链路信息，这样可以为全链路追踪增加其他追踪信息，如错误信息、耗时时间等。

5.5 万事具备，只欠东风

我们的异步事件监听设计好了， invoke tree 设计好了，gc 也设计好了。那么如何将他们串联起来呢？比如我们要监听某一个异步资源，那么我们要怎样才能把 invoke tree 和异步资源结合起来呢？

这里需要三个函数来完成结合，分别是 ZoneContext 、 setZoneContext 、 getZoneContext。下面来一一介绍下这三个函数：

5.5.1 ZoneContext

这是一个工厂函数，用来创建异步资源实例的，代码如下所示：

// 工厂函数
async function ZoneContext(fn: Function) {
  // 初始化异步资源实例
  const asyncResource = new asyncHook.AsyncResource(\'ZoneContext\')
  let rootId = -1
  return asyncResource.runInAsyncScope(async () => {
    try {
      rootId = asyncHook.executionAsyncId()
      // 保存 rootId 上下文
      root[rootId] = {}
      // 初始化 invokeTree
      invokeTree[rootId] = {
        pid: -1, // rootId 的 triggerAsyncId 默认是 -1
        rootId,
        children: [],
      }
      // 执行异步调用
      await fn()
    } finally {
      gc(rootId)
    }
  })
}

大家会发现，在此函数中，有这样一行代码： 

const asyncResource = new asyncHook.AsyncResource(\'ZoneContext\') 

这行代码是什么含义呢？

它是指我们创建了一个名为 ZoneContext 的异步资源实例，可以通过该实例的属性方法来更加精细的控制异步资源。

调用该实例的 runInAsyncScope方法，在runInAsyncScope 方法中包裹要传入的异步调用。可以保证在这个资源（ fn ）的异步作用域下，所执行的代码都是可追踪到我们设置的 invokeTree 中，达到更加精细控制异步调用的目的。在执行完后，进行gc调用，完成内存回收。

5.5.2 setZoneContext

用来给异步调用设置额外的跟踪信息。代码如下：

function setZoneContext(obj: Object) {
  const curId = asyncHook.executionAsyncId()
  let root = findRootVal(curId)
  Object.assign(root, obj)
}

通过 Object.assign(root, obj) 将传入的 obj 赋值给 root 对象中， key 为 curId 的属性。这样就可以给我们想跟踪的异步调用设置想要跟踪的信息。

5.5.3 getZoneContext

用来拿到异步调的 rootId 的属性值。代码如下：

function findRootVal(asyncId: number) {
  const node = invokeTree[asyncId]
  return node ? root[node.rootId] : null
}
function getZoneContext() {
  const curId = asyncHook.executionAsyncId()
  return findRootVal(curId)
}

通过给 findRootVal 函数传入 asyncId 来拿到 root 对象中 key 为 rootId 的属性值。这样就可以拿到当初我们设置的想要跟踪的信息了，完成一个闭环。

至此，我们将 Node.js应用全链路信息获取的核心设计和实现阐述完了。逻辑上有点抽象，需要多去思考和理解，才能对全链路追踪信息获取有一个更加深刻的掌握。

最后，我们使用本次全链路追踪的设计实现来展示一个追踪 demo 。

5.6 使用 zone-context

5.6.1 确定异步调用嵌套关系

为了更好的阐述异步调用嵌套关系，这里进行了简化，没有输出 invoke tree 。例子代码如下：

// 对异步调用A函数进行追踪
ZoneContext(async () => {
  await A()
})

// 异步调用A函数中执行异步调用B函数
async function A() {
  // 输出 A 函数的 asyncId
  fs.writeSync(1, `A 函数的 asyncId -> ${asyncHook.executionAsyncId()}\\n`)
  Promise.resolve().then(() => {
    // 输出 A 函数中执行异步调用时的 asyncId
    fs.writeSync(1, `A 执行异步 promiseC 时 asyncId 为 -> ${asyncHook.executionAsyncId()}\\n`)
    B()
  })
}

// 异步调用B函数中执行异步调用C函数
async function B() {
  // 输出 B 函数的 asyncId
  fs.writeSync(1, `B 函数的 asyncId -> ${asyncHook.executionAsyncId()}\\n`)
  Promise.resolve().then(() => {
    // 输出 B 函数中执行异步调用时的 asyncId
    fs.writeSync(1, `B 执行异步 promiseC 时 asyncId 为 -> ${asyncHook.executionAsyncId()}\\n`)
    C()
  })
}

// 异步调用C函数
function C() {
  const obj = getZoneContext()
  // 输出 C 函数的 asyncId
  fs.writeSync(1, `C 函数的 asyncId -> ${asyncHook.executionAsyncId()}\\n`)
  Promise.resolve().then(() => {
    // 输出 C 函数中执行异步调用时的 asyncId
    fs.writeSync(1, `C 执行异步 promiseC 时 asyncId 为 -> ${asyncHook.executionAsyncId()}\\n`)
  })
}

输出结果为：

A 函数的 asyncId -> 3
A 执行异步 promiseA 时 asyncId 为 -> 8
B 函数的 asyncId -> 8
B 执行异步 promiseB 时 asyncId 为 -> 13
C 函数的 asyncId -> 13
C 执行异步 promiseC 时 asyncId 为 -> 16

只看输出结果就可以推出以下信息：

• A 函数执行异步调用后， asyncId 为 8 ，而 B 函数的 asyncId 是 8 ，这说明， B 函数是被 A 函数 调用；

• B 函数执行异步调用后， asyncId 为 13 ，而 C 函数的 asyncId 是 13 ，这说明， C 函数是被 B 函数 调用；

• C 函数执行异步调用后， asyncId 为 16 ， 不再有其他函数的 asyncId 是 16 ，这说明， C 函数中没有调用其他函数；

• 综合上面三点，可以知道，此链路的异步调用嵌套关系为：A —> B -> C；

至此，我们可以清晰快速的知道谁被谁调用，谁又调用了谁。

5.6.2 额外设置追踪信息

在上面例子代码的基础下，增加以下代码：

ZoneContext(async () => {
  const ctx = { msg: \'全链路追踪信息\', code: 1 }
  setZoneContext(ctx)
  await A()
})

function A() {
  // 代码同上个demo
}

function B() {
  // 代码同上个demo
  D（）
}

// 异步调用C函数
function C() {
  const obj = getZoneContext()
  Promise.resolve().then(() => {
    fs.writeSync(1, `getZoneContext in C -> ${JSON.stringify(obj)}\\n`)
  })
}

// 同步调用函数D
function D() {
  const obj = getZoneContext()
  fs.writeSync(1, `getZoneContext in D -> ${JSON.stringify(obj)}\\n`)
}

输出以下内容：呈现代码宏出错:参数

\'com.atlassian.confluence.ext.code.render.InvalidValueException\'的值无效。

getZoneContext in D -> {"msg":"全链路追踪信息","code":1}

getZoneContext in C-> {"msg":"全链路追踪信息","code":1}

可以发现， 执行 A 函数前设置的追踪信息后，调用 A 函数， A 函数中调用 B 函数， B 函数中调用 C 函数和 D 函数。在 C 函数和 D 函数中，都能访问到设置的追踪信息。

这说明，在定位分析嵌套的异步调用问题时，通过 getZoneContext 拿到顶层设置的关键追踪信息。可以很快回溯出，某个嵌套异步调用出现的异常，

是由顶层的某个异步调用异常所导致的。

5.6.3 追踪信息大而全的 invoke tree

例子代码如下：

ZoneContext(async () => {
  await A()
})
async function A() {
  Promise.resolve().then(() => {
    fs.writeSync(1, `A 函数执行异步调用时的 invokeTree -> ${JSON.stringify(invokeTree)}\\n`)
    B()
  })
}
async function B() {
  Promise.resolve().then(() => {
    fs.writeSync(1, `B 函数执行时的 invokeTree -> ${JSON.stringify(invokeTree)}\\n`)
  })
}

输出结果如下：

A 函数执行异步调用时的 invokeTree -> {"3":{"pid":-1,"rootId":3,"children":[5,6,7]},"5":{"pid":3,"rootId":3,"children":[10]},"6":{"pid":3,"rootId":3,"children":[9]},"7":{"pid":3,"rootId":3,"children":[8]},"8":{"pid":7,"rootId":3,"children":[]},"9":{"pid":6,"rootId":3,"children":[]},"10":{"pid":5,"rootId":3,"children":[]}}

B 函数执行异步调用时的 invokeTree -> {"3":{"pid":-1,"rootId":3,"children":[5,6,7]},"5":{"pid":3,"rootId":3,"children":[10]},"6":{"pid":3,"rootId":3,"children":[9]},"7":{"pid":3,"rootId":3,"children":[8]},"8":{"pid":7,"rootId":3,"children":[11,12]},"9":{"pid":6,"rootId":3,"children":[]},"10":{"pid":5,"rootId":3,"children":[]},"11":{"pid":8,"rootId":3,"children":[]},"12":{"pid":8,"rootId":3,"children":[13]},"13":{"pid":12,"rootId":3,"children":[]}}

根据输出结果可以推出以下信息：

1、此异步调用链路的 rootId （初始 asyncId ，也是顶层节点值） 是 3

2、函数执行异步调用时，其调用链路如下图所示：

3、函数执行异步调用时，其调用链路如下图所示：

从调用链路图就可以清晰看出所有异步调用之间的相互关系和顺序。为异步调用的各种问题排查和性能分析提供了强有力的技术支持。

六、总结

到这，关于Node.js 应用全链路信息获取的设计、实现和案例演示就介绍完了。全链路信息获取是全链路追踪系统中最重要的一环，当信息获取搞定后，下一步就是全链路信息存储展示。

我将在下一篇文章中阐述如何基于 OpenTracing 开源协议来对获取的信息进行专业、友好的存储和展示。