14 - 冷启动、伸缩、计费：Serverless 的脾气
Serverless 很香，但它不是万能的。要用好它，得摸清它的”脾气”——尤其是冷启动、伸缩和计费这三件事。这一章帮你避坑，也让你知道什么场景不适合它。
脾气一：冷启动（第一次请求会慢）
回顾第 12 章：没请求时，Serverless 可能一个实例都不开（省钱）。那么当第一个请求来时，平台要临时启动一个实例——拉镜像、起容器、初始化你的应用。这个过程要花一点时间（几百毫秒到几秒），这就叫冷启动。
- 冷启动：实例从零启动，第一个请求要等它准备好，慢
- 热启动：实例已经开着，后续请求直接处理，快
类比：冷启动像便利店早上开门前要先开灯、上货、开机器；第一个顾客得等一下。等店开起来了，后面的顾客就顺畅了。
影响：偶尔的第一个请求会慢一点。对大多数应用可接受；但如果你的场景对”每一个请求都必须极快响应”很敏感，就要注意。
缓解办法：
- 把镜像做小一点（启动快）——参考 Docker 系列的镜像瘦身技巧
- 开启平台的预留实例 / 预热（保持少量实例常驻，代价是这部分要一直付费）
脾气二：自动伸缩（省心，但要理解并发）
流量大，平台自动多开实例；流量小，自动缩回。这是优点，但要理解两点：
- 无状态是前提：平台随时可能开新实例、关旧实例。所以你的后端不能把数据存在自己内存/本地磁盘里（存了，换个实例就丢了）。数据必须放外部（云数据库）。这就是第 18 章要讲的”无状态思维”。
- 突发扩容也有上限：平台不是无限扩，通常有并发上限，可按需调整/申请。
脾气三：计费（省钱，但要看清计费项）
Serverless 按用量计费，通常按这几项：
- 请求次数
- 运行时长 × 内存规格（跑了多久、占了多少内存）
- 可能还有流量费
优点很明显：没人访问几乎不花钱，非常适合起步项目。但也要注意：
- 如果被恶意刷请求，费用会涨——记得配限流 / 用量告警
- 高频、持续满负载的场景，按量算下来可能比包一台服务器还贵（见下面适用边界）
脾气四：执行时长限制（别拿它跑长任务）
很多 Serverless（尤其函数计算）对单次请求最长执行时间有限制（比如几十秒到几分钟）。所以：
- 适合：快速返回的 API 请求
- 不适合：一个请求里跑几十分钟的大任务（比如超长视频处理、大批量训练）
长任务的正确姿势：接口先快速返回”任务已提交”，把重活丢给异步任务/消息队列在后台慢慢做（参考消息队列入门）。
什么时候适合 / 不适合 Serverless
| 适合 ✅ | 不太适合 ❌ |
|---|---|
| 中小项目、创业项目、AI 应用 | 7×24 满负载的超大流量服务（可能更贵） |
| 流量不稳定、有明显高峰低谷 | 对每个请求延迟都极度敏感（受冷启动影响） |
| 团队小、没专职运维 | 单请求需要长时间运行（超过时长限制） |
| 想省钱、想少操心 | 需要在本机长期保存状态的场景 |
结论：对本教程面向的”前端 + 后端 + AI 中小项目”，Serverless 几乎是最优解。等你真长成超大规模、稳定高负载，再考虑换方案不迟。
小结
- 冷启动：首个请求要临时启动实例，会慢一点；可用小镜像 / 预留实例缓解。
- 自动伸缩：省心，但前提是后端无状态，数据要外置。
- 计费：按量付费，低流量极省钱；但要防刷、配告警，超大流量可能反而贵。
- 时长限制：别用它跑长任务，长任务交给异步队列。
- 摸清脾气后，Serverless 对中小 / AI 项目是绝佳选择。
理论齐了，下一章我们动手把一个 FastAPI 打成 Docker、部署到 Serverless，把后端这条支线跑通。
下一章 → 15 - 实战：把 FastAPI 打成 Docker 部署到 Serverless