集成 Windows Azure：适用于企业的 Windows Azure 平台

核心提示：事实证明，云计算值得受到成熟企业及新企业的关注，集成 Windows Azure：适用于企业的 Windows Azure 平台，大多数企业对云计算的关注不仅仅是出于随意的好奇，到撰写本文时为止，根据带宽、存储使用量和计算周期对订阅者按月度计费周期收费，Windows Azure 平台附带构建企业级应用程序和服务所必需

事实证明，云计算值得受到成熟企业及新企业的关注。大多数企业对云计算的关注不仅仅是出于随意的好奇。到撰写本文时为止，IT 市场研究表明，大多数企业 IT 经理有足够的资源采用云计算并将其与内部部署的 IT 功能相结合。

当然，也有人怀疑云计算不具备所号称的功能。这一新兴解决方案与 ARPANET（Internet 的前身）的出现如出一辙，当时很多持怀疑态度的研究机构因担心丢失私有数据而拒绝加入最初的网络。科学家们看到数据网络及由此实现的协作所具备的优势之后，义无反顾地将这项工作进行下去，后来的事可以说是众人皆知了。当今的大型企业，像当初 ARPANET 的怀疑者一样，正在开始认识在获取和使用计算功能的方式上发生的模式变化。

考虑到行业趋势和客户需求，Microsoft 花巨资投入云计算，发布了 Windows Azure 平台，并提供必要的支持服务，以便在云中构建和运行行业支持服务。在本文中，我将从体系结构层面讨论 Windows Azure 平台，其中会穿插介绍企业级解决方案的需求。

云计算

云计算有好几个定义，我认为最准确的定义是：通过 Internet 标准和协议以实用工具形式提供的计算功能。这个定义引出了“公共云”和“私有云”的概念。顾名思义，公共云面向全部信用卡持有人。私有云专用于由私有云任务陈述所指定的企业或企业联盟。

Windows Azure 平台、Amazon Web Services、Google App Engine 和 Force.com 等都是公共云。大型企业运行的任何私有数据中心若具有以下特征，即可称为私有云：利用由更广泛的虚拟化所支持的统一资源模型，该模型将计算、存储和网络视为一个同构资源池；利用高度自动化的过程来操作系统。

实用工具计算是计算机自动化领域由来已久的梦想。 Microsoft 的 Dynamic Systems Initiative (DSI) 和其他供应商提出的类似方案进行了大胆的尝试，帮助数据中心操作员实现类似于实用工具的特性：高度自动化、自我管理、自我优化、计量存储、网络和计算周期。这个梦想值得称赞，它取得了综合性的成功。虚拟化的出现，使实用工具计算成为现实。虚拟化有助于操作系统和应用程序与物理硬件的分离。虚拟化将操作系统和应用程序视为数据，因此可开发出自动化过程，将操作系统和其他相关资源以流的形式按需传输到目标硬件。

为便于讨论 Windows Azure 平台，我将简单介绍一下云计算领域的行业术语，并以 Windows Azure 平台为例说明这些术语，这样更易于理解。图 1 是一个三层的行业术语图，以及与 Windows Azure 平台的对应关系。在下面几节中，将详细讨论各个云服务类型及其相对差异。

图 1 Windows Azure 平台是一种 PaaS 产品

软件即服务

软件即服务 (SaaS) 是一种软件交付业务模型，由供应商或第三方承载应用程序，提供给订阅该程序的客户使用。SaaS 客户通过付费后使用的方式使用供应商的基础结构上运行的软件。无需预付资金，客户不必签订任何长期合同。

按照合同条款，客户可以随时选择停用软件。底层基础结构和软件配置对于用户是不可见的，因此，客户必须原样接受这种即开即用的功能。SaaS 使用一种可容纳很多用户的体系结构，在运行时或非运行时，用户上下文在逻辑上是彼此独立的。

这种多用户功能可能不适合某些公司的业务性质，因此供应商可能会为这些客户提供物理独立的基础结构，并向其收取额外费用以进行相关软硬件维护。 Microsoft Business Productivity Online Suite (BPOS) 和 CRM Online 是 SaaS 的典型示例。Microsoft 也为这类服务提供专门的承载服务，并对此额外收费。

在 SaaS 领域，为很多企业解决这一问题的协作应用程序颇为成功。因为软硬件配置对于最终用户是透明的，所以几乎无需 IT 专业人员介入。最终用户可通过配置自定义某些 SaaS 应用程序，不过，大多数此类应用程序是不允许自定义的。因此，最大程度减少了 SaaS 应用程序环境中的开发人员数量。

SaaS 可以缩短应用程序上市时间，还可以在上市过程中修复经常遭到抱怨的业务- IT 一致性问题。在企业采用 SaaS 的早期阶段，“影子 IT”（例如由附加到业务单元、精通电子表格的程序员组成的小型团队）分散了整个企业的方案，成为企业架构师的噩梦。这是因为 SaaS 使业务单元避开了 IT 采购过程。企业基础结构团队需要认识到这一点，并使业务单元认识到管理的重要性。他们还应设计新的管理流程，或修改现有流程，以适应 SaaS。　

在当前 IT 环境下，由于 IT 投资负担过重，中小企业可能尚不具备以最佳状态运行业务的必要能力。SaaS 可以为每个公司提供目前只有大型企业才能实现的 IT 功能类型。因为 SaaS 不需要巨额 IT 投资，所以可为小公司提供公平竞争的环境，使其拥有企业级 IT 功能。

从服务供应商的角度看，任何小型公司都可以成为 SaaS 供应商与大型软件公司竞争。现在，这些公司可以专注发展其核心领域优势，而不必将有限的资金用于购买和管理软硬件基础结构。　

平台即服务

SaaS 似乎可以满足公司的所有软件需求。然而，各公司的技术现状及其特定业务领域并不相同，因此，每个公司都有独特的 IT 特征。要找到适用于所有业务线需求的 SaaS 服务通常是不可能的，因此各公司需要进一步构建应用程序。对于希望以服务方式构建和运行自定义应用程序的客户，平台即服务 (PaaS) 可满足他们的需求。这些客户包括 ISV、增值服务供应商、企业 IT 商店以及其他所有需要自定义应用程序的客户。PaaS 提供托管应用程序服务器，这些服务器依靠大型资源池，具有几乎无限的可扩展性。PaaS 还为完整的平台提供必要的支持服务，如存储、安全、集成基础结构和开发工具。

服务供应商提供一个预配置的虚拟化应用程序服务器环境，开发人员可将应用程序部署到该环境。因为由服务供应商管理硬件（修补、升级等）及应用程序服务器的运行时间，最大程度减少了 IT 专业人员的参与。开发人员构建应用程序，并使用资源描述符对其进行注释。进行部署时，配置引擎将描述符中声明的必要基础结构功能绑定到应用程序。资源可能包括网络端点、负载平衡器、CPU 核、内存和软件依赖关系。按需可扩展性与硬件和应用程序服务器管理相结合，开发人员无需关注基础结构，只需专注于应用程序的构建。PaaS 通常适用于全新的应用程序，现有应用程序通常需要进行大规模重构才能符合沙箱规则。

基础结构即服务

基础结构即服务 (IaaS) 与传统的承载类似，企业使用承载环境作为内部部署数据中心的逻辑扩展。根据需要租用服务器（物理服务器和虚拟服务器），管理基础结构的 IT 专业人员完全控制软件配置。某些供应商甚至允许灵活配置硬件，这种服务比相应的 PaaS 产品昂贵。

软件构成包括操作系统、应用程序平台、中间件、数据库服务器、企业服务总线、第三方组件和框架，以及管理和监控软件。因为可以自由选择应用程序服务器，所以也可以灵活选择开发工具。这种灵活性增加了 IT 环境的复杂性，这是因为客户的 IT 专业人员需要像维护内部部署的服务器一样维护这些服务器。维护活动包括修补和升级操作系统和应用程序服务器、进行负载平衡、数据库服务器的故障转移群集、备份和恢复，以及用于减少软硬件故障的其他活动。

开发人员在构建、测试和部署应用程序时，要充分了解服务器的软硬件配置。通常，客户自己负责灾难恢复和保持业务连续性。IaaS 一个重要优势在于允许从原有应用程序迁移到云。因为 IaaS 可以灵活构建任何配置，所以在云供应商之间移植应用程序较为困难。原有应用程序迁移是 IaaS 的最大优势，因为这样可以在云中模拟公司基础结构。利用 IaaS 的灵活性，还可以实现需要对软件配置进行大量控制的新应用程序。例如，某些应用程序可能需要安装第三方库和服务，而 IaaS 对此不进行限制。　　

Windows Azure 平台具有 PaaS 的所有优点，同时具有与 IaaS 一样的灵活性，如图 1 所示。Windows Azure 平台将大型计算池（商用服务器）、网络和存储资源集成到实用工具计算环境，在该环境中，客户可以按需取用资源，并按实际使用情况付款。作为典型的云环境，Windows Azure 平台帮助客户避免预付资金，根据需要增加 IT 功能。

Windows Azure 平台：

Windows Azure 平台提供托管应用程序服务器和必要的存储、网络和集成基础结构，用于构建和运行 Windows 应用程序。Windows Azure 平台依赖大型商用硬件池创建实用工具计算环境。图 2 是 Windows Azure 平台资源模型，该模型使用在部署时设置的配置策略，根据需要部署虚拟化存储、网络和计算资源。Fabric Controller 是整个生态系统的中枢，包含一组不属于应用程序资源池的专用资源。Fabric Controller 不会出现故障，所以它提供了高冗余的软硬件环境。

图 2 计算基础结构的概念视图（Windows Azure 设置可能有所不同）

计算资源池由商用资源组成，这些资源由 Fabric Controller 提供容错功能。Fabric Controller 的架构适用于在早期检测应用程序故障，它可以生成附加实例，以满足合同要求的服务级别协议。Windows Azure 环境是用于承载应用程序的完整平台，它通过按需配置提供几乎无限的资源，确保应用程序的系统质量。未使用的资源会返回池中，从而提高了利用率。资源包括计算周期、用于持久保存的虚拟化存储，以及用于动态重新配置私有和公共网络路由的虚拟化网络资源。这些资源的物理配置设计为对应用程序架构师和开发人员不可见。

那么，应用程序所有者如何配置这些资源？当然可以像在传统内部部署环境中一样致电 IT 专业人员，规模巨大的 Windows Azure 平台数据中心由一组专业人员主要依靠自动化过程进行管理。数据中心的一般日常操作不需要人工参与。使用 Windows Azure 平台，应用程序所有者可通过包含资源描述符的计算机可读模型配置必要的资源。在 Windows Azure 平台中，这些资源描述符称为服务模型。这些服务模型指定必要的应用程序资源及其依赖关系，以便在无人参与的情况下配置完整的运行时基础结构。由于实现了自动化，应用程序基础结构的配置时间通常不到五分钟。将这种方式与典型内部部署环境的购置后配置的方法相比较，可以了解云计算的强大功能。

计算

Windows Azure 平台的计算部件负责提供执行应用程序的 CPU 周期。应用程序承载在虚拟环境中，以免底层操作系统和硬件产生任何物理相关性。虚拟化资源实现了应用程序的去耦合，这些资源包括本地文件、持久存储（结构化和非结构化）以及诊断和检测资源。承载环境作为虚拟机实现，因此任何应用程序故障都不会影响其物理硬件上运行的其他应用程序。

应用程序以程序包（包含角色、关联可执行代码和资源）的形式部署到 Windows Azure 平台。Azure 角色以声明方式描述承载环境的特点。激活部署的应用程序时，Azure 配置环境对服务模型进行分析，根据角色类型选择预配置的虚拟机 (VM) 映像，将应用程序位复制到 VM 中，启动计算机并启动必要的应用程序服务。图 3 中的服务定义表示一个“购物列表”应用程序，本文将使用该应用程序作为参考。

图 3 Web 角色和工作者角色的服务模型

ShoppingListService 定义

<?xml　version="1.0"　encoding="utf-8"?>　
<ServiceDefinition　name="ShoppingList">　
<WebRole　name="ShoppingList_WebRole">　
<LocalResources>　
<LocalStorage　name="ShoppoingList_ImageCache"　sizeInMB="100"　
cleanOnRoleRecycle="false"/>　
</LocalResources>　
<InputEndpoints>　
<InputEndpoint　name="HttpIn"　protocol="http"　port="80"　/>　
<InputEndpoint　name="HttpsIn"　protocol="https"　port="443"　/>　
</InputEndpoints>　
<ConfigurationSettings>　
<Setting　name="DiagnosticsConnectionString"　/>　
<Setting　name="DataConnectionString"　/>　
<Setting　name="ShoppinglistOut"/>　
</ConfigurationSettings>　
</　WebRole>　
<　WorkerRole　name="ShoppingList_WorkerRole">　
<Instances　count="2"　/>　
<ConfigurationSettings>　
<Setting　name="DiagnosticsConnectionString"　/>　
<Setting　name="DataConnectionString"　/>　
<Setting　name="ShoppinglistIn"/>　
</ConfigurationSettings>　
<　WorkerRole　/>　
</ServiceDefinition>

ShoppingListService 配置

<?xml　version="1.0"?>　
<ServiceConfiguration　serviceName="ShoppingList">　
</Role>　
<Role　name="ShoppingList_WebRole">　
<Instances　count="3"　/>　
<ConfigurationSettings>　
<Setting　name="DiagnosticsConnectionString"　value=　
　　　　　　　"UseDevelopmentStorage=true"　/>　
<!--　flip　the　commenting　of　the　following　two　lines　for　application　
storage　needs　on　local　dev　fabric　-->　
<!--<Setting　name="DataConnectionString"　value=　
　　　　　　　　　"UseDevelopmentStorage=true"　/>-->　
<Setting　name="DataConnectionString"　
value="DefaultEndpointsProtocol=http;　
AccountName=<<account　name>>;AccountKey=<<account　key>>"　/>　
<Setting　name="ShoppinglistOut"　value="shoppinglistq"/>　
</ConfigurationSettings>　
</Role>　
<Role　name="ShoppingList_WorkerRole">　
<Instances　count="2"　/>　
<ConfigurationSettings>　
<Setting　name="DiagnosticsConnectionString"　value=　
　　　　　　　"UseDevelopmentStorage=true"　/>　
<!--　flip　the　commenting　of　the　followign　two　lines　for　local　dev　fabric　-->　
<!--<Setting　name="DataConnectionString"　value=　
　　　　　　　　　"UseDevelopmentStorage=true"　/>-->　
<Setting　name="DataConnectionString"　
value="DefaultEndpointsProtocol=http;　
AccountName=<<account　name>>;AccountKey=<<account　key>>"　/>　
<Setting　name="ShoppinglistIn"　value="shoppinglistq"/>　
</ConfigurationSettings>　
</Role></ServiceConfiguration>

图 3 中的“购物列表”应用程序需要三个 Web 角色实例和两个工作者角色实例。传入多个 Web 角色实例的 Web 通信自动进行负载平衡，并且三个实例全部按照服务模型描述对 SSL 和 HTTP 端点进行配置。为避免应用程序发生整体故障，Fabric Controller 在多个故障域分散进行分配。实际的故障域组织比图 2 所示的简化视图复杂很多。为简单起见，可将每个服务器机架、与之关联的网络交换机，以及电源视为一个故障域。

如图 2 所示，Fabric Controller 最初从每个故障域（机架 #1、#3 和 #n）分配一个 Web 角色。我将通过几个假定的事件来讨论整个 Windows Azure 计算层的可靠性。在事件 #1 期间，Web 角色 #1 和工作者角色 #1 因机架电源故障而停止响应。Fabric Controller 在可用机架 #2 和 #3 中启动 Web 角色 #1 和工作者角色 #1 的配置过程。一段时间后，发生事件 #2，其间重新分配的 Web 角色 #1 因应用程序故障而未能通过运行状况检查。现在 Fabric Controller 开始将 Web 角色 #1 分配给其他某个可用机架。

这些事件发生期间，应用程序可用性不会受到影响。至少两个 Web 角色继续服务于网页请求，并且至少一个工作者角色从队列中拉出事务项，将其写入 Windows Azure Storage。在任何给定的时间，Fabric Controller 都尽力维持三个运行状况良好的 Web 角色实例和两个工作者角色实例，从而保持平衡。实际上，可以为机架装配冗余的电源和网络交换机，从而在应用程序出现问题时，可以循环和重新分配角色，或进行扩展以实现可扩展性目标。

“购物列表”服务模型需要两个工作者角色，以免发生单点故障。虽然 Web 层和批处理层已通过 Windows Azure 队列去除耦合，仍建议至少使用两个工作者角色承载对时间要求严格的关键任务批处理服务。如果承载的服务对时间要求不严格，也可以只使用一个工作者角色。

图 1 说明 Windows Azure 平台尽量兼具 PaaS 的优势和 IaaS 的灵活性。这是通过基于策略的部署模型实现的，该模型由 Web 角色、工作者角色、CGI 角色和将来会出现的大量其他角色构成。支持角色列表将不断增长，以满足客户不同的应用程序和部署需求。

面向成本的云体系结构

体系结构的选择会对中小型企业的运营经济效益产生重大影响。尽管云计算注重 IT 灵活性，在设计解决方案架构时还是要考虑企业的运营成本。云应用程序的体系结构需要实现功能和系统质量（可扩展性、可用性、可靠性和性能），还要优化运营成本。在内部部署情况下，应用程序架构师很少考虑存储成本、网络带宽或计算周期成本，因为这是在企业级别产生的资本支出。

例如，优化应用程序存储通常不是架构师的首要任务，因为存储产生的成本未包括在运营成本中。内部部署系统的首要任务是在分配的预算内符合重要的系统质量要求。在云计算环境下，在确定系统架构时优化运营成本成为软件开发过程中的重要因素。

我将以图 4 中的“购物列表”应用程序为例，讨论 Windows Azure 平台的成本模型。该图是“购物列表”的逻辑体系结构视图，图中箭头表示数据移动方向。虚线箭头表示数据中心内部的带宽消耗，实线表示数据移入和移出云数据中心。

图 4 Windows Azure 平台应用程序计费模型

Windows Azure 平台只对数据传入和传出数据中心计费，不对数据中心的本地数据传输计费。写入 Windows Azure 队列的所有数据都不会产生任何带宽或存储费用，因为队列只短时占用存储空间。不过，队列会产生事务费用。浏览、读取或写入队列项被视为一个事务。

Windows Azure 平台服务器的使用按照角色数量和部署应用程序的时间量计费。这意味着，即使应用程序没有来自最终用户的请求，Windows Azure 平台帐单系统仍将按实例小时数对状态为“挂起”和“启动”的角色计费。因此，建议根据应用程序需求尽量减少活动角色的数量。现在，这还是手动过程；不过，您可以利用诊断数据和服务管理 API，根据应用程序可扩展模式自动调整应用程序。使用 Windows Azure 表、队列和 Blob 将产生存储成本，这是按记录上的 GB 数按月收取的。有关 Windows Azure 定价信息，请参阅图 5，在撰写本文时，该定价信息已公开发布。

图 5 Windows Azure 定价

Windows Azure 功能	费用	备注
服务器使用	小：$0.12/服务小时 中：$0.24/服务小时 大：$0.48/服务小时 超大：$0.96/服务小时	按活动应用程序的角色数计费。 小：(1.6Ghz)、1.75GB 内存（中等 IO 功能） 中：(1.6Ghz)、3.5GB 内存 大：(1.6Ghz)、7.0GB 内存 超大：(1.6Ghz)、14.0GB 内存
Windows Azure Blob 和表	$0.15/GB	在每个计费周期内进行日均计量。有关这些费用的计算方式，因为较为复杂，请参阅相关详细信息。
事务	$0.01/10K 事务数	在 Windows Azure 队列、Blob 和表中进行的创建、读取、更新和删除操作视为事务。
SQL Azure：Web Edition	$9.99/月 (1GB RDBMS)	大型应用程序或销售几百件商品的小型电子商务网站的元数据。
SQL Azure：Business Edition	$99.99/月 (10GB RDBMS)	用于中型企业。或者，通过数据共享，也可以构建需要存储大量数据的应用程序。
AppFabric	$0.15/100K 消息操作数	消息操作可以是服务总线消息、访问控制令牌请求或服务管理 API 调用。
传入 GB	$0.10/GB（亚洲为 $0.30）	只对传入和传出数据中心的数据计费。
传出 GB	$0.15/GB（亚洲为 $0.45）	只对传入和传出数据中心的数据计费。

Windows Azure 平台定价非常直观，只有 Blob 和表使用的存储定价例外。在计费周期内，每天都会计量帐户的 Windows Azure Storage 使用量，并计算日均值。费用的计算方式为日均值乘以 $0.15/GB。例如，如果第一天存储 20GB，第二天增加 10GB，第三天增加 5GB，第四天删除 5GB，本计费周期的其余时间内未进行其他活动，则价格计算方式如下：

((20 +10 + 5 – 5)/30) * 0.15 = $0.15

这里假定计费周期为 30 天。对存储进行每日采样，可以确保对需要进行大量短时存储的应用程序也收取存储费用，这与只在计费周期末进行计量的系统不同。

如前所述，体系结构是决定应用程序运营成本的重要因素。例如，如果应用程序产生大量数据，并且只需要最近（如最近两周）的数据执行其功能，就可以调整体系结构以删除不需要的数据，或者定期将数据传输到内部部署系统。支付一次性带宽费用会比支付永久性存储费用节省开销。可以用同样的方式处理不再属于活动数据集的参考数据。此方法适用于已投资实现数据存档功能的公司。

应用程序方案

我将在行业支持电子商务方案环境下，从不同角度讨论 Windows Azure 平台：“购物列表”应用程序。我将重点创建并保存一个商店列表，以备以后购物时使用。Web UI 构成购物列表，并使用 Web 服务将该列表保存到 Windows Azure Storage。为实现可扩展性，Web 层将购物列表写入 Windows Azure 队列；批处理过程定期轮询队列中的列表，并将它们保存到 Windows Azure 表中。我将使用基于 Windows Azure 的身份验证和基于角色的安全性演示实际应用中的解决方案。

图 6 Windows Azure 平台上的“购物列表”应用程序

在前述面向成本的体系结构环境下，不同的决策会影响每月运营成本。下面是继续设计体系结构之前必须考虑的系统因素：

引用数据的增长率

事务数据的增长率

行为分析数据的捕获率

业务事件数据的增长率

系统事件数据的捕获率

与产品有关的媒体内容

使用队列/直接与持久存储进行交互

我的“购物列表”方案中包含的媒体内容不多，因此这不是成本公式中的重要因素。但对于传输视频、图像和音频流的内容站点，考虑媒体成本是十分重要的。图 7 是一个典型应用程序在 Windows Azure 平台上的月度运营成本。该电子表格未包含进行开发、运营支持和最终用户支持所发生的人工成本。

图 7 电子商务应用程序的 Windows Azure 运营成本计算器

云计算环境将减少运营支持人员的数量，因此，在比较内部部署和云的投资回报率时，应考虑这一点。另外，在投资回报率计算公式中应包含每个应用程序的电源和资产折旧成本。现在的内部部署应用程序成本模型不包含这些开支，因为按应用程序细分耗电量十分困难。制冷系统和地面空间的成本计算也是如此。在缺乏客观的成本明细的情况下，投资回报率计算器可以使用合理的估计值。

图 7 中的简单成本计算器估计承载在 Windows Azure 平台上的应用程序的运营成本。这个基于 Microsoft Excel 的工具允许使用典型电子商务应用程序的各种输入参数，使用图 5 所示的 Windows Azure 平台定价表计算月度运营成本。请注意，该工具使用的默认参数不是真实的，您应使用自己系统的参数，以便根据该工具的输出制定决策。成本计算器根据每月访问者数量进行计算，并假定创建一定数量的页视图、事务数据和事件数据。Windows Azure 平台团队创建了一个功能更全面的工具，不仅能计算应用程序的月度运营成本，还能够比较内部部署的应用程序和 Windows Azure 的 TCO。Windows Azure TCO 工具的访问地址是：microsoft.com/windowsazure/tco。

如图 7 所示，我们虚构的应用程序在给定月份产生了 9000GB 数据，如果将这些数据保存在 Windows Azure 表中，每月成本约为 $1,350。请注意，图 7 仅显示了时间点存储，随着应用程序继续运营，会累积事件数据费用。随着应用程序的运营趋于成熟，通过调整捕获的事件数据量可以优化这类成本。成本计算器根据每月访问者数量计算成本，使用假定的 10 个 Web 角色和 3 个工作者角色。月度总费用为 $3,571。

另外，还可以将应用程序设计为将事件数据传输到已折旧的内部部署存储系统中（如果有），这样只需花费一次性的带宽成本（传出费用为 $0.10/GB）。可以对事务和行为分析数据应用类似的策略，以免支付累积存储费用。

计算费用实际上并不累积，因此对应用程序的总体运营成本影响较小。不过，可以根据观察到的应用程序可扩展性分析，调整活动 Web 和批处理角色实例的数量，从而减少运营边际成本。就计算费用和存储费用而言，计算使用量可以随时控制，但存储成本取决于体系结构决策，一旦构建了应用程序，就无法轻易改变。因此，建议在一开始就建立能够长期使用的体系结构。

除了应用程序的成本模型之外，大型企业还密切关注应用程序安全性，下面将对此进行探讨。

计算安全性

企业非常重视云中的应用程序和数据的安全性。尽管 Microsoft 负责数据中心、基础结构和操作系统的安全，应用程序所有者也有责任维护应用程序的安全。我将以“购物列表”Web 应用程序为例讨论应用程序安全性。确保 Windows Azure 平台应用程序的安全类似于确保内部部署应用程序的安全。Windows Azure 平台提供各种系统组件，帮助开发人员在应用程序中集成安全机制。通过这些系统组件，可以在大型企业适用的联合方案中实现基本、独立身份验证和授权。　　

基本身份标识

顾名思义，基本身份标识模型用于实现独立的身份标识体系结构，以满足一个应用程序或共存的应用程序组的需求，应用程序组共享同一组用户，在实现级别上紧密耦合至同一身份标识系统。Windows Azure 平台示例包含一组 ASP.NET 提供程序（成员、角色、配置文件和会话），这些提供程序用于实现基本身份标识解决方案。Windows Azure ASP.NET 提供程序在 Windows Azure Storage 中实现，后者包含 Windows Azure 表和 Blob。这些提供程序实现 ASP.NET 提供程序约定，并利用 Windows Azure Platform SDK 中的 StorageClient API。这些提供程序的示意图如图 8 所示。

图 8 Windows Azure ASP.NET 提供程序

若要在应用程序中使用 Windows Azure ASP.NET 提供程序，需要修改 Web.config 文件，以便删除默认提供程序，然后包含新提供程序。图 9 中的配置更改类似于内部部署情况下必须对自定义 ASP.NET 提供程序进行的更改。

图 9 Windows Azure ASP.NET 提供程序的 Web.config 更改

<system.web>　
　...　...　...　...　
<authentication　mode="Forms"　/>　
<!--　Membership　Provider　Configuration　-->　
<membership　defaultProvider="TableStorageMembershipProvider"　
userIsOnlineTimeWindow="20">　
<providers>　
<clear/>　
<add　name="TableStorageMembershipProvider"　
type="Microsoft...AspProviders.TableStorageMembershipProvider"　
description="Membership　provider　using　Azure　storage"　
applicationName="ShoppingList"　
...　...　...　...　...　
minRequiredNonalphanumericCharacters="0"　
requiresUniqueEmail="true"　
passwordFormat="Hashed"/>　
</providers>　
</membership>　
<sessionState　mode="Custom"　
customProvider="TableStorageSessionStateProvider">　
<providers>　
<clear　/>　
<add　name="TableStorageSessionStateProvider"　
type="Microsoft...AspProviders.TableStorageSessionStateProvider"　
applicationName="ShoppingList"/>　
</providers>　
</sessionState>　
<roleManager　enabled="true"　
defaultProvider="TableStorageRoleProvider"　
cacheRolesInCookie="true"　
cookieName=".ASPXROLES"　
cookieTimeout="30"　
...　...　...　...　...　
cookieProtection="All">　
<providers>　
<clear/>　
<add　name="TableStorageRoleProvider"　
type="Microsoft....AspProviders.TableStorageRoleProvider"　
description="Role　provider　using　table　storage"　
applicationName="ShoppingList"　/>　
</providers>　
</roleManager>　
...　...　...　...　
</system.web>

配置 ASP.NET 提供程序后，可以像传统 ASP.NET 应用程序一样实现身份验证、授权和用户配置文件。请注意，图 9 中的配置包含基于 Windows Azure Storage 的会话提供程序，该程序可在持久存储媒体上存储会话状态。Windows Azure 负载平衡器不支持粘性会话，将会话数据存储在 Windows Azure Storage 中，用户通过基于会话的个性化可获得更好的体验。基本身份标识模型适用的应用程序具有如下特点：用户身份标识生命周期（用户帐户的创建、使用和关闭）在同一个应用程序中开始和结束。选择基本身份标识实现的原因很多，包括：

应用程序需要保留完整的用户身份标识记录

缺乏实现联合身份标识存储和支持服务所需的基础结构

需要用户注册的短期应用程序（如市场营销竞争和促销）

Windows Azure ASP.NET 提供程序还用于对 AJAX 和 Silverlight 应用程序用户进行身份验证。AJAX 可调用的 AuthenticationService、ProfileService 和 RoleService 类位于 System.Web.Extensions.dll 内，可通过 Windows Azure Web 角色发布为 .svc 端点。请注意，这些服务必须与 ASP.NET 兼容，才能访问特定于 HTTP 上下文的数据。有关如何设置上述服务，以便从 Silverlight 或 AJAX 进行调用的详细信息，请参阅标题为“使用 Silverlight 构建业务线企业级应用程序，第 2 部分”(msdn.microsoft.com/magazine/dd434653) 的文章。

联合身份标识模型

对于包括供应链、价值链、协作和社交网络，或需要将常用身份标识存储集成到 Internet 的应用程序，联合身份标识是必需的。Windows Azure ASP.NET 堆栈可与 Windows Identity Foundation (WIF) 结合在一起，从而与一个或多个安全令牌服务提供程序进行集成。WIF 与预建立的信任关系一起使用，该信任关系是由 WS-Trust 和 WS-Federation 启用的。图 10 是“购物列表”应用程序与两个令牌提供程序（分别来自内部部署和供货合作伙伴）协同工作的概念视图。

图 10 可向 Windows Azure 应用程序注册多个令牌服务

该信任关系描述安全令牌服务 (STS) 端点和为令牌请求和响应签名所需的 X509 证书。图 11 显示了信任关系示意图，其 XML 表示形式将在部署时包含在“购物列表”应用程序配置中。用户在各自的系统进行身份验证，然后所获得的安全声明标记语言 (SAML) 令牌将转发到请求应用程序。

图 11 联合信任描述符

如图 10 所示，用户访问 Windows Azure 平台承载的“购物列表”应用程序中的安全 Web 内容时，WIF 将请求转发到信任配置中的“购物列表”STS URL。“购物列表”STS 收集凭据，根据 Active Directory 对用户进行身份验证，在 Active Directory 联合身份验证服务（ADFS，以前称为“Geneva 服务器”）的帮助下建立 SAML 令牌，然后通过 Web 浏览器将该令牌转发给“购物列表”应用程序。在 Windows Azure 中运行的“购物列表”站点内的 WIF 将提取 SAML 声明并执行授权检查。

如果涉及多个 STS，网站必须实现令牌转换逻辑，将不同的令牌转换为规范的格式。为了尽量减少新 STS 加入系统时产生的影响，可将令牌转换逻辑外部化，也可将其封装到组件中，对逻辑进行修改时，不能影响使用它们的应用程序。图 12 是与 WIF 结合使用的令牌转换示意图。

图 12 使用多个令牌提供程序的联合身份标识系统

联合身份标识模型将启用的方案如下所示：

为实现法规遵从性在内部部署应用程序中存储身份标识记录

利用现有内部部署应用程序安全基础结构

在价值链和供应链中与合作伙伴集成

在内部部署和 Windows Azure 平台应用程序之间使用单一登录

通常，大型企业已实现身份验证服务和目录服务器来确保应用程序的安全。使用 Windows Azure 平台，可以在利用云快速部署应用程序的同时，利用现有基础结构实现安全机制。另外，Windows Azure 平台的设计允许使用联合身份标识，这种标识可为业务合作伙伴和价值链支持各种集成方案。

Windows Azure Storage

部署在 Windows Azure 平台上的应用程序和服务可以使用 Windows Azure Storage 来实现结构化和半结构化内容的持久存储。Windows Azure Storage 具有构建行业支持应用程序和服务所必需的三个基本功能：表、Blob 和队列。Windows Azure Storage 是一种可扩展性极强的高度可靠的持久存储机制，可由内部承载的应用程序通过行业标准 Web 服务界面（如 REST）进行访问。为实现传送时的私密性，Windows Azure Storage 支持基于 SSL (HTTPS) 和标准 HTTP 协议的访问。可扩展性和其他系统质量由大型存储场实现，这种场由商用服务器硬件和磁盘阵列组成，由 Windows Azure Storage 软件进行管理。访问存储时会在一组节点中自动平衡负载，以实现可扩展性和可用性。每个节点都负责有限数量的物理存储。对节点作用域之外的存储进行访问需通过对等接口。可靠性是通过在多个节点上设置冗余存储实体（如 ShoppingList）实现的。发生写入操作时，该存储软件会自动生成数据的多个（撰写本文时为三个）副本。存储支持原子事务写入，只有在所有副本都写入驱动器后，事务处理才完成。图 13 显示商用存储节点形成 Windows Azure Storage 服务。

图 13 存储服务

在使用过程中，任意位置的任何存储驱动器都可能发生故障，节点 4 和节点 11 处的红色“X”表示发生了故障。存储服务确定发生故障的驱动器后，即会将数据从该驱动器复制到新节点。在任意给定时间点，存储服务都遵从复制策略。如前所述，来自应用程序的请求通信在多个节点间进行负载平衡。

这种体系结构有助于实现公共云 PaaS 产品（如 Windows Azure 平台）所必需的高度扩展性。如图 13 所示，假定节点 4、11 和 14 拥有某段数据的三个初始副本。如果节点 4 和 11 出现故障，节点 14 将直接继续为请求服务，同时快速将数据重新复制到至少两个其他节点（节点 2 和 8），从而使数据副本数量维持在正常水平。　

存储安全性

Windows Azure Storage 通过基于哈希的消息身份验证代码 (HMAC) 对 REST Web 请求进行身份验证。与 Windows Azure Storage 项目关联的共享密钥与 HTTP 请求一起，计算出一个 256 字节的哈希值，将该值作为“授权”标头嵌入 Web 请求。服务器上也会进行同样的过程，对请求进行身份验证。Windows Azure 表、队列和 Blob 都遵循这一身份验证过程，不过，每个存储类型的负载和目标 URL 各不相同。在“hkshoppinglist”项目下访问上述三种存储功能的 URL 如下：

http(s)://hkshoppinglist.blob.core.windows.net/

http(s)://hkshoppinglist.queue.core.windows.net/

http(s)://hkshoppinglist.table.core.windows.net/

图 14 中的代码示例演示作为应用程序部署的存储准备工作的一部分，如何创建多个 Windows Azure 表。

图 14 演示在经过身份验证后创建 Windows Azure 表和数据的伪代码

[DataServiceKey("TableName")]　
Public　class　StorageTable　
{　
　Private　string　_tableName;　
　Public　string　TableName　
{　
　get　{　return　this._tableName;　}　
　set　{　this._tableName　=　value;　}　
}　
}　
　
Public　class　Customer:　TableServiceEntity　
{　
　Public　string　Name　{　get;　set;　}　
　Public　string　CustomerID　{　get;　set;　}　
　public　Customer()　
{　
　PartitionKey　=　"enterprise";　
　RowKey　=　string.Format("{0:10}_{1}",　DateTime.MaxValue.Ticks　–　
　DateTime.Now.Ticks,　Guid.NewGuid());　
}　
}　
CloudStorageAccount　_storageAccount　=　CloudStorageAccount.FromConfigurationSetting("DataConnectionString");　
　
Public　void　CreateMultipleCustomers(List<Customer>　customers)　
{　
　TableServiceContext　tsc　=　new　
　TableServiceContext(_storageAccount.TableEndpoint.AbsoluteUri,　
　_storageAccount.Credentials);　
　foreach　(Customer　cust　in　customers)　
{　
　tsc.AddObject("customers",　cust);　
}　
try　
{　
　DataServiceResponse　resp　=　tsc.SaveChanges(SaveChangesOptions.Batch);　
　foreach　(ChangeOperationResponse　cor　in　resp)　
{　
　if　(cor.Error　!=　null)　
{　
//cor.Headers["Location"]　can　be　parsed　to　find　out　the　failed　
//requests　which　can　be　retried　after　correcting　the　error　condition　
}　
}　
}　
catch　(Exception　ex){　//do　something　with　the　exception　}　
}　
　
protectedvoid　linkCreateTables_Click(object　sender,　EventArgs　e)　
{　
　labelStatus.Text　=　string.Empty;　
try　
{　
　CreateTable("customers");　
　CreateTable("products");　
}　
catch　(DataServiceRequestException　ex)　
{　
　labelStatus.ForeColor　=　System.Drawing.Color.Red;　
　labelStatus.Text　=　"Error:　Table　creation　error　:　"　+　ex.Message;　
}　
}　
//Use　ADO.NET　services　directly　to　create　an　Windows　Azure　Table　
Public　void　CreateTableUsingContext(AzureStorageTable　storageTable)　
{　
　TableServiceContext　tsc　=　new　
　TableServiceContext(_storageAccount.TableEndpoint.AbsoluteUri,　
　_storageAccount.Credentials);　tsc.AddObject("Tables",　storageTable);　
try　
{　
　DataServiceResponse　resp　=　tsc.SaveChanges(SaveChangesOptions.None);　
//handle　errors　
}　
catch　(Exception　ex){//do　something　here}　
}　
//much　simpler　way　of　creating　an　Windows　Azure　Table　
　publicvoid　CreateTable(string　tableName)　
{　
CloudTableClient　ctc　=　_storageAccount.CreateCloudTableClient();　
try　
{　
　ctc.CreateTable(tableName);　
}　
catch(Exception　e)　{　//handle　exception　}　
}

以 Windows Azure 表为例，我将介绍一些准备 Windows Azure Storage 进行数据事务填充的简单方法。这些代码示例说明如何使用 TableServiceContext 和 CloudTableClient 创建“customers”和“products”表，以演示基于 REST 的交互的灵活性。实际上，您还可以构建一个原始负载，将 HMAC 附加到 Web 请求，对表 URL 进行 HTTP POST，不过，这需要编写很多代码，只适于作为学术探讨。建议的方法是使用 Windows Azure SDK 中的 StorageClient。

CreateTableUsingContext 函数使用 AzureStorageTable 类，在 ADO.NET 数据服务的帮助下生成表创建负载。TableServiceContext 自动生成 HMAC，然后使用 CloudStorageAccount.Credentials 属性包含的密钥将其附加到请求。

Windows Azure 表存储允许进行批事务处理，如图 14 中的 CreateMultipleCustomers 函数所示。在一个给定更改集中，批处理不应超过 100 个操作，单个批处理的大小不应超过 4MB。有关详细信息，请参阅 Windows Azure Storage 文档。只能对同一分区内的实体进行批事务处理。

生成 HMAC 时所必需的凭据在相应 Windows Azure 角色的服务配置中指定。下面是本地存储和云存储的连接字符串的格式：

本地存储：

<Setting　name="DataConnectionString"　
value="UseDevelopmentStorage=true"/>

云存储：

<Setting　name="DataConnectionString"　
value="DefaultEndpointsProtocol=　
http;AccountName=　
<your　account>;AccountKey=<your　account　key"/>

Windows Azure Storage 没有基于角色的安全性概念；因此，在存储项目上下文中，通过身份验证的请求对存储具有完全访问权限。但 Blob 容器是个例外，该容器可以是公共（匿名）的，也可以是私有的。使用存储服务的应用程序负责进行身份验证。

总结

在本文中，我只是粗略介绍了 Windows Azure 平台。我相信，以后会有大量文章介绍本文未涉及的 Microsoft SQL Azure、AppFabric、各种服务器角色和其他安全方案。Windows Azure 平台是一种云计算平台，其架构支持按需实用工具计算，用于开发和承载应用程序和服务。

由高度自动化的软件管理的大型商用硬件池具有很高的可靠性。订阅费用低，客户享受了高度可扩展性带来的经济优势。根据带宽、存储使用量和计算周期对订阅者按月度计费周期收费。Windows Azure 平台附带构建企业级应用程序和服务所必需的平台组件，无需预先投入资金或签订长期合同。