Windows Azure Storage(WAS)是微软Azure云计算的基础存储设施，为Azure上层产品提供包括Blob、Table、Queue在内的统一存储服务，命名缩写WAS倒是与AWS有几分相似，乍看起来很容易混淆。
该专栏接下来的几篇将根据WAS发表的论文对WAS做较为详细的解读，由于论文信息量比较大，我会将其拆解为四个部分分别介绍，包括：
- 整体架构：主要介绍WAS的整体架构以及对各个模块作简要说明
- 模块解析：主要介绍以下几个子模块：
- StreamLayer解析：介绍WAS的文件存储层架构极其相关技术
- PartitionLayer解析：介绍WAS的逻辑存储层架构极其相关技术
- FrontEnd解析：介绍WAS的前端接入层的设计
WAS作为Azure云计算的底层存储设施已经在2008年左右便开始在生产环境提供服务，迄今已10年有余，其架构的合理性应该得到了较为充分的验证，同时作为公有云的核心设施，不太可能发生大的架构调整，因此，该论文虽然发表时间已经较长，但是仍值得仔细研读(个人还是对Microsoft的工程能力挺叹服的)。
好了，话不多说，我们直入主题，本文主要介绍WAS的整体架构。我们就不再介绍WAS到底是个什么产品以及扮演什么角色了，这些信息均可以在论文中找到相关介绍。
整体架构
首先，用户很多时候不太会直接与WAS打交道，而是通过其包装的其他云产品来使用WAS(如ECS、对象存储、表格存储、消息队列等)。通过URL来访问WAS服务。URL形式为：
https://AccountName.service.core.windows.net这里面几个关键的部分：
- AccountName：使用公有云服务的账号名称，这由客户通过控制台创建，一旦创建，该账号的存储位置便确定好，因此，通过AccountName，Azure的DNS服务便可以将流量定位至特定的存储区域
- service：Azure服务名称
我们从底之上梳理WAS架构：
- Storage Stamp：我们可以称之为存储单元，一般是位于同一个数据中心内的一堆存储节点构成的存储集群
- LocationService：顾名思义，WAS的位置服务，管理全局所有StorageStamp，统计StorageStamp的负载等信息，创建Account时根据负载决定将Account创建至哪个StorageStamp，LocationService也是多级集群以实现服务高可用
- DNS：根据AccountName查找其所在的StorageStamp，LocationService决定了AccountName所属的StorageStamp后会将该信息同步至DNS
接下来重点分析下StorageStamp架构。
Storage Stamp
存储单元，一般是位于同一个数据中心内的一堆存储节点构成的存储集群。而Azure作为一个全球云服务，形成了Region、DataCenter、Storage Stamp一个树形结构的存储拓扑结构：
按照论文描述，每个Storage Stamp由10~20个Rack(机架)构成，每个Rack内放置18个高密度存储节点，总的存储容量约为2PB左右，时至今日，恐怕早已突破10PB大关。因此，每个Storage Stamp内便是一个独立自治的分布式存储系统，通过StorageStamp的横向扩展来实现系统容量的进一步提升。
作为一个功能完备的统一存储单元，Storage Stamp又按照功能层次划分为以下几个组件：
- Stream Layer：文件存储层
- PartitionLayer：负责为统一存储提供更高层次的语义抽象
- Fronts-End：前端接入层，无状态，负责路由请求至特定节点
- VIP：虚拟ip层，负责将请求负载均衡至各前端接入层节点
同样，我们逐一简单介绍这几个组件，由于篇幅关系，本文不作深究。
Stream Layer
该层提供数据存取服务，之所以成为Stream Layer，是因为其不解释数据语义，仅仅将上层数据当做字节流，但需要提供数据存储格式组织、数据可靠性。可用性等一些列分布式存储系统该有的功能。
Partition Layer
WAS作为统一存储平台，其提供各种存储产品形态，有Blob存储、表格存储、消息队列等，Partition Layer
便是设计作为统一的存储抽象层，将所有的产品统一为通用存储需求并与Stream Layer对接。
Frons-End
前端接入层，无状态，负责路由请求至Partition Layer特定节点
VIP
虚拟ip层，负责将请求负载均衡至各前端接入层节点
