二、US3元數(shù)據(jù)服務(wù)的挑戰(zhàn)

目前US3元數(shù)據(jù)服務(wù)支持了EB級(jí)存儲(chǔ)規(guī)模，存儲(chǔ)了超過(guò)千億級(jí)別的文件索引。需要面臨每日數(shù)十億次索引訪問(wèn), 文件上傳請(qǐng)求,以及數(shù)億次文件刪除請(qǐng)求帶來(lái)的索引更新壓力, 同時(shí)客戶(hù)大量的對(duì)象列表請(qǐng)求，也帶來(lái)了極大的索引范圍掃描挑戰(zhàn)。

在之前的元數(shù)據(jù)服務(wù)架構(gòu)中，UCloud優(yōu)刻得采用了業(yè)內(nèi)流行的MongoDB作為底層數(shù)據(jù)存儲(chǔ)，同時(shí)輔以外部服務(wù)做數(shù)據(jù)路由、監(jiān)控統(tǒng)計(jì)，很好地滿(mǎn)足了客戶(hù)數(shù)據(jù)存儲(chǔ)需求。同時(shí)部署簡(jiǎn)單，設(shè)計(jì)上也有一定的可擴(kuò)展性。但隨著客戶(hù)數(shù)量以及存儲(chǔ)數(shù)據(jù)量的爆炸增長(zhǎng)，此架構(gòu)也遇到了一定的問(wèn)題。

三、此前的US3元數(shù)據(jù)服務(wù)架構(gòu)

US3元數(shù)據(jù)主要存儲(chǔ)在MongoDB集群內(nèi)，MongoDB集群則是鏈?zhǔn)浇Y(jié)構(gòu)，一個(gè)MongoDB集群由于寫(xiě)入量太大扛不住了，就在后面增加一個(gè)MongoDB集群，查詢(xún)的時(shí)候接入集群將請(qǐng)求下發(fā)至DB-Gateway，DB-Gateway先將json數(shù)據(jù)轉(zhuǎn)譯成bson，然后根據(jù)Bucket對(duì)應(yīng)的DB（可能有多個(gè)），從新MongoDB至老MongoDB依次查詢(xún)數(shù)據(jù)。刪除的時(shí)候則需要將發(fā)送請(qǐng)求發(fā)送至所有bucket涉及的MongoDB集群。

一定會(huì)有小伙伴問(wèn)為什么不直接擴(kuò)mongo分片？因?yàn)榫€上數(shù)據(jù)量大、服務(wù)壓力大、客戶(hù)需求高直接擴(kuò)分片會(huì)有數(shù)據(jù)遷移，從而導(dǎo)致延遲，對(duì)線上服務(wù)的影響較大。

同時(shí)隨著MongoDB存儲(chǔ)的數(shù)據(jù)量越來(lái)越大， MongoDB的性能開(kāi)始顯得不足。而原先直接在MongoDB進(jìn)行列表掃描的方式會(huì)極大地影響其讀寫(xiě)性能，為了緩解MongoDB的壓力，我們將列表服務(wù)分離出來(lái)，在外部同步MongoDB的數(shù)據(jù)，再對(duì)外提供服務(wù)。

列表服務(wù)對(duì)多個(gè)MongoDB進(jìn)行同步，每加一個(gè)MongoDB集群就要加一個(gè)列表服務(wù)節(jié)點(diǎn)，查詢(xún)的時(shí)候也是根據(jù)bucket對(duì)應(yīng)的DB，同時(shí)發(fā)送至多個(gè)列表服務(wù)，然后再在接入層聚合。

由此我們總結(jié)了在元數(shù)據(jù)服務(wù)場(chǎng)景中，通常存在的一些痛點(diǎn):

1、業(yè)務(wù)痛點(diǎn)：性能差

?鏈?zhǔn)郊軜?gòu)，老MongoDB的寫(xiě)能力用不上，讀會(huì)有放大。

?刪除需要?jiǎng)h除多個(gè)MongoDB數(shù)據(jù)，可能存在數(shù)據(jù)不一致，孤兒文檔問(wèn)題。

?列表服務(wù)同步數(shù)據(jù)有延遲，客戶(hù)無(wú)法實(shí)時(shí)檢索上傳的文件。大量刪除導(dǎo)致列表服務(wù)同步延遲飆升。

2、運(yùn)維痛點(diǎn)：可擴(kuò)展性差

?一個(gè)MongoDB頂不住就加一個(gè)MongoDB切，導(dǎo)致擴(kuò)展同步繁瑣、手動(dòng)切換出錯(cuò)概率大。

3、運(yùn)營(yíng)痛點(diǎn)：成本高

?由于性能不夠，需要更多的機(jī)器堆讀寫(xiě)性能。列表服務(wù)由于分離出來(lái)，也需要額外的機(jī)器,導(dǎo)致元數(shù)據(jù)索引服務(wù)成本高昂。

四、新的US3元數(shù)據(jù)服務(wù)架構(gòu)

我們簡(jiǎn)化了US3整個(gè)體系架構(gòu)，主要將其分為了高兼容性的DB-Gateway服務(wù)、高可用的計(jì)算存儲(chǔ)分離的分布式KV數(shù)據(jù)庫(kù)-UKV以及高度定制化的RocksDB-URocksDB三部分，將元數(shù)據(jù)存儲(chǔ)于UCloud優(yōu)刻得自研的計(jì)算存儲(chǔ)分離的UKV中，因此獲得了更強(qiáng)大的容災(zāi)能力，更快的熱點(diǎn)節(jié)點(diǎn)分裂、性能拓展能力，還有底層存儲(chǔ)EC支持，異構(gòu)存儲(chǔ)等降低成本的潛力。

新架構(gòu)帶來(lái)了幾個(gè)方面的提升：

?性能提升

元數(shù)據(jù)刪除延遲降低、讀放大降低。

?列表服務(wù)無(wú)延遲

解決了客戶(hù)經(jīng)常因?yàn)榱斜矸?wù)延遲而不能實(shí)時(shí)看到上傳的數(shù)據(jù)的問(wèn)題。（也不再有延遲告警問(wèn)題）

?成本降低

元數(shù)據(jù)服務(wù)成本降低80%。

?運(yùn)維更簡(jiǎn)單

計(jì)算節(jié)點(diǎn)容災(zāi)無(wú)數(shù)據(jù)遷移，無(wú)需提心吊膽。熱點(diǎn)自動(dòng)分裂，不再需要手動(dòng)加節(jié)點(diǎn)擴(kuò)容。

有幾個(gè)關(guān)鍵產(chǎn)品（或環(huán)節(jié)）在這次優(yōu)化中起到重要作用：

五、新架構(gòu)的幾個(gè)核心改變

1.DB-Gateway

DB-Gateway是一個(gè)無(wú)狀態(tài)進(jìn)程,它兼容老的元數(shù)據(jù)服務(wù)，同時(shí)具有底層UKV協(xié)議轉(zhuǎn)換功能，Sharding路由功能，并且聚合了原先的列表服務(wù)功能，因此能夠移除列表服務(wù)需要的機(jī)器。

DB-Gateway通過(guò)ConfigServer集群更新UKV的Sharding路由表，來(lái)將不同的請(qǐng)求打到不同的UKV節(jié)點(diǎn)上去。

2.UKV

UKV是UCloud優(yōu)刻得自研的計(jì)算存儲(chǔ)分離的分布式KV存儲(chǔ)系統(tǒng)。其存儲(chǔ)底座為分布式統(tǒng)一存儲(chǔ)Manul，Manul是具備自動(dòng)數(shù)據(jù)平衡、異構(gòu)介質(zhì)存儲(chǔ)、EC存儲(chǔ)等功能的高性能、高可用、分布式存儲(chǔ)服務(wù)。

UKV提供了集群管理服務(wù)，快速備份等常規(guī)功能，還針對(duì)US3元數(shù)據(jù)服務(wù)設(shè)計(jì)了數(shù)據(jù)結(jié)構(gòu)，使其在UCloud優(yōu)刻得日常的業(yè)務(wù)場(chǎng)景下提供更優(yōu)秀的性能。

UKV使用UCloud優(yōu)刻得自研的、由開(kāi)源RocksDB定制化的URocksDB作為計(jì)算節(jié)點(diǎn)，同時(shí)依托Manul，實(shí)現(xiàn)了主從熱備，熱點(diǎn)節(jié)點(diǎn)快速分裂等特色功能。

由于篇幅有限，對(duì)于UKV的架構(gòu)設(shè)計(jì)以及特色功能不在此展開(kāi)，敬請(qǐng)期待下一次的分享。

xiesc