被“嫌弃”的物理服务器

在云时代以前，开发者如需构建一个线上的站点，必须自己维护物理服务器。但是随着业务发展，大体量服务器逐渐增多，随之而来的是硬件、场地和维护成本的不断提高。对于面向 C 端的站点来说，网络热点事件具有随机性，流量的变化并不可控，难免会遭遇站内流量暴涨的情况。此时如果没有备用服务器，突发的大流量很可能会冲垮整个站点。但在没有突发事件的时候，备用服务器的采购和维护成本又让人不可忽略。

（运维的传统艺能：上线拜祖，图片来自网络）

哪里有问题，哪里就有商机。有人想到，如果买一批服务器放在外网，安排专人管理，然后按照用户的需要租赁出去，不正好解决了这个问题吗？

于是，一场云计算的好戏，正式上演。

虚拟机还是“超重”了

云计算时代的大幕拉开，大厂先后登台，让我们先简单做一下回顾。

2006 年，亚马逊成立 aws，从云端存储业务开始。
2008 年，云计算初创。
2009 年，阿里云成立。目前最新的数据表明，2020 年度 IaaS 市场份额调查，阿里云位居全球第三，亚太第一；前两名分别是亚马逊和微软，市场份额达 9.5%，超过谷歌的 6.1%，亚马逊 40.8%，微软 17%。国内市场份额 40% ，第二是华为云，占 18%。
2010 年，OpenStack 由 NASA 发布。OpenStack 是一个 IaaS 架构，可以用其架构来搭建自己的私有云，让任何人都可以自行创建和提供云计算服务。对比而言，AWS 和 aliyun 都是自研架构，OpenStack 是开源的。所以公司如果需要，完全可以接入 OpenStack 搭建自己的私有云。（当然前提需要有 OpenStack 核心开发能力）。
2010-2013 年之间，云计算的全球份额被 aws 和 OpenStack 瓜分。

这时的云计算技术，本质都是虚拟化技术，将硬件资源作为基础设施提供给用户，简称 IaaS 。简单理解，IaaS 就是将一个很大的服务器，通过虚拟化技术拆分成多个小的虚拟服务器，提供服务，类似于在本机装了虚拟机。

（云计算主力玩家的进场时间，图片来自网络）

但是，IaaS 时代的虚拟机还是太过于笨重了。每一台虚拟机都需要消耗 CPU 、内存等计算资源才能支撑应用的运行。即便应用再小，系统的开销都是固定的成本。如何为 IaaS 减肥，让虚拟机系统的开销降到最低？

2013 年开始，云计算正式进入了 PaaS 时代。PaaS 时代，云计算所销售的单元，从虚拟机变成了应用运行平台。于是，云厂商提供的服务更多，资源利用率也更高了。

什么是 PaaS ？我们用一个通俗的例子来解释。如果我们现在是一个烧饼店老板，采用 IaaS 模式意味着我们需要用别人厨房、锅炉、煤气，自己和面做馅料，做烧饼。如果是 PaaS，我们烧饼的面粉、馅料和调料都是别人提供好了，我们只需要把饼烤熟。

云厂商该如何构建一套好用的 PaaS 服务呢？借力开源项目，成为各厂商的共识。

Cloud Foundry 开启 PaaS 开源时代

PaaS 的核心是平台。最早出现在开发者视野中的 PaaS 开源项目中，vmware 创立的 Cloud Foundry 是知名度最高的。与 IaaS 提供云上虚拟机的服务方式不同，基于 Cloud Foundry 的云计算能够提供应用托管的功能。开发者只需要通过一条简单的命令比如：cf push "我的应用"，就可以将项目打成一个压缩包，上传到 Cloud Foundry 服务器。而 Cloud foundry 会开启自己的调度器，在一群云主机中找到满足用户需求的主机（系统版本、性能、个数），然后通过容器化技术，在主机上创建一个容器，在容器中下载压缩包，解压并运行，最终成为一个对外提供服务的应用。

此外，Cloud Foundry 平台对这些应用项目提供分发，灾备，监控，重启等等服务（这也是我们提供给用户的核心服务）。这种托管服务解放了开发者的生产力，让他们不用再关心应用的运维状况，而是专心开发自己的应用。而这就是 PaaS 的“初心”，平台即服务。

（ Cloud Foundry 提供的服务）

这里就会有同学问了，容器是什么？容器是用来解决多个应用资源冲突与隔离性问题的技术。Linux 上的 namespace 机制和 cgroups 命令都能用做资源隔离和限制，这些都是容器技术。

容器技术并不是 Docker 创建的，在 Docker 兴起之前，就已经被其他公司商用了，但是为什么现在一谈起容器，所有人第一时间想到的就是 Docker 呢？这就要提到 Cloud Foundry 的死亡。

从 Cloud Foundry 到 Docker

Cloud Foundry 似乎已经和我们现在使用的云功能区别不大，但 2021 年的现实情况却是 Cloud Foundry 已经死了。

我们看过互联网上很多文章，再结合我们活字格公有云开发的经验，我们认为这个项目的致命缺陷集中它的打包机制上。

Cloud Foundry 最核心的组件就是应用的打包和分发机制，也是开发者打交道最多的功能。Cloud Foundry 为每一种主流的语言都定义了一套打包的方式，这些方式之间毫无章法。但就是这个打包功能，成了 Cloud Foundry 的软肋，一直为用户所诟病。开发者不得不为每一种语言，每一种框架，甚至是每个版本应用维护一个打好的包，还有可能出现本机运行成功，打了个包上传上去之后就无法运行的情况。情况最严重的时候，开发者在调试云平台系统上花的时间都已经比开发一个新软件的时间要长了。

本来是为赋能开发者的而生的技术，Cloud Foundry 却对开发者如此不友好。当开发者的抱怨积累到一定程度，想要在 PaaS 浪潮中央站稳脚跟的 Cloud Foundry 被后起之秀 Docker“红牌罚出局”也就顺理成章了。

最初，Docker 是一个当时还叫 dotCloud 的公司（ 2010 年由所罗门海克斯创建，Y Combinator 孵化）开发的容器项目。在 Cloud Foundry 困于打包问题时，Docker 正在悄悄积蓄力量，在开源后的短短几个月内就迅速崛起，成为一个不容忽视的 PaaS 技术方案，吸引了云服务开发者的眼球。

滑稽的是，在 Docker 刚开源的时候，Cloud Foundry 的首席产品经理 James Bayer 就在社区做了一次详细的对比，告诉用户 Docker 和 Cloud Foundry 一样，都是使用了 Namespace 和 Cgroups 技术的沙箱而已，没什么值得关注的。

事实上，Docker 也确实就和他所说的一样，采用了这个“传统”的技术方案，但是 Docker 与 Cloud Foundry 相比，做了一点小小的创新，体现了所罗门海克斯的远见。从 2010 他就开始考虑应用打包的一致性与复用性问题，并提出了创新的解决方案，最终对 Cloud Foundry 造成了毁灭性的打击。这个解决方案就是 Docker 镜像。