本文属于【Azure 架构师学习笔记】系列。
本文属于【Azure Storage Account】系列。
接上文 【Azure 架构师学习笔记】-Azure Storage Account（4）- ADF 读取Queue Storage
前言
不管在云还是非云环境中， 存储是IT 系统的其中一个核心组件。在Azure 上，云存储主要以存储帐户（Storage Account）来实现。在使用Storage Account时，又有很多需要考虑的事项，比如安全，高可用，文件结构等。
本系列分3篇文章，以最常用的Azure Data Lake Store Gen2 （ADLS Gen2）作为例子演示一些架构方面的配置和考虑， 包括：Storage Account的物理结构、文件系统设计、安全配置。
Data Lake Layers
Storage Account是一个物理资源，但是根据现实的软件环境，又需要分为类似DEV， SIT， UAT， PROD等环境，通常每个环境会独立使用一个资源以实现环境隔离。所以首先分层的是环境。
存储帐户
在每个环境中，会有一个或多个Storage Account，在配置的时候，可以有很多选项，要按照实际情况选择，很多选项明确指明在创建后不可修改。另外也并不是所有选项都支持当前选择的所在区域。
在Storage Account下面，会有4个Feature： Container， File Shares， Queues， Tables。 最常用的就是Container， 它可以理解为一个文件系统，以分层形式存储文件。
文件系统
如果没有文件系统，文件只是像一盘沙子那样铺在存储帐户上，为了更好地组织和管理文件， 需要借助文件系统，类似Windows上的文件夹结构。除了文件本身的层级结构之外，还有一些其他需要关注的属性：
Public Access Level：
在新建container的时候会注意到有这些选项，除了名字之外，匿名访问"Anonymous access level"是显示private并且为灰色意味着当前不可修改， 需要从storage account中开启。
如果要启用，可以从overview页点下图部分进去修改：
启用后即可看到新建时的可选项。
创建之后进入container的属性页
然后点击“Access Policy”可以看到有两个access policy：
- Stored access policies：可以通过配置来控制Shred Access Signatures (SAS) 的起止时间。
- Immutable blob storage：提供单次写多次读的机制，当数据写到存储帐户后数据变成不可修改，可以通过策略来控制。
点开"Stored access policies"：控制的是SAS token的有效期和允许的操作， 这是container 级别的控制，在存储帐户级别也有类似的配置，如果同时存在，则以container的优先。
点开"Immutable blob storage"： 有两类选项，默认的“Legal hold”可以应用在数据层面用于保护数据不被修改和删除。
小结
本文初步介绍了存储帐户的概述，但是实际上光这个服务就足够用上百篇文章来解释，所以把内容拆散以免阅读疲劳。
接下来的一文将介绍Container（文件系统）内部的结构。
