链路跟踪框架为什么要在服务消费侧创建 Span

[choice4]

简单过一些 APM 实现(SkyWalking, Pinpoint, Elastic-apm), 发现这些组件在发生一次调用时，都会新创建一个 Span 并将当前上下文的 Span 作为其父级. 比如对于一次调用: HTTP Start-> DUBBO Consumer -> DUBBO Provider -> HTTP END，普遍在 HTTP 入口处创建使用一个 Span, 同时在 DUBBO Consumer 开始调用时（还没有跨越进程）会新创建一个 Span 并将相关 Trace 信息传入 Provider 侧，类似:

HTTP Span1 Enter -> DUBBO consumer Span2 ENTER -> Dubbo Provider Span3 ENTER -> DUBBO Provider Span3 EXIT -> DUBBO consumer Span2 EXIT -> HTTP Span1 Exit.

请问有没有人知道 Consumer 侧的这一次 Span 创建有什么作用呢？或者说是用于解决什么问题，理论上来说这里，应该只要传入当前 Trace 信息即可，不需要插入一次 Consumer 的 Span, 如果 Span 的创建始终在被调用侧会有什么问题吗？类似:

HTTP Span1 Enter -> Dubbo Provider Span2 ENTER -> DUBBO Provider Span2 EXIT -> HTTP Span1 Exit.

[liuxu]

为了调试时定位问题方便

[choice4]

@liuxu consumer 侧不加入 span ，定位问题会出现什么困难呢？这个没有想到

[liuxu]

@choice4 不加等遇到问题时就晚了，调试不是点到为止，是刨根问底

[lc5900]

同一个 Trace 可以会多次调用某个服务

[choice4]

@lc5900 你是说可能存在异步导致开始时间错误最终看到的调用顺序吗

[Aresxue]

因为这样信息更全面，不考虑 open tracing 的标准，仅从开发人员角度出发，如果业务代码中循环调用同一个 dubbo 服务不在消费端开一个 span 你很难一眼看清是第几次 consumer 出了问题其当前的调用对应的 provider 又是哪一个。从系统调用的层面看 http 入口是主调用，database 、mq 、cache 、rpc consumer 这些是子调用，而对于下游应用来说 rpc provider 则是入口，即满足 A 的子调用是 B 的主调用的链路逻辑，每个应用既是应用自闭环的同时还是全链路的一部分，举个比较极端的例子，A 是本业务域系统使用了 SkyWalking ，它消费的服务归属于另外业务域的系统 B 是没有 SkyWalking 的 agent 当然更不会上报链路信息，此时如果没有 DUBBO Consumer 没有新开一个 Span 将如何标识这一次 dubbo 调用呢？