相辅相成 不可分割：谈云计算、大数据和人工智能（二）

云计算不光管资源，也要管应用

有了 IaaS，实现了资源层面的弹性就够了吗？显然不是，还有应用层面的弹性。

这里举个例子：比如说实现一个电商的应用，平时十台机器就够了，双十一需要一百台。你可能觉得很好办啊，有了 IaaS，新创建九十台机器就可以了啊。

但 90 台机器创建出来是空的，电商应用并没有放上去，只能让公司的运维人员一台一台的弄，需要很长时间才能安装好的。

虽然资源层面实现了弹性，但没有应用层的弹性，依然灵活性是不够的。有没有方法解决这个问题呢？

人们在 IaaS 平台之上又加了一层，用于管理资源以上的应用弹性的问题，这一层通常称为 PaaS（Platform As A Service）。

这一层往往比较难理解，大致分两部分：一部分笔者称为“你自己的应用自动安装”，一部分笔者称为“通用的应用不用安装”。

像电商应用，安装时需要配置支付宝或者微信的账号，才能使别人在你的电商上买东西时，付的钱是打到你的账户里面的，除了你，谁也不知道。

所以安装的过程平台帮不了忙，但能够帮你做得自动化，你需要做一些工作，将自己的配置信息融入到自动化的安装过程中方可。

比如上面的例子，双十一新创建出来的 90 台机器是空的，如果能够提供一个工具，能够自动在这新的 90 台机器上将电商应用安装好，就能够实现应用层面的真正弹性。

例如 Puppet、Chef、Ansible、Cloud Foundary 都可以干这件事情，最新的容器技术 docker 能更好的干这件事情。

这样的应用可以变成标准的 PaaS 层的应用放在云平台的界面上。当用户需要一个数据库时，一点就出来了，用户就可以直接用了。

有人问，既然谁安装都一个样，那我自己来好了，不需要花钱在云平台上买。当然不是，数据库是一个非常难的东西，光 Oracle 这家公司，靠数据库就能赚这么多钱。买 Oracle 也是要花很多钱的。

然而大多数云平台会提供 MySQL 这样的开源数据库，又是开源，钱不需要花这么多了。

但维护这个数据库，却需要专门招一个很大的团队，如果这个数据库能够优化到能够支撑双十一，也不是一年两年能够搞定的。

比如您是一个做单车的，当然没必要招一个非常大的数据库团队来干这件事情，成本太高了，应该交给云平台来做这件事情。

专业的事情专业的人来做，云平台专门养了几百人维护这套系统，您只要专注于您的单车应用就可以了。

要么是自动部署，要么是不用部署，总的来说就是应用层你也要少操心，这就是 PaaS 层的重要作用。

虽说脚本的方式能够解决自己的应用的部署问题，然而不同的环境千差万别，一个脚本往往在一个环境上运行正确，到另一个环境就不正确了。

而容器是能更好地解决这个问题。

容器是 Container，Container 另一个意思是集装箱，其实容器的思想就是要变成软件交付的集装箱。集装箱的特点：一是封装，二是标准。

在没有集装箱的时代，假设将货物从 A 运到 B，中间要经过三个码头、换三次船。

每次都要将货物卸下船来，摆得七零八落，然后搬上船重新整齐摆好。因此在没有集装箱时，每次换船，船员们都要在岸上待几天才能走。

有了集装箱以后，所有的货物都打包在一起了，并且集装箱的尺寸全部一致，所以每次换船时，一个箱子整体搬过去就行了，小时级别就能完成，船员再也不用上岸长时间耽搁了。

这是集装箱“封装”、“标准”两大特点在生活中的应用。

那么容器如何对应用打包呢？还是要学习集装箱。首先要有个封闭的环境，将货物封装起来，让货物之间互不干扰、互相隔离，这样装货卸货才方便。好在 Ubuntu 中的 LXC 技术早就能做到这一点。

封闭的环境主要使用了两种技术：

所谓的镜像，就是将你焊好集装箱的那一刻，将集装箱的状态保存下来，就像孙悟空说：“定”，集装箱里面就定在了那一刻，然后将这一刻的状态保存成一系列文件。

这些文件的格式是标准的，谁看到这些文件都能还原当时定住的那个时刻。将镜像还原成运行时的过程（就是读取镜像文件，还原那个时刻的过程），就是容器运行的过程。

有了容器，使得 PaaS 层对于用户自身应用的自动部署变得快速而优雅。