3.2 第一个Windows Azure应用程序
准备好了环境，现在就可以动手创建第一个Windows Azure应用程序，这里以ASP.NET MVC网站为例。通过创建和部署这个应用程序，我们可以快速、全面地了解Windows Azure开发所必备的知识点，为后面更加详细的介绍打好基础。
3.2.1 创建Cloud Project和Web Role
进入Visual Studio开发环境并打开New Project的对话框，这时候可以看到一个新的项目分类：Cloud，如图3-3所示。选择Cloud之后可以看到一个名为Windows Azure Project的项目模板，即之前Windows Azure Tool for Visual Studio中安装的项目模板。
图3-3 Visual Studio新建项目对话框中Windows Azure的模板
单击OK按钮之后在下一个对话框里，用户需要选择是否在创建项目的同时创建所需要的Web Role或者Worker Role，否则Visual Studio只会创建一个空的Windows Azure项目。在这个对话框中可以看到，Windows Azure目前支持VB.NET、C#和F#三种.NET语言。如图3-4所示，以C#为例可以创建的Role包括以下几种。
图3-4 创建Windows Azure Role对话框
· ASP.NET Web Role：使用ASP.NET WebForm的、部署在Web Role的网站。
· ASP.NET MVC 3 Web Role：使用ASP.NET MVC 3的、部署在Web Role的网站。
· ASP.NET MVC 2 Web Role：使用ASP.NET MVC 2的、部署在Web Role的网站。
· WCF Service Web Role：部署在Web Role的WCF服务。
· Worker Role：部署在Worker Role的后台工作应用程序。
· CGI Web Role：使用FastCGI且部署在Web Role的网站或服务，例如PHP。
接下来将ASP.NET MVC 2 Web Role加入到右侧的列表中，在当前Solution中创建一个基于ASP.NET MVC 2的Web Role项目。如果在右侧选中这个Role则会出现两个按钮，分别对应修改Role的名称以及删除Role，如图3-5所示。将这个Role重命名为MyFirstAzureProject，然后单击OK按钮，Visual Studio开始创建Windows Azure项目和ASP.NET MVC 2 Web Role项目。
图3-5 创建ASP.NET MVC 2 Web Role
接下来介绍这个面向Windows Azure开发的Solution里面都包括了哪些内容。首先可以看到的是一个标准的ASP.NET MVC Web Application项目，就是在图3-5所示的步骤中加入的那个Web Role。只不过和标准的ASP.NET MVC项目不同，这个项目里面包含了一个特别的文件——WebRole.cs。这个文件是负责Web Role启动、停止等生命周期管理的文件，更详细的介绍请参见本书3.3.2节。
其次就是一个名为Shaun.WABook001的项目。它就是在图3-3所示的步骤中创建的Windows Azure项目，它将会对应到一个部署在Windows Azure平台的Hosted Service。如图3-6所示，其中Roles文件夹包含了所有加入到这个Windows Azure项目里面的Role。本例中只包含了一个Role，即之前添加的ASP.NET MVC 2 Web Role。而Role具体的代码则指向了MyFirstAzureProject这个项目。
图3-6 Windows Azure项目结构
另外Windows Azure项目还包含两个配置文件，分别是ServiceConfiguration.cscfg和ServiceDefinition.csdef。关于Windows Azure所有的部署信息，包括所选取的VM Size、Instance数目、开放的端口、申请的本地存储以及服务器安装证书等都会保存在这两个配置文件中。关于CSCFG和CSDEF文件的具体内容和作用，请参考本书3.3.1节。
参考
完成后代码：ch001_shaunwabook001.zip。
3.2.2 使用本地模拟器运行和调试Azure应用程序
接下来对MVC网站稍做修改，打开Views/Home/Index.aspx文件，在页面中加入Hello Windows Azure的文字。修改后的页面代码如下所示。
<%@ Page Language="C#" MasterPageFile="～/Views/Shared/Site.Master" Inherits="System
.Web.Mvc.ViewPage" %>
...
<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">
<h2>Hello Windows Azure!</h2>
<p>
To learn more about ASP.NET MVC visit <a href="http://asp.net/mvc" title="ASP.N
ET MVC Website">http://asp.net/mvc</a>.
</p>
</asp:Content>
接下来就可以在本地运行。需要注意的是，要确保已经将Windows Azure项目，即本例中的Shaun.WABook001项目设定为启动项。按F5键开始运行，Visual Studio将会自动启动Windows Azure本地模拟器，稍后系统的状态栏中会出现一个小的Windows Azure图标，如图3-7所示，表明本地模拟器正在工作。
图3-7 Windows Azure本地模拟器在系统状态中出现
然后，模拟器将Windows Azure项目和它包含的所有Role（本例中只有一个Web Role）打包并且部署到本地模拟器的计算服务中。同时存储服务模拟器也会随之启动，虽然在本例中还不需要使用存储服务。最后，浏览器自动打开并且显示这个ASP.NET MVC 2 Web Role，如图3-8所示。
图3-8 运行于本地模拟器的ASP.NET MVC 2 Web Role
本地模拟器不但可以让开发人员方便、快速地看到应用程序在Windows Azure平台运行的大致效果，还提供了本地调试的功能。例如，可以在Visual Studio里面打开AccountController.cs文件，然后在Index方法里面加入一个断点。返回浏览器刷新页面，这时候可以可以看到，Visual Studio停在了断点处，如图3-9所示。这就表明，在本地模拟器环境中，开发人员可以像以前开发本地应用程序一样调试Windows Azure应用程序。
图3-9 本地模拟器中调试Windows Azure应用程序
注意
虽然本地模拟器尽可能地模拟了Windows Azure的环境，但还是和真实的云环境有所区别。由于在真正的Windows Azure虚拟机中只安装了.NET Framework，所以如果项目中使用了其他在GAC中的类库，那么在云环境下有可能出现程序异常。关于本地模拟器和Windows Azure云环境的更多区别，请参考http://msdn.microsoft
本地模拟器方便了开发、测试（主要是开发人员自我测试或单元测试）和调试。如果在本地模拟器的运行环境下验证程序没有问题，那么就可以开始将其部署到真正的Windows Azure环境中去。目前有两种方式可以将应用程序部署到Windows Azure环境：通过Developer Portal网站部署或者通过Visual Studio一键部署。接下来我们介绍如何通过Developer Portal网站将刚才创建的项目部署到真正的Windows Azure中。关于如何使用Visual Studio进行部署，请参考本书5.1节。
3.2.3 购买Windows Azure
在2.2.1节提到过，在使用之前需要首先在Microsoft Online Service Portal（简称MOCP）上面购买Windows Azure服务。
参考
MOCP的地址是http://mocp.microsoftonline.com/。
在MOCP主页点击登录并输入Live ID后，可以看到在服务列表中包含一个名为Windows Azure Platform的项目，即Windows Azure平台服务。接下来单击“检视服务明细”链接，如图3-10所示。
图3-10 MOCP中Windows Azure平台的服务项目
注意
由于目前中国大陆并不在Windows Azure指定的销售地列表中，所以如果在MOCP的地区选项中选择了中国，那么将不会看到Windows Azure Platform服务。用户可以将地区选为中国香港特别行政区。
在服务明细中，MOCP列举了目前Windows Azure平台所有的计费模式，即2.2.2节中所介绍的几种套餐。单击“立即购买”便进入到订购流程，需要为这个订阅指定一个名字，并填写订购的数量。最后，如果当前用户还没有登记支付信息，则需要首先登记一个有效的信用卡。最后便可以开通Windows Azure平台服务。
在之前的介绍中特别提到过，如果使用者是微软MSDN的付费订户，那么可以获得一个优惠的Windows Azure套餐。这个套餐在刚才提到的MOCP列表中是没有的，用户需要首先登录到其MSDN管理页面，然后单击其中的Windows Azure平台链接，如图3-11所示。而后浏览器会跳转到MOCP的一个专门的Windows Azure订阅页面，即MSDN付费订户的特殊套餐页面。之后通过相同的流程用户便可以购买基于MSDN订户的特别套餐。
图3-11 在MSDN网站使用Windows Azure平台特殊优惠套餐
购买了Windows Azure服务后，用户还可以在MOCP网站检查每个月的使用量和账单信息。在MOCP首页右侧点击“检视我的账单”便会显示当前用户在MOCP上购买的所有服务账单。如果关心Windows Azure订阅每天的使用量，用户可以选择观看每日使用信息，MOCP将会显示当前一个付费周期内每天Windows Azure各个功能（计算、存储、SQL Azure和AppFabric）的使用量和对应的费用。
3.2.4 通过Developer Portal创建Hosted Service
在购买了Windows Azure服务后，使用者就可以将开发好的项目发布到Windows Azure平台上。
参考
Windows Azure Developer Portal的地址是http://windows.azure.com/。
首先需要创建一个Hosted Service。使用Live ID登录Developer Portal。这个Live ID可以是购买这个Windows Azure订阅的Subscription Live ID，也可以是由这个Subscription Live ID的持有者（一般是公司财务或项目经理）在MOCP上面创建的Admin Live ID。当用户输入了正确的Live ID之后就可以登录到Developer Portal。
接下来先简单介绍这个网站的布局，了解各个部分的大致功能以及在本书中的名称，如图3-12所示。
图3-12 Developer Portal各个功能布局
· 标题栏：主要包括当前的登录用户、账单信息链接和退出链接。
· 工具栏：随着用户的选择切换当前可执行的操作。
· 分类栏：当前选择Windows Azure项目下的子项目信息。
· 导航栏：导航到Windows Azure平台的各个功能。
· 主界面：主要的操作界面。
· 属性栏：显示当前在主界面中选中项目的详细属性。
· 状态栏：显示当前刷新状态、隐私策略等信息。
接下来详细介绍各个功能的内容，首先是左下角的导航栏，它显示了目前Windows Azure平台的几个主要的功能模块。
· Home：登录后的默认页面，包含一些Windows Azure平台的帮助信息，以及申请Beta Program。
· Hosted Services，Storage Accounts & CDN：Windows Azure部分。
· Database：SQL Azure部分。
· Reporting：SQL Azure Reporting功能（目前还处于CTP阶段）。
· Service Bus，Access Control & Caching：Windows Azure AppFabric部分。
· Virtual Network：Windows Azure Connect部分。
现在需要在Windows Azure上创建一个新的Hosted Service，因此点击“Hosted Services，Storage Accounts & CDN”项目。然后在左上部分的分类栏里面Developer Portal列举了如下几个子类。
· Deployment Health：所有已创建Service的状态汇总，包括有多少Service处在有效状态、多少个已经被禁用、是否有警告等。
· Affinity Group：管理用户自定义数据中心的配置信息。
· Management Certificates：管理用于Services Management Service的证书。关于这部分内容我们将会在5.1.2节介绍。
· Hosted Services：管理Hosted Service。
· Storage Accounts：管理Storage Service。
· User Management：管理Co-Admin。
· VM Images：管理Windows Azure VM Role所要用到的虚拟机镜像文件。
选择Hosted Services分类，在主界面将会显示当前用户订阅中已创建的Hosted Service。如图3-13所示，当前用户管理着五个订阅，分别是Ethos Tech、Ethos Norway、Dan、PDC08 CTP以及Windows Azure Pass。在Ethos Tech、Ethos Norway和PDC08 CTP这三个订阅中，可以看到已经建立了几个Hosted Service，例如Default Host、KDR Gold Beijing Development Server等。当用户选中了Windows Azure Pass这个订阅后，右侧的属性栏中会显示这个订阅的详细信息，包括：
图3-13 Windows Azure Hosted Service列表
· 这个订阅的购买者Live ID，即图3-13中的Account Administrator部分；
· 创建时间、名字；
· 限额，即当前订阅允许用户创建Hosted Service、Storage Service以及使用的CPU核心的最大个数；
· Admin Live ID，即图3-13中的Service Administrator部分；
· Subscription ID，当前订阅的ID号。当用户需要微软的技术支持以及使用Management API的时候需要指定此ID。
接下来单击工具栏左上角的New Hosted Service按钮来创建一个新的Hosted Service。在弹出的对话框中填入Hosted Service的相关信息，如图3-14所示。
图3-14 创建Hosted Service对话框
· Choose a subscription：选择要在哪个Windows Azure订阅中创建Hosted Service。
· Enter a name of your service：为Hosted Service指定一个名字。这个名字只是在Developer Portal里面显示的，所以可以包含空格、下画线、符号等。
· Enter a URL prefix for your service：为当前Hosted Service指定其URL前缀。
■ Windows Azure平台会为每一个Hosted Service分配一个（仅有一个）在Internet上的三级域名，使用者通过这个域名访问Hosted Service中的服务，例如网站、WCF服务等。
■ 这个域名的格式为“*.cloudapp.net”，这里需要指定的就是当前Hosted Service URL的前缀，即三级域名。假设用户指定为myfirstazureproject，那么最终的域名就是myfirstazureproject.cloudapp.net。
提示
如果用户输入的URL前缀已经被占用了，或者不是一个合法的URL，那么创建Hosted Service的时候将会提示错误。
· Choose a region or affinity group：选择要部署的数据中心，或者从Affinity Group里面选择预定义的数据中心。
■ Windows Azure平台目前在全世界共有六个数据中心，Hosted Service都可以选择任何一个数据中心进行部署。也就是说，在同一个订阅中，Hosted Service可能位于不同的数据中心。而选择的时候一般基于如下两个原则。
◆ 就近原则：数据中心在地理上尽量靠近主要的使用者。例如面向国内的服务，通常选择位于中国香港的东亚数据中心。
◆ 一致原则：应用程序所使用的Hosted Service、Storage Service和SQL Azure尽量选在同一个数据中心，以达到最快的访问速度，同时避免跨数据中心数据传输的费用。
■ 由于上面提到的一致原则，为了尽量保证用户在一个应用程序中的Hosted Service、Storage Service选择同一个数据中心，Windows Azure平台特别提供了名为Affinity Group的功能。所谓Affinity Group，就是用户可以将某个数据中心设置为一个组，提供一个易于记忆的名字。这样当用户需要选择数据中心的时候，就可以通过Affinity Group来指定数据中心。在下拉框中选择Create a new affinity group创建一个新的Affinity Group。在弹出的对话框（如图3-15所示）中设定这个Affinity Group Name为Demo，Location选择East Asia（中国香港数据中心）。这样如果用户还需要创建和当前演示相关的Hosted Service或Storage Service，便可以直接选择Demo这个Affinity Group，保证部署到东亚数据中心。
图3-15 创建新的Affinity Group
· Deployment options：部署选项。用户可以在创建Hosted Service的同时进行部署，也可以只创建Hosted Service而不进行部署。本例中我们不进行部署，仅创建Hosted Service，完成后的对话框如图3-16所示，单击OK按钮开始创建。
图3-16 完成后的创建Hosted Service对话框
几分钟之后，在Developer Portal中便可以看到这个Hosted Service。同时右侧的属性栏显示了它的详细信息，包括Affinity Group、创建时间、DNS前缀、目前使用的CPU核心数、显示名字等，如图3-17所示。
图3-17 完成创建的Hosted Service
完成了上述步骤即表明已经创建好了Hosted Service，但是并没有启用，也就是说这种状态下用户并不需要支付Hosted Service的费用。接下来，我们将刚才开发完成的Windows Azure项目部署到这个Hosted Service上面。
3.2.5 向Staging环境部署Windows Azure应用
前面提到过，Windows Azure平台为每个Hosted Service提供了两个部署环境：Staging环境和Production环境。一般来说，开发人员完成开发后会首先部署到Staging环境进行测试，然后通过VIP Swap功能切换到Production环境中。
回到Visual Studio界面，在解决方案管理器里面选择Windows Azure项目节点，单击鼠标右键并选择Package命令，如图3-18所示。
图3-18 打包Windows Azure项目
在弹出的Windows Azure打包对话框中单击Package按钮，如图3-19所示。Visual Studio将会调用Windows Azure SDK里面附带的打包程序，基于在Windows Azure项目里面定义的Role进行编译，然后压缩成一个文件作为部署包。同时复制Windows Azure项目下面的配置文件ServiceConfiguration.cscfg到部署包所在目录。最后，打开资源管理器并指向这个部署包的位置。
图3-19 Visual Studio部署对话框
接下来返回Developer Portal，选中此前创建好的Hosted Service，然后在工具栏中单击New Staging Development按钮向Staging环境部署，如图3-20所示。
图3-20 在Developer Portal中部署Hosted Service
在弹出的对话框中显示了当前Hosted Service的订阅名、Hosted Service名以及部署，如图3-21所示，接下来需要完成的工作说明如下。
图3-21 创建新的Hosted Service部署
· 输入Deployment Name。这个名字可以是任意字符，主要用来在Developer Portal中显示。一般来说会将部署的应用程序名以及版本号等信息填写在这里。
· 选择部署包文件和配置文件，即刚才通过Visual Studio的发布功能生成的两个文件。
提示
由于Visual Studio在发布完毕后会自动打开资源管理器并定位到部署包文件的路径，因此在Developer Portal中单击Browse Locally按钮后，可以将这个路径复制到打开文件对话框中，快速找到部署包的位置。
之后，当用户单击OK按钮开始部署时会弹出一个警告窗口，如图3-22所示。这是由于当前的ASP.NET MVC 2 Web Role只设定了一个Instance，无法享受Windows Azure计算服务提供的99.95%的高可用性支持。这里单击Yes按钮可忽略这个警告，继续部署。
图3-22 单Instance部署的时候出现的警告窗口
随后在主界面中可以注意到，Developer Portal正在为当前的Hosted Service上传文件，如图3-23所示。
图3-23 Developer Portal上传部署所需的文件
上传完毕后，主界面不断更新部署状态，即分配计算节点、初始化、启动虚拟机以及启动应用程序，直到最后显示为Ready，表明这个应用程序已经成功部署到Windows Azure平台并且已经启动。
如图3-24所示，当前项目已经部署到Staging环境中。它包含了一个名叫MyFirstAzureProject的Role，而这个Role目前只有一个名为MyFIrstAzureProject_IN_0的Instance。如果此时选择Deployment节点，在右边的属性窗口中还可以看到关于这次部署的详细信息，这里就不一一列举了。值得注意的是，DNS Name项显示了这个Hosted Service目前在Staging环境下对外的域名。读者可能注意到这个域名并非当初创建Hosted Service时指定的URL前缀所对应的域名。这是因为目前使用的是Staging环境，而Staging环境使用当次部署的Deployment ID作为DNS前缀。
图3-24 Hosted Service完成部署
点击这个域名链接，在浏览器里面将会看到刚才创建的这个ASP.NET MVC网站了，如图3-25所示。而现在，它是运行在Windows Azure云计算平台上的。
图3-25 在浏览器中访问Staging环境中的Hosted Service
3.2.6 向Production环境切换
Windows Azure平台的Staging环境主要是供测试用的，它的URL是和当次的部署ID有关，因此并不是很友好。在3.2.5节，我们已经将网站部署到了Staging环境中，接下来需要将其切换到Production环境。而这一操作称为VIP Swap。关于VIP Swap更详细的介绍，请参考本书5.2.3节。
Developer Portal为开发人员提供了极为方便的切换方法。如图3-26所示，只需在主界面选中我们的Deployment，然后单击工具栏的Swap VIP按钮。
图3-26 通过Developer Protal进行VIP Swap
在弹出的确认窗口里面列举了目前要切换的Hosted Service名字、Production和Staging环境中分别部署的Deployment Name信息，如图3-27所示。目前在Production环境中没有部署，所以显示Empty。单击OK按钮同意切换。
图3-27 VIP Swap对话框
切换操作在一分钟之内便可完成，之后在主界面便可以看到当前Hosted Service的Deployment、Role和Instance都切换到了Production环境。同时在右侧的属性窗口中DNS Name的值也变为此前创建Hosted Service时指定的URL地址，如图3-28所示。
图3-28 执行了VIP Swap后的Hosted Service信息
单击这个链接便可以打开Production环境下的ASP.NEY MVC网站，如图3-29所示。到此为止，整个部署操作全部完成，我们的第一个Windows Azure应用已经成功运行在Windows Azure云计算平台下。
图3-29 Production环境中的Hosted Service