第2章 Windows Azure云计算平台

Windows Azure平台不是一个简单独立的产品，其中包含了多个云计算服务，每个服务都有其特定的功能和使用场景。本章节将会概括介绍Windows Azure平台下的几个主要的组成部分和它们相应的功能特点。同时，由于Windows Azure是按使用量付费，账户关系和收费模式也是基于Windows Azure开发需要重点考虑的问题。在本章的后半段，我们将会详细介绍Windows Azure各个服务的收费模式和收费金额。

最后，作者将会分享一些Windows Azure平台部署运维的成本统计，对于使用Windows Azure平台降低企业IT成本提供一些相对直观的数据，并且对于部署在Windows Azure平台应用程序的性能也会给出一些简单的评测数据。

2.1 Windows Azure平台的组成部分和主要功能

自2008年微软PDC大会提出以来，Windows Azure平台中间经历了几次功能和模块的调整，直到2010年年初所包含的功能基本稳定。前面提到过，目前Windows Azure平台包含四大功能，即Windows Azure、SQL Azure、Windows Azure AppFabric和Windows Azure Connect。

2.1.1 Windows Azure

Windows Azure部分主要提供了分布式可扩展的计算和存储功能。所谓计算，就是指Windows Azure负责为部署在其上的程序提供相应的虚拟机和寄宿服务，包括对ASP.NET网站和WCF服务提供基于IIS的寄宿服务，对于普通的后台程序（C#或F#）提供基于Windows Azure Worker Role的寄宿服务，以及对于PHP等应用程序提供基于FastCGI的寄宿服务。

在提供计算能力的同时，Windows Azure还提供了存储功能。不同于本书后面介绍的SQL Azure，Windows Azure提供的存储服务主要包括：

· Table Storage：非关系型的，存储结构化数据库的服务。

· BLOB Storage：存储二进制文件的服务。

· Queue Storage：持久化的分布式队列服务。

在Windows Azure数据中心，计算节点和存储节点分别负责Windows Azure的计算和存储服务，如图2-1所示。最上层的Microsoft Online Services Portal负责Windows Azure的购买订阅功能，Windows Azure Developer Portal为使用者提供控制Windows Azure服务的功能，包括创建及删除Windows Azure计算服务和存储服务、管理密码以及证书等。上述两个Portal都通过一个名为Service Management Service的服务进行实际的操作，同时提供REST API对外接口，由数据中心底层的Windows Azure Fabric Controller控制其内部的计算和存储节点。而对于存储服务而言，Windows Azure平台还专门提供了一套REST API使其可以方便地被外部访问。

应用程序首先在开发人员的计算机上通过Visual Studio和Windows Azure SDK进行开发，然后通过Developer Portal网站或Visual Studio（基于Management Service API），连同一个专门的配置文件上传到指定的数据中心。数据中心会根据配置文件分派一个或多个虚拟机，然后由特定的启动程序安装相应的组件。最后应用程序代码将会部署在虚拟机的特定目录下。

不过，应用程序此时并不会直接暴露在Internet中。Windows Azure平台在提供了计算功能的同时，还提供了负载均衡的支持。如图2-2所示，在Windows Azure平台上面部署的计算服务，无论是基于IIS的网站或WCF服务，还是后台执行的异步任务以及部署的存储服务，当调用方通过外部Internet访问时，Windows Azure平台都会提供负载均衡。而且Windows Azure平台的负载均衡使用了基于轮询的调度方案。比如用户为一个部署在Windows Azure平台的网站设定了三个运行实例，也就是说在平台内部有三台虚拟机同时运行网站代码，那么当用户访问这个网站的时候，系统是无法预知当前请求会去访问哪一台虚拟机上面的程序。而且，用户在访问网站的时候，每个HTTP请求也不能保证都会指向同一台Windows Azure虚拟机。

Windows Azure平台的这个特性将会直接影响到开发人员如何设计应用程序。关于这一点，可以参考本书的8.12节。

2.1.2 Windows Azure相关名词

Windows Azure定义了一套专门的名词和术语，用来明确其各组成部分和层次关系。现在将这些名词以及它们之间的关系做一个系统的介绍。

当用户在Microsoft Online Services Portal上面购买了一个Windows Azure服务之后，将会得到一个订阅（Subscription），根据用户购买的内容，这个订阅里有可能包含Windows Azure的计算服务、存储服务、SQL Azure数据库服务以及Windows Azure AppFabric服务。

当用户登录了Windows Azure Developer Portal之后，将会看到一个项目（Project）。这个项目和之前提到的用户购买的订阅是一一对应的。在项目之下，用户可以使用Windows Azure提供的各项功能。例如可以在项目下创建一个或多个服务（Service）。这里的服务分为两大类：计算服务（Hosting Service）和存储服务（Storage Service）。目前，一个订阅，或者说一个项目之内，最多允许用户创建6个计算服务和5个存储服务。而在计算服务之下，用户可以添加两种角色（Role）：基于IIS的Web Role和独立运行的工作进程Worker Role。对于每一个角色，用户还可以定义它们使用的Windows Azure虚拟机配置（VM Size）。不同的虚拟机配置对应了不同的CPU、内存和本地存储空间的限制，如表2-1所示。

如果用户使用Visual Studio和Windows Azure Tool for Visual Studio进行开发，那么也可以说一个计算服务对应一个Visual Studio中的Windows Azure项目，而角色就是定义在Windows Azure项目中的一个Role节点。而一个Role节点将会对应当前Solution下面的一个Visual Studio项目。这个项目可能是一个Web Application或WCF Service（Web Role），或者是一个Class Library（Worker Role）。关于Visual Studio中的Windows Azure项目组成，请参见本书3.3节。

同时在Windows Azure平台，每个角色会包含一个或多个运行实例（Instance），也就是说用户在使用的时候不仅可以指定虚拟机的配置，还可以指定Windows Azure使用多少台虚拟机运行当前的应用，使用Windows Azure负载均衡来提高执行能力。不过，在一个订阅中最多允许用户申请使用20个运行实例。

图2-3展示了一个典型的Windows Azure应用程序配置。在一个Subscription中用户添加了两个Service：一个是用于计算的Hosting Service；一个是用于存储的Storage Service。在Hosting Service中包含两个Role，分别是基于IIS的Web Role和后台运行的Worker Role。其中Web Role启用了三个Instance，也就是使用了三台Windows Azure虚拟机；而对于Worker Role则启用了两个Instance。右侧是与之相对应的Visual Studio项目。

对于一个Hosted Service，Windows Azure平台还为使用者提供了两个完全隔离的运行环境，即生产环境（Production Environment）和测试环境（Staging Environment）。这两个运行环境物理上完全独立。这样的设计主要是为了开发人员能够安全地在Windows Azure平台上进行测试，不会影响到已经部署好的上一版本程序的运行。关于这两个环境以及如何使用，请参见本书5.2节。

在Hosted Service下，用户还可以添加安全证书（Certificate）。由于Hosted Service中的Web Role专门处理基于IIS的应用或服务，因此如果当前的服务需要SSL安全验证，也就是说需要使用HTTPS协议，那么必须要在服务器端安装相应的证书。而Hosted Service的Certificates就是专门处理安全证书的，包括安装新的证书和删除一个证书。

图2-4展示了一个典型的Windows Azure应用部署后在Developer Portal中看到的结果。可以看到，在Ethos Tech这个Subscription下面用户创建了三个Hosted Service，分别是Default Host、KDR Gold Beijing Development Service和XLR8 Demo Website。而在Default Host这个Service的Production Environment下面，用户部署了一个名叫Azure Hierarchy的应用，包含一个Web Role和一个Worker Role。Web Role配置了三个Instance，而Worker Role配置了两个Instance。并且，在Default Host这个Service下面，用户还添加了两个Certificates。

Windows Azure所有的计算功能都是基于虚拟机完成的，既然是虚拟机那么就会存在一个操作系统版本的文件。目前Windows Azure平台提供了一种名为Guest OS的机制来控制虚拟机中所安装的操作系统版本。

我们知道，整个Windows Azure数据中心是基于Windows Azure Server 2008 R2 Hyper-V构建的。当用户申请了一个计算单元之后，数据中心将按照需求分配一个或多个虚拟机，而每一个虚拟机都会有一个操作系统主版本，目前包括Guest OS 1.x和Guest OS 2.x，分别对应Windows Server 2008以及Windows Server 2008 R2两大类操作系统。在此基础上，由于Windows操作系统本身的不断更新，Windows Azure平台也会定期为虚拟机进行操作系统升级，只不过没有普通的Windows更新那么频繁。一次Windows Azure平台虚拟机的更新会对应出一个新的Guest OS小版本，所以使用者在申请Windows Azure虚拟机的时候可以指定某个版本的Guest OS，也就是安装了某些更新的Windows操作系统；可以指定使用最新版本的Guest OS，即完成了所有更新的Windows系统。对于前者，当Windows Azure平台有新版本Guest OS出现的时候，将会自动为用户升级虚拟机上的操作系统。而对于后者，除非用户指定，否则Windows Azure是不会为用户升级的。

另外需要注意的一点是，Guest OS主版本之间是不会自动升级的。例如当前Guest OS 1.x的最新版本是1.6，并且用户指定其虚拟机使用Guest OS 1.x的最新版本，那么如果Windows Azure平台提供了Guest OS 1.7，用户的虚拟机将会自动升级到这个版本。但是如果出现了Guest OS 2.1，由于其主版本不一致，所以用户的虚拟机也不会被升级。

表2-2列举了2011年年初Windows Azure Guest OS的几个版本以及升级的主要内容。这个列表随着Windows更新的增加将会越来越长。

2.1.3 SQL Azure

SQL Azure可以说是目前世界上第一个商用的云端关系型数据库服务。相对于熟悉的SQL Server，SQL Azure具有如下特点。

· 自我管理：由于SQL Azure是一个数据库服务而不是一个独立的数据库，因此用户在使用的时候并不需要关心其相关的网络环境、硬件配置和存储介质。通过SQL Azure Developer Portal使用者只需几次点击就可以完成数据库的创建和删除操作。并且，由于微软的数据中心负责维护SQL Azure，所以用户也无须关心数据库的故障恢复和容灾问题。可以这样理解，SQL Azure就是一个永远不会停机的数据库服务器。

· 伸缩性和扩展性：由于SQL Azure的自我管理和易于部署的特点，使得对SQL Azure的扩展和伸缩操作也变得非常方便。同时SQL Azure也是基于按使用量付费的模式，这样使用者便可以在需要更大数据存储需求的时候申请新的数据库；而在数据使用量减少的时候删除不需要的数据库，同时节省费用。

· 开发一致性：因为SQL Azure是基于SQL Server 2008 R2构建的，并且两者都是基于相同的TDS协议，所以使用者可以通过熟悉的工具或访问方式来使用SQL Azure。在工具方面，用户可以使用SQL Server Management Studio 2008 R2来管理SQL Azure，如图2-5所示；在代码访问方面，开发人员可以使用ADO.NET、ODBC进行数据库连接操作，使用LINQ to SQL或Entity Framework实现数据访问层。而且，SQL Azure链接字符串的格式也和SQL Server的基本相同。

与Windows Azure相似，用户购买了SQL Azure服务之后将会在他的SQL Azure Developer Portal上面看到与之对应的订阅（Subscription）。而后用户要在这个订阅下面创建一个SQL Azure服务器（Server），这个Server可看做是一个虚拟的SQL Server服务器。然后，和平时使用SQL Server类似，用户可以在这个SQL Azure Server中创建多个数据库（Database），然后在数据库中创建需要的表（Table）、字段（Column）、视图（View）、存储过程（Stored Procedure）和触发器（Trigger）等。目前，一个SQL Azure订阅中允许用户最多创建5个Server，而每个Server内最多允许创建150个Database（包含系统默认的master数据库）。关于如何创建SQL Azure数据库，请参见本书4.5节。

SQL Azure创建的数据库包含多个版本（Edition），每个版本规定了集中数据库的容量。这个容量包含数据库本身所存储的数据容量以及索引数据的容量，但是不包含数据库日志的容量。具体的数据库版本及配置如表2-3所示。

由此可见，目前SQL Azure对于单个数据库最大支持50GB。可能有人要问，如果我需要的数据库容量超出了50GB该怎么办呢。这时可能就需要用到数据库层面的横向扩展技术了，也就是常说的数据库分片（Database Partition或Database Sharding），关于数据库扩展请参考本书8.12.3节。

2.1.4 Windows Azure AppFabric

前面介绍的Windows Azure提供了云计算平台的计算能力和存储能力，而SQL Azure提供了基于云平台的关系型数据库服务，基于这两者开发人员已经可以构建出一个运行在云端的应用程序，那么Windows Azure平台的第三个模块Windows Azure AppFabric究竟是做什么用的呢？我们不妨先来看一个场景。

假设目前某企业已经完成了一个基于WCF的服务，并且发布在企业内部的局域网里面，而使用者也是这个局域网内的用户。现在这个企业又开发了一个网站并将它部署到Windows Azure上面，并且需要这个网站能够调用此前开发的WCF服务。也就是说这个WCF服务需要开放给Internet的用户（Windows Azure上的网站）使用，那么为了实现这个要求需要进行哪些操作呢？首先可能需要配置企业防火墙和端口映射，还可能需要为这个服务配置一个独立的域名。这些工作烦琐且容易出错，如果有新的内部服务需要暴露到Internet上就要重复上述工作。而Windows Azure AppFabric就是为了解决这个问题而诞生的。

Windows Azure AppFabric包含了几大部分，其中之一就是为使用者提供一个非常简便的方式将部署于企业内网的服务发布到Internet上，供广域网的用户使用。它使用了我们称之为服务总线功能（Service Bus）的概念。只要将企业内部的服务注册到AppFabric的Service Bus上，Internet上的使用者就可以根据Service Bus的地址进行访问，而且所有的调用都是可以无须额外配置并且安全地穿透企业防火墙。同时，使用者也无须知道这个服务在企业内部网络的拓扑结构、IP地址等详细信息。

除此之外，Windows Azure AppFabric还提供了一个称之为访问控制服务（Access Control Service）的功能，它为我们抽象了应用程序的身份验证逻辑（Authentication），使得开发人员可以将这部分功能从应用本身抽离出去，从而更加关注业务逻辑。并且，基于访问控制服务，开发人员还可以方便地创建基于第三方认证提供方的应用。比如可以让应用程序基于LiveID、Google ID或Yahoo ID等账号登录。

在2011年4月微软的MIX大会上，Windows Azure AppFabric Cache正式商用。它是第一个基于Windows Azure平台的高可用、分布式、基于内存的缓存服务。使用者可以通过本地的AppFabric SDK直接访问云端的分布式缓存，或者使用AppFabric SDK内置的Session State Provider或ASP.NET Output Cache Provider实现基于分布式缓存的Session和Output Cache解决方案。关于Windows Azure AppFabric Cache请参考本书8.7节。而在2011年7月，微软还发布了Windows Azure AppFabric Application的第一个社区技术预览版（CTP），使得开发人员可以构建基于模块的应用程序，并且对相关的WCF服务、WF服务进行监控。

2.1.5 Windows Azure Connect

Windows Azure Connect是微软在2010年11月随着Windows Azure SDK 1.3一起发布的一个新特性。目前Windows Azure Connect功能和Traffic Manager、VM Role功能处于Beta阶段，用户需要申请并等待微软审核通过后才能使用。

基于Windows Azure Connect，使用者可以通过Developer Portal来实现企业内的计算机与Windows Azure中虚拟机之间的IP级别连接。它利用密码安全服务来保证通信的安全性。由于这种连接是在IP级别实现的，因此可以在Windows Azure Connect建立连接的企业内部计算机和Windows Azure虚拟机之间进行很多的共享操作，例如可以让运行在云端的Windows Azure应用程序使用企业内部的网络打印机、访问企业内部服务器上面的共享文件夹和使用企业内部的SQL Server数据库等。关于Windows Azure Connect请参见本书8.3节。