什么是分布式服务的调用链跟踪?
分布式服务中完成某一个业务动作,需要服务之间的相互协作才能完成,在这一次动作引起的多服务的联动我们需要用1个唯一标识关联起来,关联起来就是调用链的跟踪。
为什么要实现调用链跟踪?
随着业务的发展,所有的系统最终都会走向服务化体系,微服务的目的一是提高系统的稳定性,二是提高持续交付的效率,为什么能提高这两项不是今天讨论的内容。
当然这也不是绝对的,如果业务还在MVP验证,团队规模小个人觉得完全没必要微服务化、单体应用是比较好的选择。作者是有经历过从单体应用到1000+应用的增长经历,也是见证了公司从初创到上市的过程,对于系统阶段和业务阶段的匹配还是有比较深的感受的。
服务拆分后带来的问题是什么呢?服务的依赖关系复杂后,对于问题的排查也增加了复杂度,当然站在更高的角度来看拆分带来的不只是排错复杂性的提升,工程效率、组织协作也都会带来新的挑战。
回到主题,如何快速查询整个请求链路上的日志并呈现出来是解决排查问题复杂度的根本方法,这就是今天我们要讲的内容,如何自己来实现一个全链路跟踪。
如何实现?
第一步,看图、看场景,用户浏览器的一次请求行为所走的路径是什么样的
如上图、省略了4层和7层的LB,请求直接到gateway->A->B 那如何把个request关联起来呢?从时序上来看我们只要在gateway生成一个traceId然后层层透传,那么每一次的request的我们就能通过traceid关联查询出来了。
如何透传、如何记录呢?或者说如何透传、如何记录让各应用的开发人员无需关注呢?
第二步,实现。不想看代码可直接拉最后看结果和原理
如何传递,这里我们使用定义统一的Request类,所有的api层需要使用这个规范,代码如下:
1 | java复制代码public class Request<T> implements Serializable { |
有了这个Request之后,我们在网关层每次都生成traceId, 然后在各服务之间传递就能做到调用链的关联了。我们继续看个各应用应该如何定义服务和使用
1 | java复制代码 @ApiMethod |
看完上面代码的同学,应该看到了有一个模拟调用其他服务的地方,这里主要解决的是服务和服务之间的调用header传递的问题,这里封装了一个createRequest的方法,其主要内容还是把当前应用的requestHeader 赋值给请求其他服务的request上。这也是一个测试接口,最后面有测试的结果
1 | java复制代码public class RPCRequest { |
当前request中的header存在什么地方呢,我们看一下RequestContext的代码
1 | java复制代码public class RequestContext { |
header是什么时候放进去的呢?这里就是AOP该发挥作用的时候了,直接看代码
1 | java复制代码public class ApiHandler { |
不想看代码的,直接看下图,原理比较简单,浅黄色为AOP作用,接口执行前和执行后,其中reqeuest和header的定义在第1段代码
这里没有介绍如何收集数据和查询展示,比较简单的办法是使用logback打本地日志,然后通过agent抽到集中式日志进行查询展示,例如ELK。
测试一下结果:
1、接口文档
2、执行结果
本文转载自: 掘金