写在前面

作为公有云的资深用户，测试过多家云平台数十个实例之后，我们一直在思考两个问题：客户最需要云厂商提供的核心能力是什么？应该如何评估一家云厂商的产品技术能力？

接下来的几篇文章中，潮云实验室将结合长期的测试数据，帮助大家选择最合适的云服务器，同时探讨几家主流云厂商的产品差异和背后的设计理念。今天，我们先从计算入手。

跑分不是唯一标准

很长一段时间，跑分似乎成为衡量性能的唯一标准，但是从实际体验来看，单纯依赖跑分去选择产品，是非常片面的决断。

首先，有些跑分工具本身就有问题。比如，近期就有爆出Unixbench跑Pipe-basedContext Switching用例时，虚拟机的得分甚至超过同等级物理机的情况（目前已经有补丁修复）。

其次，跑分往往只能测出一段时间内的性能值，但不能体现产品长期的稳定性。

计算能力：主频, IPC, 稳定性

先来看一个简单的公式：

CPU的计算性能=主频× IPC(Instruction Per Clock 即每周期执行指令数)。

所以，提升CPU处理性能的途径，可以是提升主频，也可以提升IPC。

主频：高主频肯定能带来计算性能的增长，但是高主频的CPU往往价格昂贵，另外随着主频的提升，功耗会成指数级增长，这部分运营成本(opex)当然最后也会算给客户。

IPC：要提升IPC，可以通过提高指令执行的并行度来实现，主要有两个途径：一是提高微架构的并行度，二是采用多核架构。在微架构并行度一致的情况下，关注多核架构。采用多核架构，可以减缓由于主频提高而功耗急剧上升的坡度。如果功耗相同，毫无疑问多核CPU的性能会比单核CPU要高。

我们结合价格数据来看看，以下为华为云部分产品的价格和性能对比：

1. 从提高主频的角度来看，对比计算性能，C3.large.2比S3.large.2提高了36%，但是价格却高了44%。

2. 从提升IPC的角度来看，S3.xlarge.2比S3.large.2计算性能高一倍，价格也正好高一倍。

有兴趣的也可以去对比一下其他产品，都是类似的。

如果单纯要提升计算性能，采用提升IPC的方式，更具性价比。

稳定性：相对于前两个，稳定性很难在产品页面被参数化描述，但是却是企业场景里很重要的一点，我们来重点聊聊关于CPU稳定性的那些你还不了解的事。

稳定性和vCPU绑定

很多人有这样的疑问：为什么我购买的服务器CPU性能波动那么大？今天我们就来详细说说背后的主要原因：vCPU的绑定。

先来看看什么是vCPU绑定。

假设用户购买一个2 vCPU的虚拟机，我们来看看绑定和不绑定的区别：

在绑定的情况下，通过设置处理器亲和性（Processor Affinity），这两个vCPU会映射到预定core的两个超线程HT(Hyper-Threading)上。

有人会问为什么是同一个core的两个HT，而不是两个位于不同core的HT呢？这是为了独占该core的所有资源，避免其他用户的干扰。

而不绑定的情况下，这两个vCPU会随机落到不同core的任一超线程上，往往分布在两个不同的物理core。

绑定的时候，单个core采用超线程技术能同时执行两个线程，但它并不象两个真正的CPU core那样，有些资源是需要共享的, 比如图中的L1指令和数据缓存，L2缓存。当两个线程都同时需要某一个资源时，其中一个要暂时停止，并让出资源，直到这些资源闲置后才能继续。因此超线程的性能并不等于两颗CPU core的性能。如果CPU core不分超线程，能跑出100%的能力的话，加了超线程大概能到115%-130%的能力。所以2个vCPU的性能大概等于115%-130%的单物理CPU core能力，但是该core所有资源被用户独占，业务运行稳定。

在不绑定时，每个vCPU往往单独分配去一个CPU core，这种情况下，大部分core内资源是和其他用户共享的，如图：

我们分为两种情况讨论一下：

1. 服务器空闲，即另一个超线程空闲。这时候2个vCPU的性能能真正达到200%单物理CPU core的能力（资源被独立占用，无争抢），且较平稳。

2. 服务器忙碌，你的vCPU会受到其他用户机的负载水平影响，双方产生资源争抢，表现为业务性能不稳定。

显然，使用不绑定的策略虽然能带来性能上的提升，但是和云服务的稳定性和隔离性的要求背道而驰，这相当于把自己业务稳定的主动权交给了其他用户！

那么问题来了，怎样确定云服务器有没有绑定vCPU！？

判断依据如下：如果测试单vCPU性能时接近物理CPU性能，而测试双vCPU性能时，两个vCPU性能都有一定程度的下降，那么这款实例是对vCPU进行绑定的。反之，如果两个vCPU性能仍然都接近物理CPU性能，那么一定没有绑定。

vCPU不绑定情况下性能测试

为了进一步论证，我们选取了一台腾讯云HS20专用宿主机(56核)，来模仿vCPU不绑定情况下多租户“拥挤”的使用场景。

把该物理机分成7台8核32G的虚拟机，其中一台为被测机，另外6台为干扰机。

在不同的干扰压力下(无压力，N个进程跑super_pi压力等)的业务性能,测试结果如下(以mysql_read性能为例)：

完整的mysql_read，mysql_write，mysql_read_write性能对比图如下：

可以看到，随着干扰进程数的增加，

1. QPS明显呈下降趋势, read性能下降34%, write性能下降35%,read_write性能下降30%。

2. 平均延时明显上升，read延时上升50%，write延时上升37%，read_write延时上升42%。

实验显示，vCPU没有绑定情况下，被测虚拟机受同机其他虚拟机的干扰非常大。

主流云厂商部分实例vCPU绑定盘点

用前文提到的测试方法，大致测了一下主流云服务器厂商的部分实例的vCPU绑定情况，结果如下：

可以看到，AWS和阿里云的企业级产品已经进行vCPU绑定，这些产品当然会有更好的稳定性体验。

腾讯云、华为云的几款实例及阿里云T5，AWS T2等非企业级实例，均未进行绑定，潮云实验室后续将对这几款产品进行进一步的性能测试。

小结

简单总结一下，要获得更好的计算性能，核数比主频更具性价比。

对于企业级用户来说，优先选择vCPU绑定的实例，计算性能更稳定、可预期。

不绑定vCPU在闲时可获得更高的性能，但隔离性差，不可预期，有一定业务风险。

在最终选型上，还是要根据自己的业务形态来选择合适的实例。

同时，我们也需要有清醒的认识，对云服务器来说性能测试和实际应用会有偏差，比如vCPU的绑定与否就会影响性能测试结果。

对于云计算产品，我们需要考量的还有很多。

转载：潮云实验室

分布式与云计算深刻地影响着搜索引擎的发展。与其说是云计算影响了搜索引擎，不如说是搜索引擎的发展产生了云计算的概念。Google正是由于在云计算领域的领先，才能多年在搜索领域保持霸主的地位。本节以Google的架构为例，看一下云计算是如何应用在爬虫之中的。

Google的三大核心技术构成了实现云计算服务的基础：GFS(Google文件系统)、MapReduce(分布式计算系统)和 BigTable(分布式存储系统)。

GFS(Google文件系统)位于这三项技术的最底层，负责许多服务器、机器数据的存储工作，它将一个“大体积数据(通常在百兆甚至千兆级别)分隔成固定大小的数据块放到两到三个服务器上。这样做的目的是当一个服务器发生故障时，可以将数据迅速地通过另外一个服务器恢复过来。在存储层面，机器故障的处理由Google文件系统来完成。

MapReduce (分布式计算系统)是Google开发的编程工具，用于1TB数据的大规模数据集并行运算。这项技术的意义在于，实现跨越大量数据节点分割任务，使得某项任务可以被同时分拆在多台机器上执行。例如把一项搜索任务拆分成一两百个小的子任务，经过并行处理后，将运算结果在后台合并，最后把最终结果返回到客户端。

BigTable(分布式存储系统)作为 Google 的一种针对半结构化数据进行分布存储与访问的接口或服务，它是建立在GFS和MapReduce之上的结构化分布式存储系统，可以帮助Google最大限度地利用已有的数据存储能力和计算能力，在提供服务时降低运行成本。

书名：自己动手写网络爬虫

作者：罗刚, 王振东

出 版 社：清华大学出版社

定价：￥43.00

云计算数据中心是一整套复杂的设施，它不仅仅包括计算机系统和其它与之配套的设备（例如通信和存储系统），还包含冗余的数据通信连接、环境控制设备、监控设备以及各种安全装置。作为云架构的基础设施之一，云计算数据中心的构建至关重要。

传统的数据中心网络的架构包括四大部分，即核心层、汇聚层、接入层和运营管理层。核心层一般采用双机冗余的路由设备，对外运行E-BGP或静态路由协议，对内运行IGP协议（如OSPF）；汇聚层采用双机冗余的三层交换机；接入层和运营管理层则采用二/三层交换机。

目前的网络结构有以下缺点，例如网络层次较多、时延大，核心层或网络层网络设备容量会成为发展的瓶颈，同时随着数据中心规模越来越大，网络结构也成为瓶颈问题。

网络传输由于技术成熟度和设备价格成本等因素，传统数据中心网络一般使用以太网进行数据的传输。然而传统数据中心网络与互联网运行环境有极大差别，其特殊的数据转发需求例如负载均衡或者多路径传输等，必须通过特殊的转发机制实现。这存在以下问题：一是传统的数据包转发设备，例如以太网交换机，除非进行重新设计否则无法实现这些需求；二是基于软件的转发可以通过编程很方便的实现不同需求，但是无法以较低成本达到性能要求。

解决方案针对上述问题，提出云数据中心采取扁平化结构来进行构建。 首先，由于数据中心交换机的容量和性能逐渐优越，核心层的路由转发和防攻击的功能完全可被汇聚层的交换机实现，因此从减少时延的角度可采用2层的扁平化架构，将核心层和汇聚层合并。

其次，横向扩展设备的同时会造成出口设备数量多，导致管理复杂，为了简化管理和避免STP/MSTP/RSTP等协议造成带宽利用率不高的问题，可在单纯的提高设备性能的基础上，将临近的同类网络设备进行集群化以满足需求。

最后，使用以太网进行数据传输时，由于运行环境的差别导致其转发机制各不相同，可使用VLAN技术通过软件的配置而不是对局域网的主机进行物理上的划分，实现动态灵活地将服务器群或存储设备分割成多个逻辑网络，适应不同的传输环境。同时采用传统的STP+VRRP技术部署二层网络时会带来部署复杂、链路利用率低、网络收敛时间慢等诸多问题，因此网络方案的设计需要重点考虑增强二级网络技术（如IRF/VSS、TRILL等）的应用，以解决传统技术带来的问题。

我们在基础篇中对SDN的基础概念、核心思想以及市场现状都进行简单地阐述，在本文中将就技术实现方面深入展开讨论。

在ONF于2016年发布的《SDN Architecture Issue 1.1》白皮书中，给出了最新的SDN架构，如下图所示：

SDN自上而下分为三层：应用层、控制器、转发平面，控制器开放标准的南向接口、北向接口进行应用的开发和设备的接入。由上图可见SDN主要研究重点是控制器组件，控制器的核心功能是将底层的资源进行编排和功能的虚拟化（Orachestration & Vritualization）来满足上层应用的请求。

A-CPI：即Application-Controller Plane Interface，控制器通过A-CPI北向接口对网络应用或者更高层次的控制器暴露网络服务和资源；D-CPI：即Data-Controller Plane Interface，控制器通过D-CPI南向接口对数据转发设备提供的服务和资源进行控制、管理和消费；Resource：代表任何可用于交付的网络服务，包括物理网络资源（拓扑，链路和端口）和逻辑资源（标签等），也可以是虚拟化的网络资源（NFV）。Server context: 控制器内部对给定网络设备所有资源的概念抽象组件，负责底层设备的管理和控制，也可以理解为在控制器侧针对特定网络设备所提供的能力和资源的适配器或者驱动。Client context: 控制器侧为维护特定客户端应用的所有信息的概念抽象服务端组件，负责控制器与应用的管理和控制。Virtualization: 将底层的特定的资源进行抽象，并根据选择策略分配到相应的客户端应用或者其他服务。Orchestration：根据变化持续地优化网络服务的供给策略，来满足客户端的需求。

SDN是云计算催生下的新一代网络变革，毋容置疑会成为兵家必争之地。众多包括传统网络设备厂商和新兴创新者在内纷纷推出了多种SDN解决方案，有商业化闭源的如VMware NSX、思科ACI、微软HNV等，开源项目也层出不穷，如OpenDaylight、ONOS、OpenContrail、Ryu、Foodlight、NOX等。下面我们选取其中三个主流的实现方案进行分别介绍：

SDN实现之一：VMware NSX

VMware NSX是纯软件实现的SDN解决方案的典型代表。NSX是由VMware vShield产品与其收购的Nicira NVP产品整合的产物。在2017年VMware NSX-T 1.1正式发布之前分为两个分支，NSX for vSphere (NSX-v)主要以VMware vShield的组件为主，NSX for Multiple-Hypervisor (NSX-MH)即针对KVM/Xen OVS用户，主要以NVP为主，而NSX-T则是二者完全整合同时可以支持vSphere以及其他Hypervisor，如KVM/Xen。

NSX 架构及其组件

NSX的主要目标之一是将应用于底层网络解耦，像管理虚拟机一样管理网络：创建、删除、扩展、缩容。因此在NSX的架构中，物理网络的功能只需要保证L2和L3的互联互通即可，所有网络高级功能和配置都在逻辑网络层实现。

在数据转发平面由两类组件构成：分布式组件和集中式组件。分布式组件分别安装在每台vSphere ESXi主机的Hypervisor上，仅对本主机上的虚拟机网络报文进行处理，主要应用于数据中心内部东西向（East-West）网络流量，包括L2 Logic Switch、L3 Distributed Logic Router、L2-L4 Distributed Firewall。集中式组件主要应用于网关上，处理数据中心（不同网络）之间南北向（North-South）出入口的网络流量，目前所有组件（NAT, DHCP, VPN, LB, Router）安装在虚拟机Edge Service Gateway中。

控制平面：维护着四张表：路由表、ARP表、MAC表、VTEP表。路由表是用来指明目的IP的下一跳的IP，ARP表是用来查询虚拟机IP地址所对应的MAC地址，MAC地址表记录虚拟机所有的MAC地址与VTEP的映射，VTEP表是记录逻辑交换机的用于封装VXLAN报文的IP地址。在报文到达数据平面时，数据平面代理会向控制平面请求转发/处理所需信息。

管理平面：作为NSX配置的唯一单点入口，并对外提供NSX配置的REST API。

云管平面：云管平台对外向最终用户提供网络资源的消费。

主要应用场景：

网络配置的复杂性难以满足云计算中的对网络灵活性的要求。在多租户的环境中，成百上千万级用户在每时每刻都在需要进行网络的创建、删除、修改的请求，而通过传统的工单形式显然无法满足敏捷性需求。然而传统的网络配置很大程度上依赖于人工操作，没有统一标准的API支持，所以网络自动化难度较大。而NSX一切网络相关的配置都在逻辑网络的软件层通过API自动化完成，无需网络管理员干预，也极大地简化网络运维的复杂度。大规模云服务租户之间隔离网络规格的限制。在云计算环境中，基于安全性考虑，租户之间通常要求在二层网络进行访问隔离，而传统网络IEEE 802.1Q的协议中仅支持4095个VLAN，显然在大规模的云环境中是无法满足需求的，因此需要大二层Overlay技术（VXLAN）来突破该限制。而NSX采用的VXLAN技术将普通的虚拟机网络报文封装在一个四层的UDP报文中，提供多达16M个子网。数据中心（不同网络）之间负载的迁移。由于不同的数据中心（不同网络）所在IP地址段通常不同，因此在跨数据中心或者网络之间进行网络迁移时，必须在迁移后进行网络的重新配置，这破坏了迁移带来的业务连续性。而通过大二层技术只要保证网络的四层UDP可达，上层的虚拟机不会感知下层的网络变化，无需进行任何修改。应对大规模、高密度虚拟化环境中的MAC地址爆炸问题。由于VXLAN技术在每台主机上只需要配置一个VTEP来提供虚拟机报文封装服务，因此大大降低了物理网络需要维护的MAC地址列表，极大地提升了网络转发效率。

优势：

基于VMware生态具有完整的商业化SDN解决方案，因此对于VMware产品具有天然的兼容性，并且已经经过大规模的商业化部署的验证。随着Nicira的团队的收购加入以及雄厚的资金投入，SDN技术势力整体得到全面提升，在纯软件的SDN方案于世界领先水平。软件栈从上到下都自主可控，因此易于进行全方位的优化，从而有助于持续地提升，如分布式防火墙性能目前几乎达到线速。

讨论:

VMware NSX没有按照严格意义的SDN架构实现，控制器的南向接口和北向接口都采用的是私有协议，并且不开放编程接口，而是通过管理平面提供RESTful的编程接口。VMware NSX整体解决方案中只有部分功能实现了控制平面和转发平面分离：L2逻辑交换、L3逻辑路由、防火墙、负载均衡、NAT等由管理平面直接下发指令。

SDN实现之二：ODL控制器

ODL（Open DayLight）是2013年由设备厂商和软件厂商为主导成立的一个开源SDN组织。设备厂商与其坐以待毙接受这场无可逆转的革命，还不如利用自己在业内的领导力和雄厚的技术实力参与其中，共同发掘新的金矿，争得新时代网络革命的一席之地。于是众多的设备商纷纷贡献出自己的技术，联手研发灵活统一控制平台，并在此基础上提供高质量的商业应用。

参与厂商包括：BROCADE、CISCO、ERICSSON、中兴、Arista Networks、阿里云、AT&T、AVAYA、FUJITSU、JUIPER、华为、新华三等。

ODL是一套基于JAVA开发的模块化、可插拔的灵活的SDN控制平台。同样基于SDN架构分为三层：网络应用和业务流程层、控制器平台层以及物理/虚拟网络设备层。

控制器分别通过北向和南向接口与其他二者连接。ODL南向接口使用netty来管理底层并发IO以及异步通信框架来支持多种协议与设备通信，如OpenFlow、OVSDB、NETCONF、BGP、SNMP等。

模型驱动的SAL（服务抽象层）是控制器模块化的核心，以插件的形式支持不同的底层设备，屏蔽了协议间差异，为控制器提供一致的服务：如数据包服务，流编程服务，清单服务，能力抽象服务等。

控制器平台还提供一系列的功能模块，包括拓扑管理、状态管理、交换机管理、主机追踪、最短路径转发等基本网络服务功能，以及OpenStack、floodinglight（VTN）、多租户网络虚拟化（DOVE）等扩展服务。

ODL定义了两种标准的北向接口：OSGI和REST。其中OSGI适用于模块化、面向组件、面向服务的较底层的应用开发，与控制器在同一运行地址空间，而REST是以资源的角度观察整个网络，通常用于控制器的监控和管理应用的开发。

优势：

丰富的南向接口支持多种协议，设备兼容性强。服务抽象层的模型具备厂商自定义属性能力，这就意味着一个特定网络设备功能很容易与ODL集成。

不足：

文档不够完善。版本演进过程没有清晰地说明和很好地控制，比较臃肿，存在不少废弃的代码。

SDN实现之三：ONOS

随着移动设备的不断普及以及基于云计算的OTT服务和内容分发业务爆发式增长，运营商迫切需要一次网络的变革，来提高运营的敏捷性应对指数级的带宽增长要求，ONOS便应运而生。ONOS是开放网络操作系统(Open Network Operating System)的缩写，是有全球各大运营商主导的首款开源SDN网络操作系统，主要面向服务提供商和企业骨干网。吸引了大批的国内外各知名设备厂商和运营商如AT&T、NTT通信、中国联通、Ericsson、Fujitsu、Intel、NEC等。华为也在2016年发布了基于ONOS的业界首款全景SDN同一控制器Agile Controller 3.0，面向广域网、数据中心网、企业园区以及IOT等场景。

从上图可以看出，ONOS除遵循标准SDN架构的，包含应用层、北向接口、核心层、南向接口以及适配层、设备层之外，有如下两个主要特点：

ONOS提供两个强大的北向抽象层，意图框架和全局网络视图。意图框架像真正操作系统那样将应用与网络服务具体实现细节进行抽象和隔离，提高了网络应用的开发速度。全局网络视图为应用提供了整体的网络视图，包括主机、网络设备相关的状态参数，计算最短路径，负载均衡，引流等。ONOS最大的特点是采用的分布式核心以多层次的架构组织。当ONOS以集群式部署在服务器上时，每台服务器上对称地运行相同的ONOS软件，以确保在ONOS服务器发生故障时可以快速地进行故障切换，同时在扩展集群时也能保证业务的持续性。ONOS通过发布/订阅的模式在多个实例之间进行消息的高效同步，每个转发平面关联一个主ONOS实例，当一个实例失效时，会从其他的实例中选举一个作为替代，从而转发设备零中断地切换到新的主控制器。

优势：

ONOS轻量化的设计，更加注重可靠性、性能和扩展性。ONOS提供系统的文档支持，采用清晰的目录索引，非常易于检索。

总结

ONF（开放网络组织）致力于推动SDN的标准化，打破各自为政的竖井。但整个市场仍然呈现出百家争鸣的格局，同时纵观国内外各知名厂商的商业化产品，大多一边在紧跟开源先进技术的同时，一边还在自己造轮子。

SDN技术的新生力量仍需在传统网络设备厂商格局中突围。SDN最初有望打破传统网络设备厂商的垄断，培育出更多有创新能力的新兴企业。然而，由于该网络市场依然形成寡头垄断的局面，无论从资金实力还是从技术实力大多还在传统网络设备上手中把控，这些龙头企业也并未就此故步自封，他们也在积极地迎接新的变化。

同时很多客户也对新兴技术持观望态度，因此很多厂商提供的SDN设备在Hybrid兼容模式下工作，即既可以在SDN控制平面和转发平面分离的模式下工作，也可以以传统的模式独立提供服务。

参考资料：

https://opennetworking.orgSDN Architecture 1.1Inter-Datacenter WAN with centralized TE using SDN and OpenFlowSDN架构 http://developer.huawei/cn/ict/products/sdn/components/forum/re/sdnconceptandbenefits

文中图片来源：

图1：https://3vf60mmveq1g8vzn48q2o71a-wpenginedna-ssl/wp-content/uploads/2014/10/TR-521_SDN_Architecture_issue_1.1.pdf

图3：https://slideshare/nyechiel/nfv-meetup-by-red-hat-january-2015

图4：https://sdnlab/4309.html

（图2为作者制作）

关于SDN与云计算平台的集成方案以及应用场景的讨论，敬请继续关注《云计算时代催生下一代网络变革-软件定义的网络》系列文章之三《集成应用篇》。

首先，选择超融合架构的原因，是传统存储解决不了现在企业数据中心的问题。

据麦肯锡研究显示，全球的IT数据每年在以40%的速度增加中。数据正在逐步影响商业，企业通过数据的分析来做决策与管理。

完成快速的分析决策和管理，就需要借助强大的数据中心。下图为传统SAN存储：

但是，光靠越来越快、核数越来越多的CPU是不够的，瓶颈在于传统存储的硬盘太慢了，CPU大部分计算能力都空闲或者说在等待存储数据传输过来。传统存储容量和性能不具备和“计算能力”匹配的可扩展性，不能满足企业进行数据访问的需求。

这个问题并不是现在才有。Google很早遇到这个问题。那么Google是如何做的呢？

作为一个给全世界互联网网民提供数据检索的企业，Google考虑过EMC、IBM，还有当年的SUN存储产品，但是都解决不了它的问题。无论是容量还是性能，这些公司的产品都无法满足Google的规模需求。于是Google只能自己建立一个适合自己的数据搜索的存储结构了。

Google优秀的计算机科学家们，打破了传统的存储思维，利用服务器的本地硬盘和软件构建了一个容量和性能不断可扩展的分布式文件系统，并在其上构建了其搜索和分析的计算引擎：不用把数据从存储端取出来，然后通过网络传输到计算端，而是将计算直接分发到存储上运行，将“计算”作为传输单元进行传输，这样大量的存储数据都是本地访问，不需要再跨网络上传输了，自然访问很快。于是乎，自然而然地，“计算”和“存储”运行（“融合”）在了一个服务器上，这里我们也看到超融合架构的一个优势就是，本地访问数据，不必跨网络。

现代企业的数据量越来越大，应用越来越多，他们开始面临当年Google遇到的问题，CIO要考虑怎么更高效的构建自己的计算和存储的基础架构，来满足应用的数据访问需求。

虚拟化为更容易的管理应用而生，它解决了CPU、内存资源闲置的问题。但随着虚拟化的大规模应用，虚拟机越来越多，虚拟机在传统存储上运行却越来越慢了。“慢”造成“体验差”，“体验差”成为了限制虚拟化应用的最大的瓶颈。这里面的最重要原因自然是，存储的I/O性能不够，大量的虚拟机和容器同时运行，I/O的混合，使得随机读写急剧增加，传统存储的结构无法承受大量的随机I/O.超融合恰恰是为了解决这个问题，才被带到了虚拟化和容器领域。同时，业内也存在不同的解决I/O问题的方法，我们先尝试分析下其他的解决方法：解决方法一：在存储设备采用SSD做Cache，加速I/O.这在一定的规模下可能有效，但是存储设备的SSD Cache通常比例较小，不足5%的容量比的情况下，自然满足不了用户的热数据的缓存需求。另外，仍然无法随需扩展，所有的数据仍然要从集中的存储控制器流出，这个集中的“收费站”势必堵塞“高速公路”。

解决方法二： 使用服务器侧SSD做Cache，加速I/O.这种类似的解决方案，通常缺乏高可靠性软件的支撑，服务器端的Cache如果用做写Cache，存在单点失效的问题，需要在多个服务器的Cache设备上，做副本来提供可靠性，可以说这是一个阉割版的超融合架构，将Cache放到服务器端，仍然使用传统存储，当Cache满，需要被写回传统存储的时候，仍然被传统存储的“控制器”限制整体性能。

我们看到，上面的两种方案都是受限于传统存储的结构，超融合存储则不一样，通过完全去掉传统存储，利用分布式文件系统来提供“不可限量”的性能和容量，在这个基础上，再通过Cache进行加速，甚至全部使用闪存（全闪存产品）来构建都是自然而然，不被限制了。

因此，超融合架构不是为了让单台服务器的存储飞快，而是为了让每增加一台服务器，存储的性能就有线性的提升，这样的存储结构才不限制企业业务的运行，并保证业务的可靠性。

正因为这种扩展性很好的共享存储，使得整个Google的业务得以顺畅地运转。SMARTX在做的就是这样的更好的、更稳定的基础服务。

另外，超融合近几年得以快速发展的原因，这要归功于硬件设备。CPU核数越来越多，服务器的内存容量越来越大，SSD设备和网络互联网设备越来越快，这意味着：a. 服务器的资源除了运行业务以外，仍然可以预留出来足够的CPU，内存资源来运行存储软件。将存储软件和业务运行到一块，既减少了设备量，减少了电力使用，本地读取也提高了I/O的存取效率。这在几年前是做不到的，因为CPU和内存太有限了。

b. 网络互联越来越快，无论是万兆，40Gb以太网，还是Infiniband（无限宽带技术），使得我们的软件能够将独立的存储设备进行互连，通过分布式文件系统形成共享的存储池，供上层应用使用。

c. 如果说SSD等硬件厂商让单个存储设备跑的更快，我们的软件的意义在于，让超大量的这些存储设备，一起工作，提供无止境的整体性能和容量。

我们知道云计算主要有三种服务模式，IaaS、PaaS和SaaS，其中最底层最基础的就是IaaS。企业级私有云领域，目前IaaS领域的老大就是VMWare公司；在开源领域，最流行的IaaS框架则是OpenStack框架。

正是因为开源，才让我们可以更深入地了解云计算IaaS的运作机制。通过对OpenStack的架构的介绍，说明OpenStack是如何实现IaaS服务的。

OpenStack的起源

在云计算领域，目前Amazon占据了绝对领先的市场地位。Amazon的CEO贝佐斯靠着强硬的行政命令要求开发人员按照SOA理念来进行开发，要求所有程序模块必须要用服务接口把数据和功能开放出来。所有程序模块间的通信，必须通过这些接口进行。

可以说SOA的设计思想，构成了今天AWS云平台的技术实现基础，同样这种设计思想也被OpenStack所效仿。AWS虽好，但毕竟是商用的，随着云计算的发展，开源云平台解决方案的需求越来越强烈。

2010年7月，RackSpace和美国国家航空航天局合作合作，分别贡献出RackSpace云文件平台代码和NASANebula平台代码，OpenStack由此诞生。

AWS分层架构

OpenStack的架构

作为Amazon的追随者，OpenStack在技术架构上也与AWS有很多相似之处。OpenStack也是由几个独立的核心功能组件所构成。

分别是计算（Compute）、对象存储（ObjectStorage）、认证（Identity）、用户界面（Dashboard）、块存储（BlockStorage）、网络（Network）和镜像服务（ImageService）：

Nova：计算管理，云计算IaaS的核心，类似于Amazon的EC2（ElasticComputeCloud）。为用户提供虚拟机的管理，比如创建虚拟机或对虚拟机做热迁移。Swift：对象存储，负责对文件进行存储和检索，也包括镜像文件。Keystone：为用户提供身份验证以及OpenStack服务的授权。Horizon：为用户提供一个模块化的控制面板，基于django框架实现。Cinder：块存储服务，为虚拟机提供虚拟卷。Neutron：为虚拟机提供网络连接，允许用户创建自己的虚拟网络并连接各种网络设备。Glance：负责镜像管理，为虚拟机提供镜像。

关于每个组件的具体职责，可以参见前文《云计算IaaS管理平台的基本功能有哪些？》

OpenStack的应用

国际公有云方面，AWS、AZure都采用了自己的技术来搭建云计算平台。在国内公有云市场中，阿里云、腾讯云也都是用自有技术来搭建各自的云计算平台，没有直接利用OpenStack。

虽然在公有云市场，应用OpenStack的商业案例还不算多，但在私有云市场，基于OpenStack的项目非常多，远远多于其他的开源云计算框架,如CloudStack、Eucalyptus和OpenNebula等。

与互联网公司不同，华为倒是非常积极地推进OpenStack技术，和中国三大电信运营商们一并都是OpenStack基金会的黄金会员（GoldenMember），而且为国内外多家电信运营商都部署了基于OpenStack的公有云系统。

目前OpenStack的黄金会员主要包括传统IT企业，如Intel、NEC、Dell、VMWare等，也包括通信设备商，如华为、Ericsson、Cisco、JuniperNetworks等，也包括最新加入的国内三大运营商。相信虽然OpenStack的参与者越来越多，生态越来越完善，应用项目也会越来越多。

在今天的改变与未来的发展预测中表明，有越来越多的企业开始主动拥抱“云”，用云计算提升自身的IT服务能力和运营效率。云计算要求基础设施具有良好的弹性、扩展性、自动化、数据移动、多租户、空间效率和对虚拟化的支持。应当高度贴合网络未来更高层次的发展趋势，随需而动的运维理念。

那么具体而言，应着重从高端服务器、高密度低成本服务器、海量存储设备和高性能计算设备等基础设施领域提高云计算数据中心的数据处理能力。那么，云计算环境下的数据中心基础设施各部分的架构应该是什么样的呢?我们来看这两点的分析：

1，云计算机房架构

为满足云计算服务弹性的需要，云计算的机房一般都将采用标准化、模块化的机房设计架构。模块化机房包括集装箱模块化机房和楼宇模块化机房。为减轻了建设方在机房选址方面的压力，帮助建设方将原来半年的建设周期缩短到两个月，而能耗仅为传统机房的50%,可适应沙漠炎热干旱地区和极地严寒地区的极端恶劣环境。楼宇模块化机房采用冷热风道隔离、精确送风、室外冷源等领先制冷技术，可适用于大中型数据中心的积木化建设和扩展。

2，云计算数据中心总体架构

云计算架构分为服务和管理两大部分。在服务方面，主要以提供用户基于云的各种服务为主，共包含3个层次：平台即服务PaaS、基础设施即服务IaaS、软件即服务SaaS.在管理方面，主要以云的管理层为主，它的功能是确保整个云计算中心能够安全、稳定地运行，并且能够被有效管理。着力于提高网络数据处理和存储能力，致力于低碳高效的利用基础资源。

一、云计算介绍

任何一个在互联网上提供其服务的公司都可以叫做云计算公司。其实云计算分几层的，分别是Infrastructure（基础设施）-as-a-Service，Platform（平台）-as-a-Service，Software（软件）-as-a-Service。基础设施在最下端，平台在中间，软件在顶端。别的一些“软”的层可以在这些层上面添加。

云计算架构示例1

云计算架构示例2

云计算架构示例3

二、云计算服务模式

1、IaaS: Infrastructure-as-a-Service（基础设施即服务）

基础架构，或称基础设施（Infrastructure）是云的基础。它由服务器、网络设备、存储磁盘等物理资产组成。在使用IaaS时，用户并不实际控制底层基础架构，而是控制操作系统、存储和部署应用程序，还在有限的程度上控制网络组件的选择。

通过IaaS这种模式，用户可以从供应商那里获得他所需要的计算或者存储等资源来装载相关的应用，并只需为其所租用的那部分资源进行付费，而同时这些基础设施繁琐的管理工作则交给IaaS供应商来负责。

我们从阿里云上购买的云主机就是属于此类了。

2、PaaS: Platform-as-a-Service（平台即服务）

平台即服务（Platform as a Service，PaaS）提供对操作系统和相关服务的访问。它让用户能够使用提供商支持的编程语言和工具把应用程序部署到云中。用户不必管理或控制底层基础架构，而是控制部署的应用程序并在一定程度上控制应用程序驻留环境的配置。PaaS的提供者包括Google App Engine、Windows Azure、Force、Heroku等。小企业软件工作室是非常适合使用PaaS的企业。通过使用云平台，可以创建世界级的产品，而不需要负担内部生产的开销。

3、SaaS: Software-as-a-Service（软件即服务）

软件即服务（SaaS）为商用软件提供基于网络的访问。您有可能已经使用过SaaS，即使您当时并不知道。SaaS的示例太多了，例如Netflix、Photoshop、Acrobat、Intuit QuickBooks Online、Gmail、Google Docs、Office Web Apps、Zoho、WebQQ、新浪微盘等等。可能不太明显的SaaS实现包括移动应用程序市场中的相当一部分。

简单的说，就是做好软件，用户基于互联网来使用就可以了，并且是可以按需购买使用。

4、DaaS：Data-as-a-service（数据即服务）

DaaS是Data-as-a-service（数据即服务），是继 IaaS、PaaS、SaaS之后又一个新的服务概念。

数据即服务(Data-as-a-Service，DaaS)通过资源的集中化管理，为提升IT效率以及系统性能指明了方向。因此DaaS在过去的几年中得到了许多CIO的青睐，它包含的主要技术有数据虚拟化、数据集成、SOA、BPM以及PaaS等。

5、CaaS：Communications-as-a-Service（通讯即服务）

CaaS是Communications-as-a-Service缩写，意思是通讯即服务(也可称为协作即服务)。CaaS是将传统电信的能力如消息、语音、视频、会议、通信协同等封装成API(Application Programming Interface，应用软件编程接口)或者SDK(Software Development Kit，软件开发工具包)通过互联网对外开放，提供给第三方（企业、SME、垂直行业、CP/SP以及个人开发者等等）使用，将电信能力真正作为服务对外提供。

6、MaaS：Machine as a Service（物联网即服务）

MaaS(Machine as a Service)物联网即服务，这个概念伴随着物联网产生，物联网常见的两种业务形式就是MAI与MaaS，因此MaaS属于物联网业务形式的一种。

7、XaaS：X as a service（一切都是服务）

一切皆服务（XaaS）是一个统称，代表 “X as a service”、“anything as a service”或“everything as a service” 。这一缩写指越来越多地通过互联网提供的服务，而不仅仅指本地或现场服务。云计算的本质就是XaaS。

以上六种服务都是XaaS。

三、总结

everything as a service

以前我们使用软件可以说都是一个拷贝(everything is a copy)，在云计算时代，我想只能说所有软件可能都是“everything as a service”。

更多深度文章，请关注云计算频道：https://yq.aliyun/cloud

摘要：从传统IT部署到云，人肉运维已经是过去式，云上运维该怎么开展？人工智能对于运维“威胁论”也随之袭来，如何去做更智能的活，当下很多运维人在不断思考和探寻答案。在2017云栖社区运维/DevOps在线技术峰会上，阿里云专家云登就为大家分享了云计算网络基础架构的实践和演进，精彩不容错过。

以下内容根据演讲视频以及PPT整理而成。

众所周知，云计算是以计算、存储和网络作为基础的。网络作为云计算的重要基石之一，其架构设计和演进是云计算发展的重要一环，而网络架构涉及可靠性、性能、可扩展性等多方面内容。架构是从理论设计开始的，理论设计和实践碰撞到一起，能否经得住考验，是否能够符合预期呢？厂商所提供的网络设备的高级特性真的是解决问题的银弹么？如何通过经典网络和VPC构建混合云，打通云上和云下呢？阿里云在以往的实践以及与用户的交互碰撞中遇到的问题又是如何解决的呢？本次分享中将与大家一起进行探讨。

本次分享的目录

一、常见的云计算网络架构

二、云计算网络的可靠性和故障定界

三、专有云网络的模块化

四、混合云构建的并网案例

五、云网络架构的演进趋势

下图所展示是一种常见的云计算网络集群架构。传统情况下云计算网络架构会分为三层：接入层、汇聚层和核心层。如下图所示，在接入层下面的两台交换机会进行堆叠，再下面会连接服务器，服务器一般会选择使用两个网卡进行bond之后以双上连的方式连接到2台接入交换机。在接入交换机和汇聚交换机之间也会有多条线路的连接，一般而言会存在二层或者三层的接入。对于带宽收敛比的设计而言，对于千兆集群可以采用1:1无收敛的方式，而对于万兆集群则可以使用收敛比为1:3或者1:2的方案，也可能使用无收敛的设计。从汇聚层再向上连接到核心层，一般情况会使用三层连接。

下图是另外一种比较常见的云计算网络集群架构，在Spine节点和Leaf节点之间可能会存在三层连接，而Spine节点和Core节点之间也可能会存在三层连接，这种网络架构相比于前面提到的架构而言，其扩展粒度要更细，可以细化到一组或者多组进行接入。

想必大家对于Overlay以及Underlay网络都有所了解，物理网络被称为Underlay网络，物理网络搭建完成之后应该尽量保证网络拓扑是固定的；而对于Overlay的网络而言，可以基于VXLAN技术构建VPC网络，通过软件定义和控制器的方式可以动态地构建虚拟的网络。所构建的网络可以是一个或多个虚拟的网络，可以通过云上不同的租户去定义地址规划以及路由的规划，甚至还可以提供类似于高速通道这样跨VPC之间的互通。Underlay网络的设计基本上就是前面所提到的接入-汇聚-核心架构以及Spine-Leaf架构，而对于Overlay的网络则描述的是虚拟的层面，提供的实际上是虚拟的路由器和虚拟的交换机，包括其构建出来的可以接入像SLB、RDS、ECS、OCS等云产品的VPC容器。为什么叫做Overlay呢？其实因为Overlay网络是通过VXLAN隧道的封装运行在Underlay物理网络之上的。通过Overlay逻辑网关去组织业务进行资源编排就可以构建出非常丰富的基于Overlay网络的产品。

前面主要介绍了云计算网络的一些基础概念，接下来将会针对云计算网络的可靠性以及故障定位的方式进行分享。

对于云计算平台的物理网络而言，其可靠性可以分为以下的几类：

多线路，常见二层的LACP，也就是链路聚合，对于三层则使用等价路由。设备HA，从体系结构来讲，分布式的多框、多插槽的设备能够提供多主控、多接口板这样的方式，还可以提供类似于堆叠技术和多机之间的双机热备以及多机的备份或者多机堆叠的方式，还可以提供VRRP的链路切换。探测和切换机制，实际上在网络配置交付之后，如果远端出现了问题，为了解决链路上的负载均衡以及主备切换的问题，可以引入比如NQA+Track这样的探测技术，这样可以针对静态路由的配置通过不同的优先级和NQA探测方式发现远端节点不可达的时候进行路由切换。除此之外，在探索到某台设备出现故障的时候就可以进行故障隔离，可以实现端口级或者设备级的故障隔离，保证流量可以走备份或者冗余链路进而避免流量中断，当然，这种情况下可能对于流量带宽造成一定的损失。巡检和监测，针对于Overlay和Underlay的网络会提供主动探测的机制，还有对于设备的日常日志告警的分析。设备在运行中往往会报很多的日志和告警，将这些信息收集起来之后结合云平台的业务流量可以挖掘出很多故障的可能性、已经出现的故障还有对于未来可能出现故障的预判。还可以进行流量分析，并且基于此判断云平台的网络是否出现了一些问题。

如下图所示的是常见的网络集群故障点分布图，云计算平台的网络故障点主要集中在下图中标号的几个位置：

标号1：线路故障，比如服务器上连到TOR交换机，也就是服务器上的接入网卡接入到交换机上时出现了网卡、线路或者是接入端口损坏导致线路上出现故障。同样的，从接入层到汇聚层，从汇聚层到核心层也会出现这样的线路故障。标号2：核心设备的故障，核心设备的故障可能导致跨网络端口之间的流量损失，由此造成的影响范围往往比较大。对图中所示的网络架构而言，如果流量需要跨端口进行传输，就一定需要从接入层到汇聚层再到核心层再转入另外一个POD的汇聚层。标号3：汇聚交换机的故障，一般情况下汇聚交换机采用堆叠的方式，可能会出现堆叠的分裂以及单台设备的故障，也可能出现整个端口流量上行的带宽减半或者是分裂以后导致等一些不可预期的后果，因此需要及时检测出一些故障并且及时进行隔离以及对于设备进行下线维修从而排除此类故障。标号4：接入交换机的故障，接入交换机也会发生类似于汇聚交换机的故障，堆叠分裂或者单机故障则会导致下面连接的服务器出现问题。标号5：服务器故障。标号6和7：像上述提到的堆叠出现问题造成的故障，这样的故障需要通过日常的巡检以及网络设备自身报告故障的日志告警来发现问题并及时去进行相应的处理。

以下是对于常见的网络集群故障点的详细描述：

线路故障。体现为带宽的损失，一般通过多条线路保障，三层网络设备间通常用ECMP等价路由，二层网络设备间通常采用聚合LACP，提高可靠性。在实际情况下，在公有云环境中会发现：一旦网络集群规模大了之后，堆叠出现问题的概率就会变大，与此同时，二层的广播风暴和环路出现的概率也会变大，阿里云目前在逐步地考虑去掉堆叠并且去掉二层，这也可能是未来的发展方向。这样的目的是为了简化网络并提高网络集群的可靠性。DSW故障。DSW是对于核心设备的称呼，由于所有的DSW之间不直接互联，它本身的可靠性只能依靠硬件框式分布式，多主控板（主备HA）、多接口板（上面说的多线路跨板连接）来保证单点可靠性，使用多台DSW，平时负载均衡，单台故障时互为备份链路。如果是单台DSW故障，将会影响带宽损失。PSW故障。也就是汇聚设备的故障，拓扑中有PSW堆叠和去堆叠两种情况，如果是堆叠的，单台故障，上下连线依靠跨堆叠设备的LACP或者ECMP实现业务不中断（但带宽有损失），如果不是堆叠的，参考（2）的场景。如果是单台PSW故障，影响的是下连的多组ASW带宽损失一半。ASW故障。线上很多的ASW都是堆叠的，目前阿里云也开始去堆叠，如果是堆叠的，ASW下连服务器，服务器双网卡bond接入（LACP），如果是去堆叠的ASW，服务器双网卡等价路由负载均衡。如果单台ASW故障，影响的是下连的48台服务器的带宽损失一半。未来，阿里云新构建的集群会逐渐减少对于堆叠的使用，进而提高网络设备的可靠性。其实对于网络厂商而言，他们也会对于堆叠特性进行大量的测试，但是实际上由于堆叠特性十分复杂，因为其涉及到硬件、软件、内部检测以及协议的传输备份，也就是会涉及到很多跨框、跨设备的同步以及选举机制。由于堆叠特性实现本身就非常复杂，就会导致出现问题的可能性比像路由转发这样其他简单特性更高。而在云计算场景下海量的网络设备同时运行，就进一步提升了堆叠特性出现问题的可能性，基本上就会导致出现存在堆叠的场景下可能经常会出现问题。为了解决这样的问题就需要逐步地去除堆叠和二层。服务器故障。可能体现在服务器网卡或者本身内部的应用系统的问题，服务器故障一般只会影响自己，范围比较小。PSW堆叠分裂。各自认为自己是主设备，为了减小影响，一般会配置DAD双主检测，禁掉一边，影响为整个pod的上联带宽和跨asw之间转发带宽损失一半。如果PSW堆叠整体故障，整个pod挂掉（各组ASW下的48台服务器之间仍可互通），上连不通，跨asw的互连不通。ASW堆叠分裂。类似于（6），影响为一组ASW下挂的48台服务器的互联或者上联带宽损失一半。如果ASW堆叠整体故障，该组ASW下连的48台服务器全部不通。对于（6）（7）的堆叠故障，由于厂商堆叠技术本身复杂，导致故障概率提升，再加上公共云使用的网络设备规模大，基数上去了就进一步放大出故障的概率，且影响范围大。因此网络本身的可靠性和故障位置，对于云产品来说影响的范围也是不同的，ecs之类的云产品能够打散到不同的ASW、POD甚至AZ（跨网络集群），其可靠性指标也是不同的。基本上是打散的网络设备之间的层级越高，可靠性保证越高，但同样的网络延迟也越高。

那么怎样才能够及早地发现这些故障呢？其实可以使用故障主动探测的模型。在网络集群里面，可能会选择特定的接入设备比如像服务器，将其作为主动探测的机器，其探测的目标就是网络设备下面的其他服务器。

建立的第一个简单故障主动探测的模型如下：

一个TOR下面所有物理服务器（例如48台）都同时出现大量丢包-->TOR交换机故障。个别物理服务器出现丢包-->服务器负载问题/TOR交换机端口队列打满。到某个机房的大量物理服务器同时出现大量丢包-->汇聚交换机/核心交换机故障。到某个机房的大量物理服务器出现少量概率丢包->汇聚交换机/核心交换机的个别端口问题。每个机房最少只需要1台机器作为探测源，部署对业务网络影响小，ICMPping之类的只能做Layer3的探测。

依照上述的故障主动探测模型就可以简单地判断网络出现故障的范围。

建立的第二个简单故障主动探测的模型如下：

通过选择不同位置的服务器作为探测源或者探测目标，发现不同层次的故障位置，多轮次组合。要求每台服务器运行agent，并接受外部控制器指令，动态调整探测策略，可建立TCP连接并测试。可以针对overlay和underlay网络进行探测，更容易模拟实际应用的业务流量特征，支持Layer4探测、时延计算。

第二个故障主动探测模型在服务器内部会增加一些代理Agent，安装代理之后可以做到对于4到7层的探测，可以探测出TCP连接的情况以及其延迟和性能速率。同样的，探测模型也可以组合出不同的探测方式，在了解网络架构的拓扑之后就可以探测位于同一组接入交换机下面的两台或者多台服务器，也可以探测位于不同的核心交换机或者汇聚交换机下面的多台服务器。通过这种建模方式就可以知道当前延迟高或者丢包的场景下，网络的问题到底出现在什么位置。

上述提到的是网络体现在本身体系结构上的可靠性，比如分布式设备、支持主备HA、支持双机热备或者多机堆叠以及其他一些高级特性，这些都是从网络设备本身的角度而言的。除此之外，通过线路带宽的设计保证收敛比以及负载均衡，以此来保证云计算网络的可靠性。而通过日常的巡检和探测能够及时地发现故障，并在故障发生之后及时了解故障发生的具体原因并提供故障定位的方式，进而提高云平台网络的可靠性。

上述这些都是在公有云网络上的实践，对于专有云而言，又会存在什么样的差别呢？其实对于专有云而言，更多地会对其进行模块化的设计。公有云一般而言是可规划的，可以对于未来集群的规模、建设的地域以及网络架构的选择等进行规划。而对于专有云而言，客户的需求往往不能够规划出来，不同的客户所需要的业务的场景和诉求往往是不同的，这些在网络设备的选型、已有设备的利旧使用以及对于云平台功能的裁剪上都会有所体现，所以专有云与公有云上的的网络设计就存在较大的差别。

下图是专有云网络架构图，一个很明显的特点就是专有云网络会分成几个区域，最上面的是外部接入区，外部接入区包含了阿里云和ISP或者用户骨干网出口的链接以及在其上进行安全防护的云盾。专有云网络架构图中间的DSW和下部的PSW则属于DC区，也就是网络架构的核心区域。图中右面的综合接入区分为了两个部分，一部分是阿里云所提供的负载均衡、VPC网关以及OPS相关的接入，另外一部分则是CSW，实际上就是客户的VPC专线接入区，阿里云的专有云客户会有一些原来的物理网络需要与云上的VPC进行网络打通，一般会通过VPC的专线接入交换机的综合交换机接入进来。也就是说专有云网络的每一个模块都有一个相对独立的设计，所有的模�...

云计算是一种能够通过网络以便利的、按需付费的方式获取IT资源（包括网络、服务器（虚机、容器）、存储、平台、应用和服务等）并提高其可用性的模式，这些资源来自一个共享的、可配置的资源池，并能够以最省力和无人干预的方式获取和释放。

云计算：第三次IT革命

云计算发展背景

云计算特征

云计算服务类型：IaaS、PaaS、SaaS

SaaS是一种新型软件发布模式，应用软件安装在 厂商或者服务供应商那里，用户通过网络使用。Salesforce、NetSuite、Google Apps、微软Office365是典型案例。

软件开发者可以在PaaS之上直接开发新的应用，不需要购买和部署服务器和OS、数据库和中间件软件而直接部署代码即可运行客户自己的应用。Salesforce的Force、Google AppEngine和微软 Azure都是PaaS模式的典型代表。

IaaS（Infrastructure as a Service，基础架构即服务）通过互联网提供数据中心、基础架构硬件和软件资源。典型IaaS的代表产品是亚马逊的AWS（Elastic Compute Cloud）、Google的CloudEngine。

云计算部署模式

公有云：关注性价比

面向公众/政企提供的云服务，基于互联网获取和使用服务、关注盈利模式、具有强大的可扩展性和较好的规模共享经济性等。

私有云：关注信息安全

面向内部用户、通过内部或专有网络获得和使用服务，私有云的使用体验较好，安全性较高，但投资门槛高，当出现突发性需求时，私有云因规模有限，将难以快速地有效扩展。

混合云：兼顾性价比与安全

在公有云中创建网络隔离的专有云，用户可以完全控制该专有云的网络配置，同时还可以通过VPN/专线连接到内部私有云，实现公有云与私有云的连接，兼顾公有云和私有云的优点。

社区云：过渡性模式

面向一个行业（行业云）或一个地理区域范围内（园区云）提供服务，阶段性发展的产物。