業(yè)務(wù)背景

今天給大家分享一下我們?cè)诠纠?，面向多個(gè)業(yè)務(wù)團(tuán)隊(duì)設(shè)計(jì)的數(shù)據(jù)中心架構(gòu)，他是如何一步一步的從多業(yè)務(wù)團(tuán)隊(duì)數(shù)據(jù)現(xiàn)狀分析開(kāi)始，然后逐步的演化設(shè)計(jì)出一個(gè)數(shù)據(jù)中心架構(gòu)來(lái)的，希望能幫助大家對(duì)現(xiàn)在很流行的數(shù)據(jù)中心這個(gè)概念構(gòu)建起來(lái)系統(tǒng)化的認(rèn)知。

首先跟大家說(shuō)一下在沒(méi)有數(shù)據(jù)中心的時(shí)候，公司里的各個(gè)業(yè)務(wù)團(tuán)隊(duì)是什么樣的一個(gè)狀況，簡(jiǎn)單來(lái)說(shuō)，就是不同的業(yè)務(wù)團(tuán)隊(duì)有有研發(fā)自己的業(yè)務(wù)系統(tǒng)，有自己獨(dú)立的數(shù)據(jù)存儲(chǔ)，平時(shí)就是自己的系統(tǒng)訪問(wèn)自己的數(shù)據(jù)就夠了。

如下圖 1 所示：

沒(méi)引入多業(yè)務(wù)數(shù)據(jù)中心時(shí)的痛點(diǎn)

但是接著隨著你的系統(tǒng)逐步演進(jìn)，需求越來(lái)越多，越來(lái)越復(fù)雜，逐步的會(huì)出現(xiàn)每個(gè)系統(tǒng)都需要訪問(wèn)其他系統(tǒng)的數(shù)據(jù)的情況。

此時(shí)就會(huì)出現(xiàn)你每個(gè)系統(tǒng)必須開(kāi)一些數(shù)據(jù)接口，讓別的系統(tǒng)來(lái)調(diào)用你的接口訪問(wèn)你的數(shù)據(jù)，同時(shí)你自己也可能要訪問(wèn)別人的接口去獲取別人的數(shù)據(jù)。

如下圖 2 所示：

大家看到上圖是什么感覺(jué)？是不是覺(jué)得很懵逼？因?yàn)閷?shí)際上隨著系統(tǒng)慢慢演化，可能會(huì)搞成系統(tǒng) A 開(kāi)的接口被系統(tǒng) B 和 C 調(diào)用，系統(tǒng) B 開(kāi)的接口被系統(tǒng) A 和 C 調(diào)用，系統(tǒng) C 開(kāi)的接口被系統(tǒng) A 和 B 調(diào)用。

這個(gè)時(shí)候就會(huì)出現(xiàn)非常尷尬的場(chǎng)景，就是混亂，沒(méi)錯(cuò)，我敢打賭，你盯著上面的圖看 10s，應(yīng)該還是很懵逼，沒(méi)什么頭緒。

沒(méi)錯(cuò)，所以其實(shí)這就是最大的痛點(diǎn)，各個(gè)業(yè)務(wù)系統(tǒng)其實(shí)都是一個(gè)數(shù)據(jù)孤島，也就是大家都只能訪問(wèn)到自己的數(shù)據(jù)，然后別人要訪問(wèn)你的數(shù)據(jù)，必須通過(guò)你的接口來(lái)訪問(wèn)，最后導(dǎo)致 n 個(gè)業(yè)務(wù)系統(tǒng)之間錯(cuò)綜復(fù)雜的調(diào)用關(guān)系，進(jìn)而導(dǎo)致系統(tǒng)不好維護(hù)，運(yùn)維困難。

數(shù)據(jù)中心的架構(gòu)設(shè)計(jì)思想

所以這個(gè)問(wèn)題，我們?cè)O(shè)計(jì)了一個(gè)面向多業(yè)務(wù)團(tuán)隊(duì)的數(shù)據(jù)中心，這個(gè)數(shù)據(jù)中心的架構(gòu)設(shè)計(jì)思想，就是通過(guò)各個(gè)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)存儲(chǔ)的變更監(jiān)聽(tīng)。

比如針對(duì) MySQL 數(shù)據(jù)庫(kù)就可以部署 Canal 來(lái)監(jiān)聽(tīng)他的數(shù)據(jù)變更，然后把各個(gè)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)都拉取到數(shù)據(jù)中臺(tái)里統(tǒng)一存儲(chǔ)。

如下圖 3 所示：

接著數(shù)據(jù)中心可以提供兩種數(shù)據(jù)訪問(wèn)模式，一個(gè)是主動(dòng)查詢接口，一個(gè)是被動(dòng)監(jiān)聽(tīng) MQ 通知。

也就是說(shuō)，對(duì)于數(shù)據(jù)中心來(lái)說(shuō)，你各個(gè)業(yè)務(wù)系統(tǒng)都可以調(diào)用數(shù)據(jù)中心的接口，直接獲取你想要的其他業(yè)務(wù)系統(tǒng)的數(shù)據(jù)，同時(shí)數(shù)據(jù)中心也會(huì)把各個(gè)業(yè)務(wù)數(shù)據(jù)的變更通知發(fā)送到 MQ，你也可以訂閱你感興趣的業(yè)務(wù)數(shù)據(jù)變更通知。

如下圖 4 所示：

大家看到上面的架構(gòu)設(shè)計(jì)圖，是不是瞬間感覺(jué)世界一下子就清凈了？

沒(méi)錯(cuò)，其實(shí)在互聯(lián)網(wǎng)公司里，對(duì)于多業(yè)務(wù)系統(tǒng)錯(cuò)綜復(fù)雜的互相調(diào)用接口訪問(wèn)對(duì)方數(shù)據(jù)，往往會(huì)抽出一個(gè)統(tǒng)一的公共的數(shù)據(jù)中心來(lái)，讓各個(gè)業(yè)務(wù)系統(tǒng)實(shí)現(xiàn)數(shù)據(jù)共享，這樣就可以大幅度的提升我們系統(tǒng)整體架構(gòu)的整潔性了。

數(shù)據(jù)中心的數(shù)據(jù)存儲(chǔ)架構(gòu)設(shè)計(jì)

那么再來(lái)給大家講一下數(shù)據(jù)中心架構(gòu)設(shè)計(jì)的另外一個(gè)關(guān)鍵點(diǎn)，就是他的數(shù)據(jù)存儲(chǔ)架構(gòu)設(shè)計(jì)。

大家可以想一下，雖然我們的各個(gè)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)存儲(chǔ)基本都是以 MySQL 為主的，但是我們的數(shù)據(jù)中心的存儲(chǔ)架構(gòu)其實(shí)跟業(yè)務(wù)系統(tǒng)的需求是不同的，因?yàn)闃I(yè)務(wù)系統(tǒng)一般都是需要利用 MySQL 的事務(wù)機(jī)制實(shí)現(xiàn)復(fù)雜的業(yè)務(wù)邏輯。

但是對(duì)于我們數(shù)據(jù)中心來(lái)說(shuō)，本質(zhì)僅僅是將數(shù)據(jù)同步過(guò)來(lái)，然后后續(xù)的重點(diǎn)是對(duì)外提供查詢。

這是功能上定位的不同，另外一個(gè)不同就是數(shù)據(jù)量級(jí)的不同，因?yàn)槲覀兊臄?shù)據(jù)中心是存儲(chǔ)所有業(yè)務(wù)系統(tǒng)的全量數(shù)據(jù)的，所以這就導(dǎo)致了可能各個(gè)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)量級(jí)是百萬(wàn)級(jí)到億級(jí)，而我們的數(shù)據(jù)中心他的數(shù)據(jù)量級(jí)可能是百億級(jí)的，這是很大的一個(gè)特點(diǎn)。

如下圖 5 所示：

所以最終我們的數(shù)據(jù)中心存儲(chǔ)架構(gòu)采用的是 HBase+Elasticsearch 作為核心架構(gòu)。

也就是說(shuō)，基于 HBase 把數(shù)據(jù)以 kv 的格式分布式的存儲(chǔ)在多臺(tái)服務(wù)器上，寫入的時(shí)候是 kv 格式，讀取的時(shí)候也是 kv 格式，key 就是數(shù)據(jù)的主鍵 id，value 就是一行完整的數(shù)據(jù)。

同時(shí)會(huì)為各個(gè)查詢接口的查詢條件，把要查詢的字段值寫入 ES 里建立查詢索引，讓查詢接口可以基于 ES 中的索引先搜索數(shù)據(jù)主鍵 id，然后根據(jù)數(shù)據(jù)主鍵 id 去 HBase 里查詢完整的一行數(shù)據(jù)。

如下圖 6 所示：

?接下來(lái)給大家說(shuō)一下這套架構(gòu)下的一些技術(shù)難點(diǎn)和問(wèn)題：

一個(gè)是 Hbase 和 ES 之間的一致性問(wèn)題如何保證，也就是說(shuō)，萬(wàn)一寫入 Hbase 成功了，結(jié)果寫入 ES 失敗了，此時(shí)應(yīng)該怎么辦？

這個(gè)時(shí)候其實(shí)應(yīng)該設(shè)計(jì)一個(gè)補(bǔ)償機(jī)制，也就是說(shuō)，寫入 Hbase 成功，而寫入 ES 失敗的時(shí)候，需要發(fā)一個(gè)補(bǔ)償消息到 MQ 里去，然后下次再重試做一個(gè)寫入，實(shí)現(xiàn)最終一致性的效果。

如下圖 7 所示：?

?另外一個(gè)比較關(guān)鍵的生產(chǎn)架構(gòu)經(jīng)驗(yàn)就是多業(yè)務(wù)資源隔離，也就是要限制每個(gè)業(yè)務(wù)方對(duì)數(shù)據(jù)中臺(tái)接口的訪問(wèn)量。

否則可能會(huì)出現(xiàn)一個(gè)問(wèn)題，就是某個(gè)業(yè)務(wù)方因?yàn)樽陨順I(yè)務(wù)激增或者是業(yè)務(wù) bug，導(dǎo)致讀數(shù)據(jù)局中心的接口進(jìn)行了瞬時(shí)高并發(fā)訪問(wèn)，一下子就把數(shù)據(jù)中心的請(qǐng)求處理線程都打滿了，接著就沒(méi)法處理別的業(yè)務(wù)系統(tǒng)的查詢請(qǐng)求了。

如下圖 8 所示：?

所以說(shuō)往往在這種情況下，我們必須在數(shù)據(jù)中心里設(shè)計(jì)多業(yè)務(wù)資源隔離的機(jī)制，就是說(shuō)讓每個(gè)業(yè)務(wù)系統(tǒng)接入接口訪問(wèn)的時(shí)候，最多就是使用數(shù)據(jù)中心里一部分的線程資源，超過(guò)這個(gè)閾值，就會(huì)限流，不允許這個(gè)業(yè)務(wù)方過(guò)量訪問(wèn)。

如下圖 9 所示：

數(shù)據(jù)中心的離線數(shù)據(jù)備份和恢復(fù)的機(jī)制

接著我們還有另外一個(gè)重要的架構(gòu)方案設(shè)計(jì)，數(shù)據(jù)中心現(xiàn)在是極為重要的是數(shù)據(jù)存儲(chǔ)，因?yàn)樗袠I(yè)務(wù)系統(tǒng)的數(shù)據(jù)都會(huì)在數(shù)據(jù)中心內(nèi)部進(jìn)行匯總存儲(chǔ)，然后各個(gè)業(yè)務(wù)系統(tǒng)都會(huì)強(qiáng)依賴數(shù)據(jù)中心提供的所有數(shù)據(jù)。

所以如果數(shù)據(jù)中心要是出現(xiàn)數(shù)據(jù)存儲(chǔ)故障甚至是數(shù)據(jù)丟失一類的問(wèn)題，那就會(huì)導(dǎo)致很大的麻煩，因此我們?cè)O(shè)計(jì)了離線數(shù)據(jù)備份和恢復(fù)的機(jī)制。

也就是說(shuō)，基于大數(shù)據(jù)技術(shù)將所有數(shù)據(jù)定時(shí)同步一份到 Hadoop 集群中去，如果要是出現(xiàn)了 Hbase 或者 ES 集群的崩潰或者數(shù)據(jù)丟失，此時(shí)可以基于 Hadoop 集群中的離線備份數(shù)據(jù)，把數(shù)據(jù)恢復(fù)到某個(gè)時(shí)間點(diǎn)，繼續(xù)對(duì)外提供服務(wù)。

如下圖 10 所示：

總結(jié)

好了，今天給大家分享的一個(gè)互聯(lián)網(wǎng)公司的多業(yè)務(wù)系統(tǒng)數(shù)據(jù)中心架構(gòu)設(shè)計(jì)就到這里了，希望大家看了我們的架構(gòu)設(shè)計(jì)思路之后，未來(lái)在公司里遇到類似問(wèn)題的時(shí)候，能夠有一個(gè)整體的設(shè)計(jì)和解決思路。