• 中文
    • English
  • 注册
  • 查看作者
  • Java可视化实验:5分钟理解微服务熔断,就是这么简单一回事

     微服务熔断,是当微服务中某个子服务,发生异常不可用,其他服务在进行远程调用时不能正常访问而一直占用资源,导致正常的服务也发生资源不能释放而崩溃,这时为了不造成整个微服务群瘫痪,进行的保护机制

    01 关于微服务熔断,意想不到的实验结果

    我们基于SpringCloud,搭了一个简单的微服务场景,应用A调B,在A的测试接口上设置了Hystrix熔断器,熔断超时时间是1s,如下图:

    Java可视化实验:5分钟理解微服务熔断,就是这么简单一回事

    你是否知道:

    • 这个熔断超时时间指的是A接口的执行时间,还是仅A调用B的调用时间?

    • A、B执行逻辑计算的时间都设置了500ms,熔断超时时间是1s,熔断器未开启时,A是否能拿到B的返回结果?

    • A接口超时、抛Exception这两种场景都能触发它的降级熔断,底层触发逻辑有什么不一样?看似同步的请求竟然是通过异步线程来实现的?

    • 当A触发熔断器开启后,它是否还能成功调用到B接口?难道就这样让用户一直失败

    实验结果究竟如何,我们一起往下看。(心急的小伙伴可以直接滑到文末,查看答案~)

    02 可视化熔断实验的demo介绍

    本次实验,基于SpringCloud,Eureka作为注册中心,单机部署,采用OpenFeign实现RPC调用,Hystrix实现熔断机制,下面是应用A(即consumer)的测试接口代码:

    Java可视化实验:5分钟理解微服务熔断,就是这么简单一回事

    我们借助Kindling程序摄像头,它能够查看分析一次请求调用下的所有线程的工作情况记录的能力,来看下实验结果。

    03 实验1: 当A未接入断路器,A调用B的线程分析

    当A未接入断路器,请求是通过执行线程exec来执行,请求开始,打了A开始Sleep的日志,A sleep 500ms之后,又打了开始调用B(即producter)的日志,最后拿到B的执行结果,请求结束。(关于kindling摄像头程序操作手册: )

    Java可视化实验:5分钟理解微服务熔断,就是这么简单一回事

    Java可视化实验:5分钟理解微服务熔断,就是这么简单一回事

    04 实验2: 当A接入断路器,A调用B的线程分析

    当A接入断路器后,执行线程exec上没有打执行日志了,反而是多了一个hystrix-ConsumerController线程,打了A开始sleep的日志。

    Java可视化实验:5分钟理解微服务熔断,就是这么简单一回事

    接着又由这个线程sleep500ms,再调用B,但是我们在这个线程上找不到net B的请求事件,我们可以看到,是由另外一个线程hystrix-producter来和B建立网络连接。

    Java可视化实验:5分钟理解微服务熔断,就是这么简单一回事

    但是我们点击这个线程,查看它从B读到的执行结果,它能拿到正常的返回结果:

    Java可视化实验:5分钟理解微服务熔断,就是这么简单一回事

    但是,我们发现最后A返回给用户的报文却是:

    Java可视化实验:5分钟理解微服务熔断,就是这么简单一回事

    其实这就是A接口上的熔断超时时间在起作用,如下图,Asleep了500ms,B也执行了500ms,再加上系统调用等时间开销,A接口的执行时间肯定会超过我们设置的熔断超时时间是1s,所以,Hystrix上的Timer线程,监测到时间超时,进入了降级服务。

    Java可视化实验:5分钟理解微服务熔断,就是这么简单一回事

    Java可视化实验:5分钟理解微服务熔断,就是这么简单一回事

    05 实验3: 当A接入断路器,B直接返回Exception,线程分析

    这个实验,我们让B不再执行500ms,而是直接返回Exception,也就是说,A不会再因为超时而进入降级服务。同样的,它也是由多个Hystrix线程执行业务,但是和上一个实验中,Timer线程监测到超时而触发降级的情况不同,这里是由hystrix-consumerController直接触发降级。

    Java可视化实验:5分钟理解微服务熔断,就是这么简单一回事

    虽然最后这两个实验都是进入了降级服务,但是通过Kindling程序摄像头我们就能清楚的看到,它是怎么被触发降级的。

    06 Hystrix配置讲解

    Java可视化实验:5分钟理解微服务熔断,就是这么简单一回事

    再回到配置这里,刚才实验中提到的熔断超时时间就是通过上图中,红框里的配置实验的,另外,第1条配置是Hystrix的开关。第2、3、4条配置是一起的,我这里配置的意思是:当10s内,接口的请求次数达到10次,且失败率在60%以上,就会触发熔断。

    07 实验4: 当A接入断路器,且触发熔断后,请求调用情况

    当A熔断器开启,所有请求直接返回降级结果,如下图:

    Java可视化实验:5分钟理解微服务熔断,就是这么简单一回事

    但是等过了熔断时间窗口期,我们发现,Hystrix有让一少部分请求正常执行:

    Java可视化实验:5分钟理解微服务熔断,就是这么简单一回事

    这就是熔断器的自我恢复机制,熔断器一共有三种状态,断开后,过了时间窗口期,它就会允许一部分请求进行尝试,如果成功次数达到阈值,熔断器就会关闭,服务恢复。

    Java可视化实验:5分钟理解微服务熔断,就是这么简单一回事

    最后总结一下开篇疑问:

    • 熔断超时时间指的是接口的执行时间

    • 接口超时是有HystrixTimer线程定时监测到时间超时,触发的降级,而接口异常是通过Hystrix执行线程触发降级

    • 熔断器触发之后,过了窗口时间,熔断器会允许少部分请求正常执行,尝试自我恢复

    • Hystrix的底层用的也是线程池,一个线程执行业务,一个线程做网络调用,还有个线程做超时检测

    以上就是本次分享的内容,你还想通过Kindling摄像头观测到什么场景的知识?微服务雪崩?Java锁?Java分布式?线程安全?线程池调优?Redis集群机制?欢迎添加微信好友告诉小编~

    Java可视化实验:5分钟理解微服务熔断,就是这么简单一回事

  • 0
  • 0
  • 0
  • 10
  • 请登录之后再进行评论

    登录
  • 任务
  • 实时动态
  • 发布
  • 单栏布局 侧栏位置: