云估算时代，估算资源已经变成了互联网上的水电，就像小马一开始说的。
通过各种云平台可以完成虚拟主机、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等。
近年来，随着云计算和微服务的深入发展，虚拟化技术的虚拟精细度逐渐由粗变细。 从最早的全虚拟化电脑，到后来只需要虚拟化一个操作系统，再到虚拟化一个微服务需要的环境，我觉得代表容器技术在这个时代大放异彩。
技术的发展总是随着市场的发展需求而发展。 我们很期待虚拟化的未来会怎样。
每晚进步一点点
慢可以更快
