第 3 章　使 用 场 景上一章介绍了一个参考架构，可以使用这一架构来对云计算解决方案的一些主要元

素进行分类。在这个相对简单的模型背后，有着多种多样的可选实现方案。如果我们能

对这些可选实现方案进行一番更实用化的阐述，那么形象地理解它们可能就更为容易。

大多数组件都既可以托管在一个私有的数据中心中，也可以建立在公共的基础设施上。

几乎每一种基础设施服务、平台服务和软件服务的组合都可以集成为一种解决方案。

事实上，有时为了满足某一个架构构建块的所有要求，我们可能需要利用多个服

务。举例来说，假设你想要将服务（比如计算服务和存储服务）分解成一些由多个不同

来源提供的更小单元。

通常，如果所有服务都使用同一个提供商的服务，集成起来就十分简单 ；而如果每

个组件都使用该分类中最好的一项服务，也会潜在地给我们带来成本和功能方面的很大

优势。在这两者之间，通常需要进行一番权衡。在选择如何对解决方案进行分解时，应

当考虑的因素有：延迟、集成点、数据传输（带宽）、服务提供商定价结构和故障排除的

影响。

你可能还喜欢使用那些自己的开发人员已经掌握得很好的工具和平台。而且，通常

都有与遗留应用的互操作性，以及与供应商、合作伙伴和客户进行连接的需求。

从理论上讲，平台与服务组合的数量几乎是无限的，因此我们无法将这些组合一一

列举出来，而且这样做甚至也是没有任何用处的。我们从中选择出了下列这些具有代表

性的组合情况，我们认为它们既能够展示出那些最常见的场景，又能表现出你可能需要

考虑的那些可选方案。

采用 IaaS 存储的托管服务器•

专用 IaaS•

采用 IaaS 扩展的私有应用•

纯 PaaS•

采用 IaaS 的扩展的 PaaS 应用•

下面，我们就来更加具体地介绍一下这些组合。

24　 　第一部分　模　　型

3.1　采用 IaaS 存储的托管服务器

在开始使用云计算时，最简单的方法就是利用一个基础设施服务提供商的弹性存储

（见图 3-1）。在这种情况下，实际的应用平台（包括所有的架构组件）都运行在某个托

管服务提供商（如 GoDaddy 或 1and1）的专用服务器上。托管网站通常都会提供各种各

样的框架和工具，从 FrontPage 和 .NET ASP 到 ColdFusion、PHP 和 Perl，应有尽有。

展示 平台 信息

最终用户浏览器 托管的 LAMP S3 图片存储

图 3-1　采用 IaaS 存储的托管服务器

它们通常只包含限的本地存储空间，并且通常还带有一个 MySQL 数据库。不过对

于一些小网站来说，这可能就已经足够了。然而，如果应用需要依赖于高水平的可伸缩

性，并且还有其他一些特殊需求（比如版本管理或备份服务水平等），那么一个基于云

的存储服务（比如 Amazon S3）可能会更为合适一些。由于大多数存储服务都可以通过

SOAP 和 RESTful 的 API 来访问，所以我们可以很容易地将这些存储服务集成到几乎任

何托管的应用中。

3.2　专用 IaaS

另一种进入云计算的容易方法是：在 IaaS 上使用传统的 LAMP 或 .NET 技术栈。这

种方法需要先将数据和代码从现有的三层应用中迁移到一个基础设施服务上，这一类

IaaS 有 AWS（Amazon Web Services，亚马逊网络服务）、Rackspace Cloud 和 GoGrid 等。

其典型的应用场景（如图 3-2 所示）是：使用一对 EC2 服务器来作为前端 Web 服务

器，其后是一个作为数据库服务器为其提供支持的大型 EC2 实例，该 EC2 实例驻留在

Amazon 的 Elastic Block Storage（EBS）上。我们还可以使用 EBS 或 S3 来备份数据库

第 3 章　使 用 场 景　 　25

和存储其快照。

展示平台 信息

最终用户浏览器

前端服务器

数据库服务器

前端服务器

MySQL

EBS

EC2

图 3-2　专用 IaaS

这种解决方案的优势源于它与传统的数据库模型的相似性，所以开发人员和工程师

对于所涉及的操作系统和应用软件比较熟悉。如果需要更高级的可伸缩性，它还可以借

助于前端的伸缩弹性来为建立一个替代数据库层打开通道。随着时间推移，此类解决方

案还可以利用上额外的一些基于云的能力，但我们没有仅仅为了转换为云模式而对现有

的应用进行大修的迫切需要。

3.3　采用 IaaS 扩展的私有应用

企业内部部署的应用可能能够满足企业的一些需要，但企业仍然可能有兴趣利用

云来处理内部应用的高峰负荷。我们通常把这种方式称为“云爆发”（cloudbursting）

（Perry，2008），这种方法会对在私有平台上编写的现有企业应用进行扩展，使之能够在

内部容量耗尽时利用一些外部的服务。

例如，一个组织可能使用 VMware vSphere 建立了一套以 Oracle 为后端数据库的内

部虚拟化基础设施（如图 3-3 所示）。客户可以 VMware 的合作伙伴（如 Terremark 公

司）所提供的兼容公开软件来获得额外的资源、提升冗余度或者进行灾难恢复。

26　 　第一部分　模　　型

展示 平台 信息

最终用户浏览器 Oracle 数据库

Center 私有数据中心

Terremark

vCloudExpress

vCloudExpress

VMwarevSphere

VMwarevSphere

图 3-3　采用 IaaS 扩展的私有应用

在管理多家提供商和确保所有敏感数据的隐私方面，这种方式显然会遇到一些挑

战。不过，如果可以有效地解决这些问题，那么该模型在价格上颇具吸引力，并达到既

能充分发挥所有内部固有资源的潜力，又能在必要时获得高度可伸缩能力的目标。

3.4　纯 PaaS

一个以云计算平台为基础的解决方案能够最有效地利用伸缩弹性和效率的优势。在

图 3-4 中，所有数据都驻留在 PaaS 平台（如 Google App Engine）上，而且所有计算也

都在该平台上进行。应用及其工作负载需要根据服务提供商的容量来建立模型。

这种方式的主要优势是易于实现。前端的创建和管理都很简单，因为大多数 PaaS

提供商都会提供一些可用来监测和测算流量的 SDK 和工具。应用还可以利用一些平台

所固有的自动伸缩能力。

而这种方式的缺点是 ：为了迎合平台的具体限制和能力，通常需要将应用彻底重新

编写一遍。在某些情况下，还需要将那些计算密集型的任务分解为更小一些的子任

务。例如，App Engine 就对运行时间有一个不能超过 30 秒的限制，因此，必须将那

第 3 章　使 用 场 景　 　27

些负载较大的任务分解成子任务，然后使用 Task Queue API（任务队列 API）来管

理这些子任务。

展示 平台 信息

最终用户浏览器App Engine数据存储

数据收集程序

App Engine 任务队列

RESTful 数据馈送

计算任务

App Engine Python/Django

图 3-4 　纯 PaaS 平台

在编写代码时，我们还要考虑到 PaaS 服务也有停机的可能性。这次我们还是以 App

Engine 为例，Google 提供了一些专门的 API 调用来检测计划内的停机时间安排。应用

可以利用这些 API 调用来进行故障转移的准备，或者至少是将这些预计要停机的时间告

知给用户。

为可高度伸缩的数据建模也是件不小的苦差事。虽然 BigTable 和其他一些 noSQL

数据库都有保存海量数据集的能力，但简单的 key-value 存储不具备应用可能必须需要

的那些进行复杂查询和索引的能力。对于程序逻辑上的需要与速度和伸缩性方面的业务

需求之间的矛盾，我们需要进行平衡，这不仅并非无足轻重，而且还非常重要。

3.5　采用 IaaS 存储和计算的 PaaS 应用

最后一个是最激进的模型（如图 3-5 所示），其目的是在一个组合的架构中充分利用

PaaS（如 Google App Engine）和 IaaS（如 Amazon Web Services）各自的长处。这种方

28　 　第一部分　模　　型

式的思路是 ：使用 PaaS 组件来处理前端的伸缩性和可用性，这样就可以通过配额分配

来将流量限制在预算之内。那些存储和计算密集型的工作则可以由那些运行在 IaaS 上的

Hadoop 实例来完成，这样系统就可以以实例为基础进行规模上的伸缩。

展示 平台 信息

其他客户端

最终用户浏览器

RESTful API

App Engine数据存储

Twitter 数据馈送

Facebook数据馈送

其他数据馈送Rackspace

Hadoop

App EnginePython/DJango

Hadoop

图 3-5　采用 IaaS 存储和计算的 PaaS 应用

例如，假设有个运行在 App Engine 上、使用 Python 编写的 Web 应用，它会使用

本地数据库来存储那些与最终用户相关的数据。该服务在 Amazon 上实现的那一部分会

从第三方的数据提供商处收集数据，并将数据存储在一个运行在 AWS 上的 Hadoop File

System 文件系统中。

还有一个与那些数据收集程序相分离的 Hadoop 集群，它会运行专用的 map/reduce

算法来进行分析。（虽然本例强调了 Hadoop，但外部计算作业也可以是任何未在 PaaS

上优化过的东西。）在那些 map/reduce 作业完成之后，Hadoop 会通过一个 RESTful 的

Web 接口将结果提供给 App Engine 上的最终用户的应用。

第 3 章　使 用 场 景　 　29

3.6　实用注意事项

我们希望上述这些例子有助于说明在设计云计算应用的架构时可以考虑哪些选项。

在你进行选择时，应该考虑如下一些主要的因素：

你已经拥有了多少代码？

一方面，如果你已经拥有了那个想要在云中使用的应用，那么你可能应该考虑将它

重新定位在一个基础设施服务上，或使用一些基于云计算的等价功能来替代一些现有的

功能和存储，以这种方式来简单地增强它。另一方面，如果你是从头开始，或需要对你

的应用进行大改动，那么就值得考虑使用一个基于云计算的平台（如 Microsoft Azure 或

Google App Engine），这样你就可以从它们所能提供的固有的伸缩弹性中受益。

你有个什么样的应用，它对于基础设施的依赖如何？

如果你需要与其他一些应用相连，或者需要与一些物理基础设施交互，那么你就有

可能必须为至少其中一部分组件寻找在企业内部实施的方案。这并不意味着不能考虑云

计算。有一种方案是 ：将其中几个组件集中在一起，然后将它们迁移到外部。运营一个

外部部署的现成软件可能具有一些挑战性，但是如果使用的基础设施服务得当，这样做

肯定可行。

你的数据有多敏感？

对于高度机密的数据来说，公共云可能不是最佳选择。但你仍可以考虑一下混合式

的组合，即利用一些外部服务来实现一些不敏感的组件。或者，你也可以使用基于云计

算的存储服务，但一定要确保所有信息都经过了安全加密。如果数据敏感性不高，那么

只要在你仔细审查了具体产品之后，就可以放心地将数据委托给公共服务了。

应用需要多高的可伸缩性？

平台服务适合于中等程度的可伸缩性需求，因为它无须设置就能自动提供一定程度

的自动伸缩和负载均衡能力。但是，如果你需要保存一些规模极大的数据集，或者要跟

踪大量的用户，那么基础设施（或混合型）服务可能更能满足你的需要。同样，如果系

统的工作负载包含一些复杂的计算密集型任务，那么通过一组基础设施服务可能更有效

地分配和协调这些任务。

你的开发人员更喜欢什么？

30　 　第一部分　模　　型

平台和服务的选择会对可用的编程语言和工具产生重大的影响。如果你的团队是由

经验丰富的 Java 程序员所组成的，那么选择基于 Ruby、Python 或 C# 的平台可能就不

是最有效率的选择。许多开发人员都乐于接受尝试新东西的机会，但重要的是要考虑他

们在学习新东西时所要花费的时间和成本。

你有什么样的可用性要求？

最好要将计划内的检修停机与计划外停机区分开。对于计划内的检修停机，你有一

定的回旋余地，可以减轻它所造成的损失。而计划外停机的发生时间、持续时间和范围

则都不可预知。

如果你有很严格的需求，那么可以选择服务提供商所提供的优质 SLA，或者选择

自己来实现冗余和故障转移。然而，这些都会带来一些相关的成本，因此最要紧的是

了解更高的可用性要求在业务上有无正当的理由。在 3 个 9 和 10 个 9 的正常运行时间

之间只有不到 0.1% 的差别，所以，在你投资之前应该思考一下业务上的情景，不仅要

看到失去交易所损失的机会成本，还要看到其对于信誉、顾客满意度和第三方责任等

的影响。