本文以 Hadoop 提供的分散式檔案系統（HDFS）為例來進一步展開解析分散式儲存服務架構設計的要點。
架構目標
任何一種軟體框架或服務都是為了解決特定問題而產生的。還記得我們在 《分散式儲存 - 概述》一文中描述的幾個關注方面麼？分散式檔案系統屬於分散式儲存中的一種面向檔案的資料模型，它需要解決單機檔案系統面臨的容量擴充套件和容錯問題。
所以 HDFS 的架構設計目標就呼之欲出了：
面向超大檔案或大量的檔案資料集
自動檢測區域性的硬體錯誤並快速恢復
基於此目標，考慮應用場景出於簡化設計和實現的目的，HDFS 假設了一種 write-once-read-many 的檔案訪問模型。這種一次寫入並被大量讀出的模型在現實中確實適應很多業務場景，架構設計的此類假設是合理的。正因為此類假設的存在，也限定了它的應用場景。
架構總攬
下面是一張來自官方文件的架構圖：
從圖中可見 HDFS 的架構包括三個部分，每個部分有各自清晰的職責劃分。
NameNode
DataNode
Client
從圖中可見，HDFS 採用的是中心總控式架構，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 的職責如下：
儲存檔案塊（block）
服務響應 Client 的檔案讀寫請求
執行檔案塊的建立、刪除和複製
從架構圖上看到有個 Block ops 的操作箭頭從 NameNode 指向 DataNode，會讓人誤以為 NameNode 會主動向 DataNode 發出指令呼叫。實際上 NameNode 從不呼叫 DataNode，僅僅是透過 DataNode 定期向 NameNode 傳送心跳來攜帶回傳的指令資訊。
架構圖上專門標記了 Rack1 和 Rack2，表明了 HDFS 在考慮檔案資料塊的多副本分佈時針對機架感知作了專門設計，細節我們這裡先不展開，更多關於 DataNode 的設計實現分析，後面會單獨成文詳解。
考慮到 HDFS 互動過程的複雜性，所以特地提供了針特定程式語言的 Client 以簡化使用。Client 的職責如下：
提供面向應用程式語言的一致 API，簡化應用程式設計
改善訪問效能
Client 之所以能夠改善效能是因為針對讀可以提供快取（cache），針對寫可以透過緩衝（buffer）批次方式，細節我們這裡也先不展開，更多關於 Client 的設計實現分析，後面會單獨成文詳解。
總結
蜂小云本來想在一篇文章裡寫完 HDFS 架構解析的，寫著寫著發現不太可能。作為分散式系統中最複雜的分散式儲存類系統，每一個架構設計權衡的實現細節點，都值得好好推敲，一旦展開此文感覺就會長的沒完沒了，所以這裡先總體過一下，針對每個部分的設計實現細節再以主題文章來詳細解析。