如何将区块链事件触发的多个OpenTelemetry链路合并为原始链路？

拟用方案可行性结论 #

你提到的「服务B调用区块链前序列化span上下文存储、服务C通过msg-id查询后创建子span」的方案完全可以实现链路合并，落地逻辑如下：

• 服务B在发起区块链调用前，将当前链路的traceId、parentSpanId、采样状态等核心上下文信息，和全局透传的msg-id绑定，存入Redis/MySQL这类共享存储中，需设置合理的过期时间避免存储膨胀
• 服务C监听区块链事件时，先从事件payload中提取透传的msg-id，查询存储中对应的链路上下文，以查询到的span作为父节点创建新的子span，后续该事件处理流程的所有埋点都会自动挂载到原有的Trace下
• 单请求触发多事件的场景下，每个事件都会基于同一个父上下文创建独立的子span，最终所有事件的处理链路都会归集到初始的全局Trace下，不会生成独立Trace

其他可选落地方案 #

如果不想引入额外的存储依赖，也可以选择以下两种适配不同场景的方案：

方案1：区块链事件透传链路上下文 #

如果区块链的事件payload支持自定义字段扩展，可以直接在服务B调用区块链时，将traceId、parentSpanId等链路上下文序列化为字符串，和业务参数一起上链，服务C监听事件时直接从payload中取出上下文创建子span即可，省去存储查询环节，性能更高。

方案2：链路后置归集 #

如果既不能修改区块链的payload结构，也不想额外新增存储依赖，可以在链路数据上报到APM系统后，基于全局透传的msg-id做后置关联：

• 给服务C生成的所有Trace的span统一打msg-id标签
• 在APM平台的查询页做自定义关联逻辑，输入原始Trace的msg-id时，同时展示原始链路和所有带相同msg-id标签的服务C生成的链路，从视图层面实现链路合并，不需要改造业务代码。

方案选型建议 #

• 追求性能且允许扩展区块链事件字段：优先选透传上下文方案
• 区块链字段不可扩展且希望链路是原生结构、无需额外视图改造：选上下文预存方案
• 不想改动业务逻辑，仅需要排查问题时能关联链路：选后置归集方案

内容的提问来源于stack exchange，提问作者Somjit