【IT168 专稿】微软的Windows Azure云计算平台自从2月份发布收费版以来，使用的人数正在膨胀。就在上周达到了1000个收费用户；而且，Azure正在不断改进，目的是成为刚起步的云计算市场的有力竞争者。

▲

　　尽管Google、Amazon和微软提供的云计算产品大体上比较相似——他们分别提供各自的“计算(例如应用软件)”和“存储”块——但是这些服务的提供方式确实截然不同的。当然，除了这三家，还有一些其他的厂商，但是这三个家喻户晓的名字是这个市场上具有很大的代表性的，并且，事实证明，这三家厂商在市场采用和影响方面都是最重要的。

　　云计算入门

　　云计算领域的一大重头产品是Amazon的弹性计算云(Elastic Compute Cloud http://aws.amazon.com/ec2/，EC2)，EC2可以让用户选择他们虚拟机上的操作系统，并对所选的操作系统进行配置。客户甚至可以创建并上传自己的镜像。软件可以在任何可以在镜像上运行的环境中运行。这些镜像可以使用SSH，远程桌面或其他更好的机制进行管理和配置。想在虚拟机上安装软件么?只需运行安装程序就可以了。

　　云计算领域的另一典型代表是Google的App Engine。App Engine软件运行在沙盒中，仅仅提供有限的底层操系统的访问。应用程序的编写语言只能是java(至少是JVM的目标语言)或者是Python2.5。沙盒阻止了一些基本的操作，如写磁盘或打开网络socket。

　　处于EC2和Google App Engine之间的是微软的Window Azure。在Azure中，没有对操作系统的直接访问，也不能直接访问运行在OS之上的软件——它就像是Windows的变种，它优化了可扩展性，在.NET的运行时环境下运行类似IIS的Web服务却没有Google环境下那么多限制，尽管.NET是更好的开发平台，它支持PHP、Java、有必要的时候还可以采用本地编码。唯一的限制是软件必须是无需安装就可以部署，即它不支持简单的复制到目录然后运行。

　　存储系统是十分多变的。Amazon有四个存储系统，第一个是使用最广泛的简单存储服务(Simple Storage Service，S3),S3提供了简单的名字值匹配，这个值可以是一个大小高达5GB的BLOB(Binary Large Object,二进制大对象)。第二个是弹性块存储(Elastic Block Store，EBS),EBS提供的是虚拟的块设备，这些设备可以像硬盘一样被格式化，并用来存储有规律的文件。Amazon的第三个存储系统是关系数据服务(Relational Database Service ，RDS)，RDS提供的是MySQL数据库。最后一个是数据库系统是SimpleDB。

　　SimpleDB是一个非关系型数据库;它采用一种非关系形的表格存储数据。与常规的关系型数据库相类似，这些表格所存储的每一个条目(客户、订单、地址等等)都有自己的属性(因此，一个客户可能会有一个姓名、地址和一个电话号码)。与典型的数据库不同的是，SimpleDB可以不刷新表格中现有的记录就可以添加新的属性。表与表之间没有关系，也不支持关系型数据库中的连接。如果应用程序要访问与另一个表相对应的一个表中的数据，他们将不得不进行手工的查找。

　　删减掉这些特征的原因是通过减少关系型数据库的所有限制，运供应商就可以更灵活地实现查询优化和数据存储。尽管限制这些特征，对一些有过关系数据库开发背景的人来说很艰难，但是对许多应用来说还是足够丰富了。

　　Google提供的主要存储方案是它的datastore【http://code.google.com/intl/zh-CN/appengine/docs/python/datastore/overview.html】，datastore和SimpleDB一样广泛。Google还提供另外一种服务，叫做blobstore，类似于S3的服务。这家公司的标准的App Engine服务不支持SQL数据库的特征，但是，Google打算为商业版的App Engine平台的客户提供关系型数据库服务，现在预览版已经上线。

　　微软的存储产品线与Amazon的大体差不多。Azure Storage既包括类似S3的专用二进制存储，又有类似SimpleDB的类似表单的存储。它还提供了特殊的VHD磁盘印象的支持，这些磁盘印象可以像驱动一样挂载，这类似于Elastic Block Store。最后，微软还有一个叫做SQL Azure的SQL服务器，SQL Azure为云端应用提供了几乎所有的SQL Server的特性。

　　除了常规的存储选择之外，Amazon和Microsoft都提供了队列服务。队列服务允许信息以一种可靠地、不同时的方式在应用软件间被交换。应用软件编辑者将信息导入列队，然后应用软件使用者能这空闲时很快的从列队中读出这些信息。

　　由于设计决策不同，不同的平台所优化的应用也不同。EC2使得在云环境中部署“常规”软件变得简单：将软件安装到镜像中，使用EBS磁盘存储数据，甚至可以对应用一无所知。相反，App Engine平台上的应用，必须是为该平台专门创建的。

　　Azure处于两者之间。现有的Web应用，特别是使用ASP.NET创建的应用，可以很容易地迁移到Azure上。他们可以使用常规的SQL 服务器(或类似的其他服务器)，有必要的话，他们还可以使用本地遗留的代码，但是这个平台去掉了许多传统的管理任务，如操作服务器、管理数据库等。

　　Azure似乎也吸引了许多微软的用户，尽管可扩展性是人们最常说的云计算的优势，但是大约有一半的Azure设备都是单实例的。这意味着，一个应用程序仅仅部署在一个虚拟机上，Azure被用作一种减少常规应用的运营成本，而不是用来多机器的快速简单扩展。

　　这对我来说当然也很有吸引力。虽然我不能算是一个真正的Web app开发者，但是Azure使得我能够使用现有的.NET技术，并且不用管系统管理，确实是很有诱惑力。所以，让我们一起来体会Azure的开发细节吧!

　　踏上Azure开发之旅

　　尽管Azure开发可以使用PHP或者是Java，但是Azure平台最支持的——也是我将要使用的，是.NET。第一步是安装Azure SDK。有两种办法：你可以使用独立的SDK，也可以安装一个包含VS 2008、VS 2010和SDK的包。由于我是图形界面开发的倡导者，而且对在命令行下创建和部署软件毫无兴趣，因此我选择了后者。

　　在管理和存储服务方面，Azure提供了使用HTTP和XML的REST API【http://en.wikipedia.org/wiki/Representational_State_Transfer】。然而，对软件开发来说，使用HTTP和XML是一件很无聊的事情。SDK包含了一套客户类，这些类提供了很好管理的.NET API，因为这些类对HTTP和XML底层的通信细节进行了抽象。

▲开发组件(The Development Fabric)有一些很方便的特征，比如控制台的喷涌式注销;而以前在云中不能很简单地访问他们

　　就像这些客户端库一样，SDK包含了一个有两部分组成的本地部署环境：用于部署应用的“Development Fabric”和提供Azure 的大规模云端存储的“Development Storage”。平时的开发中，您将在这样的环境下进行部署和调试。对大部分应用来说，不会感觉到有什么不同，虽然Development Storage系统跟真正的Azure存储相比有一些限制。

　　Visual Studio的集成是必需的

　　Visual Studio的集成为扩充了Azure的项目类型，F5部署上去和Development Fabric的调试，以及上传应用到云中并将其运行在付费的Azure服务上的功能。

　　显然，你将会想要将部分应用部署到云端。为了实现这个目的，你就要申请一个Azure账号。点击绿色的大按钮，并提交相关的信用卡信息(最好是自己的)。Google的App Engine为小型应用和开

▲

发成果提供了免费的配额，这不可否认是一个很诱人的特征，但是它没有Microsoft那么多的选择。

　　最近， MSDM订阅者数量有所提升，主要是由于订阅赠送额外的费用或者更多的优惠活动，比如，他们可以免费使用价值为订阅费用一部分的Azure资源。尽管优惠没有Google提供的那么大，还是给了很多.NET开发者直接访问Azure的机会，并进行尝试。

　　开了账户以后，你就能够创建不同的服务：如支持BLOB(包括挂在驱动)、表格和队列的存储账户，还有用于运行实际应用的托管服务。在创建服务的时候，我们可以选择将自己的应用托管到世界上的一个地方。一般情况下，你会希望应用尽可能离用户近一些，并且会想让存储账户离托管服务进一些。地理环境对延迟和可靠性有很大的影响——云计算使得全球范围内的分布式服务特别简单，因此自然和认为的灾害都不能危害到服务。

▲创建服务

　　每一个服务都可以被一组终端识别——URIs能用于REST 查询——所有的操作都使用这些终端。使用这些端点是受限制的。连接一个储存端点需要使用一个长的、64位的密钥。托管所使用的终端的管理采用认证(幸运的是，Azure可以产生合适的认证，因此可以避免PKI的复杂性)。

　　SQL Azure的操作与常规的SQL Server有些不同。SQL Azure利用DDL命令管理数据库的能力是仅仅有限的，意味着许多现有的数据库脚本如果不加修改的话可能不能运行。数据库用户和角色的创建和配置也是有限制的，相对常规的SQL Server来说。

▲配置SQL Azure

　　与SQL Azure的通信与常规的SQL Server相同，都是用1433端口，而不是HTTP的端口。这意味着软件可以与SQL Azure对话，就像与SQL Server对话一样。这包括SQL Server Management Studio,常规SQL Server开发使用的前端。表格、存储过程、触发器等等都可以想平常一样创建，但是管理设备不能。

▲将服务配置放到Visual Studio中

　　创建了服务以后，最后剩下的一件事情就是将存储配置放到应用中(告诉应用使用存储账户，而不再使用开发存储)，并告诉部署工具(Visual Studio集成开发环境或者是命令行工具)使用何种认证。任何使用SQL Azure开发的应用，都将需要一个适合的连接字符串，这可以通过SQL Azure Web的前端来产生。

▲分段运输环境不是所有人都可以用

　　部署的时候，我们可以将其部署到分段服务器上或直接部署到。。。(并不是所有人都做过)。分段不熟的环境与产品不同的是，它有着难看的GUID域名。点击页面中间的双箭头键将staging environment导入分段部署环境。这个操作很快;配置改变了主机名，因此产品变成了staging ，staging变成了产品。

　　▲你可以直接在这部署

　　现在所剩下的就只有编写应用程序这个较小的任务。作为例子，我将把Twitter的最差的克隆版——Chirp部署上去。这将由两部分组成：一个前端Web角色和一个后台的工作角色，前台Web角色是一个小型的难看的网站，它具有基础的用户注册和访问chirp的能力，后台的角色是用来进行一些费时间的数据处理。

　　用户数据库将被储存到SQL Azure中。然而，Chirps将使用Azure table。每一个使用者都会有一个别名，这个别名存储在一个Azure BLOB中。后台的工作者角色负责产生一系列的不同长度的别名。每一个新的改变长度的请求都会放到Azure队列中，以确保前端的Web应用不需要等待重置长度。

　　原文地址：http://arstechnica.com/microsoft/guides/2010/06/microsoft-azure-for-nubcakes.ars