推荐三个关于Azure的Session(pdc2008大会)
到目前为止，介绍关于Azure平台的底层架构的文章一直都不多，可以说少的跟“国宝大熊猫”似
的。所幸在PDC2008上有一些相关的信息（主要是一些SESSION和相关的PPTX）。今天就先整理
一下，希望有哪位在微软从事相关工作的兄台出手（在不违反保密协议的前提下）将更多的信息发出
来，让大家一起学习进步。
费话不多说了，开始今天的正文。
Session 1 : Windows Azure: Architecting & Managing Cloud Services
在该SESSION中最让人印象深刻的是对 Fabric Controller(FC)的讲解，这里暂且称之为“组织控
制器”吧。其所要做的事件就是对发布的服务进行资源分派，管理服务生命周期，维护系统正常运转。
如下图所示：
图中左上角的“What” is needed，按我的理解应该“你想要得到的东西”，换句话说是你的需求
是什么。因为微软在之前的宣传中提出过一些信息，即：
而Fabric Controller就是在对这些需求进行分析整理并加以布署实现，在该图的下方我们看到有
两块内容，一个是load-balancers（负载均衡），另一个是switches.
除了Fabric Controller(FC)之外，该Session还讲了关于服务（托管代码）的隔离和安全性问题，
效的域。
FC提供了状态检查点（state check-pointed），其实现的功能包括：
最后该SESSION还发布了在2009年度要做的工作，包括：
I.暴露更多的基础服务模型
II.更加丰富的服务生命周期管理
Session 2: Under the Hood: Inside the Windows Azure Hosting Environment
PPTX下载链接：http://mschnlnine.vo.llnwd.net/d1/pdc08/PPTX/ES19.pptx
看了上面的Session1如果感觉还不过瘾的话，可以看看这个课程，这个Session可以看
过是对之前课程的高级版讲解。里面对FC的讲解要更加透彻（我目前还在看，所以就先不
多说了）
Session 3: Windows Azure: Essential Cloud Storage Services
PPTX下载链接：http://mschnlnine.vo.llnwd.net/d1/pdc08/PPTX/ES04.pptx
该Session讲解的是关于云存储服务相关的内容，因为在之前我看过Azure tookit开发包中的一些
例子，然而却不能完全搞懂Azure平台上是如何存储结构化和非结构化数据的，所以才专门看了这个课
程，一看之下，还真发现了不少门道，下面简要归纳一下：
在Azure平台上要存储数据要使用帐号进行存储。当用户创建相应帐户后，会得到一个256位的加密
串（开发时使用）。在Azure平台上有三个基本的数据（层）抽象，分别是：
即：一个存储帐号可以有许多的Blob Containers(容器)，而一个Container即是一组blob的集合。
所谓的 共享策略需被施加于容器(container)级别之上。
同时该Session也解释了Azure平台上进行服务请求时的URL串的结构，如下图：
当然该Session的精彩之处还不在于此，其所提出的 “使用Blocks机制上传大文件”是一个
不错的亮点。如下图：
2.使用PutBlockList 的例子：
通过这些可以看出，blob结构由一个Blocks列表所组成的。每个block是通过blockid进行标识的，
其ID发布为64字节长。其次每个BLOCK之间是彼此关联，互相影响的。且每个block的最大长度是4M,
但每个BLOCK的大小可以不同。在BLOB讲解最后就是解释了如何使用RESTAPI来操作管理BLOB（更
新，添加，拷贝等）。
而对于Tables存储（结构化数据）的讲解，因为之前我一直不太赞同将 核心数据移入到云平台之后，
所以就没过多关注，但从其介绍的内容中还是可以看出一些很好的地方的，比如数据起码被拷贝三次（
冗余的需要），可以随时访问您的数据，提供以TB为单位的存储空间等等，如下：
说服务总结本身就是消息驱动的。当然在 Azure平台上所提供的异步的消息发送机制，并确保每个消息至
少被处理一次，参见下图：
该图演示当consumer1当机后,消息msg1在30秒之内还是可见(即要求被其它consumer处理)
用户可以使用当前帐户创建多个Queues，每个Queues由一系列消息组成，每个消息长度小于8K.
在该SESSION最后，作者用一张图来总结blobs,tables,queues三种数据抽象所存储结构信息类型。
我想只要记住这张图，这节SESSION应用就没白听了。
好了，今天的内容就先到这里了。
的。所幸在PDC2008上有一些相关的信息（主要是一些SESSION和相关的PPTX）。今天就先整理
一下，希望有哪位在微软从事相关工作的兄台出手（在不违反保密协议的前提下）将更多的信息发出
来，让大家一起学习进步。
费话不多说了，开始今天的正文。
Session 1 : Windows Azure: Architecting & Managing Cloud Services
PPTX下载链接：http://mschnlnine.vo.llnwd.net/d1/pdc08/PPTX/ES02.pptx
在该SESSION中最让人印象深刻的是对 Fabric Controller(FC)的讲解，这里暂且称之为“组织控
制器”吧。其所要做的事件就是对发布的服务进行资源分派，管理服务生命周期，维护系统正常运转。
如下图所示：
图中左上角的“What” is needed，按我的理解应该“你想要得到的东西”，换句话说是你的需求
是什么。因为微软在之前的宣传中提出过一些信息，即：
Windows Azure管理服务并不仅仅是服务器，它是“告之它你想要的，然后它就会自己实现相
关细节”的这样一个平台。
关细节”的这样一个平台。
而Fabric Controller就是在对这些需求进行分析整理并加以布署实现，在该图的下方我们看到有
两块内容，一个是load-balancers（负载均衡），另一个是switches.
除了Fabric Controller(FC)之外，该Session还讲了关于服务（托管代码）的隔离和安全性问题，
如下图:
效的域。
FC提供了状态检查点（state check-pointed），其实现的功能包括：
I:用于回滚到前一个检查点。（按我的理解：服务的执行可能会出现中断或失败，当出现这种情况
时，可以回滚到最近的成功执行的检查点继续执行）。
II:同时预防中断或FC状态的丢失。
III:跨失效域（fault domain）的存储（注：失效域应该是指在Azure平台上那些服务器或主机出
现硬软故障或进行升级服务时节点）
时，可以回滚到最近的成功执行的检查点继续执行）。
II:同时预防中断或FC状态的丢失。
III:跨失效域（fault domain）的存储（注：失效域应该是指在Azure平台上那些服务器或主机出
现硬软故障或进行升级服务时节点）
最后该SESSION还发布了在2009年度要做的工作，包括：
I.暴露更多的基础服务模型
II.更加丰富的服务生命周期管理
Session 2: Under the Hood: Inside the Windows Azure Hosting Environment
PPTX下载链接：http://mschnlnine.vo.llnwd.net/d1/pdc08/PPTX/ES19.pptx
看了上面的Session1如果感觉还不过瘾的话，可以看看这个课程，这个Session可以看
过是对之前课程的高级版讲解。里面对FC的讲解要更加透彻（我目前还在看，所以就先不
多说了）
Session 3: Windows Azure: Essential Cloud Storage Services
PPTX下载链接：http://mschnlnine.vo.llnwd.net/d1/pdc08/PPTX/ES04.pptx
该Session讲解的是关于云存储服务相关的内容，因为在之前我看过Azure tookit开发包中的一些
例子，然而却不能完全搞懂Azure平台上是如何存储结构化和非结构化数据的，所以才专门看了这个课
程，一看之下，还真发现了不少门道，下面简要归纳一下：
在Azure平台上要存储数据要使用帐号进行存储。当用户创建相应帐户后，会得到一个256位的加密
串（开发时使用）。在Azure平台上有三个基本的数据（层）抽象，分别是：
Blobs ：提供一个简单接口来用户存储非结构化数据文件（图片，普通文件等）和相关的元数据（我
想可能会用于数据文件同步的需要）
Tables ：提供结构化存储。该Table 是一组entities, 该entities包括一系列的属性
Queues ：提供可靠的数据存储并对相应的应用（服务）发送消息（messages）
想可能会用于数据文件同步的需要）
Tables ：提供结构化存储。该Table 是一组entities, 该entities包括一系列的属性
Queues ：提供可靠的数据存储并对相应的应用（服务）发送消息（messages）
关于Blobs （非结构化文件存储），其提出了下面的概念：
即：一个存储帐号可以有许多的Blob Containers(容器)，而一个Container即是一组blob的集合。
所谓的 共享策略需被施加于容器(container)级别之上。
同时该Session也解释了Azure平台上进行服务请求时的URL串的结构，如下图：
当然该Session的精彩之处还不在于此，其所提出的 “使用Blocks机制上传大文件”是一个
不错的亮点。如下图：
1.原理分析：
2.使用PutBlockList 的例子：
3.然后是上传之后的图形讲解：
通过这些可以看出，blob结构由一个Blocks列表所组成的。每个block是通过blockid进行标识的，
其ID发布为64字节长。其次每个BLOCK之间是彼此关联，互相影响的。且每个block的最大长度是4M,
但每个BLOCK的大小可以不同。在BLOB讲解最后就是解释了如何使用RESTAPI来操作管理BLOB（更
新，添加，拷贝等）。
而对于Tables存储（结构化数据）的讲解，因为之前我一直不太赞同将 核心数据移入到云平台之后，
所以就没过多关注，但从其介绍的内容中还是可以看出一些很好的地方的，比如数据起码被拷贝三次（
冗余的需要），可以随时访问您的数据，提供以TB为单位的存储空间等等，如下：
对于Queues应该是Azure平台的一个重点，因为消息这种数据结构在ServiceBus中是核心数据，可以
说服务总结本身就是消息驱动的。当然在 Azure平台上所提供的异步的消息发送机制，并确保每个消息至
少被处理一次，参见下图：
该图演示当consumer1当机后,消息msg1在30秒之内还是可见(即要求被其它consumer处理)
用户可以使用当前帐户创建多个Queues，每个Queues由一系列消息组成，每个消息长度小于8K.
在该SESSION最后，作者用一张图来总结blobs,tables,queues三种数据抽象所存储结构信息类型。
我想只要记住这张图，这节SESSION应用就没白听了。
好了，今天的内容就先到这里了。
更多关于Azure平台的Session可以访问：http://channel9.msdn.com/tags/pdc2008.azure/
原文链接:http://www.cnblogs.com/daizhj/archive/2008/12/22/1359727.html
作者: daizhj, 代震军
Tags: azure,serverbus,blobs,tables,queues,云存储,服务总线
网址: http://daizhj.cnblogs.com/