上节 Windows Azure云计算学习笔记1--Windows Azure简介中是对Azure的一个总体概览，这篇将第Windows Azure云计算做深入探讨。
创建Windows Azure应用
-----------------------------------------------------------------------
对于开发人员来说，创建Windows Azure应用和开发一个传统的windows应用很相似，而且Visual Studio提供了做云应用程序开发的模版。为了能在开发机器上模型云环境，微软提供了development fabric，可以在本地计算机上模拟包括web role， worker role，VM role和三种Azure云存储方式等。开发人员可以在本地创建好Azure应用然后在运行在本地的development fabric上测试，就像在真实的云环境中一样。
在本地测试好了之后就可以发布到windows Azure上去了。发布一般会有两个过程，先是发布到彩排区（Staging Area），没问题再发布到生产环境（production），如果发现问题，也可以从生产环境在切换到彩排环境上去。
彩排状态的应用有类似<GUID>.cloudapp.net的域名，用户可以用来做内部测试；发布到生产环境后就可以用自己的域名yourapp.cloudapp.net,或者全部是自己的域名比如 www.newmgdn.com
计算服务（Compute）
-----------------------------------------------------------------------
以前Web Role和Worker Role都只能运行在用户模式下，有些功能就有限制，现在这两个角色都可以运行在admin模式下，你可以干你想干的事，比如装个COM组件啥的。
不过这些都是从一个干净的镜像开始的，所以每次启动一个实例你的COM组件啥的都得重装一遍，少的话还好说，如果很多的话，效率就成问题了。对于这个问题的解决办法就是VM role。你可以弄好一个虚拟机镜像VHD，以后新开实例直接从这个配置好的VHD开始就快多了。而且这种方式（VM Role）还支持在安装过程中可以有用户交互。
还有就是现在的Azure可以让用户指定他的数据放在哪个数据中心上，目前有美国、欧洲和亚洲三个数据中心。
存储服务（Storage）
-----------------------------------------------------------------------
使用Azure 存储服务，需要创建一个存储账号。
Blob--二进制大对象一般就能满足大多数应用程序的需要，视频啊、音频，或者其他什么数据。使用Blob，开发人员需要创建一个容器，每个容器可以保护一个或者多个blob。
要指定特定的blog可以用下面方式的URI：
http://<StorageAccount>.blob.core.windows.net/<Container>/<BlobName>
有两种形式的blob：
块Blob：每个最大200G。为提高传输效率，块blob会分成块，如果传输失败只需再传一遍失败的块就可以了，而不用重新传输整个blob
页blob：最大到1T（1024G），整个页blob被分成512字节大小的页，应用程序可以随机的访问blob中的任意页。
blob相对好理解，表（Table）就复杂些。下图是Table的结构。
每个table包含一系列的entity，entity可以包含属性（或者不包含），属性由名字、类型和值组成。Azure支持的类型有二进制Binary，Bool，Datetime，Double，GUID，int，int64和string。根据值的情况，同一个属性可以在不同时间具有不能的类型，一个实体entity里也可以包含任意类型的entity。
不管包含什么属性，实体entity都作为一个读写单位，最大可以到1M。
可以看出，Azure存储的Table和RDBMS的Table是不一样的，这种结构比RDBMS有更大的可伸缩性，且更简单。
和Azure中的其他对象一样，Table也可以以REST的方式来存取，.net应用可以用WCF 数据服务来存取。其他类型的应用，包括.net也可以用REST的方式俩直接存取，比如用类似下面的URI：
http://<StorageAccount>.table.core.windows.net/<TableName>?$filter=<Query>
如果<query>返回结果多于一个，程序员可以得到一个后续的token用来继续做重复查询直到找到唯一的为止。递归的查就是了。
队列（Queue）
队列Queue主要是设计用来做数据交换用的。他也可以以REST的方式来存取，看下面形式的URI：
http://<StorageAccount>.queue.core.windows.net/<QueueName>
不过Azure中的队列有点意思，和我们普通理解的先进先出队列略有区别，看下面的工作流程：
一般来讲，普通的队列包含两个操作就够了，一个queue一个dequeue，一进一出。但Azure中的queue还有一个删除消息的操作，这是为啥呢？
上面的流程中，首先web role接到用户的请求，然后把计算密集型的任务插入到队列中让worker role来处理。worker role先从队列中取出一个来，并把这个消息在一段时间内标记为hidden，然后就开始处理他。处理完成的话皆大欢喜，到队列中把那个消息删除然后去下一个继续处理。不过万一要是worker role在处理过程中出错了，失败了，那咋办？如果用普通的队列，这个消息估计就会被漏掉了。Azure 队列中的机制是，worker role在Dequeue消息时并不删除消息，只是在一定时间内（5分钟）把他标记为hidden，然后去处理，如果处理失败，5分钟过去后，其他的worker role实例又可以看到这个消息，从而使这个消息能被别的worker role实例来处理。这样的机制保证了每个消息都能被正确的处理一次，从而保证系统的可靠性。
fabric controler
----------------------------------------------------------------------
对于云应用来说，技术服务和存储服务当然最重要，然而没有fabric controler的统一调度管理，他们也干不了啥活。fabric controler拥有数据中心的所有资源，也负责把用户的应用分配到物理计算机上去执行。
比如一个用户有5个web role实例和4个worker role实例，如果把任务指定到特定的实例上，当实例出错时，你的应用也就挂了。 fabric controler把这些资源混搭一下组成容错域（fault domain），每个容错域里有一下计算实例和存储实例，并把云应用分布到不同的容错域上。当某一个实例出问题时，并不会导致整个应用出错。
此外还有更新域（Update Domian）用来关闭系统进行更新操作，并把云应用迁移到更新版本的系统上。
今天结束之前，有些链接：
-----------------------------------------------------------------------
Windows Azure Platform Home Page
http://www.microsoft.com/windowsazure
Introducing the Windows Azure Platform, David Chappell
http://go.microsoft.com/fwlink/?LinkId=158011
Windows Azure Blobs: Programming Blob Storage
http://go.microsoft.com/fwlink/?LinkId=153400
Windows Azure Tables: Programming Table Storage
http://go.microsoft.com/fwlink/?LinkId=153401
Windows Azure Queues: Programming Queue Storage
http://go.microsoft.com/fwlink/?LinkId=153402
今天到此为止，下节课继续学习。