本文目录
保护措施应保住可及时完成的业务，而不是把所有请求留在系统里等待
限流控制进入系统的流量，熔断在依赖持续异常时减少无效调用，降级则按预定规则提供部分可用的业务结果；三者不能相互替代。规则应对应资源与业务优先级，注明拒绝、等待、旧值或关闭功能的用户含义，并限制重试。过载时分别观察已接收业务的有效完成量与被拒绝流量，避免快速失败把整体延迟“改善”。恢复阶段需要有限探测、逐步放量和数据核对，保护参数应通过项目负载与故障演练确定。
按故障原因选择保护方式
| 保护方式 | 主要适用条件 | 设计缺口 |
|---|---|---|
| 入口限流 | 流量超过某接口、租户或活动可持续预算 | 只按全站平均流量限制，热接口或单个大租户仍拖垮共享资源 |
| 并发隔离 | 某依赖或低优先级任务占用共同工作槽位 | 限 QPS 但处理变慢后仍形成大量在途请求 |
| 依赖熔断 | 某外部调用持续失败，继续调用难以完成有效业务 | 把业务拒绝误计为故障，或恢复时同时放开全部实例 |
| 业务降级 | 业务接受较旧展示、简化计算或延后非关键动作 | 返回看似成功的虚假结果，资金和权限判断被绕过 |
适用边界：先定义必须保住的业务
这份指南适用于 API、微服务依赖与有活动高峰的业务后台。保护策略要由业务与技术共同决定：交易提交、查询结果和推荐展示可以有不同优先级，但资金、权限与数据约束不能因降级而被跳过。
先列出故障时仍需要完成的最小路径，以及可以关闭、延后或返回旧值的功能。降级会改变用户得到的结果，产品应明确展示状态和补偿路径。对于必须实时且完整的操作，明确拒绝往往比假装成功更可解释；拒绝不能让请求落入未知状态。
保护规则还要说明对哪些客户生效。共享系统中的大租户、匿名请求和内部批量任务可以有不同预算，但需防止绕过身份或切换路由突破限制。紧急人工开关应设定负责人和有效期，恢复后复核临时配置，避免事故期间的例外长期留在系统里。
- 确定核心路径、可降级功能、数据新鲜度与依赖关系。
- 为每个规则指定配置所有者、使用场景和解除条件。
限流规则同时考虑速率、突发与在途请求
单一 QPS 限制不能应对处理时间突然变长。接口还需要受控并发、有限队列和等待预算；入口拒绝应发生在昂贵查询与外部调用之前，避免已经耗费大部分资源才发现超限。
令牌类限流允许一定突发，平滑类限流可能增加等待，两者适合的业务不同。多实例本地计数只约束单实例，扩容后总配额可能增加；全局协调又会引入新的依赖。应明确按账号、租户、路由或活动分配预算，并防止一个低价值请求类别占满共享容量。
- 记录规则维度、实际总配额、突发额度以及排队长度。
- 测试请求成本差异和多实例场景，不能仅验证单机计数。
熔断保护依赖，不把所有失败混作异常
依赖持续超时或错误时，熔断减少无效调用，让核心工作槽位不被占满。触发口径需区分业务拒绝、调用超时、网络失败和服务异常，并结合窗口与最小样本量，避免少量失败导致频繁切换。
同一依赖可能同时服务多个操作，如果只有某个资源异常，过大的熔断范围会扩大影响。熔断之后如何回应用户、是否允许备用依赖、能否返回旧值应分别设计。恢复时开放少量探测而非瞬时全量，防止刚恢复的依赖再被流量与积压击倒。
- 给依赖分配独立连接、并发与超时预算，标明保护范围。
- 保留触发原因、拒绝数量、探测结果和状态切换记录。
降级结果必须符合真实业务语义
可降级动作包括暂时关闭推荐、延后非关键通知、简化统计与返回允许范围内的旧内容。降级不能无条件吞掉错误，也不能把未完成写入解释为已完成，更不能改变库存、余额或访问权限的约束。
按业务动作写降级矩阵：正常依赖、依赖超时、保护触发和恢复阶段分别返回什么。备用来源可能陈旧或只能覆盖部分用户，应写明其范围。订单若已创建而通知延后，显示真实订单；订单尚未创建，则显示受理或失败，避免用户连续重试造成重复结果。
- 把降级状态、数据时间与后续动作写入接口契约。
- 为无法自动恢复的记录提供查询、补偿或人工接手入口。
实施步骤：先测保护前后的有效完成量
先测无保护下的负载拐点与依赖故障，再上线单条保护规则，验证核心业务与低优先级流量的变化，随后增加故障隔离、降级和有限恢复探测，最后检查它们与自动扩容、重试的交互。
AWS 的过载保护资料区分总吞吐和能够及时完成的有效吞吐。验收应分别统计成功、业务拒绝、限流、熔断和系统失败，不能让大量快速拒绝降低平均延迟后宣称性能提升。限流也可能压低 CPU 信号，扩容应结合需求和被拒绝量评估，避免保护机制隐藏真实缺口。
- 参数先以可回退配置灰度，不直接照搬其他系统阈值。
- 限制重试层级、次数和总时间，明确哪些业务错误不可重试。
验收：超过容量、依赖故障与恢复都要测
在超过可持续容量的阶段，已接收业务应保持约定的完成质量，超额流量得到可理解的拒绝，资源不应持续堆积。依赖恢复后逐步放量，同时验证等待任务与真实数据状态。
用受控慢依赖、持续错误、短暂抖动和进程重启分别验收，检查误触发和不同实例的状态。恢复测试需包含积压、客户端重试与多实例探测叠加。保护规则长期触发说明容量或依赖存在问题，不能把长期拒绝视作系统已经解决性能风险。
接口契约应让客户端识别是业务终态还是可稍后再试，并给出受约束的重试方式。移动端、浏览器与网关的已有重试也要检查，避免服务拒绝后客户端立即重复提交。保护触发的比例和持续时间应进入容量评估，作为是否扩容或调整业务范围的依据。
- 检查核心业务成功率、分位延迟、拒绝原因和占用资源。
- 记录恢复耗时、探测量、补偿结果与规则关闭后的容量。
需求讨论中的问题
限流和熔断有什么区别？
限流主要约束进入系统的流量；熔断主要在依赖异常时减少无效调用。即使流量不大也可能需要熔断，依赖正常也可能因流量超预算需要限流。
加了限流后平均响应时间下降，是优化成功吗？
需分别观察被接收并成功完成的业务延迟和拒绝量。大量快速失败会降低整体平均耗时，但用户完成率可能变差，应以有效业务结果验收。
依赖恢复后能马上关闭熔断吗？
应先有限探测，再逐步放量，并控制多实例同时恢复与积压重放。刚恢复的依赖可能只有部分能力，全量瞬时放开容易再次过载。
过载保护上线验收清单
可逐项勾选，辅助本次阅读；刷新页面后不保留。
参考资料
技术概念可进一步阅读以下资料；文中的业务场景与实施清单用于方案讨论。
- AWS：Using load shedding to avoid overload
核验有效吞吐、快速拒绝对延迟统计的影响，以及过载保护与自动扩容的交互。
- AWS Prescriptive Guidance：Circuit breaker pattern
核验依赖异常时的熔断用途与恢复检查；规则范围与阈值需按项目验证。
需要评估现有系统的性能瓶颈？
提供关键业务路径、真实峰值、服务器与数据库配置，以及现有压测或故障记录，月弦科技可据此梳理优化顺序、实施范围和可验证的验收条件。