近年来，基于容器的基础设施正越来越深刻地影响着云计算的各种服务模式.在IaaS(infrastruc-ture as a service)层面上，容器技术抽象出主机操作系统，使得用户能够以较小的时间延时启动新的容器，并且在扩展的过程中无需担心底层架构.亚马逊公司的ECS[1](EC2 container service)即为此类应用的一个范例，其是一项高度可扩展的高性能容器管理服务，并支持业界主流的容器实现.在PaaS(platform as a service)层面上，谷歌公司推出的App Engine[2]服务同样采用容器技术，为用户提供了一个开发、托管网络应用程序的平台.在SaaS(software as a service)层面上，Guo等人[3]提出的云件(Cloudware)正是基于容器技术的轻量化特性，为传统软件上云提供了一种新思路.
容器具有虚拟机无可比拟的轻量级特性，其可以在几秒钟内被创建或者删除，从而在应用的动态扩展中具有更大的灵活性.现代容器管理器，如LXD[4]，Docker[5]，Kubernetes[6]等通过对容器的自动调度、扩展、存储，为使用者使用容器提供了更加便捷的方式.同时，容器技术与软件开发中的微服务架构结合使得后者的优势进一步放大，微服务鼓励软件开发者将整个软件解耦为较小的功能片段，并且这些功能片段能够应对外界的故障.容器进一步对这种解耦性进行了扩展，能够将软件从底层的硬件中分离出来.这种方式所产生的结果是应用程序能够更快地进行创建，并且更易于维护，同时又能够得到更高的质量.
随着软件设计中微服务架构的普及，越来越多的容器被作为承载应用程序的基础设施，然而现有容器技术存在的问题也逐渐显现出来.目前容器的设计具有很强的操作系统形态，虽然共享了操作系统内核，但仍封装了整套操作系统发行版的功能，这些功能在运行特定服务的时候并不会全部使用到，造成容器镜像内容冗余.其次，目前业界主流的容器管理器都采用预先构建运行时环境的策略，因而对多容器间相同运行时依赖文件(主要包括可执行二进制文件与共享库文件)在内存中的共享支持得并不彻底，造成一定程度上内存数据冗余.
内存资源和存储资源的有效利用对云计算提供商至关重要.一个典型的实例为近年来逐渐流行的无服务器解决方案(如亚马逊公司的AWS Lambda)，这种解决方案鼓励应用程序开发人员将其服务实现为无状态函数的组合，用预定义的编程语言编写，并由预定义事件(例如用户请求或数据库更改)触发.这导致了云计算厂商需要实例化大量装载相似运行时环境和相同编程语言库的容器.另一个场景是在目前的线上编程教育中使用容器为用户提供特定的编程环境已成为主流，某几种特定的容器实例会被大量开启或销毁.因此实现多容器间运行时依赖文件在内存中的共享不仅是有益的，也是现实的需求.
本文的主要贡献有4方面：
1) 通过建立库文件共享数学模型，研究了库文件的共享程度对容器最大启动数量的影响因素；
2) 提出了一种通用的超轻量级容器设计方案，通过细化可操作资源的粒度，使得支撑应用程序运行的容器运行时环境最小化；
3) 对本文提出的超轻量级容器的生存周期做出了明确定义，提出了超轻量级容器状态模型，设计了对主机内存资源最大化共享方法；
4) 基于内存资源最大化共享方法，实现了超轻量级容器管理引擎REG，在镜像体积、启动速度、内存占用等方面进行对比实验，验证了所提方法在大规模容器环境下的有效性.
1 相关工作
在过去数十年里，虚拟化一直是学界研究的热点并被广泛应用，其通过在多个操作系统之间划分物理资源来共享宿主机的运算、存储等能力.将虚拟化技术应用于构建高性能计算机系统，有助于帮助开发人员高效管理和使用高性能计算机系统，使其发挥最大效能[7].虚拟化是云计算得以实现的基石[8]，人们对虚拟化的研究主要分为基于管理程序的虚拟化(hypervisor-based virtualization)和基于容器的虚拟化(container-based virtualization)2条主线[9]，究其本质都是为了最大限度地利用计算机的物理资源.本节对这2条主线做简要梳理，并介绍近些年新涌现的一些虚拟化方法，以求探究虚拟化未来的发展趋势.
1959年，Strachey[10]提出在大型计算机中分时复用的概念，开启了虚拟化研究的历史.随后，IBM公司发起一个名为构建CP
CMS系统的项目，首次提出了虚拟机的概念并研制出了虚拟机设备System370[11]，自此便有越来越多的虚拟机管理程序被开发出来.管理程序在硬件级别运行，因此支持运行与主机系统隔离的独立虚拟机，由于虚拟机管理程序将虚拟机与底层主机系统隔离，在两者中运行的操作系统可以完全不同.Popek等人[12]将虚拟机管理程序分为2类：
1) 裸金属架构(虚拟机管理程序直接运行在物理硬件之上);
2) 寄居架构(虚拟机管理程序运行在宿主机操作系统之上).
但无论哪种架构，虚拟机中总要封装一个完整的操作系统，如图1(a)所示.这意味着虚拟机的镜像将会特别庞大，此外对虚拟硬件设备的仿真也会导致更多的性能开销.安全性是云计算中虚拟化技术的重要考虑[13]，不同厂商的虚拟化产品都会涉及必要的安全防护.
Fig. 1 Comparison of four virtualization methods
图1 4种虚拟化方式对比
与虚拟机管理程序相比，基于容器的虚拟化在虚拟化和隔离方面提供了不同的抽象级别.虚拟机管理程序抽象计算机硬件资源，这会导致硬件和虚拟设备驱动程序在虚拟化方面的开销，并且每个虚拟机实例中通常运行一个完整的操作系统,如Linux，Windows.相比之下，容器实现了操作系统级别的进程隔离，从而避免了这种开销.这些容器共享同一个底层主机上运行的操作系统内核，且每个容器内可以运行一个或多个进程.因此，容器被视为基于虚拟机管理程序的虚拟化的轻量级替代方案.图1(b)显示了基于容器的虚拟化体系结构.
由于多个容器使用共享的内核以及系统库文件，基于容器的解决方案优点之一是可以实现更高密度的虚拟化实例，同时与基于管理程序的解决方案相比，容器的磁盘镜像更小.容器技术也存在一些显而易见的缺点,由于依赖主机内核，基于不同内核实现的容器无法兼容(例如Windows容器不能在Linux主机上运行).另外由于需要将主机内核暴露给容器，使得容器并没有像虚拟机管理程序那样彻底隔离资源，这对于多租户场景来说存在一定的安全问题.基于容器的虚拟化存在多种实现方式，如Linux -VServer[14],OpenVZ[15],LXD,Docker，Rocket[16].基于Linux的容器主要利用操作系统内核机制中的控制组(cgroups[17])及命名空间(namespace[18])实现，前者主要负责提供多个进程组之间的资源管理功能，后者主要负责为容器隔离出一组私有的物理资源.Docker作为一个高层容器管理平台，因其便捷的用户操作接口，使得容器技术在近几年中广受追捧[19].
Harter等人[20]的工作显示了通过使用联合文件系统存储驱动，基于同源Docker镜像启动的容器能共享部分库文件与可执行二进制文件，从而更加充分地利用内存资源.Ferreira等人[21]通过构建数学模型的方法证明了库文件在多容器间的共享能显著提升内存利用率.
尽管基于虚拟机监控器的虚拟化与基于容器的虚拟化已成为云计算领域的实际基础设施，但两者都是在已经高度分层的软件栈中又增加了一层新的抽象.一些学者对此持保留态度：是否真的有必要每隔几年便增加一个间接和抽象的层，将应用程序的代码置于繁多的抽象层之上？Unikernel便是针对这一看法的解决方案.Unikernel是一种使用库操作系统[22](library operating system)构建的专用单一地址空间机器映像[23].开发人员需要选择其应用程序运行所需的操作系统最小库集合，然后将这些库与应用程序代码、配置代码一起编译，形成一个封闭的、用于特定用途的镜像，其基本架构如图1(c)所示.
Unikernal可以直接运行在硬件或者管理程序之上，不需要中间操作系统的干预.随着云计算与虚拟化技术的发展，构建单任务操作系统的想法也获得了足够的关注，众多学者不断为其寻找在云计算领域中的应用场景.Madhavapeddy等人[24]在2013年给出了Unikernal的一种具体实现，并称其为Mirage OS.随后Bratterud等人[25]在Madhavapeddy等人的工作上进行改进构建了IncludeOS，其具有更小的镜像体积与更高的资源利用率.另一个实现方案是OSv[26],它作为一个专门为云计算而设计的操作系统，同样只运行单个应用程序.但与Mirage OS等不同的是，OSv旨在运行在虚拟机管理程序(如KVM，Xen，VirtualBox，VMware)之上，这样它既实现了基于管理程序系统的隔离优势，又避免了虚拟化整个客户操作系统的开销.一般而言，OSv主要用来运行基于Java的应用程序以及基于Linux的CC++应用程序.
图1展示了虚拟机、Docker容器、Unikernal与本文提出的超轻量级容器引擎REG在结构上的差别.
2 容器启动数量影响因素分析
当前基于容器的应用通用实现方法是将程序依赖的所有库文件打包进容器，这种做法既保证了应用运行环境的完备性，也能很好地控制依赖文件的版本.但这种方式却可能导致将相同依赖文件重复加载进内存，造成内存冗余.共享库是一种消除内存冗余的方式，其通过合并相同内容的内存页来减少系统的实际内存占用.如今的数据密集型应用程序，内存是主要的限制资源，通过库共享可以提高服务器的利用率，进而提供服务的并发程度.
本节的工作中，我们通过建立数学模型，分析并量化了共享库与内存资源利用率之间的关系，发现容器间即使仅共享一小部分内容，就能对内存利用率造成非常显著的影响.该结果为本文后面构建超轻量级容器引擎提供了理论依据，也为最后的性能分析提供了参照.
本文将服务器内存资源的总量记为1.使用v表示单个容器除去依赖库文件的内存占用量，设每个容器所依赖的库文件的大小为r×v，则一个容器的内存占用总量为v×(1+r).例如r=1，表示容器50%的内存占用是由于加载了相关库文件导致的.因此，若容器之间能在同一台服务器上共享依赖的库文件，那么由于加载库文件导致的内存占用将会大幅减少.用f表示任意2个容器间的库文件共享比例，如果多个容器都需要依赖10个库文件，则f=0.1表示容器间平均共享1个库文件.分析的目的是研究内存利用率与变量v，r，f之间的关系，内存利用率可用单位主机中容器的最大启动数量表示.假设每个容器都具有相同的资源需求，并且依赖的库文件是从n个库文件中随机选择的m个，因而容器间库文件共享比例的期望
假设某库文件没有被某容器依赖的概率为
则该库文件被加载至内存的概率p=1-(1-f)N，其中N为服务器上运行的容器数量.于是可知服务器加载库文件的平均数量为np.易知每个库文件的内存占用量为
则服务器去除库文件占用之后的可用内存容量
基于上述假设，可推导出容器的最大启动数量N：
(1)
依据式(1)，分别固定v与r的值，可绘制出相应容器最大启动数量与v,r,f的关系图，如图2所示:
Fig. 2 Relationship between container startup quantityand v,r,f
图2 容器启动数量与v,r,f的关系
Fig. 3 Ultra lightweight container runtime state model
图3 超轻量级容器运行时状态模型
由图2可以得出结论，单个容器除去依赖库文件的内存占用量v以及容器对库文件的相对需求r决定了容器启动数量的上限.随着容器间的库文件共享比例逐渐增大，服务器能开启的容器数量也随之增加，并且较小的共享比例变化就能对容器启动数量造成显著影响.例如当v=0.005，r=2时，f仅从0变化到了0.1，就使得容器启动数量从730增长到了1 940.
3 超轻量级容器整体设计
在第2节的结论启发下，本节提出了一种全新的构建超轻量级容器环境的方法.
3.1 超轻量级容器运行时状态模型
超轻量级容器执行过程中，自身状态不断发生改变，本文将其生命周期定义为以下状态的转换过程，每种状态需要满足一定的条件约束.
Generating.根据代码中声明的运行时环境获取运行时依赖文件的过程.
Generated.首先需满足运行时环境完备性，即本地仓库已经包含了所有必要的运行时依赖文件，具备生成代码中声明的运行时环境的能力，且相关运行时依赖文件已被抽取至容器空间.
Running.运行时依赖文件被加载至内存，运行时环境生成，并执行特定应用程序.为保持容器的轻量级特性，此状态要满足内存中相同运行时依赖文件的唯一性.
Inserting.向容器中插入新组件的过程，此过程不能破坏软件运行时环境.
Stopped.容器中的进程处于终止状态，运行时环境被销毁，与Generated状态的区别是该状态保存了进程运行产生的文件.
Removed.销毁容器空间，删除相关运行时依赖文件.
各状态之间的转换如图3所示：
3.2 最大化内存共享与最小化运行时环境
传统容器设计中，镜像的作用是为容器提供一个固定的运行时环境.因不能事先确定容器中的应用程序，镜像在封装过程中通常会包含通用的基础程序.这些基础程序在生产环境中往往不会被全部使用，这样构建的运行时环境不仅造成内存和磁盘空间的浪费也让容器存在更多安全隐患.同时，基于镜像的容器设计也是内存中运行时库冗余的来源，Ferreira等人[21]的工作中提到，运行时依赖文件在内存中的冗余程度是影响内存利用率的显著因素.业界主流容器管理器Docker只支持特定存储驱动下基于同源镜像的容器在内存中的库文件共享，但对于其他存储驱动或非同源镜像启动的容器却无法实现，这导致了即使相同的运行时依赖文件也会被重复地加载至内存，造成内存空间浪费.
Fig. 4 Ultra lightweight container design framework
图4 超轻量级容器设计框架
本文提出的超轻量级容器构建方法摒弃了镜像的概念，提出运行时环境嵌入代码的容器设计理念，强调代码即镜像本身.使用者在编写应用程序时，只需在项目配置文件中指定该应用程序所依赖的运行时环境(如Python，NodeJs，JVM等).容器执行时，由容器引擎解析并动态生成使用者指定的运行时环境.于是内存进行容器资源加载时，资源粒度从原本固定的镜像层细化到了具体的可执行二进制文件与共享库文件，仅生成容器中应用程序执行所需的最小化运行时环境.同时，由于所有依赖文件都由本机文件系统向容器内统一映射，使得多个容器依赖的相同文件在内存中的索引节点相同，保证了内存中相同可执行二进制文件与共享库的唯一性，从而最大化内存资源的共享.这里要做的是在共享库文件的基础上保证容器间资源隔离，以及本地库文件的防篡改工作，第4节给出了该问题的详细讨论.图4给出了本文提出的超轻量级容器的基本示意，可以看出，每个容器仅包含自身需要的最基本运行时环境.
3.3 设计折中
本节提出的超轻量级容器设计思想主要关注于对运行时环境的去冗余，以及相同依赖文件在宿主机内存中的共享.通过细化可操作资源的粒度，一方面给予了程序构建者更高的操控程度，使之自由指定项目实际使用到的依赖文件，但同时这种程序构建流程也对开发者本身提出了更高的要求.另一个事实是，不同运行时环境往往依赖不同的可执行二进制文件与共享库文件，且相同库文件具有多种不同版本.这要求构建容器的同时需要实现一套完备的库文件管理系统，实现对依赖文件的正确分发，并且保证分发过程不被篡改，第4节的原型系统中给出了一种库文件管理系统的具体实现方法.总体来讲，本节提出的超轻量级容器设计理念适合海量用户环境下的大规模容器启动问题，并对该场景下的内存敏感性应用有较强的优化能力.
4 REG原型实现与实例研究
Fig. 5 Architecture difference on two types of containers
图5 2种容器的结构差异
如相关工作中所提到，传统的容器在操作系统之上进行隔离，容器间共享主机内核，各自空间中封装了完整的操作系统发行版、应用程序及其依赖项.这样的好处是剔除了操作系统内核的冗余，在资源固定的情况下能启动更多容器实例.本节基于上述超轻量级容器设计思想，构建了REG容器管理引擎，将共享思想进一步深化，所有容器空间中仅包含各自的应用程序代码，保证隔离性的基础上做到了运行时依赖文件层面上的共享，始终保证多个容器的相同依赖项仅在内存中存在1份，实现了理论上的最优解.REG容器管理引擎与当前主流容器管理引擎在结构上的差异如图5所示:
4.1 REG的整体架构
REG作为一个超轻量级容器管理引擎，对用户而言是一个简单的CS架构，用户通过客户端与服务器端建立通信.
REG的总体架构如图6所示，其主要包括REG Client，REG Host，Remote Registry这3个部分.
REG Client是用户与REG Engine建立通信的最佳途径，用户通过客户端发起对超轻量级容器的管理请求，REG Engine收到请求后解析用户指令，进行实际操作.支持的用户指令主要包括容器生成(generate)、移除(remove)、启动(start)、停止(stop)、组件安装(install)、组件卸载(uninstall).
Fig. 6 REG container management engine architecture
图6 REG容器管理引擎架构图
Fig. 7 RET file structure
图7 RET文件结构
REG Registry是部署在公共网络上的运行时模板(runtime environment template， RET)仓库，负责运行时模板的存储与分发.运行时模板的作用可以类比于Docker容器的镜像，Docker依据镜像生成容器，而REG则依据运行时模板获得相应的二进制文件及库文件，从而生成用户指定的运行时环境.如图6所示，REG Registry中共存在2种形式的文件：RET模板文件与共享库(.so)文件.其中RET文件又包含了可执行二进制文件本身以及对相应共享库文件的依赖说明.一个典型的RET配置文件如图7所示，该文件指明了可执行文件的名称及版本号，以及运行该可执行文件所依赖的共享库文件.
REG Host作为架构的主体部分，首先具备服务端的功能，有能力接收客户端发来的请求.REG Host内部的所有任务均由Engine来完成，主要包括对用户请求的解析、从远端仓库中拉取相应的运行时依赖(可执行二进制文件与共享库文件)、容器的生成与生命周期管理等.每次创建新的容器时，REG Engine将本地仓库中的运行时库文件以硬链接的形式复制到容器空间中，这样保证了每个容器中内容相同的运行时库文件总是拥有相同的索引节点，即这些文件仅需在内存中加载1份便可被多个容器共享.
4.2 安全性与隔离性
对于容器来讲，安全性可概括为2点：1)不可对宿主机造成影响；2)不会对宿主机上的其他容器造成影响.由于采用的底层技术相同，REG的安全问题本质上是容器技术的安全性问题[27].
REG对生成的容器实现了文件系统级防护.一些内核系统目录如sys，proc必须挂载至容器环境中才能使容器正确运行，这给恶意程序留下了潜在的攻击端点.因此在实现的过程中对这些内核系统目录实行只读挂载，保证宿主机文件系统不会受到容器的影响.同时，REG采用OverlayFS作为容器的文件系统，组成运行时环境的基础文件被放置在底层目录(lower dir)中.利用该文件系统的写时复制特性，所有容器共享底层目录，一旦需要向文件系统写入数据就引导其写到与该容器相关的另一个特定文件系统中.这样保证了本地仓库中的二进制文件与共享库文件不会被污染，任何单个容器的操作不会影响到其他容器.
隔离性方面，REG采用了与当前主流容器技术相同的Linux Namespace机制，通过命名空间隔离不同容器的可见资源.如对进程编号PID的隔离，它会将所有未运行在开发者当前容器里的进程隐藏，这使得容器内的程序无法感知外部进程，从而无法对外部进程产生影响.此外REG还实现了对挂载点与进程间通信的隔离，考虑到保持REG本身的轻量级特性，暂未对容器网络进行隔离，所有容器共享宿主机的网络命名空间.
4.3 REG实例运行过程
根据本文提出的超轻量级容器状态转换模型，从用户发出指令到容器启动完成的具体步骤为：
1) 参数解析.接收到客户端的指令后，REG Engine首先会做参数解析，获取到运行时模板类型及运行的命令.如‘REG run-t python@3.5.2-c binpython’指定了运行时模板类型为3.5.2版本的python，容器生成后要执行的命令为binpython.
2) 生成OverlayFS文件系统结构.REG Engine会在项目目录的.REG文件夹下生成overlayFS文件系统结构，主要包括lower，upper，work，mount文件夹.
3) 获取运行时模板.若本地仓库不存在用户指定的运行时模板，REG Engine会从公共的REG Registry拉取.由于运行时模板有时会依赖其他模板，所以通常这个过程是递归执行的.
4) 链接文件并挂载.确认构成运行时环境的二进制文件和共享库文件都在本地仓库存在后，REG Engine会将这些文件硬链接至刚刚创建的lower文件夹.之后以overlayFS的形式挂载步骤2创建的文件结构，同时将用户的项目文件挂载至mount文件夹.
5) 创建隔离空间.在容器空间隔离方面，REG同样采用了Linux内核提供的环境隔离的方法Name-space，主要做了挂载点、进程编号与进程间通信3个方面的隔离.考虑到要保持REG轻量级的特性，REG并没有在网络层面隔离，而是直接使用主机网络.同时利用系统调用指令pivot_root使得mount目录作为容器内的根目录，做到了文件系统的隔离.
6) 挂载proc文件系统.将proc文件系统挂载进来，为整体系统提供文件服务；
7) 执行运行命令.此时容器中已经具备应用程序所依赖的运行时环境文件，REG Engine执行运行命令将运行时环境实际建立起来.
5 性能评测
本文将构建好的REG系统与Docker容器管理引擎进行了对比测评，主要评测方面包括支撑容器文件大小、容器启动时间与容器运行时的内存占用情况.列出实验的硬件配置环境:
1) 处理器.Intel Core i7-8709G(8 MB缓存、4核、8线程).
2) 内存.64 GB LPDDR3.
3) 硬盘.500 GB PCIe NVMe高速固态硬盘.
4) 操作系统.Ubuntu 16.04 (64 b).
实验的软件及版本如表1所示：
Table 1 Experimental Software and Release Notes
表1 实验软件及版本说明
SoftwareVersionStorage Drive TypeDockerv 17.06OverlayFSREGv 0.1OverlayFS
5.1 镜像体积
Fig. 8 Comparison of image volume
图8 镜像体积对比
镜像是传统容器技术中的一个概念，指支撑一个容器运行及保存容器信息所需的文件结构.虽然REG中不在具有镜像的概念，但为了便于描述，这里仍将REG容器生成过程中依据运行时模板动态拉取的依赖文件称为其镜像文件.本节选取了5种具有代表性且被使用广泛使用的软件作为构建对象，其中包括Python,NodeJs、开源数据库MySQL、常用的Web服务器Nginx与Tomcat 9.使用Docker和REG分别构建以上软件相同版本的容器镜像，两者镜像体积对比如图8所示：
可以看出，由于剔除了运行时环境之外的冗余文件，REG构建的5种容器镜像都要小于Docker构建的相同镜像.相比于Docker镜像的大小，REG构建的5种镜像每种平均减少了18%的磁盘占用.较小的镜像体积有利于节省网络资源，使得镜像文件能在多主机间快速分发.
5.2 启动时间
通过容器启动前后系统时间戳对比可计算出容器的启动时间.本文在相同系统环境下分别独立启动100个相同类型的Docker容器实例与REG容器实例，并记录下每个容器实例的启动时间，结果如图9所示.Docker容器的平均启动时间为405 ms，REG容器的平均启动时间为373 ms，相比于Docker平均减少了7.9%的启动耗时.
Fig. 9 Comparison of container startup time
图9 容器启动时间对比
Fig. 10 Comparison of start storm performance
图10 启动风暴性能对比
真实生产环境中往往存在某一时刻批量启动大量容器实例的场景，即所谓的启动风暴.本文利用上述镜像，针对2种容器引擎分别连续启动了1 000个容器实例，并记录下了每个容器实例的启动时间，结果如图10所示.Docker容器最开始的启动时间为357 ms，但随着容器实例的增加，单个实例的启动时间上升明显，第1 000个实例启动时间达到了1 964 ms.REG容器实例的启动时间也有上升，但整体较为平稳，最后一个容器的启动时间为478 ms.该实验条件下Docker的平均启动时间是827 ms,REG的平均启动时间为405 ms，相比于前者减少了51%的启动耗时.
5.3 内存占用
内存资源的有效利用对云计算厂商至关重要，从第2节相关工作可以看出，近几年虚拟化技术的一大发展方向就是在保证算力与隔离的前提下尽可能节省内存资源.为了验证REG与Docker在内存使用方面的情况，本节延用上文构建完成的5种容器镜像，在相同的镜像种类中分别运行相同的服务，并记录下每个容器的内存使用情况.图11显示了本实验中每种容器在单独运行时的内存占用：
Fig. 11 Comparison of single container memory footprint
图11 单个容器内存占用量对比
为了验证多容器实例混合部署的情况，在配置相同的虚拟机环境下，分别使用REG和Docker引擎依次将上述5种容器启动，具体启动顺序如图12所示，同时分别在5个时刻记录内存使用情况.作为对比，本文还选取1台物理机上直接运行与上述容器相同的服务，各种环境中各时刻内存使用情况如图13所示.
Fig. 12 Container startup sequence
图12 容器启动顺序示意图
Fig. 13 Change in memory usage at different time
图13 不同时刻的内存占用变化
可以看出，由于Docker无法实现非同源容器的库文件共享，启动过程中5种容器占用的总内存与容器单独启动时的内存和大致相同，相比于在物理机上直接运行多占用了47.6%的内存资源.基于REG引擎启动的5种容器相较于容器单独启动共节约了460 MB的内存空间，且仅比在物理机上直接运行多占用了2.5%.该实验验证了REG引擎对库文件在非同源镜像间共享的支持特性，该特性也使得REG对内存空间的利用率几乎接近于物理机.
综上所述，本文所提出并实现的超轻量级容器方案在镜像体积(平均减少了18%)、启动速度(平均快了51%)、内存占用(平均减少了47.6%)等方面均有较大的提升，充分体现了本文所提出的方法的有效性.
6 结 论
本文提出了一种超轻量级容器构建方法，依据抽象出的容器运行时状态模型设计了一套新的基于容器的工作流程.同时基于上述构建方法，实现了REG超轻量级容器管理引擎，使得容器间能够最大程度地共享资源，从而达到运行时环境的最小化.最后通过实验验证了REG相较于Docker在文件体积、启动时间、内存利用方面都有提升.
本文实验中未验证新构建的REG容器管理引擎在磁盘IO、CPU利用率等方面的性能表现，未来工作将给予补充.同时，优化运行时环境模板的存储、分发，共享库与可执行程序的防篡改问题等也是未来工作的研究重点.
[1]Gilani M, Inibhunu C, Mahmoud Q H. Application and network performance of Amazon elastic compute cloud instances[C] //Proc of the 4th Int Conf on Cloud Networking. Piscataway, NJ: IEEE, 2015: 315-318
[2]Ciurana E. Developing with Google App Engine[M] New York: Apress, 2009
[3]Guo Dong, Wang Wei, Zhang Jinxuan, et al. Cloudware: An emerging software paradigm for cloud computing[C] //Proc of the 8th Asia-Pacific Symp on Internetware. New York: ACM, 2016: 1-10
[4]Senthil K S. Introduction to Linux containers[G] //Practical LXC and LXD. New York: Apress, 2017: 1-9
[5]Boettiger C. An introduction to Docker for reproducible research[J]. ACM SIGOPS Operating Systems Review, 2015, 49(1): 71-79
[6]Brewer E A. Kubernetes and the path to cloud native[C] //Proc of ACM Symp on Cloud Computing. New York: ACM, 2015
[7]Qian Lei, Li Hongliang, Xie Xianghui, et al. The application research of virtualization techniques for high performance computer systems[J]. Computer Engineering & Science, 2009, 31(S1): 307-311 (in Chinese)(钱磊, 李宏亮, 谢向辉, 等. 虚拟化技术在高性能计算机系统中的应用研究[J]. 计算机工程与科学, 2009, 31(S1): 307-311)
[8]Oludele A, Ogu E C, Shade K, et al. On the evolution of virtualization and cloud computing: A review[J]. Journal of Computer Sciences & Applications, 2014, 2(2): 40-43
[9]Morabito R, Komu M. Hypervisors vs lightweight virtualization: A performance comparison[C] //Proc of the 3rd IEEE Int Conf on Cloud Engineering. Los Alamitos, CA: IEEE Computer Society, 2015: 386-393
[10]Strachey C. Time sharing in large fast computers[C] //Proc of the IFIP Congress 1959. Paris: UNESCO, 1959: 336-341
[11]Creasy R J. The origin of the VM/370 time-sharing system[J]. IBM Journal of Research and Development, 1981, 25(5): 483-490
[12]Popek G J, Goldberg R P. Formal requirements for virtualizable third generation architectures[J]. ACM SIGOPS Operating Systems Review, 1973, 7(4): 121-121
[13]Wang Huaixi, Chen Jianxiong, Wang Chen, et al. Security threats to virtualization technology in cloud computing[J]. Journal of Huazhong University of Science and Technology: Natural Science Edition, 2012, 40(S1): 153-156 (in Chinese)(王怀习, 陈建熊, 王晨, 等. 云计算中虚拟化技术的安全威胁[J]. 华中科技大学学报: 自然科学版, 2012, 40(S1): 153-156)
[14]Des Ligneris B. Virtualization of Linux based computers: The Linux-VServer project[C] //Proc of the 19th Int Symp on High Performance Computing Systems & Applications. Piscataway, NJ: IEEE, 2005: 340-346
[15]Zheng Yuhao, Nicol D M. A virtual time system for OpenVZ-based network emulations[C] //Proc of the 25th Workshop on Principles of Advanced and Distributed Simulation. Piscataway, NJ: IEEE, 2011: 102-111
[16]Sanchez C. Rocket: CoreOS new container runtime[OL]. [2018-12-04]. https: //www.infoq.com/news/2014/12/coreos-rocket
[17]Paul M. Cgroups[OL]. [2018-05-10]. https: //www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt
[18]Michael K. Namespaces—Overview of Linux namespaces[OL]. [2018-05-10]. http://man7.org/linux/man-pages/man7/namespaces.7.html
[19]Wang Kai, Zhang Gongxuan, Zhou Xiumin. Research on container virtualization technology[J]. Computer Technology and Development, 2015, 25(8): 138-141 (in Chinese)(汪恺, 张功萱, 周秀敏. 基于容器虚拟化技术研究[J]. 计算机技术与发展, 2015, 25(8): 138-141)
[20]Harter T, Salmon B, Liu R, et al. Slacker: Fast distribution with lazy Docker containers[C] //Proc of the 14th USENIX Conf on File and Storage Technologies. Berkeley, CA: USENIX Association, 2016: 181-195
[21]Ferreira J B, Cello M, Iglesias J O. More sharing, more benefits? A study of library sharing in container-based infrastructures[G] //LNCS 10417: Proc of the 23rd European Conf on Parallel Processing. Berlin: Springer, 2017: 358-371
[22]Engler D R, Kaashoek M F, Gould L A, et al. Exokernel: An operating system architecture for application-level resource management[C] //Proc of the 15th ACM Symp on Operating Systems Principles. New York: ACM, 1995: 251-266
[23]Madhavapeddy A, Mortier R, Rotsos C, et al. Unikernels: Library operating systems for the cloud[J]. ACM SIGPLAN Notices, 2013, 41(1): 461-472
[24]Madhavapeddy A, Scott D J. Unikernels: The rise of the virtual library operating system[J]. Queue-Distributed Computing, 2013, 11(11): 30-30
[25]Bratterud A, Walla A A, Haugerud H, et al. IncludeOS: A minimal, resource efficient unikernel for cloud services[C] //Proc of the 7th Int Conf on Cloud Computing Technology and Science. Piscataway, NJ: IEEE, 2016: 250-257
[26]Cloudius Systems. OSv-the operating system designed for the cloud[OL]. [2018-05-10]. http: //osv.io/
[27]Liu Siyao, Li Qiang, Li Bin. Research on container isolation based on Docker technology[J]. Software, 2015, 36(4): 110-113 (in Chinese)(刘思尧, 李强, 李斌. 基于Docker技术的容器隔离性研究[J]. 软件, 2015, 36(4): 110-113)
