》微服务熔断是当一个微服务中的一个子服务异常??不可用，其他服务在进行远程调用时无法正常访问并一直占用资源，导致正常的服务因资源无法释放而崩溃。此时时间，为了不导致整个微服务组瘫痪，实现了一个保护机制。创建一个简单的微服务场景，应用A调用B，在A的测试接口设置一个Hystrix熔断器，熔断超时时间为1s，如下图：你知道吗：这个熔断超时是指A接口的执行时间，还是只在A调用B的时候？A和B执行逻辑计算的时间设置为500ms，并且fuse超时时间为1s，在没有开启熔断的情况下，A是否可以获取到B的返回结果？A接口超时和抛出Exception两种场景都可以触发其降级熔断器，底层触发逻辑有什么区别？看似同步的请求，实际上是通过异步线程实现的？当A触发熔断器打开后，是否还能成功调用B接口？难道只是为了让用户一直失败吗？一起往下看吧。（着急的小伙伴可以直接滑到文末查看答案~）02视觉熔断实验demo介绍本次实验，基于SpringCloud，Eureka为注册中心，单机部署，使用OpenFeign实现RPC调用，Hystrix实现熔断机制。以下是应用A（即消费者）的测试接口代码：我们使用Kindling程序camera，可以查看和分析一次请求调用下所有线程的工作状态记录，下面看一下实验结果。03实验一：当A未连接断路器时，A调用B的线程解析当A未连接断路器时，通过执行线程exec执行请求，请求启动，A启动sleeplog，Asleep500mslater，然后打出开始调用B（即producter）的log，最后得到B的执行结果，请求结束。（关于kindling相机程序操作手册：http://www.kindling.space:332...）04实验二：A连接断路器时，A调用B的线程解析A连接断路器时，执行线程exec上没有执行日志。而是多了一个hystrix-ConsumerController线程，A启动睡眠日志。然后这个线程休眠500ms，然后调用B，但是我们在这个线程上找不到netB的请求事件。我们可以看到另一个线程hystrix-product与B建立了网络连接。但是我们点击这个线程查看它从B读取的执行结果，可以得到正常的返回结果：但是，我们发现最后返回的消息A给用户的是：其实这个是A接口上的熔断超时时间是起作用的，如下图，Asleep用了500ms，B也执行了500ms，加上系统调用的时间开销，执行A接口的时间肯定会超过我们设置的熔断超时时间，即1s，所以Hystrix上的Timer线程，检测到超时，进入降级服务。05实验三：当A接入断路器后，B直接返回Exception，线程分析本次实验，我们让B不再执行500ms，而是直接返回Exception，也就是说A不再进入降级服务由于超时。同理，也是由多个Hystrix线程执行，但与之前实验Timer线程检测到超时触发降级不同，这里hystrix-consumerController直接触发降级。虽然最后两个实验进入了降级服务，但是我们可以通过Kindling程序摄像头清楚的看到是如何触发降级的。06Hystrix配置详解我们回到配置上来。刚才实验中提到的熔断超时时间是通过上图红框中的配置实验得到的。另外，首先配置的是Hystrix的开关。项目2、3和4一起配置。我这里的配置是当10秒内请求接口达到10次，失败率在60%以上时，就会触发熔断。07实验四：当A接入断路器触发熔断器时，请求调用情况当A熔断器开启时，所有请求直接返回降级结果，如下图所示：但在熔断时间后窗口期，我们发现Hystrix已经允许少量请求正常执行：这就是熔断器的自愈机制。保险丝有三种状态。时间窗口被打破后，它会允许一些请求被尝试。如果成功次数达到阈值，熔断器将被打破。服务器关闭，服务恢复。最后总结一下开题：熔断超时时间是指接口的执行时间。接口超时是HystrixTimer线程触发的超时，接口异常是Hystrix执行线程触发的。熔断器触发后，窗口已过。时间，熔断器会让少量的请求正常执行，尝试自愈的Hystrix底层也使用了线程池。一个线程执行业务，一个线程进行网络调用，另一个线程做超时检测。以上就是本次分享的内容。你还想通过Kindling相机观察什么场景？微服务雪崩？爪哇锁？Java分布式？线程安全？线程池调优？Redis集群机制？欢迎加微信好友告诉小编~
