Java 实现分布式服务的调用链跟踪

目录
  • 为什么要实现调用链跟踪?
  • 如何实现?
    • 第一步,看图、看场景,用户浏览器的一次请求行为所走的路径是什么样的
    • 第二步,实现。不想看代码可直接拉最后看结果和原理
  • 测试一下结果:

为什么要实现调用链跟踪?

随着业务的发展,所有的系统最终都会走向服务化体系,微服务的目的一是提高系统的稳定性,二是提高持续交付的效率,为什么能提高这两项不是今天讨论的内容。

当然这也不是绝对的,如果业务还在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 分布式服务的调用链跟踪的资料请关注我们其它相关文章!

(0)

相关推荐

  • Java分布式session存储解决方案图解

    前言 本文主要探讨集群后不同Web服务器获取Session数据的问题解决方案. Session Stick Session Stick 方案即将客户端的每次请求都转发至同一台服务器,这就需要负载均衡器能够根据每次请求的会话标识(SessionId)来进行请求转发,如下图所示. 这种方案实现比较简单,对于Web服务器来说和单机的情况一样.但是可能会带来如下问题: 如果有一台服务器宕机或者重启,那么这台机器上的会话数据会全部丢失. 会话标识是应用层信息,那么负载均衡要将同一个会话的请求都保存到同一个

  • Java实现Twitter的分布式自增ID算法snowflake

    概述 分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的. 有些时候我们希望能使用一种简单一些的ID,并且希望ID能够按照时间有序生成. 而twitter的snowflake解决了这种需求,最初Twitter把存储系统从MySQL迁移到Cassandra,因为Cassandra没有顺序ID生成机制,所以开发了这样一套全局唯一ID生成服务. 结构 snowflake的结构如下(每部分用

  • Java基于redis实现分布式锁

    为了保证一个在高并发存场景下只能被同一个线程操作,java并发处理提供ReentrantLock或Synchronized进行互斥控制.但是这仅仅对单机环境有效.我们实现分布式锁大概通过三种方式. redis实现分布式锁 数据库实现分布式锁 zk实现分布式锁 实际上这三种和java对比看属于一类.都是属于程序外部锁. 原理剖析 上述三种分布式锁都是通过各自为依据对各个请求进行上锁,解锁从而控制放行还是拒绝.redis锁是基于其提供的setnx命令. setnx当且仅当key不存在.若给定key已

  • Java基于redis实现分布式锁代码实例

    为什么会有这个需求: 例如一个简单用户的操作,一个线程去修改用户状态,首先在在内存中读出用户的状态,然后在内存中进行修改,然后在存到数据库中.在单线程中,这是没有问题的.但是在多线程中由于读取,修改,写入是三个操作,不是原子操作(同时成功或失败),因此在多线程中会存在数据的安全性问题. 这个问题的话,就可以用分布式锁在限制程序的并发执行. 实现思路: 就是进来一个先占位,当别的线程进来操作的时候,发现有人占位了,就会放弃或者稍后再试. 占位的实现: 在redis中的setnx命令来实现,redi

  • 详解Java分布式Session共享解决方案

    分布式Session一致性? 说白了就是服务器集群Session共享的问题 Session的作用? Session 是客户端与服务器通讯会话跟踪技术,服务器与客户端保持整个通讯的会话基本信息. 客户端在第一次访问服务端的时候,服务端会响应一个sessionId并且将它存入到本地cookie中,在之后的访问会将cookie中的sessionId放入到请求头中去访问服务器,如果通过这个sessionid没有找到对应的数据那么服务器会创建一个新的sessionid并且响应给客户端. 分布式Sessio

  • Java Redis分布式锁的正确实现方式详解

    前言 分布式锁一般有三种实现方式:1. 数据库乐观锁:2. 基于Redis的分布式锁:3. 基于ZooKeeper的分布式锁.本篇博客将介绍第二种方式,基于Redis实现分布式锁.虽然网上已经有各种介绍Redis分布式锁实现的博客,然而他们的实现却有着各种各样的问题,为了避免误人子弟,本篇博客将详细介绍如何正确地实现Redis分布式锁. 可靠性 首先,为了确保分布式锁可用,我们至少要确保锁的实现同时满足以下四个条件: 互斥性.在任意时刻,只有一个客户端能持有锁. 不会发生死锁.即使有一个客户端在

  • Java中实现分布式定时任务的方法

    定时器Scheduler在平时使用比较频繁,在springboot中,配置好@Scheduled和@EnableScheduling之后,定时器就能正常执行,实现定时任务的功能. 但是在这样的情况下:如果开发的服务需要水平部署实现负载均衡,那么定时任务就会同时在多个服务实例上运行,那么一方面,可能由于定时任务的逻辑处理需要访问公共资源从而造成并发问题:另一方面,就算没有并发问题,那么一个同样的任务多个服务实例同时执行,也会造成资源的浪费.因此需要一种机制来保证多个服务实例之间的定时任务正常.合理

  • 浅谈Java分布式架构下如何实现分布式锁

    01分布式锁运用场景 互联网秒杀,抢优惠卷,接口幂等性校验.咱们以互联网秒杀为例. @RestController @Slf4j publicclassIndexController{ @Autowired privateRedissonredission; @Autowired privateStringRedisTemplatestringRedisTemplate; @RequestMapping("/deduct_stock") publicStringdeductStock(

  • 详解Java分布式系统中一致性哈希算法

    业务场景 近年来B2C.O2O等商业概念的提出和移动端的发展,使得分布式系统流行了起来.分布式系统相对于单系统,解决了流量大.系统高可用和高容错等问题.功能强大也意味着实现起来需要更多技术的支持.例如系统访问层的负载均衡,缓存层的多实例主从复制备份,数据层的分库分表等. 我们以负载均衡为例,常见的负载均衡方法有很多,但是它们的优缺点也都很明显: 随机访问策略.系统随机访问,缺点:可能造成服务器负载压力不均衡,俗话讲就是撑的撑死,饿的饿死. 轮询策略.请求均匀分配,如果服务器有性能差异,则无法实现

  • Java redisson实现分布式锁原理详解

    Redisson分布式锁 之前的基于注解的锁有一种锁是基本redis的分布式锁,锁的实现我是基于redisson组件提供的RLock,这篇来看看redisson是如何实现锁的. 不同版本实现锁的机制并不相同 引用的redisson最近发布的版本3.2.3,不同的版本可能实现锁的机制并不相同,早期版本好像是采用简单的setnx,getset等常规命令来配置完成,而后期由于redis支持了脚本Lua变更了实现原理. <dependency> <groupId>org.redisson&

  • 详解Java TCC分布式事务实现原理

    概述 之前网上看到很多写分布式事务的文章,不过大多都是将分布式事务各种技术方案简单介绍一下.很多朋友看了还是不知道分布式事务到底怎么回事,在项目里到底如何使用. 所以这篇文章,就用大白话+手工绘图,并结合一个电商系统的案例实践,来给大家讲清楚到底什么是 TCC 分布式事务. 业务场景介绍 咱们先来看看业务场景,假设你现在有一个电商系统,里面有一个支付订单的场景. 那对一个订单支付之后,我们需要做下面的步骤: 更改订单的状态为"已支付" 扣减商品库存 给会员增加积分 创建销售出库单通知仓

  • 详解Java分布式系统中session一致性问题

    业务场景 在单机系统中,用户登陆之后,服务端会保存用户的会话信息,只要用户不退出重新登陆,在一段时间内用户可以一直访问该网站,无需重复登陆.用户的信息存在服务端的 session 中,session中可以存放服务端需要的一些用户信息,例如用户ID,所属公司companyId,所属部门deptId等等. 但是随着业务的发展,技术架构需要调整,原来的单机系统逐渐被更换,架构由单机扩展到分布式,甚至当下流行的微服务.虽然在用户端看来系统仍然是一个整体,但在技术端来说业务则被拆分成多个模块,各个模块之间

随机推荐