Hystrix熔断器简介

1、微服务中的雪崩效应

  什么是微服务中的雪崩效应呢？

微服务中，一个请求可能需要多个微服务接口才能实现，会形成复杂的调用链路。

扇入：代表着该微服务被调用的次数，扇入大，说明该模块复用性好
扇出：该微服务调用其他微服务的个数，扇出大，说明业务逻辑复杂 

扇入大是一个好事，扇出大不一定是好事 

        在微服务架构中，一个应用可能会有多个微服务组成，微服务之间的数据交互通过远程过程调用完成。这就带来一个问题，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调⽤响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。 

        如图中所示，最下游简历微服务响应时间过长，大量请求阻塞，大量线程不会释放，会导致服务器资源耗尽，最终导致上游服务甚至整个系统瘫痪。

2、雪崩效应解决方案

  从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃，采用的技术手段；

        下面，我们介绍三种技术手段应对微服务中的雪崩效应，这三种手段都是从系统可用性、可靠性角度出发，尽量防止系统整体缓慢甚至瘫痪。

服务熔断

        熔断机制是应对雪崩效应的一种微服务链路保护机制。我们在各种场景下都会接触到熔断这两个字。高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护。股票交易中，如果股票指数过高，也会采用熔断机制，暂停股票的交易。同样，在微服务架构中，熔断机制也是起着类似的作用。当扇出链路的某个微服务不可⽤或者响应时间太长时，熔断该节点微服务的调用，进行服务的降级，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。

  注意：

• 服务熔断重点在“断”，切断对下游服务的调用
• 服务熔断和服务降级往往是一起使用的，Hystrix就是这样。

服务降级

        通俗讲就是整体资源不够用了，先将一些不关紧的服务停掉（调用我的时候，给你返回一个预留的值，也叫做兜底数据），待渡过难关高峰过去，再把那些服务打开。

        服务降级一般是从整体考虑，就是当某个服务熔断之后，服务器将不再被调用，此刻客户端可以自己准备一个本地的fallback回调，返回一个缺省值，这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强。

服务限流

        服务降级是当服务出问题或者影响到核心流程的性能时，暂时将服务屏蔽掉，待高峰或者问题解决后再打开；但是有些场景并不能用服务降级来解决，比如秒杀业务这样的核心功能，这个时候可以结合服务限流来限制这些场景的并发/请求量

  限流措施也很多，比如

• 限制总并发数（比如数据库连接池、线程池）
• 限制瞬时并发数（如nginx限制瞬时并发连接数）
• 限制时间窗口内的平均速率（如Guava的RateLimiter、nginx的limit_req模块，限制每秒的平均速率）
• 限制远程接口调用速率、限制MQ的消费速率等

3、Hystrix简介

        Hystrix（豪猪----->刺），宣言“defend your app”是由Netflix开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止级联失败，从而提升系统的可用性与容错性。Hystrix主要通过以下几点实现延迟和容错。

• 包裹请求：使用HystrixCommand包裹对依赖的调用逻辑。 自动投递微服务方法（@HystrixCommand 添加Hystrix控制） ——调用简历微服务
• 跳闸机制：当某服务的错误率超过一定的阈值时，Hystrix可以跳闸，停止请求该服务一段时间。
• 资源隔离：Hystrix为每个依赖都维护了一个小型的线程池(舱壁模式)（或者信号量）。如果该线程池已满， 发往该依赖的请求就被立即拒绝，而不是排队等待，从而加速失败判定。
• 监控：Hystrix可以近乎实时地监控运行指标和配置的变化，例如成功、失败、超时、以及被拒绝的请求等。
• 回退机制：当请求失败、超时、被拒绝，或当断路器打开时，执行回退逻辑。回退逻辑由开发人员自行提供，例如返回一个缺省值。
• 自我修复：断路器打开一段时间后，会自动进入“半开”状态。