核心立场：服务容错不是工具集合，而是分布式系统在”不可靠前提”下维持稳态运行的系统性治理能力。
结论：
在分布式系统中，错误不是异常事件，而是常态输入；容错设计的目标不是”避免错误”，而是在错误持续存在的情况下维持系统稳态。
容错（Fault Tolerance）：
系统在部分组件失效、性能退化或行为异常的情况下，仍能在可接受范围内持续提供核心功能的能力。
它直接服务于：
在大规模微服务系统中，**服务雪崩（Cascading Failure / Avalanche Failure）**并非单点故障，而是：
分布式系统中，由于一个服务的故障或性能退化导致资源耗尽，进而引发其他服务相继故障的级联放大效应。
服务雪崩的破坏力来自自强化反馈结构：
延迟上升 → 吞吐下降 → 队列积压 → 超时/重试增加 → 负载膨胀 → 延迟进一步上升（循环）
这是一个正反馈回路，而非线性故障。
延迟通道 故障通道
延迟上升 错误/异常率上升
↓ ↓
吞吐下降 重试增加
↓ ↓
队列积压 负载膨胀
↓ ↓
超时/重试 ←←←←←←←←←← 负载膨胀
↓
延迟进一步上升
可以将任意服务节点抽象为：
RPS ≤ 并发度 / 平均响应时间
结论：
在雪崩场景中，杀死系统的直接因素是资源耗尽，而延迟上升与故障增加是导致资源耗尽的主要途径
| 阶段 | 系统特征 | 风险状态 |
|---|---|---|
| 潜伏期 | 延迟上升但指标仍“健康” | 非稳态形成 |
| 隐患期 | 队列增长、并发被占满 | 临界态 |
| 爆发期 | 重试风暴触发 | 正反馈失控 |
| 崩溃期 | 吞吐骤降、请求堆积 | 系统失效 |
| 治理目标 | 本质作用 |
|---|---|
| 延缓非稳态进入 | 提高系统缓冲与弹性 |
| 削弱正反馈 | 控制放大回路 |
| 快速止损 | 防止局部问题扩散 |
关键思想：
治理雪崩的核心是消除正反馈环路。
| 策略 | 核心思想 |
|---|---|
| 启动预热 | 避免冷节点承压 |
| 延迟暴露 | 准备完成再接流量 |
| 冗余容量 | 提供缓冲空间 |
| 策略 | 作用点 |
|---|---|
| 重试预算 | 限制重试放大 |
| 全链路 TTL | 防止无效请求占用资源 |
| 自适应限流 | 控制入口负载 |
| 策略 | 本质 |
|---|---|
| Failfast | 快速释放资源 |
| 降级 | 保核心、弃边缘 |
| 熔断 | 切断异常依赖 |
本质：
将"是否继续等待"的决策，从无限制阻塞中抽离为可量化的时限控制。
解决的问题：
前提约束：
副作用：
反模式：不设置超时、认为超时能解决问题（超时只是发现机制）
本质：
将”是否继续调用不稳定依赖”的决策，从业务逻辑中抽离为独立的控制器。
解决的问题：
边界：
反模式：以为加了熔断器就高枕无忧
本质：
用资源边界阻断故障传播路径。
边界：
本质：对"瞬时故障"的乐观处理，通过时间换可靠性。
前提约束：
副作用：非幂等重试→脏数据；无预算重试→雪崩燃料
反模式：把重试当万能药
本质：
在系统能力受损时，主动放弃非核心功能，保证核心功能持续可用的策略。
解决的问题：
原则：
反模式：以为降级后用户体验不受影响，或降级可以代替容量规划
容错的核心是"在故障发生时维持系统稳态"，但稳态维持的前提是能感知到故障正在发生。没有可观测性，容错机制就是盲目的被动响应。
| 维度 | 说明 |
|---|---|
| 故障定位 | 不知道故障在哪里，容错策略无法精准干预 |
| 效果验证 | 不知道干预是否有效，无法形成闭环 |
| 动态调参 | 不知道系统当前状态，阈值无法自适应 |
| 指标层 | 示例 |
|---|---|
| 状态指标 | 延迟分位数、队列深度 |
| 趋势指标 | 延迟梯度、错误增长率 |
| 控制指标 | 熔断状态、限流阈值 |
观测（Metrics）
→ 判断（Decision）
→ 行动（Action）
→ 反馈（Feedback）
容错设计不是一劳永逸的，需要在设计阶段和复盘阶段进行评审验证。
资源有限时，容错投入需要优先级指导：
风险量化模型：
风险值 = 发生概率 × 影响严重度
分级：
| 等级 | 定义 | 容错策略 |
|---|---|---|
| 致命 | 必须阻断 | 优先投入容错资源，确保可恢复 |
| 严重 | 优先缓解 | 预设计降级/熔断预案 |
| 可接受 | 监控 | 保留可观测性即可 |
MCA 原则：
对每个关键场景定义：
各容错策略不是孤立存在的：
请求进入
→ 舱壁隔离检查（资源边界控制）
→ 熔断器状态判断（是否允许请求通过）
→ 超时计时（发现机制）
↓（失败）
→ 重试策略（幂等性检查 + 退避算法）
↓（重试耗尽或不可重试）
→ 熔断器状态更新（失败率累计）
↓（熔断触发）
→ 降级策略执行（保核心弃边缘）
容错是对反馈结构的设计，不是对故障的补救。理解"不该用"比"该用"更重要。
容错手段解决的是故障扩散和争取恢复时间，而非故障根源。
| 手段 | 实际作用 | 无法解决 |
|---|---|---|
| 超时 | 发现异常存在 | 异常原因 |
| 熔断 | 切断异常依赖 | 下游为何故障 |
| 隔离 | 阻断传播路径 | 依赖为何脆弱 |
| 重试 | 等待瞬时恢复 | 故障是否可逆 |
| 降级 | 维持核心可用 | 退化为何发生 |
结论：触发容错后若无修复动作，只是在拖延最终失效。
策略叠加可能产生非线性放大效应，而非能力线性叠加。
容错以资源消耗和功能降级为代价。当成本超过故障损失时，容错反成负担。
容错复杂度应与系统规模匹配。大规模系统用简单策略会治标不治本；小规模系统用复杂策略会引火烧身。
容错能力无法在故障时临时构建。降级预案必须提前设计，阈值必须提前标定。
容错策略有能力上限，无法应对超出设计容量的场景。
| 手段 | 容量约束 |
|---|---|
| 超时 | 等待线程/连接数有上限 |
| 熔断 | 半开状态放行的请求数有限 |
| 重试 | 重试预算耗尽后不再重试 |
| 降级 | 降级能力受备用资源限制 |
当实际负载超过设计容量时，容错策略无法阻止系统过载。
容错依赖对故障模式的预判和预定义配置。
断路器阈值、重试次数、退避参数等都需要事先设定。对于未知故障模式（新型攻击、未知错误码），容错机制可能失效或产生意外行为。
容错有效的前提是下游最终能够恢复。
熔断器假设服务会自行修复；重试假设故障是瞬时的。但若下游已永久性故障（数据库宕机、机房级故障），则所有容错策略只是在延迟失效并消耗更多资源。