云估算時代，估算資源已經變成了互聯網上的水電，就像小馬一開始說的。
通過各種云平臺可以完成虛擬主機、Web服務器、數據庫、對象存儲等各種服務。
云計算繁榮的背后，有一個重要的功臣，那就是虛擬化技術。 可以直白的說，沒有虛擬化技術，云計算就無從談起。
當您想到虛擬化時，您會想到什么？ 從我們常用的三件套虛擬機，，，到現在大火的KVM和容器技術？
這個技術有什么關系，背后的技術原理是什么，有什么區別，各自的應用場景是什么？
看完這篇文章，相信你可以回答前面的問題了。
歷史背景
什么是虛擬化技術？
維基百科中的解釋是這樣的：
虛擬化（技術）是一種資源管理技術，就是給計算機的各種物理資源（CPU、內存、磁盤空間、網絡適配器等）多個筆記本配置環境。
對于一臺計算機，我們可以簡單地將其定義為三層：從下到上分別是化學硬件層、操作系統層和應用層。
1974年，Popek和He兩位計算機科學家發表了一篇重要論文《第三代虛擬化架構即將到來的要求》，他們在文中提出了虛擬化的三個基本條件：
那么如何實現計算機底層數學資源的虛擬化劃分呢？在計算機技術的發展史上，有過兩種著名的解決方案，即Type I虛擬化和Type II虛擬化。
I 類虛擬化
II 類虛擬化
圖中的VMM是虛擬機監控程序的意思，或者更專業的術語：
從圖中可以明顯看出兩種虛擬化方案的區別：
TypeI：直接在硬件之上，建立多個隔離的操作系統環境
類型二：依賴于主機操作系統，在其上建立多個相互隔離的操作系統環境
其實有兩條我們熟悉的產品線。 一種是ESXi，直接安裝在裸機上，不需要額外的操作系統。 屬于第一類虛擬化。 另一種是我們普通用戶越來越熟悉的，屬于第二種虛擬化。
如何實現上述虛擬化方案？
一個典型的方法是——陷阱&模擬技術
你是什??么意思？ 簡單來說，一般情況下，虛擬機中的代碼指令是直接在化學CPU上執行的。 一旦執行到一些敏感指令，就會觸發異常，控制過程就會交給VMM，由VMM進行相應的處理。 創建虛擬計算機環境。
然而，這個經典的虛擬化解決方案在 架構上遇到了問題。
全虛擬化：補碼翻譯技術
與8086時代的16位實地址工作方式不同，x86架構進入32位時代后，引入了保護模式、虛擬內存等一系列新技術。 同時應用程序代碼與操作系統代碼安全隔離，其實現方式依賴于x86處理器的工作狀態。
這就是大家熟知的x86處理器的Ring0-Ring3的四個“環”。
操作系統的內核代碼運行在最高權限的Ring0狀態，應用程序工作在最外圍的最低權限的Ring3狀態。 剩下的主流操作系統Ring1和Ring2基本不用了。
這里提到的權限有兩個級別的約束：
下面重點說說第二點，特權指令。
CPU指令集中有一些特殊的指令，用于硬件I/O通信、內存管理、中斷管理等功能。 這些指令只能在Ring0狀態下執行，稱為特權指令。 事實上，這種操作是應用程序無法隨意進行的。 如果處于Ring3工作狀態的應用程序試圖執行這樣一條指令，CPU會手動檢查并拋出異常。
回到我們的話題虛擬化技術，在上面的定義中提到，虛擬化就是在邏輯或數學層面對預估資源進行劃分和定義，并一一建立獨立的執行環境。
根據我們上面提到的trap&方法，虛擬機中包括操作系統在內的程序可以統一運行在低權限的Ring3狀態。 一旦虛擬機中的操作系統進行顯存管理、I/O通信、中斷等待操作時，特權指令被執行，從而觸發異常，化學機將異常調度給VMM，而VMM 進行相應的模擬執行。
這本來是虛擬化的理想模型，但是基于 x86 的 CPU 卻遇到了無法逾越的坎。
有什么問題？
回顧上面描述的理想模型，這些模型能夠實現的前提是只有在執行敏感指令時才能觸發異常，讓VMM有機會介入，模擬虛擬環境。
但實際情況是，x86架構的CPU指令集中有這么一部分指令，不是特權指令，只能在Ring3狀態下執行，但這些指令對虛擬機是敏感的，不能被直接執行。 一旦執行，無法觸發異常，VMM也很難介入，虛擬機就會暴露！
這樣的結果會導致虛擬機中的代碼指令出現不可預知的錯誤，更嚴重的會影響到真正的數學計算機的運行。 虛擬化所謂的安全隔離和等價性將無從談起。
如何解決這個問題，讓x86架構的CPU也能支持虛擬化？
QEMU 采用了兩條不同的路徑。
創造性地提出了一種二補碼翻譯技術。 VMM扮演著虛擬機操作系統和宿主機之間的橋梁角色，將虛擬機中要執行的指令“翻譯”成適合宿主數學機執行的指令，從而模擬程序在宿主機中的執行。虛擬機。 你可以簡單理解為Java虛擬機執行Java字節碼的過程。 不同的是Java虛擬機執行的是字節碼，而VMM模擬執行的是CPU指令。
另外值得一提的是，為了提高性能，并不是所有的指令都在模擬中執行。 這里做了很多優化。 對于一些“安全”的指令，讓其直接執行也不是不可以。 因此，補碼翻譯技術也包含了部分直接執行。
對于虛擬機中的操作系統，VMM需要完整模擬底層硬件設備，包括處理器、內存、時鐘、I/O設備、中斷等。換句話說，VMM是用純軟件“模擬”一個該計算機由虛擬機中的操作系統使用。
這些完全模擬計算機的技術稱為全虛擬化。 這樣做的好處是顯而易見的。 虛擬機中的操作系統感知不到自己在虛擬機中，代碼無需任何修改直接安裝即可。 而缺點也可想而知：完全由軟件模擬，執行轉換翻譯，性能難以預測！
QEMU是一個完整的軟件層面的“模擬”。 乍一看好像差不多，但實際上本質是完全不同的。 它將原始的CPU指令序列翻譯成經過處理的CPU指令序列來執行。 而QEMU則完全模擬了整個CPU指令集的執行，更像是“解釋執行”。 兩者的表現不盡相同。
半虛擬化：Xen 內核自定義更改
由于存在完全虛擬化，因此也存在與之相對的半虛擬化。 前文提到，由于敏感指令的關系，全虛擬化VMM需要捕獲那些指令并完全模擬執行過程，從而達到既虛擬機操作系統的需要又不影響化學計算機。
但是簡單來說，這個模擬過程其實是相當復雜的，涉及到很多底層技術，但是這樣的模擬又費時又費力。
而試想一下，如果操作系統中所有執行敏感指令的地方都改成一個 call()， VMM會進行相應的處理，省去捕獲和模擬硬件進程等大量工作，性能會是大大改善。
這就是半虛擬化，而這項技術的代表就是誕生于2003年的開源項目Xen。
該技術最大的問題之一是需要更改操作系統的源代碼并做相應的適配工作。 這對于像 Linux 這樣的開源軟件來說是可以接受的，充其量它需要更多的工作。 但對于這樣一個閉源的商業操作系統來說，更改其代碼無異于無稽之談。
硬件輔助虛擬化 VT/AMD-v
折騰折騰都是因為x86架構的CPU天然不支持經典的虛擬化模式，軟件廠商不得不想出各種其他的方法在x86上實現虛擬化。
如果再進一步，CPU本身減少對虛擬化的支持，會發生什么？
就在軟件廠商使出渾身解數實現x86平臺虛擬化后不久，各家處理器廠商也看到了虛擬化技術的廣闊市場，紛紛推出了硬件層面的虛擬化支持，即將推動虛擬化技術。 快速發展。
以Intel的VT系列技術和AMD的AMD-v系列技術為代表。
硬件輔助虛擬化的細節更為復雜。 簡單來說，新一代的CPU在原有的Ring0-Ring3四種工作狀態下引入了一個概念，叫做工作模式。 有兩種模式： 和-root。 該模式有Ring0-Ring3四種完整的工作狀態，后者是VMM運行的模式，前者是虛擬機中OS運行的模式。
VMM 運行的級別在某些地方稱為 Ring-1。 VMM可以通過CPU提供的編程套接字來配置綁架和捕獲哪些指令，從而實現對虛擬機操作系統的控制。
也就是說，為了控制代碼在虛擬機中的執行，原來的VMM不得不借助“中間人”進行翻譯和執行。 現在新的CPU告訴VMM：別這么麻煩物理機轉換成vm虛擬機，你提前告訴我你覺得什么指令有擾動有興趣，我執行這個命令的時候通知你，什么時候出現這種擾動，你就可以意識到控制。 完全有硬件層面的支持，性能自然要高很多。
只是對硬件輔助虛擬化技術的簡單理解。 實際上，它包含了更多的元素，為VMM提供了更多的便利，包括虛擬內存、I/O虛擬化等，大大提高了VMM的設計和開發。 精簡之后，VMM不再需要付出高昂的模擬執行成本，整體虛擬化性能也得到了極大的提升。
硬件輔助虛擬化的支持從5.5版本開始引入，2011年8.0版本將全面支持。因此，我們在創建虛擬機時，可以選擇使用哪種虛擬化引擎技術，是否使用原來的二進制補碼代碼翻譯和執行，或者說是一種基于硬件輔助虛擬化的新技術。
同期，XEN也從3.0版本開始加入了對硬件輔助虛擬化的支持，從此系統也可以運行在基于XEN的虛擬機中。
KVM-QEMU
在硬件輔助虛擬化的加持下，虛擬化技術開始呈現井噴之勢。 、Hyper-V、KVM等技術如雪后生菜般相繼問世。 其中，開源的KVM技術在云計算領域享有盛譽。
KVM的全稱是for-based，意思是基于內核的虛擬機。
在底層虛擬化技術方面，KVM和后續版本一樣，都是基于硬件輔助虛擬化。 不同的是，作為一個獨立的第三方軟件物理機轉換成vm虛擬機，它可以安裝在Linux、MacOS等各種操作系統上，而KVM作為一種虛擬化技術，早已融入到Linux內核中。 可以認為Linux內核本身就是一個KVM名稱的意思，所以該技術只能用在Linux服務器上。
KVM技術常與QEMU一起使用，稱為KVM-QEMU框架。 前文提到，在x86架構CPU的硬件輔助虛擬化技術誕生之前，QEMU就已經采用了全套的軟件模擬方式來實現虛擬化，但是這些方案下的執行性能非常低下。
KVM本身是基于硬件輔助虛擬化的，只是實現了CPU和顯存的虛擬化，但是一臺電腦不僅有CPU和顯存，還需要各種I/O設備，而KVM并不負責這些。 這時候QEMU和KVM就上線了。 改造后的QEMU負責外部設備的虛擬化，KVM負責底層執行引擎和顯存的虛擬化。 三者相得益彰，成為新一代云計算虛擬化解決方案的寵兒。 .
容器技術-LXC&
無論是基于翻譯和模擬的全虛擬化技術，還是上面提到的半虛擬化技術，或者是CPU硬件支持的全虛擬化技術，虛擬化的目標都是一個完整的計算機，底層有數學硬件、操作系統和硬件的完整環境。應用程序執行。
為了讓虛擬機中的程序達到在真機上運行的“近似”效果，背后做了大量的工作，付出了“慘重”的代價。
盡管已經完成了所有這些工作，但您是否曾經詢問過虛擬機中的程序這是否是它想要的？ 好像給的太多了，但是目標程序說：你可能不用那么辛苦。
確實存在這樣的情況，虛擬機里的程序說：我只是想要一個單獨的執行環境，你不需要花那么大的力氣去虛擬一個完整的電腦。
這樣做有什么好處？
虛擬化一臺計算機的成本高還是只虛擬化一個孤立的程序運行環境？ 答案顯然是后者。 一個化機可能已經同時虛擬了10個虛擬機，已經開始頭暈目眩了，但是同時虛擬了100個虛擬執行環境之后還是可以從容應對的，這對于做全資源的使用。
近年來大火的容器技術就是在這樣的指導思想下誕生的。
與將計算機完全虛擬化的虛擬化技術不同，容器技術更像是操作系統層面的虛擬化。 它只需要虛擬化一個操作系統環境。
LXC技術就是這些解決方案的典型代表。 全稱是 。 在Linux內核技術和技術的支持下，隔離了操作系統文件和網絡等資源，在本機操作系統上隔離出一個單獨的空間。 運行在其中，這個空間的形狀類似于一個容器，里面裝著應用程序，因此得名容器技術。
打個不恰當的比方，一棟原本是三居室的房子，被二房東改造成了三套一居室。 每間單臥室套房均配有浴室和臥室。 對于以上的人來說，就是一個完整的住房。
目前各大廠商的火熱技術底層原理與LXC并沒有本質區別，甚至在早期都是直接基于LXC的高層封裝。 在LXC的基礎上更進一步，將執行環境中的各個組件和依賴打包打包成一個獨立的對象，更易于移植和部署。
容器技術的使用是輕量級的。 隔離空間中的所有程序代碼指令都可以直接在CPU上執行，無需翻譯和轉換。 你的底層是同一個操作系統，通過軟件層面的邏輯隔離產生不同的空間。 .
容器技術的缺點是安全性沒有虛擬化技術高，雖然軟件層面的隔離比硬件層面的隔離要弱很多。 隔離環境系統與外部主機共享同一個操作系統內核。 一旦利用內核漏洞發起攻擊，程序突破容器限制，逃逸，危害宿主機，安全性將不復存在。
超輕虛擬化
虛擬完全的計算機隔離好但是太麻煩，簡單的容器技術太輕，單純靠軟件隔離不夠安全。 有沒有折衷的方案，兼顧兩者的優點，做到輕量化和安全性兼顧？ ？
近年來，一種超輕虛擬化的想法開始流行，亞馬遜的推出就是一個典型代表。
綜合虛擬化技術的強隔離性和容器技術的輕便性，提出了一個概念。 底層通過KVM虛擬化技術實現強隔離，被隔離的虛擬機運行一個精簡版的Micro OS，鋸掉了很多無用的功能，一個專為容器設計的micro OS。
超輕虛擬化現已成為新浪潮。 不僅是AWS，微軟、英特爾主導的NEMU也開始在這個領域加碼。
總結
本文簡要介紹了虛擬化技術的基本概念和基本要求。 此后有人指出，由于最初的x86架構不支持經典的虛擬化方案，各家軟件廠商只能通過軟件模擬來實現虛擬化，其代表就是early days和Xen。
不過，雖然單純依靠軟件存在性能上的困難，但好在Intel和AMD及時推出了CPU硬件層面的虛擬化支持，軟件廠商也迅速跟進適配，大大提升了虛擬化的性能體驗。 這一時期的代表包括新版本的Linux、Hyper-V、KVM等。
近年來，隨著云計算和微服務的深入發展，虛擬化技術的虛擬精細度逐漸由粗變細。 從最早的全虛擬化電腦，到后來只需要虛擬化一個操作系統，再到虛擬化一個微服務需要的環境，我覺得代表容器技術在這個時代大放異彩。
技術的發展總是隨著市場的發展需求而發展。 我們很期待虛擬化的未來會怎樣。
每晚進步一點點
慢可以更快
