1. Federation 架构概述
1.1 etcd Federation 概念
etcd Federation（联邦）是一种将多个独立 etcd 集群通过逻辑层连接起来，形成统一命名空间与数据视图的分布式架构模式。它并非将多个集群合并为一个更大的 Raft 组，而是在每个集群保持独立 Raft 共识与故障域的前提下，通过跨集群复制机制实现数据的最终一致或强一致同步。
核心设计原则：每个参与联邦的 etcd 集群仍然是一个独立的 Raft 组，拥有自己的 Leader、Follower 和投票节点。联邦层只负责在集群之间转发写入请求或同步变更事件，不参与底层 Raft 日志复制。
Federation 通常用于以下场景：
- 跨地域部署：业务需要多个数据中心共享同一套配置或服务发现数据。
- 故障隔离：单个集群故障不影响其他集群的可用性，联邦层可自动切换写入目标。
- 读写分离：本地集群处理本地读请求，联邦层将写请求广播到所有集群。
- 渐进式迁移：在集群升级或扩缩容期间，通过联邦逐步切换流量。
1.2 跨数据中心复制模型
etcd Federation 支持多种跨数据中心复制模型，不同模型在一致性、延迟和吞吐量上存在显著差异。下表对比了三种主流复制模型：
| 复制模型 | 一致性级别 | 写入延迟 | 典型场景 |
|---|---|---|---|
| 异步复制 | 最终一致 | 低（本地写入即返回） | 配置分发、缓存预热 |
| 同步复制 | 强一致 | 高（等待所有集群确认） | 金融交易、全局锁 |
| 半同步复制 | 多数一致 | 中（等待多数集群确认） | 服务发现、元数据管理 |
实践建议：在压测沙盘环境中，建议先使用异步复制模型进行基准测试，再逐步切换为半同步或同步模型，以量化不同复制模型对吞吐量和延迟的影响。
跨数据中心复制的核心流程通常包含以下步骤：
- 本地写入：客户端向本地 etcd 集群发起写入请求，本地集群完成 Raft 提交。
- 变更捕获：联邦代理（Federation Proxy）通过 Watch API 或 gRPC 流捕获本地集群的键值变更事件。
- 事件转发：联邦代理将变更事件序列化为 protobuf 消息，通过跨数据中心网络发送到其他集群的联邦代理。
- 远程写入：目标集群的联邦代理将接收到的变更事件以 etcd 客户端身份写入本地集群。
- 冲突处理：若发生并发写入冲突，根据复制模型选择策略（如最后写入者胜出、版本号比较等）进行合并。
1.3 Federation vs 单集群对比
在选择使用单 etcd 集群还是 Federation 架构时，需要从多个维度进行权衡。下表从关键特性出发，对比两种架构的差异：
| 对比维度 | 单 etcd 集群 | etcd Federation |
|---|---|---|
| 故障域 | 单故障域（集群内节点故障可容忍） | 多故障域（每个集群独立，跨集群故障隔离） |
| 跨地域延迟 | 高（所有节点需跨地域通信参与 Raft） | 低（本地集群处理本地读写，跨地域仅同步变更） |
| 写入吞吐 | 受限于单集群 Raft 提交速率（通常 10K-50K ops） | 可线性扩展（每个集群独立处理写入，联邦层聚合） |
| 一致性模型 | 强一致（Raft 线性一致性） | 可配置（最终一致 / 强一致 / 多数一致） |
| 运维复杂度 | 低（单集群管理） | 高（多集群 + 联邦代理 + 网络策略） |
| 数据冲突风险 | 无（Raft 保证全局有序） | 有（并发写入需冲突解决策略） |
| 典型节点数 | 3 / 5 / 7 节点 | 每个集群 3 节点，联邦层 2-5 个集群 |
关键权衡：Federation 架构虽然提供了更好的跨地域可用性和扩展性，但引入了数据冲突、网络分区和运维复杂度。在压测沙盘环境中，建议先模拟单集群基准性能，再对比 Federation 模式下的吞吐衰减和延迟增加，从而量化架构切换的代价。