拥抱分布式上下文传播

作者：Yuri Shkuro

本文演示了一些分布式上下文传播的实际例子。我的书《掌握分布式跟踪》第10章给出了更详细的例子。

https://www.shkuro.com/books/2019-mastering-distributed-tracing/

介绍

当我们使软件系统成为分布式时，首先要做的事情之一就是观察和理解应用程序作为一个整体在做什么。我们通常有很好的工具告诉我们每个单独的组件在做什么，但我们对全局一无所知。分布式或端到端跟踪是一种工具，它可以照亮全局，提供系统的宏观视图，以及分布式应用程序执行的每个请求的微观视图。

有不同的方法用于实现跟踪基础设施。在我的书《掌握分布式跟踪》的第3章中，我介绍了其中的一些。今天几乎所有生产使用的跟踪系统采用的最受欢迎的方法，是通过特定的元数据（即跟踪上下文）请求执行的路径，可以用于关联收集自多个组件系统的性能数据，并重新组装成一个连贯的整体跟踪请求。用于传递跟踪上下文的底层机制称为分布式上下文传播（distributed context propagation）。

分布式上下文传播是一种通用机制，可以用于与端到端跟踪完全无关的目的。在OpenTracing API中，它被称为“行李”（“baggage”），Brown University的Rodrigo Fonseca教授创造了这个术语，因为它允许我们将任意的数据附加到一个请求上，并让框架自动将这些数据传播到当前微服务或组件发出的所有下游网络调用。行李与业务请求一起携带，可以在请求执行的任何时刻读取。

在本文中，我想描述一些使用分布式上下文传播的实际例子。

标记合成流量，或“测试租户”

在使用微服务构建的大型系统中，要支持具有与实际生产相同组件组成的登台环境（staging），以及与实际生产通信流类似的任何内容，通常是不切实际的。因此，许多组织正在转向生产中的测试，这包括在生产微服务网格中部署测试代码，并推动实际的流量。在其他情况下，我们希望将测试或合成流量发送到我们的生产实例，可能作为一种监视形式，即确保正确执行核心业务功能，或者执行压力测试来评估能力。

通过分布式上下文传播，使用特定的标签为这个合成的流量添加标签，可以带来许多好处。想象一下，你拥有一个微服务，它正受到这种合成流量的轰炸，并导致错误。如果你遵循良好的DevOps实践，那么你可能已经进行了监视，以度量服务产生的错误率，并在错误率超过某个阈值时发出警报。但是，你只在生产受到影响时才有兴趣获得此警告，而不是因为一些上游服务运行压力测试。通过使用来自分布式上下文的“合成流量”标记，你可以将错误率指标划分为两个时间序列，一个用于生产，另一个用于测试。然后你可以在这些时间序列上设置不同的阈值。

我们还可以使用测试租户（test tenancy，合成流量标签的另一个名称）使应用程序对请求做出不同的反应。例如，一个经过特殊处理的Kafka客户端可以将带有测试租户的消息重定向到另一个专用集群，以避免搞乱生产主题。类似地，存储层可以将带有测试租户的请求重定向到只读集群。

将分布式上下文用于可观察性目的（度量的划分）通常被认为是一种有用的实践，因为在这种情况下，上下文不用于影响应用程序本身的行为。最后一个例子可能会让一些人感到不安，因为现在我们使用上下文作为控制函数。然而，如果我们限制分布式上下文传播以这种方式使用，那么人们就会找到传递此信息的其他方法，只不过是以一种更临时、更不可靠的方式。正确实现上下文传播不是一件小事，特别是考虑到开发者可以使用许多不同的线程和异步编程模型。我认为，拥有一个经过良好测试和维护的单一传播框架要比将其留给临时的实现更好。

这说明了分布式上下文传播的横切特性（cross-cutting nature）。通过扩展组件的API来接受所需的参数，我们总是可以在不进行上下文传播的情况下实现相同的功能。但试着想象一下这在实践中会是什么样子。再次以压力测试为例，想象你是运行测试的服务下面的第5-6层存储层。为了让存储服务知道它正在获得测试流量，你需要遍历所有这些层，并与这些开发者协商，以扩展他们的API来捕获和传递租户参数。想象一下在一个运行数千个微服务的组织中必须这样做！这种方法在实践中是不可行的，而且非常死板，因为一旦需要传递另一个参数，就需要重复整个过程。

分布式上下文传播的强大之处在于，它实现了元数据的传播，而无需对传递此元数据的服务进行任何更改。

将资源使用归因于业务线

如果你的公司运行多个业务线（想想Gmail与谷歌文档与谷歌日历，等等），那么你如何判断你的硬件和基础设施开销中有多少来自于每个LOB（lines of business，业务线）？在堆栈的较高位置，这可能并不困难，因为那些LOB可能有专门负责其不同业务功能的微服务集，你可以直接测量这些服务需要多少计算资源。然而，当我们在堆栈的底层移动到共享系统（如存储或消息传递平台）时，将这些系统上的开销划分为LOB将变得困难得多。

上下文传播来救急！当请求进入我们的系统时，我们通常已经知道它代表哪个LOB，无论是来自API端点，还是直接来自客户机应用程序。我们可以使用上下文（行李）来存储LOB标记，并在调用图中的任何位置，使用它来将资源使用的度量值赋予特定的LOB，例如存储中的读/写数量，或者消息传递平台处理的消息数量。

流量优先级/QoS

由于LOB流量标记同样主要用于“观察”函数（度量和度量），所以让我们考虑上下文传播在“控制”函数中的另一个应用。现代应用程序有许多工作流，用户可以通过应用程序进行跟踪。并非所有这些工作流都具有同等的价值和重要性。在拼车应用程序中，我们可以说出行请求比向收藏夹添加位置的请求更重要。然而，当这些请求最终到达共享基础设施层（如存储）时，这些重要区别通常已经丢失了。因此，如果存储层突然遇到流量高峰，需要对请求的处理进行优先级排序，那么基于它们对业务的重要性进行优先级排序是很好的。我们可以使用上下文传播来实现这一点，例如，为所有API端点分配不同的层号，并通过调用图在上下文中传播这些层号。这些层标签可以被不同的基础设施层使用，以根据请求的重要性提供不同的服务质量。

实现上下文传播

OpenTracing API提供了一个称为“行李”（“baggage”）的标准机制来捕获、传播和检索分布式上下文元数据。像Jaeger这样的分布式跟踪平台完全支持行李，任何使用OpenTracing和Jaeger客户端库进行检测的应用程序都可以从中受益。

我还与W3C分布式跟踪工作组合作，开发一种通过HTTP和其他传输传输分布式上下文的标准格式（请参见https://github.com/w3c/correlation-context）。

https://www.w3.org/2018/distributed-tracing/

总结

分布式上下文传播是一种非常强大的技术，尤其是在使用许多微服务构建的新时代架构中。它允许我们将任意元数据与每个请求关联起来，使其在分布式调用图中的每个点上可用，透明于对处理该请求所涉及的服务。在这篇文章中，我讨论了一些使用上下文传播来解决实际问题的例子。还有很多其他的例子，例如：

• 主跟踪
• 为混沌工程传递故障注入指令
• 生产环境测试
• 生产环境调试
• 生产环境开发

http://brownsys.github.io/tracing-framework/pivottracing/

要查看这些用例的详细描述，请参阅我的书《掌握分布式跟踪》第10章。