高可用设计如何控制故障爆炸半径？
简化版
控制故障半径的核心是把流量、资源、数据、发布和权限切成独立单元，并限制跨单元依赖；一个单元出故障时，只丢失可预估的一部分能力。 常用手段包括故障域部署、舱壁与配额、分片/单元化、分批发布、租户隔离和逐级降级，同时用演练验证边界真的有效。
详细版
先画出共享资源与传播路径：线程池、连接池、数据库、缓存、消息 Topic、配置中心和运维权限都可能把局部故障放大。对核心业务按地域、租户或哈希单元切分，每单元拥有独立容量与数据主权；全局组件只保留最小控制职责，并准备降级路径。
例如 100 个租户分 10 个 cell，每个 cell 承载约 10%，单库故障理论最多影响 10%，而不是全站。代价是资源碎片、跨 cell 查询和运维复杂度。必须设置每层限额、重试预算、发布批次和自动停止条件，并监控故障是否跨边界蔓延。
完整版教学
一、爆炸半径从共享开始
所有请求共用一个连接池、所有租户共用一张热表、所有区域依赖同一配置中心时，一个局部异常就可能影响全站。控制半径不是单纯增加副本，而是减少不必要共享，并在必须共享处设置准入上限和失败隔离。
记忆钩子：先找“大家都依赖谁”，再问“它坏了会带走多少人”。
二、四类隔离边界
| 边界 | 手段 | 防止的传播 |
|---|---|---|
| 计算 | 线程池、容器配额、舱壁 | 慢请求耗尽实例 |
| 数据 | 分库分片、cell 数据归属 | 热点/锁扩散 |
| 故障域 | 主机、机架、AZ、地域 | 基础设施共同故障 |
| 变更 | 灰度、批次、权限分级 | 错误发布全量生效 |
这些边界要叠加。跨 AZ 部署应用但共用单库，仍然存在数据层全局半径。
三、Cell 架构如何量化影响
假设 100 万用户按稳定哈希分到 20 个 cell，每个约 5%。每个 cell 有独立应用、缓存和数据分片，单 cell 故障理论影响约 5%。路由层只维护 user -> cell，不能在故障时把流量随意导向没有该用户数据的 cell。
Global Router
├─ Cell 01: app/cache/db (5%)
├─ Cell 02: app/cache/db (5%)
└─ ...四、资源配额阻断噪声邻居
租户 A 突发 5000 QPS 时，如果共享队列无配额，会挤占租户 B。按租户、接口和优先级设置 QPS、并发、队列与连接预算，让 A 的超额请求在入口被拒绝。配额之和还需受全局容量约束，否则每个局部都“合法”仍会总体过载。
重试同样要隔离。局部 20% 失败若所有上游重试两次，会向共享依赖增加 40% 流量，突破原有边界。
五、变更是最常见的全局故障源
代码、配置、Schema 和权限变更都要分批。先单实例、单 cell 或内部租户，观察成功率、P99 和业务指标，再逐级扩大。全局紧急开关也要有作用域、TTL 与双人审批，避免止血动作本身影响所有区域。
数据库变更使用 expand/contract，防止新旧版本共存时互不兼容。回滚还要考虑已写入的新数据状态，不能只切镜像版本。
六、验证边界是否真实
混沌演练可让一个 cell 数据库超时，预期其他 cell 的 P99 和错误率保持基线。如果全局线程池、消息 Topic 或监控查询被拖慢，说明存在隐藏共享。故障半径指标可记录受影响用户/租户比例、跨 cell 错误与共享依赖饱和度。
隔离有成本：20 个 cell 会产生资源碎片和更多发布单元。应根据最大可接受影响比例选择粒度，不是切得越碎越好。
七、常见误区与追问
- 误区：多可用区部署就控制了所有故障半径。 数据、配置和发布仍可能全局共享。
- 误区：隔离单元越多越可靠。 过细会增加碎片、路由和运维故障。
- 误区：故障时可以把 cell 流量导到任意健康 cell。 数据归属不匹配会导致旧读或写错位置。
- 误区：只隔离计算资源即可。 数据库连接、消息和权限同样会传播故障。
- 追问：如何选择 cell 粒度？ 从允许影响用户比例、成本和跨单元需求共同推导。
- 追问：全局组件怎么办？ 最小化职责、多副本，并让数据面能用最后快照独立运行。
- 追问：如何证明没有隐藏共享？ 故障注入一个单元，观察其他单元及全局依赖是否被拖累。
八、加强记忆
故障半径按“共享识别—边界切分—配额阻断—变更分批—演练验证”控制。计算、数据、故障域和变更四层都要有边界；用受影响比例量化收益，同时承认资源碎片与复杂度。高可用不是让故障消失，而是让它只能伤到预先允许的范围。
复盘时还要区分“实际影响范围”和“最坏可扩散范围”：前者描述本次事故，后者才检验隔离设计是否真的存在硬边界。