有关如何在分布式事务中相对常见的情况下解决（酒店）跟踪的任何建议、设计模式或解决方法：批处理/原子批量操作。
由于事件/请求是在服务混合的下游处理的，因此许多处理阶段是异步的、排队的、映射/缩减的、资源密集型的，并导致批处理（甚至是聚合操作）。
从概念上讲，这样的交易可以完美地线性化，并且它将极大地有助于可视化和检查它。问题是如何实现这一点，给定 Otel API。
通常，处理器加载/获取一批消息（来自流、redis、数据库），每个消息都用其跟踪上下文进行注释。然而，它们是“立即”/原子地处理的。我的选择是：
a）除了“原子”操作之外，我还可以生成一个（通常很大）“人工”跨度列表（每个都是每个消息的远程跨度上下文的子级）。结束它们（什么时候？），只是为了“被记录”在痕迹中。此外，如果还有其他下游服务，我会将跨度映射到操作的结果（不清楚该操作本质上是否是一种聚合）。跨度将显示在迹线中。
b) 我可以使用链接。我将为整个批处理操作创建一个新的根跨度，并链接它处理的所有跨度。结果这玩意儿不太好。首先，在我尝试过的任何工具中几乎不可能分析/可视化这一点。其次，如果还有更多事情要做，我应该向下游发送哪些跟踪信息？
这些选项似乎都不合适。我相信这是许多分布式系统中非常常见的模式。然而，到目前为止我发现的几乎所有信息都只讨论了最琐碎的情况，其中单个请求遍历微服务的混合体（主要只是一系列 API 调用）。希望我能制定一些解决方案，但我宁愿问，因为很多人肯定已经在这里了。谢谢你。
OpenTelemetry 建议使用链接来建模批处理和聚合。通常，一旦开始使用“人工”跨度，建模就会出现问题。
首先，在我尝试过的任何工具中几乎不可能分析/可视化这一点。
一些供应商（例如参见这篇文章）为链接提供了相当不错的支持，但是，你是对的，它通常没有得到很好的支持。不过，这种情况正在发生变化，我们看到许多供应商最近在支持链接方面迎头赶上并改进。
第二，如果还有更多事情要做，我应该向下游发送哪些跟踪信息？
取决于您的用例。我想说，如果您转发最初收到的消息，然后保持附加上下文完整，并将下游操作链接到该原始上下文。另一方面，如果您创建向下游发送的新（可能是聚合）消息，请附加聚合或处理操作的上下文。
如果您想要阅读相当技术性的书籍，用于消息传递的 OpenTelemetry 工具将严重依赖于链接。