故障隔离限制失效跨边界传播

分布式系统共享线程、连接、数据库和依赖时，一个局部故障可能耗尽公共资源，使原本健康的功能一起失败。故障隔离通过划分资源池、故障域和调用边界，限制失效传播范围。熔断器、舱壁和降级都是实现手段，前提是系统知道哪些能力必须相互独立。

故障域决定一次事故能影响多大范围

故障域可以是进程、实例、可用区、租户、队列或数据分区。将副本部署到不同故障域，可以降低单点失效；若它们仍共享同一数据库、配置或凭据，表面分散并没有消除共同原因。

设计要列出共享资源和控制面。多个服务使用独立实例却共享连接池上限，一个批任务仍可能占满数据库；多个区域依赖同一发布系统，错误配置仍可同时传播。

隔离越细，成本和运维复杂度越高。故障域应依据风险和恢复目标选择，不是把每个功能都拆成独立系统。

舱壁分开有限资源

舱壁模式为不同工作分配独立线程、连接、队列或并发预算。低优先级批处理耗尽自己的池时，不会直接占用交互请求的全部容量。

固定分区能提供保障，但空闲池可能浪费。允许借用剩余容量可提高利用率，同时需要在压力到来时可收回，避免借用变成永久共享。

资源隔离要覆盖完整路径。入口分开线程池，但下游仍使用一个无上限连接池，故障仍会在下游汇合。监控应按池显示饱和、排队和拒绝。

熔断器阻止持续调用失败依赖

当依赖失败率或超时超过阈值，熔断器进入打开状态，快速拒绝后续调用，避免每个请求都等待同一失败。经过冷却后，半开状态允许少量探测，成功后逐步恢复，失败则重新打开。

熔断器不会修复依赖。它只是减少无效工作并给依赖恢复空间。打开期间必须定义调用方行为：返回明确错误、使用缓存、执行降级还是排队异步处理。

阈值需要足够样本和时间窗口。低流量接口一次失败不应立即永久熔断，高流量接口也不能等累计大量失败才反应。不同错误类型可能需要不同统计。

超时与重试必须服从隔离边界

没有超时的调用会长期占用隔离池，最终仍使池耗尽。超时应来自端到端期限并逐层递减，让下游有时间完成或尽早取消。

熔断打开后立即重试其他实例可能有用，但共同依赖故障时会转移压力。重试预算、退避和抖动应与熔断状态共享信号，避免每层独立放大请求。

取消要传播到真正执行工作的组件。调用方超时后下游继续查询，表面释放线程却没有释放数据库资源。

降级保留关键用户能力

隔离让系统能够只关闭受影响功能。推荐服务失败时仍可返回核心内容，实时统计不可用时可显示明确的较旧快照。降级输出必须标明时效和缺失，不能伪装成完整结果。

降级路径需要平时测试。仅在事故中首次启用的缓存或备用接口可能已经失效。数据格式、权限和容量都要纳入演练。

有些操作不能安全降级，例如资金确认和权限变更。此时快速失败比返回不确定成功更可靠，并要保留可重试标识和审计记录。

多租户隔离避免邻居噪声

共享平台中，一个租户的流量、复杂查询或大对象可能影响其他租户。按租户限额、并发池和存储配额可以限制影响，并为关键租户保留基础能力。

完全独立部署提供更强隔离，但成本更高。分层隔离可以让普通负载共享资源，高风险或高保障租户使用独立池。选择应写入服务承诺和容量模型。

隔离还要防止数据越界。资源池分开不代表授权边界正确，租户标识必须贯穿缓存键、队列消息和数据库查询。

隔离效果需要故障注入验证

正常流量下各池都健康，不能证明隔离有效。测试应让一个依赖变慢、一个租户突发或一个队列积压，观察其他关键路径是否保持目标。

指标要显示故障域、熔断状态、拒绝、降级和恢复，而不只看全站平均。局部失败会被健康大流量稀释，导致隔离已经失守却没有告警。

恢复也可能引发冲击。依赖恢复时，大量半开探测、积压和缓存失效同时到达，可能再次压垮系统。应渐进恢复并限制重放速率。

故障隔离的目的不是消灭故障，而是让故障停在可理解和可恢复的边界内。只有资源、调用、数据和运营控制共同隔离，局部问题才不会成为全局事故。

隔离边界还应与责任边界一致。某个池、分区或队列出现问题时，值班人员需要能从指标定位其所有者、容量和依赖，并执行局部止损。技术上分了区却共享不可区分的告警和操作入口，会在事故处理中重新形成全局耦合。

隔离设计因此也要配套可操作的运行手册。

资料依据

• Google：Site Reliability Engineering Books，https://sre.google/books/
• Carnegie Mellon Software Engineering Institute：Early Analysis of Software Architecture，https://www.sei.cmu.edu/library/early-analysis-of-software-architecture/