下载掌阅APP，畅读海量书库
立即打开
云计算在快速发展的过程中逐渐形成了不同的服务模式。目前我们常见的云服务模式（交付方式）主要有3种：SaaS、PaaS与IaaS，也有人喜欢把它们统称为XaaS或EaaS（Everything as a Service）。类似地，还有存储即服务（Storage as a Service）、容器即服务（Container as a Service，CaaS）等，近几年又出现了区块链及服务（Blockchain as a Service，BaaS）和功能即服务（Function as a Service，FaaS）。
从根源上讲，XaaS模式源自面向服务的体系结构（Service-Oriented Architecture，SOA）。SOA是一种架构设计模式（可类比面向对象编程语言中的设计模式），其核心就是一切以服务为中心，不同应用之间的通信协议都以某种服务的方式来定义和完成。今天我们经常看到的微服务架构（Microservices Architecture，MSA）的概念，它在本质上也是由SOA演变而来的。所以，由亚马逊公司推出的无服务器架构和它的实现方式FaaS可以被认为代表了云服务的一种新潮流，这种基于虚拟化容器的部署方式可以更精细地计算出使用的云服务数量，把云服务花钱的计量单位由虚拟机变成虚拟化容器。这就相当于帮助用户更加精打细算，实现即需即用。此外，对于云计算的使用者和开发者来说，无服务器架构也是一个好的选择，功能松散耦合，降低了开发难度，提升了开发敏捷度。
为什么会形成XaaS服务模式呢？主要原因在于最终服务交付的形态。在云计算发展过程中，不同服务模式之间的对比如图1-9所示。
图1-9 不同服务模式之间的对比
在传统的IT运维与交付模式上，从最底层的各种硬件到操作系统，到中间任何一层运行环境，再到数据与应用全需要人力来维护。SaaS是最全面的服务交付模式，从上到下所有的问题都由平台来解决，较为著名的例子是客户关系管理（Customer Relationship Management，CRM）服务提供商Salesforce和Intuit公司，后者提供从记账到报税的一站式服务。IaaS则更多地专注于底层硬件平台与虚拟化或容器封装，而把从操作系统到上层应用的自由都留给用户，典型的例子是像亚马逊公司或阿里云提供的云主机服务。在SaaS与IaaS中间，还有一种服务交付模式PaaS，PaaS可以被认为是业界在看到IaaS交付和用户使用过程中遇到的各种问题后对服务交付自然延伸的必然结果，用户希望平台方能对操作系统、中间件、运行，甚至是应用与服务的持续升级、持续集成等提供管理服务。在后面的章节中我们会专门介绍目前业界具有代表性的PaaS解决方案。
在下面的内容中，我们先来了解云的不同部署形态。
从云架构部署、服务、应用及访问方式来看，我们一般把云分为四大类，分别是私有云、公有云、混合云和社区云。
对于私有云和公有云，大家耳熟能详。混合云顾名思义，既包含私有云，又包含公有云。社区云相对少见，它是一种特殊形态的私有云、公有云或混合云，通常由一些协作的组织在一定时间内基于同样的业务诉求与安全需求而构建。目前，社区云还细分为政务云（面向政府行业）、医疗云（面向医疗行业）、金融云（面向金融行业）、教育云（面向教育行业）等专有云服务。从“术业有专攻”的细分上也可以看出，“云+行业”这种结合是目前云计算的又一个发展趋势。未来，云服务会根据各种场景制作出更多的云服务方案。下面我们主要谈谈对前3种云的认知。
私有云、公有云、混合云的定义与界定的关键是云的服务对象是谁。如果服务对象是一个机构，那么其为私有云；如果服务开放给大众，并通过互联网可以访问，则称之为公有云；混合云通常是兼有私有云和公有云两部分，这两部分可相对独立运作，也可协同工作，例如一些任务可能会横跨公有云和私有云的边界。当然还有如上所说的专有云，在本质上依然是私有云的一种。它经常以被托管的私有云的方式存在，目前各地方政府和企业经常会把自己的可以放入云中或向云端迁移的那部分业务托管给第三方云服务提供商来运维。多种云之间的对比如图1-10所示。
图1-10 多种云之间的对比
从“物种起源”的角度上说，公有云与私有云都是由早年的数据中心（Data Center，DC）或互联网数据中心（Internet Data Center，IDC）发展而来的。它们除各自所侧重的服务不同之外，在技术本质上没有高低优劣之分。
公有云侧重于对新应用（如第三平台应用）的支持，以及面向应用的弹性实现（如支持可横跨多台云主机的数据库服务），在存储角度上则大量使用对象存储（如支持对多媒体文件的检索和浏览）。为了实现利益最大化和产生正向现金流，绝大多数的云部件都被封装成商品，待价而沽。
私有云大抵是历史的原因不得不继续支撑传统的企业应用，如第二平台的大量应用，从数据库到ERP
/CRM，不一而足，因此私有云的存储形态主要是文件和块，并且侧重于基础设施弹性（第二平台应用的一个典型特点是具有独占性或者说紧耦合性，它们很难像第三平台的那些为云而生的新应用那样，能比较容易地迁移和水平可伸缩，因此业界的普遍做法是把这些应用封装后在底层的基础设施上实现弹性）。
我们做了一个简单的表格来比较3种云的异同，见表1-1。
表1-1 公有云、私有云、混合云的异同比较
业界对云的认知中普遍存在的一个印象是公有云是云的多种形态中的主体，这个印象其实只对了一小部分。按照媒体广告投入规模和曝光频率，公有云的确是更多一些，但就市场整体规模和真正承载的云计算任务量而言，私有云和专有云的总市场份额约为88%，而真正的公有云市场份额约为12%。
误解1：公有云会是未来唯一可行的云服务形态。从业务增长速度来看，公有云的增长速度的确高于私有云，但是，如果把所有在私有数据中心中的投资都计入私有云，则私有云在绝对规模上远远大于公有云。另外，业务需求的多样性，特别是对体系架构安全性、可定制性的需求决定了公有云不可能取代私有云或混合云。
误解2：公有云拥有核心技术。我们认为不同形态的云之间的技术并无本质上的区别，私有云、公有云与混合云可以说各有千秋。公有云更多注重用户体验及应用层的弹性，而私有云对安全、性能及对用户需求的可定制化有更多的关注。此外，造成它们之间的差异，即选择公有云还是私有云的主要原因是技术之外的因素——决策者对某种技术的喜好、偏执都可能会导致最终选择某种云而摒弃另外一种云。
误解3：要么是公有云要么是私有云，非此即彼，它们不会共存。这是一种典型的“非黑即白”式的认知偏差。真实世界的问题，尤其是在大中型企业的IT系统中，通常会存在多种云并存的模式：部分线上业务在公有云上运行；部分业务（如内部的多个系统）在私有云上运行；企业间的一些数据交互业务则可能是在某种社区云上运行。我们需要明白一点，对云架构的选择是业务驱动的，需要企业根据其具体情况来灵活地采取选择和处理方式。
还有一个知识点值得一提，是关于场内与场外的内容。所有的公有云对于其服务的客户而言都在云端，是场外的；而私有云多数都是场内云的本地云。有一种特殊的专有云情形，那就是在托管方地界运营的私有云是场外的。比较典型的例子是在线视频提供商美国奈飞公司（Netflix），它已经把整个基础架构都迁移到了亚马逊的云上，而且使用的是不与任何第三方共享的基础设施，从本质上说这是一种IaaS的外包形式。
认知1：胜者为王。俗话说胜者为王，败者为寇，其实西方也有类似的俗话——Winner Takes All，这也适用于公有云领域。从云的市场份额、营收规模来看，亚马逊公司的AWS如日中天，它一家的云收入超过其他全部厂家云收入总和的一半，而且亚马逊公司也是唯一一家在2015年就实现了云收入盈利的公有云服务商。对比其他云服务商，如微软公司，到2021年年底，微软公司没有公开发布其Azure云服务具体财务指标的任何资料。AWS的收入变化以及与其他厂家云服务产品收入的比较如图1-11所示。
图1-11 AWS的收入变化以及与其他厂家云服务产品收入的比较（数据来源：Statista）
图1-12展示了2022年第一季度全球云服务提供商的产品市场份额。按照Statista的统计数据，全球公有云市场变成了3家占主要份额：AWS占据了33%的市场份额，微软公司的Azure因持续的高复合增长率而拥有了21%的市场份额，谷歌云平台占据了8%的市场份额。其他我们耳熟能详的国内厂家则因为市场份额不高而被统计在其他云服务提供商部分（38%）。
图1-12 2022年第一季度全球云服务提供商的产品市场份额（数据来源：Statista）
认知2：规模经济效益，即通过一定的经济规模形成的产业链在完整性、资源配置与再生效率上的提高所带来的企业边际效益的增加。我们身边常见的例子就是大型连锁超市和小超市的商品价格不同。一般来说，大型连锁超市的商品会比小超市商品的价格便宜，这是因为大型连锁超市的规模更大，供应链更完整。这也同样适用于云计算领域，当云计算的规模较小时，相对的亏损比例会很高，而盈利的能力难以体现。只有当规模越来越大时，才会逐渐降低亏损并最终实现正向盈利。我们看到的情况是，截至目前，市场上做得比较好的是AWS，其他厂家还在不断探索和继续扩大规模。
我们用一张表来说明云计算的优点，见表1-2。
表1-2 云计算的优点优点
1 QoS：Quality of Service，服务质量。
2 SLA：Service Level Agreement，服务水平协议。
前面我们介绍了不同形态的云的特点，并列出了一些规则来帮助人们决策到底要选择哪种云以适应各自的业务需求。在拥抱云的过程中，从人的思维方式到团队的合作方式，再到与客户的接洽方式，甚至是整个社会的运作方式都在逐步发生巨大的变化。这一小节我们就来谈一谈变化中的云。
我们先回顾一下，传统的数据中心中运行的是大量的、专用的、垂直的一些堆栈式应用，完成各种响应性操作。在其向云转变的过程中，云计算带来了三大变化，如图1-13所示。
图1-13 云计算带来的三大变化
（1）基础设施
第一个变化是基础设施。当年电信运营商受到新兴IT企业冲击的背后，是其大量使用的专用点对点、回路交换等技术被包交换、IP等技术颠覆了。这些技术逐渐渗入基础设施中的各类设备上，提供了更高的性能、效率、安全和可用性。同样地，在今天云化的过程中，构建云基础设施也有类似的特点：采用了大量的虚拟化技术，选择了通用硬件平台，采取了开源技术的应用，等等。
（2）运营模式
第二个变化是运营模式。在云的时代，任何事物都可以以一种服务的方式来交付，其中包括IT。ITaaS（IT as a Service）于是应运而生。ITaaS是个抽象的概念，直观说法就是它具体体现在整个服务流程的自动化，以及对不同优先级任务的区分对待等，最终的目标是实现资源的最优调度和配比。
（3）应用
第三个变化就是应用。在第三平台中我们前所未有地注重用户体验，“一切为了应用”已经变成了一句箴言，从基础设施到运营模式都是为了更好地创造应用、优化应用，并围绕应用提供一套完整的数据采集、处理、分析、汇总、反馈的系统（十几年前我们叫商务智能，今天我们叫大数据），然后通过集成到客户端的应用展现给终端用户。
我们换一个维度来看上面提到的三大变化，即云的三大变革，如图1-14所示。
图1-14 云的三大变革
用一句话来总结基础设施变革与应用变革，那就是：变革中不会也不可能摒弃传统的架构与应用，在引进新的云架构、新应用的时候也需要兼顾传统的需求。
运营模式的变革是为了更好地服务基础设施与应用，其主要的变化可以用 “5+1+1”来表达，其中，“5”表示计量引擎、编排引擎、策略引擎、服务目录、用户门户，两个“1”分别表示敏捷流程和新IT角色。
（1）引擎+目录+门户
我们来分别了解一下“5”代表什么。用户需要一个门户作为入口，访问云计算所提供的服务。在门户当中最重要的就是提供以下服务。
① 服务目录。这个很容易理解，就好像逛超级市场或上网购物一样，你会需要一个目录来帮助你快速检索。
② 各种引擎帮助实现具体服务与任务的管理与执行，具体而言就是策略、编排与计量三大引擎。策略可以是多种多样的，如访问策略、安全策略、网络策略；编排是一个很大的概念，我们把自动化部署，以及资源管理、监控、储备等都划入编排的范畴；计量对于按需收费的云计算而言，是保证实施及完成监控的基础组件。
（2）敏捷流程
软件工程中有很多方法学与流派，其中两类的实践者最多，一类叫作顺序开发，另一类叫作迭代开发。顺序开发最典型的例子是瀑布流开发模式（见图1-15），其最大特点就是每两个环节之间紧密相连，设计之初就要有清晰的需求，实现之前就要有完整的设计，以此类推。对于传统的软件开发而言，这样的流程设计非常清晰，易于执行。而在一个需求高速变化，甚至设计也在高速变化，实现、验证与维护只有极短的时间与极少的资源来完成的时代，瀑布流开发模式就显得不合时宜，取而代之的是被称为敏捷开发的流程，如图1-16所示。敏捷开发有如下几个特点。
图1-15 瀑布流开发模式
图1-16 敏捷开发流程
① 轻监管（比瀑布流开发模式需要更少的项目监管）。
② 重互信（重视高度信任的管理与协作）。
③ 喜变更（即便在开发的晚期阶段也可能需要变更）。
④ 强交流（强调商务人员与开发人员交流的频繁程度）。
⑤ 快迭代（高频迭代，迭代周期从年缩短到月，缩短到周，缩短到天……）。
⑥ 评估项目进展的标准是可运转的软件。
从以上特点不难看出，敏捷开发流程属于典型的轻流程、重结果，具有以高速迭代为导向，保障失败后可以迅速重来的应变能力。它与瀑布流开发模式最大的区别是各环节形成了一个循环迭代的环。
值得一提的是，在从瀑布流开发模式向敏捷开发流程转变的过程中，大多数企业采用了一种折中的开发流程：瀑布式敏捷开发（Waterscrumfall），如图1-17所示。采用这种折中开发流程的核心原因是敏捷开发中依赖的迭代式增量开发模式不能被单一功能团队所完成，于是只能在部分环节依然保持瀑布流的方式。由于篇幅所限，本书无法对此展开讨论，有兴趣深究的读者可以查阅相关的专业图书。
图1-17 瀑布式敏捷开发
（3）新IT角色
我们再来看一下变革对人的影响——IT角色的变化。传统意义上的系统管理员、存储管理员、网络管理员、安全管理员等IT角色将逐渐退出历史舞台，取而代之的是云管理员、云架构师、自动化工程师、开发+运维合二为一的角色DevOps（Developer-Operations）等新IT角色，如图1-18所示。
图1-18 新IT角色
我们在前面讲解了云带来的一系列变革，那么现在来关注当选定了一种云形态之后是否就一成不变了呢？
越来越多的初创型公司在早期阶段可能会因初始化投入成本较低而选择公有云服务，常见的是从云主机入手，逐渐扩展到云存储、云数据库、云加速器等服务。但是，随着业务的发展，到达某一个阶段的时候，就会出现以其他云形态来补充或者是从一个云服务提供商迁移到另一个云服务提供商的需求。不同形态云之间的转换如图1-19所示。
图1-19 不同形态云之间的转换
云迁移的诱发因素多种多样，可归纳为如下几种。
（1）性价比：客户永远在追寻更高的性价比，仅此而已。
（2）功能导向：对于A云不能实现的功能，若B云可以实现，则该功能会被迁移到B云。
（3）策略导向：例如合规要求的变化在原有云无法实现。
在任何两种云之间，云迁移的方向可以是双向的或单向的。从应用到数据到基础架构，都可能被迁移。有的迁移像搬家一样是一次性的，有的迁移是具有随机性和重复性的。较为典型的例子有云爆发
及混合云。
图1-20中描绘的是一个典型的混合云架构，我们用表1-3来说明公有云和私有云在一个混合云架构上各自的侧重点。
图1-20 混合云架构
表1-3 混合云架构上公有云和私有云的侧重点
注：*DAS，Direct Attached Storage。
接下来我们给大家介绍一些逐渐形成潮流的云间数据交换和跨云的基础架构迁移的场景。
场景1：云间数据交换。互联网公司在业务发展初期大量使用公有云服务早已成为一种定式，但是随着业务的发展，特别是需要处理的数据量呈爆发式增长时，有一些如大数据分析的业务由于公有云服务商品化硬件的限制（如单机的CPU和内存限制），不得不考虑自建数据中心（私有云）来完成，那么就涉及公有云与私有云之间数据的传输成本与效率问题，通常最高效的方式是在两种云之间拉设光纤专线。当然，两种云所处的数据中心在物理网络上距离越近，数据交换的效果越好。比如一家位于硅谷Mountain View的公司，它在AWS的EC2主机位于马路对面的数据中心，而自建的Cassandra集群就在其隔壁的互联网服务提供商数据中心里面，若建立一条连接彼此的10 Gbit/s的专线，则专线传输相当于在高速局域网里进行数据传输。当然，前面的这个例子是比较理想的场景，我们只需要关心数据如何在两个数据中心之间进行交换。这个问题可以进一步分解为4步。
（1）源数据传输准备：提取、去重、压缩、加密等。
（2）数据分发与传输。
（3）接收源数据：解密、解压、重建。
（4）数据重构。
图1-21展示的是一个典型的从源数据中心向目标数据中心通过分布式数据分发、P2P公共网络传输数据的架构。该架构意图达到高效、可靠、分布式数据传输的效果，同样适用于基础架构迁移的场景。
图1-21 从源数据中心向目标数据中心传输数据的架构
场景2：跨云的基础架构迁移。基础架构的迁移是指要把IaaS及之上所有的平台、服务、应用及数据完全迁移，这其中最大的挑战是对业务可持续性的要求。如果对在线业务的下线时间是零容忍，那么这就是一个经典的第三平台无缝衔接大数据迁移场景。参考图1-21，我们来简单描述一下如何实现无缝、无损数据迁移（为简化设计起见，假设源与目标数据中心具有相同或类似的硬件配置），具体如下。
（1）对源数据中心进行元数据提取。
（2）在目标数据中心重构基础架构。
（3）非实时数据的大规模迁移。
（4）在目标数据中心启动服务、应用进入备用状态。
（5）以迭代、递增的方式在源和目标数据中心进行实时数据同步。
（6）目标数据中心调整为主服务集群。
（7）持续数据同步、状态监控。
（8）源数据中心下线或作为备用基础架构。
至此，我们应该对云的各种形态都有所了解，它们不是一成不变的，套用一句古希腊哲学家赫拉克利特的名言：唯一不变的就是变化本身。