应用层容灾 - omigaw/spring- GitHub Wiki

防雪崩利器:熔断器Hystrix的原理与使用

  • 雪崩效应原因:硬件故障、程序Bug、重试加大流量、用户大量请求。
  • 雪崩的对策:限流、改进缓存模式(缓存预加载、同步调用改异步)、自动扩容、降级。
  • Hystrix设计原则:
    • 资源隔离:Hystrix通过将每个依赖服务分配独立的线程池进行资源隔离,从而避免服务雪崩。
    • 熔断开关:服务的健康状况 = 请求失败数/请求总数,通过阈值设定和滑动窗口控制开关。
    • 命令模式:通过继承HystrixCommand来包装服务调用逻辑。

服务雪崩效应的定义

分布式系统中经常会出现某个基础服务不可用造成整个系统不可用的情况,这种现象被称为服务雪崩效应。为了应对服务雪崩,一种常见的做法是手动服务降级。而Hystrix的出现,给我们提供了另一种选择。
服务雪崩效应是一种因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过程。

服务雪崩效应形成的原因

1.服务提供者不可用 2.重试加大流量 3.服务调用者不可用

服务雪崩的每个阶段都可能由不同的原因造成,比如造成服务不可用的原因有:

  • 硬件故障
  • 程序Bug
  • 缓存击穿
  • 用户大量请求

形成重试加大流量的原因有:

  • 用户重试
  • 代码逻辑重试 在服务提供者不可用后,用户由于忍受不了界面上长时间的等待,而不断刷新页面甚至提交表单。服务调用端的会存在大量服务异常后的重试逻辑。这些重试都会进一步加大请求流量。 最后,服务调用者不可用产生的主要原因有: 同步等待造成的资源耗尽 当服务调用者使用同步调用时,会产生大量的等待线程占用系统资源。一旦线程资源被耗尽,服务调用者提供的服务也将处于不可用状态,于是服务雪崩效应产生了。

针对造成服务雪崩的不同原因,可以使用不同的应对策略:

1.流量控制 2.改进缓存模式 3.服务自动扩容 4.服务调用者降级服务

流量控制的具体措施包括:

1.网关限流 2.用户交互限流 3.关闭重试

使用Hystrix预防服务雪崩

  • 资源隔离
  • 熔断器
  • 命令模式