如何理解分布式链路追踪技术

什么是链路追踪？微服务引发了怎样的问题？

在深入了解分布式链路追踪技术之前，我们需要先理解这项技术产生的背景，以及它能够帮我们解决哪些棘手的问题。

提到分布式链路追踪，我们要先提到微服务。相信很多人都接触过微服务，这里再回顾下基本概念：微服务是一种开发软件的架构和组织方法，它侧重将服务解耦，服务之间通过 API 通信。它使程序更与扩展性和小团队独立开发。从而加速新功能上线。

微服务演变-亚马逊云

加速研发快速迭代，让微服务在业务驱动的互联网领域全面普及，独领风骚。但是，随之而来也产生了新问题：当生产系统面对高并发，或者解耦成大量微服务时，以前很容易就能实现的监控、预警、定位故障就变困难了。

我拿研发的搜索系统的经历，结合场景给大家聊聊（曾经这套系统要去抗峰值到日均 10 亿 PV、5 千万 UV 的高并发）

机票搜索演示图

比如搜索机票这样一个行为，其实是对上百个查询服务器发起了一个查询，这个查询会被发送到多个微服务系统，这些微服务系统分别用来处理航班信息、查询有无舱位、机票价格、机场关键字匹配，查找图片资源等等。每个子系统的查询最终聚合得到的结果，会汇总到搜索结果页上。

用户一次查询，做了这么一个“全局搜索”。任何一个子系统变慢，都会导致最终的搜索变得慢，那用户体验就会很差了。

看到这里，你可能会想，体验差我们做搜索优化不就好了么？确实如此，但一般情况，一个前端或者后端工程师虽然知道系统查询耗时，但是他无从知晓这个问题到底是由哪个服务调用造成的，或者为什么这个调用性能差强人意。

首先，这个工程师可能无法准确定位到这次全局搜索是调用了哪些服务，因为新的服务、乃至服务上的某个功能，都有可能在任何时间上过线或修改过。其次，你不能苛求这个工程师对所有参与这次全局搜索的服务都了如指掌，每一个服务都有可能是由不同的团队开发或维护的。再次，搜索服务还同时还被其他客户端使用，比如手机端，这次全局搜索的性能问题甚至有可能是由其他应用造成的。这是过去我的团队面临的问题，微服务让我们的工程师观察用户行为，定位服务故障很棘手。

为什么需要链路追踪

刚才说的情况，我们迫切需要一些新工具，帮我们理解微服务分布式系统的行为、精准分析性能问题。于是，分布式系统下链路追踪技术（Distributed Tracing）出现了。

它的核心思想是：在用户一次请求服务的调⽤过程中，无论请求被分发到多少个子系统中，子系统又调用了更多的子系统，我们把系统信息和系统间调用关系都追踪记录下来。最终把数据集中起来可视化展示。它会形成一个有向图的链路，看起来像下面这样

图一：电商系统的链路追踪图

什么是 Trace

后来，链路追踪技术相关系统慢慢成熟，涌现了像 Dapper、Zipkin、HTrace、OpenTelemetry 等优秀开源系统。他们也被业界，特别是互联网普遍采用。

目前 Dapper（诞生于 Google 团队）应用影响最大，OpenTelemetry 已经成为最新业界标准，我们重点基于它们讲解 Trace 原理。

快速入门

我们看看一个例子，某商家给（顾客）开账单（要求付款），在系统中大体的流程：

图二：一个开账单的例子

当商家从 client 发起开账单服务，请求从 client 程序先后进行了一系列操作：

• 网关 load balancer：client 的 https 请求先经过网关，网关调用下面的子系统；

• 身份认证 auth：网关 RPC 请求到服务 auth，auth 发起身份认证，完成后通知网关程序；

• 生成账单 billing：身份认证成功后，网关再发送 RPC 请求到服务 billing，billing 是生成账单的操作，billing 处理完通知网关下一步；

• 资源加载 resource：billing 成功，网关发送一个 HTTP 请求到服务 resource，加载和账单相关资源，比如静态图片，相关顾客资料，resource 完成通知网关；

• 最后网关程序处理完开账单服务，返回结果给 client；

例子中，我们把开账单服务一个流程或者叫一个事务称为 Trace。这里面有几个操作，分别是请求网关、身份认证、生成账单、加载资源，我们把每个操作(Operation)称为一个 Span。

Trace 数据模型

我们看看 Trace 广义的定义：Trace 是多个 Span 组成的一个有向无环图（DAG），每一个 Span 代表 Trace 中被命名并计时的连续性的执行片段。我们一般用这样数据模型描述 Trace 和 Span 关系：

          [Span user click]  ←←←(the root Span)                   |                      [Span gateway]                     | +------+----------+-----------------------+ |                 |                       |[Span auth]      [Span billing]     [Span loading resource]

图三:开账单 Trace 数据模型

数据模型包含了 Span 之间关系。Span 定义了父级 Span，子 Span 的概念。一个父级的 Span 会并行或者串行启动多个子 Span。图三，gateway 就是 auth、billing 的父级 Span。

上面这种图对于看清各组件的组合关系是很有用的，但是，它不能很好显示组件的调用时间，是串行调用还是并行调用。另外，这种图也无法显示服务调用的时间和先后顺序。因此，在链路追踪系统会用另一种图展现一个典型的 Trace 过程，如下面所示：

这种展现方式增加显示了执行时间的上下文，相关服务间的层次关系，任务的串行或并行调用关系。这样的视图有助于发现系统调用的关键路径。通过关注关键路径的执行过程，项目团队可能专注于优化路径中的关键位置，最大幅度的提升系统性能。例如：可以通过追踪一个用户请求访问链路，观察底层的子系统调用情况，发现哪些操作有耗时重要关注优化。Span 基本结构前面提到 Span 通俗概念：一个操作，它代表系统中一个逻辑运行单元。Span 之间通