本文以 Hadoop 提供的分布式文件系统（HDFS）为例来进一步展开解析分布式存储服务架构设计的要点。
架构目标
不论什么一种软件框架或服务都是为了解决特定问题而产生的。
还记得我们在 《分布式存储 - 概述》一文中描写叙述的几个关注方面么？分布式文件系统属于分布式存储中的一种面向文件的数据模型。它须要解决单机文件系统面临的容量扩展和容错问题。
所以 HDFS 的架构设计目标就呼之欲出了：
- 面向超大文件或大量的文件数据集
- 自己主动检測局部的硬件错误并高速恢复
基于此目标。考虑应用场景出于简化设计和实现的目的，HDFS 如果了一种 write-once-read-many 的文件訪问模型。
这样的一次写入并被大量读出的模型在现实中确实适应非常多业务场景，架构设计的此类如果是合理的。
正由于此类如果的存在，也限定了它的应用场景。
架构总揽
以下是一张来自官方文档的架构图：
从图中可见 HDFS 的架构包含三个部分。每一个部分有各自清晰的职责划分。
- NameNode
- DataNode
- Client
从图中可见，HDFS 採用的是中心总控式架构，NameNode 就是集群的中心节点。
NameNode
NameNode 的主要职责是管理整个文件系统的元信息（Metadata），元信息主要包含：
- File system namesapce
HDFS 相似单机文件系统以文件夹树的形式组织文件，称为 file system namespace - Replication factor
文件副本数。针对每一个文件设置 - Mapping of blocks to DataNodes
文件块到数据节点的映射关系
在上面架构图中，指向 NameNode 的 Metadata ops 主要就是针对文件的创建、删除、读取和设置文件的副本数等操作，所以全部的文件操作都绕不过 NameNode。除此之外 NameNode 还负责管理 DataNode，如新的 DataNode 增加集群，旧的 DataNode 退出集群，在 DataNode 之间负载均衡文件数据块的分布等等。很多其它关于 NameNode 的设计实现分析，后面会单独成文具体解释。
DataNode
DataNode 的职责例如以下：
- 存储文件块（block）
- 服务响应 Client 的文件读写请求
- 运行文件块的创建、删除和复制
从架构图上看到有个 Block ops 的操作箭头从 NameNode 指向 DataNode，会让人误以为 NameNode 会主动向 DataNode 发出指令调用。
实际上 NameNode 从不调用 DataNode，不过通过 DataNode 定期向 NameNode 发送心跳来携带回传的指令信息。
架构图上专门标记了 Rack1 和 Rack2，表明了 HDFS 在考虑文件数据块的多副本分布时针对机架感知作了专门设计，细节我们这里先不展开，很多其它关于 DataNode 的设计实现分析，后面会单独成文具体解释。
Client
考虑到 HDFS 交互过程的复杂性，所以特地提供了针特定编程语言的 Client 以简化使用。Client 的职责例如以下：
- 提供面向应用编程语言的一致 API，简化应用编程
- 改善訪问性能
Client 之所以能够改善性能是由于针对读能够提供缓存（cache），针对写能够通过缓冲（buffer）批量方式。细节我们这里也先不展开，很多其它关于 Client 的设计实现分析，后面会单独成文具体解释。
总结
本来想在一篇文章里写完 HDFS 架构解析的。写着写着发现不太可能。作为分布式系统中最复杂的分布式存储类系统，每一个架构设计权衡的实现细节点。都值得好好推敲，一旦展开此文感觉就会长的没完没了，所以这里先整体过一下。针对每一个部分的设计实现细节再以主题文章来具体解析。
參考
［1］Hadoop Documentation. HDFS Architecture.
［2］Robert Chansler, Hairong Kuang, Sanjay Radia, Konstantin Shvachko, and Suresh Srinivas. The Hadoop Distributed File System
以下是我自己开的一个微信公众号 [瞬息之间]，除了写技术的文章、还有产品的、行业和人生的思考，希望能和很多其它走在这条路上同行者交流，有兴趣可关注一下，谢谢。
