基于单元的架构：为何我们总是试图降低风险和故障

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

水平扩展微服务可以解决容量问题。但它无法解决隔离性问题，而这种差异的重要性远超表面所见。

基于单元的架构（Cell-Based Architecture）是一种在社区中仍较少被讨论的模式，但亚马逊云科技（AWS）、斯拉克（Slack）等公司已经使用多年，以确保单一故障永远不会同时影响所有用户。

其理念很简单：与其扩展同一系统的多个实例，不如将整个技术栈复制到称为“单元（cells）”的独立单位中，其中每个单元服务于用户群的一个子集。

传统微服务的问题

当我们水平扩展微服务时，通常的做法如下：

这种设计看起来具有弹性。但在实践中，单个压力点会同时影响所有用户：

• 部署中存在错误？所有用户都会受到影响。
• 某个客户产生异常巨大的流量？会降低其他所有用户的体验，即所谓的“嘈杂邻居（noisy neighbor）”效应。
• 发生级联故障？故障将在整个系统中传播。

水平扩展解决了容量问题，但未解决隔离问题。

而这种差异的重要性远超表面所见。

什么是单元（Cell）

单元（cell）是一个自治单位，包含服务于部分用户所需的一切。应用程序、基础设施和数据库共同组成一个整体，与其他单元完全隔离。

每个单元在功能上与其他单元相同。区别在于，

每个单元服务于用户群的不同部分，并且不知道其他单元的存在。

四个关键特性

### 1. 故障爆炸半径控制

如果单元 2 发生故障，只有第 100 万到第 200 万之间的用户会受到影响。

其他用户继续正常运行。即使在事故发生之前，故障的影响范围也是可预测且有限的。

### 2. 嘈杂邻居隔离

每天发出数百万次请求的企业客户不会降低位于不同单元中的其他客户的体验。
每个客户都生活在自己的独立环境中。