概述
“ 微服务熔断,是当微服务中某个子服务,发生异常不可用,其他服务在进行远程调用时不能正常访问而一直占用资源,导致正常的服务也发生资源不能释放而崩溃,这时为了不造成整个微服务群瘫痪,进行的保护机制”
01 关于微服务熔断,意想不到的实验结果
我们基于SpringCloud,搭了一个简单的微服务场景,应用A调B,在A的测试接口上设置了Hystrix熔断器,熔断超时时间是1s,如下图:
你是否知道:
- 这个熔断超时时间指的是A接口的执行时间,还是仅A调用B的调用时间?
- A、B执行逻辑计算的时间都设置了500ms,熔断超时时间是1s,熔断器未开启时,A是否能拿到B的返回结果?
- A接口超时、抛Exception这两种场景都能触发它的降级熔断,底层触发逻辑有什么不一样?看似同步的请求竟然是通过异步线程来实现的?
- 当A触发熔断器开启后,它是否还能成功调用到B接口?难道就这样让用户一直失败
实验结果究竟如何,我们一起往下看。(心急的小伙伴可以直接滑到文末,查看答案~)
02 可视化熔断实验的demo介绍
本次实验,基于SpringCloud,Eureka作为注册中心,单机部署,采用OpenFeign实现RPC调用,Hystrix实现熔断机制,下面是应用A(即consumer)的测试接口代码:
我们借助Kindling程序摄像头,它能够查看分析一次请求调用下的所有线程的工作情况记录的能力,来看下实验结果。
03 实验1: 当A未接入断路器,A调用B的线程分析
当A未接入断路器,请求是通过执行线程exec来执行,请求开始,打了A开始Sleep的日志,A sleep 500ms之后,又打了开始调用B(即producter)的日志,最后拿到B的执行结果,请求结束。(关于kindling摄像头程序操作手册:http://www.kindling.space:33215/project-3/doc-94/)
04 实验2: 当A接入断路器,A调用B的线程分析
当A接入断路器后,执行线程exec上没有打执行日志了,反而是多了一个hystrix-ConsumerController线程,打了A开始sleep的日志。
接着又由这个线程sleep500ms,再调用B,但是我们在这个线程上找不到net B的请求事件,我们可以看到,是由另外一个线程hystrix-producter来和B建立网络连接。
但是我们点击这个线程,查看它从B读到的执行结果,它能拿到正常的返回结果:
但是,我们发现最后A返回给用户的报文却是:
其实这就是A接口上的熔断超时时间在起作用,如下图,Asleep了500ms,B也执行了500ms,再加上系统调用等时间开销,A接口的执行时间肯定会超过我们设置的熔断超时时间是1s,所以,Hystrix上的Timer线程,监测到时间超时,进入了降级服务。
05 实验3: 当A接入断路器,B直接返回Exception,线程分析
这个实验,我们让B不再执行500ms,而是直接返回Exception,也就是说,A不会再因为超时而进入降级服务。同样的,它也是由多个Hystrix线程执行业务,但是和上一个实验中,Timer线程监测到超时而触发降级的情况不同,这里是由hystrix-consumerController直接触发降级。
虽然最后这两个实验都是进入了降级服务,但是通过Kindling程序摄像头我们就能清楚的看到,它是怎么被触发降级的。
06 Hystrix配置讲解
07 实验4: 当A接入断路器,且触发熔断后,请求调用情况
当A熔断器开启,所有请求直接返回降级结果,如下图:
但是等过了熔断时间窗口期,我们发现,Hystrix有让一少部分请求正常执行:
这就是熔断器的自我恢复机制,熔断器一共有三种状态,断开后,过了时间窗口期,它就会允许一部分请求进行尝试,如果成功次数达到阈值,熔断器就会关闭,服务恢复。
最后总结一下开篇疑问:
- 熔断超时时间指的是接口的执行时间
- 接口超时是有HystrixTimer线程定时监测到时间超时,触发的降级,而接口异常是通过Hystrix执行线程触发降级
- 熔断器触发之后,过了窗口时间,熔断器会允许少部分请求正常执行,尝试自我恢复
- Hystrix的底层用的也是线程池,一个线程执行业务,一个线程做网络调用,还有个线程做超时检测
以上就是本次分享的内容,你还想通过Kindling摄像头观测到什么场景的知识?微服务雪崩?Java锁?Java分布式?线程安全?线程池调优?Redis集群机制?欢迎添加微信好友告诉小编~
最后
以上就是追寻机器猫为你收集整理的眼见为实:关于微服务熔断这几个知识点,你可能理解错了的全部内容,希望文章能够帮你解决眼见为实:关于微服务熔断这几个知识点,你可能理解错了所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复