微服务雪崩效应

微服务系统中, 每一个服务专心于自己的业务逻辑, 并对外提供相应的接口, 看上去似乎耦合度比较低, 但经常会遇见这样一种场景:

可以看到, 当 C 服务挂掉时, B 服务还在不断地调用 C 服务期望获得结果, 结果在 B 服务内部产生了大量的调用等待和重试调用的线程, 随着新的请求不断地往这条调用链路上跑, 那么 B 服务的资源就会被这些线程耗尽, 从而导致 B 服务也不可用。同理, 当 B 服务也挂掉时, A 服务挂掉也只是时间的问题了。

由于服务与服务之间的依赖性, 故障会传播, 最终将会对整个微服务系统造成灾难性的后果, 这就是微服务故障的雪崩效应。

微服务中常见的容错方案

在分布式场景下, 由于网络不可靠或者服务自身设计不合理等各种各样的原因, 我们无法完全杜绝雪崩源头的发生。
只有设计合理的容错方案, 保证在一个服务发生问题之后, 不会级联地影响到其他服务的正常运行, 才是应对雪崩效应的最好办法。

常见的服务容错思路

• 隔离 : 按照一定的原则划分为若干个服务模块, 各个模块之间相互独立, 无强依赖。当有故障发生时, 能将问题和影响隔离在某个模块内部, 而不扩散锋线, 不波及其他模块, 不影响微服务系统整体。常见的隔离方式有:
  • 线程池隔离
  • 信号量隔离
• 超时 : 在上游服务调用下游服务时, 设置一个最大响应时间, 如果超过这个时间下游还未做出反应, 则直接断开请求, 执行本地 fallback 逻辑。
• 限流 : 限流就是限制系统的输入和输出流量来达到保护系统的目的。
• 熔断 : 当下游服务宕机或者响应变慢时, 上游服务为了保护系统整体的可用性, 可以暂时切断对下游服务的调用。服务熔断一般有三种状态:
  • 熔断关闭状态(Closed) : 当下游服务没有故障时, 熔断器所处的状态, 对下游服务的调用不做任何限制。
  • 熔断开启状态(Open) : 当下游服务宕机时, 熔断器所处的状态, 后续对该服务的调用将不再经过网络, 直接执行本地 fallback 逻辑。
  • 半熔断状态(Half-Open) : 当下游服务宕机一段时间后, 熔断器所处的状态, 尝试恢复对该服务的调用, 允许有限的流量调用该服务, 并监控调用成功率。此时:
    • 若成功率达到预期, 则说明下游服务已恢复, 熔断器进入熔断关闭状态(Closed)。
    • 若成功率达不到预期, 则说明下游服务仍处于宕机状态, 熔断器重新进入熔断开启状态(Open)。
• 降级 : 当整个微服务系统的负载超出了预设的上限阈值时, 为了保证重要或基本的服务能正常运行, 我们可以将一些不重要的服务暂停使用或不紧急的任务延迟执行。最简单的例子, 当下游服务宕机时, 直接快速失败(fail-fast)执行 fallback 逻辑。

Hystrix 简介

Hystrix 是 Netflix 开源的一款分布式服务容错系统, 是一种客户端熔断和断路器的解决方案。

Hystrix 设计目的是将应用中的远程系统访问、服务调用、第三方依赖包的调用入口, 通过资源控制的方式隔离开, 避免了在分布式系统中故障的级联塌方式传递, 提升本系统的弹性和健壮性。

Hystrix 通过添加延迟容忍和容错逻辑, 可以实现当调用链路中某个服务出现故障时, 阻止级联故障, 以保证服务的稳定运行。