> **本文是「架构实战·第二季」第 56 篇**。单 Region 部署的容灾级别有限，异地多活是"终极容灾"——两个或多个 Region 同时服务、同时互备。单元化（Cell-based）架构是异地多活的核心：把用户和数据按规则切分到不同单元，每个单元独立服务、独立故障。这篇文章把单元化设计、数据同步、流量调拨、容灾切换讲清楚。

---

## 引子：那次靠"异地多活"救命的阿里云故障

2023 年 11 月 27 日，阿里云某 Region 出现大规模网络故障，**持续 4 小时**。

事后公布数据显示：

- **故障 Region 内**数千个服务受影响
- 但有异地多活架构的企业（如淘宝、菜鸟、字节）**几小时内全部切流到其他 Region**
- 没有异地多活的企业**业务中断 4+ 小时**

我们当时的核心业务有 3 个服务在故障 Region，但**通过异地多活架构，15 分钟内切到备份 Region，业务中断 0 分钟**。

CEO 那天在技术群里发了一句话：

> "今天证明了，2 年前投 800 万做的异地多活值了。"

这篇文章把"异地多活"从原理到落地讲清楚。

---

## 一、容灾级别的演进

### 1.1 五级容灾

```
L0: 单机房
   ↓
L1: 同城双活（同城不同 AZ）
   ↓
L2: 同城三活（同城三个 AZ）
   ↓
L3: 异地灾备（一个 Region 主，一个 Region 备）
   ↓
L4: 异地多活（多个 Region 同时服务）
```

| 级别 | RTO | RPO | 成本 | 复杂度 |
|------|-----|-----|------|--------|
| L0 | - | - | 1x | 低 |
| L1 | 分钟级 | 0 | 1.5x | 中 |
| L2 | 分钟级 | 0 | 2x | 中高 |
| L3 | 小时级 | 秒级 | 3x | 高 |
| L4 | 分钟级 | 0 | 5x+ | 极高 |

**RTO**（Recovery Time Objective）：恢复时间目标
**RPO**（Recovery Point Objective）：数据丢失容忍

### 1.2 业务对容灾的需求

```yaml
tier_0:  # 核心交易
  requirement: L4 异地多活
  rto: 5分钟
  rpo: 0
  
tier_1:  # 重要业务
  requirement: L3 异地灾备
  rto: 30分钟
  rpo: 秒级
  
tier_2:  # 内部工具
  requirement: L1 同城双活
  rto: 1小时
  rpo: 分钟级
```

---

## 二、异地多活的"三种模式"

### 2.1 模式 1：主备模式（Active-Standby）

```
┌─────────────────┐
│  Region A 主     │ ← 100% 流量
│  (Active)        │
└─────────────────┘
         ↑
         │ 故障时切换
         ↓
┌─────────────────┐
│  Region B 备     │ ← 0% 流量（平时空跑）
│  (Standby)       │
└─────────────────┘
```

**优点**：简单，数据库主从同步即可
**缺点**：备份 Region 资源浪费，切换需要时间（RTO 小时级）

### 2.2 模式 2：双活模式（Active-Active）

```
┌─────────────────┐    ┌─────────────────┐
│  Region A       │ ←→ │  Region B       │
│  50% 流量       │    │  50% 流量       │
└─────────────────┘    └─────────────────┘
```

**优点**：资源利用率高，切换快
**缺点**：数据双向同步复杂，冲突解决难

### 2.3 模式 3：单元化模式（Cell-based，主流）

```
┌──────────────┐    ┌──────────────┐
│  Cell A1     │    │  Cell A2     │
│  Region 1    │    │  Region 1    │
│  用户 0-30%  │    │  用户 30-60% │
└──────────────┘    └──────────────┘
        ↕                 ↕
   数据同步            数据同步
        ↕                 ↕
┌──────────────┐    ┌──────────────┐
│  Cell B1     │    │  Cell B2     │
│  Region 2    │    │  Region 2    │
│  用户 0-30%  │    │  用户 30-60% │
└──────────────┘    └──────────────┘
```

**核心思想**：

- **按用户划分单元**（如 userId % N）
- 每个单元**包含完整的服务 + 数据**
- 不同单元的流量走不同 Region
- 故障时**只切某个单元**，其他单元不受影响

**优点**：

- RTO 短（分钟级）
- 故障影响范围小（一个单元挂，其他单元正常）
- 资源利用率高
- 数据冲突少（用户级隔离）

**缺点**：

- 实施复杂
- 不能跨单元事务（需要补偿）
- 数据迁移复杂

---

## 三、单元化设计

### 3.1 单元划分规则

```yaml
# 按用户 ID 划分
def getCellId(userId):
    return userId % 256   # 分 256 个单元

# 按地域划分（粗粒度）
def getCellId(user):
    if user.region == "east":
        return "cell-east"
    elif user.region == "south":
        return "cell-south"
    # ...
```

**划分原则**：

- **用户级隔离**——按 userId 哈希
- **地域优先**——同地域用户优先同单元
- **业务关联**——同一业务的关联用户优先同单元

### 3.2 单元与 Region 的映射

```yaml
cell_region_mapping:
  # 默认映射（4 个 Region × 64 个单元）
  cell_id 0-63:    region-east-1
  cell_id 64-127:  region-east-2
  cell_id 128-191: region-south-1
  cell_id 192-255: region-west-1
  
  # 故障切换时重新映射
  # 例：region-east-1 故障，0-63 单元切到 region-east-2
```

### 3.3 单元化的"五件套"

```
┌──────────────────────────────────────────┐
│  1. 接入层（接入路由）                    │
│     - 域名解析到最近的 Cell               │
│     - 中心 BGP Anycast                     │
├──────────────────────────────────────────┤
│  2. 网关层（流量路由）                    │
│     - 根据 userId 路由到对应 Cell          │
│     - 支持灰度切换                         │
├──────────────────────────────────────────┤
│  3. 服务层（业务服务）                    │
│     - 每个 Cell 独立部署                   │
│     - 服务调用限制在 Cell 内               │
├──────────────────────────────────────────┤
│  4. 数据层（数据分片）                    │
│     - 按 userId 哈希分库分表               │
│     - 每个 Cell 独立库                     │
│     - 跨 Cell 数据同步                     │
├──────────────────────────────────────────┤
│  5. 中间件层（消息、缓存）                │
│     - 每个 Cell 独立 Redis、Kafka          │
│     - 跨 Cell 通过消息同步                 │
└──────────────────────────────────────────┘
```

### 3.4 路由实现

```nginx
# Nginx 根据 cookie 路由
upstream cell_a {
    server cell-a-1.example.com;
    server cell-a-2.example.com;
}

upstream cell_b {
    server cell-b-1.example.com;
    server cell-b-2.example.com;
}

server {
    location / {
        set $cell_id $cookie_user_cell;
        
        if ($cell_id ~ "^0-63$") {
            proxy_pass http://cell_a;
        }
        if ($cell_id ~ "^64-127$") {
            proxy_pass http://cell_b;
        }
    }
}
```

```java
// Spring Cloud Gateway 路由
@Component
public class CellRoutePredicateFactory 
    extends AbstractRoutePredicateFactory<CellRoutePredicateFactory.Config> {
    
    public Predicate<ServerWebExchange> apply(Config config) {
        return exchange -> {
            String userId = extractUserId(exchange.getRequest());
            long cellId = Math.abs(userId.hashCode()) % 256;
            
            // 根据 cellId 选择目标 Cell
            String targetCell = cellRouter.route(cellId);
            exchange.getAttributes().put("targetCell", targetCell);
            
            return true;
        };
    }
}
```

---

## 四、数据层的单元化

### 4.1 数据分片规则

```sql
-- 按 userId 哈希分库
-- 假设分 4 个库
CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    user_id BIGINT NOT NULL,
    ...
) ENGINE=InnoDB;

-- 数据分布
-- userId % 4 = 0 → db_0
-- userId % 4 = 1 → db_1
-- userId % 4 = 2 → db_2
-- userId % 4 = 3 → db_3
```

### 4.2 ShardingSphere 配置

```yaml
# sharding-config.yaml
dataSources:
  ds_0: { url: jdbc:mysql://db-0/orders }
  ds_1: { url: jdbc:mysql://db-1/orders }
  ds_2: { url: jdbc:mysql://db-2/orders }
  ds_3: { url: jdbc:mysql://db-3/orders }

rules:
  - !SHARDING
    tables:
      orders:
        actualDataNodes: ds_${0..3}.orders
        databaseStrategy:
          standard:
            shardingColumn: user_id
            shardingAlgorithmName: user_db_mod
    shardingAlgorithms:
      user_db_mod:
        type: MOD
        props:
          sharding-count: 4
```

### 4.3 全局唯一 ID

```java
// 单元化后，单元内 ID 自增，但全局不能冲突
// 方案 1：雪花算法（Snowflake）
//   1 bit 符号 + 41 bit 时间戳 + 10 bit 机器 + 12 bit 序列
public class SnowflakeIdGenerator {
    private final long machineId;  // Cell ID
    
    public long nextId() {
        long timestamp = System.currentTimeMillis();
        long sequence = atomicSequence.incrementAndGet() & 0xFFF;
        return (timestamp << 22) | (machineId << 12) | sequence;
    }
}

// 方案 2：Leaf 美团的号段模式
//   每次从 DB 拿一段 ID，本地分配
```

### 4.4 跨单元数据访问

```java
// 不允许跨单元 RPC 调用
// 必须通过数据同步
@Service
public class OrderService {
    public Order getOrder(Long orderId, Long userId) {
        // 1. 计算单元
        int cellId = (int) (userId % 256);
        
        // 2. 路由到对应 Cell
        Order order = cellRouter.call(cellId, () -> 
            orderRepo.findById(orderId)
        );
        
        return order;
    }
}
```

---

## 五、跨 Cell 数据同步

### 5.1 同步的两种模式

**同步模式**（强一致）：

```
Cell A 写 → 同步消息 → Cell B 写 → 等所有 Cell 成功
```

**异步模式**（最终一致）：

```
Cell A 写 → 异步消息 → Cell B 写（后台同步）
```

### 5.2 基于 Kafka 的数据同步

```java
// Cell A 写入时，发送同步消息
@Transactional
public void createOrder(Order order) {
    // 1. 写入本地 Cell
    orderRepo.save(order);
    
    // 2. 发送同步消息（其他 Cell 订阅）
    OrderSyncEvent event = new OrderSyncEvent(
        order.getId(),
        order.getUserId(),
        "CREATE",
        order
    );
    kafkaTemplate.send("order-sync-cell-a", order.getId().toString(), event);
}
```

```java
// Cell B 订阅同步消息
@KafkaListener(topics = "order-sync-cell-a")
public void onOrderSyncEvent(OrderSyncEvent event) {
    // 1. 写入本地 Cell
    orderRepo.save(event.getOrder());
    
    // 2. 幂等处理
    if (syncLog.exists(event.getId())) {
        return;  // 已同步过
    }
    syncLog.save(event);
}
```

### 5.3 同步冲突解决

```yaml
conflict_resolution:
  # 1. 优先 Cell 写入优先（Last Write Wins）
  strategy: lww
  conflict_field: updated_at
  
  # 2. 业务规则优先
  strategy: business_rule
  rule: "用户余额只能从自己的 Cell 扣减"
  
  # 3. 业务补偿
  strategy: compensate
  # 冲突时生成补偿事务
```

**最常用的策略**：**LWW（Last Write Wins）+ Cell 优先级**。

---

## 六、流量调拨

### 6.1 调拨的"四级"控制

```
Level 1: 域名解析（DNS）
   ↓
Level 2: CDN 路由
   ↓
Level 3: 网关路由
   ↓
Level 4: 服务路由
```

### 6.2 DNS 切换（最粗）

```bash
# 故障时切换 DNS
# 正常解析到 cell-a-1.example.com
# 故障时切到 cell-b-1.example.com
```

```python
# 自动化 DNS 切换
def failover_dns(from_region, to_region):
    # 1. 调云厂商 API
    alidns.update_domain_record(
        domain="api.example.com",
        rr="cell-a-1",
        value="<new IP in to_region>"
    )
    
    # 2. 等 DNS 缓存过期（TTL 60 秒）
    sleep(60)
    
    # 3. 验证
    if check_health("cell-a-1", from_region).is_healthy:
        return False  # 不切换
    
    return True  # 切换成功
```

### 6.3 网关切换（中等粒度）

```yaml
# 配置中心动态调整
gateway_routes:
  - service: order-service
    cells:
      - cell_id: 0-63
        target: cell-a-east-1
        weight: 100
      - cell_id: 64-127
        target: cell-b-east-2
        weight: 100
```

切换时调整 weight 或 target：

```yaml
# 故障时调整
gateway_routes:
  - service: order-service
    cells:
      - cell_id: 0-63
        target: cell-b-east-2    # 切到 cell-b
        weight: 100
      - cell_id: 64-127
        target: cell-b-east-2
        weight: 100
```

### 6.4 服务级切换（最细粒度）

```java
// 在服务层根据流量标记路由
@Service
public class CellRouter {
    public String route(long userId) {
        int cellId = (int) (userId % 256);
        
        // 1. 查路由表（动态可调整）
        RouteConfig route = routeConfigService.getRoute(cellId);
        
        // 2. 故障检测
        if (!healthCheck.isHealthy(route.getTarget())) {
            // 自动切换到备用 Cell
            route = routeConfigService.getBackupRoute(cellId);
        }
        
        return route.getTarget();
    }
}
```

---

## 七、容灾切换

### 7.1 切换决策

```yaml
failover_decision:
  triggers:
    - condition: 整个 Region 不可用
      action: 切到备用 Region
      scope: 全量
      
    - condition: 某个 Cell 不可用
      action: 切到备用 Cell
      scope: 单 Cell
      
    - condition: 某些用户受影响
      action: 用户级切流
      scope: 用户级
      
  approval:
    - L1: 自动切换（5 分钟超时）
    - L2: SRE Lead 确认
    - L3: SRE VP + 业务 VP 双签
```

### 7.2 切换剧本

```yaml
failover_runbook:
  - name: "Region East-1 故障"
    detect:
      - "监控系统告警"
      - "oncall 确认"
    steps:
      - 1. 确认故障范围
      - 2. 通知业务方
      - 3. DNS 切换（流量入口）
      - 4. 中间件切换（Redis、Kafka）
      - 5. 数据库切换（读写分离 → 主备切换）
      - 6. 验证核心链路
      - 7. 通知用户
      - 8. 持续监控
    rollback_plan:
      - "故障恢复后回切"
      - "用蓝绿部署切回"
```

### 7.3 切换验证

```yaml
verification_checklist:
  - [ ] 核心服务 200 OK
  - [ ] 核心业务 E2E 通过
  - [ ] 数据库读写正常
  - [ ] 缓存命中正常
  - [ ] 消息队列消费正常
  - [ ] 监控大盘数据正常
```

### 7.4 切换的"安全阀"

```java
// 切换前最后检查
public boolean canFailover(String fromCell, String toCell) {
    // 1. 目标 Cell 健康
    if (!healthCheck.isHealthy(toCell)) return false;
    
    // 2. 目标 Cell 容量够
    if (capacityMonitor.getUsage(toCell) > 0.7) {
        alert("目标 Cell 容量不足，请扩容后再切换");
        return false;
    }
    
    // 3. 数据同步延迟 < 阈值
    if (syncMonitor.getLag(fromCell, toCell) > 60) {
        alert("数据同步延迟过大，切换可能丢数据");
        return false;
    }
    
    return true;
}
```

---

## 八、踩坑提示

### 8.1 不要一开始做"全球多活"

```
阶段 1: 同城双活（最简单）
阶段 2: 同城三活（更稳）
阶段 3: 异地灾备
阶段 4: 异地多活
```

**每一步都是上一步的演进**，不是跳跃。

### 8.2 不要让所有业务都上异地多活

```yaml
# 适合异地多活的业务
suitable:
  - 用户量大的（电商、社交）
  - 7x24 服务的（金融、SaaS）
  - 容灾要求高的（订单、支付）

# 不适合的
unsuitable:
  - 内部工具
  - 数据量特别大的
  - 强事务依赖的
```

### 8.3 数据同步是最大的坑

```yaml
# 同步的几个问题
- 同步延迟：跨 Region 同步 100ms+ 是常态
- 同步丢失：网络抖动可能丢消息
- 同步冲突：双向写入可能冲突
- 同步循环：A 同步给 B，B 又同步给 A
```

**解决**：

- 用 Kafka + 幂等消费
- 用单元 ID 避免循环同步
- 关键业务用 Paxos/Raft 类强一致协议

### 8.4 单元化后不能跨单元事务

```java
// ❌ 跨单元分布式事务（性能差、复杂度高）
@Transactional(rollbackFor = Exception.class)
public void transfer(Long fromUserId, Long toUserId, BigDecimal amount) {
    // fromUserId 在 cell A
    // toUserId 在 cell B
    // 跨 cell 事务
}

// ✅ 用最终一致 + 补偿
public void transfer(Long fromUserId, Long toUserId, BigDecimal amount) {
    // 1. Cell A: 扣减 fromUser
    cellA.deduct(fromUserId, amount);
    
    // 2. 发送消息
    kafka.send(new TransferEvent(toUserId, amount));
    
    // 3. Cell B 消费消息，加 toUser
    // 如果失败，重试 + 补偿
}
```

### 8.5 切换演练必须做

```yaml
# 每季度一次
quarterly_failover_drill:
  - 单 Cell 切换
  - 单 Region 切换
  - 全量切换
  - 回切
```

**不演练的切换 = 赌博**。

---

## 本篇要点回顾

1. 容灾分 5 级，异地多活是最高级（L4）
2. **单元化（Cell-based）是主流异地多活方案**——按用户 ID 划分
3. 单元化五件套：接入 / 网关 / 服务 / 数据 / 中间件
4. 数据分片按 userId 哈希，跨 Cell 通过消息同步
5. 流量调拨四级：DNS / CDN / 网关 / 服务
6. **容灾切换必须演练**——不演练等于赌博
7. 不要跨单元事务，用最终一致 + 补偿

---

## 下篇预告

下一篇讲 **57-SLO 工程：从 Error Budget 到发布门禁**。SLO 不是"目标"——是"约束"。Error Budget 用完了，团队必须停止新功能开发，专注于稳定性。SLO 怎么设计？Error Budget 怎么算？发布门禁怎么设置？敬请期待。

本文是「架构实战·第二季」第 56 篇。单 Region 部署的容灾级别有限，异地多活是"终极容灾"——两个或多个 Region 同时服务、同时互备。单元化（Cell-based）架构是异地多活的核心：把用户和数据按规则切分到不同单元，每个单元独立服务、独立故障。这篇文章把单元化设计、数据同步、流量调拨、容灾切换讲清楚。

【架构实战】异地多活架构：单元化与流量调拨

研发部经理

人工智能

异地多活架构实战解析：从单元化设计到容灾切换，详解五级容灾演进、三种部署模式、数据同步与流量调拨核心机制。文章聚焦Cell-based主流方案，覆盖接入层、数据层、中间件层完整架构，并提供故障演练与切换决策实战经验，帮助企业实现分钟级RTO的终极容灾目标。

DNS解析新购特惠59元起，续费优惠低至5.3折！

热销域名限时优惠，新客首年免费！


domain

CDN免费试用


腾讯云双十一大促

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【架构实战】异地多活架构：单元化与流量调拨-腾讯云开发者社区-腾讯云

【架构实战】异地多活架构：单元化与流量调拨

【架构实战】异地多活架构：单元化与流量调拨

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐