一、背景回顧

如果大家看過之前的一系列文章，應該依稀還記得??上一篇??文章最后，整個系統(tǒng)架構大致演進到了如下圖的一個狀態(tài)。

如果沒看過之前的系列文章，上來猛一看下面這個圖，絕對一臉懵逼，就看到一片“花花綠綠”。這個也沒辦法，復雜的系統(tǒng)架構都是特別的龐雜的。

二、實時計算平臺與數(shù)據(jù)查詢平臺之間的耦合

好，咱們正式開始！這篇文章咱們來聊聊這套系統(tǒng)里的不同子系統(tǒng)之間通信過程的一個可擴展性的架構處理。

這里面蘊含了線上復雜系統(tǒng)之間交互的真實場景和痛點，相信對大家能夠有所啟發(fā)。

我們就關注一下上面的架構圖里左側的部分，處于中間位置的那個實時計算平臺在完成了每一個數(shù)據(jù)分片的計算過后，都會將計算結果寫入到最左側的數(shù)據(jù)查詢平臺中。

出于種種考量，因為計算結果的數(shù)據(jù)量相比于原始數(shù)據(jù)的數(shù)據(jù)量，實際上已經少了一個數(shù)量級了。

所以，我們選擇的是實時計算平臺直接將數(shù)據(jù)寫入到數(shù)據(jù)查詢平臺的MySQL數(shù)據(jù)庫集群中，然后數(shù)據(jù)查詢平臺基于MySQL數(shù)據(jù)庫集群來對外提供查詢請求。

此外，為了保證當天的實時計算結果能夠高并發(fā)的被用戶查詢，因此當時采取的是實時計算平臺的計算結果同時雙寫緩存集群和數(shù)據(jù)庫集群。

這樣，數(shù)據(jù)查詢平臺可以優(yōu)先走緩存集群，如果找不到緩存才會從數(shù)據(jù)庫集群里回查數(shù)據(jù)。

所以上述就是實時計算平臺與數(shù)據(jù)查詢平臺之間在某一個時期的一個典型的系統(tǒng)耦合架構。

兩個不同的系統(tǒng)之間，通過同一套數(shù)據(jù)存儲（數(shù)據(jù)庫集群+緩存集群）進行了耦合。

大家看看下面的圖，再來清晰的感受一下系統(tǒng)之間耦合的感覺。

系統(tǒng)耦合痛點1：被動承擔的高并發(fā)寫入壓力

大家如果仔細看過之前的系列文章，大概就該知道，在早期主要是集中精力對實時計算平臺的架構做了大量的演進，以便于讓他可以支撐超高并發(fā)寫入、海量數(shù)據(jù)的超高性能計算，最后就可以抗住每秒數(shù)萬甚至數(shù)十萬的數(shù)據(jù)涌入的存儲和計算。

但是因為早期采用了上圖的這種最簡單、最高效、最實用的耦合交互方式，實時計算平臺直接把每個數(shù)據(jù)分片計算完的結果寫入共享存儲中，就導致了一個很大的問題。

實時計算平臺能抗住超高并發(fā)寫入沒問題了，而且還能快速的高性能計算也沒問題。

但是，他同時會隨著數(shù)據(jù)量的增長，越來越高并發(fā)的將計算結果寫入到一個數(shù)據(jù)庫集群中。而這個數(shù)據(jù)庫集群在團隊劃分的時候，實際上是交給數(shù)據(jù)查詢平臺團隊來負責維護的。

也就是說，對實時計算平臺團隊來說，他們是不care那個數(shù)據(jù)庫集群是什么狀態(tài)的，而就是不停的把數(shù)據(jù)寫入到那個集群里去。

但是，對于數(shù)據(jù)查詢平臺團隊來說，他們就會被動的承擔實時計算平臺越來越高并發(fā)壓力寫入的數(shù)據(jù)。

這個時候數(shù)據(jù)查詢平臺團隊的同學很可能處于這樣的一種焦躁中：本來自己這塊系統(tǒng)也有很多架構上的改進點要做，比如說之前提到的冷數(shù)據(jù)查詢引擎的自研。

但是呢，他們卻要不停的被線上數(shù)據(jù)庫服務器的報警搞的焦頭爛額，疲于奔命。

因為數(shù)據(jù)庫服務器單機寫入壓力可能隨著業(yè)務增長，迅速變成每秒5000~6000的寫入壓力，每天到了高峰期，線上服務器的CPU、磁盤、IO、網絡等壓力巨大，報警頻繁。

此時數(shù)據(jù)查詢平臺團隊的架構演進節(jié)奏就會被打亂，因為必須被動的去根據(jù)實時計算平臺的寫入壓力來進行調整，必須立馬停下手中的工作，然后去考慮如何對數(shù)據(jù)庫集群做分庫分表的方案，如何對表進行擴容，如何對庫進行擴容。

同時結合分庫分表的方案，數(shù)據(jù)查詢平臺自身的查詢機制又要跟著一起改變，大量的改造工作，調研工作，數(shù)據(jù)遷移工作，上線部署工作，代碼改造工作。

實際上，上面說的這種情況，絕對是不合理的。

因為整個這套數(shù)據(jù)平臺是一個大互聯(lián)網公司里核心業(yè)務部門的一個核心系統(tǒng)，他是數(shù)十個Java工程師與大數(shù)據(jù)工程師通力合作一起開發(fā)，而且里面劃分為了多個team。

比如說數(shù)據(jù)接入系統(tǒng)是一個團隊負責，實時計算平臺是一個團隊負責，數(shù)據(jù)查詢平臺是一個團隊負責，離線數(shù)據(jù)倉庫是一個團隊負責，等等。

所以只要分工合作了以后，那么就不應該讓一個團隊被動的去承擔另外一個團隊猛然增長的寫入壓力，這樣會打破每個團隊自己的工作節(jié)奏。

導致這個問題的根本原因，就是因為兩個系統(tǒng)間，沒有做任何解耦的處理。

這就導致數(shù)據(jù)查詢平臺團隊根本無法對實時計算平臺涌入過來的數(shù)據(jù)做任何有效的控制和管理，這也導致了“被動承擔高并發(fā)寫入壓力”問題的發(fā)生。

這種系統(tǒng)耦合導致的被動高并發(fā)寫入壓力還不只是上面那么簡單，實際在上述場景中，線上生產環(huán)境還發(fā)生過各種奇葩的事情：

某一次線上突然產生大量的熱數(shù)據(jù)，熱數(shù)據(jù)計算結果涌入數(shù)據(jù)查詢平臺，因為沒做任何管控，幾乎一瞬間導致某臺數(shù)據(jù)庫服務器寫入并發(fā)達到1萬+，DBA焦急的擔心數(shù)據(jù)庫快宕機了，所有人也都被搞的焦頭爛額，心理崩潰。

系統(tǒng)耦合痛點2：數(shù)據(jù)庫運維操作導致的線上系統(tǒng)性能劇烈抖動

在這種系統(tǒng)耦合的場景下，反過來實時計算平臺團隊的同學其實心里也會吶喊：我們心里也苦?。?/span>

因為反過來大家可以思考一下，線上數(shù)據(jù)庫中的表結構改變，那幾乎可以說是再正常不過了，尤其是高速迭代發(fā)展中的業(yè)務。

需求評審會上，要是不小心碰上某個產品經理，今天改需求，明天改需求。工程師估計會怒火沖天的想要砍人。但是沒辦法，最后還是得為五斗米折腰，該改的需求還是得改。該改的表結構也還是要改，改加的索引也還是要加。

但是大家考慮一個點，如果說對上述這種強耦合的系統(tǒng)架構，單表基本都是在千萬級別的數(shù)據(jù)量，同時還有單臺數(shù)據(jù)庫服務器每秒幾千的寫入壓力。

在這種場景下，在線上走一個MySQL的DDL語句試一試？奉勸大家千萬別胡亂嘗試，因為數(shù)據(jù)查詢團隊里的年輕同學，干過這個事兒。

實際的結果就是，DDL咔嚓一執(zhí)行，對線上表結構進行修改，直接導致實時計算平臺的寫入數(shù)據(jù)庫的性能急劇下降10倍以上。。。

然后連帶導致實時計算平臺的數(shù)據(jù)分片計算任務大量的延遲。再然后，因為實時計算之后的數(shù)據(jù)無法盡快反饋到存儲中，無法被用戶查詢到，導致了大量的線上投訴。

并且，DDL語句執(zhí)行的還特別的慢，耗時數(shù)十分鐘才執(zhí)行完畢，這就導致數(shù)十分鐘里，整套系統(tǒng)出現(xiàn)了大規(guī)模的計算延遲，數(shù)據(jù)延遲。

一直到數(shù)十分鐘之后DDL語句執(zhí)行完畢，實時計算平臺才通過自身的自動延遲調度恢復機制慢慢恢復了正常的計算。

orz......于是從此之后，數(shù)據(jù)查詢平臺的攻城獅，必須得小心翼翼的在每天凌晨2點~3點之間進行相關的數(shù)據(jù)庫運維操作，避免影響線上系統(tǒng)的性能穩(wěn)定性。

但是，難道人家年輕工程師沒有女朋友？難道年長工程師沒有老婆孩子？經常在凌晨3點看看窗外的風景，然后打個滴滴回家，估計沒任何人愿意。

其實上述問題，說白了，還是因為兩套系統(tǒng)直接通過存儲耦合在了一起，導致了任何一個系統(tǒng)只要有點異動，直接就會影響另外一個系統(tǒng)。耦合！耦合！還是耦合！

系統(tǒng)耦合痛點N

其實上面只不過是挑了其中兩個系統(tǒng)耦合痛點來說明而已，文章篇幅有限，很難把上述長達數(shù)月的耦合狀態(tài)下的各種痛點一一說明，實際線上生產環(huán)境的痛點還包括不限于：

• 實時計算平臺自身寫入機制有bug導致的數(shù)據(jù)丟失，結果讓數(shù)據(jù)查詢平臺的同學去排查。
• 實時計算平臺對緩存集群和數(shù)據(jù)庫集群進行雙寫的時候，雙寫一致性的保證機制，居然還需要自己來實現(xiàn)，直接導致自己的代碼里混合了大量不屬于自己的業(yè)務邏輯。
• 數(shù)據(jù)查詢平臺有時候做了分庫分表運維操作之后，比如擴容庫和表，居然還得讓實時計算平臺的同學配合著一起修改代碼配置，一起測試和部署上線。
• 數(shù)據(jù)查詢平臺和實時計算平臺兩個team的同學在上述大量耦合場景下，經常天天一起加班到凌晨深夜，各自的女朋友都以為他們打算在一起了，但實際情況是一堆大老爺兒們天天被搞的焦頭爛額，苦不堪言，都不愿意多看對方一眼。
• 因為系統(tǒng)耦合導致的各種問題，兩個team都要抽時間精力來解決，影響了自己那套系統(tǒng)的架構演進進度，沒法集中人力和時間做真正有價值和意義的事情。