云計(jì)算時(shí)代，計(jì)算資源如同小馬哥當(dāng)年所言，已經(jīng)成為了互聯(lián)網(wǎng)上的水和電。

虛擬主機(jī)、web服務(wù)器、數(shù)據(jù)庫、對象存儲等等各種服務(wù)我們都可以通過各種各樣的云平臺來完成。

而在云計(jì)算欣欣向榮的背后，有一個(gè)重要的功臣，那就是虛擬化技術(shù)。可以毫不客氣的說，沒有了虛擬化技術(shù)，云計(jì)算無從談起。

說起虛擬化你會(huì)想到什么？從我們常用的虛擬機(jī)三件套VMware、VirtualPC、VirutalBox到如今大火的KVM和容器技術(shù)Docker？

 

這些技術(shù)是什么關(guān)系，背后的技術(shù)原理是怎樣的，又有什么樣的區(qū)別，各自應(yīng)用的場景又是什么樣的？

看完這篇文章，相信大家都能回答上面問題。

歷史背景

什么是虛擬化技術(shù)？

維基百科中的解釋是這樣的：

虛擬化（技術(shù)）是一種資源管理技術(shù)，是將計(jì)算機(jī)的各種實(shí)體資源（CPU、內(nèi)存、磁盤空間、網(wǎng)絡(luò)適配器等），予以抽象、轉(zhuǎn)換后呈現(xiàn)出來并可供分割、組合為一個(gè)或多個(gè)電腦配置環(huán)境。

對于一臺計(jì)算機(jī)，我們可以簡單的劃分為三層：從下到上依次是物理硬件層，操作系統(tǒng)層、應(yīng)用程序?qū)?/p>

 

1974年，兩位計(jì)算機(jī)科學(xué)家Gerald Popek 和 Robert Goldberg發(fā)表了一篇重要的論文《虛擬化第三代體系結(jié)構(gòu)的正式要求》，在這篇論文中提出了虛擬化的三個(gè)基本條件：

• 等價(jià)性：程序在本地計(jì)算機(jī)執(zhí)行和在虛擬機(jī)中執(zhí)行應(yīng)該表現(xiàn)出一樣的結(jié)果（不包括執(zhí)行時(shí)間的差異）
• 安全性：虛擬機(jī)彼此隔離，與宿主計(jì)算機(jī)隔離
• 性能：絕大多數(shù)情況下虛擬機(jī)中的代碼指令應(yīng)該直接在物理CPU中執(zhí)行，少部分特殊指令可由VMM參與。

那如何實(shí)現(xiàn)對計(jì)算機(jī)底層的物理資源的虛擬化分割呢？在計(jì)算機(jī)技術(shù)的發(fā)展歷史上，出現(xiàn)了兩種著名的方案，分別是I型虛擬化和II型虛擬化

 

I型虛擬化

 

II型虛擬化

圖中的VMM意為Virtual machine Monitor，虛擬機(jī)監(jiān)控程序，或者用另一個(gè)更專業(yè)的名詞：HyperVisor

從圖中可以清楚的看到兩種虛擬化方案的區(qū)別：

Type I: 直接凌駕于硬件之上，構(gòu)建出多個(gè)隔離的操作系統(tǒng)環(huán)境

Type II: 依賴于宿主操作系統(tǒng)，在其上構(gòu)建出多個(gè)隔離的操作系統(tǒng)環(huán)境

我們熟知的VMware事實(shí)上有兩個(gè)產(chǎn)品線，一個(gè)是VMware ESXi，直接安裝在裸金屬之上，不需要額外的操作系統(tǒng)，屬于第一類虛擬化。另一個(gè)是我們普通用戶更加熟知的VMware WorkStation，屬于第二類虛擬化。

如何實(shí)現(xiàn)上述的虛擬化方案呢？

一個(gè)典型的做法是——陷阱 & 模擬技術(shù)

什么意思？簡單來說就是正常情況下直接把虛擬機(jī)中的代碼指令放到物理的CPU上去執(zhí)行，一旦執(zhí)行到一些敏感指令，就觸發(fā)異常，控制流程交給VMM，由VMM來進(jìn)行對應(yīng)的處理，以此來營造出一個(gè)虛擬的計(jì)算機(jī)環(huán)境。

不過這一經(jīng)典的虛擬化方案在Intel x86架構(gòu)上卻遇到了問題。

全虛擬化：VMware 二進(jìn)制翻譯技術(shù)

不同于8086時(shí)代16位實(shí)地址工作模式，x86架構(gòu)進(jìn)入32位時(shí)代后，引入了保護(hù)模式、虛擬內(nèi)存等一系列新的技術(shù)。同時(shí)為了安全性隔離了應(yīng)用程序代碼和操作系統(tǒng)代碼，其實(shí)現(xiàn)方式依賴于x86處理器的工作狀態(tài)。

這就是眾所周知的x86處理器的Ring0-Ring3四個(gè)“環(huán)”。

 

操作系統(tǒng)內(nèi)核代碼運(yùn)行在最高權(quán)限的Ring0狀態(tài)，應(yīng)用程序工作于最外圍權(quán)限最低的Ring3狀態(tài)，剩下的Ring1和Ring2主流的操作系統(tǒng)都基本上沒有使用。

這里所說的權(quán)限，有兩個(gè)層面的約束：

• 能訪問的內(nèi)存空間
• 能執(zhí)行的特權(quán)指令

來關(guān)注一下第二點(diǎn)，特權(quán)指令。

CPU指令集中有一些特殊的指令，用于進(jìn)行硬件I/O通信、內(nèi)存管理、中斷管理等等功能，這一些指令只能在Ring0狀態(tài)下執(zhí)行，被稱為特權(quán)指令。這些操作顯然是不能讓應(yīng)用程序隨便執(zhí)行的。處于Ring3工作狀態(tài)的應(yīng)用程序如果嘗試執(zhí)行這些指令，CPU將自動(dòng)檢測到并拋出異常。

回到我們的主題虛擬化技術(shù)上面來，如同前面的定義所言，虛擬化是將計(jì)算資源進(jìn)行邏輯或物理層面的切割劃分，構(gòu)建出一個(gè)個(gè)獨(dú)立的執(zhí)行環(huán)境。

按照我們前面所說的陷阱 & 模擬手段，可以讓虛擬機(jī)中包含操作系統(tǒng)在內(nèi)的程序統(tǒng)一運(yùn)行在低權(quán)限的Ring3狀態(tài)下，一旦虛擬機(jī)中的操作系統(tǒng)進(jìn)行內(nèi)存管理、I/O通信、中斷等操作時(shí)，執(zhí)行特權(quán)指令，從而觸發(fā)異常，物理機(jī)將異常派遣給VMM，由VMM進(jìn)行對應(yīng)的模擬執(zhí)行。

這本來是一個(gè)實(shí)現(xiàn)虛擬化很理想的模式，不過x86架構(gòu)的CPU在這里遇到了一個(gè)跨不過去的坎。

到底是什么問題呢？

回顧一下前面描繪的理想模式，要這種模式能夠?qū)崿F(xiàn)的前提是執(zhí)行敏感指令的時(shí)候能夠觸發(fā)異常，讓VMM有機(jī)會(huì)介入，去模擬一個(gè)虛擬的環(huán)境出來。

但現(xiàn)實(shí)是，x86架構(gòu)的CPU指令集中有那么一部分指令，它不是特權(quán)指令，Ring3狀態(tài)下也能夠執(zhí)行，但這些指令對于虛擬機(jī)來說卻是敏感的，不能讓它們直接執(zhí)行。一旦執(zhí)行，沒法觸發(fā)異常，VMM也就無法介入，虛擬機(jī)就露餡兒了！

這結(jié)果將導(dǎo)致虛擬機(jī)中的代碼指令出現(xiàn)無法預(yù)知的錯(cuò)誤，更嚴(yán)重的是影響到真實(shí)物理計(jì)算機(jī)的運(yùn)行，虛擬化所謂的安全隔離、等價(jià)性也就無從談起。

怎么解決這個(gè)問題，讓x86架構(gòu)CPU也能支持虛擬化呢？

VMware和QEMU走出了兩條不同的路。

VMware創(chuàng)造性的提出了一個(gè)二進(jìn)制翻譯技術(shù)。VMM在虛擬機(jī)操作系統(tǒng)和宿主計(jì)算機(jī)之間扮演一個(gè)橋梁的角色，將虛擬機(jī)中的要執(zhí)行的指令“翻譯”成恰當(dāng)?shù)闹噶钤谒拗魑锢碛?jì)算機(jī)上執(zhí)行，以此來模擬執(zhí)行虛擬機(jī)中的程序。你可以簡單理解成JAVA虛擬機(jī)執(zhí)行Java字節(jié)碼的過程，不同的是Java虛擬機(jī)執(zhí)行的是字節(jié)碼，而VMM模擬執(zhí)行的就是CPU指令。

 

另外值得一提的是，為了提高性能，也并非所有的指令都是模擬執(zhí)行的，VMware在這里做了不少的優(yōu)化，對一些“安全”的指令，就讓它直接執(zhí)行也未嘗不可。所以VMware的二進(jìn)制翻譯技術(shù)也融合了部分的直接執(zhí)行。

對于虛擬機(jī)中的操作系統(tǒng)，VMM需要完整模擬底層的硬件設(shè)備，包括處理器、內(nèi)存、時(shí)鐘、I/O設(shè)備、中斷等等，換句話說，VMM用純軟件的形式“模擬”出一臺計(jì)算機(jī)供虛擬機(jī)中的操作系統(tǒng)使用。

這種完全模擬一臺計(jì)算機(jī)的技術(shù)也稱為全虛擬化，這樣做的好處顯而易見，虛擬機(jī)中的操作系統(tǒng)感知不到自己是在虛擬機(jī)中，代碼無需任何改動(dòng)，直接可以安裝。而缺點(diǎn)也是可以想象：完全用軟件模擬，轉(zhuǎn)換翻譯執(zhí)行，性能堪憂！

而QEMU則是完全軟件層面的“模擬”，乍一看和VMware好像差不多，不過實(shí)際本質(zhì)是完全不同的。VMware是將原始CPU指令序列翻譯成經(jīng)過處理后的CPU指令序列來執(zhí)行。而QEMU則是完全模擬執(zhí)行整個(gè)CPU指令集，更像是“解釋執(zhí)行”，兩者的性能不可同日而語。

 

半虛擬化：Xen 內(nèi)核定制修改

既然有全虛擬化，那與之相對的也就有半虛擬化，前面說了，由于敏感指令的關(guān)系，全虛擬化的VMM需要捕獲到這些指令并完整模擬執(zhí)行這個(gè)過程，實(shí)現(xiàn)既滿足虛擬機(jī)操作系統(tǒng)的需要，又不至于影響到物理計(jì)算機(jī)。

但說來簡單，這個(gè)模擬過程實(shí)際上相當(dāng)?shù)膹?fù)雜，涉及到大量底層技術(shù)，并且如此模擬費(fèi)時(shí)費(fèi)力。

而試想一下，如果把操作系統(tǒng)中所有執(zhí)行敏感指令的地方都改掉，改成一個(gè)接口調(diào)用（HyperCall），接口的提供方VMM實(shí)現(xiàn)對應(yīng)處理，省去了捕獲和模擬硬件流程等一大段工作，性能將獲得大幅度提升。

這就是半虛擬化，這項(xiàng)技術(shù)的代表就是Xen，一個(gè)誕生于2003年的開源項(xiàng)目。

 

這項(xiàng)技術(shù)一個(gè)最大的問題是：需要修改操作系統(tǒng)源碼，做相應(yīng)的適配工作。這對于像linux這樣的開源軟件還能接受，充其量多了些工作量罷了。但對于windows這樣閉源的商業(yè)操作系統(tǒng)，修改它的代碼，無異于癡人說夢。

硬件輔助虛擬化 VT / AMD-v

折騰來折騰去，全都是因?yàn)閤86架構(gòu)的CPU天然不支持經(jīng)典虛擬化模式，軟件廠商不得不想出其他各種辦法來在x86上實(shí)現(xiàn)虛擬化。

如果進(jìn)一步講，CPU本身增加對虛擬化的支持，那又會(huì)是一番怎樣的情況呢？

在軟件廠商使出渾身解數(shù)來實(shí)現(xiàn)x86平臺的虛擬化后的不久，各家處理器廠商也看到了虛擬化技術(shù)的廣闊市場，紛紛推出了硬件層面上的虛擬化支持，正式助推了虛擬化技術(shù)的迅猛發(fā)展。

這其中為代表的就是Intel的VT系列技術(shù)和AMD的AMD-v系列技術(shù)。

 

硬件輔助虛擬化細(xì)節(jié)較為復(fù)雜，簡單來說，新一代CPU在原先的Ring0-Ring3四種工作狀態(tài)之下，再引入了一個(gè)叫工作模式的概念，有VMX root operation和VMX non-root operation兩種模式，每種模式都具有完整的Ring0-Ring3四種工作狀態(tài)，前者是VMM運(yùn)行的模式，后者是虛擬機(jī)中的OS運(yùn)行的模式。

VMM運(yùn)行的層次，有些地方將其稱為Ring -1，VMM可以通過CPU提供的編程接口，配置對哪些指令的劫持和捕獲，從而實(shí)現(xiàn)對虛擬機(jī)操作系統(tǒng)的掌控。

 

換句話說，原先的VMM為了能夠掌控虛擬機(jī)中代碼的執(zhí)行，不得已采用“中間人”來進(jìn)行翻譯執(zhí)行，現(xiàn)在新的CPU告訴VMM：不用那么麻煩了，你提前告訴我你對哪些指令哪些事件感興趣，我在執(zhí)行這些指令和發(fā)生這些事件的時(shí)候就通知你，你就可以實(shí)現(xiàn)掌控了。完全由硬件層面提供支持，性能自然高了不少。

上面只是硬件輔助虛擬化技術(shù)的一個(gè)簡單理解，實(shí)際上還包含更多的要素，提供了更多的便利給VMM，包括內(nèi)存的虛擬、I/O的虛擬等等，讓VMM的設(shè)計(jì)開發(fā)工作大大的簡化，VMM不再需要付出昂貴的模擬執(zhí)行成本，整體虛擬化的性能也有了大幅度的提升。

VMware從5.5版本開始引入對硬件輔助虛擬化的支持，隨后在2011年的8.0版本中正式全面支持。于是乎，我們在創(chuàng)建虛擬機(jī)的時(shí)候，可以選擇要使用哪一種虛擬化引擎技術(shù)，是用原先的二進(jìn)制翻譯執(zhí)行，還是基于硬件輔助虛擬化的新型技術(shù)。

 

同一時(shí)期的XEN從3.0版本也加入對硬件輔助虛擬化的支持，從此基于XEN的虛擬機(jī)中也能夠運(yùn)行Windows系統(tǒng)了。

KVM-QEMU

有了硬件輔助虛擬化的加持，虛擬化技術(shù)開始呈現(xiàn)井噴之勢。VirtualBox、Hyper-V、KVM等技術(shù)如雨后春筍般接連面世。這其中在云計(jì)算領(lǐng)域聲名鵲起的當(dāng)屬開源的KVM技術(shù)了。

KVM全稱for Kernel-based Virtual Machine，意為基于內(nèi)核的虛擬機(jī)。

在虛擬化底層技術(shù)上，KVM和VMware后續(xù)版本一樣，都是基于硬件輔助虛擬化實(shí)現(xiàn)。不同的是VMware作為獨(dú)立的第三方軟件可以安裝在Linux、Windows、MacOS等多種不同的操作系統(tǒng)之上，而KVM作為一項(xiàng)虛擬化技術(shù)已經(jīng)集成到Linux內(nèi)核之中，可以認(rèn)為Linux內(nèi)核本身就是一個(gè)HyperVisor，這也是KVM名字的含義，因此該技術(shù)只能在Linux服務(wù)器上使用。

 

KVM技術(shù)常常搭配QEMU一起使用，稱為KVM-QEMU架構(gòu)。前面提到，在x86架構(gòu)CPU的硬件輔助虛擬化技術(shù)誕生之前，QEMU就已經(jīng)采用全套軟件模擬的辦法來實(shí)現(xiàn)虛擬化，只不過這種方案下的執(zhí)行性能非常低下。

KVM本身基于硬件輔助虛擬化，僅僅實(shí)現(xiàn)CPU和內(nèi)存的虛擬化，但一臺計(jì)算機(jī)不僅僅有CPU和內(nèi)存，還需要各種各樣的I/O設(shè)備，不過KVM不負(fù)責(zé)這些。這個(gè)時(shí)候，QEMU就和KVM搭上了線，經(jīng)過改造后的QEMU，負(fù)責(zé)外部設(shè)備的虛擬，KVM負(fù)責(zé)底層執(zhí)行引擎和內(nèi)存的虛擬，兩者彼此互補(bǔ)，成為新一代云計(jì)算虛擬化方案的寵兒。

容器技術(shù)-LXC & Docker

前面談到的無論是基于翻譯和模擬的全虛擬化技術(shù)、半虛擬化技術(shù)，還是有了CPU硬件加持下的全虛擬化技術(shù)，其虛擬化的目標(biāo)都是一臺完整的計(jì)算機(jī)，擁有底層的物理硬件、操作系統(tǒng)和應(yīng)用程序執(zhí)行的完整環(huán)境。

為了讓虛擬機(jī)中的程序?qū)崿F(xiàn)像在真實(shí)物理機(jī)器上運(yùn)行“近似”的效果，背后的HyperVisor做了大量的工作，付出了“沉重”的代價(jià)。

雖然HyperVisor做了這么多，但你有沒有問過虛擬機(jī)中的程序，這是它想要的嗎？或許HyperVisor給的太多，而目標(biāo)程序卻說了一句：你其實(shí)可以不用這樣辛苦。

確實(shí)存在這樣的情況，虛擬機(jī)中的程序說：我只是想要一個(gè)單獨(dú)的執(zhí)行執(zhí)行環(huán)境，不需要你費(fèi)那么大勁去虛擬出一個(gè)完整的計(jì)算機(jī)來。

這樣做的好處是什么？

虛擬出一臺計(jì)算機(jī)的成本高還是只虛擬出一個(gè)隔離的程序運(yùn)行環(huán)境的成本高？答案很明顯是前者。一臺物理機(jī)可能同時(shí)虛擬出10臺虛擬機(jī)就已經(jīng)開始感到乏力了，但同時(shí)虛擬出100個(gè)虛擬的執(zhí)行環(huán)境卻還是能夠從容應(yīng)對，這對于資源的充分利用可是有巨大的好處。

近幾年大火的容器技術(shù)正是在這樣的指導(dǎo)思想下誕生的。

 

不同于虛擬化技術(shù)要完整虛擬化一臺計(jì)算機(jī)，容器技術(shù)更像是操作系統(tǒng)層面的虛擬化，它只需要虛擬出一個(gè)操作系統(tǒng)環(huán)境。

LXC技術(shù)就是這種方案的一個(gè)典型代表，全稱是LinuX Container，通過Linux內(nèi)核的Cgroups技術(shù)和namespace技術(shù)的支撐，隔離操作系統(tǒng)文件、網(wǎng)絡(luò)等資源，在原生操作系統(tǒng)上隔離出一個(gè)單獨(dú)的空間，將應(yīng)用程序置于其中運(yùn)行，這個(gè)空間的形態(tài)上類似于一個(gè)容器將應(yīng)用程序包含在其中，故取名容器技術(shù)。

舉個(gè)不是太恰當(dāng)?shù)谋扔鳎惶自瓉硎侨邮业姆孔樱欢繓|拿來改造成三個(gè)一居室的套間，每個(gè)一居室套間里面都配備了衛(wèi)生間和廚房，對于住在里面的人來說就是一套完整的住房。

如今各個(gè)大廠火爆的Docker技術(shù)底層原理與LXC并不本質(zhì)區(qū)別，甚至在早期Docker就是直接基于LXC的高層次封裝。Docker在LXC的基礎(chǔ)上更進(jìn)一步，將執(zhí)行執(zhí)行環(huán)境中的各個(gè)組件和依賴打包封裝成獨(dú)立的對象，更便于移植和部署。

 

容器技術(shù)的好處是輕量，所有隔離空間的程序代碼指令不需要翻譯轉(zhuǎn)換，就可以直接在CPU上執(zhí)行，大家底層都是同一個(gè)操作系統(tǒng)，通過軟件層面上的邏輯隔離形成一個(gè)個(gè)單獨(dú)的空間。

容器技術(shù)的缺點(diǎn)是安全性不如虛擬化技術(shù)高，畢竟軟件層面的隔離比起硬件層面的隔離要弱得多。隔離環(huán)境系統(tǒng)和外面的主機(jī)共用的是同一個(gè)操作系統(tǒng)內(nèi)核，一旦利用內(nèi)核漏洞發(fā)起攻擊，程序突破容器限制，實(shí)現(xiàn)逃逸，危及宿主計(jì)算機(jī)，安全也就不復(fù)存在。

超輕虛擬化 firecracker

虛擬完整的計(jì)算機(jī)隔離性好但太過笨重，簡單的容器技術(shù)又因?yàn)樘^輕量純粹靠軟件隔離不夠安全，有沒有一個(gè)折中的方案同時(shí)兼具兩者的優(yōu)點(diǎn)，實(shí)現(xiàn)既輕量又安全呢？

近年來，一種超輕虛擬化的思想開始流行開來，亞馬遜推出的firecracker就是一個(gè)典型的代表。

 

firecracker將虛擬化技術(shù)的強(qiáng)隔離性和容器技術(shù)的輕量性進(jìn)行融合，提出了一個(gè)microVM的概念，底層通過KVM虛擬化技術(shù)實(shí)現(xiàn)各個(gè)microVM的強(qiáng)隔離，而隔離的虛擬機(jī)中運(yùn)行的是一個(gè)個(gè)精簡版的微型操作系統(tǒng)，砍掉了大量無用的功能，專為容器設(shè)計(jì)的微型OS。

超輕虛擬化如今成為一個(gè)新的浪潮，除了AWS的firecracker，谷歌的gVisor, Intel主導(dǎo)的NEMU也在向這個(gè)領(lǐng)域開始發(fā)力。

總結(jié)

本文簡單介紹了虛擬化技術(shù)的基本概念和基本要求。隨后引出由于早期的x86架構(gòu)不支持經(jīng)典的虛擬化方案，各家軟件廠商只能通過軟件模擬的形式來實(shí)現(xiàn)虛擬化，其代表是早期的VMware WorkStation和Xen。

不過純粹依靠軟件的方式畢竟有性能的瓶頸，好在Intel和AMD及時(shí)推出了CPU硬件層面的虛擬化支持，軟件廠商迅速跟進(jìn)適配，極大的改善了虛擬化的性能體驗(yàn)。這一時(shí)期的代表有新版本的VMware WorkStation、Hyper-V、KVM等。

 

近年來，隨著云計(jì)算和微服務(wù)的縱深發(fā)展，對虛擬化技術(shù)的虛擬粒度逐漸從粗到細(xì)。從最早的虛擬化完整的計(jì)算機(jī)，到后來只需虛擬出一個(gè)操作系統(tǒng)，再到后來虛擬出一個(gè)微服務(wù)需要的環(huán)境即可，以Docker為代表的容器技術(shù)在這個(gè)時(shí)期大放異彩。

附VMware融合容器與虛擬機(jī)的重構(gòu)應(yīng)用

根據(jù)IDC預(yù)計(jì)，到2022年，90%的新應(yīng)用將采用微服務(wù)架構(gòu)，35%的生產(chǎn)環(huán)境應(yīng)用是云原生；此外，在Gartner的報(bào)告中，包括Kube.NETes等云原生技術(shù)也正在向應(yīng)用場景、技術(shù)、生態(tài)三個(gè)方面快速演進(jìn)，并將擴(kuò)展到更多生產(chǎn)應(yīng)用環(huán)境，比如在混合云和多云管理領(lǐng)域，以及邊緣層的創(chuàng)新應(yīng)用等。

但正如上文所提到的，企業(yè)通往云原生之路并不容易，原因就在于隨著Mesos、Kubernetes等容器相關(guān)技術(shù)的流行，云計(jì)算的核心理念正在發(fā)生本質(zhì)性的改變，即從過去的以資源編排（分配）為中心向以應(yīng)用編排（調(diào)度）為中心轉(zhuǎn)變。

 

換句話說，未來企業(yè)的核心服務(wù)模式將都轉(zhuǎn)變?yōu)樵频哪Ｊ剑液蛻?yīng)用是深度融合的，因此這就會(huì)帶來很多的挑戰(zhàn)，具體來看：

一是，不同組件帶來的異構(gòu)環(huán)境的挑戰(zhàn)，在實(shí)際生產(chǎn)環(huán)境中，企業(yè)應(yīng)用通常是由多種不同的技術(shù)組件組成，有些組件用到了最新的容器和Serverless 技術(shù)，有些組件則運(yùn)行在虛擬機(jī)中，還有的應(yīng)用需要訪問遺留系統(tǒng)，或者是訪問企業(yè)外部的SaaS 服務(wù)，這些組件分布在不同的運(yùn)行環(huán)境中，通常由不同的團(tuán)隊(duì)開發(fā)和維護(hù)，這就加大了日常管理和維護(hù)的壓力。

二是，不同應(yīng)用環(huán)境帶來的應(yīng)用孤島問題，為了支持容器和虛擬機(jī)共存的應(yīng)用，很多企業(yè)不得不在vSphere集群外搭建一套新的容器集群，但這種做法打破企業(yè)原有的標(biāo)準(zhǔn)運(yùn)維流程，運(yùn)維團(tuán)隊(duì)也并不熟悉新的Kubernetes環(huán)境，管理這兩種環(huán)境用到的工具和方法也是完全不同的，應(yīng)用治理的策略也無法同步到兩種類型的環(huán)境中，由此造成新的應(yīng)用孤島難題。

三是，越來越多云原生技術(shù)的出現(xiàn)，也加劇了運(yùn)維和管理的難度。今天，隨著云原生技術(shù)的快速落地，以及新技術(shù)的快速迭代、新需求的層出不窮，讓企業(yè)業(yè)務(wù)應(yīng)用的數(shù)量、復(fù)雜度和數(shù)據(jù)量都在呈幾何級數(shù)上漲，更使得企業(yè)通過傳統(tǒng)的運(yùn)維管理辦法，已難以滿足日益增多的系統(tǒng)和數(shù)據(jù)交互、敏捷創(chuàng)新應(yīng)用、數(shù)據(jù)共享、新業(yè)務(wù)拓展等需求。

由此可見，目前企業(yè)在走向云原生的過程中，IT和開發(fā)是相對“割裂”的，但未來IT和開發(fā)必須走向“融合”，這也意味著企業(yè)的應(yīng)用服務(wù)模式將都轉(zhuǎn)變?yōu)樵圃哪Ｊ剑液蛻?yīng)用是相互融合和交互的，由此才能完成從資源編排為中心向以應(yīng)用編排為中心的轉(zhuǎn)型和升級，實(shí)現(xiàn)“應(yīng)用定義”驅(qū)動(dòng)業(yè)務(wù)創(chuàng)新的流程和機(jī)制，最終更好的邁向數(shù)字化的轉(zhuǎn)型。

融合容器與虛擬機(jī)

為此，VMware Project Pacific解決方案“應(yīng)運(yùn)而生”，可以這么理解，Project Pacific通過對vShpere的全面的改造和優(yōu)化，讓IT運(yùn)維人員可以用自己所熟悉的vShpere管理界面vCenter來按應(yīng)用管理IT基礎(chǔ)設(shè)施，而不再像以前那樣只是管理支撐應(yīng)用的虛擬機(jī)資源；而開發(fā)者則可以通過Kubernetes統(tǒng)一調(diào)用容器、虛擬機(jī)和物理機(jī)等基礎(chǔ)設(shè)施。

由此帶來的價(jià)值是，IT運(yùn)維與開發(fā)者是在一個(gè)統(tǒng)一的平臺上管理各自的工作，由此企業(yè)可以在VMware提供的一套統(tǒng)一平臺下，把虛擬機(jī)資源與云原生應(yīng)用完成對接和實(shí)現(xiàn)統(tǒng)一管理，最終讓虛擬機(jī)和容器完美的“融合”在一起。目前，VMware提供兩種方式，幫助企業(yè)完成這種“融合”工作。

首先，是ESXi原生Pod，Project Pacific在vSphere環(huán)境中增加了一種ESXi 原生的容器運(yùn)行時(shí)環(huán)境 CRX (Container Runtime for ESXi )，CRX是一種輕量級的虛機(jī)，其中僅包含Linux內(nèi)核和必要的容器運(yùn)行環(huán)境，Pod就運(yùn)行在 CRX 虛機(jī)中。
 

 

在此過程讓能夠中，ESXi還針對CRX虛機(jī)做了專門的優(yōu)化，在vSphere 環(huán)境中運(yùn)行容器能夠達(dá)到跟物理機(jī)同樣的性能水平，不用擔(dān)心由于多了一層虛擬化而帶來的性能損失，ESXi啟動(dòng)一個(gè)原生Pod只需要花 100 毫秒，同時(shí)在單臺服務(wù)器上能夠支持上千個(gè)Pod。性能測試也顯示，ESXi原生Pod比在虛機(jī)中運(yùn)行容器Pod要快 30%，甚至比物理服務(wù)器還要快上 8%。

其次，是采用Kubernetes的方法來管理工作負(fù)載，Project Pacific為傳統(tǒng)的 vSphere環(huán)境也提供了一個(gè)Kubernetes 接口，使得開發(fā)人員在vSphere環(huán)境中也可以繼續(xù)利用熟悉的 Kubernetes 命令和 API 來開發(fā)和部署應(yīng)用。
 

 

具體而言，Project Pacific為開發(fā)人員提供了 YAML 語言來定義所有的資源對象，包括 Kubernetes Cluster、Pod、虛機(jī)、數(shù)據(jù)庫等，然后使用他們熟悉的 kubectl來部署這些資源對象，就像使用任何其他 Kubernetes 對象一樣，這種理念將 Kubernetes的使用體驗(yàn)從云原生應(yīng)用擴(kuò)展到其他應(yīng)用，使開發(fā)人員可以輕松地部署和管理現(xiàn)代應(yīng)用，即使這些應(yīng)用橫跨了多個(gè)技術(shù)堆棧。

小結(jié)一下，Project Pacific給vSphere增加了一個(gè)新的控制平面，使用戶可以用Kubernetes來管理vSphere，這樣不僅有利于企業(yè)快速構(gòu)建以應(yīng)用為中心的管理方式，同時(shí)也滿足了開發(fā)和運(yùn)維團(tuán)隊(duì)的需求。

 

它的好處主要在于，一方面對于開發(fā)人員來說，Project Pacific就像是一個(gè)增強(qiáng)的 Kubernetes集群，可以使用 Kubernetes 聲明式語法來管理虛擬機(jī)、磁盤和網(wǎng)絡(luò)等資源；另一方面，對于IT 管理員來說，Project Pacific仍舊是vSphere，但是添加了對于應(yīng)用整體管理的能力，而不是單獨(dú)管理許多個(gè)獨(dú)立的組成應(yīng)用的虛擬機(jī)或者容器。

重構(gòu)應(yīng)用與新體驗(yàn)

事實(shí)上，此前VMware大中華區(qū)戰(zhàn)略發(fā)展副總裁李映博士在接受采訪時(shí)也強(qiáng)調(diào)：“Project Pacific意義重大，它通過對VMware vSphere重構(gòu)，將Kubernetes嵌入vSphere的控制平面，讓它成為一個(gè)Kubernetes原生平臺，從而原生地支持Kubernetes。”

 

第一，Project Pacific終結(jié)了容器究竟應(yīng)該部署在虛擬機(jī)還是裸機(jī)上這一業(yè)界激辯很長時(shí)間的爭論，因?yàn)橹貥?gòu)后的VMware vSphere能夠同時(shí)提供對容器和虛擬化最好的支持，從而可以讓整體基礎(chǔ)架構(gòu)可以靈活支持未來的各種應(yīng)用。換句話說，VMware的傳統(tǒng)用戶無需在虛擬機(jī)和Kubernetes容器環(huán)境之間做出選擇，從而能自由在vSphere上進(jìn)行現(xiàn)代應(yīng)用程序開發(fā)和運(yùn)營，同時(shí)繼續(xù)利用現(xiàn)有的技術(shù)、工具和技能組合投資，最大化降低通往云原生之路上的風(fēng)險(xiǎn)和成本。

第二，Project Pacific還徹底改變了開發(fā)人員的工作環(huán)境。在過去開發(fā)人員基于Kubernetes開發(fā)和部署應(yīng)用，而IT的開發(fā)人員通過VMware vCenter來管理基礎(chǔ)架構(gòu)。而Project Pacific則能以整體資源的視角，讓企業(yè)可以通過統(tǒng)一的Kubernetes接口來管理資源，從而可以忽略底層支撐的開發(fā)平臺究竟是容器還是虛擬機(jī)。

第三，Project Pacific不但能保證企業(yè)內(nèi)部的開發(fā)和運(yùn)維的一致性，還能夠做到與公有云上的部署環(huán)境一致，因?yàn)閂Mware如今已經(jīng)與AWS、Azure、google Cloud、阿里云、甲骨文等云服務(wù)商有合作，提供類似VMware Cloud on AWS的服務(wù)，這也就意味著企業(yè)通過Project Pacific，就能夠在混合多云環(huán)境下，減少企業(yè)在云原生領(lǐng)域的運(yùn)維和管理的難度。

由此可見，借助Project Pacific，企業(yè)在通往云原生之路上可以實(shí)現(xiàn)“三統(tǒng)一”，即容器和虛擬機(jī)統(tǒng)一；開發(fā)人員和運(yùn)維人員的統(tǒng)一；私有云、公有云、混合云的統(tǒng)一，由此真正重構(gòu)應(yīng)用和體驗(yàn)，最終讓企業(yè)可以應(yīng)用當(dāng)前的組織模式和治理實(shí)踐，快速完成云原生的升級和迭代。

值得一提的是，VMware還與英特爾展開通力合作，借助vSphere中對于傲騰內(nèi)存的支持，更好的支持Project Pacific在企業(yè)開發(fā)和運(yùn)維中的落地，更進(jìn)一步幫助企業(yè)降低了從全面上云向云原生轉(zhuǎn)變過程中所面臨的挑戰(zhàn)。

 

據(jù)了解，在VMware vSphere中的虛擬機(jī)可以通過兩種方法來使用傲騰內(nèi)存：一種方式是vPMEMDisk (Virtual Persistent Memory Disk)，通過把傲騰內(nèi)存映射成為一塊虛擬硬盤提供給虛機(jī)使用，這種模式下虛機(jī)里的操作系統(tǒng)和應(yīng)用都不需要知道非易失性內(nèi)存，傳統(tǒng)的操作系統(tǒng)和應(yīng)用都可以正常使用這種模式。

另一種方式是，vPMEM (Virtual Persistent Memory)，即傲騰內(nèi)存被映射成為虛機(jī)中的非易失性內(nèi)存 (NVDIMM)，這種情況下要求虛機(jī)中的操作系統(tǒng)能夠支持 NVDIMM (例如 Windows Server 2016 和 RHEL 7.4)，然后把它映射成為存儲設(shè)備提供給上層應(yīng)用；如果是PMEM-aware應(yīng)用的話，則可以在虛機(jī)里直接訪問 vPMEM。

測試顯示，傲騰內(nèi)存對于VMware vSphere的應(yīng)用性能提升還是很有幫助的，如果把傲騰內(nèi)存當(dāng)作存儲來用也已經(jīng)比SSD有很大的性能提升；如果是PMEM-aware 應(yīng)用，通過針對非易失性內(nèi)存的優(yōu)化，性能提升則可以實(shí)現(xiàn)更多。

全文總結(jié)，云原生的時(shí)代未來已來，而VMware Project Pacific則為企業(yè)從虛擬機(jī)到容器架設(shè)了一條高效連接和融合的橋梁。從這個(gè)角度來說，有容器和虛擬機(jī)的地方，都需要有VMware Project Pacific，而它也能夠?yàn)槠髽I(yè)通往云原生的旅程提供更為強(qiáng)大的新動(dòng)力。