【编者的话】从2013年Docker发布，到2014年的全面引爆，Docker给了我们一个明显的感觉——容器正在成为新的“银弹”，而Amazon AWS引爆的虚拟机技术已成了昨日黄花。
审视一下Docker，我们从中学到了什么——Docker的关键点在于它是以App为中心的运行环境的封装，自从有了Docker，开发、测试、生产都可以使用完全相同的环境部署，生产环境需要维护的很多东西都在开发时就固化在镜像内了，维护难度下降，一致性和可确定性提升，持续交付不是梦。
所以，对虚拟机在容器面前的苛责，用一句话说就是——“虚拟机”的问题不在于“虚拟”，而在于“机”。自然地，我们会想可不可以做App为中心的虚拟化呢？
Hyper就是这样一种App-Centric的虚拟化技术，我们完全摒弃了传统虚机上必须和物理机一样，运行一个完整OS这种看似显然的假设，我们让Docker Image直接运行在Hypervisor上。我们让一组容器直接启动在hypervisor上的时间达到350毫秒，并且还在进一步优化。而且所有这些，都是“开箱即得的”。
当然有人会问，有了容器为什么还要虚机。诚然，虚机并不是所有人都需要的，但是，虚机天然具备更好的隔离性；虚拟机也仍然存在于很多企业应用的协议栈中，这样一个依赖更少、开箱即得，而且还带有Pod、persist mode等附加丰富特性的应用，是不少场景中都需要的。而我们最期待的，就是去引爆新的容器服务——CaaS。
从 Docker 到容器服务
Docker 是这两年来，云计算领域最热门的创业项目，带动了整个 Container产业。他们最厉害的一点在于，开发者直接输出 Docker Image 或者 Dockerfile，测试、部署就可以做到高度一致，这里还是贴出对 @杜玉杰@华为开源 杜总的截屏的截屏：
随着Docker的普及，越来越多应用开始倾向于采用Docker的方式部署——操作系统将只用于承载Docker，提供辅助性功能，逐渐同质化，CoreOS，Redhat Atomic，Ubuntu Core 都在走向这个方向。而 IaaS 或者 PaaS 服务商们，必然向 CaaS——容器即服务转型，避免真的沦为自来水一样的基础设施。
Hyper——用虚机解决隔离问题
但是，Container的隔离性无法得到彻底解决（图片引自黄强的演讲）
于是就有了两个不同的选择——要追求性能，那么就将物理整机机出租给用户，但是这样做弹性有限，回收之后对系统的清理很复杂，而且用户可以接触到物理机、BIOS、网络，会产生一定安全隐患；或者出租虚拟机给用户——AWS ECS（EC2 Container Service）的选择，这样就损失了性能，而且用户其实对维护虚拟机的操作系统没兴趣。
这里我们要说的就是一个其他的选择——直接用虚拟机承载容器： Hyper = hypervisor docker image。
传统虚拟机的问题其实在于过于刻意模仿物理机，刻意要承载完整操作系统，启动一台虚拟机要若干秒，甚至几分钟，Image 有若干GB，加载传播都很慢，但其实根本没有这个必要，Hyper希望兼取两者的强项
Hyper 在启动方面开销很低，即使很入门的机器，也可以有很好的性能，比如在一个小盒子上，里面跑的是超低电压的 i3 CPU，启动所用的时延只有不到500ms——
而且 Hyper 的命令行用法和 Docker 很相似，简单到一个 run 命令就可以启动一个 docker image
Hyper 的实现架构是这样的
在虚机上，引导起 kernel 之后，用 init 进程直接启动 Docker Image，没有完整OS。所有的 image 的处理，在虚拟机外面准备好，插入虚拟机运行。
此外，有时，你需要 link 几个密切关联的 docker，这样的时候，hyper 允许你把它们放在一个虚机里面，通过mount namespace隔离文件系统，这称为 pod，这个概念来自于 kubernetes。
One more thing
Hyper 还有一些额外的好处，对基于虚拟机的私有云架构，利用 hyper， 可以让已经有的针对虚机的软件栈，更平滑地向容器化的方向迁移。而且，虚机可以更好地兼容已有 openstack 软件栈，主流设备厂商的网络和存储设备都提供了针对 OpenStack Neutron 和 Cinder 的驱动，可以快速构建私有云。我们也提出了 HyperStack ，也欢迎 OpenStack 社区的伙伴一起推动容器化的应用。
下一步即将到来的改进
- 多 Hypervisor 支持—— Xen 本周发布，Virtualbox 开发中， ESXi 在 Roadmap 上
- 跨平台——Mac 的支持在开发中
欢迎访问我们的主页： hyper.sh,
QA 环节
问：有木有尝试解决k8s的领域？答：我们目前支持 k8s 的 pod 格式，服务还需要进一步集成。
问：用现有的openstack docker集成怎样？
答： 这个，其实也是openstack社区在做的方向之一，实际上最终的解决方案基本上还是倾向于 虚机-容器 两层架构，我们倒是致力于变成一层虚机，各有优缺点吧。
问：持续集成怎么玩耍？
答：
- 我们是直接跑 docker image 的，所以直接用跑Docker 持续集成就没问题 。
- 也可以在集成测试里用 hyper 做 runtime
问：你们做的是不是把虚拟机和容器进行合理的融合？
答：合理不合理这个不好自己评价啊，我们实际上用了虚拟机和 docker image，没用 lxc 或 libcontainer。
问：hypervisor相当于是一个针对docker进行裁剪的虚拟机，不知道理解对不对？
答： 嗯，hyper 基本上是一个剪裁优化过的虚拟机。
问：你们今后会支持Hyper-V吗？
答：暂时没有，这方面经验不够丰富，今后可能会考虑。
问：有规模测试吗，或者性能测试？
答：测试结果比较符合大家对虚拟机性能的估计，CPU/Mem 子系统和物理机接近，IO系统，性能越好的 IO 设备越能看到一定性能差距，和使用方式（串行还是并发等）都有关系，不过如果大家用网络存储，或者套一层虚机的话，就没什么差距了。
问：看了一下安装貌似装docker只是为了去下载镜像，然后hyper去读镜像文件，有没有考虑去除Docker的依赖，这样应该更容易理解hyper的本质。
答：是的，目前是用 docker daemon 来拉 image 的，将来有一个计划去掉这个依赖，这样在 mac 上就也能跑了。
问：想了一下，应该是hypervisor的虚机缺省运行一个docker daemon，里面只有一个container，是不是这样呢？
答： 需要相互耦合的 docker image ，会组成一个 pod，放在同一个虚机上跑，并且放在同一个 network namespace 里，这样比 link 还要方便一些，直接 localhost 访问了。
问： 这么说，hypervisor的下层就是物理机了吧？听起来应该是自建私有云的企业比较需要它，另外就是IAAS本身适合用它构建？
答： 嗯，物理机上可以直接用，公有云做容器服务也可以用的。
问：相关的 image跑在一个虚拟上 那这些的images 的应用之间有隔离什么的吗？
答：这些 image 正常的话，属于同一个租户，相互间共享 ipc namespace 和 network namespace，只是有不同 mount namespace，文件系统是隔离的。
问：虚机的lightkernel是你们定制好的？
答： 缺省是我们定制好的，用户可以用自己的 kernel，不过用户自己的 kernel 可能性能略有差异。
问：coreos也可以装在物理机上，相对于coreos，hyper有哪方面的竞争力呢？
答： 感觉还是不太一样 coreos 更强调了os的维护，重点在 host os，我们强调了在 hypervisor 里运行 image，重点在 vm 和 guest kernel 这边，两者还是有很不错的合作前景的。
问：请问，基于虚拟机的私有云架构，迁移到hyper，会不会有承载不了的场景？
答：会有，容器化，或者说是面向应用的封装，会改变开发、测试、发布的流程，当你选择了演进，我们来帮你演进的平滑，但不是说可以完全不动，安装一下就一劳永逸地演进好了 。
问：即将到来的特性里面，xen、virtualbox支持是什么意思？
答：是让xen通过用hypervisor来降低消耗？ 各有所爱吧，有人喜欢 xen，有人习惯 kvm，至于 vbox 的支持，纯粹是为了帮助开发者方便在自己的计算机上跑的。
问：插一句，OpenStack 的 Magnum 算是基于 Hypervisor 的 Docker 引擎吗？
答： 那是个大项目啦，本身不是一个 docker 的执行引擎，但是我们觉得可以集成一下。
问：请问Hyper跟Intel前段时间发布的Clear Linux最大的区别是什么？
答：
- 作者不一样，嗯
- clear linux 是比较纯粹地直接替换 container 层，比较纯粹地性能优化，我们有一些 pod 一类的 feature
- clear linux 对某些内核特性乃至 CPU 特性依赖的比较强烈，做到了很好的效果，我们则强调了多 hypervisor 的可能性，以及 out-of-box 的工作
当然，clear linux 和我们的努力有更多的方面是一样的——大家都乐于去用虚机来承载应用为中心的镜像，这个趋势应该说是得到了认同的。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以上内容根据2015年6月9日晚微信群分享内容整理。分享人王旭，Hyper 联合创始人、CTO，曾就职于中国移动研究院、盛大云计算，以及担任 VisualOps CTO，从事分布式存储系统和DevOps工具开发等工作。王旭也是一位技术作者与译者，王旭的译文和文章主要涉及了Linux内核、文件系统、虚拟化、Hadoop、NoSQL与分布式存储系统等主题。是O'Reilly的《Cassandra权威指南》的译者。接下来，DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学参与。
有疑问加站长微信联系（非本文作者）
