歡迎關注個人公眾號：石杉的架構筆記（ID:shishan100）

週一至週五早8點半！精品技術文章準時送上！

一、寫在前面

之前更新過一個“億級流量系統架構”系列，主要講述了一個大規模商家資料平臺的如下幾個方面：

• 如何承載百億級資料儲存
• 如何設計高容錯的分散式架構
• 如何設計承載百億流量的高效能架構
• 如何設計每秒數十萬併發查詢的高併發架構
• 如何設計全鏈路99.99%高可用架構。

接下來，我們將會繼續通過幾篇文章，對這套系統的可擴充套件架構、資料一致性保障等方面進行探討。

如果沒看過本系列文章的同學可以先回過頭看看之前寫的幾篇文章：

億級流量系統架構

• 億級流量系統架構之如何支撐百億級資料的儲存與計算
• 億級流量系統架構之如何設計高容錯分散式計算系統
• 億級流量系統架構之如何設計承載百億流量的高效能架構
• 億級流量系統架構之如何設計每秒十萬查詢的高併發架構
• 億級流量系統架構之如何設計全鏈路99.99%高可用架構

二、背景回顧

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

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

三、實時計算平臺與資料查詢平臺之間的耦合

好，我們們正式開始！這篇文章我們們來聊聊這套系統裡的不同子系統之間通訊過程的一個可擴充套件性的架構處理。

這裡面蘊含了線上複雜系統之間互動的真實場景和痛點，相信對大家能夠有所啟發。

我們就關注一下上面的架構圖裡左側的部分，處於中間位置的那個實時計算平臺在完成了每一個資料分片的計算過後，都會將計算結果寫入到最左側的資料查詢平臺中。

出於種種考量，因為計算結果的資料量相比於原始資料的資料量，實際上已經少了一個數量級了。

所以，我們選擇的是實時計算平臺直接將資料寫入到資料查詢平臺的MySQL資料庫叢集中，然後資料查詢平臺基於MySQL資料庫叢集來對外提供查詢請求。

此外，為了保證當天的實時計算結果能夠高併發的被使用者查詢，因此當時採取的是實時計算平臺的計算結果同時雙寫快取叢集和資料庫叢集。

這樣，資料查詢平臺可以優先走快取叢集，如果找不到快取才會從資料庫叢集裡回查資料。

所以上述就是實時計算平臺與資料查詢平臺之間在某一個時期的一個典型的系統耦合架構。

兩個不同的系統之間，通過同一套資料儲存（資料庫叢集+快取叢集）進行了耦合。

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

系統耦合痛點1：被動承擔的高併發寫入壓力

大家如果仔細看過之前的系列文章，大概就該知道，在早期主要是集中精力對實時計算平臺的架構做了大量的演進，以便於讓他可以支撐超高併發寫入、海量資料的超高效能運算，最後就可以抗住每秒數萬甚至數十萬的資料湧入的儲存和計算。

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

實時計算平臺能抗住超高併發寫入沒問題了，而且還能快速的高效能運算也沒問題。

但是，他同時會隨著資料量的增長，越來越高併發的將計算結果寫入到一個資料庫叢集中。而這個資料庫叢集在團隊劃分的時候，實際上是交給資料查詢平臺團隊來負責維護的。

也就是說，對實時計算平臺團隊來說，他們是不care那個資料庫叢集是什麼狀態的，而就是不停的把資料寫入到那個叢集裡去。

但是，對於資料查詢平臺團隊來說，他們就會被動的承擔實時計算平臺越來越高併發壓力寫入的資料。

這個時候資料查詢平臺團隊的同學很可能處於這樣的一種焦躁中：本來自己這塊系統也有很多架構上的改進點要做，比如說之前提到的冷資料查詢引擎的自研。

但是呢，他們卻要不停的被線上資料庫伺服器的報警搞的焦頭爛額，疲於奔命。

因為資料庫伺服器單機寫入壓力可能隨著業務增長，迅速變成每秒5000~6000的寫入壓力，每天到了高峰期，線上伺服器的CPU、磁碟、IO、網路等壓力巨大，報警頻繁。

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

同時結合分庫分表的方案，資料查詢平臺自身的查詢機制又要跟著一起改變，大量的改造工作，調研工作，資料遷移工作，上線部署工作，程式碼改造工作。

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

因為整個這套資料平臺是一個大網際網路公司裡核心業務部門的一個核心繫統，他是數十個Java工程師與大資料工程師通力合作一起開發，而且裡面劃分為了多個team。

比如說資料接入系統是一個團隊負責，實時計算平臺是一個團隊負責，資料查詢平臺是一個團隊負責，離線資料倉儲是一個團隊負責，等等。

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

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

這就導致資料查詢平臺團隊根本無法對實時計算平臺湧入過來的資料做任何有效的控制和管理，這也導致了“被動承擔高併發寫入壓力”問題的發生。

這種系統耦合導致的被動高併發寫入壓力還不只是上面那麼簡單，實際在上述場景中，線上生產環境還發生過各種奇葩的事情：

某一次線上突然產生大量的熱資料，熱資料計算結果湧入資料查詢平臺，因為沒做任何管控，幾乎一瞬間導致某臺資料庫伺服器寫入併發達到1萬+，DBA焦急的擔心資料庫快當機了，所有人也都被搞的焦頭爛額，心理崩潰。

系統耦合痛點2：資料庫運維操作導致的線上系統效能劇烈抖動

在這種系統耦合的場景下，反過來實時計算平臺團隊的同學其實心裡也會吶喊：我們心裡也苦啊！

因為反過來大家可以思考一下，線上資料庫中的表結構改變，那幾乎可以說是再正常不過了，尤其是高速迭代發展中的業務。

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

但是大家考慮一個點，如果說對上述這種強耦合的系統架構，單表基本都是在千萬級別的資料量，同時還有單臺資料庫伺服器每秒幾千的寫入壓力。

在這種場景下，線上上走一個MySQL的DDL語句試一試？奉勸大家千萬別胡亂嘗試，因為資料查詢團隊裡的年輕同學，幹過這個事兒。

實際的結果就是，DDL咔嚓一執行，對線上表結構進行修改，直接導致實時計算平臺的寫入資料庫的效能急劇下降10倍以上。。。

然後連帶導致實時計算平臺的資料分片計算任務大量的延遲。再然後，因為實時計算之後的資料無法儘快反饋到儲存中，無法被使用者查詢到，導致了大量的線上投訴。

並且，DDL語句執行的還特別的慢，耗時數十分鐘才執行完畢，這就導致數十分鐘裡，整套系統出現了大規模的計算延遲，資料延遲。

一直到數十分鐘之後DDL語句執行完畢，實時計算平臺才通過自身的自動延遲排程恢復機制慢慢恢復了正常的計算。

orz......於是從此之後，資料查詢平臺的攻城獅，必須得小心翼翼的在每天凌晨2點~3點之間進行相關的資料庫運維操作，避免影響線上系統的效能穩定性。

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

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

系統耦合痛點N。。。

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

• 實時計算平臺自身寫入機制有bug導致的資料丟失，結果讓資料查詢平臺的同學去排查；

• 實時計算平臺對快取叢集和資料庫叢集進行雙寫的時候，雙寫一致性的保證機制，居然還需要自己來實現，直接導致自己的程式碼裡混合了大量不屬於自己的業務邏輯；

• 資料查詢平臺有時候做了分庫分表運維操作之後，比如擴容庫和表，居然還得讓實時計算平臺的同學配合著一起修改程式碼配置，一起測試和部署上線

• 資料查詢平臺和實時計算平臺兩個team的同學在上述大量耦合場景下，經常天天一起加班到凌晨深夜，各自的女朋友都以為他們打算在一起了，但實際情況是一堆大老爺兒們天天被搞的焦頭爛額，苦不堪言，都不願意多看對方一眼

• 因為系統耦合導致的各種問題，兩個team都要抽時間精力來解決，影響了自己那套系統的架構演進進度，沒法集中人力和時間做真正有價值和意義的事情

四、下集預告

下一篇文章，我們就來聊一聊針對這些痛點，如何靈活的運用MQ訊息中介軟體技術來進行復雜系統之間的解耦，同時解耦過後如何來自行對流量資料進行管控，解決各種系統耦合的問題。

敬請期待：

• 億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（中）？
• 億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（下）？

END