冷启动到底是个啥？为什么它让开发者头疼？
实际操作要点
Serverless FaaS看似简单，真正落地时却很容易踩坑。在云原生时代，Serverless 已经被很多团队当成默认选项。你不需要操心服务器、不需要规划容量，把一段代码上传到 AWS Lambda 就能跑。但这背后隐藏着一个非常实际的痛点——冷启动。
所谓冷启动，就是当第一个请求到达时，Lambda 服务需要从头开始：拉起一个新的执行环境、加载你的代码、初始化运行时和依赖包，然后才真正执行函数。这个过程通常需要几百毫秒到几秒不等，取决于代码大小、运行时类型和初始化逻辑。对于用户来说，就是“卡了一下”。
你可能会问：为什么不能一直让函数保持“热”的状态？因为 Serverless 的计费模型是按调用次数和运行时间收费，闲置时不会产生费用，所以平台默认会在函数空闲一段时间后回收资源。这很合理，但也导致了冷启动成为 Serverless 的“原罪”。
Provisioned Concurrency 是什么？一份“提前买好”的执行环境——Serverless FaaS
故障定位思路
AWS 在 2019 年 re:Invent 上推出了 Provisioned Concurrency（预置并发），直接瞄准冷启动问题。它的核心理念很简单：既然冷启动是因为执行环境没有被事先准备好，那我们就提前创建一定数量的环境，让它们一直保持“待命”状态，随时处理请求。
形象点说，普通 Lambda 就像一个外卖骑手，接单后才去餐厅取餐；而 Provisioned Concurrency 相当于让一批骑手提前 5 分钟就站在出餐窗口，订单一下来就能立刻出发。你只需要为这些“待命”的骑手支付一部分等待费用，但换来了响应时间的确定性。
在 AWS 控制台里，你可以为某个函数版本（或者别名）设定一个预置并发数量，比如 10 个或 100 个。Lambda 服务会确保至少有这么多执行实例处于“预热”状态。当实际并发超过这个数值时，超出的部分仍然会经历冷启动，所以预置并发不是无限解决冷启动，而是控制峰值延迟。
相关阅读：此处可内链到“Serverless FaaS常见问题”专题。
Provisioned Concurrency 的工作机制（小白也能懂）
容易忽略的细节
要真正理解它的原理，得先了解 Lambda 实例的生命周期。一个常规 Lambda 函数从冷到热分三个阶段：
- Download：下载你的代码（通常从 S3 读取）。
- Extract & Initialize：解压代码、初始化运行时（比如 Node.js、Python、Java）。
- Handler Run：执行你的业务代码。前两步就是冷启动的“重灾区”。
当启用了 Provisioned Concurrency 后，Lambda 服务会主动执行前两步，让执行环境停留在 Handler 调用之前的就绪状态，并且一直保持活跃。这个过程是异步的，由 AWS 内部调度。你不需要关心它什么时候创建、什么时候销毁，只需要设置好数量。
这里有一个关键细节：Provisioned Concurrency 绑定的是函数的某个特定版本或别名。如果你更新了代码并发布新版本，旧的预置并发实例会逐渐被新版本替代。这个替换过程是平滑的，旧实例在处理完当前请求后才会销毁。
另外，Provisioned Concurrency 会与弹性伸缩自动协同。简单说，你设置的预置并发是“最低保障”，如果实际请求量超过这个数，Lambda 会动态创建新的普通实例（冷启动），直到满足需求或达到账户并发上限。所以它不限制你的弹性，只是保证一部分流量零冷启动。
怎样配置？简单三步走（附命令参考）
配置前的检查
配置 Provisioned Concurrency 有两条路：控制台点击或者用 AWS CLI。下面以 CLI 为例，看懂逻辑即可：
- 发布函数版本（如果你还没有版本号）
aws lambda publish-version --function-name my-function - 为特定版本配置预置并发
aws lambda put-provisioned-concurrency-config --function-name my-function --qualifier 1 --provisioned-concurrent-executions 10
这里的1是版本号，10是预置实例数。 - 检查状态
aws lambda get-provisioned-concurrency-config --function-name my-function --qualifier 1
返回的状态字段Status会显示READY表示实例已就绪，可以开始接收请求。
控制台操作更直观：进入 Lambda 函数页面 → 选择“版本”或“别名” → 找到“预置并发”选项 → 输入数量并保存。30 秒到 1 分钟内，你就能看到实例状态变成“就绪”。
Serverless FaaS：最佳实践：什么时候用？什么时候别碰？
Provisioned Concurrency 不是免费的，需要为预置的实例按“活跃时间”付费（通常按秒计费，价格也比普通请求稍高）。所以合理使用很重要：
推荐的场景
- 用户交互类 API：比如网站后端、手机应用接口，一旦延迟超过 1 秒用户就会感知到。用预置并发保证首次响应在 100ms 内。
- 同步执行的业务：比如支付、下单这种不能出现长时间等待的核心流程。
- 游戏、实时协作应用：对延迟极度敏感。
- 定时任务中的关键节点：如果某个定时函数负责触发后续步骤，冷启动可能导致整个链路超时。
不建议用的情况
- 异步任务、批量处理：比如日志清洗、视频转码，用户不直接等待结果，冷启动影响可以接受。
- 流量波动极小或完全不可预测：如果函数每分钟只有几次调用，预置并发等于白花钱。
- 测试阶段或非生产环境：先用普通 Lambda 跑，确认业务对延迟的容忍度后再决定。
关联教程：此处可内链到“Serverless FaaS部署与验证”内容。
避坑指南：四个常见误区
容易忽略的细节
误区一：预置并发 = 永远没有冷启动
事实上，如果突发流量超过预置实例数，超出的请求仍然冷启动。你需要结合应用负载预测来设置合理的数量，或者配合 Application Auto Scaling 动态调整预置并发。
误区二：预置并发越多越好
每个预置实例都会产生费用，而且需要提前“占用”账户区域性并发配额。比如你的账户额度是 1000，预置 800 个，那么普通实例最多只能再创建 200 个，反而限制了弹性。建议根据峰值顺时并发量来设置，预留 20%-30% 的弹性空间。
误区三：预置并发能加速初始化外的代码逻辑
它只解决环境初始化带来的冷启动，如果你函数本身有很慢的数据库连接、远程 API 调用，这些该优化还得优化。
误区四：设置完就万事大吉，不需要监控
通过 CloudWatch Metrics 可以查看预置并发实例的状态（ProvisionedConcurrencySpilloverCount 表示超过预置并发后回退到普通实例的请求数），这个指标能帮你判断预置数量是否合理。
想继续深入：此处可内链到“Serverless FaaS优化清单”文章。
总结：让冷启动变成可选的“小麻烦”
验证与回滚
Serverless 的初衷是让开发者关注业务逻辑而非基础设施。冷启动曾是这个承诺里最刺眼的裂缝。Provisioned Concurrency 把选择权交回给你：你可以为关键路径花一点成本买确定性，为非关键路径继续享受弹性带来的经济性。
理解它的原理不是为了炫技，而是帮你做更理性的架构决策。下次团队里再争论“要不要上 Lambda”时，至少你可以说：冷启动问题，我们有预置并发这个方案。真正做好Serverless FaaS，靠的不是参数堆砌，而是持续验证。
延伸阅读