Hystrix降级与熔断

Hystrix

即熔断器，一种保护机制

解决雪崩的方法有两个

• 线程隔离
• 服务熔断

线程隔离，服务降级

服务降级：请求故障的时候，不会被阻塞，也不会无休止的等待，至少可以看到一个执行结果。

触发降级的原因

• 线程池满了
• 或者请求超时

基本步骤

1.引入依赖

由服务的调用方来引入依赖

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

2.加入注解

启动类中加入@EnableCircuitBreaker注解
另因为原启动类中，常需要加入Eureka的注册注解@EnableDiscoveryClient以及SpringBoot启动注解@SpringBootApplication
标准的SpringCloud应用都要加入这三个注解所以这三个注解封装成了一个注解@SpringCloudApplication

2.1 配置服务降级内容

正确的方法上加上注解@HystrixCommand(defaultFallback = “”)参数为降级方法名。
降级方法的返回值与参数类型必须与原方法一致

类上可以写一个注解，用于所有方法的降级处理
@DefaultProperties（defaultFallback = “”） 在方法上就可以只用写@HystrixCommand用来启用降级处理，不用再写默认方法了
通用方法就不要写参数了
Hystix服务降级默认超时是1秒，不同业务可能耗时不同，所以超时时间要手动配置。

设置Hystrix相关属性

各种value属性

查找使用位置就可以看到其对应的key

这key就是其properties。
非全局的properties写在Hystrixcommand里面
全局的配置要写在yaml里面，没有提示
default同级，可以写方法、服务名。可以单独作用其上

全局配好之后，在方法上需要@Hystrixcommand启用

如果单独作用于某个服务，可将default替换为服务名

服务熔断

光降级还不行，如果每次请求都达到降级的标准的时长，那就太占用性能了。引入熔断可以使一个处于断路器open状态的服务快速返回降级结果
熔断器不需要改造代码，仅需要配置三个关键参数

circuitBreaker.requestVolumeThreshold

默认值20。含义是一段时间内至少有20个请求才进行errorThresholdPercentage计算。比如一段时间了有19个请求，且这些请求全部失败了，错误率是100%，但熔断器不会打开，总请求数不满足20。

circuitBreaker.errorThresholdPercentage

错误率，默认值50%，例如一段时间（10s）内有100个请求，其中有54个超时或者异常，那么这段时间内的错误率是54%，大于了默认值50%，这种情况下会触发熔断器打开。

circuitBreaker.sleepWindowInMilliseconds

半开状态试探睡眠时间，默认值5000ms。如：当熔断器开启5000ms之后，会尝试放过去一部分流量进行试探，确定依赖服务是否恢复。