专家：考察云平台 一种面向企业的观点

定义术语：什么是云平台？

转向云计算（cloud computing），是业界将要面临的一个重大改变。各种云平台（cloud platforms）的出现是该转变的最重要环节之一。顾名思义，这种平台允许开发者们或是将写好的程序放在“云”里运行，或是使用“云”里提供的服务，或二者皆是。至于这种平台的名称，现在我们可以听到不止一种称呼，比如按需平台（on-demand platform）、平台即服务（platform as a service，PaaS）等等。但无论称呼它什么，这种新的支持应用的方式有着巨大的潜力。
欲知个中缘由，我们先来看看目前应用平台（application platforms）是如何被使用的。开发团队在创建一个户内应用（on-premises application，即在机构内运行的应用）时，该应用所需的许多基础都已经事先存在了：操作系统为执行应用和访问存储等提供了基础支持；机构里的其他计算机提供了诸如远程存储之类的服务。倘若每创建一个户内应用都得首先构建所有这些基础的话，那么恐怕我们今天看到的应用会少很多。
同理，倘若每一个希望创建云应用（cloud application）的开发团队都得首先构建自己的云平台的话，那么我们今后看到的云应用将寥寥无几。幸运的是出现了一些致力于解决此问题的厂商，今天有很多云平台技术可供我们使用。本文的主旨即从企业应用创建者的角度来分类并简要介绍这些技术。

实际环境中的云平台：三种云服务

 

图1：云服务分为三大类
为掌握云平台，我们先从大体上考察一下云服务。如图1所示，我们可以把通过“云”提供的服务分为三大类。它们是：

/' target='_blank' style='font-size:14px;text-decoration:none;color: #0000FF;'>软件即服务（Software as a service，SaaS）：SaaS应用是完全在“云”里（也就是说，一个Internet服务提供商的服务器上）运行的。其户内客户端（on-premises client）通常是一个浏览器或其他简易客户端。Salesforce.com可能是当前最知名的SaaS应用，不过除此以外也有许多其他应用。
附着服务（Attached services）：每个户内应用（on-premises application）自身都有一定功能，它们可以不时地访问“云”里针对该应用提供的服务，以增强其功能。由于这些服务仅能为该特定应用所使用，所以可以认为它们是附着于该应用的。一个著名的消费级例子就是苹果公司的iTunes：其桌面应用可用于播放音乐等等，而附着服务令购买新的音频或视频内容成为可能。微软公司的Exchange托管服务是一个企业级例子，它可以为户内Exchange服务器增加基于“云”的垃圾邮件过滤、存档等服务。
 云平台（Cloud platforms）：云平台提供基于“云”的服务，供开发者创建应用时采用。你不必构建自己的基础，你完全可以依靠云平台来创建新的SaaS应用。如图1所示，云平台的直接用户是开发者，而不是最终用户。
要掌握云平台，首先要对这里“平台”的含义达成共识。一种普遍的想法，是将平台看成“任何为开发者创建应用提供服务的软件”。下一节，我们将对此作具体讲解。
应用平台的一般模型
我们今天对应用平台（application platform）的认识，主要来源于户内平台（on-premises platforms）。因此，一种思考云平台（cloud platforms）的方式，就是考察应用开发者在户内环境里所依赖的服务（services）是如何转变为“云（cloud）”的。图2显示的是一个适用于这两种环境的一般模型。

  

图2：可以认为现代应用平台包含三个部分

无论在户内环境、还是在“云”里，我们可以认为一个应用平台（application platform）包含以下三个部分：
 一个基础（foundation）：几乎所有应用都会用到一些在机器上运行的平台软件。各种支撑功能（如标准的库与存储，以及基本操作系统等）均属此部分。
一组基础设施服务（infrastructure services）：在现代分布式环境中，应用经常要用到由其他计算机提供的基本服务。比如提供远程存储服务、集成服务及身份管理服务等都是很常见的。
一套应用服务（application services）：随着越来越多的应用面向服务化，这些应用提供的功能可为新应用所使用。尽管这些应用主要是为最终用户提供服务的，但这同时也令它们成为应用平台的一部分。（也许你要奇怪，为什么要把别的应用视为平台的一部分，但在面向服务的世界里是这样的。）
虽然图2里没有绘出开发工具，但它们也是另一个重要部分。现代工具可以帮助开发者们运用应用平台的这三个部分来构建应用。
为了对这个抽象模型有具体的认识，下面我们将它与今天主流的户内平台加以对照。户内基础（on-premises foundation）包括有：
 操作系统（Operating system）：Windows、Linux及其它版本的Unix是主流选择。

 本地支持（Local support）：不同风格的应用采用不同的技术。例如，.NET框架和Java EE为Web应用等提供了一般性支持，而其它技术则面向特定类型的应用。比如Microsoft Dynamics 产品提供了一个为创建特定类型的商业应用而设计的平台。类似地，不同种类的存储被用于不同目的。Windows、Linux及其它操作系统里的文件系统提供了原始字节的存储功能，而各种数据库技术（比如Oracle DBMS、MySQL、Microsoft SQL Server及IBM DB2等）则提供了更加结构化的存储功能。
对于户内基础设施服务（on-premises infrastructure services），典型例子包括：
 存储（Storage）：跟基础里的存储一样，基础设施里的存储也分为多种风格。远程文件系统可以提供简单的面向字节的存储，而Microsoft SharePoint文档库可以提供更加结构化的远程存储服务。应用也可以远程访问数据库系统，从而能够访问其他种类的结构化存储。
 集成（Integration）：把机构内部的应用连接起来，通常要依赖于某种集成产品提供的远程服务。比如，消息队列（message queue）是一个简单的例子，IBM的WebSphere Process Server及微软的BizTalk Server等产品可用于更加复杂的场景。
 身份管理（Identity）：对许多分布式应用而言，提供身份信息是一个最基本的需求。常见的解决此问题的户内技术包括微软的Active Directory（活动目录）及其它LDAP（轻量级目录访问协议）服务器。
至于户内应用服务（on-premises application services），不同机构间差别很大。原因很简单：不同机构使用的是不同的应用，因而它们暴露的服务也五花八门。对于这些户内平台里的应用，一种思考方式是将它们分成两大类：
 套装软件（Packaged applications）：这包括像SAP、Oracle Applications、Microsoft Dynamics在内的许多商业软件，以及许许多多现成的产品。虽然不是所有套装软件都向其它应用暴露服务，但越来越多的套装软件是这么做的。
 定制应用（Custom applications）：许多机构对定制软件进行了大笔投资。随着这些应用逐渐将其功能以服务的形式暴露出来，它们也将成为户内应用平台的一部分。
照此描述，户内应用平台看起来好像挺复杂的。但实际上，它也是随着时间的发展而不断演化的。在计算技术的早期，应用平台只包含一个户内基础（比如IBM主机上的MVS和IMS）。到了八、九十年代，随着分布式计算的普及，户内基础设施服务也加入了进来（远程存储、集成和身份管理成为十分常见的服务）。时至今日，随着面向服务的应用的出现，户内应用服务也成为应用平台的一部分了。下一步发展是毫无疑问的，即在“云”里提供这三个部分。

从户内平台到云平台
上面那个一般模型描述的是户内平台，但它同时也可被用来考察云平台。另外，因为户内平台与云平台可以一同使用，所以理解它们如何一起工作也是十分重要的。图3展示了这幅崭新的画面。

 

图3：可以从同一个视角来考察户内平台和云平台，而且它们还能一同使用。
如图所示，正如户内应用（on-premises application）是构建于户内基础（on-premises foundation）之上的，云应用（cloud application）也可以构建于云基础（cloud foundation）之上。无论是户内环境、还是“云”里的基础设施与应用服务，均可为这两种应用所使用。户内平台为我们今天的应用提供支持，类似地，云平台为我们明天将构建的应用提供服务。

考察云平台
理解云平台，意味着要考察其各个部分：云基础（cloud foundation）、云基础设施（cloud infrastructure services）及云应用服务（cloud application services）。本节将以今天能看到的云平台技术为例，依次考察这三个部分。
在我们开始之前，有一个点需要注意：虽然是从同一个视角来考察户内平台与云平台的，但它们是两样不同的东西。随着平台功能转移到“云”里去，它们有时会发生重要改变。比如，户内平台顶多是用以支持企业级应用的；而运行在“云”里的应用则可以潜在地支持Internet规模，这要比企业应用处理更多并发请求。虽然也许这两种情况都需要同样的平台功能，但由于云平台对伸缩性的高要求，所以必须采取不同的方式来提供这些功能。下面，我们将看到“云”与户内环境的一些区别。
云基础（CLOUD FOUNDATION）
与户内基础（on-premises foundation）相似，云基础提供了应用所需的一些基本的本地功能，包括下层操作系统和本地支持。但正如下面将讲到的，云平台提供这些功能的方式跟我们所习惯的方式有所不同。
操作系统（Operating System）
以平台的观点来看，一个操作系统提供了一套基本接口，供各应用使用。目前最知名的一个云操作系统的例子就是Amazon的Elastic Compute Cloud（弹性计算云，简称EC2）。EC2为用户提供以虚拟机（VM）形式运行的专用Linux实例。从技术上看，将EC2视为一种虚拟机平台（而不是操作系统）更准确一点。尽管如此，由于开发者可以看到它提供的操作系统接口，所以不妨就把它视为操作系统。
各个开发团队可以自由随意使用虚拟机里提供的本地支持——Amazon不会管你。比如，有的应用创建者可能会采用Java EE和MySQL，有的会选择Ruby on Rails。EC2用户甚至可以随意创建多个Linux实例，然后将巨大的作业量（比如科学计算）并行分布在这些实例上运行。虽然EC2提供的服务非常基础，但同时也具有相当的一般性，因而可被用于多种不同方式。
本地支持（Local Support）
在户内平台（及EC2）里，开发者可以自由混合使用基础里的各个部分。比方说，选择采用基于Windows的.NET框架并不意味着必须采用特定的数据库。与此类似，一个采用.NET框架的户内应用可以自由访问下层的Windows操作系统，基于Java EE服务器构建的应用也是同样。
在今天主流的云基础里，本地支持功能不是这样的。相反，云本地支持技术一般都包含自己的存储，而且它隐蔽了下层操作系统的细节。开发者若选择基于特定的本地支持方案，那他就必须接受该方案施加的约束。
当然，施加这些约束是有充足理由的。云计算吸引人的一点就在于它在可伸缩性方面的潜力，但是，要令一个构建于云基础之上的应用能够处理Internet规模的工作量，就必须施加某种约束。通过使本地支持功能更加专业化，云平台提供商在优化应用环境时将有更大的自由。因此，现在云基础里的各种本地支持功能均专注于支持特定种类的应用。
例如，Google的AppEngine为运行Python Web应用提供了本地支持。除了标准的Python运行时环境，AppEngine还包含一个层次化的数据存储以及相应的查询语言。Force.com（由Salesforce.com提供）是另一个提供本地支持的云平台的例子。Force.com不是面向一般的Web应用的，相反，它用于创建面向数据的商业应用。为达到这个目的，它自己在提供数据存储支持时有自己明确的目标。而且，这个平台不是采用现有的编程语言，而是自己发明了一门叫做Apex的语言。
微软也在其 Live产品里为“云”里的应用提供本地支持。这项技术是基于前面提到的Dynamics 的，它跟Force.com差不多，也是以面向数据的商业应用为目标的。跟Force.com和AppEngine一样，它既包含运行时应用支持，也包含数据存储。微软说它们准备在此领域进一步大显身手：他们将提供一个支持标准.NET开发语言和工具的平台。微软说，其用意是允许应用与开发技能在户内基础与云基础之间相互移植。
云基础设施服务（CLOUD INFRASTRUCTURE SERVICES）
无论在户内环境里、还是在“云”里，有些应用只要有基础就够了。尽管如此，分布式存储、公共身份管理以及其他基础设施服务可以给许多应用带来好处。现在我们已经习惯于由户内环境提供这些服务了，但类似的服务也可以在“云”里提供。
正如图3所示，云基础设施服务既可以被运行在户内基础上的应用访问，也可被运行在云基础上的应用访问。最初，由于在云基础上构建的应用还不多，所以户内应用将成为云基础设施服务的主要用户。但随着时间的推移，这是会变化的，因为会有越来越多基于云的应用使用云基础设施服务。
存储（Storage）
应用使用某种本地存储是很普遍的，这就是为什么存储既属于户内基础、又属于云基础的原因。然而，正如存储服务在户内环境中很受欢迎一样，远程存储也很有用。因此，我们有理由预期，在“云”里提供存储服务将受到许多应用的欢迎。
跟户内平台一样，“云”里的远程存储也有不同的风格。例如，Amazon的Simple Storage Service（简单存储服务，简称S3）提供了基本的非结构化远程存储。它向开发者暴露的模型是简单明了的：对象（objects）就是保存在桶（buckets）里的一串字节。应用可以创建、读取、删除对象和桶。不过，对象不能被更新——你只能彻底替换之。平台服务必须为支持Internet规模访问而作出改变，Amazon就是一例，它非常注重这一点。相对于一个功能更齐备的存储服务而言，这一简单而受限的存储服务更易于实现可伸缩性。此处的权衡是显而易见的：应用开发者以较低的代价使用“云”里的存储，但他们得在自己的应用里做更多工作才能有效利用之。
实现云存储的另一条途径是支持更具结构化的数据。例如，在微软的SQL Server Data Services（SSDS）里，容器（container）包含若干个实体（entities），而各个实体具有一定数量的属性（properties）（如图4所示）。应用可以使用操作符（如==、!=、<、>、AND、OR及NOT等）对容器里的数据进行查询。

 
图4：在SQL Server Data Services里，一个容器里包含若干个具有属性的实体。

要注意的是：它不是一种关系型数据库，所以查询语言用的不是SQL。还是那句话，我们将看到当应用平台技术转移到“云”里去的时候将如何发生变化。这一更简单的做法比关系型数据库更容易使用——你不必事先定义好模式（schema）——而且也更容易实现可伸缩性。
Amazon的SimpleDB是另一个体现了“在‘云’里提供结构化存储”的价值的例子。SimpleDB组织信息的方式跟SSDS相似——它是一个由域（domains）、项（items）和值（values）构成的层次结构——而且它也提供了一个非SQL的查询语言。跟SSDS相似，它也不要求事先给出模式定义（schema definition），因此它实现了灵活性与可伸缩性兼顾。
集成（Integration）
有没有应用程序不跟任何其他应用打交道的？连接各个应用，已经成为计算领域的一个老生常谈的话题了，而厂商为进行集成已经提供了太多的户内基础设施服务。从相对简单的消息队列到十分复杂的集成服务器，均属此类。
随着集成服务转移到“云”里去，一系列技术也将随之出现。比如Amazon的Simple Queue Service（SQS）提供了一种简单的队列服务——它以一种直接的方式实现了“应用通过云中的队列交换消息”。不过SQS再次举例说明了“把一个熟悉的户内服务放到云里去”将出现的情况。由于SQS要在多个队列之间复制消息，所以应用未必能通过单次读取请求得到来自不同队列的消息。SQS也不承诺“按序单次”递送。这些简单化处理，使得Amazon可以为SQS实现更强的可伸缩性，但它们同时也意味着开发者不能按使用户内消息队列技术的方式来使用SQS。
BizTalk Services是另一个基于“云”的集成的例子。BizTalk Services不是使用消息队列，而是在“云”里实现了一个中继服务，令应用可以穿越防火墙进行通信。基于“云”的集成（比如连接来自不同机构的应用）一般要求有穿越防火墙的能力，因此解决此问题十分重要。BizTalk Services提供了一种方式，使得应用可以对自己所暴露的服务进行注册，并允许其他有权限的应用调用这些服务。另外，BizTalk Services还支持简单的工作流（workflow）。
将来，我们可以看到更多在“云”里提供的集成服务。考虑到集成在户内服务里的重要性，那么看到集成功能成为云基础设施的一部分也就不足为奇了。
身份管理（Identity）
无论一个应用是在户内环境、还是在“云”里运行，它通常都需要掌握有关它的用户的一些信息。为此，应用一般都会要求各个用户提供一个数字身份（digital identity），即一串描述该用户的字节。根据这些字节，应用便可以知道“该用户是谁”以及“他被允许做什么”了。
现在的许多户内应用都要依赖于一种户内基础设施服务（如Active Directory）来提供这种身份信息。然而，当用户访问一个云应用时，或者当户内应用访问一个云服务时，户内身份管理（on-premises identity）通常就不管用了。那基于云基础构建的应用怎么办呢？它从何处获取身份信息呢？
云身份管理服务可解决此问题。因为身份管理服务提供的数字身份可以被人、户内应用和云应用所使用，所以它适用于多种不同场景。实际上，从现存云身份管理服务的数量上便可得知其重要性了。比如，访问Amazon的云服务（如EC2或S2）时需要提供一个Amazon自定义的身份，使用Google AppEngine时也需要有一个Google帐户。微软提供的Windows Live ID可被用于访问微软的应用等，BizTalk Services也提供了自己的身份管理服务——它可以与其他身份管理服务进行联邦。虽然开发者没有绝对的自由（云平台经常是与特定的身份提供商捆绑的），但对身份管理这种云服务的需求是毫无疑问的。

云应用服务（CLOUD APPLICATION SERVICES）
应用服务（application service）与基础设施服务（infrastructure service）的区别在哪儿呢？为了回答这一问题，我们先考虑应用与基础设施之间的显著区别：应用是供人类使用的；而基础设施是供应用使用的。也可以这么说：基础设施通常提供的是一般性的、较低层次的服务；而应用提供的是具体的、较高层次的服务。基础设施服务要解决的，是各种不同应用碰到的广泛的问题；而应用服务所要解决的，是较为具体的问题。而且，正如同基础设施可以区分不同种类一样，应用服务也可以分为不同种类。本节将讲述不同种类的应用服务。

SaaS应用服务（SaaS Application Services）
现在，大多数企业既依赖于外部购买的应用，又依赖于自己内部开发的应用。随着这些应用将其功能以服务的形式暴露出来、供远程服务使用，它们成为了户内应用平台的一部分。同样，今天的SaaS应用常常将其服务暴露出来，供户内应用或其他云应用使用。例如，Salesforce.com的应用提供了各式各样的服务，这些服务可以与户内应用的功能整合起来。随着各个机构开始创建自己的、在云基础之上运行的SaaS应用，那些应用也将暴露服务。正如现在套装/定制的户内应用是户内平台的一部分，套装/定制SaaS应用暴露的服务正逐渐成为云平台的一部分。

搜索（Search）
虽然SaaS应用暴露的服务很有用，但那并不代表全部。其他种类的云应用服务也很重要。比如Google、Live Search等搜索引擎。这些搜索引擎对人类有很大帮助，但与此同时，它们为何不能提供云应用服务呢？
当然，它们可以提供。比如微软的Live Search就暴露了这样的服务，户内应用和云应用都可以向它提交搜索，并得到搜索结果。设想有个提供法律信息数据库的公司，它想让客户用一个请求就可以在自己及Web上的数据里进行搜索。它完全可以这样做：创建一个户内应用，该应用既在自己的私有数据里搜索，又通过Live Search应用服务在整个Web上搜索。客观地讲，需要这种服务的应用不会很多，但正因如此，将搜索视为一种应用服务、而不是基础设施服务是恰当的。
地图（Mapping）
如今许多Web应用都有显示地图的功能。各个酒店网站要绘制自己的位置，零售商们要提供店铺寻找功能，等等。而这些应用的创建者们多半没有时间、兴趣或预算来构建自己的地图数据库。既然有这么多应用都需要这种功能，那么创建一个提供地图功能的云应用服务是合理的。
Google Maps及微软的Virtual Earth等地图服务因此应运而生。它们都提供基于“云”的服务，应用开发者可以利用它们在网页或其他地方嵌入地图。跟搜索一样，这些地图服务是附属于那些直接面向用户的网站的，也就是说，它们是云计算服务。
其他应用服务
现在，还有许许多多的其他应用服务可以使用。实际上，几乎任何网站都可以将其功能暴露为云服务，以供开发者们使用。例如，Google的Picasa和微软的Windows Live Photo Gallery等相片分享网站就是这样做的，还有Google Contacts和微软的Windows Live Contacts等在线通讯录应用亦是如此。暴露服务的初衷是为了便于创建mashups，以利用不同Web应用提供的功能。
厂商有时会把一些云应用服务汇聚于一处。例如，你可以通过Google Data APIs来访问Google Contacts、Picasa等服务。类似，微软通过Live Platform来提供Live Search、Virtual Earth、Windows Live Contacts、Windows Live ID、Windows Live Alerts及Application-Based Storage等服务。
云基础设施服务（cloud infrastructure services）与云应用服务（ cloud application services）之间的界线有时是比较模糊的。比如，通用的云存储服务（如S3和SSDS）就明显属于基础设施，云身份管理服务亦同。像Google Earth这样的地图服务就明显是针对应用的——只有某些种类的应用需要它——Live Search亦同。不过，尽管Windows Live Alerts和Windows Live ID均被微软纳入其Live Platform，但Windows Live ID肯定是基础设施，而Windows Live Alerts服务也可被视为是基础设施，因为它的功能更具一般性。
云平台是相对较新的领域，所以为它定义一个稳定的分类是相当有难度的，这个不用奇怪。不管你如何看待它们，云应用服务承担着重要的角色，这一点是肯定的。对于现在所有的软件设计者与构建者来说，了解云里有哪些东西可为我们所用是一种核心竞争力。

总结
新应用平台的出现是不会频繁发生的。但平台方面一旦有成功的革新出现，它势必会产生巨大的影响。比如个人计算机和服务器给主机和小型机世界带来的震感，再如多层应用平台的出现对软件编写方式产生的影响。虽然旧的世界不会立即消失，但新的方法可以迅速成为新应用关注的中心。
云平台还不能提供户内环境的所有功能。比如，在云平台里就很少见，对业务流程管理技术（如完备的工作流与规则引擎）的支持也不多。不过，随着这一轮技术潮流的发展，情况是肯定会发生改变的。
云平台目前还没有成为所有人关注的中心。不过，很可能5年内（从现在算起）情况就会发生转变。云计算在可伸缩性和低成本方面的魅力是确确实实的。无论你是为软件提供商、还是为最终用户工作，只要你的工作跟应用开发相关，你会看到，将来“云”的角色将越来越重要，它将成为下一代应用平台。