探究云计算以及 Amazon、Google、Microsoft® 及 SalesForce.com 这几家主要供应商所提供的各种云平台。在这个由三个部分组成的系列文章的第 1 部分中，我们会给出一个典型的使用 JMS 队列的企业应用程序示例，并研究在云中结合使用此 JMS 基础设施的一部分时将会涉及到哪些内容。

简介

       多年来，在网络图中，我们已经习惯于使用一个云（特别是积雨云）来表示 Internet。云状图像常被用来表示无固定形状的、不清晰但又必须包含在图表中的一些内容。而网络上的线惟一的作用就是穿过云以表示数据通过 Internet。在以安全性为中心的图表上，这条穿过云的线可能还会在旁边多出一个挂锁以表示这个连接是安全的。

常用缩略词 Ajax: Asynchronous JavaScript + XML API: 应用程序编程接口（application programming interface） HTML: 超文本标记语言（Hypertext Markup Language） HTTP: 超文本传输协议（Hypertext Transfer Protocol） JMS: Java™ 消息服务（Java™Message Service） REST: 具象状态传输（Representational State Transfer） XML: 可扩展标记语言（Extensible Markup Language）

       现在云已经在网络图中扮演着主要角色。应用程序可以利用云来调用所添加的值，比如存储、队列及宿主应用程序。应用程序本身也可以被托管在云上。现在的线已不再是简单地穿过云，而是连接到云并将云用作应用程序的一部分。这就使云有了更实际的意义。

       在这个由三个部分组成的系列文章中，我们将探究云计算的方方面面。云计算的提供商相对较少，每个提供商着眼于不同的方向并提供不同的服务。编程语言各异，从 Python 到 C#、再到 Java 或其他的专有语言。与云的接口也各不相同，虽然轻量的 REST 接口是首选，但现在并不是每个云计算提供商都提供这种接口。

       在本系列的第 1 部分，我们将着重研究一个混合示例，一个使用云计算服务和基础设施进行增强了的专用应用程序。通过研究这个混合应用程序，了解云计算的功用。为此，您需要探究它的渊源、云计算的主要提供商目前所能提供的功能。本系列的第 2 部分将会涵盖在第 1 部分中设计的这个混合应用程序的开发。第 3 部分将着重介绍此解决方案在安全性和管理方面的问题。

云计算究竟是什么？

       IBM 将云计算定义为一个新兴的计算范型，在这个范型中，数据和服务位于可大规模伸缩的数据中心中，并可被 Internet 上的任何连接设备随时访问。它为应用程序提供了可观的伸缩能力（在使用 Amazon Elastic Computing Cloud 的情况下 — 通常被称为 Amazon EC2），并能托管应用程序自身。

       云计算并不适合所有的情形，但是对于一个在不同时期需要不同计算能力的组织来说，云是很有吸引力的。如果一个组织对处理和存储能力的要求是不均衡的，比如每周六的午夜进行批处理，那么此时与其采用一个大多数时间都空闲的数据中心，到不如使用云更有意义。

       云计算也特别适合于那些刚刚起步的公司。这些公司的创业者对投资资本家提出的问题恐怕都不会陌生，即 “您的技术如何伸缩？”云计算是对此问题的一个很好的答案。然而，正如您在本系列后面的部分看到的，云计算也带来了所有权、安全与成本方面的问题。

云的形成

       在云计算得到广泛应用之前，我们使用的是网格计算与效用计算。网格计算与云计算的主要区别就是网格计算环境多是由不同的机器组成的，而云计算环境则更加可控制，后端机器通常都是相同的。效用计算是指按数据流量或应用程序的使用支付费用的一种业务模型。服务的 “弹性” 增长的概念也没有现在这么盛行，而随着使用的改变而相应增加（或减少）容量的能力却是云计算的一个重要部分。

       从 2000 年初到 2000 年中，Google 和 Amazon 各自独立开发了自己的云计算架构以便在其上运行各自的业务。开发了这种基础设施后，二者发现他们自已的基础设施本身成为了一个服务，可以按照每次的使用量卖给开发人员。Amazon 更是意识到了其平台中的关键价值，以至于它完全相信有一天 Amazon 将会因其计算平台而再次名扬天下，一如它的在线零售网站一样。Amazon 认识到它可以以服务的形式出售其平台（即 Platform as a Service，缩写为 PaaS — 与 Software as a Service 即 SaaS 类似）。因此，Amazon 常被视为是云计算商业化方面的领跑者，在计费和使用模型方面尤为突出。

       在基于云的计算环境的设计方面堪称专业的成功供应商为数不多，其中包括 Amazon 和 Google。认识到这一点，Google、IBM 和几所大学组建了一个 research cloud 来为从事云计算研究的学生提供一个云计算环境以便开发新的云计算技术与应用程序。尽管其规模不能与 Amazon 与 Google 的基础设施相提并论，但此项目还是为学生研究云服务提供了一个很好的环境。来自此项目的研究成果将会有助于对云计算进行更进一步的开发，比如有创建条件的组织可以在其基础上开发专用云。

混合模型应运而生

       放弃所有本地应用程序而只使用云，或相反地，只依靠本地应用程序而忽略云，都不是明智之举，现在最流行的办法是将本地应用程序与云相结合使用。即所谓的混合模型。这就让一个公司在必要的时候使用云计算，而同时又能保持它对其关键应用程序的控制。例如，很多公司已经发现，使用 Amazon 的 Simple Storage Service (S3) 存储图片、视频或文档等会更经济。混合模型也有助于增量方法。

       即使您认为将大部分甚至全部的应用程序都转向云更有意义，但是也不建议您这么做，因为一次性完成这样的转移风险太大。借助混合模型，可以先将容易的东西（比如文件存储）转向云。然后在您适应了这种部署模型后，再将应用程序更重要的部分转向云。这也是我在本系列中所采用的方式。接下来，让我们先看一下这个通过转移部分基础设施实现混合的应用程序。

设计一个混合应用程序

       这个示例混合应用程序是一个异步的电子邮件通知系统。它可以是一个工作流系统中的一个子系统。当一个新行为被提交并等待批准时，就会向能够做出批准或拒绝决定的主体发送电子邮件。这种系统可以用于一个履行订单的系统中。当订单货物运出时，就会发出一个电子邮件以通知相关的人订单在货运途中。不难想象，在很多种应用程序中都可以使用到这个系统。电子邮件在本质上是异步的，所以能生成电子邮件的异步机制是满足此类用例的一种有效途径。

       假设有一个现成的应用程序，在此应用程序的某个位置已经具有了这种系统，可以使用很多种方法实现此类系统，但一个相对优雅的方式是使用一个 JMS。JMS 规范是 J2EE™ 技术栈的一个重要部分。目前，针对此标准已经有很多专有或开源的实现。很容易想像有这样一个系统，它向一个 JMS 队列发送通知，而另外一个系统对这个 JMS 队列进行周期性地读取并为每个消息生成电子邮件提醒。

       对于一个混合模型，可以先将这个 JMS 队列转移到云。换句话说，就是用在云中运行的一个服务来替代它。这是一种什么样的服务呢？如何更改应用程序以使其与此服务进行交互呢？这取决于所使用的云平台。接下来，我们来看一下各种平台及怎样使用这些平台来实现或像本例一样重新实现一个 JMS 队列的功能性。

Amazon Web Services

       作为一个商业化云计算的先躯，Amazon 提供了一系列开发人员感兴趣的成熟服务。Amazon 最知名的云服务莫过于 EC2 (Elastic Computing Cloud) 服务。它允许构建可在 Amazon 自已的基础设施上运行的虚拟机实例（被称为 AMI — Amazon Machine Images）。也许有人会说，除了使用的不是真实的计算机以及基于流量使用收费而非收取机器的租赁费之外，EC2 更接近于托管提供商的一项服务。

       Amazon 的 S3 服务是一个在线存储服务，对于需要扩展存储能力的新起步的那些公司来说尤其具有引吸力。它可用作其他 Amazon 云服务（比如 EC2）的一个附件。这就意味着一个 AMI ，或是一个运行着 PHP 的 Linux™ 计算机，可以使用 Amazon S3 作为它的数据存储。随着数据流量的增长，S3 服??也会弹性扩展。Amazon 的 SimpleDB 是一个基于云的快速而简单的数据库，它可以提供索引、存储及访问。很显然，它比功能完善的关系数据库要简单很多，因为它不需要模式，它可以自动地索引数据，并提供了 API 用于存储及访问。

       Amazon 的 SQS (Simple Queue Service) 提供了一个队列服务，类似于 JMS，但有一个 RESTful 接口。您也可以将 SQS 与 Amazon 的其他云服务联合使用，也可以将它作为任何一个可用简单的 HTTP GET 或 POST 连接到它的应用程序的一部分使用。对于这个混合应用程序，它是 JMS 队列的一个很好的替代品。它可以通过它的 RESTful 的 XML 接口访问到，可以方便地与一个现有应用程序集成。SQS 可能是这类混合应用程序的最为直接的选择。

       很多软件提供商都与 Amazon 有过合作以帮助其客户充分利用 EC2。例如，IBM 和 Amazon 合作开发了 IBM 的很多最受欢迎的企业软件，比如 EC2 上的 DB2®、Informix® 及 WebSphere®。

Google

       Google 因其快速而准确的搜索而闻名，对于很多用户来说，它都是 Arthur C Clarke 的名言 “任何足够先进的技术都与魔法没有区别” 的最好的体现。由于是技术将魔法变成了现实，因此 Google 是提供云计算平台的最佳之选。在 Google 的平台上运行应用程序的美好前景让开发人员无比兴奋，这完全可以理解。

       Google 提供了一个名为 App Engine 的云计算平台，它基于的是 Google 早就建立起来的底层平台。这个平台包括 GFS（Google File System）和 Bigtable（构建于 GFS 之上的数据库系统）。Google App Engine 内的编程采用的是 Python。程序员用 Python 编写应用程序，然后再在 App Engine 框架上运行。除 Python 外的其他语言在将来也会得到支持。出于开发的需要，可以下载 App Engine 环境的一个本地仿真程序。App Engine 可免费使用并且包括多达 500 MB 的存储及足够的 CPU 带宽来满足每天 5 百万次页面浏览。

       Google App Engine 提供了一些有用的基础设施，比如源自 GFS 的数据存储和一个 memcache 实现。然而，它并不提供开箱即用的排队机制。不过，有了这样一个纯 Python 的编程环境，就可以在 App Engine 之上很容易地创建您自已的 JMS 替代。这个数据存储很适合于混合应用程序，并且只需很少的 Python 编程就可以打造出一个面向您的队列的 RESTful 式接口。

Microsoft Azure

       正如您所期望的，Windows® 和 .NET 是 Windows Azure 的主要特点。Microsoft 已经提供了一个开发环境，在这个环境中，用 Visual Studio® 编写的应用程序可以被托管于 Windows Azure 环境并在其上运行。Azure 平台提供了很多服务，比如像用于文件存储与数据访问的面向基础设施的服务，同时也提供了更为专用的服务，比如搜索和联系人管理。它还包括了 NET Service Bus。这是典型的 Enterprise Service Bus (ESB) 设计模式的 Microsoft 实现。ESB 最简单的用法之一就是消息队列，它完全可以充当 JSM 队列的替代。NET Service Bus 还是开发者友好的。它既支持使用 XML 的轻量的 RESTful 接口，也支持较重量的、包括了 WS-* 标准全部实现的基于 SOAP 的接口。这两个接口均支持现有应用程序和 NET Service Bus 间的简便的互操作性。

SalesForce.com

       SalesForce.com 提供了一个模型，借助这个模型，开发人员可以使用其 Apex 开发语言来访问 SalesForce.com 服务。SalesForce 称 Apex 是 “世界上第一个随需应变的编程语言”。 随需应变主要表现在 Apex 代码托管于 SalesForce 的 Force.com 云服务，并在该上下文运行。在句法方面，Apex 与 Java 或 C# 语言类似。

       Apex 代码被用来生成服务于 VisualForce 层的 Web 页面，该层就是实际的用户界面。它也使用了 Model-View-Controller (MVC) 模型。这非常类似于 .NET 中借助 C# 生成 ASPX 页面。这些 VisualForce 页面可以包含 HTML、Ajax（XMLHttpRequest 对象）及 Adobe Flex。

       VisualForce 允许开发人员在 SalesForce.com Web 界面上创建不同的变体。这对于喜欢 SalesForce.com 但又想向其添加功能的公司来说十分有用。与其要求 SalesForce.com 构建这种功能性，不如让 Salesforce.com 的用户通过创建 VisualForce 页面并用 Apex 代码将它们写入 SalesForce.com 后端来实现同样的目的。

       Salesforce 还提供了控制器，用来连接页面表示与来自 SalesForce 数据库的底层数据，包括如 Edit 或 Save 这样的标准的例程。Force.com 云实现了巨大的成功。它不仅为开发人员提供了在云上构建应用程序的方法，借助它，还可以通过直接发行模型来向用户收取这些应用程序的使用费用。然而，它是一个非常专门化的云。它并不太适合增量方法。通常需要对 Force.com 云进行构建。

结束语

       在本文中，我们了解了不同的云服务提供商能为我们带来的各种功能，另外还学习了如何使用这些云服务来代替 JMS 队列以及如何将一个现有的应用程序转变成一个混合的云应用程序。在接下来的两篇文章中，我们将了解绑定本地应用程序与云服务的这个混合模型是如何实现的。我们还将研究能够影响云计算的安全与管理方面的重要问题。