如果有用户反馈某个页面很慢,我们知道这个页面的请求调用链是 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。
在 D 调用 E 和 F 时,分别生成 SpanID 2.1 和 2.2。
指定微服务中的“RPC 调用的公用程序”(例如 Dubbo 中的 MonitorFilter.invoke方法), 然后在运行时,通过动态修改字节码的方式来增强它:
图片
当服务 A 调用服务 B 时, Agent 就可以做点儿手脚,修改 header 了:
图片
数据收集
Agent 虽然监控、生成了足够多的数据,但是单个 Agent 无法获得全局视图,我们需要一个全局的收集器来把 Agent 的数据收集上来,这样才能生成全局的调用链。
结构如下图:
图片