unikernel到底是什么呢？
Wikipedia上有定义，我们把第一段摘抄过来：
Unikernels are specialised, single address space machine images constructed by using library operating systems. A developer selects, from a modular stack, the minimal set of libraries which correspond to the OS constructs required for their application to run. These libraries are then compiled with the application and configuration code to build sealed, fixed-purpose images (unikernels) which run directly on a hypervisor or hardware without an intervening OS such as Linux or Windows.
翻译过来就是:
Unikernel是使用libOS(library os)构建的具有专门用途的单地址空间机器镜像。为了支撑程序的运行，开发者从模块栈中选择最小的类库集合，构建对应的OS。类库和应用代码、配置文件一起构建成固定用途的镜像，可以直接运行在hypervisor或者硬件上而无需Linux或者Windows这样的操作系统。
讲的太过于晦涩，看完了还是没办法理解到底是什么意思，到底什么是libOS？专门用途？单地址空间又是什么意思？从模块栈选择最小类库集合是什么东东？最重要的是，unikernel到底要解决什么问题，能带来什么价值？
Library OS
根据kernel设计风格的不同，可以把操作系统分成很多种类，有Linux使用的宏内核，Symbian使用的微内核，Windows使用的混合内核等等。其中有一种内核类型叫做“外内核”(Exokernel)，非常的与众不同。传统的内核都对硬件进作了抽象，硬件资源和设备驱动程序都隐藏在硬件抽象层下面，应用程序不能直接操作硬件，只能访问通过硬件抽象层提供的接口。Exokernel的设计思路是尽可能减少抽象层次，允许应用程序直接访问硬件，比如直接请求特定的物理内存空间，所以Exokernel内核非常小，只负责保护和分配系统资源。应用程序过来请求资源，Exokernel看看资源是否空闲，如果空闲，直接交给应用，至于应用怎么访问是它自己的事，Exokernel不管这个。
用了Exokernel难道还要自己写各种硬件驱动，自己实现网络协议栈吗？解决这个问题的办法就是Library Operation System。首先对硬件设备的驱动进行抽象，也就是定义一组接口，再针对不同硬件设备提供实现的library，在编译的时候，根据硬件配置引入合适的library，应用和library一起构成了整个系统。
先不考虑其中的细节，把诸如libOS怎么初始化、任务调度怎么做、进程间怎么通信等问题压在心里，单从架构上看，由于减少了抽象层，可以直接操作硬件资源，并且所有操作都在同一个地址空间里（Exokernel之上），libOS可以实现更好的性能。另一方面，由于只包含应用程序和需要的library，没有任何其他的冗余，可以做到更少的资源占用。缺点呢？由于没有“内核”，很难做多进程的资源控制。另外，由于硬件设备发展迅速，需要不断的适配新的硬件。
Exokernel一直处于学术研究的状态，没有真正进入实用阶段。
虚拟化的兴起和Unikernel
云计算已经是个耳熟能详的概念了。最初的云主要是IAAS服务，其基础是操作系统虚拟化，在一台物理机上虚拟出多个虚拟机，每台虚拟机都像一台真正的机器一样，运行标准的无需任何定制的操作系统。虚拟化的出现，刚好解决了Library OS的两个主要缺陷：资源控制和硬件适配的问题。
2013年Xen孵化了Mirage OS，后者是一个基于libOS理念设计的操作系统。Mirage OS自称是"Cloud Operating System"：用于虚拟机环境里的专门用途的轻量级操作系统。Mirage OS完全依赖底层虚拟化硬件，解决了现实世界需要适配大量硬件驱动的问题。并且提出了“单一用户应用”(single purpose application)，一个Mirage OS里只运行一个应用程序，资源隔离当然也是依靠底层虚拟化完成。
上图是Unikernel和传统虚拟化工作方式的对比。相比传统的虚拟化运行方式，MirageOS包含了更少了抽象层。
Unikernel这个概念也是从Mirage OS这里提出来的，在Xen的官网上，Cloud Operating System和Unikernel就是一个概念。
说道这里，很多人可能还是对Unikernel这个概念有点模糊，其实可以这样理解：
-
Unikernel=运行在Hypervisor之上的libOS
-
libOS=应用+一堆libraries一起构建出的操作系统
为了更直观的理解Unikernel，不妨以Mirage OS为例，看看它长什么样。
上图是Mirage OS的编程模型，Mirage相关的工具可以分析代码中的依赖，这里的依赖既有传统意义上的依赖，也有libOS特有的用于形成操作系统的Libraries。所有的依赖下载到本地，开始编译、链接，熟悉Java的同学可以按Maven的工作方式理解，只不过Mirage更高端，可以直接从源码分析依赖，而不用特地声明依赖。编译链接之后生成的不是一个可执行文件，而是一个完全独立的操作系统，可以直接在Hypervisor上运行的操作系统。
Unikernel的优缺点
回到我们最初提的问题：Unikernel到底要解决什么问题，能带来什么价值？前面讲libOS的时候说过，libOS的优点在于
-
性能更好。相比于Linux/Windows这种通用操作系统，Unikernel减少了复杂的软件抽象层。由于“内核”和应用程序没有隔离，运行在同一个地址空间中，消除了用户态和内核态转换以及数据复制的开销。最后，构建时可以采用全局优化技术，比如前面的MirageOS，可以进一步优化性能。
-
除了性能外，Linux/Windows里通常包含了太多东西，不论你需不需要，都会包含在系统里，比如USB驱动，在云环境中肯定是用不到的，比如各种文件系统，实际上用到的也就一两种。Unikernel里只包含了程序真正依赖到的东西，无论镜像，还是启动后所占用的资源都非常小。
-
启动快，这个就很好理解了，因为包含的东西少，系统层初始化非常快，通常是几ms到十几ms，真正的时间会用在应用程序本身的启动上。
-
更安全，因为Unikernel里运行的内容少，减少了潜在漏洞数量，相对攻击面就很小。
这样看上去Unikernel简直完美了，是不是？当然不是，也有一些反对Unikernel的声音，认为运行内容少不能证明更安全，另外Unikernel最大的问题在于“Unikernel是完全不可调试的”。
“不可调试”或许是Unikernel最致命的问题。在Unikernel这种模式下，启动之后直接进入到应用程序中，出问题之后唯一的解法就是重启（喜欢就买，不行就分，多喝点水，重启试试）。
上图是在unikernel系统osv下运行redis的截图，虚拟化方式为virtualbox。就这么一个界面，如果Redis开始就无法访问，如果访问过程中偶尔出现网络连接失败或者突然无法连接，完全没有办法去分析排查。原先在Linux上熟悉的排查问题的方式和熟悉的工具都没法使用了，没法查看和修改配置文件、没法查看网络连接数，没法tcpdump，真的只能重启了。
Unikernel和容器
说到启动快、镜像小和资源利用率，就不得不提最近很火的Docker。Unikernel自己也一直在跟Docker进行比较，有观点认为Unikernel会替代Docker。Unikernel运行在Hypervisor上，相比共享内核的Docker，可以获得更好的隔离性和安全性。
上图是虚拟机、Unikernel和容器的运行环境对比。
设想我们能用类似Docker Build的方式，通过简单的一条命令就可以构建出Unikernel镜像，这个镜像会非常小，可以快速的分发。这个镜像可以运行在虚拟化环境中，只要你有Xen或者Kvm，就能把这个镜像运行起来。当然，这还不够，我们再搞一套编排服务，可以方便的管理集群和应用，有了这些，真的可以把Docker替换掉了......。不过目前来说这些还都是假设，Unikernel还不够成熟，尤其是生态方便，缺乏简单易用的工具，缺乏配套的生态工具。
各种Unikernel系统
前面提到过Mirage OS，但没有详细说。Mirage OS有个很重要的特点是它要求应用程序必须用Ocaml语言编写，这样它的编译器才能追踪代码依赖，寻找对应的library。这个限制太要命了，不说还得学一个Ocaml，大量的老代码怎么办？凭这一点，Mirage OS不太可能真的应用到生成环境里。
除了Mirage OS之外，还有很多其他的Unikernel系统，ClickOS、Clive、Drawbridge、Graphene、HaLVM、HermitCore、IncludeOS、LING、OSv、Rumprun、Runtime.js，其中Graphene和OSv可以兼容Linux程序，Rumprun则兼容POSIX标准。
285
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
