【SpringCloud笔记】（7）服务降级之Hystrix

Hystrix

痛点

分布式系统面临的问题：雪崩效应
多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。

对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。
所以，通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接收流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫雪崩。

概述

Hystrix官宣停更进维
如何使用：https://github.com/Netflix/Hystrix/wiki/How-To-Use
官方：https://github.com/Netflix/Hystrix

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

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

重要概念

服务降级（fallback）

服务器忙，请稍后再试，不让客户端等待并立刻返回一个友好的提示

当某个服务单元发生故障之后，向调用方返回一个符合预期的、可处理的备选响应(FallBack)，而不是长时间的等待或者抛出调用方无法处理的异常

哪些情况会触发降级？
1、程序运行异常
2、超时
3、服务熔断触发服务降级
4、线程池/信号量打满

服务熔断（break）

类比保险丝达到最大服务访问后，直接拒绝访问，拉闸限电，然后调用服务降级的方法并返回友好提示

服务降级->服务熔断->恢复调用链路

服务限流（flowlimit）

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

案例

构建以eureka7001模块作为服务中心的单机版微服务架构

创建cloud-provider-hystrix-payment8001模块

pom文件

<artifactId>cloud-provider-hystrix-payment8001artifactId>

    <dependencies>
        
        <dependency>
            <groupId>org.springframework.cloudgroupId>
            <artifactId>spring-cloud-starter-netflix-hystrixartifactId>
        dependency>
        
        <dependency>
            <groupId>org.springframework.cloudgroupId>
            <artifactId>spring-cloud-starter-netflix-eureka-clientartifactId>
        dependency>
        <dependency>
            <groupId>org.springframework.bootgroupId>
            <artifactId>spring-boot-starter-webartifactId>
        dependency>
        <dependency>
            <groupId>org.springframework.bootgroupId>
            <artifactId>spring-boot-starter-actuatorartifactId>
        dependency>
        <dependency>
            <groupId>com.mzr.springcloudgroupId>
            <artifactId>cloud-api-commonsartifactId>
            <version>1.0-SNAPSHOTversion>
        dependency>
    dependencies>

yml文件

server:
  port: 8001

spring:
  application:
    name: cloud-provider-hystrix-payment
eureka:
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/

主启动类

@SpringBootApplication
@EnableEurekaClient
public class PaymentHystrixMain8001
{
    public static void main(String[] args) {
        SpringApplication.run(PaymentHystrixMain8001.class, args);
    }
}

service层

@Service
public class PaymentService
{
    /**
     * 正常访问，肯定OK
     * @param id
     * @return
     */
    public String paymentInfo_OK(Integer id) {
        return "线程池:  "+Thread.currentThread().getName()+"  paymentInfo_OK,id:  "+id+"\t"+"O(∩_∩)O哈哈~";
    }

    /**
     * 模拟一个复杂业务逻辑响应时间较长
     * @param id
     * @return
     */
    public String paymentInfo_TimeOut(Integer id) {
        int timeNumber = 3;
        try { TimeUnit.MILLISECONDS.sleep(timeNumber); } catch (InterruptedException e) { e.printStackTrace(); }
        return "线程池:  "+Thread.currentThread().getName()+" id:  "+id+"\t"+"O(∩_∩)O哈哈~"+"  耗时(秒): ";
    }
}

controller层

@RestController
@Slf4j
public class PaymentController
{
    @Resource
    private PaymentService paymentService;

    @Value("${server.port}")
    private String serverPort;

    @GetMapping("/payment/hystrix/ok/{id}")
    public String paymentInfo_OK(@PathVariable("id") Integer id)
    {
        String result = paymentService.paymentInfo_OK(id);
        log.info("*****result: "+result);
        return result;
    }

    @GetMapping("/payment/hystrix/timeout/{id}")
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id)
    {
        String result = paymentService.paymentInfo_TimeOut(id);
        log.info("*****result: "+result);
        return result;
    }
}

启动测试

可以发现两个方法都可以正常访问，即使第二个响应会慢一点

以上述为根平台，模拟从正确->错误->降级熔断->恢复

模拟高并发压测

Jmeter下载地址：https://jmeter.apache.org/download_jmeter.cgi
下载zip压缩包，解压
在apache-jmeter-5.6.2\bin目录下有Jmeter.bat脚本文件，双击

开启Jmeter，来2000个并发压死8001，2000个请求全部去请求paymentInfo_TimeOut方法

故障现象及导致原因：

分别访问http://localhost:8001/payment/hystrix/timeout/1、http://localhost:8001/payment/hystrix/ok/1，可以发现原本毫秒级响应速度的ok接口也变慢了
why？
tomcat的默认的工作线程编池被打满了，没有多余的线程来分解压力和处理。

上面还是服务提供者8001自己测试，假如此时外部的消费者80也来访问,那消费者只能干等，最终导致消费端80不满意，服务端8001直接被拖死

新建消费者cloud-customer-feign-hystrix-order80调用提供者继续压测

使用feign+eureka

pom文件

<artifactId>cloud-customer-feign-hystrix-order80</artifactId>
    
    <dependencies>
        <!--openfeign-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-openfeign</artifactId>
        </dependency>
        <!--hystrix-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
        </dependency>
        <!--eureka client-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>
        <!-- 引入自己定义的api通用包，可以使用Payment支付Entity -->
        <dependency>
            <groupId>com.mzr.springcloud</groupId>
            <artifactId>cloud-api-commons</artifactId>
            <version>${project.version}</version>
        </dependency>
        <!--web-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
    </dependencies>

yaml文件

server:
  port: 80

eureka:
  client:
    register-with-eureka: false
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/

主启动类

@SpringBootApplication
@EnableFeignClients
public class OrderHystrixMain80 {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

service层

@Component
@FeignClient(value = "cloud-provider-hystrix-payment" ,fallback = PaymentFallbackService.class)
public interface PaymentHystrixService
{
    @GetMapping("/payment/hystrix/ok/{id}")
    public String paymentInfo_OK(@PathVariable("id") Integer id);

    @GetMapping("/payment/hystrix/timeout/{id}")
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id);
}

启动，访问正常

开始加压进行高并发测试（20000次压8001）

消费端80微服务再去访问正常的Ok微服务8001地址，发现消费端80要么转圈等待要么报超时错误

这种问题如何解决？

解决要求：
超时导致服务器变慢（转圈）—超时不再等待
出错（宕机或程序运行出错）—出错要有兜底

解决方案：
对方服务（8001）超时了，调用者（80）不能一直卡死等待，必须有服务降级
对方服务（8001) down机了，调用者（80）不能一直卡死等待，必须有服务降级
对方服务（8001) OK，调用者（80）自己出故障或有自我要求（比如自己的等待时间小于服务提供者），自己处理降级

服务降级

配置降级@HystrixCommand

8001先从自身找问题

设置自身调用超时时间的峰值，峰值内可以正常运行，超过了需要有兜底的方法处理，作服务降级fallback

8001设置fallback

业务类设置

@HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler",//设置兜底方法名称
            commandProperties = {@HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="3000")}//设置峰值，超过后回调兜底方法
    )
    public String paymentInfo_TimeOut(Integer id)
    {
        int timeNumber = 5000; //制造超时异常测试是否回调兜底方法
        //int age = 10/0;  人为制造程序异常，测试是否会回调兜底方法
        try { TimeUnit.MILLISECONDS.sleep(timeNumber); } catch (InterruptedException e) { e.printStackTrace(); }
        return "线程池:  "+Thread.currentThread().getName()+" id:  "+id+"\t"+"O(∩_∩)O哈哈~"+"  耗时(秒): ";
    }

    //兜底方法
    public String paymentInfo_TimeOutHandler(Integer id)
    {
        return "线程池:  "+Thread.currentThread().getName()+"  8001系统繁忙或者运行报错，请稍后再试,id:  "+id+"\t"+"o(╥﹏╥)o";
    }

主启动类加上@EnableCircuitBreaker

@SpringBootApplication
@EnableEurekaClient
@EnableCircuitBreaker//激活熔断器
public class PaymentHystrixMain8001
{
    public static void main(String[] args) {
        SpringApplication.run(PaymentHystrixMain8001.class, args);
    }
}

启动测试，可以发现当出现超时或者程序异常时，回到兜底方法

• hystrix既可以放在服务端也可以放在客户端，一般做服务降级放在客户端
• 另外，我们自己配置过的热部署方式对java代码的改动明显，但对@HystrixCommand内属性的修改建议重启微服务。

80设置fallback

80消费者默认等待响应时间为1s，提供者响应时间峰值设置为3s，所以消费者也需要设置服务降级

yml文件

server:
  port: 80

eureka:
  client:
    register-with-eureka: false
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/

feign:
  hystrix:
    enabled: true

主启动类加上@EnableHystrix注解

@SpringBootApplication
@EnableFeignClients
@EnableHystrix
//@EnableCircuitBreaker 服务端使用的是这个注解，注意区分！
public class OrderHystrixMain80 {
    public static void main(String[] args)
    {
        SpringApplication.run(OrderHystrixMain80.class,args);
    }
}

controller层

因为80没有接口实现类，所以我们直接在controller层添加@hystrixCommand注解回调兜底方法

 @GetMapping("/consumer/payment/hystrix/ok/{id}")
    public String paymentInfo_OK(@PathVariable("id") Integer id)
    {
        String result = paymentHystrixService.paymentInfo_OK(id);
        return result;
    }

    @GetMapping("/consumer/payment/hystrix/timeout/{id}")
    @HystrixCommand(fallbackMethod = "paymentTimeOutFallbackMethod",commandProperties = {
            @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="1500")
    })
    //@HystrixCommand
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id)
    {
        int age = 10/0;
        String result = paymentHystrixService.paymentInfo_TimeOut(id);
        return result;
    }
    public String paymentTimeOutFallbackMethod(@PathVariable("id") Integer id)
    {
        return "我是消费者80,对方支付系统繁忙请10秒钟后再试或者自己运行出错请检查自己,o(╥﹏╥)o";
    }

启动，测试发现已经回调了兜底方法

目前问题：
1、每个方法都对应一个兜底方法，大部分方法并不需要各自配置一个兜底方法，可以多个方法使用统一的兜底方法，个别方法使用自定义兜底方法，造成代码膨胀
2、兜底方法和业务逻辑方法放在一块，造成代码混乱

解决方案：

问题1，引入注解@DefaultProperties(defaultFallback = “”)，设置全局fallback方法

问题2

由于controller层调用的接口散落在各处，80消费者使用feign进行服务调用的，既然使用feign服务调用，那么一定有一个Feign客户端定义的接口，我们可以对这个接口中所有的方法集中起来统一设置fallback（不是设置统一的fallback方法），这样可以达到解耦的目的

演示案例：客户端去调用服务端，碰上服务端宕机或关闭
本次案例服务降级处理是在客户端80实现完成的，与服务端8001没有关系
只需要为Feign客户端定义的接口添加一个服务降级处理的实现类即可实现解耦

将controller层中关于@HystrixCommand、@DefaultProperties注解信息去掉，保持之前的controller内容

@RestController
@Slf4j
//@DefaultProperties(defaultFallback = "payment_Global_FallbackMethod")
public class OrderHystrixController
{
    @Resource
    private PaymentHystrixService paymentHystrixService;

    @GetMapping("/consumer/payment/hystrix/ok/{id}")
    //@HystrixCommand
    public String paymentInfo_OK(@PathVariable("id") Integer id)
    {
        String result = paymentHystrixService.paymentInfo_OK(id);
        return result;
    }

    @GetMapping("/consumer/payment/hystrix/timeout/{id}")
    //@HystrixCommand(fallbackMethod = "paymentTimeOutFallbackMethod",commandProperties = {
    //        @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="1500")
    //})
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id)
    {
        //int age = 10/0;人为制造程序异常，测试是否回调用兜底方案
        String result = paymentHystrixService.paymentInfo_TimeOut(id);
        return result;
    }

根据cloud-consumer-feign-hystrix-order80已经有的PaymentHystrixService接口,重新新建一个类(PaymentFallbackService)实现该接口，统一为接口里面的方法进行异常处理

@Component
public class PaymentFallbackService implements PaymentHystrixService {
    @Override
    public String paymentInfo_OK(Integer id) {
        return "-----PaymentFallbackService fall back-paymentInfo_OK ,o(╥﹏╥)o";
    }

    @Override
    public String paymentInfo_TimeOut(Integer id) {
        return "-----PaymentFallbackService fall back-paymentInfo_TimeOut ,o(╥﹏╥)o";
    }
}

yml文件

server:
  port: 80
spring:
  application:
    name: cloud-customer-feign-hystrix-service
eureka:
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/

# 用于服务降级 在注解@FeignClient 中添加 fallback 属性值
feign:
  hystrix:
    enabled: true  # 在feign中开启 hystrix

service层中@FeignClient注解中添加fallback = PaymentFallbackService.class

意思是：当service层中方法调用出现异常，去PaymentFallbackService实现类中找fallback方法

@Component
@FeignClient(value = "cloud-provider-hystrix-payment",fallback = PaymentFallbackService.class)
public interface PaymentHystrixService
{
    @GetMapping("/payment/hystrix/ok/{id}")
    public String paymentInfo_OK(@PathVariable("id") Integer id);

    @GetMapping("/payment/hystrix/timeout/{id}")
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id);
}

服务熔断

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

熔断机制概述
熔断机制是应对雪崩效应的一种微服务链路保护机制。
当扇出链路的某个微服务出错不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。
当检测到该节点微服务调用响应正常后，恢复调用链路。

在Spring Cloud框架里，熔断机制通过Hystrix实现。
Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省（默认的意思）是5秒内20次调用失败，就会启动熔断机制。
熔断机制的注解是@HystrixCommand。

修改cloud-provider-hystrix-payment8001模块

@Service
public class PaymentService {
    //=====服务熔断
    @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"),// 失败率达到多少后跳闸 (在10s内10次请求有60%失败率会熔断)
    })
    public String paymentCircuitBreaker(@PathVariable("id") Integer id)
    {
        if(id < 0)
        {
            throw new RuntimeException("******id 不能负数");
        }
        String serialNumber = IdUtil.simpleUUID();

        return Thread.currentThread().getName()+"\t"+"调用成功，流水号: " + serialNumber;
    }
    public String paymentCircuitBreaker_fallback(@PathVariable("id") Integer id)
    {
        return "id 不能负数，请稍后再试，/(ㄒoㄒ)/~~   id: " +id;
    }
}

controller

@RestController
@Slf4j
public class PaymentController{
    @Resource
    private PaymentService paymentService;
    
    //====服务熔断
    @GetMapping("/payment/circuit/{id}")
    public String paymentCircuitBreaker(@PathVariable("id") Integer id)
    {
        String result = paymentService.paymentCircuitBreaker(id);
        log.info("****result: "+result);
        return result;
    }
}

启动测试

根据service层代码可知：我们输入id为负数时会触发服务降级，在10s内10次请求有60%失败率就会触发开启熔断，这个时候，即使我们输入id为正数接口也不会返回正确接口

我们先测试输入id为正数时，可以发现可以正常返回结果

输入id为负数时，会触发fallback方法

接下来，我们多次访问输入id为负数的接口（>10次）达到开启熔断器条件，再次输入id为正数时，发现返回结果依然是fallback方法的返回值

再等待些许时间，输入id为正数再次访问发现恢复正常

熔断的状态：
熔断打开：请求不再进行调用当前服务，内部设置时钟一般为MTTR（平均故障处理时间），当打开时长达到所设时钟则进入半熔断状态

熔断关闭：熔断关闭不会对服务进行熔断

熔断半开：部分请求根据规则调用当前服务，如果请求成功目符合规则，则认为当前服务恢复正常，关闭熔断。

那么断路器在什么时候开始起作用呢？

@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"),// 失败率达到多少后跳闸
    })

涉及到断路器的三个重要参数：快照时间窗、请求总数阀值、错误百分比阀值

1：快照时间窗：断路器确定是否打开需要统计一些请求和错误数据而统计的时间范围就是快照时间窗，默认为最近的10秒。

2：请求总数阀值：在快照时间窗内，必须满足请求总数阀值才有资格熔断。默认为20，意味着在10秒内，如果该hystrix命令的调用次数不足20次，即使所有的请求都超时或具他原因失败，断路器都不会打开。

3：错误百分比阀值：当请求总数在快照时间窗内超过了阀值，上日发生了30次调用，如果在这30次调用中，有15次发生了超时异常，也就是超过50％的错误百分比，在默认设定50％阀值情况，这时候就会将断路器打开。

断路器开启或关闭条件
1、当满足一定的阀值的时候（默认10秒内超过20个请求次数)

2、当失败率达到一定的时候（默认10秒内超过50%的请求失败)到达以上阀值，断路器将会开启

3、当开启的时候，所有请求都不会进行转发

4、一段时间之后（默认是5秒)，这个时候断路器是半开状态，会让其中一个请求进行转发。

5、如果成功，断路器会关闭，若失败，继续开启。重复4和5

断路器打开之后:
1:再有请求调用的时候，将不会调用主逻辑，而是直接调用降级fallack，通过断路器，实现了自动地发现错误并将降级逻辑切换为主逻辑，减少响应延迟的效果。

2:原来的主逻辑要如何恢复呢?
对于这一问题，hystrix也为我们实现了自动恢复功能。
当断路器打开，对主逻辑进行熔断之后，hystrix会启动一个休眠时间窗，在这个时间窗内，降级逻辑将临时的成为主逻辑，当休眠时间窗到期，断路器将进入半开状态，释放一次请求到原来的主逻辑上，如果此次请求正常返回，那么断路器将继续闭合，主逻辑恢复，如果这次请求依然有问题，断路器继续进入打开状态，休眠时间窗重新计时。

All配置

@HystrixCommand(fallbackMethod = "str_fal1backMethod",
groupKey = "strGroupCommand",
commandKey = "strCommand",
threadPoolKey = "strThreadPool",
commandProperties = {
//没置隔离策略，THREAD表示线程池SEMAPHORE:信号池隔离
@HystrixProperty(name = "execution.isolation.strategy" , value = "THREAD"),
//当隔离策略选择信号池隔离的时候，用来设置信号地的大小（最大并发数)
HystrixProperty(name = "execution.isolation.semaphore.maxConcurrentRequests", value = "10"),
//配置命令执行的超时时间
@HystrixProperty(name = "execution.isolation.thread.timeoutinMilliseconds", value = "10"),
//是否启用超时时间
@HystrixProperty(name = "execution.timeout.enabled", value = "true),
//执行超时的时候是否中断
@HystrixProperty(name = "execution.isolation.thread.interruptOnTimeout" , value = "true"),
//执行被取消的时候是否中断
@HlystrixProperty(name = "execution.isolation.thread.interruptOnCancel" , value = "true"),
//允许回调方法执行的最大并发数
@HystrixProperty(name = "fallback.isolation.semaphore.maxConcurrentRequests", value = "10"),
//服务降级是否启用，是否执行回调函数
@HystrixProperty(name = "fa11back.enabled" , value = "true"),
@HystrixProperty(name = "circuitBreaker.enabled", value = "true"),
//该属性用来设置在滚动时间窗中，断路器熔断的最小请求数。例如，默认该值为20 的时候,
//如果煅动时间窗〈（默认10秒）内仅收到了19个请求，即使这19个请求都失败了，断路器也不会打开。
@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "20"),
//该属性用来设置在燎动时间窗中，表示在滚动时间窗中，在请求数量超过
//circuitBreaker .requestVolumeThreshold 的情况下，如果错误请求数的百分比超过50,
//就把断路器没置为“打开”状态，否则就没置为“关闭”状态。
@HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "50"),
//该属性用来没置当断路器打开之后的休眠时间窗。体眠时间窗结京之后，
//会将断路器置为“半开”状态，尝试熔断的请求命令，如果依然失败就将断路器继续设置为“打开”状态，
//如果成功就设置为“关闭”状恣。
@HystrixProperty(name = "circuitBreaker.sleepWindowinMilliseconds" , value= "5000"),
//断路器强制打开
@HystrixProperty(name = "circuitBreaker.forceOpen" , value = "false"),
//断路器强制关闭
@HystrixProperty(name = "circuitBreaker.forceClosed", value = "false"),
//滚动时间窗设置，该时间用于断路器判断健康度时需要收集信息的持续时间
@HystrixProperty(name = "metrics.rollingStats.timeinMilliseconds" , value = "10000"),
//该属性用来设置滚动时间窗统计指标侑息时划分"桶"的数量，断路器在收集指标信息的时候会根据
//设置的时间窗长度拆分成多个“桶”来累计各度量值，每个"糯"记录了一段时间内的采集指标。
//比如10秒内拆分成10个桶""收集这样，所以timeinMilLiseconds必须能被numBuckets整除。否则会抛异常
@HystrixProperty(name = "metrics.rollingStats.numBuckets", value = "10")
//该属性用来设置对命令执行的延迟是否使用百分位数来跟踪和计算。如果没置为false,那么所有的概要统计都将返回-1。
@HystrixProperty(name = "metrics.rollingPercentile.enabled" , value = "false"),
//该属性用来没置百分位统计的滚动窗口的持续时间，单位为毫秒。
CHystrixProperty(name = "metrics.rollingPercentile.timeInMilliseconds", value = "60000"),
//该属性用来没置百分位统计滚动窗口中使用“桶”的数量。
@HystrixProperty(name = "metrics.rollingPercentile.numBuckets" , value = "60000"),
//该属性用来设置在执行过程中每个“桶”中保留的最大执行次数。如果在滚动时间窗内发生超过该设定值的执行次数，
//就从最初的位置开始重写。例如，将该值设置为100，滚动窗口为10秒，若在10秒内一个“桶”中发生了500次执行，
//那么该“桶”中只保留最后的100次执行的统计。另外，增加该值的大小将会增加内存量的消耗，并增加排序百分位数所需的计算时间。
@HystrixProperty(name = "metrics.rollingPercentile.bucketSize", value = "100"),
//该属性用来没置采集影响断路器状态的健康快照（请求的成功、错误百分比）的间隔等待时间。@CHystrixProperty(name = "metrics.healthSnapshot.intervalinMilliseconds", value = "500"),
//是否开启请求缓存
@HystrixProperty(name = "requestCache.enabled" , value = "true"),
// HystrixCommand的执行和事件是否打印日志到 HystrixRequestLog 中
@HystrixProperty(name = "requestLog.enabled" , value = "true"),
},

threadPoolProperties = {
//该参数用来没置执行命令线程池的核心线程数，该值也就是命令执行的最大并发量
@HystrixProperty(name = "coreSize", value = "10"),
/该参数用来设置线程池的最大队列大小。当设置为-1时，线程池将使用SynchronousQueue实现的队列,
//否则将使用LinkedBLockingQueue实现的队列。
@HystrixProperty(name = "maxQueueSize", value = "-1")，
//该参数用来为队列设置拒绝阙值。通过该参数，即使队列没有达到最大值也能拒绝请求。
//该参数主要是对LinkedBLockingQueue 队列的补充,因为LinkedBLockingQueue
//队列不能动态修改它的对象大小，而通过该属性就可以调整拒绝请求的队列大小了。
@HystrixProperty(name = "queueSizeRejectionThreshold" , value = "5")，
}
)

服务限流

后面高级篇讲解alibaba的Sentinel说明

Hystrix工作流程

Hystrix图形化Dashboard搭建

新建cloud-consumer-hystrix-dashboard9001

pom文件

 	<artifactId>cloud-consumer-hystrix-dashboard9001artifactId>

    <dependencies>
    	<dependency>
       		<groupId>org.springframework.cloudgroupId>
        	<artifactId>spring-cloud-starter-netflix-hystrix-dashboardartifactId>
    	dependency>
    	<dependency>
        	<groupId>org.springframework.bootgroupId>
        	<artifactId>spring-boot-starter-actuatorartifactId>
    	dependency>
        
        <dependency>
            <groupId>com.mzr.springcloudgroupId>
            <artifactId>cloud-api-commonsartifactId>
            <version>${project.version}version>
        dependency>
    dependencies>

yml文件只需配置端口号

server:
  port: 9001

HystrixDashboardMain9001+新注解@EnableHystrixDashboard

@SpringBootApplication
@EnableHystrixDashboard
public class HystrixDashboardMain9001
{
    public static void main(String[] args)
    {
        SpringApplication.run(HystrixDashboardMain9001.class,args);
    }
}

所有Provider微服务提供类(8001/8002/8003)都需要监控依赖配置，之前我们都已经配置过了

<dependency>
            <groupId>org.springframework.bootgroupId>
            <artifactId>spring-boot-starter-actuatorartifactId>
        dependency>

启动cloud-consumer-hystrix-dashboard9001该微服务后续将监控微服务8001

访问 http://ocalhost:9001/hystrix看到以下页面就是搭建成功了

Dashboard监控实战

除了隔离依赖服务的调用以外，Hystrix还提供了准实时的调用监控（Hystrix Dashboard)，Hystrix会持续地记录所有通过Hysttrix发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求多少成功，多少失败等。Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合，对监控内容转化成可视化界面。

修改cloud-provider-hystrix-payment8001配置

pom文件中保证引入以下依赖

	#通常web与actuator是一起的
	<dependency>
            <groupId>org.springframework.bootgroupId>
            <artifactId>spring-boot-starter-webartifactId>
        dependency>
        <dependency>
            <groupId>org.springframework.bootgroupId>
            <artifactId>spring-boot-starter-actuatorartifactId>
   dependency>

主启动类

@SpringBootApplication
@EnableEurekaClient
@EnableCircuitBreaker//也是监控必备
public class PaymentHystrixMain8001
{
    public static void main(String[] args) {
            SpringApplication.run(PaymentHystrixMain8001.class, args);
    }


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

启动9001 7001 8001微服务测试

可以发现当前断路器是关闭状态

我们访问多次错误接口故意触发断路器开启

监控图示说明