基本構(gòu)架組成

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

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

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