云计算概述

云计算主要解决了四个方面的内容：计算，网络，存储，应用。

计算就是CPU和内存，例如“1+1”这个最简单的算法就是把“1”放在内存里面，然后CPU做加法，返回的结果“2”又保存在内存里面。网络就是你插根网线能上网。存储就是你下个电影有地方放。本次讨论就是围绕这四个部分来讲的。其中，计算、网络、存储三个是IaaS层面，应用是PaaS层面。

云计算发展脉络

云计算整个发展过程，用一句话来形容，就是“分久必合，合久必分”。

第一阶段：合，即物理设备

物理设备简介

在互联网发展初期，大家都爱用物理设备：

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

物理设备的缺点

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

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

第二阶段：分，即虚拟化

虚拟化简介

因为物理设备的以上缺点，就有了第一次“合久必分”的过程，叫做虚拟化。所谓虚拟化，就是把实的变成虚的：

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

虚拟化解决的问题

虚拟化很好地解决了在物理设备阶段存在的三个问题：

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

虚拟化时代的生态

在虚拟化阶段，领跑者是Vmware，可以实现基本的计算、网络、存储的虚拟化。如同这个世界有闭源就有开源、有windows就有linux、有Apple就有Android一样，有Vmware，就有Xen和KVM。

在开源虚拟化方面，Xen 的Citrix做的不错，后来Redhat在KVM发力不少；对于网络虚拟化，有Openvswitch，可以通过命令创建网桥、网卡、设置VLAN、设置带宽；对于存储虚拟化，本地盘有LVM，可以将多个硬盘变成一大块盘，然后在里面切出一小块给用户。

虚拟化的缺点

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

第三阶段：合，即云计算

云计算解决的问题

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

私有云、公有云的两极分化

这样，Vmware有了自己的Vcloud；也有了基于Xen和KVM的私有云平台CloudStack（后来Citrix将其收购后开源）。

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

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

私有云厂商与公有云厂商的联系与区别

如果仔细观察就会发现，私有云和公有云虽然使用的是类似的技术，但在产品设计上却是完全不同的两种生物。

私有云厂商和公有云厂商也拥有类似的技术，但在产品运营上呈现出完全不同的基因。

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

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

公有云生态及老二的逆袭

公有云的第一名AWS活的自然很爽，作为第二名Rackspace就不那么舒坦了。

没错，互联网行业基本上就是一家独大，那第二名如何逆袭呢？开源是很好的办法，让整个行业一起为这个云平台出力。于是Rackspace与美国航空航天局（NASA）合作创始了开源云平台OpenStack。

OpenStack现在发展的和AWS有点像了，所以从OpenStack的模块组成可以看到云计算池化的方法。

OpenStack的组件

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

OpenStack带来私有云市场的红海

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

公有or私有？网易的选择

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

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

第四阶段：分，即容器

现在来谈谈，应用层面，即PaaS层。

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

1. PaaS的定义与作用

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

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

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

2. PaaS的优点

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

3. PaaS部署的问题

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

容器的诞生

1. 容器的定义

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

2.容器在开发中的应用

设想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用户，都可能导致程序的运行失败。