億級流量系統架構之如何在上萬併發場景下設計可擴展架構（中）？【石杉的架構筆記】

歡迎關注我的公衆號：石杉的架構筆記（ID:shishan100）

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

目錄

1、前情提示

2、清晰劃分系統邊界

3、引入消息中間件解耦

4、利用消息中間件削峯填谷

5、手動流量開關配合數據庫運維

6、支持多系統同時訂閱數據

7、系統解耦後的感覺

8、下集預告

1、前情提示

上一篇文章 億級流量系統架構之如何在上萬併發場景下設計可擴展架構（上）？，給你們初步講述了一套大規模複雜系統中，兩個核心子系統之間一旦耦合，會發生哪些使人崩潰的場景。若是還沒看上篇文章的，建議先看一下。

這篇文章，我們就給你們來講一說經過MQ消息中間件的使用，如何重構系統之間的耦合，讓系統具有高度的可擴展性。

首先來回看一下以前畫的一張兩個系統之間進行耦合的一個大圖，從這個圖裏咱們能夠看到兩個系統徹底經過一套共享存儲（數據庫集羣+緩存集羣）進行了耦合。

2、清晰的劃分系統邊界

只要有耦合，一旦要解決耦合，那麼第一個要乾的事兒就是先劃分清楚系統之間的邊界。

好比上面那兩套系統都共享了一套存儲集羣，那麼你們能夠先思考一下，兩個系統之間的邊界應該如何劃分？也就是說，中間那套緩存集羣和數據庫集羣，到底應該是屬於哪一個系統？

首先咱們看一下，緩存集羣和數據庫集羣主要是給誰用的？

很明顯就是給數據查詢平臺用的，說白了，那兩套集羣都是數據查詢平臺賴以生存的核心底層數據存儲，這裏存儲的數據也都是屬於數據查詢平臺的核心數據。

對於實時計算平臺來講，他只不過是將本身計算後的結果寫入到緩存集羣和數據庫集羣罷了。

實時計算平臺只要寫入事後，後續就不會再管那些數據了，因此這兩套集羣明顯是不屬於實時計算平臺的。

好，那麼系統之間的邊界就很清晰的劃分清楚了，你們看一下以下的圖。首先從系統總體架構的架構而言，兩套系統之間的關係應該是下面這樣子的。

3、引入消息中間件解耦

只要劃分清楚了系統之間的邊界，接着下一步，就是引入消息中間件來進行解耦了。

若是你們對消息中間件的使用場景還不太熟悉的，能夠參考以前的一篇文章：「Java進階面試系列之一」大家系統架構中爲什麼要引入消息中間件？這篇文章裏面，對消息中間件的各類使用場景都有說明。

咱們只要引入一個消息中間件，而後讓實時計算平臺將計算好的數據按照預設的格式直接寫入到消息中間件便可。

同時，數據查詢平臺須要增長一個數據接入服務，這個數據接入服務就是負責將消息中間件裏的數據消費出來，而後落地寫入到本地的緩存集羣和數據庫集羣。

如上圖所示，此時兩個系統之間已經再也不直接基於共享數據存儲進行耦合了，中間加入了MQ消息中間件。

這個消息中間件僅僅就是用於兩個系統之間的數據交互和傳輸，職責簡單，清晰明瞭。

這樣作最大的好處，就是數據查詢平臺自身能夠對涌入自身平臺的數據按照本身的需求進行定製化的管控了，不會像以前那樣的被動。

實際上在上述架構之下，涌入數據查詢平臺的全部數據，都須要通過數據接入服務那一關。在數據接入服務那裏就能夠隨意根據本身的狀況進行管理。

4、利用消息中間件削峯填谷

還記得上一篇文章咱們提到，這兩個系統之間第一個大痛點，就是實時計算平臺會高併發寫入數據查詢平臺，以前不作任何管控的時候，致使各類意外發生。

舉個例子，好比快速增加的寫庫壓力致使數據查詢平臺必須優先cover住分庫分表那塊的架構，打破本身的架構演進節奏；

好比忽然意外出現的熱數據由於不作任何寫入管控，一會兒差點把數據庫服務器擊垮。

所以一旦用消息中間件在中間擋了一層以後，咱們就能夠進行削峯填谷了。

那什麼叫作削峯填谷呢？其實很簡單，咱們先來看看，若是不作任何管控，實時計算平臺寫入數據庫集羣的寫併發曲線圖，大概以下面所示。

在高峯期，寫入會有一個陡然上升的尖峯。

就比如說，平時每秒寫入併發就500，可是高峯期寫入併發請求有5000，那麼你們就會看到上面的那張圖，在高峯期忽然冒出來一個尖峯，一會兒涌入併發5000請求，此時數據查詢平臺的數據庫集羣可能就會受不了。

可是，若是咱們在數據接入服務裏作一個限流控制呢？

也就是說，在數據接入服務裏，根據當前數據查詢平臺的數據庫集羣能承載的併發上限，好比說就是最多承載每秒3000。

好！那麼數據接入服務本身就控制好，每秒最多就往本身本地的數據庫集羣裏寫入最多每秒3000的請求壓力。

此時就會出現削峯填谷的效果，你們看下面的圖。

由於在高峯期瞬時寫入壓力最大有5000/s，可是數據接入服務作了流量控制，最多就往本地數據庫集羣寫入3000/s，那麼每秒就會有2000條數據在消息中間件裏作一個積壓。

可是積壓一下子沒關係，最起碼保證說在高峯期，這個向上的尖峯被削平了，這就是所謂的削峯。

而後在高峯期過了以後，原本每秒可能就100/s的寫入壓力，可是此時數據接入服務會持續不斷的從消息中間件裏取出來數據而後持續以最大3000/s的寫入壓力往本地數據庫集羣裏寫入。

那麼在低峯期，你們看到還會持續一段時間是3000/s的寫入速度往本地數據庫裏寫。

原來的圖裏在低峯期是谷底，如今谷底被填平了，這就是所謂的填谷。

經過這套削峯填谷的機制，就能夠保證數據查詢平臺徹底可以以本身接受的了的速率，均勻的把MQ裏的數據拿出來寫入本身本地數據庫集羣中。

這樣子不管實時計算平臺多高的併發請求壓力過來，哪怕是那種異常的熱數據，瞬間上萬併發請求過來也無所謂了。

由於MQ中間件能夠抗住瞬間高併發寫入，可是數據查詢平臺永遠都是穩定勻速的寫入本身本地數據庫。

這樣的話，數據查詢平臺就不須要去過多的care實時計算平臺帶給本身的壓力了，能夠按照本身的節奏規劃好總體架構的演進策略，按照本身的腳本去迭代架構。

說了那麼多，老規矩！給你們來一張圖，此時的架構圖以下所示。

大夥兒能夠直觀的感覺一下，在數據接入服務中多了一個限流的模塊。

5、手動流量開關配合數據庫運維操做

如今基於消息中間件將兩個系統隔離開來以後，另一個大的好處就是：數據查詢平臺作任何數據運維的操做，好比說DDL、分庫分表擴容、數據遷移，等等諸如此類的操做，已經跟實時計算平臺完全無關了。

實時計算平臺主要就是簡單的往消息中間件寫入，其餘的就不用管了。

而後若是數據查詢平臺要作一些數據庫運維的操做，此時就能夠經過在數據接入服務中加入一個手動流量開關，臨時將流量開關關閉一下子。

好比選擇一個下午你們都在工做或者午睡的時候，相對低峯的時期，半小時內關閉流量開關。

而後此時數據接入服務就不會繼續往本地數據庫寫入數據了，此時寫入操做就會中止，而後就在半小時內迅速完成數據庫運維操做。

等相關操做完成以後，再次打開流量開關，繼續從MQ裏消費數據再快速寫入到本地數據庫內便可。

這樣，就能夠徹底避免了同時寫入數據，還同時進行數據庫運維操做的窘境。不然在早期耦合的狀態下，每次進行數據庫運維操做，還得實時計算平臺團隊的同窗配合一塊兒進行各類複雜操做，才能避免線上出現故障，如今徹底不須要人家的參與了，本身團隊就能夠搞定。

整個過程，咱們仍是用一張圖，給你們呈現一下：

6、支持多系統同時訂閱數據

引入消息中間件以後，還有另一個好處，就是其餘的一些系統也能夠按照本身的須要去MQ裏訂閱實時計算平臺計算好的數據。

舉個例子，在這套平臺裏，還有數據質量監控系統，須要獲取計算數據進行數據結果準確性和質量的監控。

另外，還有數據鏈路監控系統，一樣須要將MQ裏的數據做爲數據計算鏈路中的一個核心點數據採集過來，進行數據全鏈路的監控和自動追蹤。

若是沒有引入MQ消息中間件概念的話，那麼是否是就會致使實時計算平臺除了將數據寫入一份到數據庫集羣，還須要經過接口發送給數據質量監控系統？還須要發送給數據鏈路監控系統？這樣簡直是坑爹到不行，N個系統所有耦合在一塊兒。

以前的文章「Java進階面試系列之一」大家系統架構中爲什麼要引入消息中間件？就闡述了這種多系統訂閱同一份數據，可是經過接口調用耦合在一塊兒的窘境。

這樣每次要是有一點變更，各個系統的負責人都在一塊兒開會商討，修改代碼，修改接口，考慮各類調用細節，等等。

可是如今有了消息中間件，徹底能夠經過MQ支持的「Pub/Sub」消息訂閱模型，不一樣的系統均可以來訂閱同一份數據，你們本身按需消費，按需處理，各個系統之間徹底解耦。

整個系統的可擴展性瞬間提高了不少，由於各個系統各自迭代和演進架構，都不須要強依賴其餘的系統了。

7、系統解耦後的感覺

雲開霧散！各個團隊的同窗終於不用每天扯皮，今天說你的系統影響了我，明天是個人系統影響了你。

同時也壓根兒不用去關注其餘的系統，只要有一個總架構師把控好總體架構，各個team都按照這個分工協做來作便可。

消息中間件的引入，消除了系統的耦合性，大幅度提高了系統的可擴展性，各個team均可以快速的獨立的迭代擴展本身的架構和系統。

PS：最重要的，不一樣team的同窗，不再用爲了一些雞毛蒜皮的事兒加班到深更半夜，致使他們的女友以爲他們要在一塊兒了。。。

8、下集預告

下一篇文章，是關於可擴展架構的最後一篇。咱們把總體架構梳理完畢了以後，就能夠來看一看具體到MQ消息中間件的層面，他是怎麼經過「Pub/Sub」的訂閱模型，讓一份數據發佈出去，而後讓多個不一樣的系統來訂閱同一份數據的。

敬請期待：

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

END

若有收穫，請幫忙轉發，您的鼓勵是做者最大的動力，謝謝！

一大波微服務、分佈式、高併發、高可用的原創系列文章正在路上

歡迎掃描下方二維碼，持續關注：

石杉的架構筆記（id:shishan100）

十餘年BAT架構經驗傾囊相授

推薦閱讀：

一、拜託！面試請不要再問我Spring Cloud底層原理

二、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？

三、【性能優化之道】每秒上萬併發下的Spring Cloud參數優化實戰

四、微服務架構如何保障雙11狂歡下的99.99%高可用

五、兄弟，用大白話告訴你小白都能聽懂的Hadoop架構原理

六、大規模集羣下Hadoop NameNode如何承載每秒上千次的高併發訪問

七、【性能優化的祕密】Hadoop如何將TB級大文件的上傳性能優化上百倍

八、拜託，面試請不要再問我TCC分佈式事務的實現原理坑爹呀！

九、【坑爹呀！】最終一致性分佈式事務如何保障實際生產中99.99%高可用？

十、拜託，面試請不要再問我Redis分佈式鎖的實現原理！

十一、【眼前一亮！】看Hadoop底層算法如何優雅的將大規模集羣性能提高10倍以上？

十二、億級流量系統架構之如何支撐百億級數據的存儲與計算

1三、億級流量系統架構之如何設計高容錯分佈式計算系統

1四、億級流量系統架構之如何設計承載百億流量的高性能架構

1五、億級流量系統架構之如何設計每秒十萬查詢的高併發架構

1六、億級流量系統架構之如何設計全鏈路99.99%高可用架構

1七、七張圖完全講清楚ZooKeeper分佈式鎖的實現原理

1八、大白話聊聊Java併發面試問題之volatile究竟是什麼？

1九、大白話聊聊Java併發面試問題之Java 8如何優化CAS性能？

20、大白話聊聊Java併發面試問題之談談你對AQS的理解？

2一、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？

2二、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化

2三、互聯網公司的面試官是如何360°無死角考察候選人的？（上篇）

2四、互聯網公司面試官是如何360°無死角考察候選人的？（下篇）

2五、Java進階面試系列之一：哥們，大家的系統架構中爲何要引入消息中間件？

2六、【Java進階面試系列之二】：哥們，那你說說系統架構引入消息中間件有什麼缺點？

2七、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷

2八、【Java進階面試系列之三】哥們，消息中間件在大家項目裏是如何落地的？

2九、【Java進階面試系列之四】扎心！線上服務宕機時，如何保證數據100%不丟失？

30、一次JVM FullGC的背後，竟隱藏着驚心動魄的線上生產事故！

3一、【高併發優化實踐】10倍請求壓力來襲，你的系統會被擊垮嗎？

3二、【Java進階面試系列之五】消息中間件集羣崩潰，如何保證百萬生產數據不丟失？

3三、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（上）？

做者：石杉的架構筆記 連接：https://juejin.im/post/5c221654e51d45229f76e647 來源：掘金 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。