这是一个创建于 639 天前的主题，其中的信息可能已经有所发展或是发生改变。
简单过一些 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.
 |
1
liuxu 2023-02-23 11:41:16 +08:00
为了调试时定位问题方便
|
 |
4
lc5900 2023-02-23 16:20:01 +08:00
同一个 Trace 可以会多次调用某个服务
|
 |
6
Aresxue 2023-02-28 10:54:18 +08:00  1
因为这样信息更全面，不考虑 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 调用呢？
|
Select Language