一个虚拟化老兵的Docker浅见

来自： http://dockone.io/article/1008

近来Docker原来越火，也吸引了我这个6年虚拟化从业者的注意。笔者对Docker的技术细节并不十分熟悉，也还在学习过程中。但笔者见证了虚拟化技术兴起的全过程，参考对照虚拟化技术，笔者对Docker为什么会在当前这个时间点火起来，Docker与虚拟化的技术对比，我们该怎么办等相关问题有一些自己的理解。意见不一定正确，欢迎拍砖。

Dokcer和Kubernetes为什么此时兴起

尝过虚拟化的甜，想来点应用的辣

随着x86服务器，KVM等虚拟化技术，以及OpenStack等IaaS管理平台的普及和成熟，VM可以在不同X86服务器厂商的硬件平台上在线无缝迁移了。硬件差异化不断缩小甚至消失，软件的重要性不断提升，IT真正进入"软件定义数据中心"的时代。并且人们发现，虚拟化后的IT在部署简单化，资源利用率，高可用性，维护便利性等方面收获了的巨大的收益。在这个背景下，IT部门提出了更高的要求，如何将应用在不同操作系统间实现无缝迁移，将开发和生产统一，做到"构建一次，到处运行"？并且能否让应用的部署，分发，负载均衡，高可用性，监控运维等方面也与虚拟机一样有更统一和更简单的方法呢？在这个时间点，Docker和Kubernetes出现了。

受微服务理念的“蛊惑”

微服务的思路不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相连接的微服务。一个微服务一般完成某个特定的功能。一些微服务还会发布API给其它微服务和应用客户端使用。运行时，一个微服务实例就可以是一个Docker容器，所以微服务天然需要Docker。微服务带来的好处有：第一软件工程上多部门更好协作，第二软件本身的扩展性更强。下图是微服务的搜索图，而我们知道Docker正是2013、2014年开始火起来，所以说微服务是与Docker是"相得益彰"的关系。

互联网公司DevOps们"摇旗呐喊"

DevOps兴起于互联网公司，基本理念是开发和运维合为一体，把开源工具拿过来再根据自己的业务特点稍加改动，测试通过后就上线支撑公司的产品和服务，并一边运维一边改进。

在DevOps出现之前，开发的工作流程是：市场调研，需求分析，系统设计，软件编码，单元测试，集成测试，系统测试，软件发布。运维人员的工作流程是：安装服务器，安装软件，配置软件，系统运维。很明显在老的模型中，运维人员地位低下，整天做着重复且枯燥的工作，并且开发和运维之间相互等待资源环境，软件版本，以及buglist。所以能不能运维专注于：1）提供，维护，监控平台；2）提供工具。开发利用运维的工具发布，维护自己的产品或服务呢？互联网的神仙/屌丝们很快发现，Docker的“构建一次，到处运行”正是他们需要的。

组织IT服务云化，平台化的"Next"

IaaS平台经过长时间的市场教育和技术教育，终于在2015、2016开始大规模的普及化和落地。政府，军工，事业单位，大中小型企业正如火如荼的进行着IT服务云化的过程。道路选择上中小型企业选择的是公有云，政府，军工，事业单位，大型企业一般都是自建私有云，像12306这种某时间段对IT有大规模溢出需求的单位，更适合的是混合云。

所有的组织都需面对客户，也都有的业务和数据。当今世界发展的趋势是：

1. 用户体验越来越重要（产品过度泛滥+烧钱的大有人在+别人都在"取悦"用户） ；
2. 业务更替越来越频繁（N个试错-->1个OK-->继续N个试错）；
3. 数据就是资产（不解释）。

所以呢，未来，IT服务需要更轻量（100~1000容器/Node），更高效（无GuestOS开销），更敏捷（DevOps理念）的平台。当前，考虑原有业务迁移的便利性，笔者认为以虚拟化为核心的云平台更胜任。

Docker与虚拟化的比对分析

浅层技术对比

对Docker稍有接触的人应该都见过下图，无需更多解释，Dokcer减少Guest OS这一层级，所以更轻量和更高性能。

深层技术对比

但用户很少直接使用Docker，而是要使用Docker为核心的平台系统，那其实对比项还是蛮多的。

从上表可以看出：a. 容器更高效，更敏捷，更好维护；b. 虚拟化在安全性和支持广泛性上有天然优势；c. 管理平台成熟度上，Docker和Kubernetes还有很长的路要走。

适用场景不同

对于高I/O要求的业务，例如数据库服务，建议部署Docker+物理机，因为在虚拟机中部署Docker，I/O性能将受到虚拟机的限制。对于虚拟桌面服务等强调租户权限和安全的业务，建议采用虚拟机方式，虚拟机的多租户强隔离特性，保证租户在拥有虚机root权限的同时，其他租户和主机的安全。此外，大部分业务系统将适用于虚拟机+Docker形式的组合，操作系统和Docker引擎采用虚拟机镜像封装，平台软件、业务组件等与业务相关软件采用容器镜像封装，为实现安全隔离和资源的高利用率，基本应该遵循：不同租户的业务运行采用虚拟机隔离，相似类型的业务部署在同一组容器上的思路。

我们该怎么办

首先介绍下笔者公司产品的情况，2011年开始我们以KVM为基础自主开发了OPV-Suite平台（IaaS云平台）和OPV-VDI（桌面虚拟化）产品，主要面向私有云客户，也向公有云服务商供应产品和技术。面对Docker的挑战，我们在确定还需在虚拟化产品继续深耕下去的同时，还该怎么办呢？

未来云产业格局分布

盗一张我的领导对云产业玩家的分析图。明显看出云产业链里的价值高地正在往云服务商处聚集，当然这个服务可以是公有云服务，也可以是私有云服务，还可以是混合云服务。

笔者一直认为，云消费者并不关心，你这个服务商使用的是虚拟化技术还是Docker，更不关心你自己写的还是基于开源平台改的。他关心的是你的服务是否可靠，是否稳定，是否便宜，是否安全。所以，根据你团队的特点，选择你们自己最擅长的技术，为云消费者提供有竞争力的服务，才是未来我们能否立足的核心。

技术上先看看别人家怎么做

用户不关心技术，我们的关心呀。首先声明，下表的分析数据是从2016容器大会上各厂商PPT上了解到的，必然既不全面也不深刻。

可以明显看出分为三个阵容：基于IaaS云平台，基于Kubernetes，基于Mesos；单从数量上看势均力敌。为什么会这样，笔者认为第一Docker还在迅速发展过程中，到底怎么做大家还没有统一的意见。第二各个互联网公司的技术团队擅长的东西并不一样。

我们怎么办

好，该得出结论了，我们该怎么办呢？

提供用户需要的云计算产品和服务，适合虚拟化的就虚拟化，适合Docker的就用Docker，并以自己团队最擅长的方式构建出平台来。

DCOS应该是怎样的？

笔者认为融合了虚拟化和容器的平台，我们暂且叫它DCOS（数据中心操作系统）的体系结构应该是这样的，篇幅有限，笔者将在第二篇文章中详细介绍各模块的功能和实现方法。


原文链接