SpringCloud-Hystrix【解决灾难性雪崩】

  在微服务环境中，因为一个节点的故障而造成的其他节点的不可用的情况是比较常见的，这也就是我们常说的灾难性雪崩现象，而Hystrix给我们提供了解决这种情况的方案。

什么是灾难性的雪崩效应

  什么是灾难性的雪崩效应?我们通过结构图来说明，如下

正常情况下各个节点相互配置，完成用户请求的处理工作

当某种请求增多，造成"服务T"故障的情况时，会延伸的造成"服务U"不可用，及继续扩展，如下

最终造成下面这种所有服务不可用的情况

这就是我们讲的灾难性雪崩

造成雪崩的原因可以归纳为以下三个:

1. 服务提供者不可用(硬件故障，程序Bug，缓存击穿，用户大量请求)
2. 重试加大流量(用户重试，代码逻辑重试)
3. 服务调用者不可用(同步等待造成的资源耗尽)

最终的结果就是一个服务不可用，导致一系列服务的不可用，而往往这种后果是无法预料的。

如何解决灾难性雪崩效应

  我们可以通过以下5中方式来解决雪崩效应

1.降级

  超时降级、资源不足时(线程或信号量)降级，降级后可以配合降级接口返回托底数据。实现一个 fallback 方法, 当请求后端服务出现异常的时候, 可以使用 fallback 方法返回的值.
详细介绍：https://dpb-bobokaoya-sm.blog.csdn.net/article/details/91452879

2.缓存

  Hystrix 为了降低访问服务的频率，支持将一个请求与返回结果做缓存处理。如果再次请求的 URL 没有变化，那么 Hystrix 不会请求服务，而是直接从缓存中将结果返回。这样可以大大降低访问服务的压力。
详细介绍:https://dpb-bobokaoya-sm.blog.csdn.net/article/details/91456676

3.请求合并

  在微服务架构中，我们将一个项目拆分成很多个独立的模块，这些独立的模块通过远程调用来互相配合工作，但是，在高并发情况下，通信次数的增加会导致总的通信时间增加，同时，线程池的资源也是有限的，高并发环境会导致有大量的线程处于等待状态，进而导致响应延迟，为了解决这些问题，我们需要来了解 Hystrix 的请求合并。

详细介绍:https://dpb-bobokaoya-sm.blog.csdn.net/article/details/91475182

4.熔断

  当失败率(如因网络故障/超时造成的失败率高)达到阀值自动触发降级，熔断器触发的快速失败会进行快速恢复。
详细介绍:https://dpb-bobokaoya-sm.blog.csdn.net/article/details/91599707

5.隔离（线程池隔离和信号量隔离）

  限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用。
详细介绍:https://dpb-bobokaoya-sm.blog.csdn.net/article/details/91605654