再谈服务链监控(1.12)

在前面我专门有一篇文章谈到了跨系统的服务交互监控,这个和APM产品或微服务架构里面经常谈到的服务链监控还有些区别。对于跨系统服务交互监控偏业务协同层面,用户是业务人员;而对于服务链监控则是偏技术层面,用户为业务系统技术或开发人员为主。

对于服务链监控,一个重点就是Trace_ID,在前面谈阿里的传统企业IT架构转型的读书笔记里面专门有谈到过,在这里稍微再的展开谈下Trace_ID的生成和使用。

服务链监控本身是一个有跟节点,可以无限层级展开的树状链结构。因此可以看到最关键的就是需要有父ID和子ID将各个服务调用信息真正串联起来。我们举例来说一下Trace_ID本身的生成和使用规则。

假设我们在操作业务系统中某个功能的时候,比如点击一个按钮,我们希望把点击按钮后出发的所有后台服务调用串联起来,能够完整的看到整个服务链调用的全过程。



1.按钮实现里面按顺序调用了A,B,C三个服务

2.对于A服务的实现本身又调用了A1,A2,A3三个服务

3.对于A1服务本身又调用了A11和A12两个服务

那么我们就需要形成一个完整的树状结构展开来显示整个服务调用的顺序和层级关系。其次才是看每个服务实际的调用情况。

为了保持层级,我们可以这样设计:

1.在按钮实现里面,首先生成一个TRACE_ID=001,将001传入到A,B,C三个服务的调用中。

2.A服务在实现的时候生成新TRACE_ID=101,同时将跟ID拼接后传入到对A1服务的调用

即001.101传入到对A1服务的调用。

3.A1服务继续拼接形成001.101.201传入到对A11服务的调用。

这样在每个服务实例的运行中就有了这种能够区分层级和父子关系的TRACE_ID值,这个值就很容易用来形成树状结构。当然我们也可以在设计上将两个字段分离,即在对服务的调用的时候既要输入父ID的值,也要输入当前ID的值。这样也能够形成完整的树状跟踪结构。相对而言,个人更建议第一种方法来实现。

人月神话的BLOG稿源:人月神话的BLOG (源链) | 关于 | 阅读提示

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 科技动态 » 再谈服务链监控(1.12)

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录