1. 课程导论：容量规划驱动服务目录平台多集群水位评估的背景、目标与整体架构概览

1.1 背景：从“被动扩容”到“主动水位治理”

在微服务与云原生架构大规模普及的今天，企业通常拥有数十乃至上百个 Kubernetes 集群，承载着成千上万个微服务实例。服务目录平台作为微服务的“注册中心”与“拓扑地图”，记录了每个服务的部署位置、副本数、资源规格与依赖关系。然而，随着业务高速增长，多集群环境下的容量管理面临三大核心痛点：

• 资源碎片化：不同集群的 CPU / 内存利用率差异巨大，部分集群过载触发 OOMKill，部分集群资源闲置率超过 40%。
• 水位盲区：缺乏统一的水位评估模型，运维团队只能依赖单一集群的“平均利用率”做决策，忽略了服务级 SLA 与突发流量特征。
• 扩缩容滞后：HPA 基于瞬时指标，无法预判未来 1-2 小时的容量瓶颈，导致大促或故障恢复期间频繁“拍脑袋”加机器。

本课程将围绕一个真实的工程案例——某头部电商平台的服务目录平台，展示如何通过容量规划方法论，构建多集群水位评估引擎，实现从“被动响应”到“主动治理”的转型。

1.2 目标：建立可量化、可预测、可自愈的水位评估体系

本案例工程的核心目标可拆解为以下四个维度：

1.3 整体架构概览：四层模型 + 闭环反馈

为了实现上述目标，我们设计了一套“四层模型 + 闭环反馈”的架构。该架构以服务目录平台为数据底座，向上构建容量规划引擎，向下驱动多集群水位评估与自动化执行。

1.4 核心组件与数据流

为了更清晰地展示各层之间的数据流转与关键组件，下图以“数据流”视角拆解了从原始指标采集到最终自动化执行的完整链路。

1.5 关键设计原则

在架构设计过程中，我们遵循了以下四条关键原则，确保系统在复杂多集群环境下的健壮性与可扩展性：

1. 数据驱动，模型可解释：所有水位评估结果必须能够回溯到具体的服务指标与容量模型，避免“黑盒”决策。
2. 分层解耦，独立演进：数据采集、容量规划、水位评估、自动化执行四层之间通过标准 API 交互，每层可独立升级与替换。
3. 预测优先，预防为主：容量规划引擎的输出优先于水位评估，强调“提前 2 小时”的预测能力，而非事后告警。
4. 闭环反馈，持续学习：自动化执行的结果（如扩容是否缓解了水位）会反馈回容量规划引擎，用于模型调优与策略修正。

1.6 课程路线图

本课程共 30 章，分为五个阶段，逐步深入：