業務背景

今天給大家分享一下我們在公司里，面向多個業務團隊設計的數據中心架構，他是如何一步一步的從多業務團隊數據現狀分析開始，然后逐步的演化設計出一個數據中心架構來的，希望能幫助大家對現在很流行的數據中心這個概念構建起來系統化的認知。

首先跟大家說一下在沒有數據中心的時候，公司里的各個業務團隊是什么樣的一個狀況，簡單來說，就是不同的業務團隊有有研發自己的業務系統，有自己獨立的數據存儲，平時就是自己的系統訪問自己的數據就夠了。

如下圖 1 所示：

沒引入多業務數據中心時的痛點

但是接著隨著你的系統逐步演進，需求越來越多，越來越復雜，逐步的會出現每個系統都需要訪問其他系統的數據的情況。

此時就會出現你每個系統必須開一些數據接口，讓別的系統來調用你的接口訪問你的數據，同時你自己也可能要訪問別人的接口去獲取別人的數據。

如下圖 2 所示：

大家看到上圖是什么感覺？是不是覺得很懵逼？因為實際上隨著系統慢慢演化，可能會搞成系統 A 開的接口被系統 B 和 C 調用，系統 B 開的接口被系統 A 和 C 調用，系統 C 開的接口被系統 A 和 B 調用。

這個時候就會出現非常尷尬的場景，就是混亂，沒錯，我敢打賭，你盯著上面的圖看 10s，應該還是很懵逼，沒什么頭緒。

沒錯，所以其實這就是最大的痛點，各個業務系統其實都是一個數據孤島，也就是大家都只能訪問到自己的數據，然后別人要訪問你的數據，必須通過你的接口來訪問，最后導致 n 個業務系統之間錯綜復雜的調用關系，進而導致系統不好維護，運維困難。

數據中心的架構設計思想

所以這個問題，我們設計了一個面向多業務團隊的數據中心，這個數據中心的架構設計思想，就是通過各個業務系統的數據存儲的變更監聽。

比如針對 MySQL 數據庫就可以部署 Canal 來監聽他的數據變更，然后把各個業務系統的數據都拉取到數據中臺里統一存儲。

如下圖 3 所示：

接著數據中心可以提供兩種數據訪問模式，一個是主動查詢接口，一個是被動監聽 MQ 通知。

也就是說，對于數據中心來說，你各個業務系統都可以調用數據中心的接口，直接獲取你想要的其他業務系統的數據，同時數據中心也會把各個業務數據的變更通知發送到 MQ，你也可以訂閱你感興趣的業務數據變更通知。

如下圖 4 所示：

大家看到上面的架構設計圖，是不是瞬間感覺世界一下子就清凈了？

沒錯，其實在互聯網公司里，對于多業務系統錯綜復雜的互相調用接口訪問對方數據，往往會抽出一個統一的公共的數據中心來，讓各個業務系統實現數據共享，這樣就可以大幅度的提升我們系統整體架構的整潔性了。

數據中心的數據存儲架構設計

那么再來給大家講一下數據中心架構設計的另外一個關鍵點，就是他的數據存儲架構設計。

大家可以想一下，雖然我們的各個業務系統的數據存儲基本都是以 MySQL 為主的，但是我們的數據中心的存儲架構其實跟業務系統的需求是不同的，因為業務系統一般都是需要利用 MySQL 的事務機制實現復雜的業務邏輯。

但是對于我們數據中心來說，本質僅僅是將數據同步過來，然后后續的重點是對外提供查詢。

這是功能上定位的不同，另外一個不同就是數據量級的不同，因為我們的數據中心是存儲所有業務系統的全量數據的，所以這就導致了可能各個業務系統的數據量級是百萬級到億級，而我們的數據中心他的數據量級可能是百億級的，這是很大的一個特點。

如下圖 5 所示：

所以最終我們的數據中心存儲架構采用的是 HBase+Elasticsearch 作為核心架構。

也就是說，基于 HBase 把數據以 kv 的格式分布式的存儲在多臺服務器上，寫入的時候是 kv 格式，讀取的時候也是 kv 格式，key 就是數據的主鍵 id，value 就是一行完整的數據。

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

如下圖 6 所示：

?接下來給大家說一下這套架構下的一些技術難點和問題：

一個是 Hbase 和 ES 之間的一致性問題如何保證，也就是說，萬一寫入 Hbase 成功了，結果寫入 ES 失敗了，此時應該怎么辦？

這個時候其實應該設計一個補償機制，也就是說，寫入 Hbase 成功，而寫入 ES 失敗的時候，需要發一個補償消息到 MQ 里去，然后下次再重試做一個寫入，實現最終一致性的效果。

如下圖 7 所示：?

?另外一個比較關鍵的生產架構經驗就是多業務資源隔離，也就是要限制每個業務方對數據中臺接口的訪問量。

否則可能會出現一個問題，就是某個業務方因為自身業務激增或者是業務 bug，導致讀數據局中心的接口進行了瞬時高并發訪問，一下子就把數據中心的請求處理線程都打滿了，接著就沒法處理別的業務系統的查詢請求了。

如下圖 8 所示：?

所以說往往在這種情況下，我們必須在數據中心里設計多業務資源隔離的機制，就是說讓每個業務系統接入接口訪問的時候，最多就是使用數據中心里一部分的線程資源，超過這個閾值，就會限流，不允許這個業務方過量訪問。

如下圖 9 所示：

數據中心的離線數據備份和恢復的機制

接著我們還有另外一個重要的架構方案設計，數據中心現在是極為重要的是數據存儲，因為所有業務系統的數據都會在數據中心內部進行匯總存儲，然后各個業務系統都會強依賴數據中心提供的所有數據。

所以如果數據中心要是出現數據存儲故障甚至是數據丟失一類的問題，那就會導致很大的麻煩，因此我們設計了離線數據備份和恢復的機制。

也就是說，基于大數據技術將所有數據定時同步一份到 Hadoop 集群中去，如果要是出現了 Hbase 或者 ES 集群的崩潰或者數據丟失，此時可以基于 Hadoop 集群中的離線備份數據，把數據恢復到某個時間點，繼續對外提供服務。

如下圖 10 所示：

總結

好了，今天給大家分享的一個互聯網公司的多業務系統數據中心架構設計就到這里了，希望大家看了我們的架構設計思路之后，未來在公司里遇到類似問題的時候，能夠有一個整體的設計和解決思路。