一、简介
Hystix,即熔断器(也叫断路器)。
主页:https://github.com/Netflix/Hystrix/

Hystix是Netflix开源的一个延迟和容错库,用于隔离访问远程服务、第三方库,防止出现级联失败。

二、熔断器的工作机制

正常工作的情况下,客户端请求调用服务API接口:

当有服务出现异常时,直接进行失败回滚,服务降级处理:

当服务繁忙时,如果服务出现异常,不是粗暴的直接报错,而是返回一个友好的提示,虽然拒绝了用户的访问,但是会返回一个结果。
这就好比去买鱼,平常超市买鱼会额外赠送杀鱼的服务。等到逢年过节,超时繁忙时,可能就不提供杀鱼服务了,这就是服务的降级。
系统特别繁忙时,一些次要服务暂时中断,优先保证主要服务的畅通,一切资源优先让给主要服务来使用,在双十一、618时,京东天猫都会采用这样的策略。
三、雪崩问题
微服务中,服务间调用关系错综复杂,一个请求,可能需要调用多个微服务接口才能实现,会形成非常复杂的调用链路

如图,一次业务请求,需要调用A、P、H、I四个服务,这四个服务又可能调用其它服务。
如果此时,某个服务出现异常:

例如微服务I发生异常,请求堵塞,用户不会得到响应,则tomcat的这个线程不会释放,于是越来越多的用户请求到来,越来越多的线程会堵塞

服务器支持的线程和并发数有限,请求一直堵塞,会导致服务器资源耗尽,从而导致所有其它服务都不可用,形成雪崩效应。
这就好比,一个汽车生产线,生产不同的汽车,需要使用不同的零件,如果某个零件因为种种原因无法使用,那么就会造成整台车无法装配,陷入等待零件的状态,直到零件到位,才能继续。此时如果有很多个车型都需要这个零件,那么整个工厂都将陷入等待的状态,导致所有生产都陷入瘫痪。一个零件的波及范围不断扩大。
Hystix 解决雪崩问题的手段有两个:
- 线程隔离
- 服务熔断
四、线程隔离,服务降级
1. 原理
线程隔离示意图

服务降级(线程排满时触发,设置等待时长,若长时间未响应,返回友好错误信息)
解读:
Hystix为每个依赖服务调用分配一个小的线程池,如果线程池已满调用将被立即拒绝,默认不采用排队,加速失败判定时间。
用户的请求将不再直接访问服务,而是通过线程池中的空闲线程来访问服务,如果线程已满,或者请求超时,则会进行降级处理,什么是服务降级?
服务降级:优先保证核心服务,而非核心服务不可用或弱可用。
用户的请求故障时,不会被堵塞,更不会无休止的等待或者看到系统崩溃,至少可以看到一个执行结果(例如返回友好的提示信息)
服务降级虽然会导致请求失败,但不会导致堵塞,而且最多会影响这个依赖服务对应的线程池中的资源,对其它服务没有响应。
触发Hystix服务降级的情况:
- 线程池已满
- 请求超时
五、动手实践(服务的降级是在消费方)
1. 引入依赖
首先在user-consumer中引入Hystix依赖:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
2. 开启熔断

一个标准的Eureka客户端都得配置以上三个注解,所以springboot提供了一个新的注解替代三个(里面还是引用了以上三个注解)


3.改造消费者
Hystix 默认超时时长1秒钟

为了实现超时,服务提供方可睡眠2秒



4.以上降级处理存在的问题
方法写在controller中,且每个方法都写降级处理方法,显然不可行
修改为统一处理逻辑

单个超时时长配置


重新取值覆盖即可

整体超时时长配置


六、服务熔断
1. 熔断原理
熔断器也叫断路器,其英文单词为:Circuit Breaker

Hystix的熔断状态机模型

状态机有3个状态:
- Closed:关闭状态(断路器关闭),所有请求都正常访问。
- Open:打开状态(断路器打开),所有请求都会被降级。Hystix会对请求情况计数,当一定时间内失败请求百分比达到阈值,则触发熔断,断路器会完全关闭。默认失败比例的阈值是50%,请求次数最少不低于20次。
- Half Open:半开状态,Closed状态不是永久的,关闭后会进入休眠时间(默认是5s),随后断路器会自动进入半开状态。此时会释放部分请求通过,若这些请求都是健康的,则会完全打开断路器,否则继续保持关闭,再次进行休眠计时。
2. 动手实践
为了能够精确控制请求的成功或失败,我们在consumer的调用业务中加入一段逻辑并修改熔断时长,以便观察

开始测试
-
id为1无问题
-
id为2抛出异常,会触发降级熔断方法
-
多次快速点击id为2的请求,再访问请求为1的页面,发现服务被熔断了
-
等待5秒后,恢复正常
网友评论