Hystrix

雪崩是系统中的蝴蝶效应导致其发生的原因多种多样，有不合理的容量设计，或者是高并发下某一个方法响应变慢，亦或是某台机器的资源耗尽。从源头上我们无法完全杜绝雪崩源头的发生，但是雪崩的根本原因来源于服务之间的强依赖，所以我们可以提前评估。当整个微服务系统中，有一个节点出现异常情况，就有可能在高并发的情况下出现雪崩，导致调用它的上游系统出现响应延迟，响应延迟就会导致tomcat连接本耗尽，导致该服务节点不能正常的接收到正常的情况，这就是服务雪崩行为。

解决服务雪崩就要用到Hystrix。

服务隔离

如果整个系统雪崩是由于一个接口导致的，由于这一个接口响应不及时导致问题，那么我们就有必要对这个接口进行隔离，就是只允许这个接口最多能接受多少的并发，做了这样的限制后，该接口的主机就会空余线程出来接收其他的情况，不会被哪个坏了的接口占用满。

Hystrix就是一个不错的服务隔离框架。

导入jar

 开启功能

 代码使用

隔离共有两种隔离策略。

THREAD 线程池隔离策略  独立线程接收请求   默认的就是这种隔离策略

信号量隔离是采用一个全局变量来控制并发量，一个请求过来全局变量加1，单加到跟配置中的大小相等是就不再接受用户请求了。

Hystrix服务降级

服务降级是对服务调用过程的出现的异常的友好封装，当出现异常时，我们不希望直接把异常原样返回，所以当出现异常时我们需要对异常信息进行包装，抛一个友好的信息给前端。

Hystrix熔断

熔断就像家里的保险丝一样，家里的保险丝一旦断了，家里就没点了，家里用电器功率高了就会导致保险丝端掉。在我们springcloud领域也可以这样理解，如果并发高了就可能触发hystrix的熔断。

熔断发生的三个必要条件：
有一个统计的时间周期

相应的配置属性

metrics.rollingStats.timeInMilliseconds 

默认10000毫秒

请求次数必须达到一定数量

相应的配置属性

circuitBreaker.requestVolumeThreshold  

默认20次

失败率达到默认失败率

相应的配置属性

circuitBreaker.errorThresholdPercentage  

默认50%

上述3个条件缺一不可，必须全部满足才能开启hystrix的熔断功能。

服务监控

Hystrix进行服务熔断时会对调用结果进行统计，比如超时数、bad请求数、降级数、异常数等等都会有统计，那么统计的数据就需要有一个界面来展示，hystrix-dashboard就是这么一个展示hystrix统计结果的服务。

 

Dashboadr界面

http://localhost:9990/hystrix

然后在界面中输入需要监控的端点url：

http://localhost:8083/actuator/hystrix.stream

 

可以看到失败率超过50%时，circuit的状态是open的。

熔断器的三个状态：

1、关闭状态

关闭状态时用户请求是可以到达服务提供方的

2、开启状态

开启状态时用户请求是不能到达服务提供方的，直接会走降级方法

3、半开状态

当hystrix熔断器开启时，过一段时间后，熔断器就会由开启状态变成半开状态。

半开状态的熔断器是可以接受用户请求并把请求传递给服务提供方的，这时候如果远程调用返回成功，那么熔断器就会有半开状态变成关闭状态，反之，如果调用失败，熔断器就会有半开状态变成开启状态。

Hystrix功能建议在并发比较高的方法上使用，并不是所有方法都得使用的。