1968年5月16日清晨5点45分，伦敦坎宁镇。大多数居民还在睡梦中，一栋名为罗南角（Ronan Point）的22层塔楼突然发生局部坍塌，整栋楼的一个角落几乎被炸穿。这场事故只造成4人死亡——之所以伤亡如此之小，纯粹是因为事发时间太早，大多数住户还没起床，那些坍塌的房间大多是客厅。

引发这场灾难的，不是什么惊天动地的原因。住户艾维·霍奇（Ivy Hodge）太太早起烧水泡茶，煤气灶连接处一颗有问题的螺母导致煤气泄漏，引发了一场小规模爆炸。爆炸本身并不致命——霍奇太太被气浪掀翻在地，撞晕过去，醒来时发现自己躺在被炸翻的锅洒出的水洼里。真正致命的，是这场小爆炸引发的连锁反应。

打开网易新闻 查看精彩图片

一颗螺母引发的整楼坍塌

罗南角是二战后英国快速建造的大量高层住宅之一。当时伦敦大片区域还在战后废墟中，人口激增，住房需求迫切，这类预制装配式建筑被大量快速搭建。这种建造方式速度快、成本低，但存在一个致命弱点：结构缺乏冗余。

爆炸摧毁了某一层的一小部分承重结构，但问题没有止步于此。由于楼体缺乏替代荷载路径，上层楼板失去支撑后逐层砸落，形成多米诺骨牌效应——这就是土木工程中所谓的“渐进式坍塌”（progressive collapse）。一场本应只影响一户人家的小爆炸，最终让整栋楼的一个角彻底消失。

从建筑到软件：同样的坍塌逻辑

这个概念对做分布式系统的人并不陌生。渐进式坍塌的核心特征是：局部小故障通过系统内部的耦合关系被逐级放大，最终演变成整体性灾难。这与我们熟悉的级联故障（cascading failure）在逻辑上高度一致。

一个服务实例过载，导致依赖它的上游服务超时重试，重试又加剧了过载，进而拖垮更多依赖方——这种场景在微服务架构中屡见不鲜。就像罗南角大楼一样，问题不在于最初那个故障有多大，而在于系统有没有设计“冗余路径”来阻止故障蔓延。

建筑业的教训，分布式系统的启示

罗南角事故后，英国建筑规范进行了重大修订，要求高层建筑必须提供替代荷载路径，确保局部损坏不会导致整体坍塌。这个思路直接映射到软件系统设计：

  • 冗余与降级：关键依赖要有备用方案，单点故障不能拖垮全局
  • 隔离与舱壁：故障范围要可控，不能让一个模块的问题波及整个系统
  • 限流与熔断：防止故障引发的重试风暴进一步放大压力

萨姆·纽曼（Sam Newman）在研究中发现，土木工程领域对渐进式坍塌的防范思路，与韧性工程（resilience engineering）的核心理念高度契合。他在演讲中提到，罗南角的故事只是开始，后续还有更多系统故障案例——其中一起他亲身参与，另一起可能影响过不少听众。

一颗螺母、一次小爆炸、一栋楼的坍塌。这个1968年的建筑事故，对今天构建复杂分布式系统的工程师来说，依然是一堂值得反复咀嚼的课：真正决定系统生死的，往往不是最初那个故障，而是故障之后发生了什么。