2. Serverless 基础：FaaS 与 BaaS 概念、事件驱动模型、无服务器计算的优势与挑战
在深入容量规划与自动扩缩容之前，必须建立对 Serverless 计算模型的准确理解。Serverless 并非“没有服务器”，而是将服务器的管理、容量规划、故障恢复等底层运维责任完全抽象，交给云平台。开发者只需关注业务代码与数据。本章将拆解其核心构成：FaaS、BaaS、事件驱动模型，并客观分析其优势与挑战。
2.1 FaaS 与 BaaS：Serverless 的两大支柱
Serverless 架构由两个核心服务类别组成：函数即服务（FaaS）和后端即服务（BaaS）。二者共同实现了“无服务器”的体验。
| 维度 | FaaS（函数即服务） | BaaS（后端即服务） |
|---|---|---|
| 核心单元 | 函数（Function）：一段无状态、短生命周期的代码 | 托管服务：数据库、对象存储、认证、消息队列等 |
| 运行模式 | 事件触发、按需执行、自动扩缩 | 始终在线、按量计费或预留容量 |
| 开发者关注点 | 业务逻辑、函数编排、依赖管理 | 数据模型、访问控制、服务集成 |
| 典型产品 | AWS Lambda、阿里云函数计算、Azure Functions | Amazon DynamoDB、阿里云 OSS、Firebase Auth |
| 计费粒度 | 调用次数 + 执行时长（毫秒级） | 存储量、请求次数、出网流量 |
关键理解： FaaS 是计算层，BaaS 是数据与基础设施层。在容量规划中，FaaS 的扩缩容由平台自动完成，而 BaaS 的容量（如数据库连接数、存储吞吐）往往需要提前规划或配置自动扩展策略。
2.2 事件驱动模型：Serverless 的“触发器”
FaaS 函数不会主动运行，它由事件触发。事件驱动模型是 Serverless 架构的“心脏”。理解事件源、触发器与函数的关系，是设计可扩缩系统的前提。
下图展示了典型的事件驱动流程：
容量规划启示： 事件源的类型和流量模式直接决定了 FaaS 函数的扩缩容行为。例如，来自消息队列的事件可以控制消费速率（背压），而来自 HTTP 网关的事件则可能产生突发流量，需要平台具备极快的冷启动和横向扩展能力。
2.3 无服务器计算的优势
从容量规划专家的视角看，Serverless 带来的核心优势集中在运维效率与资源利用率上。
- 零容量规划： 平台根据请求量自动分配资源，无需预置服务器或担心峰值容量不足。这是传统架构与 Serverless 最本质的区别。
- 精细化的按需付费： 只对实际执行的计算资源（CPU、内存）和调用次数付费。空闲时段成本趋近于零，消除了传统预留资源的浪费。
- 近乎无限的弹性： 平台可以瞬间从 0 扩展到数千甚至数万个并发执行实例，适合流量波动极大的业务（如电商大促、视频转码）。
- 降低运维复杂度： 补丁、操作系统升级、硬件故障均由云平台负责，团队可专注于业务代码。
2.4 无服务器计算的挑战
优势显著，但挑战同样不容忽视。在制定容量规划策略时，必须正视这些限制。
| 挑战领域 | 具体表现 | 对容量规划的影响 |
|---|---|---|
| 冷启动延迟 | 函数实例首次启动或长时间空闲后重新启动，需要加载运行时和代码，产生额外延迟（数百毫秒至数秒）。 | 需要规划预热策略（如定时触发器保持实例“热”），或接受冷启动带来的尾部延迟。 |
| 执行时长与资源限制 | FaaS 函数通常有最大执行超时（如 15 分钟）和内存上限（如 10GB）。 | 长任务或内存密集型任务不适合直接使用 FaaS，需拆解为异步工作流或迁移至容器。 |
| 无状态约束 | 函数实例不保留本地状态，所有状态必须外部化到 BaaS 服务（如 Redis、数据库）。 | 每次调用都需建立外部连接，增加了延迟和 BaaS 服务的吞吐压力，需规划连接池和缓存。 |
| 调试与可观测性 | 分布式追踪困难，无法 SSH 登录实例，日志分散。 | 需要强大的可观测性基础设施（如链路追踪、结构化日志），否则容量瓶颈难以定位。 |
| 供应商锁定 | FaaS 接口、BaaS 服务、事件源均与特定云厂商深度绑定。 | 跨云迁移成本高，容量规划工具和策略可能无法复用。 |
容量规划避坑： 不要因为 Serverless 宣称“自动扩缩”就完全放弃规划。你需要规划的是：
1. BaaS 服务的并发上限（如数据库连接数、API 限流）。
2. 函数的内存配置（影响执行速度和成本）。
3. 预留并发额度（避免冷启动和节流 Throttling）。
1. BaaS 服务的并发上限（如数据库连接数、API 限流）。
2. 函数的内存配置（影响执行速度和成本）。
3. 预留并发额度（避免冷启动和节流 Throttling）。