本期，我们对虚拟化和云计算主题做一个小结。
由于Intel为代表的处理器厂商发现，处理器主频的提升受到硅材料物理特性的限制，难以突破4.0GHz的瓶颈，从而转向在处理器集成电路上集成多个处理核心，以提升处理器的计算力。为了让多个处理核心可以运行多个不同的应用程序和服务，出现了把一台物理机资源分割为多个虚拟机的虚拟化技术。
虚拟化技术需要解决的问题有三个：
- 让虚拟机的操作系统内核既具备ring0特权及直接访问部分硬件的高性能，又不能越过虚拟机本身的访问权限；
- 不同的虚拟机拥有隔离的内存空间；
- 为虚拟机赋予运作效率接近于真实设备的块IO设备和网卡；
Intel的VT-X技术解决了1/2，QEMU利用VirtIO解决了问题3。
同时，SR-IOV技术可以将一个PCIe设备虚拟化为多个不同的PCIe设备，拥有彼此独立的配置空间，在操作系统看来会被视为多个设备(Virtual Function, VF)。将支持SR-IOV的网卡的VF分配给不同的虚拟机以后，虚拟机在使用网卡时就无需通过QEMU虚拟的VirtIO设备，或通过Linux的network namespace，其性能大大提升。
在SR-IOV网卡的基础上，进一步地衍生出了智能网卡，可以内置vSwitch实现虚拟机的互通不经过宿主机的CPU，也可以代替宿主机上vSwitch实现Overlay封装，VirtIO设备挂载等功能。
为了进一步压榨虚拟化下CPU的能力，出现了超分配特性，也就是将1个物理CPU硬件线程，当作多个vCPU使用，其具体实现是将QEMU的多个线程绑定到1个Linux下的CPU上，利用时分复用的方式来复用物理CPU。
而内存超分配的实现，一般是借用其他VM内的空闲内存。但内存超分配有可能导致被借用的VM发生OOM错误，造成系统不稳定，在生产系统中不能使用这种分配方式。
有时，管理员需要把虚拟机从一台宿主机上搬移到另一台宿主机上，这时候就需要虚拟机迁移技术。虚拟机的热迁移依赖于云盘挂载和脏内存二次迁移。
为了避免一台宿主机故障影响多个同一业务的虚拟机，管理员可以使用反亲和性调度策略来将同一业务的多个虚拟机打散到多个宿主机上；另一种场景是如多个虚拟机有频繁的互动，那么管理员可以应用亲和性调度策略，让它们位于同一宿主机，以缩短访问时延。
一般的应用其访问量都有明显的峰值特点，在不同时段访问量不一样。有了弹性伸缩功能之后，可以对弹性伸缩组内虚拟机的CPU利用率和内存利用率进行采样，并基于采样数据，拉起更多虚拟机运行应用实例，或关闭部分实例来让虚拟机数量适应业务访问量。
但是，虚拟机的启动时间一般为分钟级，对于一些峰值出现迅速的业务，分钟级的弹性扩容时延难以接受。工程师们发现，虚拟机启动的瓶颈是虚拟机GuestOS的启动时间。因此，出现了剥离掉GuestOS，将多个应用混部在Linux宿主机上的技术。为了让各个应用彼此隔离，可以利用Linux的namespace，cgroups和unionfs技术实现。这就是所谓的容器技术，docker就是容器技术的一种常见实现。
在容器技术出现后，又出现了自动化编排容器的kubernetes平台，通过CRI接口实现对接不同的容器运行时。kubernetes平台也可以对接prometheus等主流的性能监控器，根据监控到的容器性能实现容器的弹性伸缩，如HPA(水平伸缩)或VPA(垂直伸缩)等。
有开发经验的同学会发现，以SpringCloud为代表的微服务技术也可以与容器技术配合，将SpringCloud的微服务实例运行在容器中。以Istio为代表的服务网格技术、以及Serverless技术等，都依托于容器技术，才能够良好地运作。这些前沿技术代表了云计算的未来。
然而，无论是虚拟化，容器，还是serverless或云原生，本质上只是计算资源的一种调度手段和封装。如何构建高性能，低耦合，高内聚的技术架构，优化系统的资源利用率，还依赖于工程师对计算机运作方式的理解，包括对硬件内部的运作方式和为硬件保驾护航的底层软件。
因此，我们开启一个新的主题——计算机底层与软硬件融合。
最后回答一个被读者们问到的问题：为什么不提OpenStack?
答案很简单：因为OpenStack逐渐走向没落，未来的云计算的世界是属于大型公有云及与大型公有云同构的专有云平台的，对于政企等关系国计民生的用户而言，专有云是八九点钟的太阳，而选择openstack云则是选择了弯路。
