什么是故障隔离单元？如何划分？
简化版
故障隔离单元是资源、流量和状态相对独立的一组组件，单元故障时影响被限制在该边界内。划分应依据可接受爆炸半径、业务优先级、租户/地域和共享依赖，配合独立容量、限流、发布与故障转移；只把应用多部署几份但仍共享同一数据库或连接池，不算真正隔离。
详细版
常见隔离层级包括线程池/连接池、实例组、分片、可用区、地域以及 cell。选择粒度时先定义“最多允许一次故障影响多少用户或交易”，再决定按租户、用户哈希、业务类型或地域把流量和数据映射到哪个单元。
一个有效隔离单元需要控制四类共享：计算资源、数据存储、依赖配额和控制面变更。若多个 cell 仍共用容量无上限的数据库、MQ 或配置发布通道，底层故障和错误配置仍会全局传播。隔离也有代价：资源冗余增加，热点单元可能闲忙不均，跨单元查询和迁移更复杂。
工程上应维护稳定路由和单元归属，避免一次请求跨越过多单元；为每个单元单独观测 SLI、容量与版本；通过故障演练验证摘除一个单元后其他单元不受影响。故障转移前还要确认目标单元有容量并解决数据所有权，不能把隔离变成过载转移。
完整版教学
一、隔离单元解决什么问题
冗余只能降低单个组件故障概率，不能限制故障影响范围。一个错误 SQL 把共享数据库打满时，连接它的所有应用副本都会失败；一个错误配置全量下发，也可能让全部冗余同时失效。隔离单元关注的是 blast radius，即一次故障最多伤到多少业务。
如果平台有 1000 万用户，拆成 10 个独立 cell，每个承载约 10%，理想情况下单 cell 故障影响约 100 万用户而非全站。这个上限是否可接受，要由业务 SLO 和成本共同决定。
记忆钩子：高可用问“还有没有副本”，故障隔离问“坏了会不会一起坏”。
二、从进程内到地域的隔离层级
隔离可逐层建立。进程内用独立线程池防止慢依赖占满全部工作线程；服务层用实例组和配额隔离在线与批处理；数据层用分片或独立库；基础设施层用可用区和地域抵抗机房故障。
| 层级 | 隔离对象 | 典型手段 | 无法单独解决 |
|---|---|---|---|
| 线程/连接池 | 慢调用、资源等待 | bulkhead、并发上限 | 进程或机器故障 |
| 实例组 | 业务优先级、租户 | 独立部署与限流 | 共享数据库过载 |
| 数据分片/cell | 数据与流量 | 稳定路由、独立存储 | 区域级灾难 |
| 可用区 | 电力、网络故障 | 多 AZ 部署 | 地域级故障 |
| 地域 | 大范围灾难 | 多活/灾备 | 全局控制面错误 |
层级越大成本越高，通常组合多层而不是只选一种。
三、如何选择划分键
划分键要让同一业务事务尽量留在一个单元。SaaS 常按 tenantId，消费者业务可按 userId 哈希，强地域属性业务按 region。若订单和用户被不同规则随机分配，一次请求频繁跨 cell，隔离效果会被跨单元依赖削弱。
稳定性也重要。cell = hash(userId) % 10 在扩到 11 个 cell 时会移动大量用户，可使用显式映射表、号段或一致性哈希控制迁移。大租户可能超过单 cell 容量，需要独立单元或进一步分片，而不能只靠平均值。
route(tenantId) -> cellId
cellId -> {gateway pool, service pool, database shard, MQ namespace}
请求携带 cellId，默认禁止跨 cell 写四、共享依赖会怎样击穿隔离
两个 cell 各自有应用实例，但共享一个无配额数据库账号时，cell A 的慢查询能耗尽全部连接，cell B 仍会受害。类似的共享点还有 DNS、配置中心、认证服务、消息集群、对象存储和发布控制面。
不是所有依赖都必须物理复制，但必须有逻辑限额和退路。例如共享 MQ 集群可按 cell 设置 topic、生产配额和消费线程；共享数据库可使用独立连接池、账号和资源组。对于无法隔离的全局依赖，应明确它是系统故障域上限，并优先治理。
检查架构时可画“共同命运图”：任何一个节点故障能同时切断哪些 cell。图上连接全部单元的单点，就是隔离设计的薄弱处。
五、容量与故障转移怎么算
隔离会降低资源共享效率。4 个 cell 每个峰值需要 100 核，若各留 30% 余量，总配置约 520 核；完全共享池可能用更少资源，但爆炸半径更大。成本是隔离换取风险上限的代价。
故障转移还需预留接管容量。若 3 个 cell 各承载 1000 QPS，其中一个故障并均摊到另外两个，每个会从 1000 增至 1500 QPS，即需要 50% 余量。若没有余量，自动切流只是把单元故障变成全局过载。
N+1 容量近似：每个存活单元容量 >= 总峰值 / (单元数 - 1)
3 单元、总峰值 3000 QPS -> 每个至少准备 1500 QPS也可以不全量接管，而是只接关键请求并降级非核心功能，以降低冗余成本。
六、发布和控制面也要分批隔离
运行时隔离做得再好，全量发布同一个坏版本仍会同时摧毁所有单元。发布顺序应以单元为灰度批次，先选择低风险 cell，观察业务指标后再扩大；配置、证书和路由规则同样需要分批生效。
控制面故障不应立刻让数据面停止。配置中心不可用时，服务可在安全期限内使用最后一次有效配置；路由控制面故障时，网关保留已验证的路由快照。缓存必须带版本和签名，不能把任意旧配置当作安全回退。
每个单元要能独立展示版本、配置和数据滞后，避免“全局看起来正常”掩盖局部故障。
七、如何用演练验证边界
隔离是否有效只能靠故障注入证明。可让一个 cell 的数据库延迟增加到 2 秒、耗尽其连接池或发布错误配置，检查其他 cell 的成功率和 P99 是否保持稳定。若全局线程池、重试或日志管道被拖垮，说明仍有隐藏共享。
指标既要看故障单元，也要看健康单元的连带影响。建议记录单元流量、拒绝率、资源水位、跨单元调用数、迁移数量和故障转移后的容量余量。
failed_cell: c3
affected_traffic_share: 9.8%
healthy_cell_error_rate_delta: 0.02%
cross_cell_writes: 0
failover_headroom: 34%八、常见误区与追问
- 误区：多副本部署就是完成了故障隔离。 副本若共享同一故障依赖或错误配置，仍会一起失败。
- 误区：隔离越细越好。 单元越细资源碎片、运维和跨单元协作成本越高，应由可接受爆炸半径反推。
- 误区：自动故障转移一定提高可用性。 目标单元没有容量时，切流会造成级联过载。
- 误区：只隔离数据面即可。 全量配置、发布、证书和路由错误会绕过数据面边界，需要控制面灰度。
- 追问：大租户如何处理？ 为其分配独立 cell、再按子资源分片，或设置专属容量，避免压垮普通租户单元。
- 追问：全局唯一数据怎么办？ 缩小全局写路径，使用专门的强一致服务，并让普通请求缓存或异步消费结果。
- 追问：怎样发现隐藏共享依赖？ 做依赖图和共同命运分析，再通过单 cell 压测、断网和配置故障验证。
九、加强记忆
用“定爆炸半径、选划分键、查共享点、算接管容量”设计故障隔离。单元内部可以共享命运，单元之间要在计算、数据、依赖配额和变更上尽量解耦；故障转移还必须有容量和数据前提。最终通过破坏一个单元、观察其他单元是否稳定，证明边界真的存在。