1. 课程导论：Serverless 平台控制面面临的 etcd 多租户挑战，为什么需要仲裁水位隔离策略
在 Serverless 架构中，控制面是集群的“大脑”，负责调度、资源分配、状态持久化与租户管理。etcd 作为云原生控制面的状态存储基石，其稳定性直接决定了 Serverless 平台的可用性。然而，当多个租户共享同一个 etcd 集群时，租户间的资源争抢与仲裁级联故障成为最棘手的挑战。
1.1 多租户场景下的 etcd 资源争抢模型
Serverless 平台通常将每个租户的工作负载、配置、元数据存储在 etcd 的不同 key 前缀下。这种逻辑隔离在物理上仍然是共享同一 etcd 集群的存储与网络带宽。当某个“吵闹邻居”租户产生大量写入请求或存储大量数据时，会直接挤压其他租户的可用资源。
| 资源维度 | 争抢表现 | 影响范围 |
|---|---|---|
| 存储容量 | 单个租户写入大量 key，导致 etcd 存储配额耗尽 | 全局写入被限速，所有租户 PUT 操作失败 |
| 请求吞吐 | 租户突发高 QPS 请求，打满 etcd 的请求队列 | 其他租户请求超时、重试，控制面响应延迟飙升 |
| 网络带宽 | 租户 watch 大量 key，产生频繁的事件推送 | gRPC 流阻塞，影响所有 watch 客户端的实时性 |
| 内存与 CPU | 租户数据量过大，导致 etcd 内存缓存膨胀 | 节点 OOM 风险增加，触发 leader 切换 |
关键洞察： 传统基于租户 ID 的 key 前缀隔离，只能实现逻辑上的数据分区，无法阻止物理资源的跨租户抢占。当资源争抢达到 etcd 的仲裁水位时，整个集群的读写能力都会受损。
1.2 仲裁水位：etcd 集群的“安全红线”
etcd 使用 Raft 共识算法，要求集群中超过半数的节点（仲裁）达成一致才能提交写入。当集群资源使用接近极限时，会出现以下连锁反应：
- 磁盘 I/O 饱和：WAL 写入延迟增加，心跳超时，触发 leader 选举。
- 选举风暴：频繁的 leader 切换导致集群进入“无主”状态，所有写入被阻塞。
- 仲裁丢失：如果多个节点因资源耗尽而失联，集群永久失去仲裁能力。
我们将 etcd 集群能够维持正常仲裁操作的最大资源使用阈值称为仲裁水位。一旦超过该水位，集群的可用性将急剧下降。
实践参考： 在生产环境中，建议将 etcd 的存储使用率控制在 70% 以下，请求延迟 P99 不超过 100ms，以避免触发仲裁水位风险。
1.3 为什么需要仲裁水位隔离策略
仲裁水位隔离策略的核心目标是：在共享 etcd 集群中，为每个租户划定独立的资源使用上限，确保任何单一租户的异常行为都不会将集群推过仲裁水位。该策略不是简单的配额限制，而是一套包含检测、限流、降级与快速恢复的完整机制。
以下是仲裁水位隔离策略需要解决的关键问题：
- 公平性：防止“吵闹邻居”租户抢占其他租户的可用资源。
- 可预测性：为每个租户提供稳定的性能基线，避免突发流量导致全局抖动。
- 故障域隔离：单个租户的故障（如数据膨胀、watch 风暴）不应扩散到其他租户。
- 运维简化：通过自动化的水位控制，减少人工干预和紧急扩容操作。
1.4 多租户仲裁水位隔离架构总览
下图展示了 Serverless 平台控制面中，仲裁水位隔离策略的整体架构与数据流：
注意： 仲裁水位隔离策略不是 etcd 内置功能，而是需要在 Serverless 控制面与 etcd 之间构建的中间层。本课程将深入讲解如何设计、实现与运维这一关键中间层。
1.5 本课程的核心内容预览
本课程将围绕仲裁水位隔离策略，系统性地讲解以下核心模块：
- 水位检测与度量：如何定义和采集 etcd 的多维度资源指标，建立租户级的水位模型。
- 租户级配额与限流：基于 bucket、sliding window 等算法，实现精细化的请求控制。
- 存储隔离与数据分片：通过 key 空间划分、租户级存储上限、watch 过滤等技术实现存储隔离。
- 自动降级与快速恢复：当租户触发水位阈值时，自动执行降级策略，并在恢复后快速回切。
- 生产环境运维实践：包括监控告警、容量规划、故障演练与性能调优。
通过本课程的学习，你将掌握构建高可用、多租户 Serverless 控制面的核心技能，能够有效应对 etcd 在规模化场景下的稳定性挑战。