问题描述
是否有一种方法可以推断跨度之间的关系，而无需基于有关事务的其他信息将父跨度ID传递给子服务？
我们正在研究使用opentracing捕获定时信息，以实现到嵌入式设备的端到端命令/响应流。据我了解，为了将多个跨度组合成整个操作的连贯痕迹，跨度需要知道其父级，以便可以报告该跨度与该跨度具有“子项”或“后继”关系。对于我们的大多数系统而言，这不是问题，但是我们的系统具有一个服务，该服务通过SMS将命令发送到设备，而另一个服务则通过UDP接收答复。 SMS预算中没有足够的空间将上下文发送到设备，尽管我们确实具有设备的唯一标识符和命令的递增序号。
我想解决此问题的一种方法是让发送服务将其span ID写入数据库，并让接收者在得到答复时在数据库中查找span ID。这似乎是解决该问题的非常重要的解决方案，所以我想问一下这种情况是否曾经有人遇到过。
解决方法
我认为要真正回答这个问题，我们需要更多地了解您正在使用的实现（Zipkin，Jaegar，Instana？），但是我将尝试以一种通用的方式回答这个问题，至少讨论一种可能的解决方案
OpenTracing标准非常清楚地表明，它们并非故意推断这种关系：https://opentracing.io/docs/overview/inject-extract/
...在这些基于黑匣子推理的方法的明显便利性与组装迹线的新鲜度和质量之间需要权衡。出于对质量的关注，OpenTracing是一个明确的分布式跟踪检测标准...
它可能仍然会为SMS带来额外的费用，但是如果您严格限制注入/提取模型，则可以使用自定义载体：https://opentracing.io/docs/overview/inject-extract/#custom-carriers
该实现将基于您的跟踪解决方案而特定，因为OpenTracing实际上只是调用您的跟踪器提供的SDK。
假设您实际上可以保证数据库记录中具有一定程度的唯一性，因此您不会混淆痕迹，则可以将常用的运营商格式（文本映射或dict表示HTTP标头）存储在然后，DB查找并注入。我仍然会尝试通过SMS通过有线方式发送某种UUID，因为双方都在猜测该跟踪的唯一ID可能会有问题。
根据您的请求量，您可能需要使用键值存储（例如redis）。这可能会更高效+您不需要RDBMS将为您提供的大多数功能。
对于UDP返回，您应该坚持使用通用的运营商格式，已经有一些适用于通过有线进行此类呼叫的方式。