Serverless Computing，即”無服務器計算”，這一概念在剛剛提出的時候并沒有獲得太多的關注，直到2014年AWS Lambda這一里程碑式的產品出現。通過將無服務器計算的概念嵌入到整個云計算服務的整體產品框架中，無服務器計算正式走進了云計算的舞臺。2017年，AWS發布了Fargate產品以充實自己的無服務器計算產品線。

今年5月，Google在KubeCon+CloudNative 2018期間開源了gVisor容器沙箱運行時并分享了它的設計理念和原則。隨后，今年7月，Google在舊金山舉辦了2018年度Google Next大會，在這次大會上，Google推出了自己的 Google Serverless Platform。針對App Engine，最重要的更新就是低層的沙箱技術采用了gVisor。當然，我們有足夠的理由相信Google指的是gVisor的內部實現版本。

今年的re:Invent 2018上，AWS點（kai）燃（yuan）了Firecracker —— AWS容器安全沙箱的基礎組件，用于函數計算服務AWS Lambda和托管的容器服務AWS Fargate[1][7]。

圖1 Firecracker microVM

Firecracker利用了Linux KVM來構建專門用于容器的微虛擬機，即Firecracker microVM。并力圖提供一種針對容器的，同時滿足了安全隔離、性能穩定、高資源利用率的方案。AWS的首席“傳教士”Jeff Barr稱它：即提供了傳統虛擬機對業務負載的安全與隔離特性，也帶來了像使用容器一樣高效的資源利用率。

Firecracker派生自Crosvm[2] —— 用Rust編寫的、開源的、用于Chromium OS的Virtual Machine Monitor。基于Crosvm，AWS于2017年10月開始了Firecracker的研發。但與Crosvm的目標不同，Firecracker聚焦于Serverless，即：專為無服務器計算場景提供安全高效的運行時。近些年，系統安全越發受到重視，Rust語言也變的越來越流行。Firecracker可能也是Rust語言在生產環境中部署的，規模最大的系統軟件。

Firecracker目前還沒有實現與Docker及Kubernetes對接。但是AWS同時開源了一個對接containerd的原型[9]，并表示未來一定會和Kubernetes兼容。

根據AWS的說法，Firecracker微虛機可以在每個主機上以每秒150個實例的速率，在125ms內啟動。并宣稱VMM組件的內存開銷小于5MiB（注：不包括客戶內存，vCPU線程占用的內存，和控制平面上API Server線程占用的內存）。因此，可以在一臺服務器上部署成百上千個微虛機。

2. AWS Lambda的演進與Firecracker的誕生

Firecracker目前已經用在AWS無服務器計算業務中，包括AWS Lambda和AWS Fargate。AWS認為，使用無服務器計算服務的用戶負載的典型特點是“生命周期短”，而Firecracker專為這種場景打造。讓我們看一下，Firecracker是如何支撐AWS Lambda的。

Firecracker誕生的內因是AWS Lambda的演進，而要了解Lambda的演進，就需要看一下Lambda對用戶請求的執行過程和執行環境。如下圖所示，用戶請求通過“ALB”轉發給“Front End”，“Front End”請求“Worker Manager”，“Worker Manager”初始化“Worker”，“Worker”準備函數沙箱執行環境，完成后，將狀態原路返回給“Front End”，然后由“Front End”觸發函數執行。

圖2 AWS Lambda 執行過程

用戶函數運行在“Lambda Runtime”中，在其之下是沙箱。與Linux中跑容器時常用的套路一樣，使用了cgroups，namespaces，seccomp，iptables，和chroot等一些列工具以實現操作系統層級上的虛擬化（也稱為“容器化”）[11]。再往下一層，是實現安全隔離的重點，即虛擬化技術與設備模擬。全棧如下圖所示：

圖3 AWS Lambda 執行環境

當AWS剛開始打造Lambda服務時，它始于在一個EC2實例中構建每一個“Worker”。原因很直接：

很好的安全邊界；

快速構建好整個系統使業務上線；

這種方式今天依然在使用，并且運行在Nitro平臺上面。

圖4 基于EC2實例的AWS Lambda

通過AWS Lambda長期以來的生產實踐和客戶的需求反饋，AWS意識到，基于EC2實例的Lambda并不適合今天的無服務器計算場景。并總結出無服務器計算的典型特征應該是：“啟動快，密度高，水平擴展”。但要達到以上這三個點，不能損失一點安全性。基于這些因素，AWS決定對Lambda進行改進，并在此過程中開發了Firecracker微虛機。由此，AWS Lambda有了另一種跑在微虛機中的“Worker”。

圖5 基于Firecracker的AWS Lambda

為了進一步加固安全隔離，AWS在微虛機外面又套了一層沙箱（使用運行容器時常用的工具）。由此可見，安全隔離是對外提供服務的基本前提。

當啟動變快，內存開銷變低時，實例部署密度也自然有了更大的提升空間。但實際上，實例部署密度不僅與CPU、內存相關，還涉及到與業務相關的一整套資源，比如：ENI網卡，IP地址資源等。隨著部署密度從一百提升到一千甚至更高的時候，相關資源的供給及使用的問題隨之而來。

當Lambda創建和啟動一個函數服務時，它需要經歷在用戶VPC網絡中創建EC2 ENI網卡，并將該網卡添加給“Worker”。這個添加網卡的過程比較費時，并且每個ENI網卡需要在用戶子網中消耗一個IP地址。有些情況下，這種模型還不錯，簡單并且支持VPC的所有特性。但最大的弊端，也是特別被某些用戶所詬病的，就是等待VPC啟動所耗費的時間過長。因此，AWS將ENI從“Worker”中移出，在“Worker”與ENI之間做了NAT，在多個不同的“Worker”間復用同一個ENI。本質上，這意味著在多個租戶間復用數量有限的ENI網卡。這樣改進后，帶來的直接好就是可預期的VPC啟動延時，快速的水平伸縮，低服務延時，和高易用性。

3. Firecracker的設計

3.1 內部架構

Firecracker微虛機的創建用到兩個組件，Jailer和Firecracker，前者負責利用Linux提供的seccomp、cgroup、chroot、net/pid/user namespaces來創建沙箱環境，然后在其創建的沙箱環境中啟動后者。后者利用Linux KVM創建設備模型極度精簡的微虛擬機。結構如下：

6 firecracker結構框圖

一個Firecracker進程就是一個微虛擬機，其內部主要有三個組件：

API Server

API Server以Unix domain socket的方式對主機提供了一個API endpoint，接口采用RESTful API格式，詳見接口規范[10]。

通過這個API Endpoint，可以對微虛機進行管理和控制，包括：

規格配置：比如vCPU個數，用戶內存大小；

網絡配置：添加一個或多個網卡；

存儲配置：

添加“只讀”或“讀寫”虛擬盤，每個虛擬盤盤是一個基于文件的塊設備；

運行時觸發“re-scan”；

更換后端文件；

QoS：通過帶寬限制和iops限制進行流控；

日志與遙測配置；

啟動配置：內核及其參數，根文件系統；

關閉微虛機；

Firecracker以一個單獨的線程運行API Server。

Virtual Machine Monitor

VMM負責構建Firecracker定制的虛擬機模型。其中包括：

最小化的老式設備模型；

微虛機元數據服務（microVM metadata service/MMDS）；

VirtIO虛擬網絡設備和塊設備；

QoS流控；

串口控制臺和半功能鍵盤；

VMM采用單線程事件驅動模型，對各種I/O請求進行服務。

vCPU Threads

根據規格配置，通過KVM接口創建vCPU結構，為每個vCPU啟動一個線程，執行vCPU事件循環，并執行同步I/O和基于內存映射I/O的操作。

3.2 微虛機模型

Firecracker利用了硬件輔助虛擬化，同時使用一個極簡的設備模型。從系統虛擬化角度看，可分解為如下幾個方面：

CPU/Memory: 利用VT-x進行CPU虛擬化和內存虛擬化

系統總線：移除PCI系統總線模

設備模擬：

virtio-net

virtio-block

console

keyboard

irqchip

clock source

KVM in kernel devices

in VMM

3.3 社區及路線圖

在Firecracker代碼庫中的文檔里面公布的路線圖上[8]可以看出，目前它主要部署在Intel的平臺，計劃還會支持AMD、ARM平臺，及存儲加密等特性。

Firecracker的開發者與社區的互動還是比較積極的。由此看來，他們希望借助社區的力量以實現與k8s很好的集成。在它的版本庫上，還提供了一個與containerd對接的原型“firecrack-containerd”。Firecracker的維護者Anthony Liguori（前QEMU社區維護者）也表示出與Kata Containers社區合作的意愿。

4. 總結

注意到許多關于Firecracker的評論中，不少人對“容器運行時”與Firecracker之間的差別存在誤解，在此強調下：Firecracker是一個virtual machine manager，QEMU也是一個virtual machine manager。Kata Containers使用QEMU。因此，Firecracker是AWS用于構建無服務器計算場景下的“容器運行時(Runtime)”（也叫“容器安全沙箱”）所用到的一個組件，作用是替換掉QEMU。當然，更談不上是新型虛擬化技術，它依然使用Intel VT-x，依然需要機器模型和設備模型，只不過，它做的很精簡（當然，為什么不呢？）。

為什么要替換QEMU？原因有很多，比如：龐大的代碼體積；近年來高發的漏洞數量[12]；對基本上用不到的傳統設備、總線、機器模型的模擬。雖然某些情況下，對各種硬件協議的真實模擬還是不錯的，但是，針對無服務器計算（Serverless）這樣的場景，需要業務啟動快，密度高，可快速水平擴展，這種方式顯然就不適合了，需要一種更敏捷的容器運行環境。

除了Firecracker，Kata Containers和gVisor也致力于提供安全可靠的容器運行環境。它們之間存在哪些差異呢？

Firecracker與Kata Containers

首先，Kata Containers使用QEMU作為VMM，使用Linux作為Guest OS，通過配置QEMU的編譯選項來裁剪掉一些不用的功能，通過配置Linux的編譯選項裁剪掉不用的設備驅動、子系統和一些功能。但是，QEMU中的傳統機器模型始終存在，還有一些“設備模擬”的功能沒有編譯選項，因此無法被裁剪掉；而Linux的子系統，如SMP，調度，內存管理，ACPI，PCI總線等也都依然假定活在真實物理機上。對于無服務器計算場景，這些都是沒有意義的，因為在這種場景下，Guest OS完全由我們來提供。不需要考慮其他情況，如Windows或其他老的Linux版本。但凡對業務運行沒有用的設備都不需要，甚至是設備模型和機器模型。Firecracker走的方向與我們正在走的設計方向很相似，即：極簡的機器模型，拿掉PCI總線，替換掉QEMU。我們也曾考慮用Rust語言構建容器沙箱，但AWS動手更早，并已經大規模部署了。回頭來考慮我們的容器實例場景，Aliyun ECI，試想下我們用Firecracker替換了QEMU，并且對Guest OS做進一步的優化，比如頁表預分配，vCPU直接64bit分頁模式啟動等，沙箱的啟動可以更快。

Firecracker與gVisor

對比Firecracker與gVisor的設計，不難發現一個很有意思的話題：“虛擬化的界面”，即：對Guest而言，它與Hypvervisor之間的接口是什么？_與“虛擬機”模型不同，gVisor采用了與Dune[13]類似的“進程虛擬化”模型，將虛擬化的界面畫在了“系統調用/syscall”這個邊界上。因此，徹底去掉了機器模型和設備模型。這不僅意味著減輕了虛擬化的“開銷”，還意味著可以更加靈活高效的利用主機上的系統資源。gVisor就通過host-guest（vmx-root/nonroot）鏡像內核地址空間的內存布局設計，使得它可以既作為host上的hypervisor，又作為guest中的supervisor，因此可以在vCPU調度上內外打通，使得vCPU“協程”可以按需增減。此外，gVisor自然的享受了Go Runtime中的concurrent garbage collector帶來的好處，比如當執行完“用戶負載/函數”時，或當Guest中的“工作集”縮小時，Go的GC的會立即把多余的內存回收并還給主機系統。這就使得gVisor在vCPU和內存資源的使用上都很有“彈性”。

但是，在系統調用這個邊界上提供虛擬化意味著：為Guest提供大量的POSIX接口支持。從安全隔離的角度，這開出了很大的口子，因此，出于安全和性能的考慮，gVisor不得不將一些系統調用的實現放在它的內核里面，并在整個進程外面套一層沙箱環境（cgroups，namespaces，seccomp）。一直以來，我們也在討論這個話題，這個“界面”越往上，虛擬化的開銷越低，但同時，接口數量也變得越大，含義越豐富，嚴謹性越弱，即：“攻擊面”越大。_那么，將“界面”畫在哪里才是合理的呢？_可能沒有一種完美的設計可以滿足所有用戶場景。但在針對無服務器計算這個場景，AWS給出的選擇是接口數量小、含義確定的“虛擬機”模型，不同的是采用極簡的機器模型和設備模型來降低開銷。當然，這也就是說，無論在vCPU還是內存方面，firecracker都跟普通虛擬機一樣，沒有gVisor那樣的“彈性”。這也說明，當在安全隔離和其他因素之間做取舍時，AWS首選前者。

此外，Go runtime并不是“免稅”的，它帶來“彈性”的同時也引入了一些不利的影響，Cody Cutler[14]在他paper中對用Go語言編寫的內核進行了詳細分析，在此不展開了。最后，我們也看到，自Google開源gVisor以來，已經存在幾個漏洞，如[15][16]。可見開發一個穩定的內核很不容易，需要嚴謹的設計和長時間的打磨。

Firecracker的核心設計準則

無服務計算（Serverless）到底需要什么樣的平臺呢？根據前面的分析，其實不難看出，AWS已經給出了它的答案。

一、對外服務的前提是安全隔離，而硬件輔助虛擬化是在多租戶間進行安全隔離的最低標準。在安全和性能面前， 安全第一。

二、無服務器計算場景下，典型的業務特征是生命周期短，因此需要它的平臺提供：

啟動快：極簡設備模型，沒有BIOS，沒有PCI，甚至不需要設備直通；

密度高：內存開銷低；

水平擴展：因為容器的生命周期短；甚至不需要熱遷移；

三、在提高服務器資源利用率方面，AWS也給出了答案，即：基于統計數據搞混部。例如AWS Lambda，它將不同用戶、不同函數運行在同一組硬件資源上，利用用戶負載的波峰波谷互補（與我們搞混部的思路也是一致的）。