老夫先将这个小系列的前两篇内容链接奉上，方便感兴趣的朋友一气读之。

揭秘大数据 | 19、软件定义的世界-CSDN博客 

揭秘大数据 | 20、软件定义数据中心-CSDN博客

今天，书接上文，开聊软件定义计算的那些事儿！

虚拟化是软件定义计算最主要的解决途径。

虽然类似的技术早在IBM S/360系列的机器中已经出现过，但是真正走入大规模数据中心还是在VMware公司推出基于X86架构处理器的全虚拟化产品之后，随后还有Microsoft Hyper-V、Citrix XEN、Redhat KVM、Sun VirtualBox（现在叫作Oracle VM VirtualBox）等商业或开源解决方案。

虚拟化是一种用来掩蔽或抽象化底层物理硬件并在单个或集群化物理机之上并发运行多个操作系统的技术。

虚拟机成为计算调度和管理的单位，可以在数据中心，甚至跨数据中心的范围内动态迁移而不用担心服务会中断。

基于虚拟机技术的虚拟化计算（见图1）有三大特点，具体如下：

(1)支持创建多个虚拟机，每个虚拟机的行为与物理机相似，各自运行操作系统（可异构）与程序。

(2)在虚拟机与底层硬件间有一层被称为虚拟机管理程序，它通常有内核与虚拟机管理器（Virtual Machine Manager，VMM，又称作Hypervisor）两大组件。

(3)虚拟机可获得标准硬件资源（通过虚拟机管理程序模拟及提供的硬件接口、服务来实现）​。

虚拟机管理程序包含以下两个关键组件：

(1)虚拟机管理程序内核提供与其他操作系统相同的功能，例如进程创建、文件系统管理、进程调度等。它经过专门设计后用于支持多个虚拟机和提供核心功能，例如资源调度、I/O堆栈等。

(2)VMM负责在CPU上实际执行命令，以及执行二进制转换。它对硬件进行抽象化，以显示为具有自己的CPU、内存和I/O设备的物理机。每个虚拟机会被分配一个具有一定份额的CPU、内存和I/O设备的VMM，以成功运行虚拟机。虚拟机开始运行后，控制权将转移到VMM，随后由VMM开始执行来自虚拟机的指令。

虚拟机管理程序可以分为两种：

1）裸机虚拟机管理程序
2）托管虚拟机管理程序

见下图2所示：

(1)裸机虚拟机管理程序：这类虚拟机管理程序直接被安装在X86硬件上。裸机虚拟机管理程序可直接访问硬件资源，因此，它比托管虚拟机管理程序的效率更高——这一类型是规模化数据中心的主要虚拟化形态。

(2)托管虚拟机管理程序：这类虚拟机管理程序是作为应用程序在操作系统上进行安装和运行的。它由于运行在操作系统上，因此支持最广泛的硬件配置——它更适用于测试人员通过模拟来测试不同类型的操作系统平台。

容器计算是软件定义计算虚拟化的新锐势力，它与虚拟机技术的最大区别在于不需要虚拟化整个服务器的硬件栈，而是在操作系统层面对用户空间进行抽象化，因此我们称其为操作系统级虚拟化，以区别于之前的基于硬件虚拟化的虚拟机技术。

基于容器计算的用户应用不需要单独加载操作系统内核。在同样的硬件之上，可以支撑数以百计的容器，但是只能支撑数以十计的虚拟机。虚拟机架构与容器架构的对比如图3所示。

容器计算最早可以追溯到UNIX系统上的Chroot（1979年）​，当时只是单纯为单个进程提供可隔离磁盘空间。1982年这一特性被实现在BSD操作系统之上。2000年FreeBSD v4推出的Jails则是最早的容器计算，在Chroot基础之上，它又实现了更多面向进程的沙箱功能，例如，隔离的文件系统、用户、网络。每个Jail有自己的IP地址、可定制化软件安装与配置等。这可比Docker早了整整13年，比Docker（v0.9之前）一度依赖的LXC[其为Linux Container（容器）的简写]早了8年，比Cloud Foundry的Warden早了11年，比Solaris Containers早了4年，比Linux OpenVZ早了5年，比Linux cgroups早了7年（cgroups基于谷歌公司于2007年贡献给Linux内核的Control Groups——其前身是谷歌公司内部在2006年的Process Container项目，目的是可以对进程使用的系统资源高度可控）​。

 
容器技术因其具有比虚拟机技术更高的敏捷性、更优的资源利用率而备受初创公司、互联网企业青睐。但是和任何新兴技术一样，容器技术面临的挑战（弱点）主要有三大方面：

(1)安全与隔离。

共性内核意味着位于同一内核上的任何一个容器被攻破都可能会影响剩余的其他所有容器。

(2)管理复杂性。

在虚拟机的基础上，容器在数量上又上升了一个数量级，而这些容器之间又可能产生复杂的对应关系，因此对容器系统进行有效管理的需求显然是对现有管理系统的一个巨大挑战。

(3)对状态服务、应用的支持。

容器技术对无状态、微服务架构类型应用的支持可谓完美，可是对数据库类、ACID类型服务的支持还远未成熟。我们将常见容器技术方案进行比较，见下图/表4:

 
上表中Linux LXD是基于LXC构造的，准确地说是提供了一套优化的容器管理工具集（以及Linux distro分发模板系统）​；ThinApp是VMware公司的应用虚拟化解决方案，面向Windows应用；RKT(appc)则是CoreOS公司联合业界推出的与Docker既兼容又对抗的容器虚拟化架构。Docker在早期阶段也是基于LXC的，不过随后推出了自己的libcontainer库。图5展示了Docker容器虚拟化功能接口，也能很好地说明Docker的基本架构。

作为容器行业的领头羊，Docker公司对容器计算寄予了厚望，他们认为未来的互联网架构不再是原有的基于TCP/IP的4层（物理层、IP层、TCP/UDP层、应用层）架构，而是4层逻辑实体：互联网硬件层、互联网软件（容器）层、互联网应用层；程序员层，具体如图6所示：

这样的分层显然极大降低了网络、硬件、系统架构的复杂性，以服务为中心、以软件定义为中心、以应用特别是微服务架构为中心、以面向程序员为中心，最终实现更敏捷的开发、更短的交付/上市时间、更高的系统效率以及更好的全面体验。

我们有理由相信，假以时日，容器技术的作为会更大，不过在相当长的一段时间内容器技术更侧重于第三平台的应用，特别是无状态类应用与服务。而虚拟机技术更多地满足第二平台的应用，特别是传统企业级应用。显然，容器技术与虚拟机技术会各自满足不同类型的应用需求，或业界的巨头们通常会把两者结合起来用于一些典型业务场景，例如在虚拟机之上运行容器，或者在一个资源管理平台上允许并置容器、虚拟机与逻辑，并进行统一调配、管理……

容器计算显然不会是软件定义计算的最终形态，2015—2016年期间又出现了两种架构：

1）无主机计算

2）统一内核

无主机计算以亚马逊公司的AWS Lambda服务为代表，让程序员或云计算/大数据服务的用户不再纠结于底层基础架构，而是专注于业务需求的描述。它有着比容器计算更高的敏捷性，向按需计算又迈进了一步。软件定义计算的演进如图7所示：

 
统一内核则是把已经被容器虚拟化简化的技术栈再进一步精简。图8展示了从容器到统一内核的精简过程，很显然，统一内核缩减了操作系统内核的足印，也简化了每个容器化应用对底层的依赖关系，由此带来了更快的部署、更高的迁移运行速度。这也解释了为什么Docker要在2016年年初收购初创公司Unikernels Systems（开源库操作系统MirageOS的开发者）​。

至此，我们回顾并展望软件定义计算的发展历程：
始终是向着不断追求更高效的系统处理能力、更敏捷的业务需求实现、更高的性价比、更好的用户体验的目标前进，而这也同样适用于人类社会进步的普遍价值追求。

此外，利用普世价值的说辞行欺世盗名之实也并非少见，我们看到很多企业、团队、创业者沉迷于拿来主义，不愿意在底层软件开发做任何实际投入，大公司做KPI驱动的开源，小公司在开源项目上包层“皮”就可以到资本市场上横冲直撞……当投资人评估一个项目的价值是靠GitHub的评价（表现为星星数量）来量化的时候，我们就知道软件定义世界依然是任重而道远的。

（文/Ricky - HPC高性能计算与存储专家、大数据专家、数据库专家及学者）

· END ·