分布式虚拟时间和虚拟同步_分布式虚拟跟踪

叁歲伎倆 2023-02-25 05:57 18阅读 0赞

分布式 虚拟时间和虚拟同步

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

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

## 什么是痕迹？ ##

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

![format_png][]

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

## 分布式跟踪的外观如何？ ##

![format_png 1][]

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

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

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

## 如何捕获跟踪？ ##

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

--------------------

![format_png 2][]

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

![format_png 3][]

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

![format_png 4][]

<table> 
 <tbody> 
  <tr> 
   <td> <em>SubmitOrder</em>微服务会在HTTP标头中发现跟踪ID。 这使<em>SubmitOrder</em>可以将其跨度与<em>E-shop</em>父级链接。 <br><br> 处理请求时， <em>submitOrder</em>微服务发现它需要调用<em>checkInventory</em>微服务。 再次通过向下游传递跟踪ID来实现。 <em>checkInventory</em>微服务现在是该树中的终端节点，没有子依赖项。 因此，它仅处理请求并将响应发送回父级。 完成此操作后， <em>checkInventory</em>微服务中的整个范围就准备好了。 </td> 
  </tr> 
 </tbody> 
</table>

![format_png 5][]

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

![format_png 6][]

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

![format_png 7][]

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

![format_png 8][]

## 代理商如何工作？ ##

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

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

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

SubmitOrder微服务会在HTTP标头中发现跟踪ID。这使SubmitOrder可以将其跨度与E-shop父级链接。 
    
     处理请求时， submitOrder微服务发现它需要调用checkInventory微服务。 再次通过向下游传递跟踪ID来实现。 checkInventory微服务现在是该树中的终端节点，没有子依赖项。 因此，它仅处理请求并将响应发送回父级。 完成此操作后， checkInventory微服务中的整个范围就准备好了。

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

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

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

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

## 标记轨迹和跨度 ##

迹线和跨度往往会被标记以支持多维查询以分析迹线。 常用标签的一些示例：

*  用户身份
 *  serverId
 *  clusterId
 *  API端点
 *  HTTP响应码

使用标签，可以轻松回答不同的问题：

*  此微服务中的哪个API端点已损坏？
 *  该前端中哪些API端点最慢？
 *  哪些用户遇到了错误？
 *  罪魁祸首是哪个微服务？

良好的跟踪提供程序将不同的维度无缝地集成到产品UI和警报设置中，因此您可以避免使用数百万条单独的跟踪，而是立即而及时地获得宝贵的见解。

![format_png 9][]

## 带走 ##

跟踪是一种非常强大的诊断工具，尤其是在应用于分布式环境时。 由于可以在整个执行路径中观察每个单独的请求，因此问题得以解决。 借助标签，可以公开分析查询，从而使影响估算变得微不足道。

> 翻译自: [https://www.javacodegeeks.com/2020/02/distributed-tracing-for-dummies.html][https_www.javacodegeeks.com_2020_02_distributed-tracing-for-dummies.html]

分布式 虚拟时间和虚拟同步

[format_png]: /images/20230209/c460bc1f65564acf85555c7f24bb055d.png
[format_png 1]: /images/20230209/0fe24826087d45e4bbd1ff73484d9b0d.png
[format_png 2]: /images/20230209/9b52c043fe3443c89a545e86ec6d0c99.png
[format_png 3]: /images/20230209/356067a975034642b37138fe68ce3974.png
[format_png 4]: /images/20230209/3488f9d5ca9c4840a15dd33ac617bd61.png
[format_png 5]: /images/20230209/6ebd5d6f0cad4ad7b1928acecdf8c550.png
[format_png 6]: /images/20230209/54b2aef36bf644e3a2589998aa15bad0.png
[format_png 7]: /images/20230209/2280472ade8e4ac8b9ed3e41560d61d0.png
[format_png 8]: /images/20230209/092e35c53bcd4cb68d5fa0be47f90dbf.png
[Zipkin]: mailto:https://zipkin.io/
[OpenTracing]: mailto:https://opentracing.io/
[Jaeger]: mailto:https://www.jaegertracing.io/
[format_png 9]: /images/20230209/125d6ea054de44068f8330582070a021.png
[https_www.javacodegeeks.com_2020_02_distributed-tracing-for-dummies.html]: https://www.javacodegeeks.com/2020/02/distributed-tracing-for-dummies.html