在跨平台、容器化火热的时代，为什么许多互联网公司要转向容器化呢？这就是今天要谈论的内容
从应用部署的角度来看，可以划分为以下三个时代
接下来，我们对其进行，一 一分析
物理机时代这个时代是伴随我们最长的一个时代，但他的缺点也是最多的。
首先是部署非常慢、当部署一个应用程时，其依赖都需要运维工程师手动去安装，非常非常的慢。
二呢是成本高、如果公司自建机房的话，会涉及到电、宽带、服务器设备本身的等维护成本是非常昂贵的。
三呢资源浪费，如果你的程序是密集型运行，对对内存的要求不高，当在采购服务器是总不能数买 32 核的 CPU 配 8G 的内存，这肯定不合理吧。在物理机时代，通常情况对于服务器使用只发挥了其百分之 20-30 性能，剩余通常都处于闲置状态。
四呢难于扩展迁移，当程序需要从一个服务器迁移到另外一个服务器时，需要手动安装所有的依赖，一个依赖安装有问题应用程序就会运行异常，非常麻烦。
虚拟化时代是在物理机上，通过虚拟化技术模拟出来许多个，完整的计算机。
例如，通过 vmware 在物理虚拟出来多个完整操作系统，我们可以对第一个分配多些 CPU 少量内存进行密集计算，对第二个分配多的内存少量 CPU，对第三个分配均衡的 CPU 与内存等等
虚拟机时代解决了物理机时代资源浪费的问题，可以对应用程序进行隔离，扩展相对来说也是比较容易。
但是他也有缺点，虚拟机需要完整的操作系统，有时候需要运行的应用可能还没有一个虚拟出来的系统大，这样对物理资源的利用率还是没有那么高。
容器化时代
应为虚拟化时代存在的问题，出现容器化技术，这也是一个化时代的技术
容器化强调的是应用层面的隔离。而虚拟化是物理层资源面的隔离。它比虚拟机更灵活、更小巧，小的呢有十几 M，大的呢有一两百 M，比起动辄上 G 的操作系统太轻量级。
是不是使用了容器化技术，我们的资源利用率就非常高了呢？不是的，容器化是一个革命性划时代的意义。接着往下看
容器化解决的问题首先抛开容器化，来看物理机时代或者虚拟化时代，他们的弊端
做开发的同学都知道，当我们开发一个.net 或者 java 程序，在部署对于的物理机或者虚拟机，都需要安装 IIS 或者 Tomact 等各项依赖，缺少一个程序都会运行不起来。
同学们都知道，研发工程师对应得是开发或者测试环境，而运维工程师对应得是线上环境。当部署一个应用到线上时，从前需要研发工程师写一堆的开发文档，让运维工程师在线上环境部署一堆依赖。上个线一两个小时顺利就算是烧高香了，出个问题调试的那恶心的，工作过的同学懂得都懂。
那怎么解决呢，直到容器化的时代到来，才发现他是个好东西
什么是容器呢？他是一个标准化的应用打包方式，简单的可以看做是一个集装箱
当我们开发的 .NET 或者 Java 程序，都可以打包成为一个镜像放到集装箱内运行，对于其依赖的 Redis、RabbitMQ 等都可以放置在集装箱内，对外来说无论里面装的什么，对外都是一个集装箱，进行了一个统一
回想以前部署时代的弊端，当在容器化时代，研发工程师开发完成程序后，只需要将程序打包成镜像放置私有镜像仓库，他的工作就完成了，剩余的完全交给运维工程师即可，他只需要几条简单的命令即可，无需关注底层的依赖等，简简单单只需几分钟时间即可。接着测试工程师与研发工程师只需要验收就行了，这就是容器化的一个体现。
通过容器化打通了开发与运维之间的一个桥梁，用为无论任何程序都是一统一的形式展现的。这也就为互联网一次性部署成百上千个节点提供了可能。
尤其就是阿里、腾讯这样的互联网大厂，怎么可以做到通过点击一个按钮，就可以还原一个操作系统来呢，其实这就是容器化，本质上就是基于镜像，操作系统处于每个容器内。
容器化优点1 . 标准化迁移方式
所以都是基于镜像、容器统一发布，在任何一台物理服务器运行环境都是无差异的。
2 . 统一参数配置
统一的参数配置，对于发布的程序，肯定是有个配置中心进行统一配置进行管理，无序到每台服务器配置应用程序
3 . 自动化部署
自动化部署这也是现在我们原生云一个基础的功能
4 . 应用集群监控
容器化相关有许多的副产品，可以对当前应用的执行状况进行大规模的集群监控。像 Google 的 K8S 可以同时对 20 万台服务器进行监控
5 . 打通开发与运维桥梁
最重要的是打通了开发工程师与运维工程师之间消息传递的桥梁