第一章 方案背景与目标
1.1 故障场景：从单点损坏到级联雪崩
在分布式系统与微服务架构中，一个模块的局部损坏如果缺乏防护手段，往往会迅速引发上下游依赖的连锁超时、资源耗尽，最终演化为整个服务的不可用。本章所定义的“模块损坏”并非指代码逻辑错误（Bug），而是指以下三类典型故障：
| 故障类型 | 典型表现 | 示例场景 |
|---|---|---|
| 资源耗尽 | 内存泄漏、连接池占满、磁盘 I/O 打满 | 缓存模块因 key 膨胀导致 GC 激增，响应从 5ms 退化到 30s |
| 状态损坏 | 本地数据文件损坏、持久化索引不一致 | 搜索引擎的分片索引文件因断电产生 CRC 校验失败 |
| 依赖中断 | 下游基础库/中间件版本冲突、动态链接缺失 | 升级 OpenSSL 后现有加密模块无法加载符号表 |
关键观察： 这三种场景的共同特征是——模块本身未完全宕机，但已无法对外输出正确或及时的结果。如果继续向该模块转发流量，轻则局部超时，重则引发整条调用链的“级联雪崩”。
1.2 降级与回滚的定义
本方案将“降级”和“回滚”定义为两个独立的防御阶段，而非混用术语：
- 降级（Degradation） —— 检测到模块损坏后，立即切断对该模块的调用，并将其职能切换至预先准备好的替代路径（静态缓存、默认值、旁路逻辑）。目标是止损，让系统以弱化但仍可用的方式继续服务。
- 回滚（Rollback） —— 在降级生效的基础上，将损坏模块的代码、配置或数据恢复到上一个已知正确的版本。目标是修复，恢复模块的原始能力。
区分要点： 降级是“路由切换”，不修改模块本身；回滚是“状态恢复”，涉及模块内容的变更。二者必须串行执行——先降级止损，再回滚修复。
1.3 方案核心目标
本方案围绕三个可量化的目标展开设计：
- RTO（恢复时间目标）≤ 30s —— 从模块损坏被识别到降级策略生效，必须在 30 秒内完成呼叫切断与替代路径切换。
- 回滚成功率 ≥ 99.5% —— 对于已损坏模块的版本回退操作，必须通过完整性校验和灰度验证，确保回滚后功能正常。
- 影响面 ≤ 1% 请求 —— 降级期间，仅影响依赖损坏模块的请求分支，其他功能链路不受干扰。
权衡提示： RTO 越短，对检测灵敏度和配置分发速度的要求就越高，可能引入更多“误降级”风险。方案需要在灵敏度和误报率之间找到平衡点，后续章节会专门讨论熔断阈值与健康检查窗口的关系。
1.4 适用范围与边界
本方案适用于有状态或无状态的应用层模块，包括但不限于微服务、网关中间件、数据处理管道。以下情况不在本方案覆盖范围内：
- 基础设施层故障（物理机宕机、网络分区）—— 应由集群调度和负载均衡处理。
- 业务逻辑层面的策略错误（如优惠券计算规则有误）—— 需要业务回滚而非模块回滚。
- 完全非预期的未知损坏（无预定义降级路径）—— 属于灾难恢复范畴。
下图为本章核心概念的脉络总览：从故障发生到降级/回滚的宏观流程，以及方案目标的覆盖范围。
1.5 章节要点总结
- 本方案针对的是“模块未宕机但已损坏”的场景，这类故障最容易引发级联雪崩。
- 降级与回滚是两个独立阶段：降级是路由切换，回滚是状态恢复。
- 三个核心目标（RTO、成功率、影响面）将作为后续所有设计决策的度量标准。
- 方案边界明确：聚焦应用层模块，不覆盖基础设施和纯业务逻辑错误。