0

我们希望在我们的堆栈中实现 Zipkin。当我研究 Zipkin 时，扩展 Zipkin 系统以处理通用标志对我来说是有意义的。

观察：

  1. Zipkin 的任何实现都需要捕获“B3”标记值（HTTP 中的标头）并将它们传播到堆栈的更下方的请求。
  2. 一些值发生了变化
  3. 一些值只是传播（采样，调试）

结论：

  • 使用传播 (X-)B3-Flag- 键/值对的选项扩展 Zipkin 是有意义的。
  • 这支持 A/B 测试和蓝/绿部署。
  • 除非服务开发团队指出，否则这些技术通常需要比较时间以确保时间相似或有所改进。
4

1 回答 1

1

TL;DR; 是B3 传播最初是为固定大小的数据设计的：携带辅助跟踪的数据不在范围内，因此任何以这种方式扩展 B3 的解决方案都不会与现有代码兼容。

因此，这意味着任何像这样的解决方案都将是一个扩展，这意味着在检测应用程序中进行自定义处理，这些应用程序是传递标头的东西。服务器不会在意，因为它无论如何都不会看到这些标头。

人们通常将其他东西（例如标志与 zipkin）集成的方式是添加一个标签，也就是二进制注释，包括它的值（通常在根跨度中）。这将允许您离线查询或检索这些，但它不解决来自应用程序的动态查找。

假设我们不想使用像 linkerd 这样的中介或特定于平台的传播上下文，而是希望将责任分派给跟踪层。首先，什么样的数据可以正常工作？最简单的是设置一次（如 zipkin 的跟踪 id）。任何设置和传播而不改变它的东西都是最少的机制。下一个困难是在中间添加新条目，最困难的是变异/合并条目。

假设这是针对从不通过请求/跟踪树更改的入站标志。我们在处理跟踪数据时会看到一个标头，我们将其存储并转发到下游。如果跟踪系统不需要读取此值，这是最简单的，因为它主要是传输/传播问题。例如，也许其他中间件读取了该标头，而这只是我们添加到跟踪器以记住要传递的某些内容的“副业”。如果这是在单个标头中完成的，那么代码将少于每个要添加的位置中的模式。如果可以将标志编码为数字，那么代码将更少，但这可能是不切实际的。

有一些带有 api 的库可以手动操作传播的上下文，例如来自 brownsys 和 OpenTracing 的“baggage”（其中一些库支持 zipkin）。前者旨在成为任何仪器（例如监控、退款、跟踪等）的通用层，而后者特定于跟踪。OpenTracing 定义了像注入器和提取器这样的抽象类型，可以定制它们以携带其他字段。但是，您仍然需要一个具体的实现（它知道您的标头格式等）才能做到这一点。除非您希望应用程序读取此数据，否则它需要是该实现的秘密细节（特别是跟踪上下文）。

某些特定于 zipkin 的库（例如 Spring Cloud Sleuth 和 Brave）可以自定义标头的解析方式，以支持 B3 的变体或新的或特定于站点的跟踪格式。目前并非所有人都支持这一点，但我希望这种类型的功能会变得更加普遍。这意味着您可能需要进行一些手术才能支持您可能需要支持的所有平台。

长话短说，有一些库在传播方面是可插入的，并且这些库最容易修改以支持这个用例。不管 B3 当前没有定义这样的表达式，都需要一些代码。

于 2017-04-01T05:46:41.607 回答