工作中,自然少不了开发去排查问题,那如果链路比较长,客户端一个请求打进来,可能内部微服务进行了多个服务的交互,那么如果其中有一个环节出现了问题,我们如何定位是哪一个请求或者是说是哪一条调用链呢?
可能开发的时候或多或少会加入自己的一些表示,例如请求里面会加入 requuid,链路中涉及的服务都会将这个 requuid 传下去,直到整个调用链结束
当然比较 low 的一种方式是,在微服务交互的请求和相应中加上 requuid 字段,这个应该也是从单体服务过度到微服务开发时特别容易出现的情况
实际上做链路跟踪,简单的方式就是在各种请求的上下文加上 traceid 就可以了,今天我们来看看 go-zero 中的链路跟踪是如何应用的
分别从如下几个部分来看看 go-zero 中应用链路跟踪
当然关于日志组件,数据库组件等相关组件,应用到链路跟踪的地方,做法大体一致,我们一起看看 http 和 rpc 服务中应用的方式,其他的组件应用咱们也就可以简单的将知识迁移过去即可上手
对于 ge-zero http ,我们可以一起来看看 服务端部分是如何应用的
简单来说,在我们启动 http 服务的时候,就已经将链路追踪的功能给打开了,go-zero 是通过 http handle 的方式来处理的
当然,同理,我们也可以自己在 go-zero 中加一个 middleware 也是可以达到这样的效果
go-zero 中实际上在我们服务 start 的时候,内部就开始了各种初始化,大体流程是这样的
调用内部服务启动,注册路由
进行路由的绑定,并默认添加中间件 middleware TracingHandler
我们可以看看关于 TracingHandler 的源码实现
根据代码,我们基本可以看出来 TracingHandler 主要做了这几件事情:
request
中产生新的ctx,并将相应的信息封装在 ctx 中,返回那其实 rpc 服务端和客户端部分的实现和 http 的也是类似的,http 使用的是中间件的方式来进行处理,那么 rpc 这边块,其实可以通过拦截器的方式来进行处理
使用 go-zero 项目的框架,我们在启动 rpc 服务的时候,看看都做了些什么
服务 start,go-zero 默认就给我们的 rpc 服务添加了一些默认的拦截器
其中 UnaryTracingInterceptor 不难看出就是用于做拦路追踪的
而且我们可以看到 rpc 部分的拦截器分为流式的和非流式的,例如用于链路追踪的还有 StreamTracingInterceptor
阅读服务端 UnaryTracingInterceptor 拦截去源码,我们可以知道实际上做法和 http server 部分的做法大体一致
那么客户端有什么不一样呢,其实也差不多
当我们 api 层服务在初始化客户端的时候就会使用 zrpc 包的 MustNewClient 方法
跟踪代码我们知道,最终客户端的建立,会去和 rpc 服务端进行建立连接,在建立连接的过程中会带上一些参数
正式 buildDialOptions 在处理 options 的时候将客户端的拦截器给默认加上了 UnaryTracingInterceptor 和 StreamTracingInterceptor
那么 UnaryTracingInterceptor 的具体实现是这个样的:
关于 微服务框架 go-zero 的链路追踪简单的流程咱们就先走到这里,有兴趣的也可以把他用起来
【欢迎查看历史文章】
感谢阅读,欢迎交流,点个赞,关注一波 再走吧
朋友们,你的支持和鼓励,是我坚持分享,提高质量的动力
好了,本次就到这里
技术是开放的,我们的心态,更应是开放的。拥抱变化,向阳而生,努力向前行。
我是阿兵云原生,欢迎点赞关注收藏,下次见~
可以进入地址进行体验和学习:https://xxetb.xet.tech/s/3lucCI