searchusermenu
  • 发布文章
  • 消息中心
点赞
收藏
评论
分享
原创

一种零存储的RPC调用链路跟踪的方法

2024-08-16 09:37:08
30
0

1、背景

RPC调用是系统微服务化过程中的一个重要组成,不同模块之间通过RPC调用进行交互,不同的模块各司其职,共同完成业务过程。一个完整的业务处理过程,有可能需要多个模块共同参与,所以其调用链路可能会变得非常复杂,对RPC调用链路的跟踪,可以清楚地了解业务执行过程,便于分析问题。而在异地双活的情况下,RPC路由会更加复杂,RPC调用链路的跟踪可以有效地帮助问题的追查和分析。

2、问题

目前市面上已有很多链路跟踪的方案了,但是基本套路都是先通过监听调用过程,上报调用日志,然后通过日志数据分析,得到用户请求的调用链路。这种方法的问题在于需要大量的高性能的日志存储服务、需要打通用户实例应用与日志存储服务之间的网络、需要额外消耗日志数据的传输成本。这种方案在单租户应用上使用问题不大,但是在云平台多租户上使用,或者对于某些小型用户来说,使用成本就不小了。

基于调用日志分析的链路跟踪方案,主要思路为,先为这次调用生成一个唯一的请求id,然后通过切面上报所有调用信息,再在控制台中搜索这些调用信息并组成调用链信息。

1、接受到HTTP/RPC请求的时候,获取请求id,如果没有则生成一个,并写入到线程上下文
2、在微服务的服务端上通过切面上报访问日志及请求id
3、在通过微服务的客户端发起请求时,将请求id从线程上下文中取出,写入到请求中
4、分析访问日志,生成结构化的调用链数据
5、用户通过请求id,在控制台中查询对应请求的调用链。

3、方案

本方案提出一种在用户应用本地进行计算和分析、无需额外存储的RPC调用链路跟踪的方法,减少了使用成本,满足了大多数场景的业务需求。

与基于日志分析的方案不同,用户的调用信息并不存储在控制台侧,而是用户在发起调用后直接通过响应信息返回,用户在分析调用链的时候使用的不是请求id,而是整个调用链信息,当用户提供的调用链信息与控制台提供的架构地图结合,便可以进行调用链的可视化分析。

1、接受到HTTP/RPC请求的时候,从请求的附加信息中(header/attachment)解析链路跟踪开关,如果开关已打开,那么将开关标记状态及当前写入线程上下文
2、在通过微服务的客户端发起请求时,将链路跟踪开关从线程上下文中取出,写入到请求的附加信息中(header/attachment),传递开关标记
3、在微服务的客户端调用完成时,从请求的附加信息中(header/attachment)获取这次调用的调用链信息,附加上调用层次信息,拼接上当前的调用信息,再回写到线程上下文中
4、在响应HTTP/RPC请求的时候,将本地收集的路由信息响应到附加信息中(header/attachment),用户可以从这个附加信息中获取完整的调用链信息
5、用户请求完毕,从请求中获取完整的链路信息,在控制台的架构地图中提供该调用链路信息进行分析,生成可视化的调用链路。

0条评论
0 / 1000
唐****律
20文章数
2粉丝数
唐****律
20 文章 | 2 粉丝
原创

一种零存储的RPC调用链路跟踪的方法

2024-08-16 09:37:08
30
0

1、背景

RPC调用是系统微服务化过程中的一个重要组成,不同模块之间通过RPC调用进行交互,不同的模块各司其职,共同完成业务过程。一个完整的业务处理过程,有可能需要多个模块共同参与,所以其调用链路可能会变得非常复杂,对RPC调用链路的跟踪,可以清楚地了解业务执行过程,便于分析问题。而在异地双活的情况下,RPC路由会更加复杂,RPC调用链路的跟踪可以有效地帮助问题的追查和分析。

2、问题

目前市面上已有很多链路跟踪的方案了,但是基本套路都是先通过监听调用过程,上报调用日志,然后通过日志数据分析,得到用户请求的调用链路。这种方法的问题在于需要大量的高性能的日志存储服务、需要打通用户实例应用与日志存储服务之间的网络、需要额外消耗日志数据的传输成本。这种方案在单租户应用上使用问题不大,但是在云平台多租户上使用,或者对于某些小型用户来说,使用成本就不小了。

基于调用日志分析的链路跟踪方案,主要思路为,先为这次调用生成一个唯一的请求id,然后通过切面上报所有调用信息,再在控制台中搜索这些调用信息并组成调用链信息。

1、接受到HTTP/RPC请求的时候,获取请求id,如果没有则生成一个,并写入到线程上下文
2、在微服务的服务端上通过切面上报访问日志及请求id
3、在通过微服务的客户端发起请求时,将请求id从线程上下文中取出,写入到请求中
4、分析访问日志,生成结构化的调用链数据
5、用户通过请求id,在控制台中查询对应请求的调用链。

3、方案

本方案提出一种在用户应用本地进行计算和分析、无需额外存储的RPC调用链路跟踪的方法,减少了使用成本,满足了大多数场景的业务需求。

与基于日志分析的方案不同,用户的调用信息并不存储在控制台侧,而是用户在发起调用后直接通过响应信息返回,用户在分析调用链的时候使用的不是请求id,而是整个调用链信息,当用户提供的调用链信息与控制台提供的架构地图结合,便可以进行调用链的可视化分析。

1、接受到HTTP/RPC请求的时候,从请求的附加信息中(header/attachment)解析链路跟踪开关,如果开关已打开,那么将开关标记状态及当前写入线程上下文
2、在通过微服务的客户端发起请求时,将链路跟踪开关从线程上下文中取出,写入到请求的附加信息中(header/attachment),传递开关标记
3、在微服务的客户端调用完成时,从请求的附加信息中(header/attachment)获取这次调用的调用链信息,附加上调用层次信息,拼接上当前的调用信息,再回写到线程上下文中
4、在响应HTTP/RPC请求的时候,将本地收集的路由信息响应到附加信息中(header/attachment),用户可以从这个附加信息中获取完整的调用链信息
5、用户请求完毕,从请求中获取完整的链路信息,在控制台的架构地图中提供该调用链路信息进行分析,生成可视化的调用链路。

文章来自个人专栏
应用中间件
9 文章 | 1 订阅
0条评论
0 / 1000
请输入你的评论
1
1