软件定义的计算

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

虽然类似的技术早在IBM S/360系列的机器中已经出现过，但是真正“平民化”，走入大规模数据中心还是在VMware推出基于x86架构处理器的全虚拟化（Full-Virtualization）产品之后。

随后，还有Microsoft Hyper-V、Citrix XEN、Redhat KVM（Kernel-based Virtual Machine）、Sun VirtualBox（现在改叫Oracle VM VirtualBox）、QEMU（Quick EMUlator）等商业或开源解决方案。

虚拟化是一种用来掩蔽或抽象化底层物理硬件并在单个或集群化物理机之上并发运行多个操作系统的技术。虚拟机成为计算调度和管理的单位，可以在数据中心，甚至跨数据中心的范围内动态迁移而不用担心服务会中断。

图： 虚拟化的计算

基于虚拟机技术的计算虚拟化有三大特点：

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

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

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

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

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

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

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

 

·裸机虚拟机管理程序

·托管虚拟机管理程序

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

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

容器计算是软件定义计算虚拟化的新锐势力，它与虚拟机技术的最大区别在于不需要虚拟化整个服务器的硬件栈（Server Hardware Stack），而是在操作系统层面对用户空间进行抽象化，因此我们也称其为OS-level Virtualization（操作系统级虚拟化），以区别于之前的基于硬件虚拟化的虚拟机技术。基于容器技术的每个用户应用不需要单独加载操作系统内核（见下图），在同样的硬件之上，可以支撑数以百计的容器，但是只能支撑数以十计的虚拟机。

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

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

· 安全与隔离：共性内核意味着在同一内核上的任何一个容器被攻破都可能会影响剩余的所有容器！

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

· 对状态服务、应用的支持：容器技术对无状态（Stateless）、MSA类型应用的支持可谓完美，可是对于数据库类、ACID类型服务支持还远未成熟。

下表列出了常见的操作系统级容器虚拟化技术及功能比较：

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

作为容器行业的（曾经的）头羊，Docker公司对于容器计算寄予了厚望，他们认为未来的互联网架构不再是原有的基于TCP/IP协议的四层（物理硬件层、IP层、TCP/UDP层、应用层），而是由如下图所示的四层逻辑实体取代：

·互联网硬件层

· 互联网软件（容器）层

·互联网应用层

·程序员

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

当然，提到了Docker，不得不提一下K8S (Kubernetes)，两者的区别可以单独写一篇长文了。简而言之，K8S“天然”集成了分布式，而Docker是基于单节点的。也就是说，Docker之间所形成的网络的管理要用户自己来完成。或许是现在大家都太懒了，这一两年Docker有些式微，也可能是公有云太能忽悠了，很多人都信了，但是有多少人能管理好K8S的生产环境，这个还是个问号 -- 并且有多少环境的规模大到你要想Google云一样用K8S来管理呢？

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

容器计算显然不会是软件定义的计算的最终形态，在2015~—2016年又出现了两种新的概念（架构）：

·Serverless Computing（无主机计算）

·Unikernels（统一内核）

前者以Amazon公司的AWS Lambda服务为代表，让程序员或云、大数据服务的用户不再纠结于底层基础架构，而专注于业务需求的描述，它有着比容器计算更高的敏捷性，向着按需计算又迈进了一步（见下图）。

如上图所示，很显然，Unikernels缩减了操作系统内核的足印（Footprint），也简化了每个容器化应用对底层的依赖关系，由此带来更快的部署、迁移运行速度—这也解释了为什么Docker在2016年年初收购了初创公司Unikernels Systems（开源库操作系统MirageOS的开发者）。

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

标签：容器,定义,虚拟化,管理程序,虚拟机,计算,软件,Docker,操作系统
来源： https://blog.csdn.net/Ultipa/article/details/118484416