服务熔断、降级、限流

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

20180331133509474.png

服务熔断

熔断机制是应对雪崩效应的一种微服务链路保护机制。当下游的服务因为某种原因突然变得不可用,上游服务为了保证自己整体服务的可用性,不再继续调用目标服务,直接返回,快速释放资源。如果目标服务情况好转则恢复调用。
需要说明的是熔断其实是一个框架级的处理,那么这套熔断机制的设计,基本上业内用的是断路器模式,如 Martin Fowler 提供的状态转换图如下所示
725429-20190130230717121-435467568.jpg

  • 最开始处于 closed 状态,一旦检测到错误到达一定阈值,便转为 open 状态;
  • 这时候会有个 reset timeout,到了这个时间了,会转移到 half open 状态;
  • 尝试放行一部分请求到后端,一旦检测成功便回归到 closed 状态,即恢复服务;

服务降级

服务降级有两种常见场景

  • 当下游的服务因为某种原因响应过慢,下游服务主动停掉一些不太重要的业务,释放出服务器资源,增加响应速度。
  • 当下游的服务因为某种原因不可用,上游主动调用本地的一些降级逻辑,避免卡顿,迅速返回给用户!

由上面的不同的场景可以理解:

  • 服务降级有很多种降级方式!如开关降级、限流降级、熔断降级!
  • 服务熔断属于降级方式的一种!

熔断与降级是必定一起出现的,当上游服务发现下游服务不可用时,则会进入服务降级逻辑。而熔断就是降级的一种方式。
从触发原因上来说,熔断的出现,一般是下游某个服务不可用导致的;而降级的出现,一般是从系统整体的负载考虑,降低业务级别不高的微服务资源。

开关降级

开关降级的意思就是在应用程序中,设置一个开关,当开关打开时,执行对应业务,关闭时不执行对应业务。在应用程序中设置开关的过程,也叫做 “埋点”。

简化业务流程

简化业务流程执行,当系统无法抗住时,关闭非核心业务流程,从而简化业务流程。

关闭次要功能

将功能进行主次分级,对次要功能进行开关控制。当整体系统无法抗住时,关闭开关,暂时停止次要功能执行,从而把更多资源让给主要功能执行。

降低一致性

如果发现,上述操作还是无法满足需要时。可以对主要业务下手,将强一致性降低为最终一致性。

服务限流

微服务提供者要清楚自己提供的能力极限。当并发量超出自己的极限,则进行服务限流。
服务限流有两种效果:

  • 直接拒绝(Reject),当前的请求量超过对应规则的阈值后,新的请求就会被立即拒绝。这种方式适用于对系统处理能力确切已知的情况下,比如通过压测确定了系统的准确水位时。
  • 匀速排队(Throttling)方式会严格控制请求通过的间隔时间,也即是让请求以均匀的速度通过,对应的是漏桶算法。多余的请求可以排队等待而不是立即拒绝。

uniform-speed-queue.png

需要注意的是,在限流配置的时候,一般从数据库压力入手。假设 Mysql 的极限 QPS 是 1000,这个微服务有 10 个 pod,那么限流的配置应该是 100 QPS。

https://www.cnblogs.com/rjzheng/p/10340176.html
https://zhuanlan.zhihu.com/p/341939685
https://blog.csdn.net/aa1215018028/article/details/81700796