系统设计面试题：如何用 Cell-Based Architecture 限制故障影响？
题干与适用场景
一个全球服务经常因单次错误发布、过载或共享依赖故障导致大范围中断。请设计 Cell-Based Architecture，把用户流量分配到相互独立的 cell，并说明路由、数据、容量、发布、跨 cell 操作和灾难恢复策略。
面试官考察点
- 是否把 cell 定义为可独立运行、扩展和回滚的完整副本。
- 是否能解释故障半径、路由映射和新用户分配的一致性。
- 是否能处理共享控制面、跨 cell 数据、容量倾斜和热点迁移。
- 是否能把渐进发布、指标门禁和恢复演练落到具体流程。
回答前需要澄清的问题
- 隔离键是用户、租户、地域还是业务分区？跨区访问是否允许？
- 哪些数据必须全局一致，哪些数据可以 cell 内最终一致？
- 目标是限制单次部署影响，还是应对区域级灾难？
- 负载是否可预测，热点租户能否迁移，迁移期间如何保证幂等？
30 秒回答框架
我会把每个 cell 做成包含计算、缓存和主要数据依赖的独立服务副本，用稳定的用户到 cell 映射把请求路由过去。全局控制面只保存映射、版本和容量摘要，数据面尽量不跨 cell 调用。新版本先在一个 cell 金丝雀，依据错误率、延迟和饱和度逐步扩展；故障时停止该 cell 的流量并回滚，其他 cell 保持服务。跨 cell 任务通过异步编排、幂等键和明确的降级策略完成。
分步骤深入解答
1. Cell 的边界
Cell 是可独立部署、扩展和恢复的系统单元，通常包含服务实例、缓存、队列和专属数据分片。共享的 DNS、身份或配置服务应尽量保持低权限、低耦合，并定义它们故障时的降级行为。
2. 路由与映射
路由层根据用户或租户键查找映射，把请求转发到目标 cell。映射需要版本、校验和过期策略；迁移时先写入新映射，再等待旧请求排空，避免同一实体同时写入两个 cell。
3. 数据隔离
每个 cell 拥有本地写入边界，跨 cell 查询优先使用异步复制的只读投影。全局唯一约束应放到专门的协调服务，或改成分区内唯一加最终合并，避免把所有写入重新集中到单点。
4. 容量与热点
为每个 cell 设置请求、队列、数据库连接和存储配额，控制单 cell 的最大爆炸半径。监控租户分布和资源水位，热点租户可迁移到空闲 cell，但迁移必须支持双读、单写和可重放事件。
5. 共享控制面风险
控制面负责映射、版本和编排，不应承载所有业务数据。控制面不可用时，路由器应使用带 TTL 的本地快照继续服务；快照过期后只允许安全的读流量或返回可重试错误。
6. 发布与回滚
先选一个 cell 运行新版本，比较基线 cell 的错误率、尾延迟、资源饱和度和业务指标。达到门槛后按批次扩散；任何 cell 出现回归就暂停扩散并回滚该版本，不把健康 cell 一起降级。
7. 跨 cell 操作
跨 cell 报表、批处理和账户迁移应通过任务编排器执行，使用幂等键、租约和进度检查点。任务失败时只重试未完成分片，并把部分完成状态显式暴露给调用方。
8. 灾难恢复与演练
为每个 cell 备份数据和配置，定义恢复点与恢复时间目标。定期演练单 cell 隔离、控制面失联、区域故障和映射损坏，验证流量转移、数据恢复和回滚脚本，而不只依赖理论上的冗余。
设计取舍与边界
- Cell 越小故障半径越低，但运维、容量碎片和跨 cell 协调成本越高。
- 强全局一致性会重新引入共享瓶颈；应按业务价值拆分一致性边界。
- 路由快照提高控制面故障时的可用性，却可能把请求送到已下线或容量不足的 cell，需要 TTL 和熔断。
- 多 cell 发布降低爆炸半径，不能替代兼容的数据迁移和可回滚 schema 设计。
落地计划与证据
- 画出 cell、路由层、控制面、数据面和共享依赖的边界图，标注每条跨 cell 调用。
- 用压测确定单 cell 的容量上限和热点迁移阈值，记录 P95、P99、错误率和队列深度。
- 实现映射版本、TTL、双读单写和事件幂等，并演练迁移中断恢复。
- 建立单 cell 金丝雀、指标门禁、自动暂停和回滚流水线。
- 对照 AWS Cell-Based Architecture 指南与 Well-Architected Reliability Pillar 复核故障隔离和恢复目标。
常见误区与追问
误区一：只复制计算实例就称为 cell
如果缓存、队列或数据库仍是全局共享，关键故障仍会跨 cell 扩散。必须列出每个依赖的隔离和降级方案。
误区二：用随机分流替代稳定映射
随机分流会让同一租户跨 cell 写入，破坏缓存和数据边界。需要可版本化、可迁移的确定性映射。
误区三：把控制面当成永不失败
控制面故障是常见爆炸源。应缓存映射、设置 TTL，并定义快照失效后的安全行为。
追问：如何选择 cell 数量？
从单 cell 容量、目标故障半径、部署批次和运维成本反推，保留至少一个可承接故障流量的余量，再用压测和演练校准。
追问：跨 cell 交易如何保证一致？
优先避免跨 cell 事务；必须协同时使用幂等事件、补偿动作和可见的部分完成状态，不把分布式锁当作万能方案。