多活与单元化架构
按用户或地域把流量与数据划分到多个单元（cell），每个单元独立读写、自成闭环，单元之间故障隔离，出问题时由调度层把流量迁到健康单元。它把『容灾切换』转化为『流量调度』：切换粒度更小、影响面更可控。代价是对数据分片、路由与全局数据同步的设计要求明显提高。
基本信息
| 划分维度 | 用户 ID 哈希、地域、租户 |
|---|---|
| 单元内 | 应用与数据自包含，单元内调用不跨城 |
| 跨单元 | 少量全局数据（配置、路由表）单独同步 |
| 切换单位 | 单元级或分片级，而非整站级 |
典型使用场景
- 大规模互联网业务：按用户分片，避免单集群容量与故障域过大
- 跨地域低延迟：用户就近访问所属单元，减少跨地域调用
- 灰度与隔离：新版本先在部分单元上线，观察后再全量
- 容量扩展：新增单元即扩容，比纵向扩单集群更平滑
- 故障演练：随机下线一个单元，验证流量调度与数据完整性
路由与切换示意
路由与切换示意
# 用户分片键 user_id -> 单元 A / B / C（路由表由调度层维护）
# 单元内闭环：A 的用户只访问 A 的应用与数据分片
# 单元 A 故障 -> 调度层把新会话路由到 B / C
# 存量会话：强制重新登录或按降级策略处理
# 全局数据：路由表、配置、白名单单独同步，变更需审核与灰度
# 观测要点：单元维度的成功率、时延与数据一致性指标，按单元分别看设计要点与风险
| 要点 | 说明 | 风险 |
|---|---|---|
| 分片键选择 | 决定数据落在哪个单元 | 选择不当会造成热点单元 |
| 单元自包含 | 单元内不依赖其他单元 | 跨单元强依赖会把局部故障放大 |
| 全局数据 | 配置与路由表 | 同步链路成为隐藏单点 |
| 数据迁移 | 用户跨单元迁移 | 迁移中的双写与一致性问题最难处理 |
单元化把切换粒度变小，但对调度与数据路由设计要求高：一旦路由表本身成为集中式单点，多活的收益会被抵消。