Hystrix

一：服务器雪崩故障发生的原因

1：服务提供者不可用：硬件故障，程序bug，缓存击穿，大量请求

2：重试加大流量：用户重试，代码逻辑重试

3：服务调用者不可用：同步等待造成资源耗尽

雪崩的解决方式：流量控制，改进缓存模式，服务自动扩容，服务调用者降级服务

二：使用 Hystrix 预防服务雪崩（针对的是服务调用者Service Consume）

通过对依赖服务实现线程池隔离，让我们的应用更加健壮，不会因为个别依赖服务出现问题而引起非相关服务的异常。同时，也使得我们的应用变得更加灵活，可以在不停止服务的情况下，配合动态配置刷新实现性能配置上的调整。除了使用线程池之外，还可以使用信号量来控制单个依赖服务的并发度，信号量的开销小于线程池，但是它不能设置超时和实现异步访问，所以只有在依赖服务是足够可靠的情况下才使用信号量。

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

 

这个阈值涉及到三个重要参数：快照时间窗、请求总数下限、错误百分比下限。这个参数的作用分别是：
快照时间窗：断路器确定是否打开需要统计一些请求和错误数据，而统计的时间范围就是快照时间窗，默认为最近的10秒。
请求总数下限：在快照时间窗内，必须满足请求总数下限才有资格进行熔断。默认为20，意味着在10秒内，如果该Hystrix Command的调用此时不足20次，即时所有的请求都超时或其他原因失败，断路器都不会打开。
错误百分比下限：当请求总数在快照时间窗内超过了下限，比如发生了30次调用，如果在这30次调用中，有16次发生了超时异常，也就是超过50%的错误百分比，在默认设定50% 下限情况下，这时候就会将断路器打开。

断路器保持在开路状态一段时间后 (默认5秒)，自动切换到半开路状态 (HALF-OPEN)。这时会判断下一次请求的返回情况，如果请求成功，断路器切回闭路状态 (CLOSED)，否则重新切换到开路状态 (OPEN)。

当一个请求调用相关服务后，hystrix的工作流程：

1：创建HystrixCommand/HystrixObservableCommand对象

2：执行命令（HystrixCommand对应execute和queue；HystrixObservableCommand对应observer和toObservable）

3：结果是否被缓存。若当前命令请求的缓存功能被启用，且缓存命中，则直接返回

4：断路器是否处于打开状态，若是直接执行第8步。

5：命令相关的依赖服务线程池是否满，若是直接第8步

6：执行HystrixCommand.run，若是抛出异常直接第8步

7：计算断路器的健康度。断路器根据这些指标判断是否需要将断路器打开，直到恢复期结束。若在恢复期结束后，统计数据还是达不到健康指标，则再次断开。

8：fallback处理，服务降级的逻辑

9：返回成功的响应

三：Hystrix Dashboard监控

在服务实例pom.xml中的dependencies节点中新增spring-boot-starter-actuator监控模块以开启监控相关的端点，并确保已经引入断路器的依赖spring-cloud-starter-netflix-hystrix。Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求多少成功，多少失败等。 需要新建一个监控项目，在启动项上配置@EnableHystrixDashboard。对于被监控的项目在启动项上配置@EnableHystrix，同时引入actuator依赖。

支持的监控类型：

单体应用监控：/hystrix

集群监控（默认的和指定的两种）：/turbine.stream。需要整合turbine。（通过http收集集合或通过消息代理收集集合）