服务降级原理与常见降级策略：给微服务装上”安全气囊”

前言

上一篇我们聊了一次真实的服务雪崩事故，相信大家对服务雪崩的破坏力已经有了直观感受。那么问题来了：如何避免服务雪崩？

有人可能会说：加机器啊，没有什么是钱解决不了的。但现实是，资源永远是有限的，我们需要在有限的硬件条件下，尽可能保障服务的稳定运行。

最好的方案就是——服务降级。简单来说就是：处理不过来就不处理了，先保证自己活着。

一、什么是服务降级

服务降级是服务自我保护的一种方式，也是保护下游服务的一种方式。它的核心目标是：确保服务不会因为请求突增而彻底崩溃，至少要保证核心功能可用。

想象一下这些场景：

• 服务B的业务线程池全部占满时，应该主动拒绝服务A的请求，保护自己不被拖垮
• 服务A发现服务B多次拒绝请求后，就不要再死缠烂打了，给对方留点余地
• 服务A自己的请求堆积如山时，应该果断拒绝新的客户端请求，堆积再多也处理不过来

这些都是服务降级的体现。就像家里的电路保险丝，电流过大时自动熔断，保护整个电路不被烧毁。

二、三种常见的服务降级方式

服务降级的实现方式有很多种，其中最常见的有三种：

降级方式	核心思想	适用场景
限流降级	限制请求数量，超出阈值直接拒绝或排队	秒杀、突发流量
熔断降级	检测到下游”不行了”就自动切断调用	依赖不稳定的服务
开关降级	通过开关人工控制某些功能是否可用	大促、已知高峰期

下面我们逐一展开来讲。

三、限流降级：把流量挡在门外

什么是限流降级

假设服务A依赖服务B完成一次请求。服务B可以通过压测提前知道自己单节点的最大并发处理能力，只要不超过这个极限，服务就能稳定运行。

限流降级就是给服务设定一个”最大接待能力”，比如每秒只处理200个请求，超出的部分要么直接拒绝，要么排队等待。

限流的粒度可以很灵活：

• 单节点限流：限制每个实例的处理能力
• 集群限流：限制整个服务集群的总流量（实现难度更高，需要统一统计）

流量控制策略

超过阈值的流量怎么办？直接拒绝太粗暴了，我们还可以有更”温柔”的策略：

• 直接拒绝：最简单粗暴，超出阈值直接报错，适用于秒杀等场景
• 匀速排队：让请求排队慢慢处理，适用于间歇性突增的流量

举个例子：某一秒突然涌入大量请求，接下来几秒又很空闲。如果直接拒绝，用户体验不好；如果用匀速排队，系统可以在接下来的空闲时间里慢慢把这些请求处理掉。

限流降级的适用场景

限流降级不是万能的，它有自己的适用场景。

比如电商下单场景，如果一限流就导致很多用户下单失败，那意味着直接的收入损失。老板宁愿多加几台服务器，也不愿看到用户想买买不了。这种场景更适合用集群自动伸缩来解决。

限流降级最适合的场景是秒杀——抢到的是有效流量，抢不到的本来就是无效流量，拒绝了也不心疼。

四、熔断降级：像保险丝一样保护系统

什么是熔断降级

假设服务A依赖服务B，如果服务A能感知到服务B的状态，在服务B”不行了”的时候主动停止调用，那服务A自身就不会被拖累。

怎么判断服务B”行不行”呢？

比如一秒内向服务B发了230个请求，其中30个超时或异常。根据这个数据，我们可以预测：后续请求服务B大概率也会失败。既然发出去也是异常，不如直接放弃，还能节省资源。

这就是熔断降级——当下游服务突然不可用或不稳定时，上游自动切断调用，保证自己的可用性。就像保险丝一样，电流异常升高时自动熔断。

熔断的自动恢复机制

服务B不会一直不行，等它恢复了，服务A也应该能自动恢复调用。

怎么实现自动恢复呢？答案是时间窗口。

熔断以一个固定时长为周期（比如1秒），每个时间窗口重新统计请求总数、异常数等指标。如果在一个窗口内触发了熔断，等下一个窗口就重新尝试，看看服务是不是恢复了。

熔断降级的实现位置

熔断降级不一定非要在消费端实现，服务提供端也可以自己实现。

打个比方：别人发现你的缺点可能会疏远你，但你自己也能发现自己的问题，及时调整，避免给别人留下不好的印象。

• 消费端熔断：调用方统计调用情况，发现异常就不再调用（对接第三方接口时只能用这种）
• 提供端熔断：服务提供者自己统计接口处理情况，处理不过来就主动拒绝请求

Sentinel的系统负载保护本质上也是一种熔断降级——当系统负载过高时，主动拒绝新请求。

三种常见熔断策略

熔断降级通常基于以下几种指标来判断：

1. 异常数策略：每秒请求异常数超过阈值时触发熔断
2. 异常比例策略：每秒请求异常率超过阈值时触发熔断
3. 响应时长策略：每秒请求平均耗时超过阈值时触发熔断

异常越多、异常比例越高、平均耗时越长，都说明服务的处理能力在下降。

五、开关降级：大促前的”断臂求生”

什么是开关降级

开关降级是另一种常见的降级方式，它的核心思想是：在有限的硬件条件下，牺牲一些非核心功能，换取核心功能的高并发处理能力。

做电商的朋友对开关降级应该最熟悉。每次大促之前，我们都会把一些”无关紧要”的功能关掉，比如：

• 用户头像上传
• 评论功能
• 推荐功能
• 各种非核心查询

只保留最核心的下单、支付功能，确保核心链路的稳定。

开关控制方式

控制降级开关的方式有很多种：

• 人工控制：通过配置中心或Redis手动开关，适合大促等可预测的场景
• 定时任务控制：在固定时间段自动开启/关闭，适合有规律的高峰期

比如外卖平台的高峰期在中午，就可以11点左右打开降级开关，13点半之后关闭。

六、三种降级方式对比总结

对比维度	限流降级	熔断降级	开关降级
触发时机	流量达到阈值就触发	异常/耗时达到阈值才触发	人工或定时控制
是否自动恢复	流量降下来就恢复	有自动恢复机制	需要手动/定时恢复
主动性	主动限制流量	被动响应故障	完全人工控制
适用场景	突发流量、秒杀	依赖不稳定服务	大促、已知高峰期
实现位置	消费端/提供端都可以	消费端/提供端都可以	一般在提供端

几个关键区别：

• 限流降级：就算系统没到瓶颈，只要流量到了阈值就会限流，比较”刚性”
• 熔断降级：尽可能处理所有请求，容忍一些失败，实在不行才熔断，比较”柔性”，还能自动恢复
• 开关降级：最”硬核”，直接关掉某些功能，适合可以明确预估并发突增的场景

总结与思考

服务降级的本质是：牺牲一部分流量或功能，换取整个系统的稳定运行。 这是一种”丢卒保车”的智慧。

几个值得思考的问题：

1. 降级不是”银弹”：降级只是应急手段，不能替代性能优化和架构设计。该加机器还是得加，该优化代码还是得优化。
2. 降级策略要提前规划：不要等到线上出问题了才想起来要降级，哪些接口需要限流、哪些场景需要熔断、大促时关哪些功能，都要提前梳理好。
3. 降级要有灰度和验证：降级规则配置完要验证，不能想当然。比如限流阈值设多少合适，要基于压测数据来定。
4. 用户体验也很重要：降级时不能直接给用户甩一个报错页面，要有友好的提示，比如”当前抢购人数过多，请稍后再试”。

理解了服务降级的概念和常见方式，接下来我们就可以正式进入Sentinel的世界了。下一篇，我们来聊聊为什么选择Sentinel，以及它和Hystrix的对比。