1. 课程导论：多租户架构的挑战、故障域隔离的重要性、容量规划驱动的核心理念
1.1 多租户架构的核心挑战
在云原生与分布式系统实践中，多租户（Multi-Tenancy）架构已成为资源复用与成本优化的基石。然而，当多个租户共享同一套基础设施时，故障传播与资源争抢成为悬在SRE团队头顶的达摩克利斯之剑。以下表格总结了多租户场景下最突出的三大挑战：
| 挑战维度 | 典型表现 | 后果 |
|---|---|---|
| 故障爆炸半径 | 单节点宕机导致其上所有租户实例同时中断 | 影响面不可控，SLA大面积违约 |
| 资源噪声邻居 | 某租户突发流量抢占CPU/内存/IO，挤占其他租户 | 服务质量下降，尾延迟飙升 |
| 运维复杂度 | 租户数量增长后，人工打散、迁移、扩缩容效率极低 | 变更风险高，故障恢复慢 |
关键认知： 多租户不是简单的“一台机器跑多个应用”，而是要在共享与隔离之间找到精确的平衡点。没有隔离的共享是灾难，没有效率的隔离是浪费。
1.2 故障域隔离：为什么是必选项？
故障域（Failure Domain）是指系统中一旦发生故障就会同时影响的一组组件。在多租户架构中，故障域隔离意味着将不同租户的实例部署到相互独立的故障域中，使得一个域的失效不会波及其他域。其核心价值体现在：
- 爆炸半径控制： 将单点故障的影响范围从“全集群”缩小到“单个故障域”。
- SLA保障： 高优先级租户可以独占或优先占用更可靠的故障域组合。
- 滚动升级与容灾： 故障域天然成为蓝绿部署、灰度发布和跨可用区容灾的基本单元。
下图展示了未隔离与隔离后的故障影响对比：
实践建议： 在Kubernetes环境中，故障域通常对应节点、机架、可用区（AZ）三个层级。设计租户调度策略时，应至少保证同一租户的主备实例分布在不同的节点和可用区。
1.3 容量规划驱动的核心理念
传统的故障域隔离往往依赖静态配置或人工经验，缺乏对集群整体容量和租户资源需求的全局感知。本课程提出的容量规划驱动（Capacity Planning Driven）理念，核心在于将容量预测与调度决策闭环联动，实现故障域隔离的自动化和最优化。
其核心理念包含三个层次：
- 预测性容量视图： 基于历史指标和租户SLA，预测未来时间窗口内每个故障域的剩余容量和压力水位。
- 隔离策略的容量约束： 租户重调度时，不仅考虑故障域分散，还必须满足目标节点的CPU、内存、网络带宽等容量约束，避免“为了隔离而超卖”。
- 动态重调度闭环： 当节点宕机或容量预警触发时，系统自动计算最优的租户迁移方案，在保障隔离的前提下最小化迁移代价。
下图展示了容量规划驱动的故障域隔离整体架构：
常见误区： 不要将容量规划与故障域隔离视为两个独立流程。没有容量约束的隔离会导致资源碎片化或超卖；没有隔离意识的容量规划则无法保障租户SLA。二者必须融合。
1.4 课程目标与学习路径
通过本课程，你将掌握以下核心能力：
- 设计能力： 构建多租户故障域模型，定义租户隔离等级与容量约束。
- 调度能力： 实现基于容量预测的租户重调度算法，处理节点宕机、扩容、缩容等场景。
- 工程能力： 在Kubernetes或自研调度系统中落地容量规划驱动的隔离策略。
- 运维能力： 建立故障域健康度与容量水位的监控告警体系。
接下来的章节将从故障域建模、容量预测算法、重调度策略设计、系统实现与案例复盘五个模块展开，逐步深入。