笔者案

前阵子与行业内的朋友聊到企业云的建设路线选择事宜，在涉及到虚拟化和容器技术的选择议题上讨论的比较多，基于当前容器技术在某些场景中有替代虚拟化的趋势，市场上也听到一些声称容器可能会完全取代虚拟化的声音。我个人也在思考，这两种技术然道是完全对立的吗？容器真的会完全取代虚拟化技术吗？这里，我从一些基本的技术细节来洞察两者的差异性，并从应用场景的角度来分析企业该如何对这两种技术做出合理的选择决策。

常见 误区  

虚拟机资源占用高、启动速度慢、难以实现弹性伸缩

资源占用

实质上，这要从操作系统和应用两个层面去分析：

每个虚拟机是独立的操作系统，而容器则是多个容器共享一个操作系统，因此，虚拟机比容器实际上是多的是操作系统层的消耗，但这带来了容器所没有的高度隔离性。

比如在容器应用场景中，出于安全考虑，是不建议以root权限在容器中运行应用的，但随之而来就会导致已有应用的兼容性问题，而虚拟机却没有这个限制，无论在资源的隔离性和安全性方面都很好，所以，资源的消耗所带来的影响是相对的；

而应用程序的消耗呢？实际上这取决于应用本身，虚拟化本身并不会给应用带来太多的性能损耗，而容器技术本身也没有说能够让一个应用的资源消耗变少。

速度问题，分开来讲则包括启动速度和运行速度，容器启动速度快？

有一种说法是说容器能够秒级启动，我认为如果实践一下，你就会发现这秒级启动远比我们想象的时间要长，比如说，如果你是在一个没有运行过某个容器应用的节点上第一次运行它的话，那么很显然，数秒甚至数分钟的镜像下载过程是少不了的，这个时间可是取决于镜像的大小和网络的速度。

当镜像下载完，容器启动的时候，有心看看容器启动日志就知道，容器确实秒级启动，而里面的应用程序呢？

所以，这就是为什么Kubernetes提供了Liveness 和Readiness等健康检查探针的原因，容器秒级启动，应用程序却不是秒级启动的。

那虚拟机是否可以做到秒级启动？

当然，经过优化后的IaaS云平台架构，每个节点将无需重复下载虚拟机镜像，甚至可以直接从分布式存储卷上调用模板镜像快速启动新的虚拟机，这可比容器要快多了。

这就类似于kubernets节点在某个docker镜像经过第一次启动后本地缓存了该容器镜像一样，第二次就飞快启动的效果，只不过，虚拟机还需要经历一个操作系统启动的过程，但如果对操作系统进行适当的优化，其实也可以缩短到十几秒，如果效仿容器只运行一个应用的话，那其实启动速度差不太多；那运行速度呢？其实就相同的应用来说，其实是差不多的，容器并没有在应用上对已有应用进行改造，其运行速度还是取决于应用本身和底层硬件效能的。

难以弹性伸缩？

未必，包括AWS、Openstack都提供了autoscaling功能，虚拟机实际上早已经有弹性伸缩功能。只不过在虚拟化环境中，开发和运维人员要特别注意弹性应用所需的分布式架构和无状态化的考量，而这两点在容器的属性上是默认的。也就是虚拟化架构并没有告诉开发和运维人员需要将状态数据从虚拟机中拿出去，而容器的层次化存储模型则时刻提醒着开发人员将数据和有状态的配置放置在容器之外；而无状态化或轻量化往往又是弹性伸缩所必须考虑的重要因素之一。

所以，无论是容器还是虚拟机，都可以实现弹性伸缩，其核心就是要注意状态和数据的分离和共享问题。

虚拟化未来会消失、会被容器完全颠覆和取代吗？

这个问题也是具有片面性的。至少从目前来看，并非所有应用都适合在容器中运行，除此之外，虚拟化经过多年的发展，已经形成了完整的软件定义的云数据中心架构（通常称为IaaS）和众多相关的生态技术。无论是公有云还是私有云都是由虚拟化及相关技术生态逐步发展而来，包括软件定义计算（虚拟机）、软件定义存储（分布式存储，包括分布式的块存储和对象存储技术），以及软件定义网络（比如SDN、vFW、ELB等）。在现有的IaaS平台中无一不是成熟的解决方案，然道容器平台都不需要这些技术就能支持所有业务应用了？实际我们看到的情况是，独立的容器云平台往往可能要再造一遍轮子！

实际上，容器与虚拟机同属于计算形态，其之间的关系可以是从属关系（容器运行在虚拟机中），也可以是并列关系（如云平台提供物理机直接运行容器），两者所需的计算、存储、网络等技术完全可以通过已有的IaaS平台实现复用和共享，而不是对立或取代。而且，企业要兼容不同的应用形态，业务需要异构和共存、相辅相成，以满足企业不同阶段、不同层次的业务要求。

如何 选择  

那我们如何选择和应用这两种技术呢？在实际的实践当中，业务场景的需求，才是企业对不同技术选择的优先考量。

通常来说，稳态的应用适合虚拟机，敏态的应用容器更胜一筹，但也不完全都是这样。

为什么呢？

并非所有应用都适合用容器

比如传统的关系型数据库应用，则不是像容器场景中宣称的那样随时都可以随便重启的，而且，数据库的高可用也不是像Kubernetes那样挂一个服务发现就能解决的，而是应当使用数据库本身的高可用架构来实现以确保数据的可靠性和一致性！

场景化需求才是两种技术选择的关键

之前我们也说过，容器更适合于无状态化的应用，当然，轻量状态或者业务本身有一致性保证的逻辑存在的业务应用也是适合的，因为容器也有数据持久化技术（如kubernetes的StatefulSet 、PV等）。当然，如果一个应用本身启动速度和资源消耗与虚拟机无异的话（如传统的单体应用），那其实在生产上改造成容器的收效也不大，但在开发测试环境当中，却能一定程度上提高资源利用和提高重复测试的效率，所以还是要看应用场景来取用不同技术的，稳态和敏态的选择也并非绝对。

应用架构和选择趋势

从企业业务角度出发，业务应用已经逐步成为企业的关键竞争力，比如制造业的车联网、金融业的能力开放平台等，按照Gartner的预测，到2020年，企业75％的应用将是由企业自己开发而非购买，这意味着什么呢？

可以说，未来的所有企业，无论哪个行业，软件都将成为企业的核心竞争力之一，客户的需求从线下逐步转移到线上，由人与人的交互，逐步向人机交互甚至是设备间的自动化交互，因此，软件将成为其中最为关键的因素。

针对这样的趋势，企业提出了如下需求：

如何提高软件的迭代效率以加快产品推出速度，要求抢在竞争对手之前发布、或者缩短与竞争对手的发布时间；

快速上线后，还能根据客户的需求不断调整，要求平台的迭代速度可以按天计量，而不是过去的数个月甚至是半年一年才发布一次；

新业务可以随时扩展，随时给客户带来惊喜的同时不会影响到已有业务的稳定运行。

综上所述，其实这些需求已经超出了我们今天虚拟化和容器之间的话题，但从本质上看，又有所关联。

为什么呢？

微服务的提出首先在互联网公司对上述几个需求得到了验证，但同时，缺乏敏捷架构的支持带来的则是人肉运维的低效制约着微服务架构潜力与效能的发挥。

微服务虽然带来了业务的扩展性，但架构复杂程度也是骤然上升，这也是为什么传统业务如果没有业务压力并无需立即对传统业务进行微服务改造的原因；而面对微服务带来的复杂性挑战，模块的标准化、开发运维组织架构的调整则是必然的趋势，也就是说技术上要标准化，组织上要流程化：

技术标准化：IaaS提供统一标准化的基础资源构建，包括基础资源计算（虚拟机和容器）、存储、网络，稳态业务单元应用，如数据库，以及敏态业务单元如中间件、消息缓存等

组织流程化：也就是通常我们可能经常听到的DevOps，包括技术和组织两个层面：

技术方面包括主要体现在技术工具上，这部分的趋势是将各环节所涉及的工具链进行集成、链接，根据工作流程实现流水线式的作业模式，当然，业内也有很多厂商在将这些接口、流程进行聚合形成标准化的产品，帮助企业快速构建起工具链流水线。

组织方面则需要打通部门墙，融通开发、测试、运维，实现开发运维一体化的软件开发生产的企业组织体系，这就需要企业高层，特别是正在建设自有软件团队的企业CIO们要考量和规划的：包括部门组织的调整、软件生产文化的建设等，不单纯是技术的问题。

总结

总结下来，虚拟机和容器技术本身并不对立，也不存在谁取代谁的问题，关键是企业是否合理运用技术在合理的应用场景当中解决相应的技术问题，未来的企业级云平台也应该囊括对这些技术的支持，以满足企业对不同业务所需不同技术栈的灵活选择！

文｜启迪云计算解决方案顾问 林文炜