谈谈Unikernel

导语Docker收购当下掌握Unikernel社区主导话语权的Unikernel Systems公司，从Docker创建libcontainer成为独立容器引擎，到创建Swarm成为独立集群方案，如今Docker开始投入真金白银，搅入Unikernel这片充满机遇的蓝海，这个举动足以看出Docker公司的远见。
　　前言
　　2016年初，与Docker相关的第一条重磅新闻莫过于在1月份Docker公司宣布收购刚刚在业界小有名气的微型操作系统公司Unikernel Systems。然而时至今日，当我们在技术圈内谈及Unikernel时，看到的仍然是许多人疑惑的表情。就像『容器』这个怪物刚刚出现在国内的技术社区时那样，到处都显得格格不入。
　　在Docker才诞生时，布道者们通常会拿出一张经典的虚拟机vs容器对比图，来讲解容器的好处。那么我们今天的话题开始前，我先搁上这张图，加上Unikernel的对比，镇一下场子。诸位坐好，且听我把容器与Unikernel的这点事儿慢慢道来。
　　
　　图1 虚拟机、容器和Unikernel
　　Unikernel是什么
　　『Unikernel』的概念在早在20世纪90年代的时候就已经有雏形了，它是一类特殊操作系统的通称，有点像我们现在所说的『容器』或者『Container』，是个概念层面的东西。最早的Unikernel操作系统原型是Exokernel和Nemesis，之后相对比较出名的有Xen社区主导的MirageOS、前Kvm开发者主导的OSv、以及由NetBSD公司开源的Rump Kernels。
　　在通常的操作系统中，系统的内核与用户的应用程序之间是有明确分界的，在Windows或是Linux中都有清晰的『内核态』和『用户态』定义，并通过『系统调用』的方式进行数据交换。这样做的目的是将操作系统与硬件打交道的功能与上层应用隔离，从而屏蔽其底层的差异性和复杂性。而在Unikernel的操作系统中是没有这种差别的，所有程序与底层的核心驱动都运行在一起，不存在运行时状态上下文切换的额外开销。在国内关于Unikernel的一些早期文章中将这种运行方式表述成所有程序都运行在『内核态』，这样的表述并不准确，因为Unikernel并没有专门的内核概念，而是将每个应用程序在编译时可以直接指定引入特定的驱动和核心library，相当于每个程序都是自带操作系统的，而且是单独定制裁剪的操作系统。
　　通过Unikernel系统方式构建出来的应用程序都是可以独立发布和直接运行在虚拟化平台上的，由于Unkernel系统原生不考虑多用户和多任务的复杂场景，因此可以做得十分精巧。一个应用服务就是一个操作系统，从而形成规模极大的操作系统集群。你可能会说，这不就是嵌入式操作系统么？单纯的从概念上看，Unikernel与嵌入式系统颇有几分相似，但Unikernel系统的运行环境通常是虚拟化的基础设施，而不是那些嵌入式硬件设备，稍后我们也会对这个关键性差异进行更深入的讲解。
　　说到这里，有些读者可能开始嘀咕了。在本篇开始时说到被Docker收购的那个『Unikernel Systems』与我们说所的『Unikernel』是同一个东西么？
　　其实不是。
　　被Docker收购的『Unikernel Systems』是一个由许多专注于Unikernel技术的极客们组成的，致力于推广和发展专用Unikernel产品的公司，总部在英国。两者的关系在于，Unikernel Systems公司（只有13名正式员工）同时也是Unikernel社区目前最主要的贡献者。Unikernel组织的官方网站是『unikernel.org』，而Unikernel Systems公司的官方网站是『unikernel.com』，从两者的网站风格上同样能看出千丝万缕的联系。