跨机房单元化部署与数据分片架构

一、项目概述

1.1 背景与行业痛点

随着业务规模的持续增长，单机房部署模式的脆弱性日益凸显。2022年某头部互联网公司因光缆被挖断导致全站故障持续 8 小时，直接损失估算超过 1.2 亿元，品牌口碑损失更是难以估量。这类事件为整个行业敲响了警钟：单机房故障不再是小概率事件，而是每个快速增长的企业都必须正视的现实威胁。

常见的单机房故障场景包括：电力系统失效（UPS电池耗尽、发电机故障）、网络基础设施故障（光缆断裂、DDoS攻击导致 BGP 瘫痪）、自然灾害（火灾、洪水、地震）、以及人为事故（误操作、配置错误）。任何一种场景都可能将业务置于 RTO（Recovery Time Objective）= 数小时 的险境。

与此同时，监管合规对数据本地化提出了更高要求。《数据安全法》和《个人信息保护法》实施后，部分业务数据必须存储在特定地域的数据中心，跨地域部署不再是可选项，而是必选项。这进一步推动了跨机房多活架构的落地进程。

1.2 核心矛盾与技术挑战

• 跨机房数据同步延迟：同城机房间延迟约 <5ms，异地机房间延迟可达 30-50ms，同步方案设计必须充分考虑延迟对业务的影响
• 网络分区（Network Partition）：两个机房之间的网络中断，如何保证数据一致性和业务连续性？CAP 定理中 C 和 A 的取舍是核心决策
• 流量调度的公平性：如何确保用户请求在多机房之间公平分配，且在故障时能够快速切换？DNS 缓存、Anycast 路由都是需要深度考虑的因素
• 一致性保障：单元化架构中，相同用户的所有请求必须路由到同一单元，同时又不能牺牲跨单元的数据可见性
• 运维复杂度激增：四机房部署意味着配置管理、监控告警、故障定位的复杂度呈指数级上升，需要强大的自动化运维能力

1.3 架构演进路径

1.4 量化业务目标

二、技术架构设计

2.1 四层架构总体设计

系统采用四层架构：流量接入层 → 流量调度层 → 业务逻辑层 → 数据存储层。整体设计遵循"单元封闭"原则，即一个用户的所有请求在同一单元内闭环处理，单元之间无跨单元调用，确保故障隔离和线性扩展能力。

2.2 同城双活架构

同城双活是两个机房位于同一城市核心网络区域内，网络延迟 <5ms，具备构建强一致性双活的基础条件。同城双活的核心设计原则是：

• 双写数据同步：两个机房同时接收写请求，通过 MySQL Group Replication 实现强一致性复制
• 流量 50/50 分发：DNS 智能解析根据用户地理位置将请求路由到最近机房，同时保证负载均衡
• 故障自动切换：健康检查发现主机房不可达时，自动将流量切换到备用机房，切换时间 < 30 秒
• 网络分区保护：当网络分区发生时，通过 ZooKeeper Leader 选举确定主机房，未连接主节点的机房自动降级为只读

同城双活的挑战在于 CAP 取舍：当网络分区发生时（两个机房之间网络中断），系统面临 CP（一致性+分区容忍）或 AP（可用性+分区容忍）的选择。我们的策略是默认选择 CP——在网络分区期间，从机房降级为只读，保证数据强一致；仅当业务明确允许最终一致性时，才允许从机房继续写入（通过冲突解决机制）。

2.3 异地多活架构

异地多活应对城市级灾难（地震、洪水、大规模停电）。主备机房相距 300-800 公里，网络延迟 30-50ms，不适合强一致性同步。异地多活采用最终一致性架构：

• 异步数据复制：主机房写操作通过 Kafka 异步同步到备机房，复制延迟约 1-5 秒
• 冲突数据处理：双写冲突使用"最后写者胜出（LWW, Last Write Wins）"策略，通过业务时间戳或全局序列号解决
• 跨机房查询：读请求优先访问本机房数据，热点数据通过 Redis 跨机房复制加速
• 城市级故障切换：主机房整体不可用时，备机房接管全部流量，RTO < 5 分钟（因涉及数据补齐）

2.4 单元化架构设计

单元化（Cell-Based Architecture）是跨机房多活架构的终极形态，目标是支撑业务线性扩展到 100+ 单元，每个单元完全自包含，单元之间无同步调用。核心设计原则：

• 数据路由隔离：按用户 ID 取模（cell_id = user_id % cell_count）将用户路由到固定单元，相同用户的所有请求在同一单元内处理
• 单元封闭性：业务逻辑在单元内闭环，跨单元交互通过异步消息（MQ）实现，避免同步跨单元调用带来的延迟和可用性风险
• 单元等比扩容：新增单元时，通过用户迁移实现数据重分布，迁移过程对用户无感知
• 全局数据只读副本：报表、分析等需要聚合全量数据的场景，通过全局只读副本（MySQL Binlog 同步）支持，不影响单元内事务

单元化架构的关键挑战在于"新增单元时的用户迁移"。我们采用 一致性哈希环 替代简单取模：每个用户在一致性环上有多个虚拟节点，新增单元时只需迁移部分虚拟节点，影响范围控制在 < 10% 的用户。

2.5 流量调度架构

流量调度的关键挑战是 灰度切流：当需要将部分流量从主机房迁移到备用机房时，如何保证迁移过程平稳且可回滚？我们设计了五步灰度切流策略：

• Step 1（1%）：DNS 权重调整，将 1% 流量切到备用机房，观察 30 分钟
• Step 2（5%）：扩大至 5%，观察 1 小时，关注错误率、延迟、业务指标
• Step 3（20%）：扩大至 20%，如有问题立即回滚（DNS TTL=60s，5分钟内可完全回滚）
• Step 4（50%）：主机房降级为备用，新写入流量主要写入备用机房
• Step 5（100%）：主机房完全下线，备用机房接管全部流量

三、核心技术挑战与解决方案