基本構架組成

1.網關服務(Gateway):
客戶端發送請求(Request)到網關服務(Gateway)再由網關服務實現將客戶端請求轉換為相應的數據(Data)、元數據(Metadata)，消息對列(MQ)的操作。一般來講網關服務主要承擔以下幾個角色的功能：
協議轉換:實現前端客戶端協議(HTTP/RPC)等向后端模塊(TCP/RPC/MQ)之間的協議轉換。
請求分發:負責將前端請求按不同請求類型(數據操作。元數據操作、異步隊列操作)分發到不同后端模塊上。

協同與調度:部分前端請求可能會同時涉及到與多個后端模塊之間的交互，因此網關服務還需要統一這些請求，并實現多個模塊之間的協同與調度。
負載均衡:實現客戶端請求的負載均衡，提升整體系統的并發吞吐性能。

高速緩存:實現熱數據的高速緩存，提高客戶端請求的命中率，同時降低底層模塊的訪問壓力。當出現底層模塊不可用時，仍然能夠提供部分數據來支撐客戶端的請求訪問，提供類似降級服務，從而在一定程度上提高整體服務的可用性。
正是鑒于上面講到的幾個功能特性，如果把整個對象存儲比作一輛超級大卡車，網關服務相當于“方向盤，變速箱，儀表盤”這些和司機有著密切交道的操控設備，車子開起來順不順手，很大程度上都由這些決定。
2.數據存儲服務(Data store):
同時滿足水平擴展，高性能、高可用等分布式存儲的特性，為整個對象存儲提供底層數據存儲最堅實的基石，用一句話來形容就是"堅如磐石"。數據存儲服務模塊可以對上提供多種類型的數據存儲I/O接口，比如文件存儲、對象存儲、塊存儲，上層通過調用這些標準化的存儲接口，實現對象數據內容的存儲。如果把對象存儲系統比作一輛車，那么數據存儲服務相當于整個對象存儲的"車身、懸架、輪胎"。
3.元數據存儲(KV store):
一個完整的對象數據主要由數據內容和元數據兩部分構成，除了通過上面提到的數據存儲服務以外，一些元數據信息也需要用到存儲。值得注意的是數據內容一般都是非結構化化或者半結構化，但元數據一般都是可以結構化的內容，比如文件的MIME，MD5值、修改時間(mtime)，屬主(ower)等，這些信息一般都是以key-value方式存儲并關聯到具體的對象，而且這些元數據信息經常性的需要進行快速遍歷和查詢、更新等，同時為了更好的做到模塊之間的解耦，將元數據存儲單獨抽離出來并以Key-value方式存儲在特定的KV存儲引擎中變得非常有必要，特別是當對象存儲數據規模到達海量以后，獨立的KV存儲(元數據存儲)能夠極大的避免成為整個系統的性能瓶頸。可以毫不夸張的說元數據存儲的重要性相當于整個對象存儲系統的"傳動系統、變速器"。
4.異步任務隊列(Async queue):
為什么一個對象存儲系統需要用到一個獨立的異步任務隊列系統，相信這是很多新手司機的困惑。同樣也是基于解耦的初衷，讓我們看看下面幾個場景。
1).用戶數據需要進行一些定期的數據操作，比如通過lifecycle，實現定期篩選并清除用戶數據，亦或是定期從熱存儲資源池將數據遷移到冷存儲資源池。
2).用戶已經刪除了對象，底層需要按一定的規則觸發相應的垃圾回收(GC)機制,釋放那些被占用的磁盤空間。
3).用戶需要跨越物理區域去同步多個存儲集群之間的數據，考慮到網絡延遲、磁盤延遲等各方面因素，這些操作都無法做到實時同步。
4).用戶需要將傳上來的數據進行加工處理，比如對上傳上來的視頻文件進行轉碼，對圖片進行壓縮，對文件進行加密等，這些操作都需要消耗大量的計算資源，而且都無法做到實時返回結果。
了解完上面的幾種場景，你會發現，如果采取同步機制去要求所有的客戶端操作都立即返回執行結果，是非常不現實的，至少目前硬件層面還無法做到這么高的實時性，于是我們只能做出適當取舍，設計一個獨立的異步任務隊列來滿足這些需求，把一些耗時操作都丟給這個異步的任務隊列。引入異步隊列系統確實能解決整個對象存儲系統中一些無法實時操作的痛點，但同時也引入了一些新的問題:
1).如何確保用戶的數據一致性，特別是用戶頻繁進行數據和元數據操作的時候，如何保障這些異步操作原子化，最大程度的符合用戶對數據一致性的預期。
2).異步隊列自身的健壯性，如何保障每一個提交到異步隊列的實務(task)能夠實時有效的執行，特別是在異步隊列自身出現故障等各種問題的時候，如何快速有效且正確的去執行這些實務。
3).平滑的水平擴展，如何在處理現有任務隊列的同時確保整個隊列系統的平滑水平擴展。
4).任務時序化和優先級，對象存儲系統一般實現的都是數據的最終一致性，如何確保所有任務嚴格按時間序列或者其他規則執行，如何確定同一時刻對同一個對象的不同操作的優先級順序。
上面只是我這邊簡單羅列的幾個引入異步隊列所帶來的問題，相信各位讀者對這些問題都有著自己不同的理解，一千個讀者就有一千個哈姆雷特，這里因為篇幅有限，我們不再深入下去，談到這些需要思考的問題主要是想告訴各位讀者，異步任務隊列是一把"雙刃劍"，如果你功底深厚可以做出很多超出你想象的功能特性，將整個對象存儲服務在功能上提高好幾個Level，但是反之，一旦陷入深坑，也可能“萬劫不復”。所以我個人的經驗是，對待異步隊列時刻保持警惕態度，盡可能少的去涉及這個模塊，用一句話概括就是"simple is the best"。可以毫不掩飾的說，異步任務隊列是一個對象存儲產品是否成熟的關鍵指標，類似"倒車雷達，定速巡航"一類高級功能，如果把選購對象存儲產品比作選購汽車，這也將成為區別“普通汽車”與“高檔汽車”的關鍵。