Hystrix断路器

1. 概述

1. 分布式系统面临的问题

复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败。这就造成有可能会发生服务雪崩。那么什么是服务雪崩呢？

多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的“扇出”（向一把打开的折扇）。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，这就是所谓的”雪崩效应“。也就是系统的 高可用 受到了破坏。

对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源在几秒内饱和。比失败更糟的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发送更过的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便 单个依赖关系的失败，不能取消整个应用程序或系统。

所以，通常当发现一个模块下的某个实例失败后，这时候这个模块依然还会接受流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫做雪崩。而面对这种糟糕的问题，我们就应该采取 服务降级、服务熔断 等方式来解决。

2. Hystrix是什么

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整个服务失败，避免级联故障，以提高分布式系统的弹性。

“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似于物理的熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

3. Hystrix能做什么？

主要有服务降级、服务熔断、接近实时的监控、限流、隔离等等，其官方文档参考。当然Hystrix现在已经停更了，虽然有一些替代品，但是学习Hystrix及其里面的思想还是非常重要的！

2. Hystrix重要概念

1. 服务降级——Fall Back

假设微服务A要调用的服务B不可用了，需要服务B提供一个兜底的解决方法，而不是让服务A在那里傻等，耗死。不让客户端等待并立刻返回一个友好图示，比如像客户端提示服务器忙，请稍后再试等。哪些情况会触发服务降级呢？

比如程序运行异常、超时、服务熔断触发服务降级、线程池/信号量打满也会导致服务降级。

2. 服务熔断——Break

服务熔断就相当于物理上的熔断保险丝。类比保险丝达到最大服务访问后，直接拒绝访问，拉闸断点，然后调用服务降级的方法并返回友好提示。

3. 服务限流——Flow Limit

秒杀高并发等操作，严禁一窝蜂的过来拥挤，大家排队，一秒钟N个，有序进行。

3. Hystrix案例实操

1. 构建

新建一个Module：cloud-provider-hystrix-payment8001作为服务提供方的微服务，和之前的服务消费方同样选择8001端口，但是在POM文件中需要引入Hystrix的依赖：

<!--hystrix-->
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

然后编写其配置文件，端口号为8001，服务名为cloud-provider-hystrix-payment，以使其入驻服务注册中心。然后编写其主启动类，在SpringCloud-01Eureka服务注册与发现都有详细介绍过，之后编写其业务类，service编写入下：

package cn.sher6j.springcloud.service;import org.springframework.stereotype.Service;import java.util.concurrent.TimeUnit;/*** 应该要先写接口，再写实现类，这里为了节约时间，直接用实现类了* @author sher6j* @create 2020-05-21-17:29*/
@Service
public class PaymentService {/*** 正常访问* @param id* @return*/public String paymentInfo_OK(Long id) {return "线程池： " + Thread.currentThread().getName() + " paymentInfo_OK, id: " + id;}/*** 模拟复杂业务需要3秒钟* @param id* @return*/public String paymentInfo_TimeOut(Long id) {int time = 3;//暂停几秒钟线程，程序本身没有错误，就是模拟超时try {TimeUnit.SECONDS.sleep(time);} catch (InterruptedException e) {e.printStackTrace();}return "线程池： " + Thread.currentThread().getName() + " paymentInfo_TimeOut, id: " + id;}
}

Controller编写入下：

package cn.sher6j.springcloud.controller;import cn.sher6j.springcloud.service.PaymentService;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;/*** @author sher6j* @create 2020-05-21-17:34*/
@RestController
@Slf4j
public class PaymentController {@Autowiredprivate PaymentService paymentService;@Value("${server.port}")private String serverPort;@GetMapping("/payment/hystrix/ok/{id}")public String paymentInfo_OK(@PathVariable("id") Long id) {String result = paymentService.paymentInfo_OK(id);log.info("========result:" + result);return result;}@GetMapping("/payment/hystrix/timeout/{id}")public String paymentInfo_TimeOut(@PathVariable("id") Long id) {String result = paymentService.paymentInfo_TimeOut(id);log.info("========result:" + result);return result;}
}

也就是说cloud-provider-hystrix-payment服务提供了两个方法，paymentInfo_OK 方法可以很快访问，paymentInfo_TimeOut 方法我们模拟了一个复杂的业物逻辑，通过线程休眠的方式使其模拟一个需要执行3秒的服务方法。

在启动了注册中心和8001服务后，我们对服务的 paymentInfo_OK（下面用OK代替）和 paymentInfo_TimeOut （下面用TO代替）分别进行访问，我们发现，http://localhost:8001/payment/hystrix/ok/1 可以很快的访问，而http://localhost:8001/payment/hystrix/timeout/1 每次访问大约需要3秒的时间。

2. 高并发测试

1. 服务提供方自测压力测试：

需要3秒的复杂业务逻辑 TO 访问时，需要时间很少的 OK 是完全可以正常访问的，但是在高并发的情况下，也就是说 TO 有很多访问量的时候，OK 还能够这么正常的访问吗？下面我们用 Jmeter 进行高并发压力测试，用20000个请求都去访问 TO 服务，在 Jmeter 中新建一个线程组：测试Hystrix用来模拟高并发访问 TO 服务，线程组配置参数如下：

然后我们用该线程组发送HTTP请求给 TO 服务，创建如下的HTTP请求进行压力测试：

我们观察8001服务的后端控制台，可以看到对 TO 服务进行了大量的访问：

而此时我们再去访问 OK 服务时什么样的呢？？

可以看到，OK 服务无妨像之前一样很快能够得到访问，这里我们模拟的是20000的访问量（没敢模拟数字太大的访问量，怕把系统直接搞死哈哈哈哈），实际中可能会有远大于20000的访问量，当访问量更多的时候，甚至可能卡死服务，原因就是Tomcat的默认的工作线程数被打满了，没有多余的线程来分解压力和处理。

而刚才做的压力测试还只是服务提供方8001自己实现的测试，如果此时是外部的服务消费方80来访问该服务，那么服务消费方只能够进行干等，消费方显然会对这样的等待时间不满意，服务提供方很有可能直接被拖死。我们发现8001自测都会出现问题，那如果我们再用服务消费方测试呢？

2.服务消费方进行压力测试：

新建一个Module：cloud-consumer-feign-hystrix-order80作为服务消费方，服务消费方利用feign访问提供方的服务，编写对应的service接口如下：

package cn.sher6j.springcloud.service;import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.stereotype.Component;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;/*** @author sher6j* @create 2020-05-21-20:00*/
@Component
@FeignClient("CLOUD-PROVIDER-HYSTRIX-PAYMENT")
public interface PaymentHystrixService {@GetMapping("/payment/hystrix/ok/{id}")public String paymentInfo_OK(@PathVariable("id") Long id);@GetMapping("/payment/hystrix/timeout/{id}")public String paymentInfo_TimeOut(@PathVariable("id") Long id);
}

然后编写其Controller：

package cn.sher6j.springcloud.controller;import cn.sher6j.springcloud.service.PaymentHystrixService;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;/*** @author sher6j* @create 2020-05-21-20:02*/
@RestController
@Slf4j
public class OrderHystrixController {@Autowiredprivate PaymentHystrixService paymentHystrixService;@GetMapping("/consumer/payment/hystrix/ok/{id}")public String paymentInfo_OK(@PathVariable("id") Long id) {String result = paymentHystrixService.paymentInfo_OK(id);return result;}@GetMapping("/consumer/payment/hystrix/timeout/{id}")public String paymentInfo_TimeOut(@PathVariable("id") Long id) {String result = paymentHystrixService.paymentInfo_TimeOut(id);return result;}
}

将80服务启动，用http://localhost/consumer/payment/hystrix/ok/1 对服务提供方的 OK 服务进行访问，再进行压力测试，和之前一样，无法迅速访问该服务，如果压力测试中的线程数更多的时候，很可能会造成超时错误，出现以下错误提示：

故障原因：8001同一层次的其他接口服务被困死，因为Tomcat线程池里面的工作线程已经被挤占完毕，80此时再调用8001，必然导致客户端访问响应缓慢。正是因为出现了这种现象，所以我们才需要服务降级、容错、服务限流等技术。

3. 服务降级Fall Back

1. 服务端服务提供方的服务降级

降级的配置用 @HystrixCommand 注解，在服务提供方自身找问题，设置自身调用超时时间的峰值，在峰值内可以正常运行，超过了峰值需要有兜底的方法处理，用作服务降级。

首先在服务提供方的业务类上启用 @HystrixCommand 实现报异常后如何处理，也就是一旦调用服务方法失败并抛出了错误信息后，会自动调用 @HystrixCommand 标注好的fallbackMethod服务降级方法。在服务提供方的service中我们修改 TO 服务：

    /*** 模拟复杂业务需要3秒钟* HystrixCommand配置2秒以内走正常的逻辑，超过2秒走服务降级逻辑* @param id* @return*///设置服务降级方法为paymentInfo_TimeOutHandler，超时峰值为2秒@HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler", commandProperties = {@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "2000")})public String paymentInfo_TimeOut(Long id) {int time = 3;//暂停几秒钟线程，程序本身没有错误，就是模拟超时try {TimeUnit.SECONDS.sleep(time);} catch (InterruptedException e) {e.printStackTrace();}return "线程池： " + Thread.currentThread().getName() + " paymentInfo_TimeOut, id: " + id;}/*** 兜底方法* @param id* @return*/public String paymentInfo_TimeOutHandler(Long id) {return "系统忙，请稍后再试";}

然后在主启动类上添加 @EnableCircuitBreaker 注解对熔断器进行激活，TO服务的访问时间3秒，而我们用Hystrix配置的时间峰值为2秒，也就是当服务超时或服务出错时，会访问我们设置的fallbackMethod服务降级方法，再次访问TO服务，我们发现其执行的方法确实为服务降级方法：

2. 客户端服务消费方的服务降级

既然服务的提供方可以进行降级保护，那么服务的消费方，也可以更好的保护自己，也可以对自己进行降级保护，也就是说Hystrix服务降级既可以放在服务端（服务提供方），也可以放在客户端（服务消费方），但是！！！通常是用客户端做服务降级，下面在服务消费方即客户端配置自己的服务降级保护，修改80消费方的配置文件，添加如下配置已使其支持Hystrix：

feign:hystrix:enabled: true

在80消费方的主启动类上添加 @EnableHystrix 激活Hystrix服务。然后在80的Controller中同样加入**@HystrixCommand**注解已实现服务降级：

    @GetMapping("/consumer/payment/hystrix/timeout/{id}")@HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler", commandProperties = {@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1500")})public String paymentInfo_TimeOut(@PathVariable("id") Long id) {String result = paymentHystrixService.paymentInfo_TimeOut(id);return result;}/*** 兜底方法* @param id* @return*/public String paymentInfo_TimeOutHandler(Long id) {return "系统忙，请稍后再试";}

也就是说如果消费方访问服务提供方的时间超过了1.5秒，那么就会访问自己的降级服务方法。

3. 统一全局服务降级方法

而当前的这种处理方式是有问题的，也就是每个业务方法都对应了一个服务降级犯法，这会导致代码膨胀，所以我们应该定义一个统一的服务降级方法，统一的方法和自定义的方法分开。而且我们将服务降级方法和业务逻辑混合在了一起，这会导致代码混乱，业务逻辑不清晰。

对于第一个问题，我们可以用feign接口中的 @DefaultProperties(defaultFallback = "") 注解来配置全局的服务降级方法，也就是说自己配置过**@HystrixCommand(fallbackMethod = “”）** fallbackMethod方法的采用自己配置的服务降级方法，而没有配置过的就采用**@DefaultProperties(defaultFallback = "")** 配置的全局的服务降级方法。这样的话通用的服务降级方法和独享的服务降级方法分开，避免了代码膨胀，合理减少了代码量，修改服务消费方80的Controller入下：

package cn.sher6j.springcloud.controller;import cn.sher6j.springcloud.service.PaymentHystrixService;
import com.netflix.hystrix.contrib.javanica.annotation.DefaultProperties;
import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
import com.netflix.hystrix.contrib.javanica.annotation.HystrixProperty;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;/*** @author sher6j* @create 2020-05-21-20:02*/
@RestController
@Slf4j
@DefaultProperties(defaultFallback = "payment_Global_FallbackMethod") //全局服务降级
public class OrderHystrixController {@Autowiredprivate PaymentHystrixService paymentHystrixService;@GetMapping("/consumer/payment/hystrix/ok/{id}")@HystrixCommandpublic String paymentInfo_OK(@PathVariable("id") Long id) {int i = 1/0; //手动模拟错误String result = paymentHystrixService.paymentInfo_OK(id);return result;}@GetMapping("/consumer/payment/hystrix/timeout/{id}")//定制服务降级@HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler", commandProperties = {@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1500")})public String paymentInfo_TimeOut(@PathVariable("id") Long id) {String result = paymentHystrixService.paymentInfo_TimeOut(id);return result;}/*** 定制服务降级方法* @param id* @return*/public String paymentInfo_TimeOutHandler(Long id) {return "定制异常处理信息";}/*** 全局服务降级方法* @return*/public String payment_Global_FallbackMethod() {return "全局异常处理信息";}
}

paymentInfo_TimeOut由于定制了降级服务，所以访问服务提供方会出现超时（服务提供方提供的服务执行时间超过1.5秒），而paymentInfo_OK我们用 int i = 1/0; 这行代码模拟了错误，分别访问http://localhost/consumer/payment/hystrix/timeout/1 和http://localhost/consumer/payment/hystrix/ok/1 ，我们得到如下结果：

可以看到由于paymentInfo_OK没有进行定制的服务降级方法，所以其访问的是全局服务降级方法，而paymentInfo_TimeOut访问的是定制服务降级方法，这里需要注意的是，无论是否配置了定制服务降级方法，都要在其服务上加入注解 @HystrixCommand，否则服务降级和该服务没关系，比如paymentInfo_OK如果没有加入该注解，就直接会报除数为0错误。

而对于第二个问题，我们可以为Feign客户端定义的接口添加一个服务降级处理的实现类即可实现解耦，我们的80客户端已经有了PaymentHystrixService接口，我们新建一个类PaymentFallbackService实现该接口，并重写接口中的方法，为接口里的方法进行异常处理，并且我们在PaymentHystrixService声明其服务降级方法所在的类：

package cn.sher6j.springcloud.service;import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.stereotype.Component;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;/*** @author sher6j* @create 2020-05-21-20:00*/
@Component
//当出现错误是到PaymentFallbackService类中找服务降级方法
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT", fallback = PaymentFallbackService.class)
public interface PaymentHystrixService {@GetMapping("/payment/hystrix/ok/{id}")public String paymentInfo_OK(@PathVariable("id") Long id);@GetMapping("/payment/hystrix/timeout/{id}")public String paymentInfo_TimeOut(@PathVariable("id") Long id);
}

package cn.sher6j.springcloud.service;import org.springframework.stereotype.Component;/*** @author sher6j* @create 2020-05-21-21:27*/
@Component
public class PaymentFallbackService implements PaymentHystrixService {@Overridepublic String paymentInfo_OK(Long id) {return "paymentInfo_OK出现异常";}@Overridepublic String paymentInfo_TimeOut(Long id) {return "paymentInfo_TimeOut出现异常";}
}

然后我们将Controller中耦合的代码都取消：

package cn.sher6j.springcloud.controller;import cn.sher6j.springcloud.service.PaymentHystrixService;
import com.netflix.hystrix.contrib.javanica.annotation.DefaultProperties;
import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
import com.netflix.hystrix.contrib.javanica.annotation.HystrixProperty;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;/*** @author sher6j* @create 2020-05-21-20:02*/
@RestController
@Slf4j
public class OrderHystrixController {@Autowiredprivate PaymentHystrixService paymentHystrixService;@GetMapping("/consumer/payment/hystrix/ok/{id}")public String paymentInfo_OK(@PathVariable("id") Long id) {String result = paymentHystrixService.paymentInfo_OK(id);return result;}@GetMapping("/consumer/payment/hystrix/timeout/{id}")public String paymentInfo_TimeOut(@PathVariable("id") Long id) {String result = paymentHystrixService.paymentInfo_TimeOut(id);return result;}
}

然后我们关闭8001服务提供方服务，模拟服务器宕机，如图，在服务访问出现错误时，访问了我们配置的PaymentFallbackService类中的服务降级方法，这样就实现了代码的解耦，使业务逻辑不再混乱。

4. 服务熔断Break

1. 熔断机制概述

熔断机制是应对雪崩效应的一种微服务链路保护机制，当扇出链路的某个微服务出错不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，也就是说服务熔断会导致服务降级，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。也就是说，服务熔断在服务好了之后会重新允许访问服务。在SpringCloud框架中，熔断机制通过Hystrix实现。Hystrix会监控微服务间的调用状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。熔断机制的注解是 @HystrixCommand。关于熔断机制，具体可以参考论文CircuitBreaker。

2. 实操

在8001服务提供方的Service中添加如下代码：

 //======服务熔断/*** fallbackMethod                               服务降级方法* circuitBreaker.enabled                       是否开启断路器* circuitBreaker.requestVolumeThreshold        请求次数* circuitBreaker.sleepWindowInMilliseconds     时间窗口期* circuitBreaker.errorThresholdPercentage      失败率达到多少后跳闸* 以下配置意思是在10秒时间内请求10次，如果有6此是失败的，就触发熔断器* 注解@HystrixProperty中的属性在com.netflix.hystrix.HystrixCommandProperties类中查看* @param id* @return*/@HystrixCommand(fallbackMethod = "paymentCircuitBreaker_fallback", commandProperties = {@HystrixProperty(name = "circuitBreaker.enabled", value = "true"),@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),@HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "10000"),@HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "60")})public String paymentCircuitBreaker(@PathVariable("id") Long id) {if (id < 0) {throw new RuntimeException("id 不能为负数");}String serialNumber = IdUtil.simpleUUID();return Thread.currentThread().getName() + " 调用成功，流水号： " + serialNumber;}/*** 服务熔断触发的服务降级方法* @param id* @return*/public String paymentCircuitBreaker_fallback(@PathVariable("id") Long id) {return "id 不能为负数，请稍后再试。id:" + id;}

在 @HystrixCommand 注解中配置熔断机制的参数，配置的参数含义如下：

属性名	含义	默认值
circuitBreaker.enabled	是否开启断路器	true
circuitBreaker.requestVolumeThreshold	请求次数	20
circuitBreaker.sleepWindowInMilliseconds	时间窗口期	5000
circuitBreaker.errorThresholdPercentage	失败率达到多少后跳闸	50

这些属性名的具体含义一级其默认值可以在 com.netflix.hystrix.HystrixCommandProperties 类中进行查看。而我们在service中配置的意思就是在10秒时间内请求10次，如果有6次是失败的，就触发熔断器。

在Controller中添加该服务：

    @GetMapping("payment/circuit/{id}")public String paymentCircuitBreaker(@PathVariable("id") Long id) {String result = paymentService.paymentCircuitBreaker(id);log.info("=========result:" + result);return result;}

3. 测试

根据我们的业物逻辑，也就是当我们的id为整数时，服务可以正常访问，而当id为负数时，访问服务出错。我们先访问 http://localhost:8001/payment/circuit/1 代表正确的服务请求，可以发现一切正常！！！：

然后我们进行大量的错误访问，强行触发服务熔断，然后在进行正确的访问。

我们发现在进行超出我们阈值的错误访问后，触发了服务熔断，即使再进行正确的访问也无法进行，但是一定时间后，正确的服务访问又可以顺利进行，这就是服务熔断的整体过程：在触发了服务熔断后，先进行服务的降级，再逐渐恢复调用链路。

4. 总结

结合官网中对熔断机制的描述，其熔断过程可以如下描述：

熔断器打开和关闭的精确方式如下：

**1.**假设电路上的访问达到某个阈值（HystrixCommandProperties.circuitBreakerRequestVolumeThreshold()）…
**2.**并假设误差百分比超过阈值误差百分比（HystrixCommandProperties.circuitBreakerErrorThresholdPercentage()）…
**3.**然后，断路器从CLOSED为OPEN，触发熔断机制。
**4.**当它断开时，它会使针对该断路器的所有请求短路。
**5.经过一段时间（HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds()）后，下一个单个请求被允许通过（这是HALF-OPEN状态）。如果请求失败，断路器将OPEN在睡眠窗口期间返回到该状态。如果请求成功，则断路器切换到，CLOSED，并且1.**中的逻辑再次接管。

也就是在熔断机制中，熔断器分为三个状态：

熔断器打开OPEN	请求不再进行调用当前服务，内部设置时钟一般为MTTR（平均故障处理时间），当打开时长达到所设时钟则进入半熔断状态（HALF-OPEN）。
熔断器关闭CLOSED	熔断关闭不会对服务进行熔断。
熔断器半开HALF-OPEN	部分请求根据规则调用当前服务，如果请求成功且符合规则则认为当前服务恢复正常，关闭熔断。

下面是官网上的熔断器流程图：

那么熔断器在什么情况下开始起作用呢？

涉及到熔断器的三个重要参数：
1. 快照时间窗口期circuitBreaker.sleepWindowInMilliseconds：熔断器是否打开需要统计一些请求和错误数据，而统计的时间范围就是快找时间窗，默认为最近的10秒；
2. 请求总数阈值circuitBreaker.requestVolumeThreshold：在快照时间窗内，必须满足请求总数阈值才有资格触发熔断，默认为20次，这意味着在快照时间窗规定的时间内，如果该Hystrix命令的调用次数不足20次，即使所有请求都超时或其他原因失败，熔断器都不会打开；
3. 错误百分比阈值circuitBreaker.errorThresholdPercentage：当请求总数在快照时间窗内超过了阈值，且在这些调用中，超过错误百分比阈值比例的错误调用，熔断器就会打开。
熔断器打开后再有请求调用的时候，将不会调用主逻辑，而是直接调用服务降级的方法，实现了自动发现错误并将降级逻辑切换为主逻辑，减少响应延迟的效果。
在熔断器打开后，原来的主逻辑如何恢复呢？

当熔断器打开后，对主逻辑进行熔断之后，Hystrix会启动一个 休眠时间窗 ，在这个时间窗内，降级逻辑是临时的主逻辑，当休眠时间窗到期，熔断器会进入半开状态，释放一次请求到原来的主逻辑上，如果此次请求能够正常访问，则熔断器会进入闭合状态，从而恢复主逻辑，如果注册请求依然有问题，则熔断器继续保持打开状态，并且休眠时间窗重新计时。

5. Hystrix工作流程

整体的Hystrix工作流程图入下：

4. 服务监控Hystrix Dashboard

除了隔离依赖服务的调用以外，Hystrix还提供了准实时的调用监控——Hystrix Dashboard，Hystrix会持续的记录所有通过Hystrix发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求，多少成功，多少失败等。SpringCloud也提供了Hystrix Dashboard的整合，对监控内容转化成可视化界面。

新建Module：cloud-consumer-hystrix-dashboard9001作为Hystrix Dashboard服务

添加Hystrix Dashboard的依赖：

<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
</dependency>

写配置文件application.yml，加个端口即可：
```
server:port: 9001
```

编写主启动类，在主启动类上添加@EnableHystrixDashboard注解开启Hystrix Dashboard功能：

package cn.sher6j.springcloud;import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.hystrix.dashboard.EnableHystrixDashboard;/*** @author sher6j* @create 2020-05-21-23:47*/
@SpringBootApplication
@EnableHystrixDashboard
public class HystrixDashboardMain9001 {public static void main(String[] args) {SpringApplication.run(HystrixDashboardMain9001.class);}
}

所有的服务提供方微服务（如我们的8001/8002）都需要监控依赖配置：

<!--actuator监控信息完善-->
<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

访问 http://localhost:9001/hystrix 我们就可以看见Hystrix Dashboard的图形化界面

为了让服务提供方的服务能被Hystrix Dashboard监控到，需要在提供方服务的主启动类中添加如下配置：

 /***此配置是为了服务监控而配置，与服务容错本身无关，springcloud升级后的坑*ServletRegistrationBean因为springboot的默认路径不是"/hystrix.stream"，*只要在自己的项目里配置上下面的servlet就可以了*/@Beanpublic ServletRegistrationBean getServlet() {HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet);registrationBean.setLoadOnStartup(1);registrationBean.addUrlMappings("/hystrix.stream");registrationBean.setName("HystrixMetricsStreamServlet");return registrationBean;}

在Hystrix Dashboard的图形化界面中输入要监控的服务提供者：

下面就是Dashboard对服务的监控状态：

SpringCloud-06-Hystrix断路器相关推荐

【SpringCloud】Hystrix断路器【五】
1. Hystrix理解 1.1 概述 1.2 背景 1.3 雪崩效应常见场景 1.4 雪崩效应应对策略 1.5 初探Hystrix 1.6 Hystrix流程图 2. 构建问题项目 2.2 构建cl ...
SpringCloud与Hystrix断路器
服务熔断,服务降级,服务监控的学习笔记: 问题复杂分布式体系结构中的应用程序有数十个依赖关系,每个依赖关系在某些时候将不可避免地失败. 服务雪崩多个微服务之间调用的时候,假设微服务A调用微服务B和 ...
SpringCloud中 Feign结合Hystrix断路器开发。
Feign结合Hystrix断路器开发: 转载于:https://www.cnblogs.com/longdb/p/10468371.html
Hystrix断路器原理及实现（服务降级、熔断、限流）
Hystrix断路器原理及实现(服务降级.熔断.限流) 分布式系统面临的问题 Hystrix重要概念(面试常考) Hystrix案例 Hystrix 服务提供者 Hystrix 服务消费者原因与解决 ...
五、Hystrix断路器
Hystrix断路器概述分布式系统面临的问题复杂分布式体系结构中的应用程序有数十个依赖关系,每一个依赖关系在某些时候将不可避免的失败. 服务雪崩多个微服务之间调用的时候,假如微服务A调用微服务 ...
微服务——Hystrix断路器（豪猪哥）
提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档文章目录概述分布式系统面临的问题是什么能干嘛 Hystrix重要概念服务降级(fallback) 哪些情况会触发降级服务熔 ...
SpringCloud07 - Hystrix 断路器
扯淡: 服务与服务之间有业务关联就需要调用,当被调用的服务发生故障(上线后多半是由于网路原因导致连接超时),必然会波及到服务调用者.通俗讲,断路器就是在低层级的服务发生故障时将服务间的连接断开. 个人 ...
SpringClound——Hystrix断路器
SpringCloud学习资料汇总超级棒的如上是我在看文章时忽然看到的一个很好的学习SpringCloud的网站 SpringClound--微服务概述--史上最烂 SpringClound--Sp ...
Hystrix断路器入门1
Hystrix断路器入门1 1.分布式系统面临的问题复杂分布式体系结构中的应用程序有数十个依赖关系,每个依赖关系在某些时候将不可避免地失败. 服务雪崩多个微服务之间调用的时候,假设微服务A调用微服 ...
Spring Cloud构建微服务架构：服务容错保护（Hystrix断路器）【Dalston版】
前言在前两篇<Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)>和<Spring Cloud构建微服务架构:服务容错保护(Hystrix依赖隔离)&g ...

SpringCloud-06-Hystrix断路器