關注 TencentServerless 公衆號，回覆「PPT」，即可領取本屆大會演講 PPT。
無服務器背後的一個關鍵技術稱作 microVMM。Firecracker 就是用於創建和管理 microVMM的開源項目。Firecracker 運行在用戶空間，使用 KVM 來創建實例。其快速啓動和低內存特性尤爲關鍵。本議題將介紹 Firecracker 的基礎、最小設備模型，以及它所帶來的快速啓動、性能、安全性和利用率的提升。本文由 Amazon Web Services 首席開發者佈道師費良宏在 Techo TVP 開發者峯會 ServerlessDays China 2021 上的演講《microVMM — Serverless 核心技術揭祕》整理而成，向大家分享，本次分享完整視頻請見文末。
01. Serverless 的發展現狀
今天跟大家分享一個有意思的話題，Serverless 背後核心的技術 — microVMM。我們一起見證和經歷了很多開源技術、開發技術、軟件架構技術不斷的變化，很難相信在今天有如此多可以選擇的技術棧，讓我們去開發、運維、部件和部署，它們讓我們覺得這個時代變得更加美好。其中就包括了今天我們談論的主要話題：Serverless 無服務器，我最早接觸它是在2014 年 Amazon Lambda 發佈時，當我寫下第一行「Hello World」，感到如此簡單——將業務邏輯簡單分裝，只需幾秒鐘，就部署到雲的環境中，我迅速獲得一個 Endpoint 端點，就可以調用它獲得一切的能力。這與以往的開發經歷相比，簡直是天壤之別，雖然那個時候 Serverless 還有很多不方便的地方、有很多技術上的限制。但過去幾年裏，這些技術的發展已經突飛猛進，給我們全新的感覺和認知。
Serverless 究竟發展到怎樣的程度？今年的 5 月份，DataGog 公司針對 Serverless 市場發佈了一份分析報告，可以讓我們一睹在今天的市場當中 Serverless 技術發展的情況。
這個報告談到幾個有意思的觀點：
第一，Serverless 的火熱程度。以 Amazon Lambda 平臺爲例，對比 2019 年 Q1 與 2020 年 Q1，從全球的使用量來看，有了 3.5 倍的提升，這是非常了不起的進步，在絕大多數企業中，每天調用 Serverless 技術的函數時間大概達到 90 小時以上。甚至不僅 AWS Lambda，包括像 Azure Functions 和 Google Cloud Functions 等這些技術都有了長足的進步，用戶的使用量和規模也越來越大。這一切都揭示着一個事實 — Serverless 技術變得越來越活躍，並且被廣泛地接受。接受 Serverless 的用戶，不僅僅是個體的開發者、創業公司、企業用戶，甚至遍及到各行各業、在各種業務場景當中，我們甚至可以把 Serverless 看作是一種「膠水」一樣的工具，把很多原來不可想象的運維、數據處理、機器學習的推理包括移動端的調用等都通過這樣一個簡單的技術加以貫穿起來。
同時，我們注意到開發者在使用 Serverless 技術本身上，也有了很大的變化。例如，每一個開發函數的調用時間，從 2019 年到 2021 年，這個變化明顯地在於函數運行時間大致下降一半左右。以中位數爲例，今天我們看到的絕大多數 Serverless Function 運行時間大概是 60 毫秒左右，這說明什麼問題？第一點，開發者越來越成熟，可以更好地駕馭 Serverless 技術，用最佳實踐方法進行函數開發。同時，我們看這張表格，也注意到它的尾部比較長，這也說明了雖然 Serverless 函數有運行時間的限制，以 Amazon Lambda 爲例，有 900 秒的限制。但我們越來越多地不僅把 Serverless Function 用在短任務上，也用於一些長任務的執行和處理上，Serverless 的應用範圍和領域是越來越豐富了。其實如果細分，這個報告中還有一些有意思的話題。例如 Amazon Lambda 所支持的 6 個語言中，最活躍的開發語言 Python 和 Node.js 大致佔了 90% 的份額，其中，Python 大致佔比達 58%，Node.js 佔 31% 左右。對於不同規模的企業來說，規模越小的企業選擇 Node.js 的比例越高，大型企業更多選擇 Python。選擇語言本身是一個非常值得探討的話題，今天時間原因，沒有辦法展開這個探討，但這一點也值得大家關注。
歸納起來，作爲一個函數的運行環境，一個 Serverless 平臺，我們需要提供怎樣的功能給到開發者？歸納起來，無非這三個最基礎的功能和需求：
第一，安全的特性。代碼以及運行的數據需要在安全的環境當中運行，畢竟雲計算提供多租戶的環境，如果不能有很好的解決數據和執行代碼的安全問題，那這一切的基礎將不再存在。
第二，啓動時間。大家談到 Serverless 技術的時候經常遇到一個問題，就是冷啓動，我們需要利用一切可能，將冷啓動的時間減少，讓我們代碼的響應時間越來越快，甚至接近於運行在裸機主環境中的原生代碼。
第三，利用率。對於平臺是非常重要的一點。我們運營很多個機器，構成一個集羣，在集羣上運行不同用戶的多個甚至數以海量計的函數時，需要在每臺物理機器上運行儘可能多的函數，這樣確保我們的經濟效益以及運營的效率。
所以，歸納起來，安全、啓動時間和利用率成爲運行一個好的 Serverless 平臺最重要的三個問題。如果解決這三個問題的話，我們相信提供給開發者的將是一個非常優良的 Serverless 平臺。
如果我問大家，今天選擇技術棧去構建一個這樣的平臺，你會怎樣考慮去實現這些技術目標？如果大家對 Linux 的 kernel 環境有所瞭解，我相信大家第一時間跳出的都是這樣的詞彙：Cgroups（資源限制）、Namespaces（可見性限制）……這些在過去幾十年中已非常成熟地用於資源管理、隔離和安全控制的技術手段。不瞞大家說，當 2014 年 Amazon Lambda 出現的時候，最初的版本就是使用 Cgroups、Namespaces 這樣成熟的隔離機制來實現基礎的隔離和資源的控制，但是這一切能夠滿足真正生產環境當中 Serverless 的需求嗎？
或許還有其他的選擇，例如我們會在一個物理的環境當中去部署 Serverless 環境，或者考慮選擇在一個虛擬機的環境中構建 Serverless 環境。利用虛擬機所提供的隔離機制達成這些效果，再或者用今天大家所熟悉的容器技術，實現資源的分割以及容器化的隔離。這些或許都是選擇，但事實上這些選擇都不是一個非常完美的答案，因爲畢竟這些技術的出現，針對的問題以及解決問題的角度跟我們今天所面對的 Serverless 有很大的差異。設想一下，今天我們所需要的是在一臺物理機裏面運行不同用戶許多個不同的函數，這些函數對於資源的開銷有很大的不同，有不同語言的運行時，那麼它們的峯值對於 CPU、對於網絡、對於存儲的要求也有不同的差異。是不是用剛纔談到的資源管理和隔離的技術可以滿足這一切？
坦率說，現有的許多技術並不能夠滿足。這也意味着我們需要一種新的隔離技術或者資源管理的技術，去達成一個好的 Serverless 運行環境的最基本的要求。那這樣的一個環境，我們可以把它簡單稱爲「microVMM」，之所以稱之爲「microVMM」，是因爲強調它與我們傳統意義上的虛擬環境 VM 有很大不同，它針對的就是 Serverless 環境，而不是通用的虛擬化的環境。這就是我想爲大家介紹的 microVMM 的背景。
02. Serverless 爲何需要一個 microVMM
microVMM 只是一個概念，實現的方法會有很多，其中一個就是今天我想爲大家介紹的非常有效的一個開源的實現 — Firecracker（鞭炮）。它的出現爲大家提供了參考範本，讓我們瞭解，當我們試圖打造一個好的 Serverless 環境時，一個真正意義上的可以商業化運營的、在生產環境中提供實現的 microVMM 究竟是怎樣的。
回到剛纔的主題，我們會去思考這樣一個問題：Serverless 環境當中究竟需要怎樣的一個 microVMM？如果不能回答這個問題，恐怕接下來的內容將無從談起。如果回答這個問題，我們可以從最基礎的要求進行嘗試。例如在一臺服務器上運行函數，可以選擇一臺裸金屬服務器，在 EC2 環境中一款規格爲 M5 的實例，有 384G 內存，64 顆核心。當我們試圖在這臺物理服務器上運行 Serverless 的時候，即使是今天 Amazon Lambda 最小的一個函數，它的開銷也需要 128 兆內存。當然，在管理上 CPU 的資源與內存的多少存在一定的映射關係。這意味着我們要在一臺這樣的服務器裏面儘可能多地裝下這樣的一個又一個的Serverless VM。我們達成的效果就意味着能夠提供的資源環境和利用的效率能提升到怎樣的高度，並且在這樣的環境當中，彼此要是安全的隔離，我們要對資源進行有效的管理和分配，這就是我們所面對最主要的問題和挑戰。
簡單歸納一下，剛纔談到的幾個關鍵點：
第一個需求，隔離技術。在一臺物理機器當中，需要運行數千個 Serverless 函數的時候，每個函數之間是隔離，而且是有效隔離。我們要減少攻擊面，減少我們的應用和數據被泄露或被攻擊的可能性。
第二，在這個環境當中，我們要解決負載的問題，讓每一個函數能夠公平地得到所需要的 CPU、內存、網絡等相關的資源；甚至我們需要在這樣的環境當中儘可能多地運行更多的 Serverless 函數以確保經濟效益，完成平臺運營的目標。
第三，性能的問題。當我們開發一個 Serverless 函數的時候，需要這個函數儘可能多地跟我們在原生環境中運行函數的效果一致。大家使用程序都有這樣的感覺：當我們開發調試的時候，我們對一個函數運行的效果、執行的時間和資源的開銷會有一個預判，如果運行環境和開發環境有很大出入，這對我們實現一個算法、功能會有很大的差異。沒有辦法使得所設想的目標在一個無服務器環境當中被很好地執行。所以，我們希望提供的運行環境是跟原生的環境儘可能多地趨於一致的。
後一點，談到兼容性的問題。在歷史上曾經出現過類似這樣的機制，例如 Google 的 APP Engine 大概在 2008 年出現。那個時候在選擇這個平臺的時候，很多人抱怨原有的開發習慣、開發工具和語言等等沒有辦法很好地運行在這個新的平臺之上，需要爲新的平臺重新打造一套新的輪子，這顯然跟今天的開發理念是違背的。所以，我們希望儘可能保持在 Linux 環境中一致的兼容性，這種兼容性包含二進制文件、庫函數以及系統調用等等，都保持跟現有的開發和原有的知識一脈相承。唯有如此，我們的開發效率纔可以提升，讓我們的代碼可以隨意部署在相關的環境當中。
再有一點，資源分配。畢竟衆多的函數運行在同一臺物理機上，需要有效地針對用戶所訂閱的不同配置來進行合理的分配。甚至在某種情況下，我們要提供一種超額訂閱的機制，這才能使得平臺的經濟性表現得最好。原有的許多技術，例如像 KVM 技術，KEMU 等等，它們的計算密度和負載的問題顯然不能滿足這一點。僅舉一例，QEMU 的代碼規模是 140 萬行，無疑是非常強大、功能完備的。但是顯然開銷也太大了，所以計算的密度和負載的性能本身滿足不了我們的需要。其他的技術，像容器化技術，它的隔離的能力也受到了詬病。爲了解決隔離問題，我們甚至會限制一些系統調用，這就跟兼容性的要求有很大的出入。坦率地說，今天我們所面對的，已經成熟的那些隔離和分配的技術，不能很好地滿足 Serverless 環境，這就是爲什麼我們要打造一個新的 microVMM，也就是 Firecracker 的主要原因。
03. 什麼是 Firecracker？
什麼是 Firecracker？Firecracker 是面向無服務器環境的、開源的 microVMM 的實現。這個實現的目的就像大家看到的示意圖一樣，它運行在一個物理的服務器之上，跟我們傳統架構不同的是，沒有所謂的 Hypervisor 就起到了相應的作用。在 Firecracker 之上運行了一個一個實例，是標準的 Linux Guest OS，也支持 Osv Guest 的操作系統。在每一個 Firecracker 實例當中，它提供了一組 RESTful 的 API，我們可以通過命令行、應用、控制面板來對每一個 microVMM 的實例來進行控制。例如啓停資源分配、銷燬等等。在整個資源環境當中，需要針對我們的網絡、存儲、Metadata 等等進行管理。包括不同的運行環境當中，對資源的消耗等等也需要 Rate Limiting 來進行限制，這就是最標準的一個架構示意圖。當我們在環境當中去創建這樣的一個實例的時候，我們會按照用戶所指定、訂閱的不同的類型，去分配相關的 CPU 和內存，以確保我們的函數可以在正確配置的實例當中運行。那這樣的運行環境，就是我們心中一個理想的 Serverless 環境。
這個項目在 2017 年 10 月開始啓動，2018 年底宣佈了開源。截止到今天，版本已經迭代到了 0.24.4，來自全球不同社區的開發人員爲它貢獻。簡單來說，它的設計思想來自於谷歌 Cloud OS 的設計思想，而 Cloud OS 當初是爲了 Cloud OS 的隔離環境實現的。Firecracker 最初源於 Google 的 Chromium OS，之後兩個不同的項目分道揚鑣，但是來源還是同一個來源，所以我們說它來源於開源，也是基於 Crosvm 技術來實現，但前身是 Chromium OS。開源的協議是 Apache 2.0，這也意味着可以在最大程度上充分利用開源所賦予我們的權利。更爲重要的是，Firecracker 的實現不是針對通用環境下的 VM，是針對無服務器環境下的 microVMM，是小型化的，不是通用而是針對特定環境來實現的。
作爲一個開源項目，它有哪些特點？
首先，它將 Firecracker 的很多實現成果回饋到社區。我們今天看到的 VMM 都已經充分集成和借鑑了 Firecracker。包括像最近因特爾主導的 Cloud 、Hypervisor 就大量地利用了Firecracker出現的一些成果，包括在容器的隔離方面，都對整個社區產生了巨大的影響。對於普通的 Serverless 函數開發人員來說，當我們理解 Firecracker 實現的機理，就可以更好地利用和充分實現函數的功能。例如 Firecracker 可以支持 AVX 指令，我們就可以在程序當中去利用這點加速我們的程序運行。例如 Firecracker 可以支持超線程（SMT）技術，可以利用超線程的方式使 CPU 的利用率達到極致，這些都是 Firecracker 能夠帶來的主要好處。同樣，開源的實現也給我們很好的參考，當有志於打造屬於自己的 microVMM 的時候，完全可以基於這樣一個項目，來構造我們自己定製的一個 microVMM 的實現。
截止到目前，有來自 48 個開源社區的 147 個開發者爲此做了貢獻，其中很多開發人員也是 Amazon 全職的開發者，這個開發的成果不僅成爲了 Amazon Lambda 這樣的無服務器平臺運行的基礎，同樣也被很多開源的社區和開源的項目所集成。這些集成的結果也使得 Firecracker 的影響力在整個開源社區變得越來越大，未來我希望 Firecracker 能夠推動 Rust-VMM、Cloud Hypervisor 能夠最終成爲一個統一的版本，提供給我們一個更好虛擬的環境。
如果大家關心 Firecracker，我想爲大家分享一下這個項目的設計原則。Firecracker 的設計目標是面向雲計算環境中 Serverless 的實現，天生就是面向多租戶環境的 microVMM。除此之外，不同的函數運行需要有 CPU 和內存的組合，所以它要支持各種類型不同的 VCPU 和內存組合的應用環境，有充分的資源管理和分配的機制。它允許超額訂閱，這意味着當我們在一臺物理服務器上支持這個特性的時候，我們可以極大程度上去超售相關函數的資源。那麼超額訂閱的結果，並不會影響我們具體函數的執行，只是讓單臺的物理服務器的利用效率得以提升。
突變的特性是指當創建新增 Serverless VM 的時候，可以保持一個固定的頻率，以確保穩定持續地創建更多的 VM，去滿足多租戶或者大規模併發的特殊場景。對於 Firecracker 性能上的限制，我們要求它僅僅受限於硬件的環境，而儘量減少虛擬化所帶來額外的開銷。對於整個環境來說，對它進行管理和控制，通過一組有效的 RESTful API 實現，使用這個 RESTful API 可以通過我們的程序、命令行工具以及相關的直接對於 API 的控制達成效果和目標。整個的 VM 的環境相比較傳統的 VM 來說，可以說是輕量級以及超級簡化的環境，例如它的設備只有 6 種最簡單的基礎設備，好處就是減少了額外開銷，並且讓產生攻擊的攻擊面積減小，並且性能和效率得到良好提升。
安全性是 Firecracker 非常重點和強調的特徵，如果不能解決安全的問題，我相信沒有任何一個生產環境可以大膽放心地使用 Serverless。如何提升安全性？簡單來說就是有限的設備，像我剛纔談到的只有 6 種最簡化的基礎設備，並且它的功能級不是標準操作的全級，僅僅滿足不同運行時最低可運行的要求和條件。在我們的 Guest OS 和 Host OS 之間進行交互的時候，由於這種開銷相對來說比較大，所以如果能夠有效減少這種開銷，並且把開銷的性能降到最低，會提升整個 VM 的性能。沙箱機制是我們有效的管理方法，不僅僅是通過虛擬化的方式實現沙箱，還需要把每一個 VM 控制在一個相對隔離的空間範圍內，也就是所謂的既有的 VMM。在實現這個產品上，選擇一種安全、可靠的程序語言，也就是 Rust，這是一個非常好的實踐。對於每個 Firecracker，它的實例對應的就是一個 VM，而效率方面我們強調的是快速啓動的性能，這也是 Firecracker 比較傳統的 VM，有很大優勢的一個方面。在低內存、低開銷，也就是每個 VM 的 footprint 在最小化方面，遠遠超過了傳統的 VM。
對於 Firecracker 的實現，開發人員關注的是這樣幾個方面：
在文件系統上，不同於一個標準的 OS，不需要網絡共享，所以它的文件系統是最小的文件系統級。也就是說沒有文件共享的能力，我們並不需要在這個 VM 當中附加太多動態的設備，所以不需要去實現這個特點。在網絡實現方面，由於它是一個虛擬化的網絡，所以僅僅實現了 TAP 的網絡接口，而不是別的接口。這樣有限的接口，使我們的網絡棧變得簡單和容易實現。相比較 QEMU 的 140 萬行代碼，Firecracker 只有區區 8 萬行代碼，從代碼數量來看，就可以瞭解到它的規模和精簡的程度。
在跨界通訊方面，主要使用 VSOCK 的機制，這個開銷足以滿足我們的需要。對於整個 Firecracker 的架構，我們可以看到這樣的一個示意圖。我們在最基礎使用了 QEMU 虛擬化的技術，使用了內核所帶給我們的虛擬化的特性，在此之上，我們實現了文件和網絡接口的虛擬化抽象。有 VMM 和 Seccomp 這樣的實現，6 種最精簡的設備去實現 Firecracker 的 VM。如果大家看到這張圖，就會理解我剛纔所談到的一個精簡 VM 所提供最基礎的環境。雖然從功能級方面無法跟標準的 VM 相提並論，但是在它的尺寸開銷、性能、加載的速度方面會遠遠超過傳統的 VM。
在開發語言方面，它跟之前以往大家所習慣採用的語言不同，選擇了 Rust 語言。之所以有這樣的選擇，來源於最大的挑戰就是內存安全。由於指針濫用的結果，導致 C++ 或者 C 語言當中存在着內存不安全的問題。如果這個問題持續存在的話，修復它的代價一定是非常高昂的。Rust 的出現讓我們獲得了內存安全的機制，簡單來說，Rust 語言本身所具備的沒有 use-after-free 這樣的機制，使得我們的內存本身可以比較安全自由的使用。我們不會去讀取一個未經初始化的任何內存，也就是內存釋放之後一定會被初始化，不會被誤讀。同樣，Rust 本身存在安全的機制，沒有了數據徵用，這就使得我們在實現 Firecracker 的時候，由於語言的選擇，降低了很多的難度。
同樣，由於這樣的語言選擇，在內存的安全方面，由於選擇了 VM 虛擬化的機制，以及 VCPU 半虛擬化的技術，這種技術已經非常成熟，所以實現難度很低，而且實現的標準應該非常好地與今天的技術相兼容。
線程安全方面，大家知道，所謂的線程就是 VCPU，VCPU 的概念跟 Rust 相結合，確保了我們的線程安全。通過模擬的技術，達成了對線程的一個實現。開發人員可以盡情地去使用所有的線程技術，而忽略掉線程背後實現具體上的物理實現。
歸納起來，這就是我們今天所談到的 Firecracker 最主要的幾個特點。我想跟大家重點強調一下，性能上的幾個優勢。例如，快速啓動，在用戶空間創建完整的 Firecracker 的 VM，只需要最多 125 毫秒，這個相比傳統的 container 或 VM，優勢是非常巨大的。如果我們從一個休眠的棧恢復到完整的 VM 環境當中，最少只需要 5 毫秒，這是一個了不起的成就了。
突變率可以達成每秒鐘一個主機上創建 150 個以上的 VMs，當我們遇到大規模併發請求或者集羣調度的時候，可以提供很好的調入機制。內存開銷方面，每一個 Firecracker 的 VM，內存開銷小於 5M，這也意味着可以在物理機上儘可能多地集成更多的 Firecracker 的 VM，可以運行更多的函數。
談到所有的一切，通過這樣一張圖可以瞭解管理機制。在管理方面，最簡單的方法就是利用我們的管理人員，通過我們的 API 對整個 VM 的實力進行註銷、啓動、資源分配和控制。我們有足夠隔離的邊界，針對資源進行通信。這些技術存在於之前已有很多的實現當中，那在這個環境當中，具體說在 Firecracker 的 VM 當中，更多實現的是簡化，更安全以及性能的提升。
性能的表現究竟如何？這想必是大家非常關心的一點。我們可以看到這樣一張圖，這張圖就是 Firecracker 的串行啓動延遲的表現，我們選擇的是 Firecracker 以及傳統的 VM 進行對比的效果。所謂 Preed Firecracker 就是加載了 Firecracker 的守護進程，提前預熱好這樣的一個實例。我們會看到，Firecracker 幾乎是在 150 毫秒左右的區間去實現這樣一個目標，遠遠優於傳統 VM 技術 200 毫秒以上的開銷。在並行啓動的環境當中，我們看到 Firecracker 以及 Firecracker Preed 這樣的技術帶來的優勢也遠遠超過傳統的虛擬化技術。這就是在啓動方面，Firecracker 帶來最直接的變化。
在 IO 方面，看一下 QD1 深度是 1，4K 的讀取性能。從對比性能來看，在 4K 讀的環境當中，跟傳統的 QEMU 非常接近，當然在 128K 的場景下還有很多的提升空間需要改善。當達到隊列深度位 32 的時候，吞吐量也可以看到跟傳統的虛擬化技術包括跟裸機之間的對比，事實上在 IO 這個吞吐方面還需要性能上不斷的提升。
最後想總結一下，究竟 Firecracker 爲 Serverless 環境提供了哪些不一樣的技術，以及帶來了哪些優勢？首先就是安全隔離機制。它的隔離的深度會更好，防禦能力更強，最小的設備模型可以減小這個攻擊面，所以安全隔離機制是滿足生產環境。它是一個簡化的設備模型，有限的設備導致性能的提升以及暴露給使用者的是受控的空間和環境，帶來的直接好處就是它的啓動時間以及引導進入 OS 的加載時間的巨大優勢。第三點，高效擴展，強調的是它的內存開銷，在足夠小的環境下，可以在一個物理環境當中儘可能多地允許更多的 Serverless 環境被執行。
04. 經驗總結
最後，總結一下，在過去幾年當中，應用 Firecracker 技術支持 Serverless 環境當中運行的經驗教訓。
第一，兼容性是硬道理。所有做的一切工作，都是爲了滿足硬件的兼容性，以確保開發人員能夠更快地融入和接受這樣新的技術。這些兼容性有很多很細節的問題，包括超線程的技術，內存管理技術，網絡技術等等，很多問題都是在不斷的摸索和實踐當中發現。但是，兼容性是最重要的一點，如果不能夠解決兼容性，我相信開發者不會接受這樣的一個工具。除了一般意義上的軟件兼容性之外，性能的兼容性也需要考慮。我們儘可能提供一個跟一臺物理環境相接近的性能環境，如果性能兼容，相距較大的話，這恐怕也是開發人員拒絕的一個理由。
第二，不可變的環境，有運行時間的機器。Serverless 環境簡單來說就是一個不可變的環境，不可變的環境意味着我們要對它進行初始化、預配置。有運行時間是強調它有一個超時的時間，這個環境當中確保整個系統的可靠與它的有效運行。有一些系統管理工具，在此實現當中已經證明會破壞我們不可變的特性。例如 Linux 中的 rpm、dpkg 都會帶來巨大的脆弱性和不確定性，所以這是我們盡力避免的特性。限制機器的最大生命週期可以有良好的運營效果，當然很多人詬病函數運行存在 900 秒的限制。希望未來這可以變成參數化的方法，配置環境的時候，靈活地定製，對於應用而言那樣將會更好。
第三，要解決的問題永無止境。隨着現在開發技術不斷髮展，新的技術不斷湧現，對於 Serverless 環境的要求也會越來越高，相信今天的 Firecracker 還在不斷增加新的特性，解決一些遺留的問題。只有保持這樣的勁頭，才能讓 microVMM 更好地去支持未來的開發環境和應用。
對於未來，還有很多需要解決和發展的方向。2017 年的 10 月份，Firecracker 的項目正式啓動，是考慮到了 Lambda 特殊的需求創建的。2018 年的時候項目開源，2018 年 12 月產生 rust-VM，當時開源社區意識到了 Firecracker 和 Cloud OS 某種程度來說會有很多重疊的問題，需要幫社區的資源整合在一起，於是出現了 rust-VMM，這也是一個非常有意思的項目，也許會對未來整個開源的虛擬化帶來巨大的影響。
2019 年，INTEL 也主導了一個 Cloud Hypervisor 的技術，未來非常希望雲上的 Hypervisor 能夠被統一到一個新的架構下，也許是我們今天談的技術，也許是其它新的技術。如果那樣的一天到來，我們的無服務器以及虛擬化技術將變得無比美好。未來 Firecracker 還有很多問題需要解決，在性能方面的限制、在 IO 方面的不足等等，今天的 IO 特性更多依賴於一些 Hypervisor 的特殊的實現，比如說 EC2 對於 Nitro 的依賴，可以通過將網絡以及存儲的相關負載卸載到專用的芯片當中實現，未來這種優化還會持續，IO 性能一定會有更大的提升。
調度尤其是對尾部的延遲，還有很大的提升空間，希望每一個實例的加載，VM 運行的開銷越來越小，延遲越來越低，這纔是我們追求的目標。正確性的證明是非常有意思的話題。整個 Serverless 的 Function 運行在一個完全託管的環境當中。對於開發者來說，意味着這是一個黑盒，我們需要了解運行環境的正確性與否，所以對於無服務器的環境來說，未來需要有更好的正確性證明的有效手段和工具，以確保我們的調試、部署和監控。在快照、內存的 ballooning 方面需要有很大的提升，以確保我們虛擬機總體內存的開銷不能夠超過物理機的實際內存等等，以確保每一代物理機能夠被有效、正確地運行起來。
rust-VMM 也是非常值得關注的方向，也許有一天 rust-VMM 會改寫整個雲計算環境的基礎設施，對於未來的發展我們充滿了各種希望，也希望這些開源的技術能夠改變這一切！在 Firecracker 的網站當中能夠看到這樣一個現象，今天正在致力解決和增加新的特性，也希望更多的開發人員將你們的智慧、努力跟這樣的一個開源項目結合起來，讓這一切變得更美好，讓這樣一個 microVMM 成長更爲迅速，對整個開源社區有更大的貢獻。希望給大家帶來一些啓發，謝謝大家。
分享嘉賓
費良宏，Amazon Web Services 首席開發者佈道師。20多年一直從事軟件架構、程序開發以及技術推廣等領域的工作。經常在各類技術會議上發表演講進行分享，是多個技術社區的熱心參與者。擅長Web領域應用、移動應用以及機器學習等的開發，也從事過多個大型軟件項目的設計、開發與項目管理。目前專注於雲計算以及互聯網等技術領域，致力於幫助開發者構建基於雲計算的新一代的互聯網應用。
One More Thing
立即體驗騰訊雲 Serverless Demo，領取 Serverless 新用戶禮包 👉 騰訊雲 Serverless 新手體驗
歡迎訪問：Serverless 中文網！