🦾 AWS 如何秘密打破软件物理定律（你也可以做到）

“每一种架构都涉及相互竞争目标之间的根本性权衡，许多组织却忽视了这一点，从而导致系统不可靠。然而，AWS 明确拥抱这些悖论，其典型代表便是“单元（Cells）”架构，该架构支撑着 S3 和 DynamoDB 等超大规模服务。核心挑战在于如何在海量规模与故障隔离之间取得平衡：一旦单个大型集群发生故障，将影响整个系统。单元架构通过将服务划分为小型、自给自足且相互隔离的集群（即“单元”）来解决这一问题。每个单元都拥有独立的计算、存储和网络资源，确保某一单元发生故障时不会波及其他单元。一个智能请求路由器负责将入站流量引导至合适的单元，并在某单元不健康时自动进行重定向。以 Amazon S3 为例，它利用数百个单元来管理其庞大的对象存储，并在每个单元内部保持强一致性。这种设计通过增加单元数量实现近乎无限的扩展能力，同时将任何单一故障的影响范围（即“爆炸半径”）限制在最小限度。然而，跨单元操作被有意设计为缓慢甚至不可行，这是为隔离性而做出的 deliberate 妥协。DynamoDB 同样采用基于单元的方法，并配备独立的存储单元和路由器单元以实现高可用性。关键启示包括：拥抱简单且相互隔离的单元；显式地设计以限制故障传播；并接受弱全局一致性。开发者和架构师应致力于设计可分区的系统，避免单点故障，同时强大的自动化能力对于管理众多单元至关重要。“单元架构”作为一种在各大科技公司中广泛存在的模式，证明了在分布式系统中，隔离是控制故障的关键。