多集群与跨云架构

当单集群单地域的容量、可用性与成本无法满足业务时，多集群（Multi-Cluster）与跨云（Cross-Cloud）架构成为必然选择。它不只是"多部署几份"，而是要在网络、数据、流量、容灾与成本五个维度上重新设计。本文系统讲解多集群跨云架构的完整设计。

1. 为什么需要多集群与跨云

但跨集群/跨云也带来新的复杂度：网络互通、数据同步、流量一致性、运维分裂。核心是"三地一控"：多地部署、单一控制平面统一管理。

2. 多集群网络

2.1 集群联邦（KubeFed）

KubeFed（Kubernetes Federation）让一个控制平面管理多个集群，核心概念是模板 + 放置策略 + 覆盖：

FederatedDeployment（模板）
  ├─ 放置策略：放到 cluster-a、cluster-b、cluster-c
  └─ 覆盖：cluster-b 副本数为 3，cluster-c 副本数为 5

控制平面把模板渲染成分散到各集群的 Deployment

apiVersion: types.kubefed.io/v1beta1
kind: FederatedDeployment
metadata:
  name: order-service
  namespace: production
spec:
  template:
    spec:
      replicas: 3
      template:
        spec:
          containers:
            - name: order
              image: registry.example.com/order:v1.2.3
  placement:
    clusters:
      - name: cluster-a
      - name: cluster-b
  overrides:
    - clusterName: cluster-b
      clusterOverrides:
        - path: /spec/replicas
          value: 6

2.2 服务网格跨集群

Istio 等服务网格提供跨集群的服务发现与流量路由。多集群 Istio 的常见形态：

• 主从模型（Primary-Remote）：一个主集群的控制面管理多个远端集群
• 多主模型（Multi-Primary）：每集群独立控制面，通过共享 CA 互信，流量网格化互达
• 多主+多网络：跨 VPC/跨云时每集群一个网络，通过东西向网关打通

cluster-a (主)                    cluster-b (远程)
┌────────────────────┐            ┌────────────────────┐
│ istiod (控制面)     │───信任────►│ 无 istiod           │
│ Envoy sidecar      │            │ Envoy sidecar      │
│ 服务 order-svc     │◄───gRPC────│ 调用 order-svc      │
│ 服务 pay-svc       │            │ 服务 pay-svc        │
└────────────────────┘            └────────────────────┘

多集群服务网格的虚拟服务可以跨集群路由流量，用于灰度与容灾：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: order-routing
spec:
  hosts:
    - order-svc.production.svc.cluster.local
  http:
    - route:
        - destination:
            host: order-svc.cluster-a
          weight: 90
        - destination:
            host: order-svc.cluster-b
          weight: 10

2.3 网络方案对比

3. 跨云数据同步

3.1 单向同步与双向同步

3.2 数据同步手段

数据库同步：
  MySQL: 主从复制（跨专线） / binlog CDC（如 Canal、Debezium）→ 目标写入
  PostgreSQL: logical replication / BDR
  Redis: Redis Sentinel + 跨云 Proxy 同步 / 写主读从

对象存储/文件：
  对象存储厂商复制 / 自建同步任务（事件驱动触发复制）

消息/事件：
  Kafka MirrorMaker2 跨云复制 Topic
  RocketMQ/其他 → 跨云桥接消费再投递

# Kafka MirrorMaker2 跨云复制示例
clusters:
  source-cloud:
    bootstrap.servers: source-cluster:9092
  target-cloud:
    bootstrap.servers: target-cluster:9092
  source-cloud->target-cloud:
    enabled: true
    topics.replication.factor: 2
    config:
      replication.factor: 2
      sync.group.offsets.enabled: false
      emit.checkpoints.enabled: true

3.3 一致性与冲突解决

双向同步必然面临冲突。冲突解决策略：

最佳实践：跨云双活的数据冲突，最好通过"分片归属 + 单向同步 + 对账“组合避免，而不是让业务代码处理复杂的双向冲突合并。

4. 流量调度

4.1 GSLB 与全局负载均衡

GSLB（Global Server Load Balancer）根据用户地理位置、集群健康状态、负载把流量调度到最近的可用集群：

用户 ──► DNS (GSLB)
          ├─ 就近解析：华东用户 → cluster-shanghai
          ├─ 健康探测：主集群故障 → 解析到备集群
          └─ 负载均衡：多集群按权重/容量分配

# GSLB 配置抽象
cluster:
  shanghai: { weight: 50, health: ok, region: cn-east }
  singapore: { weight: 30, health: ok, region: ap-southeast }
  frankfurt: { weight: 20, health: ok, region: eu-central }

policy:
  geo: first-match    # 优先就近
  failover: active-standby
  probing: every 30s (http /healthz)

4.2 流量调度层次

第 1 层：DNS/GSLB —— 按地域/健康选择集群
第 2 层：网关/负载均衡 —— 集群入口路由
第 3 层：服务网格 —— 服务级跨集群路由（灰度/容灾）
第 4 层：应用层 —— 分片归属路由（单元化）

4.3 流量切换与回切

容灾切换（failover）必须有可观测、可回滚的流程：

1. 健康状态异常 / 人工决策触发
2. GSLB 将流量切到备集群（DNS TTL 控制生效时间）
3. 数据层切换到备集群可写（promote）
4. 验证：切流后观察错误率、延迟、数据一致性
5. 回切：故障恢复后，先追平数据，再逐步回切（金丝雀式）

回切比切换更危险：主集群恢复后数据可能落后，必须先数据追平、再小流量验证、再全面回切，否则会二次故障。相关容灾指标可参考 https://plumephp.com/distributed-multi-site-dr/。

5. 容灾与成本

5.1 RTO/RPO 设计

5.2 成本模型

跨云的成本往往被低估，规划时必须算清：

5.3 成本优化实践

• 只对关键链路做跨云：非核心服务保留单云，避免全量双份
• 冷数据集中：历史数据放对象存储并只存一份（或低频冗余）
• 按地域差异化：低延迟要求不高的地域少部署副本
• 数据压缩 + 增量：同步前先压缩，尽量只传增量而非全量

6. 架构模式与实践

6.1 三种主流模式

6.2 跨云业务系统部署示例

                 ┌─────────── GSLB/DNS ───────────┐
                 │     就近接入 + 健康切换          │
                 ▼                                ▼
      ┌─── 云 A（上海）───┐              ┌─── 云 B（新加坡）───┐
      │ 入口网关           │              │ 入口网关           │
      │ order-svc (分片1) │              │ order-svc (分片2) │
      │ 本地 MySQL 主      │              │ 本地 MySQL 主      │
      │ Redis 集群         │              │ Redis 集群         │
      │ Kafka 实例A        │              │ Kafka 实例B        │
      └─────┬─────────────┘              └─────┬─────────────┘
            │  binlog CDC 单向同步              │
            └──────────┬───────────────┬───────┘
                       ▼               ▼
                 ┌── 中心数据仓库 / 对账平台 ──┐
                 │  汇聚两份数据 + 对账验证     │
                 └────────────────────────────┘

6.3 关键原则与常见坑

1. 控制面统一、数据面隔离：用一个平台管理多集群，但数据必须按地域隔离
2. 不要全量双向同步：双向同步的冲突成本极高，优先分片归属 + 单向
3. 网络先于应用：跨云先打通网络与 DNS，再谈服务互调
4. 容灾必须演练：跨云切换不演练等于没有，定期 GameDay
5. 对账必配：跨云复制/同步链路多，没有 https://plumephp.com/distributed-data-consistency-reconciliation/ 兜底难以发现静默丢数据

总结

多集群与跨云是分布式系统在规模与合规压力下的必然演进，它的本质是”通过架构冗余换取可用性，通过统一平台消化复杂度"。与 https://plumephp.com/distributed-multi-site-dr/ 的容灾设计配合阅读，可形成完整的多云高可用视角。