虚拟机有什么好处和坏处（虚拟机好处和缺点）

我做容器研究和容器化已经好几年了，从最初对容器的初步了解到积累了大量的容器迁移经验。

在向客户解释了容器技术后，我发现他对容器的理解有很多误解，容器不是虚拟机的替代品，它有一个非常具体的应用场景。

理解容器的六大误区

误区一：容器启动速度快，秒启动速度快

这是很多人在布道容器时经常说的一句话。人们经常开始一个 Nginx 这样的应用，真的可以很快启动。

为什么容器启动快，一是没有核心，二是镜像比较小。

然而，容器有一个主要的过程，即 Entrypoint，只有当主过程完全启动时，容器才能真正启动。

用一个比喻：容器更像人的衣服，人站起来，衣服站起来，人躺下，衣服也躺下。衣服有一定的隔离性，但隔离性不太好。衣服没有根(内核)，但衣服可以和人一起走。

所以按一个 Nginx 判断一个容器的启动速度有意义吗？对于 Java 安装在里面的应用程序 Tomcat，而 Tomcat 启动，加载 War，而真正的应用开始了。

如果你盯着 Tomcat 如果看日志，还是需要一些时间，根本不是秒级；如果启动应用程序需要一两分钟，仅仅谈论容器的秒级启动是没有意义的。

现在 OpenStack 中 VM 启动速度也优化得越来越快，启动一个 VM 当时，原来需要从 Glance 下载虚拟机镜像。

后来有了一个技术，就是在 Glance 与系统盘共享 Ceph 存储时，虚拟机镜像不需要下载，启动速度要快得多。

而且容器启动速度快的原因，往往建议使用非常小的镜像，比如 alpine，里面的很多东西都被剪掉了，启动速度更快。

OpenStack 虚拟机镜像也可以通过大量的切割快速启动。

我们可以仔细测量虚拟机启动的每一步，切断相应的模块和启动过程，大大降低虚拟机的启动时间。

例如在 UnitedStack 在一个博客里 https://www.ustack.com/blog/build-block-storage-service，我们可以看到这样的实现和描述:

使用原生的 OpenStack 需要创建虚拟机 1~3 分钟，改造后使用 OpenStack 仅需要不到 10 秒钟时间。

这是因为 nova-compute 不再需要通过 HTTP 下载整个镜像，虚拟机可以直接读取 Ceph 启动中的镜像数据。

这是因为 nova-compute 不再需要通过 HTTP 下载整个镜像，虚拟机可以直接读取 Ceph 启动中的镜像数据。

因此，对于虚拟机的整体启动时间，在优化良好的情况下，一般可以在十秒到半分钟内完成。

这个时间和 Tomcat 与启动时间相比，它不是一个负担。与容器的启动速度相比，没有质的差异。有些人可能会说，启动速度更快。

特别是对于挂断自修复的在线环境，不是分秒必争吗？关于自修的问题，我们下面再说一遍。

然而，虚拟机的一个优点是它具有良好的隔离性。如果容器是衣服，虚拟机就是房子。房子站在那里。不管里面的人是站着还是躺着，房子总是站着，房子不会跟着人。

使用虚拟机就像人们住在公寓里一样。每个人都有一个房间，不互相干扰。使用容器就像每个人都穿着衣服挤在公共汽车里一样。它似乎被隔离了。没有人能离开公共汽车。

综上所述，容器的启动速度不足以构成对 OpenStack 虚拟机的明显优势，但虚拟机的隔离，秒杀容器。

误区二:容器轻量级，每个主机运行数百个容器

很多人会做实验，甚至告诉客户容器平台有多好。你看，我们可以在一台机器上运行数百个容器。虚拟机根本做不到这一点。

但是一台机器运行数百个容器，有这样真实的应用场景吗？对于容器来说，重要的是内部应用程序，其核心是稳定性和高并发支撑，而不是密度。

在许多演讲会议上，我遇到了许多著名的处理双十一和 618 讲师通常会反馈当前的讲师 Java 应用基本上 4 核 8G 它是标准的。如果容量不足，少数通过纵向扩容进行，大部分通过横向扩容进行。

如果 4 核 8G 是标配，不到 20 一台服务器可以占据一台物理服务器，一台机器可以运行数百台 Nginx 有意思么？ 这不是一个严肃的使用场景。

当然，现在有一个很火的 Serverless 无服务架构，在无服务器架构中，所有自定义代码都被编写和执行为孤立、独立和经常细粒度的函数，例如 AWS Lambda 在无状态计算服务中运行。

这些计算服务可以是虚拟机或容器。对于无状态函数，需要快速创建和删除，执行函数的时间很可能很短。在这种情况下，容器比虚拟机有一定的优势。

目前，无服务架构更适合运行一些任务批量操作，利用过程水平的水平弹性能力来抵消过程创建和销毁的巨大成本。

在 Spark 和 Mesos 集成中，有一个 Fine-Grained 模式，在执行大数据时，任务的执行过程已经申请了资源。与在那里分配资源不同，这种模式只有在任务分配时才能分配资源。

优点是资源的灵活应用和释放能力，缺点是过程的创建和破坏或粒度过大，因此在这种模式下 Spark 操作性能会更差。

Spark 这种做法类似于无服务架构。你会发现，当我们最初学习操作系统时，我们说过程粒度太大，每次创建和销毁过程都太慢。

为了高并发性，后来有了线程，线程的创建和销毁有很多轻量级，当然还是觉得慢，所以有了线程池，就提前在那里创建了。使用时不需要现在创建，不使用时交回。

后来还是觉得慢，因为线程的创建也需要在内核中完成，所以后来有了协程，线程切换都是在用户态中进行的。

例如 AKKA，Go 使用协程，你会发现趋势是高并发，粒度越来越细，现在很多情况下需要进程水平，有一种风水轮流的感觉。

误区三:容器有镜像，可以保持版本号，可以升级回滚

容器有两个特点，一个是包装，一个是标准。有了容器镜像，可以包装应用程序的各种配置、文件路径和权限，然后像孙悟空说的“固定”一样，设置在包装的那一刻。

镜像是标准的，无论在哪个容器运行环境中，同样的镜像都可以恢复当时的那一刻。

容器的镜像和版本号，我们可以根据容器的版本号进行升级。一旦升级错误，我们可以根据版本号进行回滚。回滚后，我们可以确保容器内部仍处于原始状态。

但是 OpenStack 虚拟机也有镜像，虚拟机镜像也可以玩 snapshot 的，打 snapshot 当时，所有的状态都会保存在那一刻，而且 snapshot 也可以有版本号，也可以升级回滚。

容器似乎有这些特性 OpenStack 虚拟机都有，两者有什么区别？

虚拟机镜像大，容器镜像小。虚拟机镜像总是几十个 G 甚至上百 G，还有几百个容器镜像 M。

虚拟机镜像不适合跨环境迁移。例如，开发环境在本地，测试环境在一个地方 OpenStack 在另一个环境中，开发环境 OpenStack 上面，虚拟机的镜像迁移非常困难，需要复制非常大的文件。

容器要好得多，因为镜像很小，可以很快从不同的环境中迁移。

虚拟机镜像不适合跨云迁移。目前，没有公共云平台支持虚拟机镜像的下载和上传（安全原因、盗版原因），因此不同云或同一云之间的镜像 Region 之间，不能迁移，只能再做一个镜像，这样就不能保证环境的一致性。

容器的镜像中心独立于云。只要能连接到镜像中心，就可以在任何云上下载。由于镜像小，下载速度快，镜像分层，每次只需下载不同的部分。

OpenStack 对于镜像的优化，它基本上在一个云中工作。一旦跨越多个环境，镜像就更方便了。

误解4：容器可以自动重启容器平台管理，实现自修复

经常吹嘘容器的自修功能。因为容器是衣服，人们躺下，衣服也躺下，容器平台可以立即发现人们躺下，所以你可以迅速唤醒人们的工作。

而虚拟机是房子，人躺下，房子还站着。所以虚拟机管理平台不知道里面的人能不能工作，所以容器挂了会自动重启，虚拟机里的应用挂了。只要虚拟机不挂，很可能没人知道。

这些说法是正确的，但人们慢慢地发现了另一个场景，即容器中的应用程序没有悬挂，因此容器似乎仍在启动，但应用程序不再工作，没有反应。

当容器启动时，虽然容器的状态已经上升，但内部应用程序需要一段时间才能提供服务。

因此，对于这种场景，容器平台将为容器提供应用程序 health check，不仅要看容器在不在，还要看里面的应用能不能用。如果没有，可以自动重启。

一旦引入了 health check，和虚拟机没有太大区别，因为有 health check，虚拟机还可以看到里面的应用是否工作，不工作也可以重启应用。

还有容器启动速度快，秒级启动，如果能自动重启修复，那就是秒级修复，所以应用更可用。

当然，这种观点是不正确的。应用程序的高可用性与重启速度无直接关系。高可用性必须通过多个副本来实现。任何一个挂断后，都不能通过这个应用程序快速重启来解决。相反，在挂断期间，其他副本应立即接管任务进行解决。

在有多个副本的情况下，虚拟机和容器可以有多个副本，重启是 1 秒还是 20 秒，没那么重要，重要的是程序在挂断期间做了什么。

假如程序做的是无关紧要的操作，那就挂了 20 第二，没关系；如果程序正在进行交易和支付，请挂断 1 秒也不行，也必须能够修复。

因此，应用程序的高可用性取决于应用层的重试和功率，而不是基础设施层的快速重启。

对于无状态服务，在重试机制下，自动重启修复是没有问题的，因为无状态服务不会保存非常重要的操作。

对于有状态的服务，不仅不推荐重启容器，还可能是灾难的开始。

一个服务是有状态的，比如数据库，一旦在高并发场景下挂断，哪怕只有 1 秒，我们必须弄清楚 1 第二秒发生了什么，保存了什么数据，丢失了什么数据，不能盲目重启，否则很可能导致数据不一致，以后无法修复。

比如高频交易下的数据库挂了，按说 DBA 我们应该严格审查丢失的数据，而不是 DBA 在不知情的情况下，盲目重启，DBA 我还是觉得什么都没发生，最后很久才能发现问题。

因此，容器更适合部署无状态服务，可以随意重启。

容器部署有状态的容器并非不可能，但要非常小心，甚至不推荐。

虽然许多容器平台都支持状态容器，但除非您非常非常熟悉容器中的应用程序，否则平台通常无法解决数据问题。

当容器挂断时，你可以准确地知道丢失了什么，什么是重要的，什么是无关紧要的，并编写代码来处理这些情况，然后支持重启。

在主备同步的情况下，网易的数据库是通过修改的 MySQL 源代码，保证主备之间的数据完全同步，才敢在主挂的情况下，准备自动切换主。

为客户服务是一种非常不经济的行为，因为客户往往不知道应用程序的逻辑，甚至购买应用程序。

如果你使用一个状态容器，让它自动重启，当客户发现数据丢失时，它仍然会责怪你。

因此，自动重启状态服务并非不可用，需要足够的特殊性业才行。

误区五：容器可以使用容器平台进行服务发现

容器平台 Swarm，Kubernetes，Mesos 都是支持服务发现的，当一个服务访问另一个服务，都会有服务名转化为 VIP，然后访问具体的容器。

然而人们会发现，基于 Java 写的应用，服务之间的调用多不会用容器平台的服务发现，而是用 Dubbo 或者 Spring Cloud 的服务发现。

因为容器平台层的服务发现，还是做的比较基础，基本是一个域名映射的过程，对于熔断，限流，降级都没有很好的支持。

然而既然使用服务发现，还是希望服务发现中间件能够做到这一点，因而服务之间的服务发现之间使用容器平台的少，越是需要高并发的应用，越是如此。

那容器平台的服务发现没有用了么？不是，慢慢你会发现，内部的服务发现是一方面，这些 Dubbo 和 Spring Cloud 能够搞定，而外部的服务发现就不同了。

比如访问数据库，缓存等，到底是应该配置一个数据库服务的名称，还是 IP 地址呢？

如果使用 IP 地址，会造成配置十分复杂，因为很多应用配置之所以复杂，就是依赖了太多的外部应用，也是最难管理的一方面。

如果有了外部的服务发现，配置就会简单很多，也只需要配置外部服务的名称就可以了，如果外部服务地址变了，可以很灵活的改变外部的服务发现。

误区六：容器可以基于镜像进行弹性伸缩

在容器平台上，容器有副本数的，只要将副本数从 5 改到 10，容器就基于镜像进行了弹性伸缩。

其实这一点虚拟机也能做到，AWS 的 Autoscaling 就是基于虚拟机镜像的，如果在同一个云里面，就没有区别。

当然如果是跨云无状态容器的弹性伸缩，容器方便很多，可以实现混合云模式，当高并发场景下，将无状态容器扩容到公有云，这一点虚拟机是做不到的。

容器理解误区总结

如上图，左面是经常挂在嘴边的所谓容器的优势，但是虚拟机都能一一怼回去。

如果部署的是一个传统的应用，这个应用启动速度慢，进程数量少，基本不更新，那么虚拟机完全能够满足需求：

应用启动慢：应用启动 15 分钟，容器本身秒级，虚拟机很多平台能优化到十几秒，两者几乎看不出差别。

内存占用大：动不动 32G，64G 内存，一台机器跑不了几个。

基本不更新：半年更新一次，虚拟机镜像照样能够升级和回滚。

应用有状态：停机会丢数据，如果不知道丢了啥，就算秒级启动有啥用，照样恢复不了，而且还有可能因为丢数据，在没有修复的情况下，盲目重启带来数据混乱。

进程数量少：两三个进程相互配置一下，不用服务发现，配置不麻烦。

如果是一个传统应用，根本没有必要花费精力去容器化，因为白花了力气，享受不到好处。

容器化，微服务，DevOps 三位一体

什么情况下，才应该考虑做一些改变呢？

传统业务突然被互联网业务冲击了，应用老是变，三天两头要更新，而且流量增大了，原来支付系统是取钱刷卡的，现在要互联网支付了，流量扩大了 N 倍。

没办法，一个字：拆

拆开了，每个子模块独自变化，少相互影响。拆开了，原来一个进程扛流量，现在多个进程一起扛。

所以称为微服务。

微服务场景下，进程多，更新快，于是出现 100 个进程，每天一个镜像。

容器乐了，每个容器镜像小，没啥问题，虚拟机哭了，因为虚拟机每个镜像太大了。

所以微服务场景下，可以开始考虑用容器了。

虚拟机怒了，老子不用容器了，微服务拆分之后，用 Ansible 自动部署是一样的。

这样说从技术角度来讲没有任何问题，然而问题是从组织角度出现的。

一般的公司，开发会比运维多的多，开发写完代码就不用管了，环境的部署完全是运维负责，运维为了自动化，写 Ansible 脚本来解决问题。

然而这么多进程，又拆又合并的，更新这么快，配置总是变，Ansible 脚本也要常改，每天都上线，不得累死运维。

所以在如此大的工作量情况下，运维很容易出错，哪怕通过自动化脚本。这个时候，容器就可以作为一个非常好的工具运用起来。

除了容器从技术角度，能够使得大部分的内部配置可以放在镜像里面之外，更重要的是从流程角度，将环境配置这件事情，往前推了，推到了开发这里，要求开发完毕之后，就需要考虑环境部署的问题，而不能当甩手掌柜。

这样做的好处就是，虽然进程多，配置变化多，更新频繁，但是对于某个模块的开发团队来讲，这个量是很小的，因为 5-10 个人专门维护这个模块的配置和更新，不容易出错。

如果这些工作量全交给少数的运维团队，不但信息传递会使得环境配置不一致，部署量会大非常多。

容器是一个非常好的工具，就是让每个开发仅仅多做 5% 的工作，就能够节约运维 200% 的工作，并且不容易出错。

然而本来运维该做的事情开发做了，开发的老大愿意么？开发的老大会投诉运维的老大么？

这就不是技术问题了，其实这就是 DevOps，DevOps 不是不区分开发和运维，而是公司从组织到流程，能够打通，看如何合作，边界如何划分，对系统的稳定性更有好处。

所以微服务，DevOps，容器是相辅相成，不可分割的。

不是微服务，根本不需要容器，虚拟机就能搞定，不需要 DevOps，一年部署一次，开发和运维沟通再慢都能搞定。

所以，容器的本质是基于镜像的跨环境迁移。

镜像是容器的根本性发明，是封装和运行的标准，其他什么 namespace，cgroup，早就有了，这是技术方面。

在流程方面，镜像是 DevOps 的良好工具。容器是为了跨环境迁移的，第一种迁移的场景是开发，测试，生产环境之间的迁移。

如果不需要迁移，或者迁移不频繁，虚拟机镜像也行，但是总是要迁移，带着几百 G 的虚拟机镜像，太大了。

第二种迁移的场景是跨云迁移，跨公有云，跨 Region，跨两个 OpenStack 的虚拟机迁移都是非常麻烦，甚至不可能的，因为公有云不提供虚拟机镜像的下载和上传功能，而且虚拟机镜像太大了，一传传一天。

所以跨云场景下，混合云场景下，容器也是很好的使用场景。这也同时解决了仅仅私有云资源不足，扛不住流量的问题。

容器的十大正确使用场景

根据以上的分析，我们发现容器推荐使用在下面的场景下：

部署无状态服务，同虚拟机互补使用，实现隔离性。

如果要部署有状态服务，需要对里面的应用十分的了解。

作为持续集成的重要工具，可以顺利在开发，测试，生产之间迁移。

适合部署跨云，跨 Region，跨数据中心，混合云场景下的应用部署和弹性伸缩。

以容器作为应用的交付物，保持环境一致性，树立不可变更基础设施的理念。

运行进程基本的任务类型的程序。

用于管理变更，变更频繁的应用使用容器镜像和版本号，轻量级方便的多。

使用容器一定要管理好应用，进行 health check 和容错的设计。