第2章 云计算的架构内涵与关键技术

2.1 云计算的总体架构

从上述分析不难看出，云计算推动了IT领域自20世纪50年代以来的三次变革浪潮，对各行各业数据中心基础设施的架构演进及上层应用与中间件层软件的运营管理模式产生了深远的影响。在云计算发展早期，Google、Amazon、Facebook等互联网巨头们在其超大规模Web搜索、电子商务及社交等创新应用的牵引下，率先提炼出了云计算的技术和商业架构理念，并树立了云计算参考架构的标杆与典范，但那个时期，多数行业与企业IT的数据中心仍然采用传统的以硬件资源为中心的架构，即便是已进行了部分云化的探索，也多为新建的孤岛式虚拟化资源池（如基于VMware的服务器资源整合），或者仅仅对原有软件系统的服务器进行虚拟化整合改造。随着近两年云计算技术与架构在各行各业信息化建设中和数据中心的演进变革，以及更加广泛和全面地落地部署与应用，企业数据中心IT架构正在面临一场前所未有的，以“基础设施软件定义与管理自动化”、“数据智能化与价值转换”以及“应用架构开源化及分布式无状态化”为特征的转化。

从架构视角来看，云计算正在推动全球IT的格局进入新一轮 “分久必合、合久必分”的历史演进周期，我们通过分离回归融合的过程从三个层面进行表述，如图2-1所示。

1．基础设施资源层融合

面向企业IT基础设施运维者的数据中心计算、存储、网络资源层，不再体现为彼此独立和割裂的服务器、网络、存储设备，以及小规模的虚拟化资源池，而是通过引入云操作系统，在数据中心将多个虚拟化集群资源池统一整合为规格更大的逻辑资源池，甚至进一步将地理上分散、但相互间通过MPLS/VPN专线或公网连接的多个数据中心以及多个异构云中的基础设施资源整合为统一的逻辑资源池，并对外抽象为标准化、面向外部租户（公有云）和内部租户（私有云）的基础设施服务，租户仅需制定其在软件定义的API参数中所需资源的数量、SLA/QoS及安全隔离需求，即可从底层基础设施服务中以全自动模式弹性、按需、敏捷地获取到上层应用所需的资源配备。

2．数据层融合

面向企业日常业务经营管理者的数据信息资产层，不再体现为散落在各个企业、消费者IT应用中，如多个看似关联不大的结构化事务处理记录（关系型数据库）数据孤岛，非结构化的文档、媒体以及日志数据信息片段，而是通过引入大数据引擎，将这些结构化与非结构化的信息进行统一汇总，汇聚存储和处理，基于多维度的挖掘分析与深度学习，从中迭代训练出对业务发展优化及客户满意度提升有关键价值的信息，从而将经营管理决策从纯粹依赖人员经验积累转变到更多依赖基于大数据信息内部蕴藏的智慧信息，来支撑更科学、更敏捷的商业决策。除大数据之外，数据层融合的另一个驱动力，来自于传统商业数据库在处理高并发在线处理及后分析处理扩展性方面所遭遇的不可逾越的架构与成本的瓶颈，从而驱动传统商业闭源数据库逐步被Scale Out架构的数据库分表分库及水平扩展的开源数据库所替代。

3．应用平台层融合

面向企业IT业务开发者和供应者的应用平台层，在传统IT架构下，随具体业务应用领域的不同，呈现出条块化分割、各自为战的情况，各应用系统底层的基础中间件能力，以及可重用的业务中间件能力，尽管有众多可共享重用的机会点，但重复建设的情况非常普遍（比如ERP系统和SCM系统都涉及库存管理），开发投入浪费相当严重。各业务应用领域之间由于具体技术实现平台选择的不同，也无法做到通畅的信息交互与集成；而企业IT应用开发本身，也面临着在传统瀑布式软件开发模型下开发流程笨重、测试验证上线周期长、客户需求响应慢等痛点。于是，人们开始积极探索基于云应用开发平台来实现跨应用领域基础公共开发平台与中间件能力去重整合，节省重复投入，同时通过在云开发平台中集成透明的开源中间件来替代封闭的商业中间件平台套件，特别通过引入面向云原生应用的容器化应用安装、监控、弹性伸缩及生命周期版本灰度升级管理的持续集成与部署流水线，来推动企业应用从面向高复杂度、厚重应用服务的瀑布式开发模式，逐步向基于分布式、轻量化微服务的敏捷迭代、持续集成的开发模式演进。以往复杂、费时的应用部署与配置，乃至自动化测试脚本，如今都可以按需地与应用软件打包，并可以将这些动作从生产环境的上线部署阶段，前移到持续开发集成与测试阶段。应用部署与环境依赖可以被固化在一起，在后续各阶段以及多个数据中心及应用上下文均可以批量复制，从而将企业应用的开发周期从数月降低数周，大大提升了企业应用相应客户需求的敏捷度。

综上所述，企业IT架构云计算演进中上述三个层次的融合演进，最终目的只有一个，那就是通过推动企业IT走向极致的敏捷化、智能化以及投入产出比的最优化，使得企业IT可以更好地支撑企业核心业务，进而带来企业业务敏捷性、核心生产力与竞争力的大幅提升，以更加从容地应对来自竞争对手的挑战，更轻松地应对客户需求的快速多变。

那么，云计算新发展阶段具体的架构形态究竟是怎样的呢？是否存在一个对于所有垂直行业的企业数据中心基础设施云化演进，以及无论对于公有云、私有云及混合云场景都普遍适用的一个标准化云平台架构呢？

答案无疑是肯定的。

尽管从外在表象上来看，私有云与公有云在商业模式、运营管理集成存在显著差别，然而从技术架构视角来看，我们宏观上不妨可将云计算整体架构划分为云运营（Cloud BSS）、云运维（Cloud OSS）以及云平台系统（IaaS/PaaS/SaaS）三大子系统，这三大子系统相互间毫无疑问是完全SOA解耦的关系，云平台和云运营支撑子系统很明显是可以实现在公有云和私有云场景下完全重用的，仅云运营子系统（Cloud BSS）部分，对于公有云和私有云/混合云存在一定差异。因此，我只需要将这部分进一步细分解耦打开，即可看到公有云、私有云可以共享的部分，如：基础计量计费，IAM认证鉴权，私有云所特有的ITIL流程对接与审批、多层级租户资源配额管理等，以及公有云所特有的批价、套餐促销和在线动态注册等。

由此我们可以看到，无论是公有云、私有云，还是混合云，其核心实质是完全相同的，都是在基础设施层、数据层，以及应用平台层上，将分散的、独立的多个信息资产孤岛，依托相应层次的分布式软件实现逻辑上的统一整合，然后再基于此资源池，以Web Portal或者API为界面，向外部云租户或者内部云租户提供按需分配与释放的基础设施层、数据层以及应用平台服务，云租户可以通过Web Portal或者API界面给出其从业务应用的需求视角出发，向云计算平台提出自动化、动态、按需的服务能力消费需求，并得以满足。

综上所述，一套统一的云计算架构完全可以同时覆盖于公有云、私有云、混合云等所有典型应用场景。

2.1.1 云计算架构上下文

云计算架构应用上下文的相关角色包括：云租户/服务消费者、云应用开发者、云服务运营者/提供者、云设备提供者（见图2-2）。

一、云租户/云服务消费者

云租户是指这样一类组织、个人或IT系统，该组织/个人/IT系统消费由云计算平台提供的业务服务（比如请求使用云资源配额，改变指配给虚拟机的CPU处理能力，增加Web网站的并发处理能力等）组成。该云租户/云业务消费者可能会因其与云业务的交互而被计费。

云租户也可被看做是一个云租户/业务消费者组织的授权代表。比如说一个企业使用到了云计算业务，该企业整体上相对云业务运营及提供者来说是业务消费者，但在该业务消费者内可能存在更多的细化角色，比如使得业务消费得以实施的技术人员，以及关注云业务消费财务方面的商务人员等。当然，在更为简化的公有云场景下，这些云业务消费者的角色关系将简化归并到一个角色。

云租户/业务消费者在自助Portal上浏览云服务货架上的服务目录，进行业务的初始化以及管理相关操作。

就多数云服务消费者而言，除从云服务提供者那里获取到的IT能力之外，也同时继续拥有其传统（非云计算模式）IT设施，这使得云服务与其内部既有的IT基础设施进行集成整合至关重要，因此特别需要在混合云的场景下引入云服务集成工具，以便实现既有IT设施与云服务之间的无缝集成、能力调用以及兼容互通。

二、云应用开发者

云应用开发者负责开发和创建一个云计算增值业务应用，该增值业务应用可以托管在云平台运营管理者环境内运行，或者由云租户（服务消费者）来运行。典型场景下云应用开发者依托于云平台的API能力进行增值业务的开发，但也可能会调用由BSS和OSS系统负责开放的云管理API能力（云应用开发者当然也可能选择独立构建其独立于云平台的增值业务应用系统的BSS/OSS系统，而不调用或重用底层的云管理API）。

云业务开发者全程负责云增值业务的设计、部署并维护运行时主体功能及其相关的管理功能。如同云租户/云业务消费者以及云业务运营提供者一样，云业务开发者也可以是一个组织或者个人，比如一个开发云业务的ISV开发商是一个云业务开发者，其内部可能包含了上百个担任不同细分技术或商业角色的雇员。另外，负责云业务管理的运维管理人员与负责开发云业务的开发组织紧密集成也是一种常见的角色组织模式（比如Google、Amazon、百度等自营加自研的互联网DevOps服务商），这是提升云业务发放和上线效率的一种行之有效的措施，因为此类角色合一的模式提供了更短的问题反馈路径，使得云业务的运营效率有了进一步实质性提升。

目前云计算业务开发者在公有云及私有云领域的典型应用包括：运营商虚拟主机出租与托管云、企业内部IT私有云或专有云、桌面私有云、运营商桌面云服务、企业网络存储与备份云、视频媒体处理云、IDC Web托管及CDN云以及大数据分析云等。

三、云服务运营者/提供者

云服务运营者/提供者承担着向云租户/服务消费者提供云服务的角色，云服务运营者/提供者概念的定义来源于其对OSS/BSS管理子系统拥有直接的或者虚拟的运营权。同时作为云服务运营者以及云服务消费者的个体，也可以成为其他对外转售云服务提供者的合作伙伴，消费其云服务，并在此基础上加入增值，并将增值后的云服务对外提供。当然，云服务运营者组织内部不排除有云业务开发者的可能性，这两类决策既可在同一组织内共存，也可相对独立进行。

四、云设备/物理基础设施提供者

云设备提供者提供各种物理设备，包括服务器、存储设备、网络设备、一体机设备，利用各种虚拟化平台，构筑成各种形式的云服务平台。这些云服务平台可能是某个地点的超大规模数据中心，也可能是由地理位置分布的区域数据中心组成的分布式云数据中心。

云设备提供者可能是云服务运营者/提供者，也可能就是一个纯粹的云设备提供者，他将云设备租用给云服务运营者/提供者。

在这里我们特别强调云设备/物理基础设施的提供者必须能够做到不与唯一的硬件设备厂家绑定，即在云计算系统平台南向接口上所谓的多厂家硬件的异构能力。

五、接口说明

从上述云计算的基础上下文描述，我们不难看出云平台和云运营与运维管理系统是介于上层多租户的IT应用、传统数据中心管理软件，以及下层数据中心物理基础设施层之间的一层软件。其中云平台可进一步被分解为面向基础设施整合的云操作系统，面向数据整合的大数据引擎，以及面向应用中间件整合的应用开放平台。而云运营与运维管理系统在云计算引入的初期，与传统数据中心管理系统是并存关系，最终将逐步取代传统数据中心管理。

云平台的南向接口IF4向下屏蔽底层千差万别的物理基础设施层硬件的厂家差异性。针对应用层软件以及管理软件所提出的基础设施资源、数据处理以及应用中间件服务诉求，云平台系统向上层多租户的云应用与传统数据中心管理软件屏蔽如何提供资源调度、数据分析处理，以及中间件实现的细节，并在北向接口IF1、IF2和IF3为上层软件及特定租户提供归一化、标准化的基础设施服务（IaaS）、数据处理及应用平台服务（PaaS）API服务接口。在云平台面向云运营与管理者（拥有全局云资源操作权限）的IF3接口，除了面向租户的基础设施资源生命周期管理API之外，还包括一些面向物理、虚拟设施资源及云服务软件日常OAM运行健康状态监控的操作运维管理API接口。

其中IF1/IF2/IF3接口中关于云租户感知的云平台服务API的典型形态为Web RESTful接口。IF4接口则为业务应用执行平面的x86指令，以及基础设施硬件特有的、运行在物理主机特定类型OS中的管理Agent，或者基于SSL承载的OS命令行管理连接。IF3接口中的OAM API则往往采用传统IT和电信网管中被广泛采用的Web RESTful、SNMP、CORBA等接口。

2.1.2 云计算的典型技术参考架构

基于上述分析，我们不难得出如下的云计算数据中心架构分层概要（见图2-3）。

一、云平台IT基础设施架构层

自20世纪50年代前第一台电子计算机诞生至今，IT基础设施先后经历了大规模集中式计算的大型机/小型机，到小规模分布式的个人计算PC机和小规模集中化的B/S、C/S客户端服务器架构，再到大规模集中化的云计算，从合并、分离，再重新走向融合。这个阶段的融合，借助虚拟化及分布式云计算调度管理软件，将IT基础设施整合成为一个规模超大的“云计算机”，相当于建成了一座“基础设施电厂”。多个租户可以从这座电厂中随时随地获取到其所需的资源，从而大大提升了业务敏捷度，降低了TCO消耗，甚至提供了更优的业务性能与用户体验。

然而，历史总是在螺旋式前进的，“云计算机”看似大型机，但绝非简单回到了大型机时代。

1．区别1：架构不同，规模扩展能力不同

由“垂直扩展”到“横向扩展”；计算处理能力，存储容量，网络吞吐能力，租户/应用实例数量，均相差n个数量级以上，从硬件成本视角来看，TCO成本也更低。

2．区别2：硬件依赖性不同，生态链、开放性不同

由“硬件定义”到“软件定义”；对于早期的IT系统，少数硬件厂家绑定OS和软件，IT只是少数用户的奢侈品。在新的时代，通过软件屏蔽异构硬件差异性，同一个硬件平台上，可以运行来自多个不同厂家的软件和OS。新时代的IT生态链更加繁荣，IT成为人人消费得起的日用品。

3．区别3：可靠性保障方式不同

由“单机硬件器件级的冗余实现可靠性”发展到“依赖分布式软件和故障处理自动化实现可靠性，甚至支持地理级容灾”。

4．区别4：资源接入方式不同

将IT基础设施能力比作“电力”，大型机只能专线接入，是只能服务于少数人群的 “发电机”，基于企业以太网或者互联网的开放接入，是可以为更多人群提供服务的“发电站”和“配电网”。

基础设施层又可进一步划分为物理资源层、虚拟资源层，以及资源服务与调度层。

1．物理资源层

所有支撑IaaS层的IT基础设施硬件，其中包括服务器、存储（传统RAID架构垂直扩展的Scale Up存储和基于服务器的分布式水平扩展的Scale Out存储），以及数据中心交换机（柜顶、汇聚以及核心交换）、防火墙、VPN网关、路由器等网络安全设备。

2．虚拟资源层

虚拟资源层在云计算架构中处于最为关键与核心的位置。该层次与“资源服务与调度层”一道，通过对来自上层操作系统及应用程序对各类数据中心基础设施在业务执行和数据平面上的资源访问指令进行“截获”。指令和数据被截获后进行“小聚大”的分布式资源聚合处理，以及“大分小”的虚拟化隔离处理，以及必要异构资源适配处理。这种处理可以实现在上层操作系统及应用程序基本无须感知的情况下，将分散在一个或多个数据中心的数据中心基础设施资源进行统一虚拟化与池化。

在某种程度上，虚拟资源层对于上层虚拟机（含操作系统及应用程序）的作用与操作系统对于应用软件的支撑关系是类似的，实质上都是在多道应用作业实例与底层的物理资源设备或者设备集群之间进行时分和空分的调度，从而让每道作业实例都“感觉”到自己是在独占相关资源，而实际上资源在多个作业实例之间的复杂、动态的复用调度机制完全由虚拟资源层屏蔽。技术实现的主要困难与挑战在于，操作系统的管理API是应用程序感知的，而虚拟资源层则必须做到上层操作系统与应用程序的“无感知”，同时如何对于频繁的指令级陷入和仿真调度助力，做到令上层应用及OS可接受的性能开销。

虚拟资源层又包括三个部分，具体如下。

（1）计算虚拟化

所有计算应用（含OS）并非直接承载在硬件平台上，而是在上层软件与裸机硬件之间插入了一层弹性计算资源管理及虚拟化软件：弹性计算资源管理软件对外负责提供弹性计算资源服务管理API，对内负责根据用户请求调度分配具体物理机资源；虚拟化软件（Hypervisor）对来自所有的x86指令进行截获，并在不为上层软件（含OS）所知的多道执行环境并行执行“仿真操作”，使得从每个上层软件实例的视角，仍然是在独占底层的CPU、内存以及I/O资源（见图2-4）；而从虚拟化软件的视角，则是将裸机硬件在多个客户机（VM）之间进行时间和空间维度的穿插共享（时间片调度、页表划、I/O多队列模拟等）。由此可见，计算虚拟化引擎本身是一层介于OS与硬件平台的中间附加软件层，因此将不可避免地带来性能上的损耗。然而随着云计算规模商用阶段的到来，以及计算虚拟化的进一步广泛普及应用，越来越多的计算性能敏感型和事务型的应用逐步被从物理机平台迁移到虚拟化平台之上，因此对进一步降低计算虚拟化层的性能开销提出了更高的要求，典型的增强技术包括以下内容。

虚拟化环境下更高的内存访问效率：应用感知的大内存业务映射技术，通过该技术，可有效提升从虚拟机线性逻辑地址到最终物理地址的映射效率。

虚拟化环境下更高的CPU指令执行效率：通过对机器码指令执行的流程进行优化扫描，通过将相邻执行代码段中的“特权”指令所触发的“VM_Exit”虚拟化仿真操作进行基于等效操作的“合并”，从容达到在短时间内被频繁反复地执行。由于每次VM_Exit上下文进入和退出的过程都需要涉及系统运行队列调度以及运行环境的保存和恢复，即将多次上下文切换合并为一次切换，从而达到提升运行效率的目的。

虚拟化环境下更高的I/O和网络包收发处理效率：由于多个虚拟机在一个物理机内需要共享相同的物理网卡进行网络包收发处理，为有效减少中断处理带来的开销，在网络及I/O发包过程中，通过将小尺寸分组包合并为更大尺寸的分组包，可以减少网络收发接受端的中断次数，从而达到提升虚拟机之间网络吞吐率的目的。

更高的RAS可靠性保障：针对云计算所面临的电信领域网络及业务云化的场景，由于硬件故障被虚拟化层屏蔽了，使得物理硬件的故障无法像在传统物理机运行环境那样直接被传送通知给上层业务软件，从而导致上层业务层无法对故障做出秒级以内的及时响应，比如业务层的倒换控制，从而降低了对整体可靠性水平。如何感知上层的业务要求，快速进行故障检测和故障恢复，保证业务不中断，这给计算虚拟化带来了新的挑战。

（2）存储虚拟化

随着计算虚拟化在各行业数据中心的普遍采用，x86服务器利用效率提升中已获得普遍应用的同时，人们发现存储资源的多厂家异构管理复杂、平均资源利用效率低下，甚至在I/O吞吐性能方面无法有效支撑企业关键事务及分析应用对存储性能提出的挑战，通过对所有来自应用软件层的存储数据面的I/O读写操作指令进行“截获”，建立从业务应用视角覆盖不同厂家、不同版本的异构硬件资源的统一的API接口，进行统一的信息建模，使得上层应用软件可以采用规范一致的、与底层具体硬件内部实现细节解耦的方式访问底层存储资源。

除去带来硬件异构、应用软件与硬件平台解耦的价值之外，通过“存储虚拟化”层内对多个对等的分布式资源节点的聚合，实现该资源的“小聚大”。比如，将多个存储/硬盘整合成为一个容量可无限扩展的超大（EB级规模）的共享存储资源池。由此可以看到，存储虚拟化相对计算虚拟化最大的差别在于：其主要定位是进行资源的“小聚大”，而非“大分小”。原因在于，存储资源的 “大分小”在单机存储以及SAN/NAS独立存储系统，乃至文件系统中通过LUN划分及卷配置已经天然实现了，然而随着企业IT与业务数据的爆炸式增长，需要实现高度扁平化、归一化和连续空间，跨越多个厂家服务器及存储设备的数据中心级统一存储，即“小聚大”。存储“小聚大”的整合正在日益凸显出其不可替代的关键价值（见图2-5）。

高性能分布式存储引擎：伴随着云计算系统支撑的IT系统越来越大，覆盖范围从不同服务器存储节点，到分布在不同地理区域的数据中心，这就需要有一个分布式存储引擎。这个引擎，能满足高带宽、高I/O等各种场景要求，能很好地进行带宽的扩展。

存储异构能力：如何利旧，将不同厂家原有的独立SAN、NAS设备组合成一个大的存储资源池，也是软件定义存储中需要解决的问题。

存储卸载：传统的企业存储系统，在采用各种各样的存储软件，这些软件存储操作对存储I/O和CPU资源均有较大消耗，会影响到用户业务性能的发挥。因此，如何将存储操作标准化，然后将存储操作利用某些标准的硬件动作去代替，这就是存储卸载。

（3）网络虚拟化

站在操作系统角度，OS管理的资源范畴仅仅是一台服务器，而Cloud OS管理的资源范畴扩展到了整个数据中心，甚至将跨越多个由广域网物理或者逻辑专线连接起来数据中心。在一台服务器内，核心CPU、内存计算单元与周边I/O单元的连接一般通过PCI总线以主从控制的方式来完成，多数管理细节被Intel CPU硬件及主板厂家的总线驱动所屏蔽，且PCI I/O设备的数量和种类有限，因此OS软件层面对于I/O设备的管理是比较简单的。相对而言，在一个具备一定规模的数据中心内，甚至多个数据中心内，各计算、存储单元之间以完全点对点的方式进行松耦合的网络互联。云数据中心之上承载的业务种类众多，各业务类型对于不同计算单元（物理机、虚拟机）之间，计算单元与存储单元之间，乃至不同安全层次的计算单元与外部开放互联网网络和内部企业网络之间的安全隔离及防护机制要求动态实现不同云租户之间的安全隔离。云数据中心还要满足不同终端用户不同场景的业务组网要求以及他们的安全隔离要求。因此，云操作系统的复杂性将随着云租户及租户内物理机和虚拟机实例的数量增长呈现几何级数的增长，由业务应用驱动的数据中心网络虚拟化和自动化已变得势在必行和不可或缺。为了实现彻底与现有物理硬件网络解耦的网络虚拟化与自动化，唯一的途径与解决方案就是SDN（也即所谓软件定义的网络），即构建出一个与物理网络完全独立的叠加式逻辑网络，其主要部件以及相关技术包括以下几方面。

SDN控制器：这是软件定义网络的集中控制模块。负责云系统中网络资源的自动发现和池化、根据用户需求分配网络资源、控制云系统中网络资源的正常运行。

虚拟交换机：根据SDN控制器，创建出的虚拟交换机实例。可以对这个虚拟交换机进行组网的设计、参数的设置，一如对物理交换机的使用。

虚拟路由器：根据SDN控制器，创建出的虚拟路由器实例。可以对这个虚拟路由器进行组网的设计、参数的设置，一如对物理路由器的使用。

虚拟业务网关：根据用户业务的申请，由SDN控制器创建出虚拟业务网关实例，提供虚拟防火墙的功能。可以对这个虚拟业务网关进行组网的设计、参数的设置，一如对物理业务网关的使用。

虚拟网络建模：面对如此复杂多变的组网，如何保证网络的有效区分和管理，又能保证交换和路由的效率，一个有效的建模方法和评估模型是需要的。虚拟网络建模技术能提前预知一个虚拟网络的运行消耗、效率和安全性。虚拟网络建模可以做成一个独立功能库，在需要的时候启动，以减少对系统资源的占用。

3．资源服务与调度层

相对虚拟化层在业务执行面和数据面上“资源聚合与分割仿真”，该层次主要体现为管理平面上的“逻辑资源调度”。

由于多个厂家已经投入到云计算的研发和实施中，不可避免地有多种实现方式。而要实现云计算真正的产业化并被广泛使用，各厂家的云计算平台必须要能够互相交互，即进行接口标准化。接口标准化后，主流的虚拟化平台，例如Hyper-V、KVM、UVP、ESX等之间能够互相兼容。各个硬件厂家或者中间件厂家可以自由选择虚拟化内核。

在云计算新的发展阶段中，面向公有云、面对国际化公司的分布式云系统将是重点。这样引发对超大资源的分配和调度。在整个云计算的实现架构上，计算、存储、网络资源的分配和使用将走向专业化。这是因为一个云应用业务，根据性质的不同，它对计算、存储、网络资源的需求可能是不一样的。例如：呼叫中心业务偏向于计算资源使用，而对于网盘业务则偏向于存储资源使用。在这种情况下，为了更有效地利用资源，给业务层提供基本资源调用API是最好的选择，将计算、存储、网络资源都作为基本资源单位，提供统一的资源调用接口，让云业务开发者自己选择如何高效地使用这些资源。这些API包括以下几个方面。

弹性计算资源调用API：计算资源包括CPU和内存，云计算平台根据云运营商的要求，已经将CPU和内存虚拟化和池化。系统提供资源的动态申请、释放、故障检测、隔离和自动切换功能，做到业务不感知。CPU资源又可以分为纯计算型、图像处理型等不同类型。不管是CPU还是内存，都提供瘦分配功能，资源的自动伸缩保证在低业务量时减少资源的消耗，高业务量时开启所有物理资源，确认业务的高效运行。计算资源API还需要提供集群能力。

弹性存储资源调用API：存储资源API提供文件或者卷接口，除了提供常见的资源申请、释放、瘦分配等功能外，还涉及其他几个关键方面。

● 异构资源的池化：不同的厂家在将存储资源池化后，提供统一的API，一个厂家可以利用这些API，将不同厂家的存储资源池构成一个大的资源池，然后再封装出API供业务调用。

● 存储资源的分层分级存储：因业务性能要求的不同，分层存储是一个常用的技术，业务系统在申请存储资源的时候，可以选择是否使用这个特性。

● 内存存储资源的支持：未来的系统，内存一定会成为主存，所有的存储，除非一些特别重要的信息，基本上不再需要存入非易失性介质。而使用内存资源作为主存，可靠性是关键要求。在构造内存存储池的时候，可靠性必须贯彻始终，每个内存存储在其他地方有备份，或者确保内存存储有可靠的UPS保护。

弹性网络资源调用API：网络资源API的基本功能也包括资源的申请、释放、监控、故障隔离和恢复等，也需要考虑异构资源的统一化。

二、云平台大数据引擎层

数据服务层是叠加在基础设施服务之上，具备多租户感知能力的结构化、半结构化及非结构化数据服务的能力。

结构化数据服务子层提供对结构化数据的存储和处理功能，它通过叠加各种结构化数据库软件来实现，例如常见的Oracle\Sybase\HANA等。为提高处理效率，弹性存储资源调度层会针对不同的基于磁盘或者基于内存的数据库，提供更高效的存储资源调用API。例如面向HANA内存数据库，提供内存专用的存储资源调用API接口。

非结构化数据服务主要是叠加常见的NoSQL数据库的功能模块，例如Map-reduce、HBase等，提供弹性存储资源的特殊接口。

流数据服务更多地涉及对特殊CPU资源和专用芯片资源的使用。在弹性计算资源API中提供一些专用接口，来进行流数据的高效输入、压缩、解压缩、处理和转发。

传统IT系统中，软件业务处理逻辑总是位于端到端软件栈的核心，数据是作为业务处理逻辑可持久化的后端支撑，由此出现了数据库引擎技术及SQL标准化查询语言，用来进行可靠、高效的关系型数据创建、更新、存储和检索。由于数据库领域的算法难度大、专业性强，一直以来可商用数据库均由Oracle、IBM、Sybase等少数几家厂家所垄断。随着开源数据库技术的不断成熟和发展，特别是大数据与分布式数据库技术方兴未艾的发展，以及基于大量基础数据的机器学习算法不断取得突破，并在互联网搜索、电商和广告领域获得广泛应用，打破了数据总是作为独立应用的附属支撑的定位，使得之前被事务处理逻辑边界限制的数据孤岛，有可能通过ETL数据抽取和汇总机制，被大规模集中存储起来，并进行大规模的横向跨数据源、数据集（OLTP），乃至跨越较长时间跨度的内生关联关系与价值信息的抽象分析提取与挖掘分析，原先需要通过昂贵的软件License及专业支持才能实现的数据汇总分析（OLAP），通过开源软件即可实现。

三、云应用开发部署及中间件层

传统企业IT数据中心中，J2EE、微软．NET、IBM WebSphere、Oracle WebLogic等是被普遍采用企业应用开发平台及中间件（如消息队列、缓存、企业集成总线等），然而随着全球互联网化、移动化等大趋势对业务创新能力以及快速响应客户需求的挑战不断加剧，传统企业中间件在开放互通性、水平扩展能力、支撑快速敏捷迭代开发等方面越来越无法满足业务支撑的需要，与此同时，以Kubernetes、Mesos、Coudify等为代表面向DevOps敏捷开发的开源应用与部署开发工具链与平台，具备分布式水平扩展能力的系列开源数据库和中间件，如MySQL/PostgreSQL/MangoDB、RabbitMQ/Kafka消息队列、Redis缓存，以及业务流行的Spring for Java、Ruby on Rails、Sinatra、Node.js、Grails、Scala on Lift、PHP及Phython等，在近年来获得快速成熟发展，且体现出相比传统企业中间件的几个关键优势。

开放性、标准化：基于开源，应用开发平台的管理API更为开放透明，同时也引入了容器化技术进行应用部署，使得应用实例的部署不再与编程语言（如Java）绑定。

轻量化：相比闭源软件，Web中间件自身的资源消耗大幅减少，容器化应用部署相比虚拟机模式更加轻量化、敏捷化。

分布式及弹性扩展：与数据库层扩展能力配合，提供负载均衡及弹性伸缩控制基础框架机制的支撑，使Scale-Out应用架构可聚焦于应用逻辑本身，开发更加轻松高效。

敏捷开发与上线部署：支持从开发、集成、测试验证到生产上线的全流程自动化环境置备及测试自动化，配置随同应用一起发布，任何生产环境、任何开发集成部署节点皆可一键式快速重用，而无须烦琐部署配置流程。

四、云服务运营控制

云服务运营控制系统的主要服务对象是云服务产品定义、销售与运营人员，针对上述基础设施层、大数据层以及应用开发部署层的云服务产品，当然不是云服务运营者无偿提供给租户和用户使用的，需要引入“云服务运营控制”子系统来负责建立云服务产品在供应者和消费者之间的线上产品申请、受理及交付控制，以及完成与信息交付服务等值的货币交换。该系统以可订购的服务产品的形式在服务目录上呈现各层丰富多样的云服务产品，同时可基于云资源及云服务的实际使用量、使用计次及使用时长的消费记录，或简单按照包年包月的模式进行计量和计费，从而将企业获取IT产品和服务的商业和交付模式真正从买盒子、买上门人工服务支持（CAPEX）这样直接在线获取转变为按需在线购买（OPEX）的模式。一方面充分保障了面向云租户与消费者的经济性、敏捷性效益，另一方面也让公有云服务运营者从外部租户的规模经济效益中获利，并不断提升其服务质量；而私有云运营者也可有效依据计量计费信息来核算内部各租户、各部门对云服务产品的消费情况，并给出预算优化建议。

因此，对于公有云来说，“云服务运营控制”系统，进一步包含了租户身份认证鉴权管理、客户关系（CRM）管理、订购管理、产品定义与服务目录、促销与广告、费率管理、批价与信用控制、计费计量等一系列功能模块；而除了与公有云场景共享的租户身份认证鉴权、产品定义和服务目录、计量计费功能之外，与企业内部多层级部门组织结构相匹配的资源配额与服务封装和服务目录定制，服务申请审批流程，与ITIL系统的对接等，则是私有云服务运营过程需要解决的独特性问题。

无论是公有云还是私有云，为广泛引入第三方ISV的软件加入自己的云平台生态系统，将第三方软件与自建的云平台相结合，并进一步实现对自研和第三方云服务能力的封装组合及配置部署生命周期管理的工作流及资源编排自动化管理，引入了所谓Markeplace应用超市及XaaS业务上线系统，使得未来在IaaS/PaaS平台能力基础上引入的第三方业务上线部署、配置以及测试过程从原来多次重复的人工干预过程，转变为一键式触发的全自动化过程，从而大幅提升第三方应用软件在公有云、私有云平台上实现上线过程的自动化和敏捷化效率。

五、云DC运维管理

云DC运维管理子系统，目标是服务于云DC的运维管理人员的日常运维管理，包含云平台与应用软件的安装部署与升级补丁，虚拟及物理基础设施的监控与故障管理、日志管理、自动化仿真测试、安全管理，成本管理等功能模块和内部服务，通过管理工具支撑运维人员对系统运行的异常事件及健康状态进行快速、高效的响应处理，从而保障面向最终租户提供的云服务可靠性、可用性、性能体验等SLA属性达到甚至超出承诺的水平。

1．面向DevOps敏捷开发部署的软件安装与升级自动化及业务连续性保障

在管理控制平面上，云DC相对于传统DC运维体系带来的一个显著变化，就是各云平台、云服务，以及云运维管理软件的架构，从原来厚重的模块化、服务总线式架构，演进到被拆解分离的多个轻量化、运行态解耦的微服务架构，各微服务间仅有REST消息交互，没有任何数据库、平台组件的实例化共享依赖，从而实现了在线模式下各微服务的独立安装、灰度升级，数以百计的各个不同版本的云平台、云服务以及云管理运维微服务，只需保证升级时间窗内多个共存版本的服务接口契约语义级与功能级兼容性，以及各自上线前的预集成验证工作充分到位，无须做端到端系统测试，即可基于敏捷开发、集成与部署的支撑工具流水线，实现各自独立版本节奏的升级更新与上线发布，并在新上线发布的观测期期间一旦发现问题，具备快速升级回退的能力。

在数据平面上，由于租户的所有业务应用运行承载在每台服务器的虚拟化引擎及分布式存储和软件定义网络平台的基础上，因此为保障在对数以万计到百万计的资源池节点上的虚拟化引擎，分布式存储及软件定义网络，以及其管理代理节点进行软件升级的过程中，租户业务中断最小化，甚至是零中断，首先在工程上必须将此类资源池基础平台类软件的升级分批执行，其次也必须支持完善的虚拟化和分布式软件系统的热补丁机制，以及必要的跨物理节点热迁移机制，从而最大限度地降低升级过程中系统平台重启动带来的对云租户可感知的业务中断影响。此外，在热补丁无法完全覆盖、重启租户资源池服务器的场景下，则需要考虑引入对云租户可见的故障域的概念，引导用户将具备主备、负荷分担冗余能力的应用负载部署在不同的故障区域内，从而实现在不对故障域做并行升级的前提下，业务基本不中断，或业务中断时间仅取决于业务应用的主备切换或负荷分担切换的时延。

2．智能化、自动化的故障与性能管理

与传统DC高度精细化的人工干预管控及治理模式不同，云DC运维管理最为显著的差异化特点是管理对象的数量、规模及复杂度均呈现指数级增长，因此对运维管理的自动化、智能化提出了更高的要求。从上述系统架构描述不难看出，无论是公有云还是私有云，一个功能完整的云DC软硬件栈系统是由基础设施层（进一步分解为虚拟化和软件定义存储与软件定义网络构成的数据平面，以及标准化云服务管理层）、数据层，以及应用开发部署平台与中间件层等多个SOA解耦的微服务、软件组件所构成的，具有很高的系统复杂度；同时云DC中的分布式、规模和数量庞大的基础设施（对于公有云及大型私有云，服务器数量往往可达数万到数十万、百万规模）及各类系统云服务及租户的业务应用负载数量，也达到了数以百万乃至千万级的程度，对网络与安全工程组网也提出了巨大挑战。因此，为应对上述挑战，将云DC运维管理员从传统DC烦琐低效的人工干预、保姆式管理监控与故障处理中解放出来，转向尽可能无人干预的自动化、智能化的运维管理模式，将人均维护管理效率从平均每人数十台服务器，提升到平均每人数千台服务器，需要解决的关键问题及其解决方案包括以下几点。

基于工作流的自动化人工故障修复机制：过基于最佳运维实践预定义的工作流驱动，或者依据长期积累的故障模式库来驱动自动化运维工作流进行监测及无人干预或基于事件告警通知的一键式修复。

基于日志和监控信息的跨微服务、跨系统的制定业务流程和租户用户追踪与关联分析，用以解决客户报障和主动告警场景下的快速故障定位：传统数据中心中，各软硬件系统的日志监控信息往往相对零散孤立，没有实现与业务和用户的自动关联，因此难以适应复杂度更高的云数据中心故障管理的需要。

基于大数据机器学习引擎的大规模运维场景下的性能与故障规律分析、趋势预测及故障根因识别定位：传统数据中心的故障发现与修复建议的处理，主要依赖于运维管理系统收集监控日志信息，以及运维团队长期积累的历史经验总结出来的典型故障模式。但随着云数据中心管理维护对象的数量级增长，以及系统复杂度的持续迭代提升，导致基于人工经验及故障模式积累的维护效率终将难以跟上公有云及大型私有云业务规模快速扩张发展的步伐，因此需要引入大数据机器学习机制，对历史积累的海量故障和监控信息进行围绕特定主题的关联分析，从而自动化地、智能化地挖掘出更多高价值的、运维人员认知范围外的故障模式与系统优化模式，从而进一步提升系统运维的效率。

3．生命周期成本管理

除上述挑战之外，由于公有云、私有云面向云租户与云服务消费者的基础设施服务，是一个需要持续投入服务器和网络与安全硬件的重资产经营过程，因此如何保证运营过程中的硬件资产投入产出比与经济效益，如何进行精细化的成本管理，就成为一个至关重要的问题。在传统数据中心中，所有硬件资产都是以配置库的形式进行编号管理，用户与硬件基本是固定对应的关系，然而在这些硬件资产资源池化和多租户自动化之后，硬件通过虚拟化和跨节点调度机制在多个租户间动态共享，而云服务界面上甚至也会参照QoS/SLA的要求，面向租户提供超出硬件实际供给能力的资源配额，这些硬件资源是否在云资源池的共享环境下得到了高效的使用，硬件的平均空置率，或者说应用和租户对硬件资源的实际使用效率是否达到了理想水平（比如高于80%的实际使用率，或低于20%的空置率），是否需要对资源分配算法、超分配比率做出及时调整，将对公有云的可持续运营利润水平，以及私有云、混合云的成本控制效率，将产生决定性的影响。

2.1.3 云计算的服务及管理分层分级架构

面向云租户、云服务消费者的服务分层分级视图，如图2-6所示。

一朵云划分为多个服务区域（Region），每个服务区域对应一组共享的IaaS/PaaS/SaaS云服务实例，不同服务区域可能有不同的服务产品目录，以及体现云服务对区域本地化需求的考虑，如本地化的服务订购Portal，虚拟机及云服务的区域化定制选项等。

公有云面向全球的用户提供云服务，因此往往设计为跨多个服务区域，每个服务区域部署一套云服务，但多个服务区域共享同一套租户认证鉴权管理系统（SSO一次性登陆鉴权），这样租户一旦成功登录鉴权后，即可在不同服务区域间随意按需切换，而无须重新鉴权。

一个服务区域由2个或2个以上可用性区域（AZ）组成，每个可用性区域面向租户呈现为一个地理上独立的可靠性保障区域，该区域一般依赖于相同的数据中心层1基础设施，比如数据中心电源供给、UPS非间断电源。

一般情况下，租户会指定将其申请的云资源及应用发放部署在哪个AZ内，对于分布式应用，则可选择应用跨AZ部署，以实现更高层次的地理容灾可靠性保障。

在租户签约虚拟机或容器服务的情况下，可以看到隶属于该租户的每台虚拟机或每个容器实例；在租户签约物理机的情况下，可以看到每台物理机实例，除此之外的资源池集群，物理数据中心等概念均对租户不可见。

面向云数据中心运维人员的管理分层视图，如图2-7所示。

每个服务区域（Region）下的可用性区域（AZ）设计部署对于云DC管理员直接可见，每个Region到租户/最终用户侧的接入时延一般推荐在100 ms的范围内。

服务区域（Region）内各可用性区域（AZ）间的网络传输时延迟一般控制在10ms的范围内，一个可用性区域一般由一个多个物理数据中心构成，物理数据中心层仅对运维管理员可见，对普通租户/用户不可见。

数据中心内物理网络传输时延一般在1ms范围以内，由一个或多个层2网络或层3子网构成。

每个物理数据中心内可以部署一个或多个资源池集群（POD），每个资源池集群（POD）对应一个云资源池调度管理系统实例（如OpenStack），每个资源池集群包含的服务器规模一般是数千到数万台，其中包含了用于承载租户业务应用负载的计算集群，以及用来承载租户数据的存储集群。

每台虚拟机缺省情况下直接接入到基础云资源调度管理系统，但对于异构的传统虚拟化集群，也可整体作为一台逻辑“大主机”接入到资源池调度管理系统。

在同一物理资源池集群范围内，考虑到云租户对服务器硬件需求的特殊性（比如对于GPU加速硬件、SR-IOV网卡、不同工作频率和数量的CPU、不同容量的内存、不同类型的虚拟化集群，乃至裸金属物理机集群等），均需要对隶属于同一资源选择属性的服务器进行标签（Tagging），隶属于同一资源属性标签的服务器构成一个“主机集合”，同一服务器主机可被标记为多个资源属性标签，即可以隶属于多个“主机集合”。由此可见，“主机集合”是一个物理资源池集群范围内用来划分与动态资源调度相关的，基于特定资源池属性维护来划分的“逻辑资源池”概念，该“主机集合”的标签条件，将与云资源池调度管理软件API入口制定的动态调度参数进行匹配，从而决定当前的资源发放申请被调度到哪些“主机集合”内。

分布式数据中心

对于新建的公有云数据中心，一般会选择尽量在选定的数据中心内集中式部署大规模资源池，即在云资源调度软件能力可以支撑的范围内，尽量扩大整合资源池的管控范围和规模。然而，由于部分大企业云租户对部分关键信息资产上公有云的安全顾虑，公有云也可选择将部分可用性区域及资源池集群建在远端的企业数据中心内，或者物理上与公共资源池完全隔离的托管区，此时该AZ/POD的规模往往规模较小，仅有几十到上百台服务器的规模，称之为“微型数据中心”（Micro DC），但同样可通过与公有云大规模集中管理数据中心之间的VPN/MPLS广域网络连接实现统一的资源管控与调度，并保障该租户特有的敏感应用负载及数据仅存放于该租户专属的物理托管区域内。

对于新建的私有云数据中心，考虑到对现有分散部署的虚拟化及物理资源池的继承和利旧需求，以及部分终端用户接入体验敏感的应用负载就近接入的需求（比如虚拟桌面、视频交互应用等），也会提出从大集中数据中心拉远的分布式多站点的可用性区域/资源池集群的需求。

2.1.4 拉通公有云与私有云的混合云架构

如上面几个章节所讨论，公有云服务因其大规模集约化的优势，在弹性、敏捷性以及无须固定硬件投资、按需资源及服务申请和计费的成本优势方面，获得了广大企业用户，特别是中小企业用户的青睐。公有云业务在国内乃至全球范围内的普及程度和渗透率也有了大幅度提升。然而与此同时，我们也不难发现，很多大企业及政府机构在面临云计算的建设使用模式的选择时，不可避免地将安全性问题放在了一个非常重要的位置上，甚至是作为首要考量的因素。目前，仅有在自建数据中心及自己维护管理组织的掌控范围内私有云模式才能保障企业敏感涉密的关键信息资产。这一事实决定了私有云仍将是很多大企业建设云计算首要选择的模式，私有云仍将与公有云在未来相当长一段时间内并存发展。只有拉通公有云和私有云的混合云能够将线上的公有云弹性敏捷优势，与私有云的安全私密保障优势相结合，实现优势互补，才能成为企业的最佳选择（见图2-8）。

然而，考虑到大企业、政府机构等的业务负载的多样性，需要向云端迁移的应用并不仅仅包含核心涉密的信息资产，也包括业务突发性强，资源消耗量大，并且具备资源使用完毕之后可以立即释放的特征，比如开发测试应用、大数据分析计算应用、电商渠道的分布式Web前端应用等，均属于此类应用负载。这些应用当然也更适合采用公有云的方式来承载。但对于同一企业租户来说，如果一部分应用负载部署在公有云端，另一部分应用负载部署在私有云端，则仅仅跨云的身份认证、鉴权、拉通的统一发放及API适配是不够的，更重要的是必须实现拉通公有云和私有云的安全可信网络，实现自动化建立网络连接。

除基于企业应用负载的安全隐私级别分别跨公有云和私有云进行静态部署之外，对于已部署在私有云之上的应用而言，电商网站的三层Web架构、负载均衡、Web前端和数据库后端初始已部署在私有云内。当业务负载高峰到来后，企业用户希望可以在不对Web网站应用做任何修改与配置调整的情况下，实现Web前端到公有云的一键式敏捷弹性伸缩，并借用公有云端的弹性IP及其带宽资源，从而应对峰值业务负载对资源使用量及IP带宽资源的冲击。

为满足上述诉求，需要跨不同的公有云和私有云，构建一层统一的混合云编排调度及API开放层，实现跨不同异构云的统一信息模型，并通过适配层将不同异构私有云、公有云的云服务及API能力集，对齐到混合云的统一信息模型，并通过SDN与各公有云、私有云的网络控制功能相配合，最终完成跨异构云网络互联的自动化。

当然这个统一编排调度引擎，以及API开放层的实现架构，存在不同的可选路径。

1．路径1

引入一个全新的编排调度层，逐一识别出跨不同异构云的公共服务能力，并以此公共能力及其信息建模为基础参照，进行到各公有云、私有云的计算，存储原生API能力的逐一适配。

该路径下的跨云网络互联方案，需要混合云SDN与各公有云、私有云的VPN网络服务进行紧密协同配合，由于不同异构云之间的网络服务语义及兼容性相比计算和存储服务差别更大，因此也必然给跨云的VPN网络连接适配处理带来了更大的复杂度与挑战。

2．路径2

依托于业界开源事实标准的云服务与调度层（如OpenStack），作为拉通各异构公有云、私有云的信息模型及API能力的基准，通过社区力量推动各异构云主动提供与该事实标准兼容的适配驱动。

该路径下的跨云网络互联，采用叠加在所有异构云虚拟化之上的Overlay虚拟网络机制，无须进行跨异构云的网络模型适配转换，即可面向租户实现按需的跨云网络互联，从而大大降低了跨云网络互联处理的难度，为混合云的广泛普及奠定了坚实的基础。