技术文章

您运行的任何测试的价值取决于您收集的测试数据的广度和准确性。然而，当数字基础设施遍布全球时，收集测试数据即使不是几乎不可能，也可能很困难。诀窍是实现分布式跟踪。

分布式跟踪技术使得在请求通过实现其目的所需的各种系统和服务时监控请求的活动成为可能。对于任何使用全球现代 Web 应用程序的测试从业者来说，清楚地了解分布式跟踪至关重要。

什么是分布式追踪？

分布式跟踪是一种用于在请求穿过分布式体系结构时分析和监视应用程序活动的技术。

过去，当 Web 应用程序在静态或缓慢变化的机器阵列上执行时，观察应用程序活动是一项非常简单的任务。您可以在服务器上安装性能监视器来观察服务器的整体行为。要监视特定请求的活动，您可以使用访问应用程序日志来了解基本的请求响应行为。监视数据库中的活动通常只需要使用内置的查询跟踪功能即可。（见图 1。）

图 1：当机器分配是静态或缓慢变化且所有数据都驻留在公共数据存储中时，观察性能行为非常简单。

然而，随着按需使用资源的基于云的临时计算在数字环境中变得越来越普遍，准确理解应用程序内发生的情况变得更加困难。活动分布在各种计算资源上，每个资源专用于一个特定的关注领域。（见图 2。）

图 2：在云中运行的应用程序可以由各种容器化组件组成，可以创建或销毁给定的容器来支持瞬时需求。

而且，每个组件可以以与任何其他组件完全分离的方式携带自己的数据，而不是让应用程序的组件共享公共数据库。将这种程度的隔离与可以立即创建或销毁组件以满足需求的潮起潮落的事实相结合，使得观察特定请求的行为变得困难。

请求可以随时随地发送。有时请求的路径是显而易见的。其他时候，例如当请求进入消息队列时，它会变得隐藏。在这种情况下，除非采取足够的预防措施，否则观察行为类似于放牧猫。一旦你弄清楚一个请求在哪里，另一个请求就会从你的视线中消失。

尽可能长时间地关注一切都变得不可或缺，不仅对于性能测试而且对于整个系统故障排除也是如此。因此，分布式跟踪的好处。

分布式追踪如何工作？

首先，没有魔法。为了使跟踪发挥作用，应用程序或服务需要在其代码中启用智能功能，以便将信息发送到中央收集器。应用程序中安装的智能通常称为跟踪客户端或检测客户端。需要理解的重要一点是应用程序中的智能（客户端）提供了应用程序将相关信息发送到中央跟踪收集器的方法。该中央收集器是可位于网络上的服务器。（见图 3。）

图 3：跟踪客户端将跟踪和跨度信息发送到收集数据的跟踪服务器。

一旦应用程序中安装了客户端检测，当应用程序接收到请求时，跟踪客户端就会为该请求提供唯一的标识符。标识符通常被注入到请求标头中。（在标头中放置唯一标识符是首先在相关标识符模式中开发的技术。）这标识了事务，封装了请求从服务传输到服务端点以完成其任务时所采用的整个路由。

在分布式跟踪用语中，此类事务通常称为跟踪。每个跟踪都由跨度组成：跟踪期间执行的活动，例如对微服务或数据库的调用。每个跨度也有一个唯一的 ID。跨度可以创建称为子跨度的后续跨度，并且子跨度可以有多个父跨度。

所有跟踪行为都被收集并存储在通用数据存储库中，例如Cassandra、Redis、etcd或Elasticsearch。数据存储后，只需进行切片报告即可。通常，报告和跟踪信息可视化是给定分布式跟踪技术的一个组件。然而，鉴于分布式跟踪正在成为现代企业架构框架的重要组成部分，许多开放标准项目（例如OpenTracing和OpenCensus）已经出现，允许公司针对各种收集器使用各种报告工具。

为了使分布式跟踪在不同的测试活动中发挥作用，测试从业者需要将跟踪报告集成作为其规划活动的一部分。对于设计测试报告尤其如此。这些数据将会在那里——只需正确分析它，然后以有意义的方式报告结果即可。

实施分布式追踪

IT 部门实施分布式跟踪需要做的第一件事就是决定共同努力来实现。请注意，不是付出努力，而是决定付出努力。与任何具有企业范围影响的计划一样——相信我，分布式跟踪确实具有企业范围影响——必须定义一个关于如何从 A 点到 B 点的深思熟虑的计划。否则，您的公司将面临重演猫群场景的风险，您将不再追求一组难以捉摸的请求指标，而是追求一系列旨在检索这些指标的系统范围程序方法。

然而，正如我们许多人所知，实现一个想法总是比最初拥有这个想法要困难一个数量级。

整个 IT 部门需要对当前的需求以及如何满足需求有一个共同的理解。实现目标可以通过群体共识或行政命令来实现。我更喜欢集体共识的方法。但是，如果达成共识会导致一名工程师试图比下一位工程师更聪明而浪费时间和金钱，那么法令可能是合理的选择。再说一遍，我不太喜欢法令，但必须建立一种共同的、众所周知的理解和方法来实现分布式跟踪。请记住，进入部署周期的每个应用程序、容器和机器都将受到您决定的分布式跟踪机制的约束。

一旦充分理解了原因和方法，下一步就是实现计划。

实现计划

围绕分布式跟踪的大量规划活动将集中在工具选择上。好消息是有很多选择，其中许多都符合以通用格式发布跟踪信息的新兴标准。因此，选择工具并不是一个不可撤销的决定，但仍然需要谨慎选择工具。

有越来越多的开源工具可用于分布式跟踪。有Zipkin，它是由 Twitter 开发的。它是用 Java 编写的，但可以作为 Docker 容器安装。Jaeger是另一个开源项目。Jaeger 的优点之一是它拥有适用于多种编程环境的客户端库，包括Java、Node.js和Go。AppDash是一种基于 Google 的Dapper分布式跟踪解决方案和 Zipkin 的分布式跟踪技术，也开始流行起来。

在商业端，Datadog的APM产品支持分布式跟踪，Instana也是如此， Instana是一个专注于云中运行的微服务的商业应用程序性能监控解决方案。

从工具转向实践

选择工具后，您需要实施部署计划并坚持下去。您的 IT 部门需要一段时间才能有效地使用跟踪工具。

开发人员需要重构代码，这本身就是一个机会。正如左移运动所倡导的那样，关注性能测试的最佳时机是在编写代码时。

尽管开发人员在分布式跟踪方面所做的重构工作很可能是围绕安装所需的仪器客户端进行的，但开放代码确实为测试人员和开发人员提供了密切合作的机会。重构代码不仅仅是添加跟踪客户端。开发人员和测试人员可以共同创建新的、巧妙的方法来发布日志输出，从而更深入地了解应用程序性能。各方都可以利用集体智慧来确保分布式追踪工作得到最大化。

分布式跟踪有可能将应用程序监控和性能测试提升到难以想象的新水平。查看应用程序活动整个景观中的一切（无论是静态的还是短暂的）是一个游戏规则的改变者。秘诀是坚持和耐心。当您能够了解过去完全不透明的操作时，它就会得到回报。