如何通过架构设计将故障限制在局部

「泰坦尼克号只有一个船舱，撞上就沉。现代邮轮有多个水密舱，一个舱进水不会淹没整艘船。」

一、爆炸半径的几何学

2017年，AWS S3 outage。

原因： 一个子系统的配置错误。

影响： 整个S3服务不可用，数千个依赖S3的网站瘫痪。

为什么一个小错误能造成大范围影响？

因为故障没有边界。

二、核心观点：故障隔离是架构的第一性原理

让我说一个架构设计的黄金法则：

设计系统时，首先考虑的不是「如何不失败」，而是「失败时如何不扩散」。

爆炸半径（Blast Radius）： 一个故障能影响多大范围。

好的架构： 爆炸半径最小化。

差的架构： 单点故障导致全局崩溃。

三、穿越周期：从单体到微服务到Cell架构

阶段1：单体应用

所有功能在一个进程里
↓
一个模块故障 → 整个应用崩溃

爆炸半径： 100%

阶段2：微服务

功能拆分为独立服务
↓
一个服务故障 → 其他服务继续运行

爆炸半径： 10-30%

阶段3：Cell架构（AWS模式）

每个Cell是独立部署单元
↓
一个Cell故障 → 流量切到其他Cell

爆炸半径： < 5%

四、反直觉洞察：隔离带来复杂性，但值得

直觉： 单体架构简单，微服务复杂。

现实：

  • 单体架构简单开发，复杂运维（故障影响大）
  • 微服务复杂开发，简单运维（故障影响小）

权衡： 你愿意在哪一步承担复杂性？

答案是： 在开发阶段承担复杂性，换取运维阶段的简单性。

五、实战：故障隔离的设计模式

模式1：舱壁隔离（Bulkhead）

像轮船的水密舱一样，把系统分成独立的部分。

用户服务 A ←→ 订单服务
用户服务 B ←→ 订单服务
用户服务 C ←→ 订单服务

一个用户服务故障，不影响其他用户

模式2：熔断器（Circuit Breaker）

当依赖服务故障时，自动「熔断」，阻止故障扩散。

服务A → 服务B（故障）
↓
熔断器打开
↓
服务A直接返回降级结果，不再调用B

模式3：限流（Rate Limiting）

限制每个用户的请求速率，防止过载。

用户请求 → 限流器 → 服务
         超出限额 → 拒绝

六、写在最后：设计你的故障边界

你无法预防所有故障，但你可以控制故障的范围。

最好的架构：

  • 假设任何组件都可能失败
  • 设计故障隔离边界
  • 确保单点故障不会摧毁一切

不是构建永不失败的系统，是构建失败时有边界的系统。

📚 参考链接与延伸阅读

故障隔离

微服务与架构

容灾设计

*Published on 2024-03-11 深度阅读时间：约 5 分钟*

SRE思维实验室系列 #10 —— 故障隔离与架构设计