到底什麼是 Unikernel？

如果你持續關注DevOps周刊，DevOps主題的會議或是對技術真正感興趣，你也許已經聽說Unikernel很多次了。在過去的幾個月，它似乎越來越受關注。

然而，究竟什麼是Unikernel? 它是我想要的東西嗎？

我糾結這個問題許久。不知如何定義Unikernel以及它存在的意義？

什麼是Unikernel？

真相的來源僅僅是Wikipedia上的一段晦澀的解釋，我們先看看：

Unikernel是通過使用專門的庫作業系統來構建的單地址空間機器映象。開發者通過選擇棧模組和一系列最小依賴庫來執行應用，而這些棧和庫對應於作業系統中執行應用所必需的依賴。

這些庫負責應用和設定程式碼編譯，構建成封閉的、固定用途的映象（即 Unikernel）可以直接在虛擬機器管理程式（hypervisor）或硬體上執行，不需要類似Linux或Windows的作業系統介於其中。

---- 維基百科：Unikernel

都清楚了，對嗎？

好吧，如果是我，或許以上並沒有說太多。接下來是我對Unikernel的解釋。

首先讓我們跟著這裡例子回顧一下。假設你是一個開發者在寫PHP應用。當你執行你的PHP（其他Ruby、Node、Perl均類似）應用，你本質上是在執行：

• 語言直譯器：PHP、Perl、Ruby、...
• 呼叫作業系統中系統級別的API
• 其中的一些API呼叫需要不同級別的許可權，強制切換應用程式的上下文...（使用者空間 vs. 核心空間）
• 所有執行在作業系統上，例如CentOS、Debian、Ubuntu、...
• 或許是執行在VM上，例如VMware、Xen、KVM、...
• 或許是執行在自己的虛擬化管理系統上，例如ESXi、Xen Hypervisor...
• 依次執行在硬體上
• 通過BIOS或UEFI來引導

說老實話，如果你在抽象一個應用程式構建所需的所有層次，這會是一個奇蹟般的工作。

但是他們做到了。並且做得非常好，有較好的效能。但是你必須認識到，在提供應用執行環境的硬體到應用程式本身存在許多層。

那就是Unikernel試圖解決的：刪除應用與硬體中間臃腫的部分。讓最“精簡”的作業系統執行你的程式碼。

這裡有一篇論文總結得非常好： 

Unikernel的願景：當你看到雲用戶端時就像看到單應用硬體一樣。

- The Rise and Fall of the Operating System

Unikernel試圖抹去現代作業系統帶來的一些複雜性。因為“通用”的作業系統（就像任何Linux和Windows的發行版），通常會伴隨著帶來一些對你的應用來說並不需要的驅動、依賴包、服務、等等，但這些對每一個作業系統來說某種程度上又是必需的。

甚至是在Linux核心的核心模組都並不是需要每一次都完全載入。像USB驅動這類東西在虛擬化的“雲”環境被認為是無用的，但仍然會被包含在核心中。

相比容器和虛擬化，Unikernel所呈現的演進如下圖：


（來源：road_to_unikernels）

unikernels.png

Unikernel對比通用的作業系統例如Linux有許多優勢：

• 安全性的提升：只執行作業系統的核心，廢棄掉那些可能是干擾源的視訊和USB驅動。
• 占用很小空間：想象一下能夠抹去95%核心的大小，因為你的應用不需要那些。
• 客製化的實現：深諳應用並且把核心精簡調整到你想要的部分。
• 快速精準的執行Unikernel範例（就像執行一個Docker範例一樣），啟動時間少於1s。

這樣我們非常自然的把Unikernel當作是微服務的備選方案。

用Unikernel抹去複雜的中間層

如果你執行應用之後想要它的開銷是最小的，那你就可能要考慮製作一個Unikernel。

為此，要使用庫作業系統（LibOS）。一個庫作業系統會給你提供構建自己的Unikernel的方式。最值得關注的是MirageOS（術語“unikernel”的創造者）和Rump Kernels。兩者本質上都是一系列標準化的驅動和庫，這樣你就不需要重複發明像TCP棧、持久儲存層等這類東西。

Unikernel是用高階語言客製化的作業系統核心，並且作為獨立的軟體構件。完整的應用（或應用系統）作為一個分散式系統執行在一套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年的歷史。

為了使作業系統和應用執行得更加流暢，這些unikernel庫需要使用核心部分儘可能小。

現在，由於虛擬化技術，像Xen或VMware這類虛機管理系統（註*：原Operating System）把異構的硬體裝置抽象成一堆標準的虛擬化裝置，unikernel也能為客製化的虛擬裝置而優化。

Unikernel利用虛擬化的優勢創造出一種專屬的經過優化的作業系統。

想要編譯應用程式的“unikernel”，需要依賴MirageOS的庫和OCaml語言，結果像這樣：

編譯器輸出一個完全獨立的核心取代Unix可執行檔案。這些unikernels是只為滿足特定的應用程式和組態檔而實現的庫作業系統VM，並且會依賴hypervisor提供的資源復用和隔離。

--- queue.acm.org: Unikernels: Rise of the Virtual Library Operating System

最終你通過執行一個Unikernel，精簡專屬的作業系統，來執行你應用程式的一部分。如果你的應用和設定需要更新，你需要重新編譯你的原始碼來生成新的Unikernel並部署新版本。如果是新的安全升級？也同樣需要重新編譯和部署。

這將使部署的協調和編排更加困難，但好處是執行應用程式更加高效。

構建不可變的基礎設施架構的關鍵在於：應用程式不再儲存狀態，並且能方便地丟棄和重新構建。

一方面，我們可以讓Unikernel執行在Docker容器中，但是是否應該盡量避免增加其他複雜的中間層？另一方面，Docker在使用和部署上的優勢確實可以彌補這點中間層的開銷。

誰應該使用Unikernel？

實話實說，這個問題的答案對我來說還並不明確。我認為說如果你現在是要在WordPress上部署web應用，使用Unikernel也許還有一定的鴻溝。

另一方面，Unikernel的好處是明顯的，但需要一個完全不同的模式來管理你的基礎設施，一組不同的技能來構建這類的應用和核心並且需要深諳目前對我們來說還完全陌生的一個概念：不可變的基礎設施架構。

也許在今後的5至10年，我們會以新的規範一樣來部署Unikernel。目前，我認為它針對一小部分想要相當專業和安全應用的使用者。對於大多數普通使用者，虛機（或是，如果你走在技術前沿一定會明白：Docker容器）或許才是你應該專注的。

更多Unikernel相關閱讀：

如果您對這個主題感興趣，推薦您一些相關連結：

• Unikernels: Rise of the Virtual Library Operating System
• The Rise and Fall of the Operating System (pdf)
• Presentation: The Road to Unikernels
• After Docker: Unikernels and Immutable Infrastructure
• Unikernels, meet Docker!

本文永久更新連結地址：http://www.linuxidc.com/Linux/2015-12/125701.htm