数据库云主要指基于云平台构建的结构化、半结构化的数据库处理系统。数据库可以基于虚拟化平台，也可以基于物理平台直接构建。

数据库加速：为了取得更好的数据库性能，会在硬件层、弹性存储层做垂直层面的深入调优。

数据库加固：为了保证数据库数据不丢失、不损坏，会在中间件服务层增加数据库的备份、恢复、容灾、定期校验等服务，提高数据可用性。

释放价值，分享知识和经验，解读IT前沿和技术。帮助他人，提升自己。更多交流请关注itboxes（IT智囊）。

【IT168 SACC专场报道】2017年10月19日-21日，一年一度的中国系统架构师大会(SACC)再度盛装来袭。作为国内最负盛名的架构师盛会，SACC 2017云集了百余位国内外的顶级专家。下图为SACC 2017专场十一《云平台架构进化之路(下)》，来自瓜子云，搜狗云、360 云安全、Datalex等技术大牛演讲嘉宾金句分享：

▲更多精彩请点击：http://sacc.it168/topic2017/

【IT168 云计算】2017年10月19日-21日，一年一度的中国系统架构师大会(SACC)再度盛装来袭。在SACC 2017专场一云平台架构进化之路(上)，来自AWS、去哪儿网、小米生态云、阿里巴巴、滴滴出行的专家分享。

▲

从传统的烟囱式模型到云化架构，经历了底层硬件设备X86化、虚拟化，再到资源整合，调配管理等，实现底层资源的快速调配能力以及资源生态环境绿色发展；

通过云计算技术，实现资源分配的高弹性高扩展性。满足互联网时代业务对技术架构的高并发、快速响应、高可靠、海量存储等要求。

从上图可以看出，云化架构需要进一步加强上层软件平台的建设发展，主要为了实现业务服务接入的标准化，调度服务标准化以及服务共享。因此需要进一步平台化建设，即PaaS平台建设；

将各系统逐步进行改造形成应用+平台，标准化的、集成化、开放化的技术、数据、业务能力平台，提高应用系统的专业化、组件化程度，提高建设效率。统一规划、管理各类数据，加强大数据分析、挖掘等数据服务能力建设，推进数据变现。

PaaS平台功能架构如下所示：

在PaaS平台为了实现开放、其他业务能力接入的能力，将平台分层为DCOS平台、基础技术服务平台、业务服务平台以及整体运营&运维平台；

其中DCOS平台是为了实现与IaaS层设备的联动以及管理资源动态伸缩；

基础技术服务平台包括技术上暂时无法实现统一能力管理（性能等），或者统一能力管理使得用户无法充分个性化定制（优化）软件。

基础技术组件主要包括如下：

1、关系型数据库：MySQL，MariaDB，PostgreSQL

2、消息队列服务：Kafka，RabbitMQ，ActiveMQ

3、缓存服务：Redis，Memcached

4、Web和应用服务器：Tomcat，Nginx，Apache， Weblogic、WebSphere

5、非关系型数据库：Cassandra，MongoDB

6、搜索引擎：Elasticsearch，Slor

7、其他：Drone，Jenkins等

业务服务平台主要用来实现原子服务能力，通过原子服务的解耦通过编排重新组合提供对外服务能力，实现业务系统的云化架构。

在企业云计算平台（以下简称云平台）的建设过程中，IaaS平台(基础设施即服务，Infrastructure as a Service)是IaaS和Paas建设的前提和基础，其规划设计和具体实施是至关重要的。

那么，当企业进行IaaS平台建设时，如何去有效评估既有的IT基础设施架构？基于实际评估结果，如何设定IaaS平台建设的各个渐进阶段？对这些渐进阶段又如何去进行客观评估？这些问题，企业用户和相关的云计算服务提供商必须面对并作出契合实际的准确回答。

IaaS平台规划：务实和细节

目前，云计算的主流公司都有各自的云平台参考模型，这些模型的底层原理和相关组件大同小异，对云平台的框架性结构进行了规划和定义。研究这些参考模型，对理解云平台的各组件固然是大有裨益的，但是，在企业的云平台建设中，需要解决的关键问题不仅仅是整体结构的规划和定义，更为重要和现实的问题是进行具体而微的细节设计。

作为云平台基础的IaaS平台建设，其路线图规划绝不是大而化之的务虚工作，而是建立在全面掌握实际情况基础上的核心设计工作，可以说“处处需务实、步步要落实”。这些工作包括：对现有IT基础设施的“云化”程度进行评估，在此基础上，对构建IaaS平台所需的具体模块进行技术细节规划，进而设定建设相应模块的先后次序，最终，完成具备完善云计算服务能力的IaaS平台。

Iaas平台成熟度模型和CCRA

在业界具有相当知名度的Iaas平台成熟度模型和CCRA（Cloud Computing Reference Architecture，云计算参考框架），是建立在云计算领域的实际服务经验之上的云平台建设标准。这些经验包括：为企业用户提供云计算平台咨询服务、主导云平台规划设计工作、主持云平台的具体技术实施工作。正因为来源于实践，IaaS平台成熟度模型和CCRA才具有极其重要的现实意义，才能被被广泛地应用于IaaS平台构建的实践活动中。

事实上，业界公认，IaaS平台成熟度模型是衡量企业IaaS建设水平的标尺，而CCRA则定义了用于具体实现IaaS平台的Adoption Pattern（即“采用模式”，可理解为用于具体实现的架构、模式和方法。实际上，CCRA还定义了PaaS平台和SaaS平台等其他5类Adoption Pattern，但本文只讨论IaaS平台相关内容），是对企业IaaS整体架构进行设计时的基础框架，是规划IaaS建设路线图时所依据的纲领，而且，从服务的角度看，也是IaaS平台建成后能为企业提供的一个整体服务目录。

下面两图是IaaS平台成熟度模型的5个等级与CCRA IaaS平台采用模式的6个渐进建设阶段之间的对应关系。为了方便读者阅读，提供了两个版本的图，第一个图适用于在手机等移动终端查看，第二个图适合于在PC端查看。

上图中，右边是CCRA IaaS采用模式的6个渐进式建设阶段，是IaaS的规划设计，是基础架构；左边是IaaS平台成熟度模型所有5个级别的成熟度，是对规划设计的成熟度评估，是技术标尺。

在纵向层次，从下往上的方向上，云计算能力在不断增长，右边的6个渐进式建设阶段是企业建设IaaS平台的必由历程，从低级阶段向高级阶段进化，而左边的IaaS成熟度模型则用于衡量企业IaaS建设的成熟度，也是从底层次逐渐往高层次演进；

在两者相互对应的层次关系上：

（1）在大体层次上，CCRA IaaS采用模式0～4级的建设阶段对应于IaaS成熟度模型1～4级的成熟度。也就是说，对CCRA IaaS采用模式0～4级的建设阶段，如果以IaaS成熟度模型去衡量，成熟度在1～4级别之间（具体的IaaS平台的单个建设阶段所对应的成熟度，如图中所示）。在纵向上，这两者都属于企业内部的云化数据中心的建设范畴。

（2）CCRA IaaS采用模式第5级的建设阶段对应于IaaS成熟度模型第5级成熟度。也就是说，对CCRA IaaS采用模式第5级的建设阶段，如果以IaaS成熟度模型去衡量，成熟度为第5级。在纵向上，这两者都已经超越了企业内部云化数据中心的范畴，站在了云服务提供商的高度。

实践证明，基于这两个重要的标尺和框架，逐步地、分阶段地推进IaaS平台的建设是扎实的、可行的，其渐进式建设过程是目标明确的，也是和缓的，这使得企业的IT基础设施在极低的风险下得以平稳提升至IaaS平台水平。

砌墙与Iaas平台建设的类比

其实，这两项标准和框架的配合，正如手工砌墙的过程。在砌墙之前，设计人员要先到实地勘测，根据以往的墙体设计经验（相当于CCRA的Adoption Pattern），结合实际勘测所得情况，进行墙体的各项规格参数设计，完成设计图纸后，工人再按图纸去砌墙。在砌墙的过程中，要用拉水平线和放置铅直线等方式保证质量，还要用建筑业的各项既定标准去衡量墙的质量（相当于用Iaas平台成熟度模型去衡量企业的IaaS建设水平），一旦出现问题就及时修正和整改，就这样，“一边砌墙，一边衡量”，直到墙体完工并通过验收。

如上所述，IaaS平台的建设对应于砌墙，IaaS平台成熟度模型相当于水平线、铅直线和各项建筑业标准，CCRA的IaaS Adoption Pattern类似于由以往所积累的墙体设计经验而形成的通用设计模式和方法，而具体的企业IaaS规划设计则类比于墙的各项具体规格参数和设计图纸。

具体来说，就是在构建云平台的时候，结合企业的实际情况，将Iaas平台成熟度模型用于衡量IaaS现状和具体建设成效，将CCRA的IaaS Adoption Pattern用于具体的IaaS平台框架设计和阶段性建设目标的设定。也就是说，在企业进行云平台建设时，先采用Iaas平台成熟度模型去衡量企业的IT基础设施现状，基于具体的衡量和评估结果，依据CCRA的IaaS Adoption Pattern所对应的IaaS平台基础框架，规划企业的IaaS平台建设路线图。此后，当IaaS建设推进到一定阶段时，再用Iaas平台成熟度模型去衡量建设的具体成效，根据客观的衡量和评估结果，进行总结和归纳，并依据CCRA对下一阶段的建设内容和目标进行修正。随后，继续推行IaaS建设，同样遵循上述过程，如此循环往复，直到IaaS平台实现了预先规划的建设目标，当然，用于作出这一判断的技术标尺也正是Iaas平台成熟度模型。

至此，本文对Iaas平台成熟度模型和CCRA的基础知识进行了简要的介绍。企业IaaS平台的规划设计人员必须在思想上充分地认识到，正确理解并熟练运用IaaS平台建设的技术标尺和基础框架，就可以成功地分析企业的IT基础设施建设现状，进而有效地为企业构建出务实的IaaS平台。

《企业云计算IaaS平台的技术标尺和基础框架》系列文章的下一篇，将重点对Iaas平台成熟度模型和CCRA的各层次内容分别进行较为详尽的分析和梳理。

在互联网的时代，企业面临业务的不确定性和可能的爆发性IT需求。而当您考虑部署云平台时，很可能您的企业已经有传统技术为主的IT环境，云平台只是作为一个独立的环境来使用和支撑部分新业务，甚至我们所知的部分企业基于使用的云操作系统产品不同，分别部署了不同的云环境，来支持不同的业务。这样就形成了企业内以产品技术为区别的不同的资源环境和孤岛。

我们建议基于业务系统的特性，如：敏态，稳态，来采用不同的核心技术来进行支撑，并采用统一的云管理平台来进行不同资源池，IT环境的统一调度和管理，来简化管理，提升IT的敏捷性，如下图所示：

主流的云管理平台可以采用无侵入技术来管理物理机为主的传统IT环境和异构虚拟化，公有云环境，并提供统一的可视化的控制界面，面对不同角色的用户提供不同的敏捷管理和服务，如下图所示：架构师可以跨资源池，进行服务的编排和设计，把编排好的资源组合变成服务目录，发布给用户。IT用户可以通过自服务门户查看IT服务目录，进行自服务。IT管理员可以通过管理控制台进行可视化、自动化、智能化的运维管理和计量、计费。

此外，自服务门户可以定制服务目录，资源配额和审批工作流，便于DevOps团队快速获取个性化的自助服务。利用云管理平台的RET API，IT可以与ITIL服务管理系统进行集成，并赋能快速的DevOps和服务编排。

在云管理平台上，所有这些对于不同IT环境的服务管理需进行自动化和优化。包括：

内置的工作流自动化为资源生命周期管理提供基于策略的控制基于应用的关键特性，如：用户，合规，性能压力来智能化、自动化部署。传统环境和云环境租户资源使用的计量和计费资源和成本优化，提供云之间进行成本对比的能力。

云管理平台使企业避免被单一技术和产品锁定，允许企业采用最优的云技术组合来构建同时支持稳态和敏态的IT环境。主流的云管理平台，如RightCLoud支持物理机，IBM Power，Vwmare，Openstack和阿里云，腾讯云，华为云，AWS等主流的云技术，企业可以把现有的IT环境与多源云环境进行融合。

云管理平台的集成模块，可与企业现有的ITIL服务流程系统，配置管工具等进行无缝集成。

在当今世界的DevOps自动化，追求敏捷的企业需要的不仅仅是虚拟机部署。企业IT需要为提供更具价值的应用程序和PaaS服务。主流的云管理平台，具有服务目录的设计编排能力和业务流程引擎，如RIghtCloud可以提供完整的应用程序和多层次的PaaS服务。

我们知道云计算主要有三种服务模式，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的参与者越来越多，生态越来越完善，应用项目也会越来越多。

更多深度文章，请关注云计算频道：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/专线连接到内部私有云，实现公有云与私有云的连接，兼顾公有云和私有云的优点。

社区云：过渡性模式

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