Amazon S3  全稱Amazon Simple Storage Service,旨在通過web服務(wù)接口提供業(yè)界領(lǐng)先的性能、速度、安全性、可伸縮性和數(shù)據(jù)可用性。該平臺由亞馬遜網(wǎng)絡(luò)服務(wù)(AWS)開發(fā)，并于2006年3月14日首次推出,后續(xù)S3逐漸演變?yōu)閷ο蟠鎯Φ臉?biāo)準(zhǔn)。

隨著公司的快速發(fā)展,公司內(nèi)對各種圖片、視頻、文件等這類對象的存儲需求越來越強(qiáng)烈。

目前公司內(nèi)的接入場景包括，二維碼，景區(qū)推薦視頻，圖片，css，js，ML訓(xùn)練素材等資源，大約10億+文件數(shù)。都是核心的業(yè)務(wù)場景,如果存儲服務(wù)故障，影響的范圍會比較大，比如掃不了入園二維碼，訪問不了圖片等。

由于歷史原因，現(xiàn)在公司內(nèi)提供類似存儲的服務(wù)有好幾套，包括Ceph s3，F(xiàn)astDfs+Redis(做元數(shù)據(jù)存儲)，公有云 s3代理等，幾套服務(wù)都有比較明顯的問題。比如公有云 s3，使用成本相對比較高,而且走外網(wǎng)交互性能得不到保障；比如Ceph，想完全維護(hù)好需要投入大量的成本，性價(jià)比不是很高；再比如fastdfs+redis，接入不太友好，支持不了主流的S3。所以我們提供了一套新的對象存儲服務(wù)來解決以上問題，本文會詳細(xì)介紹，我們新的對象存儲服務(wù)(OSS)是怎么做的。

01 設(shè)計(jì)目標(biāo)

整體的設(shè)計(jì)目標(biāo)如下：

可擴(kuò)展: 至少需要支持到10億+的對象數(shù),并且需要有水平擴(kuò)展的能力；

高可用: 要做到高可用,至少要有隔離,多租戶,限流,災(zāi)備/雙活等能力,最核心業(yè)務(wù)甚至可以做到不同存儲產(chǎn)品的災(zāi)備；

高性能: 需要足夠快,類似ceph rados,后續(xù)需要可以作為分布式文件存儲的存儲底座；

低成本: 可以用遠(yuǎn)低于ceph的成本支撐所有的業(yè)務(wù)；

接入簡單: 能夠支持主流對象存儲S3協(xié)議的接入；

無縫升級: 可以在業(yè)務(wù)無感知的情況下,穩(wěn)定的、無縫將業(yè)務(wù)從ceph s3,公有云 s3遷到新oss。

02 系統(tǒng)設(shè)計(jì)

簡單來說，設(shè)計(jì)目標(biāo)可以拆分成2個(gè)點(diǎn):

• 需要一個(gè)非常強(qiáng)大的對象存儲oss服務(wù)
• 如何在架構(gòu)層面解決業(yè)務(wù)無縫切換,存儲無縫升級從而保障業(yè)務(wù)的穩(wěn)定性

下面我將從這2點(diǎn)來介紹下我們是怎么做的。

oss技術(shù)選型

近些年越來越火的開源+商業(yè)化的模式讓每個(gè)方向都或多或少出現(xiàn)了一些比較好的開源產(chǎn)品,比如時(shí)序存儲方向的TDengine,OLAP方向的ClickHouse等等,在對象存儲選型的時(shí)候,我們也優(yōu)先考慮開源產(chǎn)品,通過開源共建的方式來完成我們的產(chǎn)品,盡量不從0開始造輪子。整個(gè)社區(qū)看下來,相對比較熱門的有minio,SeaweedFS,fastdfs,ceph。其中ceph跟fastdfs不在考慮范圍內(nèi),所以精力就放在minio跟SeaweedFS上,看是否能滿足要求。

minio

minio應(yīng)該是目前最火的開源對象存儲，github 3w4的star數(shù)。

minio的優(yōu)點(diǎn)包括:

• 友好的UI
• 部署比較簡單,很容易上手
• 支持文件級別的自愈,在節(jié)點(diǎn)故障時(shí)無需人工干預(yù)
• 全EC存儲,成本相對比較低
• 中大文件性能比較好
• 基于文件系統(tǒng)設(shè)計(jì),無需額外的存儲來存儲元數(shù)據(jù)

同樣minio的缺點(diǎn)也相對明顯：

• 僅支持EC,會存在io放大的問題,特別是在大量小文件的場景下
• 擴(kuò)容不太友好,對等擴(kuò)容時(shí)需要全集群停止服務(wù)
• 支持的文件數(shù)量有限,基于本地文件系統(tǒng)設(shè)計(jì),在對象數(shù)變多以后,inode的查找都會變得很耗時(shí)

minio是一款有明顯優(yōu)缺點(diǎn)的產(chǎn)品,在我們的需求背景下,minio不能夠很好的滿足,特別是不能夠支持我們10億+對象存儲需求,而且在現(xiàn)有的架構(gòu)設(shè)計(jì)下,也不太好改造,然后通過與社區(qū)共建的方式來滿足我們海量小文件的需求。

SeaweedFS

越來越火的對象存儲開源方案,github star數(shù)1w5+,且增長速度比較喜人,社區(qū)也比較活躍。

SeaweedFS官方介紹的核心點(diǎn)有2個(gè)：

• to store billions of files!
• to serve the files fast!

跟我們的部分核心目標(biāo)比較貼近。

核心優(yōu)點(diǎn)包括:

• 性能比較強(qiáng)大: 核心理論依據(jù)是基于 Facebook's Haystack design paper ,該paper的目標(biāo)也是解決facebook內(nèi)部圖片視頻等數(shù)據(jù)的存儲查詢問題
• 架構(gòu)設(shè)計(jì)比較靈活: 系統(tǒng)設(shè)計(jì)參照了Facebook’s Tectonic Filesystem ,特別是幾個(gè)核心組件的設(shè)計(jì),抽象的比較好,非常方便擴(kuò)展不同的實(shí)現(xiàn),并且整體架構(gòu)上可以水平擴(kuò)容,沒有明顯的瓶頸點(diǎn)
• 功能齊全: 存儲比較關(guān)心的冷熱分離,EC存儲,TTL等功能都有支持
• 部署簡單: 部署非常簡單,很容易上手

相比于優(yōu)點(diǎn),也會有些不足

• S3的適配不完全: 實(shí)現(xiàn)了大部分的常用接口,部分非常用接口未實(shí)現(xiàn),比如Canned ACL等。
• 項(xiàng)目背景: 相比于minio等開源產(chǎn)品后面都是強(qiáng)大的商業(yè)化公司,該項(xiàng)目核心的作者只有 chrislusf 大神

從各個(gè)維度來看,基于SeaweedFS開源共建的方式來打造我們的對象存儲服務(wù)是目前比較合理的方案。

系統(tǒng)架構(gòu)

架構(gòu)介紹

確定選型SeaweedFS后，下一步就是怎么來設(shè)計(jì)整體服務(wù)來滿足我們的需求，簡易架構(gòu)如下：

整體架構(gòu)其實(shí)是一個(gè)比較常見的架構(gòu),非常簡單

• Proxy層: 來適配不同的Api以及對業(yè)務(wù)做存儲適配
• 存儲層: 包括SeaweedFS,Ceph s3,公有云 s3. 公有云 s3的操作跟Ceph s3類似,本文就不展開了
• 管控平臺: 可視化UI,做權(quán)限配置,配額配置,數(shù)據(jù)列表等

名詞解釋：

• 公有云 s3 Api: 公司內(nèi)部之前封裝的公有云 s3對外的Api
• Efs Api: 公司內(nèi)部之前封裝的對外的靜態(tài)資源相關(guān)的Api
• S3 Api: 適配了S3的所有Api
• StoreAdapter: 來根據(jù)配置來處理業(yè)務(wù)的請求,選擇存儲適配
• Filer/s3 Api: SeaweedFS用來對外暴露s3等相關(guān)Api的服務(wù)
• DCDB: 公司基于BaiKalDB共建的分布式數(shù)據(jù)庫,下文會詳細(xì)介紹
• BlobStorage: SeaweedFS中用來實(shí)際做對象存儲的模塊

設(shè)計(jì)目標(biāo)詳解

可擴(kuò)展

目標(biāo): 至少需要支持到10億+的對象數(shù),并且需要有水平擴(kuò)展的能力。

proxy是無狀態(tài)的,可以做到水平擴(kuò)展,所以只需要SeaweedFS做到可以水平擴(kuò)展就可以滿足我們的需求了。

從整體架構(gòu)上來看,SeaweedFS核心的有2層(S3存儲最核心的基本都是這2塊)

• File Storage: 用來做metadata元信息的存儲以及做api的適配
• Blob Storage: 對象存儲的底座

metadata的能力是比較核心的一個(gè)環(huán)節(jié),他至少需要做到:水平擴(kuò)展能力,不丟數(shù)據(jù),讀寫性能比較好,高可用。類似的服務(wù)有:Cassandra,Tidb,YDB,toctonics用的ZippyDB等等?；谖覀児粳F(xiàn)狀,我們選擇了跟BaiKalDB共建的分布式數(shù)據(jù)庫DCDB。

DCDB在我們公司使用的比較多,性能得到了很好的驗(yàn)證,并且能夠很 好的匹配 我們的訴求。 在引入DCDB做元數(shù)據(jù)服務(wù)后,測試下來讀寫請求的平均耗時(shí)在1ms內(nèi),能夠滿足我們的需求。

以上是dcdb真實(shí)使用下來的監(jiān)控?cái)?shù)據(jù),因?yàn)榭梢运綌U(kuò)容,我 們壓測 結(jié)果為即使數(shù)據(jù)量級到了幾十億,也沒有出現(xiàn)性能瓶頸。

有了DCDB的加持,比如整個(gè)讀流程就會非常的簡單,從DCDB獲取元信息,返回?cái)?shù)據(jù)對應(yīng)的存儲節(jié)點(diǎn),直接跟存儲節(jié)點(diǎn)交互獲取數(shù)據(jù),存儲節(jié)點(diǎn)之間是沒有直接關(guān)系的,可以做到水平擴(kuò)展。

整體看下來,現(xiàn)在整個(gè)集群內(nèi)沒有明顯的瓶頸點(diǎn),所有的組件都可以做到水平擴(kuò)容,可以很好 的滿 足我們對規(guī)模的要求。

高可用

需要做到高可用至少需要保障在單點(diǎn)故障(物理機(jī)故障等),預(yù)期外流量沖擊,甚至單idc故障時(shí)服務(wù)要可用,以及要做到多租戶之間相互隔離。下面分別介紹下這幾種場景是怎么做的：

（1）隔離

業(yè)務(wù)隔離,我們做到了在nginx上做分流,不同的業(yè)務(wù)(bucket)使用不同的proxy,filer,volumeServer。 做到了業(yè)務(wù)與業(yè)務(wù)之間物理隔離,相互不影響。

（2）租戶與限流

除了物理隔離外,還需要至少做到業(yè)務(wù)級別的限流熔斷功能。對象存儲跟其它的大數(shù)據(jù)服務(wù)有個(gè)比較大的區(qū)別是流量特別大,比如并發(fā)上傳1M的文件,很輕松就可以將流量打到幾十上百GB,會造成網(wǎng)絡(luò)上面的瓶頸,所以我們要做到可以給業(yè)務(wù)配置閾值,做到當(dāng)某個(gè)業(yè)務(wù)有預(yù)期外的流量時(shí),可以單獨(dú)限制不能影響到整體服務(wù),甚至造成網(wǎng)絡(luò)故障。

關(guān)于租戶的限流我們pr了2個(gè)策略,一個(gè)是基于bucket級別的全局流量限制,一種是可以基于 count+單文件下載限速的流量控制可以比較好的使得整個(gè)集群可控。

（3）高可用

proxy,filer,dcdb上文都介紹了,可以做到高可用,現(xiàn)在介紹一下數(shù)據(jù)是怎么做高可用的。數(shù)據(jù)高可用正常會有2種方式:多副本與EC糾刪碼

SeaweedFS支持實(shí)時(shí)寫數(shù)據(jù)使用副本方式,后期可以轉(zhuǎn)換為EC. 都是可以做到數(shù)據(jù)高可用的。

高性能

SeaweedFS官方介紹的其中一個(gè)特點(diǎn)是:to serve the files fast!

核心實(shí)現(xiàn)思路是參照Facebook's Haystack design paper,論文里面介紹的比較詳細(xì)。

工程實(shí)踐后最終效果做到了,小文件合并后的順序?qū)懸约癘(1)的硬盤讀. 下圖是我們6臺256G,12*8TB SATA盤,壓測的是1M的寫,io優(yōu)先到了瓶頸點(diǎn)。寫入3000 TPS

下圖是我們6臺256G,10TB SSD盤,壓測的是1M的 寫,因 為帶寬限制,沒有繼續(xù)壓,各個(gè)指標(biāo)遠(yuǎn)沒有到達(dá)瓶頸。 寫入4000 TPS

在寫入,查詢,刪除混合場景(6:3:1)壓測下,1M的文件 3500+ QPS

以上結(jié)果僅用了6臺機(jī)器測試,性能結(jié)果達(dá)到我們的需求,后期如果有更高的需求,可以做水平擴(kuò)展。

低成本

對象存儲最大的成本會是在存儲上,數(shù)據(jù)量會非常大,幾百TB,PB甚至EB都是可能的。 如上圖,各種云廠商也提供了不同存儲的不同的計(jì)費(fèi),簡單來說,就是冷的數(shù)據(jù)可以犧牲一部分性能來降低存儲的成本。 同樣SeaweedFS也做了類似的功能。

補(bǔ)充個(gè)小知識點(diǎn): 多備份與EC的差異,可以清楚的看到成本角度,EC比多副本更有優(yōu)勢。

現(xiàn)在我們可選的存儲介質(zhì)包括NVME SSD,SATA SSD,HDD?？蛇x的數(shù)據(jù)存儲方式有多副本,EC。

如圖,隨著數(shù)據(jù)越來越冷,我們會慢慢從SSD遷移到HDD,以及從副本方式改為EC存儲。 做了性能與成本的取舍。

無縫升級

上面介紹了SeaweedFS的一些功能,下面介紹一下我們是如何讓業(yè)務(wù)無縫從ceph s3,公有云 s3,efs api等存儲切到新的平臺來。目前場景以ceph為例:

（1)流程適配

業(yè)務(wù)直接通過S3對ceph進(jìn)行操作。我們要做的就是偷梁換柱,在業(yè)務(wù)無感知的情況下,將ceph s3替換為更高可用的SeaweedFS。大概需要做幾個(gè)事情

• 全api的適配

proxy適配了我們原先所有對外的api,包括s3 api,公有云 s3 api,efs api,所有api解析完內(nèi)部操作完全一致了,這樣可以做到只需要域名解析調(diào)整到proxy就可以了。

• 讀流程的適配

因?yàn)闅v史的原因,現(xiàn)在ceph s3以及公有云 s3里面存在了大量的不再使用的數(shù)據(jù)幾百TB,這些數(shù)據(jù)是不需要導(dǎo)入到新存儲的,如上圖,我們proxy支持了一種策略s3 -> S3的策略。 主要特點(diǎn)有2個(gè):

①存儲級別的高可用:新存儲故障自動切到備存儲,做到存儲級別的高可用

②自動數(shù)據(jù)補(bǔ)齊:新存儲無數(shù)據(jù),備存儲有數(shù)據(jù),自動將該數(shù)據(jù)的元信息寫入MQ

同時(shí)我們還有一個(gè)補(bǔ)償?shù)某绦騺碜x取MQ中的數(shù)據(jù),自動將被存儲的數(shù)據(jù)補(bǔ)償?shù)叫麓鎯?這樣可以做到一段時(shí)間后,所有熱數(shù)據(jù)(有訪問的數(shù)據(jù))自動備份到新存儲了,ceph s3/公有云 s3可以下線。

注: 寫MQ的時(shí)候需要注意,需要按照文件級別做順序?qū)懭?防止數(shù)據(jù)有問題

• 寫流程的適配

寫入做了取舍,為了提升性能,寫入只需要一個(gè)存儲寫成功就響應(yīng)給業(yè)務(wù),第二個(gè)存儲的數(shù)據(jù)由補(bǔ)償程序來完成。 該流程可以做到任意存儲故障時(shí),業(yè)務(wù)都無感知。

proxy中所有操作都是S3的標(biāo)準(zhǔn)接口操作,所以可以輕易做到SeaweedFS與ceph s3,SeaweedFS與公有云 s3,SeaweedFS與SeaweedFS的多種災(zāi)備方案。比如最核心的業(yè)務(wù)場景二維碼,景區(qū)圖片等,我們會先運(yùn)行一陣SeaweedFS與公有云 s3的自動災(zāi)備,防止某種場景 下觸發(fā)了某個(gè)存儲的bug,而造成大面積的影響。

寫入MQ的數(shù)據(jù)還有一個(gè)用途,用來做雙存儲的數(shù)據(jù)校驗(yàn),保障2個(gè)集群的數(shù)據(jù)最終一致性。

注:

• 圖中默認(rèn)寫入MQ是成功的,實(shí)際proxy中有兜底策略,寫MQ失敗有另外的兜底策略,比較復(fù)雜,這里不做闡述。
• 以上介紹了2個(gè)核心場景流程,還有部分場景稍有區(qū)別,如list api等 。

（2）升級步驟

除了理論上的無縫外,為了穩(wěn)定的運(yùn)行上線,上線流程也比較講究,我們大概會分幾步：

• 數(shù)據(jù)比對: 拿s3 api為例,切換之前我們會有個(gè)比對程序,訂閱nginx的訪問日志,來做2個(gè)存儲的結(jié)果比對,核心比對結(jié)果主要包括文件的MD5,以及響應(yīng)的header頭。
• 策略調(diào)整: 因?yàn)闃I(yè)務(wù)比較核心,為了穩(wěn)定的推進(jìn),每次只做最小化變更,推進(jìn)過程分了3步: 1: 引入代理,保障代理功能正常 2: 引入SeaweedFS為主,做成SeaweedFS與ceph的

集群備份,這樣可以做到即使SeaweedFS有問題,我們也可以快速的將流量回滾到ceph 3:下線ceph,最終形態(tài),做成SeaweedFS的雙集群備份。

03 落地收益

得益于開源的好處,我們僅僅投入了2個(gè)人力,整個(gè)迭代從選型到源碼、原理研究到開始落地大概持續(xù)了3個(gè)月,該項(xiàng)目上線已經(jīng)運(yùn)行了接近3個(gè)月,運(yùn)行良好,達(dá)到了預(yù)期的期望效果。目前已接入 接近2000w對象,60TB的數(shù)據(jù)量,還在快速流量切換中。

以核心業(yè)務(wù)efs為例,之前存儲使用的是公有云 s3,現(xiàn)在切換到了第二步(SeaweedFS為主集群,公有云 s3為備用集群)。 切換后的收益：

• 性能: 響應(yīng)耗時(shí)有了質(zhì)的提升,從150ms下降到3ms。
• 穩(wěn)定性: 之前訪問公有云 s3走的是公網(wǎng),性能波動比較大,切換后耗時(shí)變得非常平穩(wěn)。
• 成本: 目前到了第二步,公有云 s3還剩下了寫入的流量,讀的流量基本清0了,成本也下降了很多。

04 使用tips

• volumeGrowthCount: 這個(gè)需要調(diào)整,要做到盡量所有volumeServer都有writeable的volume,否則寫入,查詢性能會有影響。
• fs.configure: SeaweedFS的設(shè)計(jì)是每個(gè)bucket都對應(yīng)一個(gè)collection,這樣可以方便的做生命周期管理,需要控制bucket數(shù)量,否則性能會影響比較大。我們內(nèi)部先改版了取消這個(gè)綁定,做到性能最優(yōu),不過犧牲了一些bucket的統(tǒng)計(jì)功能,完整功能還在優(yōu)化中。
• filer.sync: 沒有proxy的情況下,可以使用filer.sync的同步工作來做雙集群災(zāi)備。

05 未來展望

• 定期備份: 核心bucket的增量、全量定期備份,做到跟db類似的效果,可以做到萬一誤刪等問題也可以回滾。
• 開源共建: 到目前為止,我們也陸陸續(xù)續(xù)大大小小提交了20+pr,包括bug fix,性能功能優(yōu)化,后續(xù)會持續(xù)的關(guān)注社區(qū),跟社區(qū)一起成長。
• 基于S3的存計(jì)分離方案: 現(xiàn)在很多主流的存儲產(chǎn)品都適配了S3,比如prometheus,clickhouse等等。因?yàn)樾耾ss的強(qiáng)大的性能,我們會在這些適配S3的存儲上面試點(diǎn)存儲與計(jì)算分離。
• 分布式文件存儲: 類似ceph,可以基于對象存儲rados打造分布式文件存儲,以及現(xiàn)在比較火的juicefs或curvefs也是基于s3構(gòu)建的。后期也計(jì)劃基于該oss實(shí)現(xiàn)分布式文件存儲,一期目標(biāo)在除了對io latency要求非常高(mysql)的場景外落地,為業(yè)務(wù)賦能。