我们必须得区分每个调用链，得给它分配一个全局唯一的 TraceID，并且在调用链上的每次调用都带上这个 ID，这样每个调用都被关联起来了。
微服务架构
图片
如果有用户反馈某个页面很慢，我们知道这个页面的请求调用链是 A -----> C -----> B -----> D(图片有误)，怎么来定位是由哪个服务引起的问题呢？
更进一步，如果每个服务 Service A,B,C,D 都部署在好几台机器上。怎么知道某个请求调用了服务的具体哪台机器呢？
图片
可以明显看到，由于无法准确定位每个请求经过的确切路径，在微服务这种架构下有以下几个痛点：
1. 排查问题难度会比较大，解决问题的周期长
2. 特定场景很难再次复用
3.系统性能瓶颈分析同样也不同意
这就需要一个分布式调用链追踪系统。
图片
分布式调用链追踪系统:设计
如果要我们自己实现一个这样的分布式追踪系统，该怎么去设计？
首先，我们必须得区分每个调用链，得给它分配一个全局唯一的TraceID，并且在调用链上的每次调用都带上这个 ID，这样每个调用都被关联起来了。
图片
然后，我们得记录所有调用的先后次序和父子关系。
假设有以上这样的调用链，如果我们只记录了这四个调用：
A---->B
B---->C
A---->D
D---->E
D---->F
虽然我们知道它属于一个调用（TraceID 相同），还是无法画出完整的调用拓扑图。
所以必须得记录父子关系：
A---->B 是 B---->C 的父调用
A---->D 是 D---->E 的父调用
A---->D 还是 D---->F 的父调用
图片
Agent
微服务是来实现业务的，肯定不能来干这个监控和跟踪的活儿，那样对微服务的侵入性就太强了。
所以必须得有一个独立的组件，在不干扰微服务的情况下，监控微服务之间的调用，把这些 ID 生成， 这个独立的组件就是 Agent。
Agent 要想施展魔法，需要安装在每个服务所在的机器上：
图片
这个魔法师遵循的规则也非常简单，以上图中服务 A 上的 Agent 为例：
当 Agent 监测到有人调用服务 A 时，没有 ParentSpanID，它意识到这是一次全新的调用，于是创建新的 TraceID。
当 Agent 察觉到 A 调用了 B 时，生成SpanID= 1，并将此 ID 作为 ParentSpanID 传递给 B。这样，当 B 调用 C 时，B 的 Agent 就能生成此次调用的 SpanID 为 1.1。
当 Agent 察觉到 A 调用 D 时，生成 SpanID = 2，并将此 ID 作为 ParentSpanID 传递给 D。
4. 在 D 调用 E 和 F 时，分别生成 SpanID 2.1 和 2.2。
指定微服务中的“RPC 调用的公用程序”（例如 Dubbo 中的 MonitorFilter.invoke方法）， 然后在运行时，通过动态修改字节码的方式来增强它：
图片
当服务 A 调用服务 B 时， Agent 就可以做点儿手脚，修改 header 了：
图片
数据收集
Agent 虽然监控、生成了足够多的数据，但是单个 Agent 无法获得全局视图，我们需要一个全局的收集器来把 Agent 的数据收集上来，这样才能生成全局的调用链。
结构如下图：
图片
©本文为清一色官方代发，观点仅代表作者本人，与清一色无关。清一色对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文不作为投资理财建议，请读者仅作参考，并请自行承担全部责任。文中部分文字/图片/视频/音频等来源于网络，如侵犯到著作权人的权利，请与我们联系（微信/QQ:1074760229）。转载请注明出处：清一色财经
微信扫码打赏 
支付宝扫码打赏 
