限流、熔断、降级和隔离怎么区分？系统架构设计师讲解

限流、熔断、降级和隔离怎么区分？

微服务稳定性题很容易被一句“保护系统”糊住。限流、熔断、降级、隔离确实都在保护系统，但触发原因和保护对象不一样。老师讲这类题时，一般先问：是流量太大，还是下游坏了？是要少进来一点，还是要别继续打过去？

系统架构设计师专题软考题库编辑部持续更新

内容整理：软考题库编辑部最近更新：2026-06-14

限流先看“入口流量”

限流的核心是控制进入系统或某个接口的请求速率。秒杀活动、开放 API、登录接口、下单接口，如果瞬间请求量超过系统承载能力，就需要按令牌桶、漏桶、配额、并发数等方式控制进入量。

题干如果说“每秒最多接收多少请求”“接口配额”“突发流量”“防止流量一下子打满系统”，优先想到限流。限流不是系统坏了才做，它更像在入口处控制水流，避免后面所有组件被一起冲垮。

熔断更像电路保护。调用方连续访问某个下游服务，如果频繁超时或失败，继续调用只会占住线程、连接和等待时间，甚至引发级联故障。熔断就是在失败达到阈值后，暂时停止调用这个不稳定依赖。

考试题里如果出现“库存服务连续超时”“积分服务故障拖慢订单主流程”“失败率超过阈值后暂时停止调用”，优先想到熔断。它不是永久关闭服务，通常还会有打开、半开、关闭等恢复过程。

秒杀入口请求太多：先想限流。

库存服务连续超时：先想熔断。

积分服务不可用但订单仍要提交：先想降级。

不同业务线程池互不挤占：先想隔离。

降级的重点是取舍。系统资源紧张或依赖不可用时，把非核心能力暂时关闭或返回兜底结果，让核心业务还能继续跑。比如下单时积分展示失败，可以先不展示积分；商品推荐服务异常，可以先返回默认推荐；但支付扣款这种核心动作不能随便降级成“假成功”。

很多同学把降级理解成“系统变差就关掉功能”。更准确地说，降级要有业务优先级：先保交易、登录、支付、查询等核心链路，再牺牲推荐、排行榜、个性化展示等非核心能力。

超时是给等待设置边界，避免调用方一直卡住。重试是应对偶发失败，但重试不能无脑加。下游已经扛不住时，大量重试可能把故障放大，所以重试通常要配合退避、限次、熔断和幂等设计。

系统架构设计师题目经常把这些措施组合出现。读题时先抓触发条件：流量大看限流，下游坏看熔断，保核心看降级，防互相拖累看隔离，等待太久看超时，偶发失败看有限重试。这样答题比背名词更稳。