Hystrix：Spring Cloud服务熔断与降级组件

Hystrix：Spring Cloud服务熔断与降级组件

问题总结

1. 熔断器？

2. Spring Cloud Hystrix？

3. Hystrix服务降级？

4. 全局降级方法？

5. 解耦降级逻辑？

6. Hystrix服务熔断？

7. Hystrix故障监控？

问题答案

1. 熔断器

• 当微服务系统的一个服务出现故障时，故障会沿着服务的调用链路在系统中疯狂蔓延，最终导致整个微服务系统的瘫痪，这就是“雪崩效率”。
• 微服务架构引入“熔断器”的一系列服务容错和保护机制。
• 熔断器在某个服务发生故障后，向服务调用方返回一个符合预期的、可处理的降级响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常。

---

2. Spring Cloud Hystrix

• Spring Cloud Hystrix具有服务降级、服务熔断、线程隔离、请求缓存、请求合并以及实时故障监控等功能。
  • 保护线程资源：防止单个服务的故障耗尽系统中所有线程资源。
  • 快速失败机制：当某个服务发生了故障，不让服务调用方一直等待，而是直接返回失败。
  • 提供降级（FallBack）方案：在请求失败后，提供一个设计好的降级方案。
  • 防止故障扩散：使用熔断机制，防止故障扩散到其他服务。
  • 监控功能：提供熔断器故障监控组件Hystrix Dashboard，随时监控熔断器状态。

---

3. Hystrix服务降级

• 保证当前服务不受其他服务故障的影响，提高服务的健壮性。

  • 在服务器压力剧增时，根据实际业务情况及流量，对一些不重要、不紧急的服务进行有策略地不处理或简单处理，从而释放服务器以保证核心服务正常运作。
  • 当某些服务不可用时，为了避免长时间等待造成服务卡顿或雪崩效应，主动执行备用的降级逻辑立即返回一个友好的提示，以保证主体业务不受影响。

• 服务降级处理的场景:

  • 程序运行异常

  • 服务超时

  • 熔断器处于打开状态

  • 线程池资源耗尽

---

4. 全局降级方法

• 只有业务方法没有指定其降级方法时，服务降级时才会出发全局回退方法。若业务方法指定了自己的回退方法，那么在服务降级时，就只会直接触发它自己的回退方法，而非全局回退方法。

---

5. 解耦降级逻辑

• 业务方法指定的降级方法和全局降级方法，都必须在同一个类中才能生效，业务逻辑和降级逻辑耦合度高。

1. 通过重写服务类方法，实现解耦回退逻辑。

---

6. Hystrix服务熔断

• 熔断状态

  • 熔断关闭状态：服务访问正常，熔断器处于关闭状态，客户端正常对服务进行调用。
  • 熔断开启状态：默认情况下，在固定时间内接口调用出错比率达到一个阈值（50%），熔断器会进入熔断开启状态。进入熔断状态后，后续对该服务的调用都会被切断，熔断器会执行本地的降级（FallBack）方法。

  

• Hystrix实现熔断机制

  1. 当服务调用出错率达到或超过Hystrix规定的比率（默认50%）后，熔断器进入熔断开启状态。
  2. 进入熔断开启状态后，Hystrix会启动一个休眠时间窗，在这个时间窗内，该服务的降级逻辑会临时充当业务主逻辑，原来的逻辑不可用。
  3. 当有请求再次调用该服务时，会直接调用降级逻辑快速地返回失败响应，以避免系统雪崩。
  4. 当休眠时间窗到期后，Hystrix会进入半熔断状态，允许部分请求对服务原来的主业务逻辑进行调用，并监控其调用成功率。
  5. 如果调用成功率达到预期，则说明服务已经恢复，Hystrix进入熔断关闭状态，服务原来的主业务逻辑恢复；否则Hystrix重新进入熔断开启状态，休眠时间重新来开始进行。

---

7. Hystrix故障监控

• Hystrix 会持续地记录所有通过 Hystrix 发起的请求的执行信息，并以统计报表的形式展示给用户，包括每秒执行请求的数量、成功请求的数量和失败请求的数量等。