史上最容易懂的云计算的前世今生

云计算的整个过程，用一个词来讲就是“分久必合，合久必分”。

云计算其实主要解决了四个方面的内容：计算，网络，存储，应用。前三者是资源层面的，最后是应用层面的。

• 计算是CPU和内存，为啥？1+1这个最简单的算法是把1放在内存里面，运行加法是CPU做的，做完了结果2又保存在内存里面。
• 网络就是你插根网线能上网。
• 存储就是你下个电影有地方放。本次讨论就是围绕这四个部分来讲的。

 在原始社会，大家最爱用的是物理设备：

• 服务器用的是物理机，例如戴尔，惠普，IBM，联想等物理服务器，随着硬件设备的进步，物理服务器越来越强大了，64核128G内存都算是普通配置。
• 网络用的是硬件交换机和路由器，例如思科的，华为的，从1GE到10GE，现在有40GE和100GE，带宽越来越牛。
• 存储方面有的用普通的磁盘，也有了更快的SSD盘。容量从M，到G，连笔记本电脑都能配置到T，更何况磁盘阵列。

 如果部署应用直接使用物理机，看起来很爽，总有种土豪的感觉，却又大大的缺点：

• 人工运维：如果你在一台服务器上安装软件，把系统安装坏了，怎么办？只有重装。当你想配置一下交换机的参数，需要串口连上去进行配置。当你想增加一块磁盘，总要买一块插进服务器。这些都需要人工来，而且很大可能要求机房。你们公司在北五环，机房在南六环，这酸爽。
• 浪费资源：其实你只想部署一个小小的网站，却要用128G的内存。混着部署吧，就有隔离性的问题。
•  隔离性差：你把好多的应用部署在同一台物理机上，他们之间抢内存，抢cpu，一个写满了硬盘，另一个就没法用了，一个弄挂了内核，另一个也同时挂了，如果部署两个相同的应用，端口还会冲突，动不动就会出错。

 于是有了第一次合久必分的过程，叫做虚拟化。所谓虚拟化，就是把实的变成虚的。

• 物理机变为虚拟机：cpu是虚拟的，内存是虚拟的，内核是虚拟的，硬盘是虚拟的。
• 物理交换机变为虚拟交换机：网卡是虚拟的，交换机是虚拟的，带宽也是虚拟的。
• 物理存储变成虚拟存储：多块硬盘虚拟成一大块。

 虚拟化很好的解决了上面的三个问题：

• 人工运维：虚拟机的创建和删除都可以远程操作，虚拟机被玩坏了，删了再建一个分钟级别的。虚拟网络的配置也可以远程操作，创建网卡，分配带宽都是调用接口就能搞定的。
• 浪费资源：虚拟化了以后，资源可以分配的很小很小，比如1个cpu，1G内存，1M带宽，1G硬盘，都可以被虚拟出来。
• 隔离性差：每个虚拟机有独立的cpu, 内存，硬盘，网卡，不同虚拟机的应用互不干扰。

但是虚拟化还有以下的缺点，通过虚拟化软件创建虚拟机，需要人工指定放在哪台机器上，硬盘放在哪个存储设备上，网络的VLAN ID，带宽具体的配置，都需要人工指定。所以单单使用虚拟化的运维工程师往往有一个Excel表格，有多少台机器，每台机器部署了哪些虚拟机。所以，一般虚拟化的集群数目都不是特别的大。

在虚拟化阶段，领跑者是Vmware，可以实现基本的计算，网络，存储的虚拟化。

当然这个世界有闭源，就有开源，有windows就有linux，有apple就有andord，有Vmware，就有Xen和KVM。在开源虚拟化方面，Xen方面Citrix做的不错，后来Redhat在KVM发力不少。

对于网络虚拟化，有Openvswitch，可以通过命令创建网桥，网卡，设置VLAN，设置带宽。

对于存储虚拟化，对于本地盘，有LVM，可以将多个硬盘变成一大块盘，然后在里面切出一小块给用户。

为了解决虚拟化阶段剩余的问题，于是有了分久必合的过程。这个过程我们可以形象的称为池化，也就是说虚拟化已经将资源分的很细了，但是对于如此细粒度的资源靠Excel去管理，成本太高，能不能打成一个大的池，当需要资源的时候，帮助用户自动的选择，而非用户指定。所以这个阶段的关键点：调度器Scheduler。

于是vmware有了自己的vcloud。

于是基于Xen和KVM的私有云平台CloudStack，后来Citrix将其收购后开源。

当这些私有云平台在用户的数据中心里面卖的其贵无比，赚的盆满钵满的时候。有其他的公司开始了另外的选择，这就是AWS和Google，开始了公有云领域的探索。

AWS最初就是基于Xen技术进行虚拟化的，并且最终形成了公有云平台。也许AWS最初只是不想让自己的电商领域的利润全部交给私有云厂商吧，于是自己的云平台首先支撑起了自己的业务，在这个过程中，AWS自己严肃的使用了自己的云计算平台，使得公有云平台不是对于资源的配置更加友好，而是对于应用的部署更加友好，最终大放异彩。

如果我们仔细观察就会发现，私有云和公有云使用的是类似的技术，却在产品设计上是完全不同的两种生物。私有云厂商和公有云厂商也拥有类似的技术，却在产品运营上呈现出完全不同的基因。

私有云厂商都是卖资源的，所以往往在卖私有云平台的时候往往伴随着卖计算，网络，存储设备。在产品设计上，私有云厂商往往强调又长又详尽，但是客户几乎不会使用的计算，网络，存储的技术参数，因为这些参数可以用来和友商对标的过程中占尽优势。私有云的厂商几乎没有自己的大规模应用，所以私有云厂商的平台做出来是给别人用的，自己不会大规模使用，于是产品往往围绕资源展开，而不会对应用的部署友好。

公有云的厂商往往都是有自己的大规模应用需要部署的，所以其产品的设计，可以将常见的应用部署所需要的模块作为组件提供出来，用户可以像拼积木一样，拼接一个适用于自己应用的架构。公有云厂商不必要关心各种技术参数的PK，不必关心是否开源，是否兼容各种虚拟化平台，兼容各种服务器设备，网络设备，存储设备。你管我用什么，客户部署应用方便就好。

当然公有云的第一名AWS活的很爽，第二名Rackspace就不太爽了，没错，互联网行业嘛，基本上就是一家独大。第二名如何逆袭呢？开源是很好的办法，让整个行业大家一起为这个云平台出力，兄弟们，大家一起上。于是Rackspace与美国航空航天局（NASA）合作创始了开源云平台OpenStack。OpenStack现在发展的和AWS有点像了，所以从OpenStack的模块组成，可以看到云计算池化的方法。

OpenStack包含哪些组件呢？

• 计算池化模块Nova：OpenStack的计算虚拟化主要使用KVM，然而到底在那个物理机上开虚拟机呢，这要靠nova-scheduler。
• 网络池化模块Neutron：OpenStack的网络虚拟化主要使用Openvswitch，然而对于每一个Openvswitch的虚拟网络，虚拟网卡，VLAN，带宽的配置，不需要登录到集群上配置，Neutron可以通过SDN的方式进行配置。
• 存储池化模块Cinder:OpenStack的存储虚拟化，如果使用本地盘，则基于LVM，使用哪个LVM上分配的盘，也是用过scheduler来的。后来就有了将多台机器的硬盘打成一个池的方式Ceph，则调度的过程，则在Ceph层完成。

有了OpenStack，所有的私有云厂商都疯了，原来VMware在私有云市场实在赚的太多了，眼巴巴的看着，没有对应的平台可以和他抗衡。现在有了现成的框架，再加上自己的硬件设备，你可以想象到的所有的IT厂商的巨头，全部加入到社区里面来，将OpenStack开发为自己的产品，连同硬件设备一起，杀入私有云市场。

网易当然也没有错过这次风口，上线了自己的OpenStack集群，网易蜂巢基于OpenStack自主研发了IaaS服务，在计算虚拟化方面，通过裁剪KVM镜像，优化虚拟机启动流程等改进，实现了虚拟机的秒级别启动。在网络虚拟化方面，通过SDN和Openvswitch技术，实现了虚拟机之间的高性能互访。在存储虚拟化方面，通过优化Ceph存储，实现高性能云盘。

但是网易并没有杀进私有云市场，而是使用OpenStack支撑起了自己的应用，这是互联网的思维，没错。仅仅是资源层面弹性是不够的，还需要开发出对应用部署友好的组件。例如数据库，负载均衡，缓存等，这些都是应用部署必不可少的，也是网易在大规模应用实践中，千锤百炼过的。这些组件称为PaaS。

前面一直在讲IaaS层的故事，也即基础设施即服务，基本上在谈计算，网络，存储的事情。现在应该说说应用层的事情了。

IaaS的定义比较清楚，PaaS的定义就没那么清楚了，有的把数据库，负载均衡，缓存作为PaaS服务，有的把大数据Hadoop, Spark平台作为PaaS服务，有的讲应用的安装与管理，例如Puppet, Chef, Ansible作为PaaS服务。

其实PaaS主要用于管理应用层的，我总结两部分：一部分是你自己的应用应当自动部署，比如Puppet, Chef, Ansible, Cloud Foundry等，可以通过脚本帮你部署，一部分是你觉得复杂的通用应用不用部署，比如数据库，缓存，大数据平台，可以在云平台上一点即得。

要么就是自动部署，要么不用部署，总的来说就是应用层您也少操心，就是PaaS的作用。当然最好是都不用部署，一键可得，所以公有云平台将通用的服务都做成了PaaS平台。另一些应用，是您自己开发的，除了你自己，其他人都不知道，所以您可以用工具变成自动部署。

有了PaaS最大的优点，就是可以实现应用层的弹性伸缩。比如双十一来了，10个节点要变成100个节点，如果使用物理设备，再买90台机器固然来不及，仅仅只有IaaS实现资源的弹性是不够的，再创建90台虚拟机，也是空的啊，还是需要运维人员一台一台的部署。所以有了PaaS就好了，一台虚拟机启动后，马上运行自动部署脚本，进行应用的安装，90台机器自动安装好了应用，才是真正的弹性伸缩。

当然这种部署方式也有一个问题，就是无论Puppet, Chef, Ansible把安装脚本抽象的再好，说到底也是基于脚本的，然而应用所在的环境千差万别，文件路径的差别，文件权限的差别，依赖包的差别，应用环境的差别，Tomcat, PHP, Apache等软件版本的差别，JDK，Python等版本的差别，是否安装了一些系统软件，是否占用了哪些端口，都可能造成脚本执行的不成功。所以看起来是一旦脚本写好，就能够快速复制了，但是一旦环境稍有改变，就需要把脚本进行新一轮的修改，测试，联调。例如在数据中心写好的脚本，移到AWS上就不一定直接能用，在AWS上联调好了，迁移到Google Cloud上去也可能再会出问题。

于是容器应运而生。容器是Container，Container另一个意思是集装箱，其实容器的思想就是要变成软件交付的集装箱。集装箱的特点，一是打包，二是标准。设想没有集装箱的时代，如果从A将货物运到B，中间要经过三个码头，换三次船的话，每次货物都要卸下船来，摆的七零八落，然后再换船的时候，需要重新整齐摆好，所以没有集装箱的时候，船员们都能够在岸上待几天再走。然而有了集装箱，所有的货物都打包在一起了，并且集装箱的尺寸全部一致，所以每次换船的时候，整体一个箱子搬过去就可以了，小时级别就能完成，船员再也不能上岸长时间休息了。所以设想A就是程序员，B就是用户，货物就是代码及运行环境，中间的三个码头分别是开发，测试，上线。

 

假设代码的运行环境如下：

1.        Ubuntu操作系统

2.        创建用户hadoop

3.        下载解压缩JDK 1.7在某个目录下

4.        将这个目录加入JAVA_HOME和PATH的环境变量里面

5.        将环境变量的export放在hadoop用户的home目录下的.bashrc文件中

6.        下载并解压缩tomcat 7

7.        将war放到tomcat的webapp路径下面

8.        修改tomcat的启动参数，将Java的Heap Size设为1024M

 

看，一个简单的Java网站，就需要考虑这么多零零散散的东西，如果不打包，就需要在开发，测试，生产的每个环境上查看保证环境的一致，甚至要将这些环境重新搭建一遍，就像每次将货物打散了重装一样麻烦，中间稍有差池，比如开发环境用了JDK 1.8，而线上是JDK 1.7，比如开发环境用了root用户，线上需要使用hadoop用户，都可能导致程序的运行失败。

容器如何对应用打包呢？还是要学习集装箱，首先要有个封闭的环境，将货物封装起来，让货物之间互不干扰，互相隔离，这样装货卸货才方便。好在ubuntu中的lxc技术早就能做到这一点，这里主要使用了两种技术，一种是看起来是隔离的技术，称为namespace，也即每个namespace中的应用看到的是不同的IP地址，用户空间，进程号等。另一种是用起来是隔离的，称为cgroup，也即明明整台机器有很多的CPU，内存，而一个应用只能用其中的一部分。

有了这两项技术，集装箱的铁盒子我们是焊好了，接下来是决定往里面放什么的时候了。最简单粗暴的方法，就是将上面列表中所有的都放到集装箱里面。但是这样太大了，因为虚拟机的镜像就是这样的，动辄几十G，如果你安装一个干干静静的ubuntu操作系统，什么都不装，就很大了。这其实相当于把船也放到了集装箱里面，答案当然是NO.

所以撇下第一项操作系统，剩下的所有的加起来，也就几百M，就轻便多了。所以一台服务器上的容器是共享操作系统内核的，容器在不同机器之间的迁移不带内核，这也是很多人声称容器是轻量级的虚拟机的原因。轻不白轻，自然隔离性就差了，一个集装箱把船压漏水了，所有的集装箱一起沉。

另一个需要撇下的就是随着应用的运行而产生并保存在本地的数据，多以文件的形式存在，例如数据库文件，文本文件。这些文件会随着应用的运行，越来越大，如果这些数据也放在容器里面，会让容器变得很大，影响容器在不同环境的迁移。而且这些数据在开发，测试，线上环境之间的迁移是没有意义的，生产环境不可能用测试环境的文件，所以往往这些数据也是保存在容器外面的存储设备上。也是为什么人们称容器是无状态的。

至此集装箱焊好了，货物也装进去了，接下来就是如何将这个集装箱标准化，从而在哪艘船上都能运输。这里的标准一个是镜像，一个是容器的运行环境。所谓的镜像，就是将你焊好集装箱的那个时刻，将集装箱的状态保存下来，就像孙悟空说定，集装箱里面就定在了那一刻，然后将这一刻的状态保存成一系列文件。这些文件的格式是标准的，谁看到这些文件，都能还原当时定住的那个时刻。将镜像还原成运行时的过程，就是读取镜像文件，还原那个时刻的过程，也就是容器的运行的过程。除了大名鼎鼎的Docker，还有其他的容器，例如AppC，Mesos Container，都能运行容器镜像。所以说容器不等于Docker。

总而言之，容器是轻量级的，隔离差的，适用于无状态的，基于镜像标准实现跨主机，跨环境的随意迁移。

有了容器，使得PaaS层对于用户自身应用的自动部署变得快速而优雅。容器快，快在了两方面，第一是虚拟机启动的时候要先启动操作系统，容器不用启动操作系统，因为是共享内核的。第二是虚拟机启动后使用脚本安装应用，容器不用安装应用，因为已经打包在镜像里面了。所以最终虚拟机的启动是分钟级别，而容器的启动是秒级。容器咋这么神奇。其实一点都不神奇，第一是偷懒少干活了，第二是提前把活干好了。

因为容器的启动快，人们往往不会创建一个个小的虚拟机来刚刚部署应用，因为这样太费时间了，而是创建一个大的虚拟机，然后在大的虚拟机里面再划分容器，而不同的用户不共享大的虚拟机，可以实现操作系统内核的隔离。

 这又是一次合久必分的过程。由IaaS层的虚拟机池，划分为更细粒度的容器池。

 容器的粒度更加细，管理起来更难管，甚至是手动操作难以应对的。假设你有100台物理机，其实规模不是太大，用Excel人工管理是没问题的，但是一台上面开10台虚拟机，虚拟机的个数就是1000台，人工管理已经很困难了，但是一台虚拟机里面开10个容器，就是10000个容器，你是不是已经彻底放弃人工运维的想法了。

所以容器层面的管理平台是一个新的挑战，关键字就是自动化：

• 自发现：容器与容器之间的相互配置还能像虚拟机一样，记住IP地址，然后互相配置吗？这么多容器，你怎么记得住一旦一台虚拟机挂了重启，IP改变，应该改哪些配置，列表长度至少万行级别的啊。所以容器之间的配置通过名称来的，无论容器跑到哪台机器上，名称不变，就能访问到。
• 自修复：容器挂了，或是进程宕机了，能像虚拟机那样，登陆上去查看一下进程状态，如果不正常重启一下么？你要登陆万台docker了。所以容器的进程挂了，容器就自动挂掉了，然后自动重启。
• 弹性自伸缩 Auto Scaling：当容器的性能不足的时候，需要手动伸缩，手动部署么？当然也要自动来。

如果有了容器的管理平台，又是一次分久必合。

当前火热的容器管理平台有三大流派：

• 一个是Kubernetes，我们称为段誉型。段誉(Kubernetes)的父亲(Borg)武功高强，出身皇族(Google)，管理过偌大的一个大理国(Borg是Google数据中心的容器管理平台)。作为大理段式后裔，段誉的武功基因良好(Kubernetes的理念设计比较完善)，周围的高手云集，习武环境也好(Kubernetes生态活跃，热度高)，虽然刚刚出道的段誉武功不及其父亲，但是只要跟着周围的高手不断切磋，武功既可以飞速提升。
• 一个是Mesos，我们称为乔峰型。乔峰(Mesos)的主要功夫降龙十八掌(Mesos的调度功能)独步武林，为其他帮派所无。而且乔峰也管理过人数众多的丐帮(Mesos管理过Tweeter的容器集群)。后来乔峰从丐帮出来，在江湖中特例独行(Mesos的创始人成立了公司Mesosphere)。乔峰的优势在于，乔峰的降龙十八掌(Mesos)就是在丐帮中使用的降龙十八掌，相比与段誉初学其父的武功来说，要成熟很多。但是缺点是，降龙十八掌只掌握在少数的几个丐帮帮主手中(Mesos社区还是以Mesosphere为主导)，其他丐帮兄弟只能远远崇拜乔峰，而无法相互切磋(社区热度不足)。
• 一个是Swarm，我们称为慕容型。慕容家族(Swarm是Docker家族的集群管理软件)的个人功夫是非常棒的(Docker可以说称为容器的事实标准)，但是看到段誉和乔峰能够管理的组织规模越来越大，有一统江湖的趋势，着实眼红了，于是开始想创建自己的慕容鲜卑帝国(推出Swarm容器集群管理软件)。但是个人功夫好，并不代表着组织能力强(Swarm的集群管理能力)，好在慕容家族可以借鉴段誉和乔峰的组织管理经验，学习各家公司，以彼之道，还施彼身，使得慕容公子的组织能力(Swarm借鉴了很多前面的集群管理思想)也在逐渐的成熟中。

三大容器门派，到底鹿死谁手，谁能一统江湖，尚未可知。

欲知后事，且听下回分解。