微服务中服务限流、服务降级、服务熔断_熔断策略在网关还是具体服务应用

服务熔断

一般在微服架构中，有一个组件角色叫熔断器。顾名思义，熔断器起的作用就是在特定的场景下关掉当前的通路，从而起到保护整个系统的效果。

在微服务架构中，一般我们的独立服务是比较多的，每个独立服务之间划分责任边界，并通过约定协议接口来进行通信。当我们的调用链路复杂依赖多时，很可能会发生雪崩效应。

假设有这么一个场景，有A, B, C, D四个独立服务，A会依赖B，C，D；当D发生负载过高或网络异常等导致响应过慢或超时时，很可能A会因此堆积过多的等待链接，从而导致A的状态也转为异常，后面依赖到A的其他服务跟着发生链式反应，这将会导致大面积的服务不可用，即使本来是一些没有依赖到B，C，D的服务。如下图所示：

这不是我们希望看到的结果，所以这个时候熔断器可以派上用场。最简单的做法，我们为每个依赖服务配置一个熔断器开关，正常情况下是关闭的，也就是可以正常发起请求；当请求失败(超时或者其他异常)次数超过预设值时，熔断器自动打开，这时所有经过这个熔断器的请求都会直接返回失败，并没有真正到达所依赖的服务上。这时服务A本身仍然是能正常服务的， 如下图所示：

那么熔断器具体又是怎么工作的呢？来看下，一个拥有基本功能的熔断器的状态机大体是这样子的：

主要在三种状态中转换：

关闭状态 ：
当熔断器处于关闭状态时，请求是可以被放行的；
当熔断器统计的失败次数触发开关时，转为打开状态。

打开状态 ：
当熔断器处于打开状态时，所有请求都是不被放行的，直接返回失败；
只有在经过一个设定的时间窗口周期后，熔断器才会转换到半开状态

半开状态 ：
当熔断器处于半开状态时，当前只能有一个请求被放行；
这个被放行的请求获得远端服务的响应后，假如是成功的，熔断器转换为关闭状态，否则转换到打开状态。

服务降级

C ⇄ S 的异常问题：C 的请求太多，超出 S 的服务能力，导致 S 不可用。例如：DoS 攻击，企图耗尽被攻击对象的资源，让目标系统无法响应直至崩溃。因此，S 需要能够进行自我保护，例如：S 对 C 限流，保护 S 的服务资源。

限流通常在网关或网络层面实施。对各类请求设置最高的 QPS 阈值，当请求高于阈值时直接阻断。常用的限流算法有滑动计数，漏斗限流和令牌桶限流三种。

• 滑动计数限流：按时间片（比如 1秒）定义滑动窗口，计数器记录当前窗口的请求次数，达到阈值就限流，窗口滑动后计数器归零。可采用循环队列数据结构实现。
• 漏斗限流：维护一个队列，所有请求进队列，按 FIFO 服务，队满溢出则丢弃请求。
• 令牌桶限流：按固定速率往桶中存入令牌，服务前先从桶中取令牌，取到令牌才服务。

限流策略有很多，最简单的比如当单位时间内请求数过多时，丢弃多余的请求。另外，也可以考虑分区限流。仅拒绝来自产生大量请求的服务的请求。例如：商品服务和订单服务都需要访问促销服务，商品服务由于代码问题发起了大量请求，促销服务则只限制来自商品服务的请求，来自订单服务的请求则正常响应。

服务降级

C ⇄ S 的异常问题：S 自身出现异常，或者由于资源有限需要对部分 C 请求故意表现为异常（类似限流），为了不影响其他服务功能，主动关闭服务的一些功能。

当下游服务停止工作后，如果该服务并非核心业务，则上游服务应该降级，以保证核心业务不中断。比如：网上超市下单界面有一个推荐商品凑单的功能，当推荐模块挂了后，下单功能不能一起挂掉，只需要暂时关闭推荐功能即可。

简而言之，降级类似于把部分代码注释掉，牺牲部分功能。这要求 S 在实现时，需要具备感知异常的能力，并对关键逻辑实现开关控制。实际场景中，对异常的感知通常由熔断器实现。