我們該如何定義 Unikernel 以及它的存在？
本文介紹了一種新的應用虛擬化技術，它讓應用及其所依賴的運行環(huán)境、甚至是連內(nèi)核一起打包，直接運行在硬件或是Hypervisor上，從而更加高效的利用計算機資源。非常有意思，推薦給大家。
如果你持續(xù)關注DevOps周刊，DevOps主題的會議或是對技術真正感興趣，你也許已經(jīng)聽說Unikernel很多次了。在過去的幾個月，它似乎越來越受關注。
然而，究竟什么是Unikernel? 它是我想要的東西嗎?
我糾結這個問題許久。不知如何定義Unikernel以及它存在的意義?
什么是Unikernel?
真相的來源僅僅是Wikipedia上的一段晦澀的解釋，我們先看看：
| Unikernel是通過使用專門的庫操作系統(tǒng)來構建的單地址空間機器鏡像。開發(fā)者通過選擇棧模塊和一系列最小依賴庫來運行應用，而這些棧和庫對應于操作系統(tǒng)中運行應用所必需的依賴。
這些庫負責應用和配置代碼編譯，構建成封閉的、固定用途的鏡像(Unikernel)可以直接在虛擬機管理程序(hypervisor)或硬件上運行，不需要類似Linux或Windows的操作系統(tǒng)介于其中。 ---- 維基百科：Unikernel |
都清楚了，對嗎?
好吧，如果是我，或許以上并沒有說太多。接下來是我對Unikernel的解釋。
首先讓我們跟著這里例子回顧一下。假設你是一個開發(fā)者在寫PHP應用。當你運行你的PHP(其他Ruby、Node、Perl均類似)應用，你本質上是在運行：
- 語言解釋器：PHP、Perl、Ruby、...
- 調用操作系統(tǒng)中系統(tǒng)級別的API
- 其中的一些API調用需要不同級別的權限，強制切換應用程序的上下文...(用戶空間 vs. 內(nèi)核空間)
- 所有運行在操作系統(tǒng)上，例如CentOS、Debian、Ubuntu、...
- 或許是運行在VM上，例如VMware、Xen、KVM、...
- 或許是運行在自己的虛擬化管理系統(tǒng)上，例如ESXi、Xen Hypervisor...
- 依次運行在硬件上
- 通過BIOS或UEFI來引導
說老實話，如果你在抽象一個應用程序構建所需的所有層次，這會是一個奇跡般的工作。
但是他們做到了。并且做得非常好，有較好的性能。但是你必須認識到，在提供應用運行環(huán)境的硬件到應用程序本身存在許多層。
那就是Unikernel試圖解決的：刪除應用與硬件中間臃腫的部分。讓最“精簡”的操作系統(tǒng)運行你的代碼。
這里有一篇論文總結得非常好：
| Unikernel的愿景：當你看到云客戶端時就像看到單應用硬件一樣。 |
Unikernel試圖抹去現(xiàn)代操作系統(tǒng)帶來的一些復雜性。因為“通用”的操作系統(tǒng)(就像任何Linux和Windows的發(fā)行版)，通常會伴隨著帶來一些對你的應用來說并不需要的驅動、依賴包、服務、等等，但這些對每一個操作系統(tǒng)來說某種程度上又是必需的。
甚至是在Linux內(nèi)核的核心模塊都并不是需要每一次都完全加載。像USB驅動這類東西在虛擬化的“云”環(huán)境被認為是無用的，但仍然會被包含在內(nèi)核中。
相比容器和虛擬化，Unikernel所呈現(xiàn)的演進如下圖：
(來源：road_to_unikernels)
Unikernel對比通用的操作系統(tǒng)例如Linux有許多優(yōu)勢;
- 安全性的提升：只運行操作系統(tǒng)的核心，廢棄掉那些可能是干擾源的視頻和USB驅動。
- 占用很小空間：想象一下能夠抹去95%內(nèi)核的大小，因為你的應用不需要那些。
- 定制的實現(xiàn)：深諳應用并且把內(nèi)核精簡調整到你想要的部分。
- 快速精準的運行Unikernel實例(就像運行一個Docker實例一樣)，啟動時間少于1s。
這樣我們非常自然的把Unikernel當作是微服務的備選方案。
用Unikernel抹去復雜的中間層
如果你運行應用之后想要它的開銷是最小的，那你就可能要考慮制作一個Unikernel。
為此，要使用庫操作系統(tǒng)(LibOS)。一個庫操作系統(tǒng)會給你提供構建自己的Unikernel的方式。最值得關注的是MirageOS(術語“unikernel”的創(chuàng)造者)和Rump Kernels。兩者本質上都是一系列標準化的驅動和庫，這樣你就不需要重復發(fā)明像TCP棧、持久存儲層等這類東西。
Unikernel是用高級語言定制的操作系統(tǒng)內(nèi)核，并且作為獨立的軟件構件。完整的應用(或應用系統(tǒng))作為一個分布式系統(tǒng)運行在一套unikernels上。
MirageOS基于OCaml語言并且讓unikernels運行在Xen hypervisor上。
-- queue.acm.org: Unikernels: Rise of the Virtual Library Operating System
目前***的用來寫unikernel的語言是：
- Rust
- Go (or 'golang')
- OCaml
- Haskell
這些并不都是新的編程語言。除了Go和Rust，其他均有超過15年的歷史。
為了使操作系統(tǒng)和應用運行得更加流暢，這些unikernel庫需要使用內(nèi)核部分盡可能小。
現(xiàn)在，由于虛擬化技術，像Xen或VMware這類虛機管理系統(tǒng)(注*：原Operating System)把異構的硬件設備抽象成一堆標準的虛擬化設備，unikernel也能為定制的虛擬設備而優(yōu)化。
Unikernel利用虛擬化的優(yōu)勢創(chuàng)造出一種專屬的經(jīng)過優(yōu)化的操作系統(tǒng)。
想要編譯應用程序的“unikernel”，需要依賴MirageOS的庫和OCaml語言，結果像這樣：
編譯器輸出一個完全獨立的內(nèi)核取代Unix可執(zhí)行文件。這些unikernels是只為滿足特定的應用程序和配置文件而實現(xiàn)的庫操作系統(tǒng)VM，并且會依賴hypervisor提供的資源復用和隔離。
--- queue.acm.org: Unikernels: Rise of the Virtual Library Operating System
最終你通過運行一個Unikernel，精簡專屬的操作系統(tǒng)，來運行你應用程序的一部分。如果你的應用和配置需要更新，你需要重新編譯你的源碼來生成新的Unikernel并部署新版本。如果是新的安全升級?也同樣需要重新編譯和部署。
這將使部署的協(xié)調和編排更加困難，但好處是運行應用程序更加高效。
構建不可變的基礎設施架構的關鍵在于：應用程序不再保存狀態(tài)，并且能方便地丟棄和重新構建。
一方面，我們可以讓Unikernel運行在Docker容器中，但是是否應該盡量避免增加其他復雜的中間層?另一方面，Docker在使用和部署上的優(yōu)勢確實可以彌補這點中間層的開銷。
誰應該使用Unikernel?
實話實說，這個問題的答案對我來說還并不明確。我認為說如果你現(xiàn)在是要在WordPress上部署web應用，使用Unikernel也許還有一定的鴻溝。
另一方面，Unikernel的好處是明顯的，但需要一個完全不同的模式來管理你的基礎設施，一組不同的技能來構建這類的應用和內(nèi)核并且需要深諳目前對我們來說還完全陌生的一個概念：不可變的基礎設施架構。
也許在今后的5至10年，我們會以新的規(guī)范一樣來部署Unikernel。目前，我認為它針對一小部分想要相當專業(yè)和安全應用的用戶。對于大多數(shù)普通用戶，虛機(或是，如果你走在技術前沿一定會明白：Docker容器)或許才是你應該專注的。
更多Unikernel相關閱讀：
如果您對這個主題感興趣，推薦您一些相關鏈接：
