億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（中）？【石杉的架構筆記】
歡迎關注個人公眾號：石杉的架構筆記（ID:shishan100）
週一至週五早8點半！精品技術文章準時送上！
目錄
一、前情提示
二、清晰劃分系統邊界
三、引入訊息中介軟體解耦
四、利用訊息中介軟體削峰填谷
五、手動流量開關配合資料庫運維
六、支援多系統同時訂閱資料
七、系統解耦後的感受
八、下集預告
一、前情提示
上一篇文章 億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（上）？，給大家初步講述了一套大規模複雜系統中，兩個核心子系統之間一旦耦合，會發生哪些令人崩潰的場景。如果還沒看上篇文章的，建議先看一下。
這篇文章，咱們就給大家來說一說通過MQ訊息中介軟體的使用，如何重構系統之間的耦合，讓系統具備高度的可擴充套件性。
首先來回看一下之前畫的一張兩個系統之間進行耦合的一個大圖，從這個圖裡我們可以看到兩個系統完全通過一套共享儲存（資料庫叢集+快取叢集）進行了耦合。
二、清晰的劃分系統邊界
只要有耦合，一旦要解決耦合，那麼第一個要乾的事兒就是先劃分清楚系統之間的邊界。
比如上面那兩套系統都共享了一套儲存叢集，那麼大家可以先思考一下，兩個系統之間的邊界應該如何劃分？也就是說，中間那套快取叢集和資料庫叢集，到底應該是屬於哪個系統？
首先我們看一下，快取叢集和資料庫叢集主要是給誰用的？
很明顯就是給資料查詢平臺用的，說白了，那兩套叢集都是資料查詢平臺賴以生存的核心底層資料儲存，這裡儲存的資料也都是屬於資料查詢平臺的核心資料。
對於實時計算平臺來說，他只不過是將自己計算後的結果寫入到快取叢集和資料庫叢集罷了。
實時計算平臺只要寫入過後，後續就不會再管那些資料了，所以這兩套叢集明顯是不屬於實時計算平臺的。
好，那麼系統之間的邊界就很清晰的劃分清楚了，大家看一下如下的圖。首先從系統整體架構的架構而言，兩套系統之間的關係應該是下面這樣子的。
三、引入訊息中介軟體解耦
只要劃分清楚了系統之間的邊界，接著下一步，就是引入訊息中介軟體來進行解耦了。
如果大家對訊息中介軟體的使用場景還不太熟悉的，可以參考之前的一篇文章：「Java進階面試系列之一」你們系統架構中為何要引入訊息中介軟體？這篇文章裡面，對訊息中介軟體的各種使用場景都有說明。
我們只要引入一個訊息中介軟體，然後讓實時計算平臺將計算好的資料按照預設的格式直接寫入到訊息中介軟體即可。
同時，資料查詢平臺需要增加一個數據接入服務，這個資料接入服務就是負責將訊息中介軟體裡的資料消費出來，然後落地寫入到本地的快取叢集和資料庫叢集。
如上圖所示，此時兩個系統之間已經不再直接基於共享資料儲存進行耦合了，中間加入了MQ訊息中介軟體。
這個訊息中介軟體僅僅就是用於兩個系統之間的資料互動和傳輸，職責簡單，清晰明瞭。
這樣做最大的好處，就是資料查詢平臺自身可以對湧入自身平臺的資料按照自己的需求進行定製化的管控了，不會像之前那樣的被動。
實際上在上述架構之下，湧入資料查詢平臺的所有資料，都需要經過資料接入服務那一關。在資料接入服務那裡就可以隨意根據自己的情況進行管理。
四、利用訊息中介軟體削峰填谷
還記得上一篇文章我們提到，這兩個系統之間第一個大痛點，就是實時計算平臺會高併發寫入資料查詢平臺，之前不做任何管控的時候，導致各種意外發生。
舉個例子，比如快速增長的寫庫壓力導致資料查詢平臺必須優先cover住分庫分表那塊的架構，打破自己的架構演進節奏；
比如突然意外出現的熱資料因為不做任何寫入管控，一下子差點把資料庫伺服器擊垮。
因此一旦用訊息中介軟體在中間擋了一層之後，我們就可以進行削峰填谷了。
那什麼叫做削峰填谷呢？其實很簡單，我們先來看看，如果不做任何管控，實時計算平臺寫入資料庫叢集的寫併發曲線圖，大概如下面所示。
在高峰期，寫入會有一個陡然上升的尖峰。
就好比說，平時每秒寫入併發就500，但是高峰期寫入併發請求有5000，那麼大家就會看到上面的那張圖，在高峰期突然冒出來一個尖峰，一下子湧入併發5000請求，此時資料查詢平臺的資料庫叢集可能就會受不了。
但是，如果我們在資料接入服務裡做一個限流控制呢？
也就是說，在資料接入服務裡，根據當前資料查詢平臺的資料庫叢集能承載的併發上限，比如說就是最多承載每秒3000。
好！那麼資料接入服務自己就控制好，每秒最多就往自己本地的資料庫叢集裡寫入最多每秒3000的請求壓力。
此時就會出現削峰填谷的效果，大家看下面的圖。
因為在高峰期瞬時寫入壓力最大有5000/s，但是資料接入服務做了流量控制，最多就往本地資料庫叢集寫入3000/s，那麼每秒就會有2000條資料在訊息中介軟體裡做一個積壓。
但是積壓一會兒不要緊，最起碼保證說在高峰期，這個向上的尖峰被削平了，這就是所謂的削峰。
然後在高峰期過了之後，本來每秒可能就100/s的寫入壓力，但是此時資料接入服務會持續不斷的從訊息中介軟體裡取出來資料然後持續以最大3000/s的寫入壓力往本地資料庫叢集裡寫入。
那麼在低峰期，大家看到還會持續一段時間是3000/s的寫入速度往本地資料庫裡寫。
原來的圖裡在低峰期是谷底，現在谷底被填平了，這就是所謂的填谷。
通過這套削峰填谷的機制，就可以保證資料查詢平臺完全能夠以自己接受的了的速率，均勻的把MQ裡的資料拿出來寫入自己本地資料庫叢集中。
這樣子無論實時計算平臺多高的併發請求壓力過來，哪怕是那種異常的熱資料，瞬間上萬併發請求過來也無所謂了。
因為MQ中介軟體可以抗住瞬間高併發寫入，但是資料查詢平臺永遠都是穩定勻速的寫入自己本地資料庫。
這樣的話，資料查詢平臺就不需要去過多的care實時計算平臺帶給自己的壓力了，可以按照自己的節奏規劃好整體架構的演進策略，按照自己的指令碼去迭代架構。
說了那麼多，老規矩！給大家來一張圖，此時的架構圖如下所示。
大夥兒可以直觀的感受一下，在資料接入服務中多了一個限流的模組。
五、手動流量開關配合資料庫運維操作
現在基於訊息中介軟體將兩個系統隔離開來之後，另外一個大的好處就是：資料查詢平臺做任何資料運維的操作，比如說DDL、分庫分表擴容、資料遷移，等等諸如此類的操作，已經跟實時計算平臺徹底無關了。
實時計算平臺主要就是簡單的往訊息中介軟體寫入，其他的就不用管了。
然後如果資料查詢平臺要做一些資料庫運維的操作，此時就可以通過在資料接入服務中加入一個手動流量開關，臨時將流量開關關閉一會兒。
比如選擇一個下午大家都在工作或者午睡的時候，相對低峰的時期，半小時內關閉流量開關。
然後此時資料接入服務就不會繼續往本地資料庫寫入資料了，此時寫入操作就會停止，然後就在半小時內迅速完成資料庫運維操作。
等相關操作完成之後，再次開啟流量開關，繼續從MQ裡消費資料再快速寫入到本地資料庫內即可。
這樣，就可以完全避免了同時寫入資料，還同時進行資料庫運維操作的窘境。否則在早期耦合的狀態下，每次進行資料庫運維操作，還得實時計算平臺團隊的同學配合一起進行各種複雜操作，才能避免線上出現故障，現在完全不需要人家的參與了，自己團隊就可以搞定。
整個過程，我們還是用一張圖，給大家呈現一下：
六、支援多系統同時訂閱資料
引入訊息中介軟體之後，還有另外一個好處，就是其他的一些系統也可以按照自己的需要去MQ裡訂閱實時計算平臺計算好的資料。
舉個例子，在這套平臺裡，還有資料質量監控系統，需要獲取計算資料進行資料結果準確性和質量的監控。
另外，還有資料鏈路監控系統，同樣需要將MQ裡的資料作為資料計算鏈路中的一個核心點資料採集過來，進行資料全鏈路的監控和自動追蹤。
如果沒有引入MQ訊息中介軟體概念的話，那麼是不是就會導致實時計算平臺除了將資料寫入一份到資料庫叢集，還需要通過介面傳送給資料質量監控系統？還需要傳送給資料鏈路監控系統？這樣簡直是坑爹到不行，N個系統全部耦合在一起。
之前的文章「Java進階面試系列之一」你們系統架構中為何要引入訊息中介軟體？就闡述了這種多系統訂閱同一份資料，但是通過介面呼叫耦合在一起的窘境。
這樣每次要是有一點變動，各個系統的負責人都在一起開會商討，修改程式碼，修改介面，考慮各種呼叫細節，等等。
但是現在有了訊息中介軟體，完全可以通過MQ支援的“Pub/Sub”訊息訂閱模型，不同的系統都可以來訂閱同一份資料，大家自己按需消費，按需處理，各個系統之間完全解耦。
整個系統的可擴充套件性瞬間提升了很多，因為各個系統各自迭代和演進架構，都不需要強依賴其他的系統了。
七、系統解耦後的感受
雲開霧散！各個團隊的同學終於不用天天扯皮，今天說你的系統影響了我，明天是我的系統影響了你。
同時也壓根兒不用去關注其他的系統，只要有一個總架構師把控好整體架構，各個team都按照這個分工協作來做即可。
訊息中介軟體的引入，消除了系統的耦合性，大幅度提升了系統的可擴充套件性，各個team都可以快速的獨立的迭代擴充套件自己的架構和系統。
PS：最重要的，不同team的同學，再也不用為了一些雞毛蒜皮的事兒加班到深更半夜，導致他們的女朋友覺得他們要在一起了。。。
八、下集預告
下一篇文章，是關於可擴充套件架構的最後一篇。我們把整體架構梳理完畢了之後，就可以來看一看具體到MQ訊息中介軟體的層面，他是怎麼通過“Pub/Sub”的訂閱模型，讓一份資料釋出出去，然後讓多個不同的系統來訂閱同一份資料的。
敬請期待：
- 億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（下）
END
如有收穫，請幫忙轉發，您的鼓勵是作者最大的動力，謝謝！
一大波微服務、分散式、高併發、高可用的原創系列文章正在路上
歡迎掃描下方二維碼，持續關注：
石杉的架構筆記（id:shishan100）
十餘年BAT架構經驗傾囊相授
推薦閱讀：2、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？
3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰
6、大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問
7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍
8、拜託，面試請不要再問我TCC分散式事務的實現原理坑爹呀！
9、【坑爹呀！】最終一致性分散式事務如何保障實際生產中99.99%高可用？
11、【眼前一亮！】看Hadoop底層演算法如何優雅的將大規模叢集效能提升10倍以上？
16、億級流量系統架構之如何設計全鏈路99.99%高可用架構
18、大白話聊聊Java併發面試問題之volatile到底是什麼？
19、大白話聊聊Java併發面試問題之Java 8如何優化CAS效能？
20、大白話聊聊Java併發面試問題之談談你對AQS的理解？
21、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？
22、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化
23、網際網路公司的面試官是如何360°無死角考察候選人的？（上篇）
24、網際網路公司面試官是如何360°無死角考察候選人的？（下篇）
25、Java進階面試系列之一：哥們，你們的系統架構中為什麼要引入訊息中介軟體？
26、【Java進階面試系列之二】：哥們，那你說說系統架構引入訊息中介軟體有什麼缺點？
27、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷
28、【Java進階面試系列之三】哥們，訊息中介軟體在你們專案裡是如何落地的？
29、【Java進階面試系列之四】扎心！線上服務宕機時，如何保證資料100%不丟失？
30、一次JVM FullGC的背後，竟隱藏著驚心動魄的線上生產事故！
31、【高併發優化實踐】10倍請求壓力來襲，你的系統會被擊垮嗎？
作者：石杉的架構筆記
連結：https://juejin.im/post/5c221654e51d45229f76e647
來源：掘金
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。