技术深度解析
Firecracker 是一个用 Rust 编写的虚拟机监控器，利用 Linux 内核虚拟机（KVM）创建轻量级微虚拟机。其架构刻意保持最小化：仅实现启动 Linux 内核和运行单个应用程序进程所需的基本设备。这包括一个用于存储的 virtio-block 设备、一个用于网络的 virtio-net 设备、一个串行控制台和一个最小的 ACPI 表。没有 BIOS、UEFI、VGA 或传统设备模拟。
启动过程异常高效。Firecracker 将压缩的 Linux 内核镜像（通常为 5-10 MiB 的 vmlinux 二进制文件）直接加载到客户内存中，设置初始页表，然后跳转到入口点。通过使用自定义内核配置，剥离不必要的驱动程序、文件系统和功能，启动时间降至 125 毫秒以下。为了更快的冷启动，Firecracker 支持快照/恢复，其中预启动的微虚拟机状态保存到磁盘，并在 5 毫秒内恢复。
内存开销是另一个关键优化。每个微虚拟机预留固定数量的内存（客户机最低 128 MiB），但 VMM 本身使用的主机内存不到 5 MiB。这是通过避免任何每 VM 内存气球或超量分配实现的——Firecracker 直接使用 KVM 的硬件辅助内存虚拟化。结果是，一台 256 GiB 的主机可以同时运行超过 2,000 个微虚拟机，每个配备 128 MiB 内存。
性能基准测试
| 指标 | Firecracker (微虚拟机) | Docker (容器) | QEMU/KVM (完整虚拟机) |
|---|---|---|---|
| 冷启动时间 | 125 毫秒 | <10 毫秒 | 3-5 秒 |
| 每个实例的内存开销 | <5 MiB | <1 MiB | 50-100 MiB |
| 每台主机的最大实例数 (256 GiB) | ~2,000 | ~5,000 | ~50 |
| 安全隔离 | 硬件虚拟机 | 命名空间/cgroup | 硬件虚拟机 |
| 内核启动时间 | 100 毫秒 | 不适用 | 2-4 秒 |
数据要点： Firecracker 以略高于容器的冷启动时间换取了显著更强的安全隔离。其密度是传统虚拟机的 40 倍，使其成为无服务器平台的理想中间地带。
Firecracker 的代码库可在 GitHub 上的 `firecracker-microvm/firecracker` 获取。该仓库已累积超过 33,900 颗星和 2,500 个分支。该项目完全用 Rust 编写，提供内存安全而不依赖垃圾回收器——这对于安全敏感的 VMM 至关重要。代码是模块化的，包含 VMM 核心、API 服务器和 jailer（沙盒工具）的独立 crate。最近的提交集中在改进快照性能、添加对 ARM64 的支持，以及与基于 Rust 的 `vmm-reference` 管理程序集成。
关键参与者与案例研究
AWS 是 Firecracker 的主要开发者和用户。这项技术源于提高 AWS Lambda 密度和安全性的需求，Lambda 最初运行在带有完整虚拟机的 EC2 实例上。Firecracker 的首次生产部署是在 2018 年，现在它支撑着 Lambda 和 Fargate。AWS 尚未披露生产环境中 Firecracker 微虚拟机的确切数量，但 Lambda 每月处理数万亿次执行，这意味着每天有数百万个微虚拟机被创建和销毁。
除了 AWS，多家公司已将 Firecracker 用于自己的无服务器平台：
- Fly.io 使用 Firecracker 在边缘位置运行完整的 Linux 虚拟机，使开发者能够在靠近用户的地方部署应用程序，同时具有强大的隔离性。
- Koyeb 将其无服务器平台构建在 Firecracker 之上，强调亚秒级冷启动和全球部署。
- Ionos Cloud 提供由 Firecracker 驱动的无服务器容器服务。
- OpenFaaS 和 Knative 社区已尝试将 Firecracker 作为 containerd 的替代方案，用于安全函数执行。
竞争技术
| 解决方案 | 类型 | 启动时间 | 安全模型 | 主要用例 |
|---|---|---|---|---|
| Firecracker (AWS) | 微虚拟机 | 125 毫秒 | 硬件虚拟机 | 无服务器函数、Fargate |
| gVisor (Google) | 用户空间内核 | <10 毫秒 | 应用沙盒 | 容器安全 |
| Kata Containers | 轻量级虚拟机 | 1-2 秒 | 硬件虚拟机 | 安全容器 |
| Cloud Hypervisor | 轻量级 VMM | 200 毫秒 | 硬件虚拟机 | 云工作负载 |
| Amazon Nitro | 硬件卸载 | 3-5 秒 | 专用硬件 | EC2 实例 |
数据要点： Firecracker 最接近的竞争对手是 Kata Containers，它也使用 KVM，但启动链更重（包括完整的客户内核和初始化系统）。Firecracker 的优势在于其最小的设备模型和 Rust 实现，这减少了攻击面和启动时间。
行业影响与市场动态
Firecracker 催化了云基础设施设计的转变。传统的每租户一个虚拟机的模式正在让位于基于微虚拟机的多租户模式，其中数千个隔离的工作负载共享一台主机。这对云经济有直接影响：提供商可以在不牺牲安全性的情况下显著提高服务器利用率，从而降低最终用户的成本。
对于无服务器计算市场，Firecracker 使 AWS 能够提供 Lambda 和 Fargate 等服务，这些服务在安全性和性能方面优于基于容器的替代方案。虽然容器提供更快的启动时间，但它们缺乏硬件虚拟化的安全边界，使它们不适合多租户环境中的不可信代码。Firecracker 填补了这一空白，提供了两全其美的方案：容器的密度和速度，以及虚拟机的安全性。
展望未来，Firecracker 可能会在边缘计算中发挥关键作用，其中低延迟和强隔离至关重要。Fly.io 等公司已经在边缘部署中使用 Firecracker，并且随着 5G 和 IoT 的扩展，对轻量级、安全隔离的需求只会增长。此外，Firecracker 的 Rust 代码库使其成为未来安全关键型基础设施项目的有吸引力的基础。
然而，挑战依然存在。Firecracker 的生态系统仍然相对较小，与 Docker 和 Kubernetes 的集成需要额外的工作。虽然 Firecracker 支持快照/恢复以实现快速冷启动，但它缺乏容器编排工具（如 Kubernetes）的原生支持。社区正在努力解决这些限制，但广泛采用可能还需要时间。
总之，Firecracker 代表了云基础设施设计的一个转折点。通过证明微虚拟机可以像容器一样快速且密集，同时保持硬件虚拟化的安全性，AWS 为无服务器计算的新时代奠定了基础。随着云提供商继续优化其基础设施以实现多租户和边缘部署，Firecracker 的方法可能会成为行业标准。