互联网企业生产环境的应用部署所经历的过程，大致可分三个阶段：
- 物理机部署
- 虚拟机部署
- 容器化部署
物理机部署时代
用纯粹的物理机部署应用，这是所有早期物联网公司必然经历的一个阶段。一台服务器，至少32核CPU、64G内存，如果只部署一个应用，那就太浪费了。于是，多个应用进程，DB，缓存进程等等都部署在同一个机器上。这样部署固然能高效的利用好昂贵的物理机，但是这种简单粗暴的方式有一个最大的痛点：进程间资源抢占。如果某个进程耗用了100%的CPU资源，其他的进程无法提供服务。或者如果一个进程因为突发异常很多，日志把磁盘打满了，所有的进程都要挂掉。进程间抢占资源导致其他进程无法提供服务所导致的血案数不胜数。这样的问题相信很多同学的遇到过。 既然因为资源共享导致的问题，那么解决方式就是：进程间硬件资源隔离。虚拟机技术的出现解决了这个棘手的问题。
虚拟机部署时代
虚拟机通过硬件虚拟化，即每台虚拟机事先从物理机分配好cpu核数，内存， 磁盘，每台虚拟机一般只部署一个应用。从而解决了进程间资源隔离的问题。不同的进程在不同的虚拟机上跑，大家相安无事，老死不相往来，自然没有资源冲突。一台物理机会部署多台虚拟机，物理机里的所有虚拟机则依靠虚拟机管理系统进行管理。
虚拟机技术解决了物理机部署的痛点。但是虚拟机并不是完美的，他也有自己的缺点。大集群部署情况下，软件的版本和配置文件容易碎片化。
大应用集群的虚拟机第一次安装时，由于操作系统镜像是一样的，所以刚开始，软件的版本和库依赖是统一的。随着时间的推移，开源的软件（tomcat, jdk, nginx）需要逐步升级，于是运维同学开始批量升级集群的软件版本，批量升级可能有遗漏或升级失败。同时有些开发同学会自己登陆机器修改软件的版本或者配置，以满足自己的需求。长此以往，一个应用的集群的虚拟机的软件版本和配置逐渐碎片化。当线上出现问题，需要排查到基础软件层面时，由于软件版本碎片化的问题，导致排查变得很棘手。
为了解决虚拟机部署的痛点，容器技术应运而生。
容器部署时代
容器技术不仅限于docker，但是docker目前最为流行，我以docker为例讲容器。docker容器技术的核心之一在于镜像文件。 镜像文件，通俗的理解就是一个进程运行时依赖的软件文件的集装箱。 应用集群部署时，每台机器首先会拉取指定版本的镜像文件。安装镜像后产生了docker容器。由于所有机器的镜像文件一样，容器的软件版本故而一样。即使开发或运维中途修改了容器的软件版本，但是容器销毁时，软件的改动会随容器的销毁一起湮灭。当应用用已有的镜像文件重新部署时，生成的docker容器跟修改之前的容器完全一样。这也是Infrastructure as code思想带来的好处。
容器如果要升级软件版本，那就修改镜像文件。这样部署时集群内所有的机器重新拉取新的镜像，软件因此跟着一起升级。软件版本混乱的问题，到docker这里，也就得到了完美的解决。
一个疑问：有了容器技术，生产环境为何还需要部署虚拟机？
虚拟机能做到硬件资源的彻底隔离，docker不行。虚拟机 和 docker各取长处，最佳CP。
