转载请注明出处：葡萄城官网，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。
大家在工作中或许或多或少都接触过 Docker，那你知道 Docker 以及容器化背后的原理到底是什么吗？
容器化技术满天下，那为什么只有 Docker 被大家所熟知呢？
后 Docker 时代，到底谁才是云原生时代的王者？
我们相信本系列文章能帮您解答这些疑惑。
在云时代以前，开发者如需构建一个线上的站点，必须自己维护物理服务器。但是随着业务发展，大体量服务器逐渐增多，随之而来的是硬件、场地和维护成本的不断提高。对于面向 C 端的站点来说，网络热点事件具有随机性，流量的变化并不可控，难免会遭遇站内流量暴涨的情况。此时如果没有备用服务器，突发的大流量很可能会冲垮整个站点。但在没有突发事件的时候，备用服务器的采购和维护成本又让人不可忽略。
哪里有问题，哪里就有商机。有人想到，如果买一批服务器放在外网，安排专人管理，然后按照用户的需要租赁出去，不正好解决了这个问题吗？
于是，一场云计算的好戏，正式上演。
云计算时代的大幕拉开，大厂先后登台，让我们先简单做一下回顾。
这时的云计算技术，本质都是虚拟化技术，将硬件资源作为基础设施提供给用户，简称 IaaS 。简单理解，IaaS 就是将一个很大的服务器，通过虚拟化技术拆分成多个小的虚拟服务器，提供服务，类似于在本机装了虚拟机。
但是，IaaS 时代的虚拟机还是太过于笨重了。每一台虚拟机都需要消耗 CPU 、内存等计算资源才能支撑应用的运行。即便应用再小，系统的开销都是固定的成本。如何为 IaaS 减肥，让虚拟机系统的开销降到最低？
2013 年开始，云计算正式进入了 PaaS 时代。PaaS 时代，云计算所销售的单元，从虚拟机变成了应用运行平台。于是，云厂商提供的服务更多，资源利用率也更高了。
什么是 PaaS ？我们用一个通俗的例子来解释。如果我们现在是一个烧饼店老板，采用 IaaS 模式意味着我们需要用别人厨房、锅炉、煤气，自己和面做馅料，做烧饼。如果是 PaaS，我们烧饼的面粉、馅料和调料都是别人提供好了，我们只需要把饼烤熟。
云厂商该如何构建一套好用的 PaaS 服务呢？借力开源项目，成为各厂商的共识。
PaaS 的核心是平台。最早出现在开发者视野中的 PaaS 开源项目中，vmware 创立的 Cloud Foundry 是知名度最高的。与 IaaS 提供云上虚拟机的服务方式不同，基于 Cloud Foundry 的云计算能够提供应用托管的功能。开发者只需要通过一条简单的命令比如：cf push "我的应用"，就可以将项目打成一个压缩包，上传到 Cloud Foundry 服务器。而 Cloud foundry 会开启自己的调度器，在一群云主机中找到满足用户需求的主机（系统版本、性能、个数），然后通过容器化技术，在主机上创建一个容器，在容器中下载压缩包，解压并运行，最终成为一个对外提供服务的应用。
此外，Cloud Foundry 平台对这些应用项目提供分发，灾备，监控，重启等等服务（这也是我们提供给用户的核心服务）。这种托管服务解放了开发者的生产力，让他们不用再关心应用的运维状况，而是专心开发自己的应用。而这就是 PaaS 的“初心”，平台即服务。
这里就会有同学问了，容器是什么？容器是用来解决多个应用资源冲突与隔离性问题的技术。Linux 上的 namespace 机制和 cgroups 命令都能用做资源隔离和限制，这些都是容器技术。
容器技术并不是 Docker 创建的，在 Docker 兴起之前，就已经被其他公司商用了，但是为什么现在一谈起容器，所有人第一时间想到的就是 Docker 呢？这就要提到 Cloud Foundry 的死亡。
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 镜像。
（ Docker，图片来自官网）
刚开源的 Docker 迅速爆火，憨态可掬的小鲸鱼，对用户友好的文档，三分钟部署一个 Nginx 集群的宣传语，以及 Docker Image 这个 “微不足道的创新”，让 Docker 席卷整个 PaaS 领域。
Docker 成功的关键，在于 Docker 镜像几乎完美地解决了 Cloud Foundry 在打包方面的软肋。
所谓的镜像，其实也是一个压缩包，但是比起 Cloud Foundry 那种执行文件+启动脚本的打包结果，镜像提供给用户的是一套完整的运行环境，每一个镜像都可以指定操作系统版本，内部可以构建程序执行的文件结构，并且一份镜像可以完全共享在多处使用。
此外，Docker 还给开发者提供了一套完善的镜像制作流程，这套流程与编程语言和框架无关。开发者只需要按照该流程，定制对应程序所需要的运行的操作系统环境即可。
总之，Docker 镜像完美解决了两个问题：
1.本地环境和服务器环境的差异 2.同一份镜像可以让所有的机器进行复用
从这一刻开始，PaaS 的市场已经完全是 Docker 的天下。
本文是系列文章的第一期，我们一起回顾了 IaaS 取代物理服务器，基于 IaaS 构建 PaaS 的发展路线。在构建 PaaS 时，我们经历了 Cloud Foundry 的衰败，见证了 Docker 的成功。
但是，只依靠 Docker 就能构建起完整的 PaaS 服务吗？我们的活字格公有云版最终选择了哪个技术方案？云计算的故事还没有讲完，敬请期待下期精彩内容。
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.