3. Serverless 架构特点：弹性伸缩、按量计费、冷启动对 SLO 的影响
Serverless 架构将基础设施的运维复杂性抽象化，使开发者能够专注于业务代码。然而，这种“无服务器”的体验背后，其核心特性——弹性伸缩、按量计费与冷启动——对容量 SLO 和错误预算的消耗方式与传统架构截然不同。理解这些差异，是构建可靠 HPA 面板的前提。
3.1 三大核心特性对比
| 特性 | 传统虚拟机/容器 | Serverless (FaaS) | 对 SLO 的影响 |
|---|---|---|---|
| 弹性伸缩 | 分钟级扩容，需预留缓冲 | 秒级至毫秒级，从零开始 | 扩容速度决定突发流量下的错误预算消耗速率 |
| 按量计费 | 按资源包年/包月，闲置付费 | 按请求次数与执行时长计费 | 成本与请求量强相关，错误请求同样产生费用 |
| 冷启动 | 实例常驻，无启动延迟 | 首次调用或闲置后需初始化运行时 | 增加尾部延迟，直接推高 SLO 中的延迟错误率 |
3.2 弹性伸缩：从零到无限的“假象”
Serverless 平台宣称“自动从零扩展到无限”，但在实际生产环境中，这种伸缩存在物理上限和延迟窗口。HPA 面板需要关注以下两个关键阶段：
- 扩容阶段（Scale-Out）：当请求并发激增，平台需要创建新的函数实例。这个过程通常需要 200ms-2s，期间新请求可能被排队或直接丢弃，导致 5xx 错误。
- 缩容阶段（Scale-In）：流量下降后，平台会回收空闲实例。如果缩容策略过于激进，可能导致下一波小流量触发冷启动。
SRE 提示： 在 HPA 面板中，应同时监控 并发实例数 与 扩容等待队列长度。当队列长度持续 > 0 且实例数未达到平台并发上限时，说明扩容速度已无法匹配流量增速，错误预算正在快速消耗。
3.3 按量计费：成本与 SLO 的耦合
在 Serverless 模型中，每一次函数调用（无论成功或失败）都会产生费用。这意味着：
- 错误请求也在消耗预算：一个返回 500 错误的请求，同样会占用执行时长和内存，产生账单。
- 重试风暴放大成本：当上游服务或客户端未正确处理超时，可能发起大量重试，导致函数实例数暴增，同时推高错误率和成本。
避坑指南： 不要仅根据“请求总数”来评估成本。在 HPA 面板中，应增加 错误请求成本估算 视图，公式为：
错误请求数 × 平均执行时长 × 单价。这有助于在错误预算消耗过快时，快速判断是流量增长还是错误率恶化。
3.4 冷启动：尾部延迟的隐形杀手
冷启动是 Serverless 架构对 SLO 影响最隐蔽的因素。它发生在函数实例首次创建或从闲置状态恢复时，需要完成以下步骤：
- 下载代码包：从对象存储拉取函数代码（通常 50-500ms）。
- 启动运行时：初始化 Node.js、Python、Java 等虚拟机（通常 200ms-2s）。
- 执行初始化代码：运行全局变量、数据库连接池等初始化逻辑（通常 100ms-5s）。
冷启动对 SLO 的影响主要体现在 P99（99 分位）延迟 上。一个常规请求可能只需 50ms，但冷启动请求可能高达 3s，直接导致 P99 延迟突破 SLO 阈值。
3.5 冷启动对错误预算的量化影响
假设一个 Serverless 函数的 SLO 为：99.9% 的请求延迟 < 1s。如果冷启动率为 5%，且冷启动平均延迟为 2s：
- 热启动请求（95%）：延迟 50ms，全部满足 SLO。
- 冷启动请求（5%）：延迟 2s，全部违反 SLO。
- 整体 SLO 达成率：95% × 100% + 5% × 0% = 95%，远低于 99.9% 的目标。
结论： 即使只有 5% 的冷启动率，也足以将整体 SLO 从 99.9% 拉低到 95%。在 HPA 面板中，必须将 冷启动率 作为核心指标，并与错误预算消耗速率关联展示。
3.6 本章小结
| 特性 | HPA 面板关键指标 | 对错误预算的影响 |
|---|---|---|
| 弹性伸缩 | 扩容延迟、实例数、队列长度 | 扩容滞后直接导致 5xx 错误，快速消耗预算 |
| 按量计费 | 错误请求成本、重试率 | 错误请求产生额外成本，重试风暴放大消耗 |
| 冷启动 | 冷启动率、P99 延迟、初始化时长 | 显著推高尾部延迟，导致延迟类 SLO 违约 |