设计存储组织策略
在设计需要存储数据的应用时，必须考虑到应用要如何在各存储帐户、容器和 blob 之间组织数据。
存储帐户
一个存储帐户已足够灵活，可以整理 blob。 但是你应在必要时使用更多存储帐户，有条理地单独管理成本和控制对数据的访问。
容器和 Blob
在本质上，你的应用及其存储的数据应该能帮助实施你的容器及 blob 命名和整理策略。
如果应用使用了 blob 作为存储方案的一部分，并且该存储方案包含一个数据库，则通常无需重度依赖组织、命名或元数据，这些应用就能显示其数据的一些相关信息。 此类应用通常使用 GUID 等标识符作为 blob 名称，并在数据库记录中引用这些标识符。 该应用将使用数据库来确定 blob 的存储位置及其包含的数据类型。
其他应用更像使用个人文件系统一样使用 Azure Blob 存储。 容器和 Blob 名称指示含义和结构。 这些类型的应用中的 Blob 名称通常类似于传统文件名。 它们可以包括文件扩展名（如 .jpg）来指示它们包含的数据类型。 此类应用使用虚拟目录来组织 Blob。 它们经常使用元数据标记来存储有关 Blob 和容器的信息。
在决定要如何整理和存储 blob 及容器时，需要考虑以下几个重要事项。
命名限制
容器和 blob 名称必须符合一组规则，包括满足长度限制和字符限制。 有关命名规则的更多具体信息，请参阅本模块末尾的“延伸阅读”部分。
公共访问权限和作为安全边界的容器
默认情况下，需进行身份验证才能访问任何 blob。 但是，可配置单独的容器，使其允许公众无需身份验证即可下载其 blob。 公共下载支持很多用例，例如承载静态网站资产和共享文件。 此方法很有效，因为下载 Blob 内容的工作方式与通过 Web 读取任何其他数据的方式相同。 只需将浏览器或任何可以发出 GET 请求的对象指向该 blob URL 即可。
启用公共访问对于可伸缩性非常重要。 直接从 Blob 存储下载的数据不会在服务器端的应用中产生任何流量。 即使你未立即允许公共访问或使用数据库来控制数据访问权限，也仍需计划为要公开提供的数据使用单独的容器。
注意
任何知道这些存储 URL 的人都可以下载已配置为可供公开访问的容器中的 blob，而无需任何类型的身份验证或审核。 绝不要将你不打算公开共享的 blob 数据放到公共容器中。
除了公共访问权限，Azure 还有一个共享访问签名功能，它可用于细化对容器权限的控制。 通过精确的访问控制，可实现进一步提升可伸缩性的方案，因此，将容器视作安全边界非常有用。
Blob 名称前缀（虚拟目录）
容器的结构是扁平的。 它们不支持任何类型的嵌套或层次结构。 如果向 blob 赋予类似文件路径的分层名称（例如 finance/budgets/2017/q1.xls），该 API 的列表操作可以筛选结果，将范围缩小至特定的前缀。 此方法使你能够在列表中导航，如同它是文件和文件夹的分层系统一样。
某些工具和客户端库使用此方法将 Blob 存储可视化以及在 Blob 存储中导航，就好像它是文件系统一样。 每次文件夹导航均触发一个单独的调用，以列出该文件夹中的 blob。 此功能通常称为“虚拟目录”。
注意
如果启用帐户的分层命名空间功能，则目录不再是虚拟的。 相反，它们将成为可以直接操作的具体独立对象。 目录可以存在，但不包含任何文件。 本模块仅介绍未启用分层命名空间功能的帐户。
Blob 类型
可在以下三种不同类型的 blob 中存储数据：
- 块 blob 由不同大小的块构成，你可独立、并行地上传这些块。 在写入到块 blob 时，需要将数据上传到块并将其提交到 blob。
- 追加 blob 是专用的块 blob，它们仅支持追加新数据，而不支持更新或删除现有数据。 它们非常适合此目的。 追加 blob 非常适用于存储日志或写入流数据等方案。
- 页 blob 支持涉及随机存取读写的方案。 页 Blob 用于存储 Azure 虚拟机使用的虚拟硬盘 (VHD) 文件。 它们非常适合涉及随机访问的任何方案。
对于大多数不是特别需要追加 blob 或页 blob 的方案，块 blob 是最佳选择。 其基于块的结构支持快速的上传和下载以及对 blob 各个部分的高效访问。 大多数客户端库会自动管理和提交块。 有些还处理并行上传和下载，以最大程度地提高性能。