分布式虚拟跟踪

跟踪提供了对系统的可见性，使开发人员和操作人员可以在运行时观察应用程序。当系统不断增长并与更多微服务进行交互时，跟踪变得非常有价值。在这样的环境中，这些痕迹非常棒，可以定位导致性能下降的故障和瓶颈。

在这篇文章中，我们将帮助您详细了解跟踪。我们将通过示例跟踪事件和问题管理过程中如何使用跟踪。

什么是痕迹？

在检查如何捕获跟踪及其组成之前，让我们看一下跟踪的正式定义：

这样，您可以将跟踪视为一棵树，其根节点是用户进行的交互，并且这些节点代表所有参与处理请求和准备响应的微服务。

分布式跟踪的外观如何？

上面的示例说明了一个由七个跨度组成的迹线。要了解跨度和轨迹，请看一下定义：

跟踪公开了通过分布式系统的执行路径。迹线由一个或多个跨度组成。
跟踪中的跨度代表执行路径中的一项微服务。例如，信用评分检查可能是贷款申请处理过程中的跨度。跨度可以创建多个子跨度，而一个子跨度恰好具有一个父跨度。

因此，将跨度组合成一条轨迹可以揭示如何处理请求在整个分布式系统中的流动。可视化跟踪使用父子表示法来显示跨度之间的依赖性以及每个跨度执行所需的时间。

如何捕获跟踪？

所有跟踪解决方案都要求参与处理入站请求的微服务由代理库进行检测。每个此类代理库都捕获跟踪的一部分，并将其发送到组成跟踪的中央服务器。要了解它是如何工作的，让我们看一个示例电子商店，该例子说明了跟踪捕获：

每当请求到达系统边界时，代理会通过监视第一个节点为它分配一个唯一的ID。该标识符称为跟踪ID。

E-shop前端节点处理入站请求，并决定调用下游的SubmitOrder微服务。这样做时，它通常使用自定义HTTP标头将跟踪ID传递到下游。

SubmitOrder微服务会在HTTP标头中发现跟踪ID。这使SubmitOrder可以将其跨度与E-shop父级链接。

处理请求时， submitOrder微服务发现它需要调用checkInventory微服务。再次通过向下游传递跟踪ID来实现。 checkInventory微服务现在是此树中的终端节点，没有子依赖项。因此，它仅处理请求并将响应发送回父级。完成此操作后， checkInventory微服务中的整个范围就准备好了。

在SubmitOrder中间节点和E-shop父节点中也是如此。跨度组成，配备有开始和结束时间戳记，并使用跟踪ID进行链接。

代理库捕获跨度后，它们会将跨度发送到集中式服务器。在此服务器中，节点被组成跟踪并存储以进行查询。

该过程的结果是组成了完整的痕迹。在上面的示例中，组合的跟踪看起来类似于以下内容：

代理商如何工作？

可以使用两种不同的方法来构建从单个微服务捕获跨度的代理：

跟踪器库 （例如Zipkin ， OpenTracing和Jaeger）使应用程序开发人员可以检测代码并将跨度发送到集中式服务器。它们提供了最常用的语言和框架的库，并在缺少支持的情况下使用户能够构建自己的库

举例说明如何使用Zipkin来检测PHP微服务的示例可能会给您一个想法：

SubmitOrder微服务会在HTTP标头中发现跟踪ID。这使SubmitOrder可以将其跨度与E-shop父级链接。 

 处理请求时， submitOrder微服务发现它需要调用checkInventory微服务。 再次通过向下游传递跟踪ID来实现。 checkInventory微服务现在是此树中的终端节点，没有子依赖项。 因此，它仅处理请求并将响应发送回父级。 完成此操作后， checkInventory微服务中的整个范围就准备好了。

这种方法有其缺点-从将跟踪库引入微服务的示例可以看出，需要更改代码才能捕获所需的信息。要在大型组织中实现这一目标，而由不同团队开发和维护数十甚至数百个微服务，可能是一个艰巨的挑战。

基于代理的解决方案（例如NewRelic或DataDog或我们自己的Plumbr）使用应用程序运行时中的低级挂钩来对微服务进行检测。代理已附加在应用程序配置中，不需要更改代码。

例如，使用Plumbr Java Agent进行跟踪等效于仅更改JVM启动参数，类似于：

SubmitOrder微服务会在HTTP标头中发现跟踪ID。这使SubmitOrder可以将其跨度与E-shop父级链接。 

 处理请求时， submitOrder微服务发现它需要调用checkInventory微服务。 再次通过向下游传递跟踪ID来实现。 checkInventory微服务现在是此树中的终端节点，没有子依赖项。 因此，它仅处理请求并将响应发送回父级。 完成此操作后， checkInventory微服务中的整个范围就准备好了。

因此，推出基于代理的解决方案更加简单，尤其是在管理更大的部署时。但是，大多数基于代理的解决方案都是商业的， 而不是开放源代码的跟踪器库，因此涉及一些成本。