今天給大家分享一下我們在公司裡，面向多個業務團隊設計的資料中心架構，他是如何一步一步的從多業務團隊資料現狀分析開始，然後逐步的演化設計出一個資料中心架構來的，希望能幫助大家對現在很流行的資料中心這個概念構建起來系統化的認知。
首先跟大家說一下在沒有資料中心的時候，公司裡的各個業務團隊是什麼樣的一個狀況，簡單來說，就是不同的業務團隊有有研發自己的業務系統，有自己獨立的資料儲存，平時就是自己的系統訪問自己的資料就夠了。
圖 1
沒引入多業務資料中心時的痛點
但是接著隨著你的系統逐步演進，需求越來越多，越來越複雜，逐步的會出現每個系統都需要訪問其他系統的資料的情況。
此時就會出現你每個系統必須開一些資料介面，讓別的系統來呼叫你的介面訪問你的資料，同時你自己也可能要訪問別人的介面去獲取別人的資料。
圖 2
大家看到上圖是什麼感覺？是不是覺得很懵逼？因為實際上隨著系統慢慢演化，可能會搞成系統 A 開的介面被系統 B 和 C 呼叫，系統 B 開的介面被系統 A 和 C 呼叫，系統 C 開的介面被系統 A 和 B 呼叫。
這個時候就會出現非常尷尬的場景，就是混亂，沒錯，我敢打賭，你盯著上面的圖看 10s，應該還是很懵逼，沒什麼頭緒。
沒錯，所以其實這就是最大的痛點，各個業務系統其實都是一個資料孤島，也就是大家都只能訪問到自己的資料，然後別人要訪問你的資料，必須透過你的介面來訪問，最後導致 n 個業務系統之間錯綜複雜的呼叫關係，進而導致系統不好維護，運維困難。
資料中心的架構設計思想
所以這個問題，我們設計了一個面向多業務團隊的資料中心，這個資料中心的架構設計思想，就是透過各個業務系統的資料儲存的變更監聽。
比如針對 MySQL 資料庫就可以部署 Canal 來監聽他的資料變更，然後把各個業務系統的資料都拉取到資料中臺裡統一儲存。
如下圖 3 所示：
圖 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
總結
好了，今天給大家分享的一個網際網路公司的多業務系統資料中心架構設計就到這裡了，希望大家看了我們的架構設計思路之後，未來在公司裡遇到類似問題的時候，能夠有一個整體的設計和解決思路。