Lambda 冷启动的本质与基于实测的优化策略
从 Firecracker MicroVM 的生命周期解析 Lambda 冷启动的发生机制，通过 SnapStart、Provisioned Concurrency、函数设计三个维度比较基于实测数据的优化方法。
冷启动为何发生
要正确优化 Lambda 冷启动，首先需要理解其发生机制。Lambda 在 Firecracker MicroVM 上执行函数。当新请求到达时，如果不存在可复用的执行环境，AWS 需要经历 MicroVM 启动、运行时初始化、函数代码下载和解压、处理程序外全局作用域执行等一系列过程，才能处理请求。这就是冷启动。冷启动的持续时间取决于运行时类型、部署包大小、初始化代码的复杂度和内存配置。
各运行时的冷启动特性
各运行时的冷启动特性是架构设计初期应考虑的要素。Node.js 和 Python 最为轻量，即使在 128MB 内存配置下冷启动也能控制在 200 至 400ms。Go 作为编译后的二进制运行，运行时初始化开销几乎为零，冷启动在 100 至 200ms，属最快级别。而 Java 由于 JVM 启动和类加载，冷启动通常在 3 至 10 秒，是最慢的运行时之一。.NET 也因 CLR 初始化而在 1 至 3 秒范围。
SnapStart - Java 冷启动问题的根本解决
2022 年 re:Invent 发布的 SnapStart 是 AWS 对 Java 运行时冷启动问题的解答。SnapStart 在函数部署时通过 Firecracker 的 UFFD（Userfaultfd）机制获取已初始化执行环境的快照，冷启动时从快照恢复执行环境。这将 Java 的冷启动从数秒缩短至数百毫秒。SnapStart 对使用 Spring Boot 等框架的应用特别有效，因为框架初始化占冷启动时间的大部分。
Provisioned Concurrency - 以成本换取确定性
Provisioned Concurrency 是预先维持指定数量执行环境为预热状态的功能。可完全消除冷启动，但即使空闲也会产生费用，因此成本设计很重要。Provisioned Concurrency 的费用按预置并发数乘以时间计算。例如，1024MB 内存的函数以 100 并发预置，月费约 460 美元。适用于 API Gateway 后端等 P99 延迟直接关系 SLA 的用例。Application Auto Scaling 可根据使用率自动调整预置并发数。
通过函数设计优化 - 开发者立即可做的事
即使不使用 SnapStart 或 Provisioned Concurrency，仅通过改进函数设计就能大幅缩短冷启动。效果最大的是减小包大小。Lambda 在冷启动时从 S3 下载并解压部署包，包越大初始化越慢。Node.js 可使用 esbuild 或 webpack 进行 tree-shaking 消除未使用代码。避免导入整个 AWS SDK v3 而仅导入所需客户端。Python 可使用 Lambda Layer 分离依赖。
三种优化方法的选型
冷启动优化的三种方法应根据用例选择。API Gateway 后端等 P99 延迟直接关系 SLA 的用例，Provisioned Concurrency 最为可靠。成本增加但是唯一能完全消除冷启动的方法。使用 Java 或 .NET 且冷启动超过 1 秒的情况，SnapStart 是最佳选择。零额外成本即可将冷启动缩短至数百毫秒。对于大多数工作负载，通过函数设计优化（减小包大小、延迟加载、增加内存）即可将冷启动控制在可接受范围内。