分布式跟踪系统的四大功能模块如何协同工作

早在十年前，认真研究过分布式跟踪基本上只有学者和一小部分大型互联网公司中的人。对于任何采用微服务的组织来说，它如今成为一种筹码。其理由是确立的：微服务通常会发生让人意想不到的错误，而分布式跟踪则是描述和诊断那些错误的最好方法。

也就是说，一旦你准备将分布式跟踪集成到你自己的应用程序中，你将很快意识到对于不同的人来说“ 分布式跟踪 Distributed Tracing ”一词意味着不同的事物。此外，跟踪生态系统里挤满了具有相似内容的重叠项目。本文介绍了分布式跟踪系统中四个（可能）独立的功能模块，并描述了它们间将如何协同工作。

分布式跟踪：一种思维模型

大多数用于跟踪的思维模型来源于 Google 的 Dapper 论文。OpenTracing 使用相似的术语，因此，我们从该项目借用了以下术语：

![Tracing](/data/attachment/album/202002/03/004452quhjuxjaj1wp7uws.png "Tracing")

跟踪 Trace ：事物在分布式系统运行的过程描述。
跨度 Span ：一种命名的定时操作，表示工作流的一部分。跨度可接受键值对标签以及附加到特定跨度实例的细粒度的、带有时间戳的结构化日志。
跨度上下文 Span context ：携带分布式事务的跟踪信息，包括当它通过网络或消息总线将服务传递给服务时。跨度上下文包含跟踪标识符、跨度标识符以及跟踪系统所需传播到下游服务的任何其他数据。

如果你想要深入研究这种思维模式的细节，请仔细参照 OpenTracing 技术规范。

四大功能模块

从应用层分布式跟踪系统的观点来看，现代软件系统架构如下图所示：

![Tracing](/data/attachment/album/202002/03/004500dl1kkhbiml6pir61.png "Tracing")

现代软件系统的组件可分为三类：

应用程序和业务逻辑：你的代码。
广泛共享库：他人的代码
广泛共享服务：他人的基础架构

这三类组件有着不同的需求，驱动着监控应用程序的分布式跟踪系统的设计。最终的设计得到了四个重要的部分：

跟踪检测 API A tracing instrumentation API ：修饰应用程序代码
线路协议 Wire protocol ：在 RPC 请求中与应用程序数据一同发送的规定
数据协议 Data protocol ：将异步信息（带外）发送到你的分析系统的规定
分析系统 Analysis system ：用于处理跟踪数据的数据库和交互式用户界面

为了更深入的解释这个概念，我们将深入研究驱动该设计的细节。如果你只需要我的一些建议，请跳转至下方的四大解决方案。

需求，细节和解释

应用程序代码、共享库以及共享式服务在操作上有显著的差别，这种差别严重影响了对其进行检测的请求操作。

检测应用程序代码和业务逻辑

在任何特定的微服务中，由微服务开发者编写的大部分代码是应用程序或者商业逻辑。这部分代码规定了特定区域的操作。通常，它包含任何特殊、独一无二的逻辑判断，这些逻辑判断首先证明了创建新型微服务的合理性。基本上按照定义，该代码通常不会在多个服务中共享或者以其他方式出现。

也即是说你仍需了解它，这也意味着需要以某种方式对它进行检测。一些监控和跟踪分析系统使用黑盒代理 black-box agents 自动检测代码，另一些系统更想使用显式的白盒检测工具。对于后者，抽象跟踪 API 提供了许多对于微服务的应用程序代码来说更为实用的优势：

抽象 API 允许你在不重新编写检测代码的条件下换新的监视工具。你可能想要变更云服务提供商、供应商和监测技术，而一大堆不可移植的检测代码将会为该过程增加有意义的开销和麻烦。
事实证明，除了生产监控之外，该工具还有其他有趣的用途。现有的项目使用相同的跟踪工具来驱动测试工具、分布式调试器、“混沌工程”故障注入器和其他元应用程序。
但更重要的是，若将应用程序组件提取到共享库中要怎么办呢？由上述内容可得到结论：

检测共享库

在大多数应用程序中出现的实用程序代码（处理网络请求、数据库调用、磁盘写操作、线程、并发管理等）通常情况下是通用的，而非特别应用于某个特定应用程序。这些代码会被打包成库和框架，而后就可以被装载到许多的微服务上并且被部署到多种不同的环境中。

其真正的不同是：对于共享代码，其他人则成为了使用者。大多数用户有不同的依赖关系和操作风格。如果尝试去使用该共享代码，你将会注意到几个常见的问题：

你需要一个 API 来编写检测。然而，你的库并不知道你正在使用哪个分析系统。会有多种选择，并且运行在相同应用下的所有库无法做出不兼容的选择。
由于这些包封装了所有网络处理代码，因此从请求报头注入和提取跨度上下文的任务往往指向 RPC 库。然而，共享库必须了解到每个应用程序正在使用哪种跟踪协议。
最后，你不想强制用户使用相互冲突的依赖项。大多数用户有不同的依赖关系和操作风格。即使他们使用 gRPC，绑定的 gRPC 版本是否相同？因此任何你的库附带用于跟踪的监控 API 必定是免于依赖的。

因此，一个（a）没有依赖关系、（b）与线路协议无关、（c）使用流行的供应商和分析系统的抽象 API 应该是对检测共享库代码的要求。

检测共享式服务

最后，有时整个服务（或微服务集合体）的通用性足以使许多独立的应用程序使用它们。这种共享式服务通常由第三方托管和管理，例如缓存服务器、消息队列以及数据库。

从应用程序开发者的角度来看，理解共享式服务本质上是黑盒子是极其重要的。它不可能将你的应用程序监控注入到共享式服务。恰恰相反，托管服务通常会运行它自己的监控方案。

四个方面的解决方案

因此，抽象的跟踪应用程序接口将会帮助库发出数据并且注入/抽取跨度上下文。标准的线路协议将会帮助黑盒服务相互连接，而标准的数据格式将会帮助分离的分析系统合并其中的数据。让我们来看一下部分有希望解决这些问题的方案。

跟踪 API：OpenTracing 项目

如你所见，我们需要一个跟踪 API 来检测应用程序代码。为了将这种工具扩展到大多数进行跨度上下文注入和提取的共享库中，则必须以某种关键方式对 API 进行抽象。

OpenTracing 项目主要针对解决库开发者的问题，OpenTracing 是一个与供应商无关的跟踪 API，它没有依赖关系，并且迅速得到了许多监控系统的支持。这意味着，如果库附带了内置的本地 OpenTracing 工具，当监控系统在应用程序启动连接时，跟踪将会自动启动。

就个人而言，作为一个已经编写、发布和操作开源软件十多年的人，在 OpenTracing 项目上工作并最终解决这个观察性的难题令我十分满意。

除了 API 之外，OpenTracing 项目还维护了一个不断增长的工具列表，其中一些可以在这里找到。如果你想参与进来，无论是通过提供一个检测插件，对你自己的 OSS 库进行本地测试，或者仅仅只想问个问题，都可以通过 Gitter 向我们打招呼。

线路协议： HTTP 报头 trace-context

为了监控系统能进行互操作，以及减轻从一个监控系统切换为另外一个时带来的迁移问题，需要标准的线路协议来传播跨度上下文。

w3c 分布式跟踪上下文社区小组在努力制定此标准。目前的重点是制定一系列标准的 HTTP 报头。该规范的最新草案可以在此处找到。如果你对此小组有任何的疑问，邮件列表和Gitter 聊天室是很好的解惑地点。

（LCTT 译注：本文原文发表于 2018 年 5 月，可能现在社区已有不同进展）

数据协议（还未出现！！）

对于黑盒服务，在无法安装跟踪程序或无法与程序进行交互的情况下，需要使用数据协议从系统中导出数据。

目前这种数据格式和协议的开发工作尚处在初级阶段，并且大多在 w3c 分布式跟踪上下文工作组的上下文中进行工作。需要特别关注的是在标准数据模式中定义更高级别的概念，例如 RPC 调用、数据库语句等。这将允许跟踪系统对可用数据类型做出假设。OpenTracing 项目也通过定义一套标准标签集来解决这一事务。该计划是为了使这两项努力结果相互配合。

注意当前有一个中间地带。对于由应用程序开发者操作但不想编译或以其他方式执行代码修改的“网络设备”，动态链接可以帮助避免这种情况。主要的例子就是服务网格和代理，就像 Envoy 或者 NGINX。针对这种情况，可将兼容 OpenTracing 的跟踪器编译为共享对象，然后在运行时动态链接到可执行文件中。目前 C++ OpenTracing API 提供了该选项。而 JAVA 的 OpenTracing 跟踪器解析也在开发中。

这些解决方案适用于支持动态链接，并由应用程序开发者部署的的服务。但从长远来看，标准的数据协议可以更广泛地解决该问题。

分析系统：从跟踪数据中提取有见解的服务

最后不得不提的是，现在有足够多的跟踪监视解决方案。可以在此处找到已知与 OpenTracing 兼容的监控系统列表，但除此之外仍有更多的选择。我更鼓励你研究你的解决方案，同时希望你在比较解决方案时发现本文提供的框架能派上用场。除了根据监控系统的操作特性对其进行评级外（更不用提你是否喜欢 UI 和其功能），确保你考虑到了上述三个重要方面、它们对你的相对重要性以及你感兴趣的跟踪系统如何为它们提供解决方案。