下游故障时怎样避免拖垮整个系统：限流、熔断、隔离、降级与背压

某天，续签服务的流量从 2,000 QPS 涨到 5,000 QPS，钱包服务的数据库开始变慢。调用耗时从 80 ms 升到 2 s，续签服务里等待钱包响应的线程和连接越来越多。客户端因超时重试，网关也重试一次，消息补偿任务随后加入。几分钟内，原本只在钱包服务里的问题扩散到网关、续签服务、线程池、连接池和数据库。

这种事故不能靠一个“熔断开关”解决。流量进入系统前，要判断是否接受；请求进入后，要限制能占用多少并发资源；不同依赖之间要隔离；下游明显失效时，要停止无意义调用；上游生产速度过快时，要把压力反馈回去；业务还要决定失败时返回什么。限流、并发控制、隔离、熔断、背压和降级分别负责其中一段。

本文回答的问题是：当请求量超过处理能力，或者某个下游持续变慢时，怎样组合这些机制，使局部故障不会演变成级联故障？ 超时、重试、幂等和 RPC 结果未知已经分别在超时、重试与幂等和一次 RPC 可能处于哪些状态中展开；实例级健康判断与摘除见服务发现、健康检查与故障摘除。这里重点讨论系统容量的保护和机制之间的配合。

先用一张表分清六种机制

机制	观察的信号	做出的动作	主要保护对象
限流	单位时间内到达量	拒绝、排队或发放令牌	系统入口与业务配额
并发控制	当前在途请求数	等待或拒绝新请求	线程、连接、内存与下游容量
隔离	资源属于哪个调用方或依赖	拆分线程池、信号量、连接池和配额	其他租户、接口与依赖
熔断	一段窗口内的失败率、慢调用率	暂停调用，随后小流量探测	调用方和失效依赖
背压	消费速度低于生产速度	让生产方减速或停止发送	队列、内存和整条流
降级	依赖不可用或预算不足	返回较弱结果、异步处理或关闭功能	核心业务可用性

这六种机制的触发位置不同。限流通常发生在请求刚进入某个保护域时；熔断发生在决定是否调用某个依赖时；隔离贯穿资源分配；背压连接生产者和消费者；降级位于业务决策层。把它们都叫作“防雪崩”，会导致实现时所有开关堆在网关，服务内部依然没有边界。

过载治理中各机制所在的位置

图中有两条容易忽略的边界。入口限流通过后，请求仍可能因下游变慢积累，因此还要限制在途并发。熔断拒绝调用后，也必须有业务结果：直接失败、返回缓存、转异步或标记处理中，这是降级策略，不是熔断器替业务决定的。

一、过载为什么会形成正反馈

系统容量不是一个固定的 QPS 数字。它由请求成本、依赖延迟、资源上限和目标延迟共同决定。一个近似关系来自 Little’s Law：

平均在途请求数 ≈ 平均到达速率 × 平均处理时间

若服务接收 2,000 QPS，平均耗时 100 ms，在途请求约为 200。下游变慢后平均耗时升到 2 s，即使 QPS 没变，在途请求也会接近 4,000。每个请求持有对象、线程栈、连接或响应缓冲区，资源很快耗尽。延迟还会触发上游超时与重试，使实际到达量继续上升。

排队只能吸收短暂波动，不能创造处理能力。若到达速率长期大于完成速率，队列长度会持续增长。排在后面的请求开始执行时，调用方的 deadline 可能已经过期，服务却仍为一个无人等待的结果消耗数据库与 CPU。无界队列把“立即拒绝”改成“占用大量内存后超时”。

下游变慢后形成的过载正反馈

Google SRE 在级联故障分析中把延迟上升、资源耗尽和重试放大列为常见传播路径，并建议使用小而有界的队列、负载卸载和重试预算。图里的保护点并不要求同时拒绝同一批请求：入口控制总量，并发控制限制正在消耗资源的工作，熔断减少确定性失败，背压阻止上游继续堆积。

容量预算要落到四个具体上限

一条同步调用链至少要给出四类预算：端到端 deadline、每跳超时、最大在途并发和最大等待队列。只有 QPS 上限，没有并发与 deadline，慢请求仍能占满系统；只有并发上限，没有入口速率，所有客户端会同时竞争少量许可，尾延迟和拒绝率无法控制。

例如续签接口的端到端 deadline 是 800 ms，可以给本地校验 30 ms、钱包调用 300 ms、数据库落流水 150 ms，保留网络抖动和返回的余量。钱包调用最多允许 400 个并发，等候许可不超过 20 ms。等待超时后，系统应立即执行已定义的失败或异步路径，不能再进入另一个无界队列。

这些数值来自容量测试和依赖 SLO，不是通用模板。关键是所有等待都有上限，而且越接近链路末端，可用预算越少。下游不能拿到一个比上游 deadline 更长的超时。

二、限流控制进入保护域的速率

限流回答“在这段时间内最多接收多少请求”。它适合防止突发流量压垮入口，也适合表达产品配额，例如每个用户每秒只能发起五次验证码请求。限流维度决定公平性：全局 QPS 保护集群，总租户配额防止一个客户占满容量，用户或业务键配额抑制热点，接口配额则把昂贵请求和便宜请求分开。

常见算法解决的是不同流量形状

固定窗口计数器实现简单，但窗口交界处可能在很短时间内放过两倍请求。滑动窗口把统计分成多个小格，边界更平滑，代价是更多状态。令牌桶按固定速度补充令牌，并允许桶容量范围内的突发，适合多数 API；漏桶以稳定速度排出，更强调削平输出。

令牌桶：
  refill_rate = 2,000 tokens/s
  capacity    = 500 tokens
  request     = consume 1 token or reject

这表示系统长期接受约 2,000 QPS，同时容忍最多 500 个请求的短突发。桶容量不能随意设大：若后端只能承受 200 个额外在途请求，允许 5,000 个瞬时令牌只会把流量尖峰搬到服务内部。

Resilience4j RateLimiter用 limitRefreshPeriod 和 limitForPeriod 描述周期性许可，并限制获取许可的等待时间。无论用哪种库，都应明确超出配额时是立即拒绝、等待少量时间，还是转入异步队列。三种行为的延迟和资源成本完全不同。

本地限流和全局限流不能互相替代

本地令牌桶没有网络依赖、延迟低，实例之间却看不到彼此用量。十个实例各放行 300 QPS，集群上限接近 3,000 QPS；扩容还会自动提高总配额。全局限流能表达准确租户配额，但中心计数器会增加延迟和新的故障面。

常见组合是：网关做租户和接口的全局粗粒度配额，每个服务实例再用本地速率与并发限制保护自己。全局系统短暂不可用时，可以使用预分配额度或保守的本地上限。若故障时默认无限放行，限流组件最需要工作的时候反而会失效。

限流返回也属于接口契约。HTTP 可以用 429 Too Many Requests 并携带可重试提示；内部 RPC 需要区分容量拒绝、权限拒绝和业务失败。调用方若对每个 429 立即重试，限流只会制造同步重试风暴。

三、并发控制限制正在消耗的工作

速率相同，耗时不同，需要的资源差异很大。1,000 QPS、10 ms 的接口约有 10 个请求在途；同样 1,000 QPS、2 s 的接口约有 2,000 个请求在途。并发限制直接约束线程、连接、内存和下游活跃请求，更适合应对延迟上升。

最简单的实现是一组信号量许可：进入钱包调用前获取许可，完成、失败或取消时归还。拿不到许可的请求只允许短暂等待，随后快速失败或转为异步。许可数应与钱包连接池、数据库容量以及本服务的内存预算协调。若连接池只有 200 个连接，却允许 2,000 个调用进入，剩余 1,800 个只是换了一个地方排队。

并发上限也可以自适应。控制器观察最小延迟、当前延迟、超时率和利用率，逐步增减许可，在延迟开始陡升前停止加压。自适应策略需要稳定的采样和上下界，不能因一小段网络抖动把许可降到零，也不能把短期成功率当成可无限扩容的证据。

队列必须有长度、等待时间和丢弃策略

并发已满时，有界队列能吸收毫米到秒级的短暂抖动。设计队列时要同时回答：最多几项、最多等待多久、满后丢谁、请求取消后能否移除、进程重启是否允许丢失。缺少任何一项，都可能把队列变成隐藏的可靠消息系统。

同步在线请求通常适合短队列或直接拒绝，因为用户的 deadline 很短。必须可靠执行的任务应写入有持久化、重试和消费语义的消息队列，而不是在应用内存里等待几十秒。实时性和可靠性是两套约束，不能用一个超长线程池队列兼得。

四、背压让生产者感知消费能力

背压用于一条持续的数据流：消费者只能处理 1,000 条/s 时，生产者不能继续以 5,000 条/s 无限发送。有效的背压会把“我还能接收多少”反馈给上游，或者让发送动作本身在容量不足时暂停。只在消费者内部堆队列，没有反馈，不算完整的背压。

Reactive Streams 规范让订阅者通过 request(n) 声明需求，发布者发送的数据不能超过已请求数量。TCP 接收窗口、HTTP/2 flow control、消息系统的消费者拉取与暂停分区，也都在不同层面表达接收能力。它们保护的资源不同：TCP 背压只能阻止更多字节进入某条连接，无法替业务系统决定某个租户的公平配额。

背压必须沿链路传播才有效。服务 B 的输出缓冲区满后暂停读取 A，但 A 若把数据转存到无界内存队列，压力仍停在 A；A 继续从消息队列确认数据，又会让 broker 误以为消费正常。系统需要把暂停、减少预取或拒绝一直传回真正的生产源。

在线 RPC 很难让用户请求无限减速，所以常将背压表现为并发许可、短等待和明确拒绝。流式处理则可以按需求拉取。二者目标相同，交互协议不同。

五、隔离把一个故障限制在自己的资源池

共享资源提高利用率，也让一个依赖的慢调用占满所有资源。若用户画像接口和钱包接口共用同一线程池，画像服务卡住后，扣款请求可能连执行机会都拿不到。隔离（Bulkhead）按依赖、接口、租户或优先级拆分资源和配额，使某个池耗尽时其他池仍能工作。

Resilience4j Bulkhead提供两类模型：信号量 Bulkhead 直接限制并行调用数；固定线程池 Bulkhead 同时限制线程和等待队列。同步阻塞客户端常用独立线程池或信号量，异步客户端可以限制 in-flight future；数据库和 HTTP 客户端还需要独立连接池。

隔离不是池越多越好。每个池都预留容量会降低总体利用率，也增加配置数量。通常先隔离高风险或高价值边界：第三方依赖与内部核心依赖分开，核心交易与报表查询分开，大租户与普通租户分开。剩余流量可以共享一个有总上限的公共池。

虚拟线程降低了阻塞线程的内存和调度成本，却不会增加数据库连接数、下游 CPU 或第三方配额。即使每个请求创建虚拟线程，也仍需用信号量限制对稀缺依赖的并发。

六、熔断停止大概率无效的调用

当钱包服务已经持续超时，继续发送请求只会占用调用方资源，并给钱包恢复制造额外压力。熔断器根据最近一段调用结果判断依赖是否处于失效状态，然后在本地快速拒绝新调用。

典型状态机包含三种状态：

CLOSED    正常放行并统计结果
   │ 失败率或慢调用率超过阈值
   ▼
OPEN      快速拒绝，不再访问下游
   │ 等待恢复窗口
   ▼
HALF_OPEN 只允许少量探测调用
   ├─ 探测稳定成功 → CLOSED
   └─ 探测失败     → OPEN

Resilience4j CircuitBreaker支持按调用数或时间维护滑动窗口，分别计算失败率和慢调用率，并通过最小调用数避免样本过少时误开。Half-open 状态只发放少量许可，避免所有调用方在同一时刻恢复全量流量。

熔断范围和失败分类比阈值更重要

一个调用因用户余额不足返回业务拒绝，说明钱包工作正常，不应计入系统失败。连接错误、超时、服务端过载和部分 5xx 才可能进入熔断统计。慢调用也要单独观察：若所有请求最终成功但耗时 5 s，资源依然会被拖垮。

熔断 key 过粗会扩大影响。把整个 wallet-service 共用一个熔断器，某个机房故障可能切断所有机房；把每个 URL 都拆开，又会让样本太少。常见维度是调用方、目标服务、方法和区域，再结合实际故障域取舍。

熔断还要区分服务发现文章中的实例摘除。实例摘除处理“某个 endpoint 是否应该继续被选中”，负载均衡器还能改选其他健康实例；熔断处理“这一类依赖调用是否整体仍值得尝试”。某个实例连续连接失败时应先摘除它，所有实例都在超时或依赖整体过载时，服务级熔断才开始发挥作用。

Half-open 恢复需要限制探测洪峰

如果一百个调用实例各自维护本地熔断器，它们可能在相同等待时间后一起进入 half-open。每台只放十个探测，也会产生一千个请求。等待时间应加入抖动，探测许可要小，必要时结合全局并发限制和渐进放量。一次成功只能证明一个请求成功，不能证明依赖已经恢复到满载容量。

Envoy 的 circuit breaking还把最大连接数、在途请求数、待处理请求数和重试数纳入上游保护。工程产品中的“熔断”经常包含并发与队列上限；理解配置时应看它实际限制的资源，而不是只看功能名称。

七、降级决定故障期间交付什么业务结果

熔断器打开后只会返回“本次调用不应发出”。降级要由业务回答接下来怎么办。可以使用过期缓存、隐藏非核心模块、降低结果精度、转异步、返回“处理中”，也可以明确失败。安全的降级不能伪造核心事实。

对商品推荐而言，返回一份稍旧的列表通常可接受；对扣款而言，在没有钱包确认时返回“支付成功”会制造资金错误。支付链路可以记录一笔带幂等业务号的处理中流水，异步查询钱包结果并最终收敛，但前端必须展示真实状态。这里依赖的是状态机、幂等和补偿，不是一段默认值代码。

降级前可以把依赖分成三类：

依赖类型	失败时策略	例子
核心强依赖	失败、处理中或可靠异步化	扣款、库存确认、权限校验
可替代依赖	缓存、静态规则或较弱算法	推荐、画像、搜索排序特征
可省略依赖	跳过并记录待补动作	通知、埋点、非关键装饰信息

缓存降级也有边界。权限、价格、库存和风控结果可能不能接受过期值；缓存未命中时若所有请求回源，会在依赖故障时制造新的洪峰。降级数据需要标注最大陈旧时间、适用接口和失效行为。

降级开关必须可观测、可演练并有退出条件。长期保持降级会掩盖真实故障，临时逻辑也可能在几年后成为未测试的主路径。自动降级适合边界清楚的情况，涉及资金与权限时通常需要更严格的状态约束。

八、重试必须服从同一份容量预算

一次请求经过网关、服务 A 和服务 B，若每层最多重试两次，最坏情况下 B 可能收到 3 × 3 = 9 次调用；再加客户端重试，放大会更严重。重试会提高偶发失败下的成功率，也会在过载时增加最稀缺的负载。

重试应满足四个条件：错误可重试、操作幂等、端到端 deadline 仍有余量、重试预算尚未耗尽。指数退避和 jitter 用于打散时间，最大次数与最大总耗时用于封顶。AWS Well-Architected 的重试建议强调退避、抖动和重试上限，并建议避免多层同时重试。

重试预算可表达为“每 100 个正常请求最多额外产生 5 个重试”，也可以使用独立令牌桶。成功请求补充少量令牌，重试消耗令牌；故障率升高后令牌很快用尽，系统停止自我放大。Envoy 也建议用 retry budget 相对活跃请求数限制重试，而不是只设一个固定并发值。

机制顺序要避免绕过保护：重试的每次尝试都必须重新经过熔断器和并发许可，不能在 bulkhead 内部持有许可睡眠退避。请求 deadline 已经过期时要取消下游工作并归还资源。

九、把机制组合成一条可执行的请求路径

没有唯一固定的中间件顺序，但一次同步调用可以按下面的决策关系理解：

1. 校验请求、身份和幂等键
2. 检查端到端 deadline 是否还有预算
3. 通过租户 / 接口速率限制
4. 获取本接口或本依赖的并发许可
5. 查询熔断器是否允许本次尝试
6. 在单次超时内调用一个健康实例
7. 按错误分类记录结果，更新熔断统计
8. 若可重试且预算允许，退避后重新执行 4～7
9. 归还许可，返回成功、明确失败、处理中或降级结果

速率限制放在较前位置，避免已经超额的请求占用昂贵资源。并发许可覆盖真正消耗下游资源的调用，不覆盖退避等待。熔断器需要看到尝试结果，却不能把入口限流拒绝记成下游故障。降级位于调用尝试之外，因为即使熔断器没有打开，超时、限流和资源隔离也可能触发降级。

异常分类应是结构化数据，而不是靠错误字符串：BUSINESS_REJECTED、RATE_LIMITED、BULKHEAD_FULL、CIRCUIT_OPEN、UPSTREAM_TIMEOUT、UPSTREAM_5XX、DEADLINE_EXCEEDED。这些状态决定是否重试、是否计入熔断和向客户端返回什么。

十、用续签支付链路走一遍故障过程

假设续签服务接收请求后调用钱包扣金币，再写本地流水并发放权益。trade_order_no 是幂等业务号，接口 deadline 为 800 ms。钱包正常容量为 2,500 QPS，续签服务给钱包设置 400 个并发许可，单次调用超时 300 ms。

正常状态

网关按用户和接口发放令牌，续签实例再执行本地并发限制。请求从服务发现提供的健康实例中选择一个钱包节点。扣款成功后，本地状态机从 INIT 推进到 PAID，再发放权益。通知写入消息队列，不阻塞主链路。

单个钱包实例故障

连接错误被负载均衡器记录，实例级被动健康检查将该 endpoint 摘除；在 deadline 和重试预算允许时，调用方可以换一个实例重试。其他实例仍健康，因此不应打开整个钱包服务的熔断器。相同 trade_order_no 保证换实例不会重复扣款。

钱包整体变慢

平均耗时上升后，400 个并发许可很快占满。新请求最多等待 20 ms，拿不到许可便停止进入钱包，防止续签线程与连接无限增长。慢调用率达到阈值后熔断器打开，后续请求无需等待 300 ms 超时便走失败路径。重试预算耗尽后不再重试。

续签服务不能把扣款状态写成成功。若钱包支持按 trade_order_no 查询结果，本地可记录 PROCESSING，由 MQ 补偿和 DB Scanner 继续查询；若请求确定没有发送，则可直接失败。客户端看到“处理中”后按状态查询，不自动创建新业务号。

流量本身超过容量

如果钱包健康，但活动流量超过约定容量，入口的接口与用户维度令牌桶先拒绝超额请求。核心会员续签和后台补偿任务使用不同配额与资源池，避免批量扫描抢占在线请求。可延迟的任务通过消息队列消费，消费者根据处理能力减少预取或暂停分区，把背压传回 broker。

恢复阶段

熔断等待期加入随机抖动，half-open 只允许少量探测。钱包成功率恢复后，调用并发逐步增加，不能一步恢复到 400。积压补偿任务设置独立速率上限，否则恢复后的第一波流量会来自系统自己的 backlog。降级开关在核心指标稳定一段时间后退出，并核对处理中订单是否全部收敛。

这个过程里没有任何一个组件单独保证正确性。实例摘除减少坏节点调用，熔断和并发限制保护容量，限流控制流量，幂等与状态机保护资金事实，异步补偿让未知结果最终收敛。

十一、分布式部署中的局部状态与全局约束

限流器、熔断器和并发控制通常先做成本地状态，因为每次请求都访问一个中心协调服务会增加延迟，也会让保护机制依赖新的共享组件。本地状态反应快、故障域小，但扩缩容、流量不均和多机房会让各实例观察不同。

因此要先判断约束是否必须全局精确。防止单实例内存耗尽，本地并发上限即可；限制合作方合同配额，可能需要网关集中计数或分层额度；保护某个数据库集群，可以由每个调用方持有保守额度，再让数据库代理设置总连接上限。全局目标经常由多层近似控制完成，而非每个请求做强一致计数。

本地熔断器也可能产生分歧：一台调用方恰好命中坏实例而打开，另一台仍正常。它不一定是错误，局部保护本就根据局部证据行动。若需要全局故障公告，可以由控制面下发禁用配置，但该路径要有版本、过期时间和回滚，不能用一个永久开关替代数据面检测。

多机房还要防止故障转移把健康机房压垮。A 机房失去 50% 容量后，把全部流量切到本来已运行在 70% 利用率的 B 机房，B 不可能接住。跨区路由、预留容量、入口限流和降级策略需要一起做容量演练。

十二、怎样观测和验证这些策略

只看总体成功率，很难知道请求在哪一层被拒绝。至少应按服务、接口、依赖、区域和租户记录以下指标：

到达 QPS、放行 QPS，以及各限流 key 的拒绝量；
在途并发、许可使用率、等待时长、队列长度与丢弃量；
熔断状态、状态迁移次数、失败率、慢调用率和 half-open 探测结果；
每类错误、重试次数、重试预算余量和重试成功率；
降级触发量、持续时间、返回的数据版本，以及处理中业务数量；
下游延迟分位数、连接池使用率、取消请求与 deadline 超时。

指标标签不能直接使用无界的 user_id 或订单号，否则监控系统本身会出现高基数问题。具体订单用结构化日志和 trace 查询，聚合指标使用有限的租户等级、接口名、区域和错误类别。

压测要越过拐点，而不只证明正常容量

容量测试应逐步增加到目标流量以上，观察吞吐何时不再增长、延迟何时陡升、最先耗尽的是哪种资源。Google SRE 的生产最佳实践建议在负载测试中超越预期容量，并验证优雅拒绝和降级。若压测只到“刚好成功”的 QPS，就看不到保护是否真的生效。

至少覆盖五类实验：突发流量、下游延迟注入、部分实例失败、依赖全失败、恢复后积压回放。每次实验都要检查拒绝是否发生在预期层、核心流量是否仍获得许可、调用方资源是否保持有界、错误状态是否正确，以及解除故障后是否出现恢复洪峰。

配置需要版本化并能回滚。某个阈值从 50% 改成 20% 可能造成频繁熔断；并发从 400 提到 2,000 可能突破钱包数据库上限。变更时应保留旧值、负责人、原因和预期指标，而不是只在事故群里发一条临时命令。

十三、常见的错误组合

每层都重试

这会指数放大流量。指定唯一重试层，其他层传播明确错误；所有重试共享端到端 deadline 和预算。

用大队列代替容量治理

大队列让故障晚一点显现，同时增加尾延迟和内存。队列应有界，等待时间要小于剩余 deadline；可靠任务进入真正的持久化消息系统。

熔断一开就返回假成功

熔断只说明不应继续调用，不说明业务已经完成。资金、库存和权限必须返回真实状态，并依靠查询、幂等和补偿收敛。

所有接口共享一个线程池和连接池

低价值慢查询可以耗尽核心交易资源。按风险和优先级隔离，同时保留总资源上限，避免分池后总连接数失控。

只做网关限流

网关看不到服务内部每个依赖的延迟变化。入口流量合法时，一个慢依赖仍可拖满服务。服务内部需要按依赖做并发控制、隔离和熔断。

只看错误率，不看慢调用和排队

过载早期请求往往仍成功，只是越来越慢。并发数、队列等待、慢调用率和连接池利用率通常比错误率更早发出信号。

十四、落地时从四个问题开始

面对一条新的调用链，不必先引入完整的韧性框架。先写清四件事：系统愿意接收多少工作；每类工作最多占多少在途资源；依赖失败时哪些业务结果仍然诚实；恢复时积压怎样受控地释放。答案会自然映射到限流、并发与隔离、降级和背压。

随后再为熔断和重试选择窗口、阈值与预算。阈值来自压测、SLO 和故障演练：正常慢请求比例是多少，连接失败多快能被实例摘除，打开熔断后业务走哪条路径，half-open 的探测量会不会再次压垮依赖。没有这些答案，框架默认值只是未经验证的假设。

可以用下面的清单审查设计：

入口是否同时考虑总量、公平性和热点业务键？
每个稀缺依赖是否有独立且有界的并发许可与队列？
背压能否传回生产源，还是只把数据堆在中间层？
熔断统计是否排除了业务拒绝，并与实例摘除区分？
重试是否只有一层，受 deadline、幂等和预算约束？
降级结果是否真实，核心事实能否最终查询和收敛？
恢复时是否渐进放量，并限制 backlog 回放速度？
是否能从指标区分限流、隔离、熔断、超时和业务失败？

过载治理的目标不是让每个请求都成功，而是在容量不足和依赖故障时，明确选择哪些工作继续、哪些尽快停止，并确保已经接受的核心工作得到足够资源。只要请求、资源和业务结果的边界可见，局部故障就有机会停在局部。