文章目录
- 目录
- 服务限流
- 服务降级
- 服务熔断
服务限流
C ⇄ S 的异常问题：C 的请求太多，超出 S 的服务能力，导致 S 不可用。例如：DoS 攻击，企图耗尽被攻击对象的资源，让目标系统无法响应直至崩溃。因此，S 需要能够进行自我保护，例如：S 对 C 限流，保护 S 的服务资源。
限流通常在网关或网络层面实施。对各类请求设置最高的 QPS 阈值，当请求高于阈值时直接阻断。常用的限流算法有滑动计数，漏斗限流和令牌桶限流三种。
- 滑动计数限流：按时间片（比如 1 秒）定义滑动窗口，计数器记录当前窗口的请求次数，达到阈值就限流，窗口滑动后计数器归零。可采用循环队列数据结构实现。
- 漏斗限流：维护一个队列，所有请求进队列，按 FIFO 服务，队满溢出则丢弃请求。
- 令牌桶限流：按固定速率往桶中存入令牌，服务前先从桶中取令牌，取到令牌才服务。
限流策略有很多，最简单的比如当单位时间内请求数过多时，丢弃多余的请求。另外，也可以考虑分区限流。仅拒绝来自产生大量请求的服务的请求。例如：商品服务和订单服务都需要访问促销服务，商品服务由于代码问题发起了大量请求，促销服务则只限制来自商品服务的请求，来自订单服务的请求则正常响应。
C ⇄ S 的异常问题：S 自身出现异常，或者由于资源有限需要对部分 C 请求故意表现为异常（类似限流），为了不影响其他服务功能，主动关闭服务的一些功能。
当下游服务停止工作后，如果该服务并非核心业务，则上游服务应该降级，以保证核心业务不中断。比如：网上超市下单界面有一个推荐商品凑单的功能，当推荐模块挂了后，下单功能不能一起挂掉，只需要暂时关闭推荐功能即可。
简而言之，降级类似于把部分代码注释掉，牺牲部分功能。这要求 S 在实现时，需要具备感知异常的能力，并对关键逻辑实现开关控制。实际场景中，对异常的感知通常由熔断器实现。
服务熔断C ⇄ S 的异常问题：当 C 发现 S 出现异常（比如：大量超时），由 C 主动出击，暂停对 S 的请求。
当一个服务因为各种原因停止响应时，调用方通常会等待一段时间，然后超时或者收到错误返回。如果调用链路比较长，可能会导致请求堆积，整条链路占用大量资源一直在等待下游响应。所以当多次访问一个服务失败时，应熔断，标记该服务已停止工作，直接返回错误。直至该服务恢复正常后再重新建立连接。
C 对 S 熔断后，那么原本需要调用 S 实现的逻辑怎么办呢？C 可以使用 Mock 数据、缓存数据、缺省数据等替代，或者干脆就是抛异常返回错误信息。此时，如果 C 也是一个服务，它相当于做了服务降级。所以我们经常看到服务熔断和服务降级一起出现（Hystrix 的断路器在实现时就是把熔断和降级方案打包实现的）。但本质上它们不是一回事，降级发生在 S，熔断发生在 C。之所以配合实现，是因为许多微服务模块同时承担 C 和 S 两种角色。
服务熔断的设计有两个关键点：
- 判断何时熔断：通常使用无锁循环队列计数来实现。C 对每次请求 S 的正常、异常（失败、拒绝、超时）返回计数，当异常返回次数超过设定阈值时进行熔断。
- 何时从熔断状态恢复：处于熔断状态时，C 每隔一段时间（比如 5 秒），允许部分请求通过，若这部分请求正常返回，就恢复熔断。
