1. 课程导论：Serverless与容量规划的关系、自动扩缩容的核心价值、课程目标与学习路径
1.1 为什么Serverless需要容量规划？
传统认知中，Serverless 架构的“免运维”特性常被误解为“无需容量规划”。实际上，Serverless 只是将容量管理的责任从基础设施层转移到了集群与资源调度层。无论是基于 Kubernetes 的 Knative、OpenWhisk，还是云厂商的托管 Serverless 平台，底层都依赖一组计算节点（EC2、ECI、Fargate 等）来承载函数实例。
容量规划在 Serverless 场景下的核心矛盾在于：用户负载的突发性与节点池资源供给的滞后性。如果节点池预留过多，会产生闲置成本；预留过少，则导致冷启动加剧、请求超时甚至拒绝服务。
关键认知： Serverless 的“自动扩缩容”并非无中生有，而是基于容量规划模型对节点池进行动态调整。没有容量规划的自动扩缩容，就像没有导航的自动驾驶——可能很快，但方向未必正确。
1.2 Serverless 自动扩缩容的核心价值
自动扩缩容（Auto Scaling）是 Serverless 平台兑现“按需付费、弹性伸缩”承诺的关键机制。其核心价值体现在三个维度：
| 维度 | 传统架构痛点 | Serverless 自动扩缩容价值 |
|---|---|---|
| 成本 | 需预留峰值容量，日常利用率低（通常 10%~30%） | 节点数随负载动态变化，低谷期缩容至零，成本与真实请求量线性相关 |
| 性能 | 扩容依赖人工干预或简单阈值，响应滞后（分钟级） | 基于容量规划模型提前预测，实现秒级扩容，减少冷启动与排队延迟 |
| 运维 | 需要专人持续监控集群水位、调整资源规格 | 容量规划策略自动化执行，运维人员从“消防员”转变为“策略制定者” |
实践观察： 在大型电商促销场景中，未做容量规划的 Serverless 集群在流量突增时，冷启动率从 2% 飙升至 35%，平均响应时间从 50ms 恶化到 1.2s。而引入容量规划驱动的扩缩容后，冷启动率稳定在 5% 以内，响应时间波动不超过 20%。
1.3 容量规划与自动扩缩容的关系模型
为了直观理解两者关系，下图展示了容量规划在 Serverless 自动扩缩容闭环中的位置：
1.4 课程目标
完成本课程后，你将具备以下能力：
- 理解容量规划原理 — 掌握 Serverless 场景下容量规划的核心指标（QPS、并发数、Pod 密度、冷启动率）与预测模型（时间序列、排队论、机器学习）。
- 设计扩缩容策略 — 能够根据业务特征选择或组合 HPA（水平 Pod 自动伸缩）、VPA（垂直 Pod 自动伸缩）、KEDA（基于事件驱动自动伸缩）等机制。
- 实现容量规划驱动闭环 — 搭建从指标采集、容量预测到扩缩容执行的自动化流水线。
- 优化成本与性能 — 在保证 SLO（服务等级目标）的前提下，将节点资源利用率提升至 50%~70%，同时将扩缩容延迟控制在 10 秒以内。
1.5 学习路径与章节地图
本课程共 30 章，分为四个阶段，循序渐进地构建容量规划驱动的自动扩缩容体系：
| 阶段 | 章节范围 | 核心内容 | 实践产出 |
|---|---|---|---|
| 基础篇 | 第 1~8 章 | Serverless 架构原理、Kubernetes 节点管理、容器调度、冷启动分析 | 搭建最小 Serverless 集群（Knative + K8s） |
| 容量规划篇 | 第 9~16 章 | 指标体系设计、预测算法（ARIMA、Prophet）、容量模型构建 | 实现基于历史数据的容量预测服务 |
| 扩缩容实战篇 | 第 17~25 章 | HPA/VPA/KEDA 配置、自定义指标适配、节点池自动伸缩（Cluster Autoscaler） | 完成容量规划驱动的自动扩缩容流水线 |
| 进阶与优化篇 | 第 26~30 章 | 多集群扩缩容、成本优化策略、混沌工程验证、生产级最佳实践 | 输出容量规划运维手册与故障演练报告 |
下图展示了四个阶段之间的依赖关系与学习主线：
前置要求： 本课程假设你已具备基础的 Kubernetes 操作经验（Pod、Deployment、Service 概念），了解 Docker 容器化原理。如果你对 K8s 完全陌生，建议先花 2~3 天完成官方入门教程，再开始本课程的基础篇。
1.6 本章小结
本章明确了容量规划在 Serverless 自动扩缩容中的核心驱动地位，阐述了自动扩缩容在成本、性能、运维三个维度的核心价值，并通过闭环模型展示了从负载输入到节点调整的完整链路。最后，课程目标与四阶段学习路径为后续 29 章的学习提供了清晰的导航图。