老夫先將這個小系列的前兩篇內容鏈接奉上，方便感興趣的朋友一氣讀之。

揭秘大數據 | 19、軟件定義的世界-CSDN博客?

揭秘大數據 | 20、軟件定義數據中心-CSDN博客

今天，書接上文，開聊軟件定義計算的那些事兒！

虛擬化是軟件定義計算最主要的解決途徑。

雖然類似的技術早在IBM S/360系列的機器中已經出現過，但是真正走入大規模數據中心還是在VMware公司推出基于X86架構處理器的全虛擬化產品之后，隨后還有Microsoft Hyper-V、Citrix XEN、Redhat KVM、Sun VirtualBox（現在叫作Oracle VM VirtualBox）等商業或開源解決方案。

虛擬化是一種用來掩蔽或抽象化底層物理硬件并在單個或集群化物理機之上并發運行多個操作系統的技術。

虛擬機成為計算調度和管理的單位，可以在數據中心，甚至跨數據中心的范圍內動態遷移而不用擔心服務會中斷。

基于虛擬機技術的虛擬化計算（見圖1）有三大特點，具體如下：

(1)支持創建多個虛擬機，每個虛擬機的行為與物理機相似，各自運行操作系統（可異構）與程序。

(2)在虛擬機與底層硬件間有一層被稱為虛擬機管理程序，它通常有內核與虛擬機管理器（Virtual Machine Manager，VMM，又稱作Hypervisor）兩大組件。

(3)虛擬機可獲得標準硬件資源（通過虛擬機管理程序模擬及提供的硬件接口、服務來實現）?。

虛擬機管理程序包含以下兩個關鍵組件：

(1)虛擬機管理程序內核提供與其他操作系統相同的功能，例如進程創建、文件系統管理、進程調度等。它經過專門設計后用于支持多個虛擬機和提供核心功能，例如資源調度、I/O堆棧等。

(2)VMM負責在CPU上實際執行命令，以及執行二進制轉換。它對硬件進行抽象化，以顯示為具有自己的CPU、內存和I/O設備的物理機。每個虛擬機會被分配一個具有一定份額的CPU、內存和I/O設備的VMM，以成功運行虛擬機。虛擬機開始運行后，控制權將轉移到VMM，隨后由VMM開始執行來自虛擬機的指令。

虛擬機管理程序可以分為兩種：

1）裸機虛擬機管理程序
2）托管虛擬機管理程序

見下圖2所示：

(1)裸機虛擬機管理程序：這類虛擬機管理程序直接被安裝在X86硬件上。裸機虛擬機管理程序可直接訪問硬件資源，因此，它比托管虛擬機管理程序的效率更高——這一類型是規模化數據中心的主要虛擬化形態。

(2)托管虛擬機管理程序：這類虛擬機管理程序是作為應用程序在操作系統上進行安裝和運行的。它由于運行在操作系統上，因此支持最廣泛的硬件配置——它更適用于測試人員通過模擬來測試不同類型的操作系統平臺。

容器計算是軟件定義計算虛擬化的新銳勢力，它與虛擬機技術的最大區別在于不需要虛擬化整個服務器的硬件棧，而是在操作系統層面對用戶空間進行抽象化，因此我們稱其為操作系統級虛擬化，以區別于之前的基于硬件虛擬化的虛擬機技術。

基于容器計算的用戶應用不需要單獨加載操作系統內核。在同樣的硬件之上，可以支撐數以百計的容器，但是只能支撐數以十計的虛擬機。虛擬機架構與容器架構的對比如圖3所示。

容器計算最早可以追溯到UNIX系統上的Chroot（1979年）?，當時只是單純為單個進程提供可隔離磁盤空間。1982年這一特性被實現在BSD操作系統之上。2000年FreeBSD v4推出的Jails則是最早的容器計算，在Chroot基礎之上，它又實現了更多面向進程的沙箱功能，例如，隔離的文件系統、用戶、網絡。每個Jail有自己的IP地址、可定制化軟件安裝與配置等。這可比Docker早了整整13年，比Docker（v0.9之前）一度依賴的LXC[其為Linux Container（容器）的簡寫]早了8年，比Cloud Foundry的Warden早了11年，比Solaris Containers早了4年，比Linux OpenVZ早了5年，比Linux cgroups早了7年（cgroups基于谷歌公司于2007年貢獻給Linux內核的Control Groups——其前身是谷歌公司內部在2006年的Process Container項目，目的是可以對進程使用的系統資源高度可控）?。

?
容器技術因其具有比虛擬機技術更高的敏捷性、更優的資源利用率而備受初創公司、互聯網企業青睞。但是和任何新興技術一樣，容器技術面臨的挑戰（弱點）主要有三大方面：

(1)安全與隔離。

共性內核意味著位于同一內核上的任何一個容器被攻破都可能會影響剩余的其他所有容器。

(2)管理復雜性。

在虛擬機的基礎上，容器在數量上又上升了一個數量級，而這些容器之間又可能產生復雜的對應關系，因此對容器系統進行有效管理的需求顯然是對現有管理系統的一個巨大挑戰。

(3)對狀態服務、應用的支持。

容器技術對無狀態、微服務架構類型應用的支持可謂完美，可是對數據庫類、ACID類型服務的支持還遠未成熟。我們將常見容器技術方案進行比較，見下圖/表4:

?
上表中Linux LXD是基于LXC構造的，準確地說是提供了一套優化的容器管理工具集（以及Linux distro分發模板系統）?；ThinApp是VMware公司的應用虛擬化解決方案，面向Windows應用；RKT(appc)則是CoreOS公司聯合業界推出的與Docker既兼容又對抗的容器虛擬化架構。Docker在早期階段也是基于LXC的，不過隨后推出了自己的libcontainer庫。圖5展示了Docker容器虛擬化功能接口，也能很好地說明Docker的基本架構。

作為容器行業的領頭羊，Docker公司對容器計算寄予了厚望，他們認為未來的互聯網架構不再是原有的基于TCP/IP的4層（物理層、IP層、TCP/UDP層、應用層）架構，而是4層邏輯實體：互聯網硬件層、互聯網軟件（容器）層、互聯網應用層；程序員層，具體如圖6所示：

這樣的分層顯然極大降低了網絡、硬件、系統架構的復雜性，以服務為中心、以軟件定義為中心、以應用特別是微服務架構為中心、以面向程序員為中心，最終實現更敏捷的開發、更短的交付/上市時間、更高的系統效率以及更好的全面體驗。

我們有理由相信，假以時日，容器技術的作為會更大，不過在相當長的一段時間內容器技術更側重于第三平臺的應用，特別是無狀態類應用與服務。而虛擬機技術更多地滿足第二平臺的應用，特別是傳統企業級應用。顯然，容器技術與虛擬機技術會各自滿足不同類型的應用需求，或業界的巨頭們通常會把兩者結合起來用于一些典型業務場景，例如在虛擬機之上運行容器，或者在一個資源管理平臺上允許并置容器、虛擬機與邏輯，并進行統一調配、管理……

容器計算顯然不會是軟件定義計算的最終形態，2015—2016年期間又出現了兩種架構：

1）無主機計算

2）統一內核

無主機計算以亞馬遜公司的AWS Lambda服務為代表，讓程序員或云計算/大數據服務的用戶不再糾結于底層基礎架構，而是專注于業務需求的描述。它有著比容器計算更高的敏捷性，向按需計算又邁進了一步。軟件定義計算的演進如圖7所示：

?
統一內核則是把已經被容器虛擬化簡化的技術棧再進一步精簡。圖8展示了從容器到統一內核的精簡過程，很顯然，統一內核縮減了操作系統內核的足印，也簡化了每個容器化應用對底層的依賴關系，由此帶來了更快的部署、更高的遷移運行速度。這也解釋了為什么Docker要在2016年年初收購初創公司Unikernels Systems（開源庫操作系統MirageOS的開發者）?。

至此，我們回顧并展望軟件定義計算的發展歷程：
始終是向著不斷追求更高效的系統處理能力、更敏捷的業務需求實現、更高的性價比、更好的用戶體驗的目標前進，而這也同樣適用于人類社會進步的普遍價值追求。

此外，利用普世價值的說辭行欺世盜名之實也并非少見，我們看到很多企業、團隊、創業者沉迷于拿來主義，不愿意在底層軟件開發做任何實際投入，大公司做KPI驅動的開源，小公司在開源項目上包層“皮”就可以到資本市場上橫沖直撞……當投資人評估一個項目的價值是靠GitHub的評價（表現為星星數量）來量化的時候，我們就知道軟件定義世界依然是任重而道遠的。

（文/Ricky - HPC高性能計算與存儲專家、大數據專家、數據庫專家及學者）

· END ·