多地域多活架构的可靠性设计

单机房架构：
                                          ┌── App Server ×N
  用户 ──→ DNS/CDN ──→ Load Balancer ─────┼── App Server ×N
                                          └── App Server ×N
                                                    │
                                          ┌─────────┴─────────┐
                                          │   Database (主从)   │
                                          └───────────────────┘

问题：
  1. 如果机房断电/网络中断 → 全站不可用
  2. 跨地域用户延迟高（北京到广州 ~30ms RTT）
  3. 容量受限于单个机房

RTO 和 RPO 的关系：

时间线：
  正常运行 │←─────── 故障发生 ───────→ 恢复
           │                            │
           │←── RPO ──→│               │
           │  数据丢失范围               │
           │                            │
           │←────── RTO ──────────────→│
              服务不可用时间

  用户 ──→ DNS ──→ 主机房（Active）
                     ├── App Server
                     ├── DB (Primary)
                     └── ↓ 异步复制
                 备机房（Standby）
                     ├── App Server（待命）
                     └── DB (Standby)

  用户 ──→ DNS ──→ 负载均衡（按权重分流）
                     │
          ┌──────────┴──────────┐
          ↓                     ↓
    机房 A（Active）        机房 B（Active）
    ├── App Server          ├── App Server
    ├── DB (Primary)        ├── DB (Replica)
    └── 同步复制 ←─────────┘

  用户 ──→ 全局 DNS（按地域路由）
              │
    ┌─────────┼─────────┐
    ↓         ↓         ↓
  北京区域   上海区域   海外区域
  ├── App    ├── App    ├── App
  ├── DB     ├── DB     ├── DB
  └──┬───────┴──┬──────┘
     │ 异步复制  │
     └──────────┘

需要多机房容灾？
  │
  ├─ 是 → RTO 和 RPO 要求？
  │   │
  │   ├─ RTO < 1min, RPO = 0
  │   │   → 同城双活（同步复制）
  │   │   → 需要：低延迟专线、同步复制数据库
  │   │
  │   ├─ RTO < 30min, RPO < 1min
  │   │   → 异地主备（异步复制）
  │   │   → 需要：异步复制、自动故障切换
  │   │
  │   └─ RTO < 4h, RPO < 1h
  │       → 异地冷备（定期备份）
  │       → 需要：备份系统、手动恢复流程
  │
  └─ 需要全球低延迟？
      → 异地多活（单元化架构）
      → 需要：数据同步方案、写冲突解决、全局路由

场景：用户在北京和上海同时修改个人资料

  14:00:00  北京：用户改名 "张三" → 写入北京 DB
  14:00:01  上海：用户改名 "李四" → 写入上海 DB
  14:00:05  异步复制：北京 → 上海（"张三" 覆盖 "李四"）
  14:00:06  异步复制：上海 → 北京（"李四" 覆盖 "张三"）
  → 数据冲突！最终状态不确定

单元化架构：

  用户 ──→ 路由层（按用户 ID 路由到归属单元）
              │
    ┌─────────┼─────────┐
    ↓         ↓         ↓
  Unit-北京  Unit-上海  Unit-深圳
  ├── App    ├── App    ├── App
  ├── DB     ├── DB     ├── DB
  └── 数据按用户分片

  用户 A 的数据只在 Unit-北京读写
  用户 B 的数据只在 Unit-上海读写
  → 无写冲突

# 单元路由配置
unit_routing:
  rule: "hash(user_id) % unit_count"
  
  units:
    - name: "unit-bj"
      region: "beijing"
      user_range: "0-33%"
      
    - name: "unit-sh"
      region: "shanghai"
      user_range: "33-66%"
      
    - name: "unit-sz"
      region: "shenzhen"
      user_range: "66-100%"

  # 用户首次访问时确定归属单元
  # 之后所有请求路由到该单元

用户请求
  │
  ↓
全局 DNS / GSLB（Global Server Load Balancing）
  │
  ├── 按地域就近路由
  ├── 按健康状态路由
  ├── 按容量权重路由
  └── 故障时自动切换

# DNS 故障切换配置
dns_failover:
  primary:
    record: "api.example.com"
    target: "1.2.3.4"          # 主机房 IP
    health_check: "https://api.example.com/healthz"
    check_interval: 10s
    
  failover:
    target: "5.6.7.8"          # 备机房 IP
    trigger: "primary health check failed 3 consecutive times"
    ttl: 30s                   # DNS TTL 设短，加速切换
    
  # 注意：DNS 切换有 TTL 缓存延迟
  # 客户端可能缓存了旧 IP，最多需要 TTL 时间才生效

# 应用层流量路由（更精确）
app_level_routing:
  gateway:
    type: "API Gateway / Service Mesh"
    
  routing_rules:
    normal:
      - region: "beijing"
        weight: 50%
      - region: "shanghai"
        weight: 50%
    
    failover:
      trigger: "beijing region health check failed"
      action:
        - region: "beijing"
          weight: 0%            # 立即摘除
        - region: "shanghai"
          weight: 100%          # 全量切换
      speed: "instant"          # 应用层切换无 DNS 缓存问题
    
    canary_failover:
      trigger: "beijing region degraded (latency > 1s)"
      action:
        - region: "beijing"
          weight: 25%           # 降级而非完全摘除
        - region: "shanghai"
          weight: 75%

traffic_switching_best_practices:
  before_switch:
    - "验证目标机房健康状态"
    - "确认数据同步延迟在可接受范围"
    - "通知相关团队"
    - "准备回滚方案"

  during_switch:
    - "逐步切换，而非一次性全量"
    - "切换过程中持续监控"
    - "如出现异常，立即回滚"

  after_switch:
    - "验证服务正常"
    - "观察至少 15 分钟"
    - "更新 DNS 记录"
    - "通知所有团队切换完成"

  switch_sequence:
    1: "降低源机房流量权重（100% → 90%）"
    2: "观察目标机房是否能承受 10% 流量"
    3: "继续降低源机房权重（90% → 50%）"
    4: "观察目标机房在 50% 流量下的表现"
    5: "完成切换（50% → 0%）"
    6: "源机房完全摘除"

RTO = 故障检测时间 + 决策时间 + 切换时间 + 验证时间

示例：
  故障检测：30 秒（健康检查 3 次失败 × 10 秒间隔）
  决策时间：30 秒（自动决策脚本）
  切换时间：60 秒（DNS 更新 + 流量切换）
  验证时间：60 秒（健康检查确认）
  → RTO ≈ 3 分钟

RPO = 数据复制延迟

同步复制：RPO = 0（数据实时同步）
异步复制：RPO = 复制延迟时间（通常 1-60 秒）

# RTO/RPO 监控指标
disaster_recovery_monitoring:
  rto_related:
    - metric: "health_check_failure_count"
      alert: "> 3 consecutive failures"
      action: "trigger automatic failover"
    
    - metric: "failover_execution_time"
      target: "< 60s"
    
    - metric: "service_recovery_time"
      target: "< 5min (RTO target)"

  rpo_related:
    - metric: "replication_lag_seconds"
      alert: "> 10s"
      action: "warning"
      critical: "> 60s"
    
    - metric: "replication_lag_bytes"
      alert: "> 10MB"
      
    - metric: "data_loss_on_failover"
      target: "0 (RPO target)"

# Prometheus 监控复制延迟
# MySQL 主从复制延迟
mysql_slave_status_seconds_behind_master > 10

# PostgreSQL 复制延迟
pg_replication_lag > 10

# Redis 复制延迟
redis_replication_offset_diff > 1024000

监控架构：

  北京机房                上海机房
  ├── Prometheus          ├── Prometheus
  ├── Node Exporter       ├── Node Exporter
  ├── App Metrics         ├── App Metrics
  └── ↓ remote_write      └── ↓ remote_write
         │                        │
         └────────┬───────────────┘
                  ↓
          中央 Prometheus / Thanos
                  │
          ┌───────┼───────┐
          ↓       ↓       ↓
        Grafana  AlertManager  长期存储

multi_region_monitoring:
  # 1. 各地域服务健康
  per_region:
    - "各地域服务可用性"
    - "各地域延迟（P50/P95/P99）"
    - "各地域错误率"
    - "各地域流量分布"

  # 2. 跨地域数据同步
  cross_region:
    - "数据库复制延迟"
    - "消息队列跨地域同步延迟"
    - "缓存同步延迟"
    - "复制通道健康状态"

  # 3. 全局视图
  global:
    - "全局可用性（所有地域的加权平均）"
    - "全局 SLO 达成状态"
    - "地域间流量分布"
    - "DNS 解析分布"

  # 4. 容灾就绪度
  dr_readiness:
    - "备用机房健康状态"
    - "数据同步延迟是否在 RPO 范围内"
    - "故障切换脚本是否可用"
    - "最近一次切换演练的时间"

# 全局监控仪表盘设计
global_dashboard:
  row_1_global_overview:
    - panel: "全局服务可用性"
      query: "avg by (region) (slo:availability:rate30d)"
    - panel: "全局流量分布"
      query: "sum by (region) (rate(http_requests_total[5m]))"
    - panel: "全局错误率"
      query: "sum by (region) (rate(http_requests_total{status=~'5..'}[5m]))"

  row_2_replication_health:
    - panel: "数据库复制延迟"
      query: "max by (region) (mysql_slave_status_seconds_behind_master)"
      threshold: "10s (warning), 60s (critical)"
    - panel: "消息队列同步延迟"
      query: "max by (region) (mq_replication_lag_seconds)"

  row_3_dr_readiness:
    - panel: "各机房健康状态"
      type: "status_map"
      query: "up by (region, instance)"
    - panel: "RPO 状态"
      type: "gauge"
      query: "max(replication_lag_seconds)"
      threshold: "green < 10s, yellow 10-60s, red > 60s"
    - panel: "最近演练时间"
      type: "stat"
      query: "time() - last_drill_timestamp"

真实案例：
  某公司投入数百万建设异地容灾，三年没有演练。
  真实故障时尝试切换，发现：
    - DNS 切换脚本过期不可用
    - 备机房的数据库版本与主机房不一致
    - SSL 证书已过期
    - 备机房的应用配置不完整
  → 容灾形同虚设

# 多活故障切换演练

## 演练目标
验证从北京机房切换到上海机房的完整流程，确认 RTO < 5min，RPO < 10s。

## 前置条件
- [ ] 上海机房健康状态正常
- [ ] 数据同步延迟 < 5s
- [ ] 切换脚本经过仿真验证
- [ ] 回滚方案已准备
- [ ] 相关团队已通知
- [ ] 选择低峰时段（凌晨 2:00-4:00）

## 演练流程

### Phase 1: 预检查（T-30min）
1. 验证上海机房服务健康
   ```bash
   curl -s https://api-sh.example.com/healthz

### 自动化故障切换

```yaml
# 自动故障切换配置
auto_failover:
  enabled: true
  trigger:
    condition: "primary region health check failed 3 consecutive times"
    health_check:
      url: "https://api-bj.example.com/healthz"
      interval: 10s
      timeout: 5s
      failure_threshold: 3

  pre_failover_checks:
    - "standby region health: OK"
    - "replication lag < 10s"
    - "standby capacity > 100% of current traffic"

  failover_steps:
    1:
      action: "update DNS weights"
      from: "bj:100,sh:0"
      to: "bj:0,sh:100"
      timeout: 30s
    
    2:
      action: "promote standby DB to primary"
      command: "./promote_standby_db.sh --region sh"
      timeout: 60s
    
    3:
      action: "verify service health"
      command: "./verify_service.sh --region sh"
      timeout: 60s
    
    4:
      action: "notify teams"
      command: "./notify.sh --event auto_failover --to all"

  rollback:
    condition: "verification failed or service not healthy after 5 min"
    action: "revert DNS weights to original"

伪双活：
  两个机房都部署了应用，但数据库只有一个机房。
  机房 A 故障 → 机房 B 的应用无法访问数据库 → 全站不可用。

  这不是双活，只是"双部署"。
  
真正的双活：
  两个机房都有完整的应用 + 数据库副本。
  任一机房故障 → 另一个机房独立继续服务。

场景：
  应用做了双活，但依赖的第三方服务（如短信网关、支付通道）只有单点。
  机房故障 → 应用切换到备机房 → 但备机房无法访问第三方服务 → 仍然不可用。

教训：
  双活的范围必须覆盖所有关键依赖，包括第三方服务。
  第三方服务也需要有备用方案（如多个短信供应商）。

场景：
  DNS TTL 设为 1 小时。
  机房故障时切换 DNS，但客户端缓存了旧 IP。
  1 小时内部分用户仍然访问故障机房。

教训：
  故障切换场景的 DNS TTL 应设为 30-60 秒。
  或使用应用层路由（API Gateway/Service Mesh）绕过 DNS 缓存。

场景：
  异步复制延迟 30 秒。
  主机房故障时强制切换，丢失最后 30 秒数据。
  用户发现刚提交的订单消失了。

教训：
  明确 RPO 目标，并在切换前检查复制延迟。
  如果复制延迟超过 RPO，应该等待而非立即切换。
  对于 RPO=0 的场景，必须使用同步复制。

场景：
  建设了多活容灾，但从不演练。
  真实故障时发现切换脚本过期、配置不一致、证书过期。

教训：
  没有演练过的容灾方案等于没有容灾。
  至少每半年做一次全量切换演练。
  每月做一次部分流量切换验证。

multi_region_cost_analysis:
  infrastructure:
    dual_active:
      compute: "2x（两个机房都需要完整计算资源）"
      storage: "2x + 复制带宽"
      network: "专线/互联带宽"
      
    active_standby:
      compute: "1.5x（备机房可缩减规模）"
      storage: "2x"
      network: "复制带宽"

  operational:
    engineering: "需要多活架构经验的工程师"
    monitoring: "跨地域监控系统"
    testing: "定期演练成本"

  hidden_costs:
    - "数据复制延迟导致的业务复杂性"
    - "跨地域调试和排障的时间成本"
    - "数据合规审计的额外工作"
    - "团队需要掌握多活运维技能的培训成本"

  roi_analysis:
    benefit: "避免机房级故障导致的业务损失"
    question: "机房级故障的年概率 × 故障损失 vs 多活架构年成本"
    typical: "核心业务值得做多活；非核心业务用主备即可"