我们希望在我们的堆栈中实现Zipkin。当我研究Zipkin时，扩展Zipkin系统以处理通用标志对我来说是有意义的。
观察：
结论：
答案 0 :(得分：1)
TL; DR;是B3 propagation最初设计用于固定大小的数据：携带跟踪跟踪的数据不在范围内，因此任何以这种方式扩展B3的解决方案都不会与现有代码兼容。
所以，这意味着任何这样的解决方案都将是一个扩展，这意味着instrumented apps中的自定义处理是传递标题的东西。服务器无关紧要，因为它永远不会看到这些标题。
人们通常将标记与zipkin等其他内容集成在一起的方法是添加一个标签，即二进制注释，包括其值（通常在根跨度中）。这将允许您离线查询或检索这些，但它不会解决应用程序的飞行中查找。
假设我们不想使用像linkerd这样的中介或特定于平台的传播上下文，而是将责任分配给跟踪层。首先，什么样的数据可以正常工作？最简单的就是set-once（就像zipkin的trace id）。任何设置和传播而不改变它的东西是最少的机制。接下来的困难是在流中追加新条目，最困难的是变异/合并条目。
假设这是针对从不通过请求/跟踪树更改的入站标志。我们在处理跟踪数据时看到一个标题，我们将其存储并向下游转发。如果跟踪系统不需要读取该值，则最简单，因为它主要是传输/传播问题。例如，也许其他中间件读取该标题并且它只是我们添加到跟踪器以记住某些事物传递的“侧面工作”。如果这是在单个头中完成的，那么代码将比添加的每个位置中的模式少。如果标志可以用数字编码，那么代码就更少了，但这可能是不现实的。
有些apis库可以手动操作传播的上下文，例如"baggage" from brownsys和OpenTracing（其中一些库支持zipkin）。前者旨在成为任何仪器的通用层（例如监控，退款，跟踪等），后者专门用于跟踪。 OpenTracing定义了像injector and extractor这样的抽象类型，它们可以自定义以承载其他字段。但是，为了做到这一点，你仍然需要一个具体的实现（知道你的标题格式等）。除非您希望应用程序读取此数据，否则它将需要是该实现的秘密细节（特别是跟踪上下文）。
某些特定于zipkin的库（如Spring Cloud Sleuth和Brave）具有customize how headers are parsed的功能，可支持B3的变体或新的或特定于站点的跟踪格式。目前并非所有人都支持这一点，但我希望这种类型的功能变得更加普遍。这意味着您可能需要进行一些手术以支持您可能需要支持的所有平台。
长话短说，有一些库可以在传播方面进行插拔，而且最容易修改以支持这个用例。无论B3当前没有定义这样的表达式，都需要一些代码。