Hystrix降级与熔断

Hystrix

即熔断器,一种保护机制

解决雪崩的方法有两个

  • 线程隔离
  • 服务熔断

线程隔离,服务降级

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

触发降级的原因

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

基本步骤

1.引入依赖

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

        
            org.springframework.cloud
            spring-cloud-starter-netflix-hystrix
        

2.加入注解

启动类中加入@EnableCircuitBreaker注解
另因为原启动类中,常需要加入Eureka的注册注解@EnableDiscoveryClient以及SpringBoot启动注解@SpringBootApplication
标准的SpringCloud应用都要加入这三个注解所以这三个注解封装成了一个注解@SpringCloudApplication
Hystrix降级与熔断_第1张图片

2.1 配置服务降级内容

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

Hystrix降级与熔断_第2张图片
类上可以写一个注解,用于所有方法的降级处理
@DefaultProperties(defaultFallback = “”) 在方法上就可以只用写@HystrixCommand用来启用降级处理,不用再写默认方法了
通用方法就不要写参数了
Hystix服务降级默认超时是1秒,不同业务可能耗时不同,所以超时时间要手动配置。

设置Hystrix相关属性

Hystrix降级与熔断_第3张图片

各种value属性
Hystrix降级与熔断_第4张图片
查找使用位置就可以看到其对应的key
Hystrix降级与熔断_第5张图片
这key就是其properties。
非全局的properties写在Hystrixcommand里面
全局的配置要写在yaml里面,没有提示
default同级,可以写方法、服务名。可以单独作用其上
Hystrix降级与熔断_第6张图片
全局配好之后,在方法上需要@Hystrixcommand启用

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

服务熔断

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

circuitBreaker.requestVolumeThreshold

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

circuitBreaker.errorThresholdPercentage

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

circuitBreaker.sleepWindowInMilliseconds

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

你可能感兴趣的:(SpringCloud)