目录为什么要实现调用链跟踪？如何实现？第一步，看图、看场景，用户浏览器的一次请求行为所走的路径是什么样的第二步，实现。不想看代码可直接拉最后看结果和原理测试一下结果：
为什么要实现调用链跟踪？
随着业务的发展，所有的系统最终都会走向服务化体系，微服务的目的一是提高系统的稳定性，二是提高持续交付的效率，为什么能提高这两项不是今天讨论的内容。
当然这也不是绝对的，如果业务还在MVP验证，团队规模小个人觉得完全没必要微服务化、单体应用是比较好的选择。作者是有经历过从单体应用到1000+应用的增长经历，也是见证了公司从初创到上市的过程，对于系统阶段和业务阶段的匹配还是有比较深的感受的。
服务拆分后带来的问题是什么呢？服务的依赖关系复杂后，对于问题的排查也增加了复杂度，当然站在更高的角度来看拆分带来的不只是排错复杂性的提升，工程效率、组织协作也都会带来新的挑战。
回到主题，如何快速查询整个请求链路上的日志并呈现出来是解决排查问题复杂度的根本方法，这就是今天我们要讲的内容，如何自己来实现一个全链路跟踪。
如何实现？
第一步，看图、看场景，用户浏览器的一次请求行为所走的路径是什么样的
如上图、省略了4层和7层的LB，请求直接到gateway->A->B 那如何把个request关联起来呢？从时序上来看我们只要在gateway生成一个traceId然后层层透传，那么每一次的request的我们就能通过traceid关联查询出来了。如何透传、如何记录呢？或者说如何透传、如何记录让各应用的开发人员无需关注呢？
第二步，实现。不想看代码可直接拉最后看结果和原理
如何传递，这里我们使用定义统一的Request类，所有的api层需要使用这个规范，代码如下：
public class Request<T> implements Serializable { //header：携带需要传递的信息 private RequestHeader header; //业务参数 private T bizModel; //...省略get set}public class RequestHeader implements Serializable { //调用链唯一ID private String traceId; //当前用户Id private String userId; //上游调用方appId private String callAppId; //...省略get set}
有了这个Request之后，我们在网关层每次都生成traceId, 然后在各服务之间传递就能做到调用链的关联了。我们继续看个各应用应该如何定义服务和使用
@ApiMethod @PostMapping("/test") @ApiOperation(value = "test", notes = "", response = String.class) public Response<ExampleRespDTO> test(@RequestBody Request<ExampleReqDTO> req) { ExampleRespDTO exampleRespDTO = new ExampleRespDTO(); exampleRespDTO.setName(req.getBizModel().getName()); //输出当前应用的header信息 System.out.println("上游的traceId："+RequestContext.getHeader().getTraceId()); System.out.println("上游的callAppId："+RequestContext.getHeader().getCallAppId()); System.out.println("上游的userId："+RequestContext.getHeader().getUserId()); /*** * 模拟调用其他应用服务 * 通过RPCRequest 来构建request对象 */ Request<OtherAppServiceReqDTO> otherAppServiceReqDTORequest =RPCRequest.createRequest(new OtherAppServiceReqDTO()); //输出下游应用的header信息 System.out.println("调用下游的traceId："+otherAppServiceReqDTORequest.getHeader().getTraceId()); System.out.println("调用下游的callAppId："+otherAppServiceReqDTORequest.getHeader().getCallAppId()); System.out.println("调用下游的userId："+otherAppServiceReqDTORequest.getHeader().getUserId()); return Response.successResponse(exampleRespDTO); }
看完上面代码的同学，应该看到了有一个模拟调用其他服务的地方，这里主要解决的是服务和服务之间的调用header传递的问题，这里封装了一个createRequest的方法，其主要内容还是把当前应用的requestHeader 赋值给请求其他服务的request上。这也是一个测试接口，最后面有测试的结果
public class RPCRequest { public static <T> Request<T> createRequest(T requestData){ Request<T> request = new Request(); RequestHeader requestHeader=new RequestHeader(); requestHeader.setTraceId(RequestContext.getHeader().getTraceId()); requestHeader.setUserId(RequestContext.getHeader().getUserId()); requestHeader.setCallAppId(AppConfig.CURRENT_APP_ID); request.setHeader(requestHeader); request.setBizModel(requestData); return request; }}
当前request中的header存在什么地方呢，我们看一下RequestContext的代码
public class RequestContext { private static ThreadLocal<RequestHeader> threadLocal=new ThreadLocal<>(); public static void setHeader(RequestHeader header){ threadLocal.set(header); } public static RequestHeader getHeader(){ return threadLocal.get(); } public static void clear(){ threadLocal.remove(); }}
header是什么时候放进去的呢？这里就是AOP该发挥作用的时候了，直接看代码
public class ApiHandler { public ApiHandler() { } public Response handleApiMethod(ProceedingJoinPoint pjp, ApiMethod apiMethod) { //获取上游调用方的request header Object[] args = pjp.getArgs(); Request request = (Request) args[0]; RequestHeader header = request.getHeader(); //将header加入到当前request 到ThreadLocal保存 RequestContext.setHeader(header); Response response = null; try { //构建response header ResponseHeader responseHeader = new ResponseHeader(); responseHeader.setTraceId(RequestContext.getHeader().getTraceId()); //执行service方法 response = (Response) pjp.proceed(args); response.setHeader(responseHeader); } catch (Throwable throwable) { throwable.printStackTrace(); }finally { //清除ThreadLocal中当前请求的header 对象 RequestContext.clear(); } return response; }}
不想看代码的，直接看下图，原理比较简单，浅黄色为AOP作用，接口执行前和执行后，其中reqeuest和header的定义在第1段代码
这里没有介绍如何收集数据和查询展示，比较简单的办法是使用logback打本地日志，然后通过agent抽到集中式日志进行查询展示，例如ELK。
测试一下结果：
1、接口文档
2、执行结果
以上就是Java 实现分布式服务的调用链跟踪的详细内容，更多关于Java 分布式服务的调用链跟踪的资料请关注其它相关文章！
即使爬到最高的山上，一次也只能脚踏实地地迈一步。
