3. 多集群 Federation 架构：控制平面、集群注册与发现、跨集群资源调度

在 etcd 压测沙盘中引入 Federation 架构，是为了解决单集群资源瓶颈与地域容灾问题。Federation 层作为统一的控制入口，将多个物理 etcd 集群抽象为一个逻辑集群，压测流量可以透明地分发到不同集群，同时每个集群仍保留独立的限流策略。

3.1 Federation 控制平面架构

Federation 控制平面是整个多集群调度的核心，它由三个关键组件构成：

3.2 集群注册与发现机制

成员集群必须通过注册流程加入 Federation，才能接收压测调度。注册与发现采用 心跳 + 租约 模式，确保控制平面始终持有最新的集群拓扑。

注册流程（4 步）

1. 集群代理部署： 在每个成员 etcd 集群侧部署 federation-agent，负责与控制平面通信。
2. 元数据上报： Agent 向 Federation API Server 发送集群标识、端点列表、当前限流阈值、容量水位。
3. 租约绑定： 控制平面为每个集群创建租约（TTL 默认 30s），Agent 需每 15s 续约。
4. 状态持久化： 注册成功的集群元数据写入 Cluster State Store，标记为 ACTIVE。

发现机制

• 主动拉取： Scheduler Engine 定期从 State Store 拉取全量集群列表，缓存本地。
• 事件推送： 当集群状态变更（加入/退出/限流触发），State Store 通过 Watch 机制推送增量事件。
• 故障摘除： 连续 3 次心跳超时的集群自动标记为 UNREACHABLE，不再接收新请求。

3.3 跨集群资源调度策略

跨集群调度的核心目标是在满足每个集群限流约束的前提下，最大化压测吞吐。调度策略分为三个层级：

调度决策示例

假设沙盘中有 3 个 etcd 集群，限流阈值分别为 5000 QPS、8000 QPS、3000 QPS。全局调度器按比例分配压测流量：

总压测目标：12000 QPS
集群 A 配额：12000 × (5000 / 16000) = 3750 QPS
集群 B 配额：12000 × (8000 / 16000) = 6000 QPS
集群 C 配额：12000 × (3000 / 16000) = 2250 QPS

当集群 B 触发限流（拒绝率 > 5%）时，调度器自动将超出的 500 QPS 转移到集群 A 和 C，直到集群 B 恢复。

3.4 限流策略在 Federation 中的传播路径

限流策略的配置与生效遵循 下发 → 缓存 → 执行 → 反馈 的闭环：

1. 策略下发： 运维人员通过 Federation API Server 配置全局限流策略（如：集群 A 最大 5000 QPS，集群 B 最大 8000 QPS）。
2. 本地缓存： 每个成员集群的 federation-agent 将策略缓存到本地内存，避免控制平面故障时策略丢失。
3. 网关执行： etcd 网关层根据本地缓存的限流阈值，对压测请求进行令牌桶或漏桶限流。
4. 状态上报： Agent 周期性上报当前限流拒绝率、实际吞吐量，供调度器调整配额。

3.5 沙盘中的 Federation 部署验证

在压测沙盘中，建议按以下步骤验证 Federation 架构的正确性：