企业如何从 0 到 1 构建整套全链路追踪体系

今天，我来跟大家分享 ARMS 在全链路追踪领域的最佳实践，分享主要分为四部分。首先，是对分布式链路追踪的整体简介。其次，是对 ARMS 在分布式链路追踪领域的核心能力进行介绍。然后，介绍如何从 0 到 1 构建整套全链路追踪体系。最后，介绍一些最佳实践案例。

01

什么是分布式链路追踪

Aliware

首先，什么是分布式链路追踪。我对分布式链路追踪的理解就是跟踪请求在分布式系统中的流转路径与状态，从而协助开发人员能够进行故障诊断、容量评估、性能瓶颈分析等工作。

我们可以看到典型的链路轨迹追踪例子：比如用户通过手机做了一个下单动作，这个请求会通过移动端来到网关，再到应用层，比如说有交易、下单、支付等等一系列的应用，然后中间也会穿插到去调用云基础设施，这样用户的行为轨迹是能够被清晰还原出来的。

 

为了更方便的理解这个概念，我们可以把链路追踪和物流追踪做对比。在发送快递物流时，每个快递包裹都会赋予一个唯一的快递单号，对于系统请求来说就是全局唯一的 TraceId。通过快递单号来查询快递途径哪些站点，是否有延迟或丢件情况。那么，也同样可以通过 TraceId 来查询请求在每个系统之间的流转路径和状态。除了快递订单查询之外，还可以把整个物流状态，按照站点去进行汇总统计，来看每个站点吞吐，从而进行物流提效的优化工作。

对于链路追踪来说也是一样的，我们可以把链路数据进行一个统计，然后去看每一个应用或接口的状态，或者去梳理它们之间的强弱依赖。那么，什么样的系统更加需要链路追踪呢？当微服务架构拆分的越精细，服务间依赖越复杂的系统，就更加的需要链路追踪技术，比较典型的就是电商这种。

 

接下来我们看一下链路追踪作为可观测的三元组之一，就是 Traces、Metrics 和 Logs。其最大价值就是实现了除机器和时间维度之外的用户行为的确定性关联。怎么理解这个事情呢？就是在没有 Tracing 之前，比如说通过指标或者日志，只能根据数据在同一台机器上，并且在同一个时间点，判断它们应该是在一起的。但这只是弱关联，并不是强关联。而调用链会很明确说明这个请求就是这个数据，就是来到了这个节点，这个信息是一定准确的。通过这种确定性的关联，除了可以将服务应用接口层面的数据关联起来之外，还可以通过打标上下文传递的方式，把一些业务的标签，比如说来自于什么渠道、订单金额等这种直接、间接的数据都关联起来，发挥 1+1>N 的价值。

接下来再看一下链路追踪的应用场景，我对它做了一个初步分级。

从下往上看，最基础级就是通过调用链来还原单次请求的轨迹状态，这是最基本的应用。

再往上，可以对链路数据去做预聚合或后聚合统计的分析，去看整个链路在概率分布上的一些信息，比如说整个服务维度的监控数据，上下游整体的依赖，这是第二级——聚合分析。

第三等级，就是除了调用链数据本身具备的这些链路数据之外，还可以更进一步发挥关联性作用，把一些间接的业务数据，包括容器或者 JVM 的一些指标信息或者是一些变更的日志事件，也能够通过调用链紧密的关联在一起，形成多维数据关联和分析，最终来实现我们根因定位的能力。

再往后有点像自动驾驶，有了这么多数据，能不能够自动发现其中一些问题？可以结合领域专家经验和恰当的算法，来实现整个诊断流程自动化或者半自动化。

最后一步就是诊断问题的最终目标--保障系统稳定。能不能够把问题诊断和系统恢复两个事关联在一起？从而实现整个系统的故障自愈，进一步提升稳定性。这个就需要与管控系统去融合。目前开源 Tracing 系统大概是在 L1 到 L3 的等级。ARMS 我们那边沉淀了很多领域专家经验以及算法可以做到 L4 等级，ARMS 再加上一些应用托管服务进行自动流控降级、弹性扩缩容，把监控和管控系统结合在一起，从而实现故障自愈能力。

接下来我们再看看链路追踪的发展趋势。在 2010 年，随着谷歌论文发表，拉开了整个链路追踪的技术序幕，很多厂商都纷纷实现了自己的链路追踪技术。当然，在谷歌之前也有很多其他探索，但谷歌给了后续实现者比较完整的理论基础。同时，通过自身实践，证明了链路追踪的企业级价值，这是开山鼻祖式的奠基。