虚拟化其实是一个过于宽泛的概念，但是一般大家默认这个术语指的是虚拟机相关技术。
VMware vSphere虚拟化架构
首先还是拿个友商出来做对照。当初是在大四毕业的暑假到研究生的第一年期间考的VCP和VCAP，vSphere的版本还在6.5/6.7，放在今天多少有点过气。但我还是打算把VMware拎出来，看看VMware vSphere虚拟化架构。
VMware vSphere的主要产品有两个：ESXi和vCenter Server。
ESXi 是VMware自家的hypervisor，是在虚拟机和物理资源之间的一个抽象层。Type-1 hypervisor直接运行在物理硬件上，比如VMware的ESXi，微软的Hyper-V，开源的Xen和KVM。Type-2 hypervisor需要运行在虚拟机上，比如Oracle的VirtualBox， VMware的workstation。
所有的VM都是运行在hypervisor上的。VM有两个关键部分：VM Files（虚拟机文件）和Live State（虚拟机的实时状态）。Live State包含了vm在内存中的当前状态以及虚拟硬件的状态。比如vm写入文件时，将发送SCSI命令，这些命令被ESXi主机拦截并传递给storage adapter。VM Files包含了vm的配置文件，比如vm运行在哪台主机上，拥有多少vCPU。
而vCenter Server作为管理平台。运维一般会用Windows Server做AD和DNS，别的物理机通过远程管理卡安装ESXi，然后用vCenter Server做集中管理。存储可以利用iSCSI搭建IP SAN，或者FC SAN，或者VMware家的vSAN。网络层面VMware在vSphere 4.0开始推出了vDS（virtual distributed switch)，也允许使用第三方交换机比如Cisco Nexus 1000V。
AWS & Google Cloud虚拟化架构
Hypervisor层面Google Cloud用的是修改后的KVM。AWS早期使用的是Xen，17年之后也转向KVM。Azure使用的是Windows Hyper-V。
同为KVM，Google Cloud和AWS也有不同。2017年，AWS发布了Nitro system，其中Nitro hypervisor走了offload路线。offload是指将一部分依赖内核的操作交给专门的物理设备来做，绕过CPU。这样一来减少了额外开销，提高了效率。一般比较常见的是网卡offload，hypervisor层面的offload确实是很有创新性。Nitro hypervisor跑在专门的Nitro Cards上，仅启动速度一项，AWS就比Google Cloud快出40%。AWS re:Invent 2017的演讲《C5 实例和 Amazon EC2 虚拟化的演变 (CMP332)》包含了更详细的内容 https://youtu.be/LabltEXk0VQ
然而没过多久，Google Cloud就反超了AWS，将虚拟机的启动时间压缩到0.5s。根据Google的论文，Google Cloud使用Borg管理VM，同时修改了KVM，重新实现了VMM，代号叫做vanadium。根据Evan Anderson在StackOverflow的帖子，这种技术选择有两个原因：1.是KVM与Google已有的隔离/扩展程序相兼容。2.是Google在Linux内核上有着长期的投资，KVM相关人才储备充足。原帖位置：https://stackoverflow.com/a/23699164
云厂商的虚拟化架构有多个技术方向，Google Cloud并非没有尝试实现hypervisor层面的offload，然而相比于已有的KVM人才储备，选择新的技术方向需要大量前期投入，所以最终被放弃。对比Azure选择的Hyper-v，AWS的Nitro System，Google Cloud的定制化KVM，目前看来区别不大，最后影响技术选择的取决于公司已有的技术储备，说白了技术也有路径依赖。
Serverless
为了追求比0.6s更快的启动速度，并且在云计算市场上对抗容器和Kubernetes等新概念（AWS希望把大家的注意力从容器转回到虚拟机的方向，以保持自己的优势地位），2018年AWS推出了microVM产品Firecracker。MicroVM的最初目的是为了解决容器安全性的问题，意图提供完整而独立的虚拟机环境来运行程序，实现完全隔离。NEC lab在SOSP 2017 Kernels Session上发表了《My VM is Lighter (and Safer) than your Container》(http://cnp.neclab.eu/projects/lightvm/lightvm.pdf)，该论文的研究其实落后于当时的业内实践，唯一的创新性可能在于该论文是基于Xen架构的。这篇论文真正有用的地方是系统性的阐述了容器在隔离性上的取舍，和为什么lightVM可以作为一个轻量且安全的方向。而论文本身的价值其实不高，因为早在2014年谷歌就发布过一个叫做no vm的Go项目，15年Intel发布了Clear Container， HyperHQ发布了runV（17年这二者合并成了Kata Container）。
Firecracker是来自于crosvm（Google为ChromeOS实现的Virtual Machine Monitor，使用Rust编写 https://chromium.googlesource.com/chromiumos/platform/crosvm/ ）的一个分支，并且进行了裁剪，没有BIOS和PCI，不支持任何graphics / accelerators / hardware passthrough / legacy devices，只保留网络设备(virtio net)，IO设备（virtio block），KVM时钟（timer），串口控制台和重置按钮，从而大幅度降低冷启动时间。根据AWS的博客，Firecracker启动时间小于125ms，内存消耗小于5MB，一分钟内可以启动4000个实例。
2020年，AWS发表了Firecracker的相关论文《Firecracker: Lightweight Virtualization for Serverless Applications》(https://assets.amazon.science/96/c6/302e527240a3b1f86c86c3e8fc3d/firecracker-lightweight-virtualization-for-serverless-applications.pdf )。实际上这篇论文并没有揭露更多有效信息，作为从业人员和竞争对手（比如GCP和Azure），在AWS发布Firecracker之后的几天之内就已经摸清楚了相关技术信息。尤其是这东西并没有啥技术上的创新（相比于Google的vanadium）。个人觉得比较有意思的点在于这篇论文透露了一些AWS Lambda的使用情况。Firecracker的动机在于之前的Lambda基于单虚拟机，作为一款Serverless产品居然亏损严重。使用了Firecracker之后AWS可以10倍超售（测试环境下20倍都没有问题）。
作为AWS Lambda的同类产品，Google Cloud Functions 并没有走MicroVM路线，而是在 Cloud Next '18上发布了gVisor隔离方案。gVisor的理念来自AppArmor, Seccomp BPF和SELinux。MicroVM的解决方案无论如何都要启动一个kernel，对于Google来说，嵌套一层VM意味着性能下降。gVisor用Go编写，实现了一个独立的user space kernel，隔离了Linux kernel。
gVisor能够达到150ms的启动时间和～15MB的内存消耗。考虑到这东西使用了Go来实现，依然能获得这种性能，确实有点东西。gVisor同样提供两层isolation，演讲现场还演示了一下gVisor对抗Dirty Cow和Meltdown漏洞。
最重要的是gVisor额外提供了runsc作为runC的替代，兼容OCI，在kubernetes生态下比Firecracker更有优势。具体细节可以看Cloud Next演讲Sandboxing your containers with gVisor 视频地址：https://youtu.be/kxUZ4lVFuVo
