消息中間件的核心作用及能力

1、系統解耦
假設你有個系統A，這個系統A會產出一個核心數據，現在下游有系統B和系統C需要這個數據。
那簡單，系統A就是直接調用系統B和系統C的接口發送數據給他們就好了。整個過程，如下圖所示：

但是現在要是來了系統D、系統E、系統F、系統G，等等，十來個其他系統慢慢的都需要這份核心數據呢？如下圖所示：

大家可別以爲這是開玩笑，一個大規模系統，往往會拆分爲幾十個甚至上百個子系統，每個子系統又對應N多個服務，這些系統與系統之間有着錯綜複雜的關係網絡。
如果某個系統產出一份核心數據，可能下游無數的其他系統都需要這份數據來實現各種業務邏輯。
此時如果你要是採取上面那種模式來設計系統架構，那麼絕對你負責系統A的同學要被煩死了。
先是來一個人找他要求發送數據給一個新的系統H，系統A的同學要修改代碼然後在那個代碼里加入調用新系統H的流程。
一會那個系統B是個陳舊老系統要下線了，告訴系統A的同學：別給我發送數據了，接着系統A再次修改代碼不再給這個系統B。
然後如果要是某個下游系統突然宕機了呢？
系統A的調用代碼裏是不是會拋異常？那系統A的同學會收到報警說異常了，結果他還要去care是下游哪個系統宕機了。
所以在實際的系統架構設計中，如果全部採取這種系統耦合的方式，在某些場景下絕對是不合適的，系統耦合度太嚴重。
並且互相耦合起來並不是核心鏈路的調用，而是一些非核心的場景（比如上述的數據消費）導致了系統耦合，這樣會嚴重的影響上下游系統的開發和維護效率。因此在上述系統架構中，就可以採用MQ中間件來實現系統解耦。
系統A就把自己的一份核心數據發到MQ裏，下游哪個系統感興趣自己去消費即可，不需要了就取消數據的消費，如下圖所示：

2、異步調用
假設你有一個系統調用鏈路，是系統A調用系統B，一般耗時20ms；系統B調用系統C，一般耗時200ms；系統C調用系統D，一般耗時2s，如下圖所示。

現在最大的問題就是：
用戶一個請求過來巨慢無比，因爲走完一個鏈路，需要耗費：
20ms + 200ms + 2000ms（2s） = 2220ms，也就是2秒多的時間。
但是實際上，鏈路中的系統A調用系統B，系統B調用系統C，這兩個步驟起來也就220ms。
就因爲引入了系統C調用系統D這個步驟，導致最終鏈路執行時間是2秒多，直接將鏈路調用性能降低了10倍，這就是導致鏈路執行過慢的罪魁禍首。那此時我們可以思考一下，是不是可以將系統D從鏈路中抽離出去做成異步調用呢？
其實很多的業務場景是可以允許異步調用的。
舉個例子：你平時點個外賣，咔嚓一下子下訂單然後付款了，此時賬戶扣款、創建訂單、通知商家給你準備菜品。
接着，是不是需要找個騎手給你送餐？那這個找騎手的過程，是需要一套複雜算法來實現調度的，比較耗時。
但是其實稍微晚個幾十秒完成騎手的調度都是ok的，因爲實際並不需要在你支付的一瞬間立馬給你找好騎手，也沒那個必要。
那麼我們是不是就可以把找騎手給你送餐的這個步驟從鏈路中抽離出去，做成異步化的，哪怕延遲個幾十秒，但是隻要在一定時間範圍內給你找到一個騎手去送餐就可以了。
這樣是不是就可以讓你下訂單點外賣的速度變得超快？支付成功之後，直接創建好訂單、賬戶扣款、通知商家立馬給你準備做菜就ok了，這個過程可能就幾百毫秒。
然後後臺異步化的耗費可能幾十秒通過調度算法給你找到一個騎手去送餐，但是這個步驟不影響我們快速下訂單。
當然我們不是說那些大家熟悉的外賣平臺的技術架構就一定是這麼實現的，只不過是用一個生活中常見的例子給大家舉例說明而已。
所以上面的鏈路也是同理，如果業務流程支持異步化的話，是不是就可以考慮把系統C對系統D的調用抽離出去做成異步化的，不要放在鏈路中同步依次調用。這樣，實現思路就是系統A -> 系統B -> 系統C，直接就耗費220ms後直接成功了。
然後系統C就是發送個消息到MQ中間件裏，由系統D消費到消息之後慢慢的異步來執行這個耗時2s的業務處理。通過這種方式直接將核心鏈路的執行性能提升了10倍。
整個過程，如下圖所示：

3、流量削峯
假設你有一個系統，平時正常的時候每秒可能就幾百個請求，系統部署在8核16G的機器的上，正常處理都是ok的，每秒幾百請求是可以輕鬆抗住的。但是如下圖所示，在高峯期一下子來了每秒鐘幾千請求，瞬時出現了流量高峯，此時你的選擇是要搞10臺機器，抗住每秒幾千請求的瞬時高峯嗎？

那如果瞬時高峯每天就那麼半個小時，接着直接就降低爲了每秒就幾百請求，如果你線上部署了很多臺機器，那麼每臺機器就處理每秒幾十個請求就可以了，這不是有點浪費機器資源嗎？大部分時候，每秒幾百請求，一臺機器就足夠了，但是爲了抗那每天瞬時的高峯，硬是部署了10臺機器，每天就那半個小時有用，別的時候都是浪費資源的。

但是如果你就部署一臺機器，那會導致瞬時高峯時，一下子壓垮你的系統，因爲絕對無法抗住每秒幾千的請求高峯。此時我們就可以用MQ中間件來進行流量削峯。所有機器前面部署一層MQ，平時每秒幾百請求大家都可以輕鬆接收消息。一旦到了瞬時高峯期，一下湧入每秒幾千的請求，就可以積壓在MQ裏面，然後那一臺機器慢慢的處理和消費。等高峯期過了，再消費一段時間，MQ裏積壓的數據就消費完畢了。

這個就是很典型的一個MQ的用法，用有限的機器資源承載高併發請求，如果業務場景允許異步削峯，高峯期積壓一些請求在MQ裏，然後高峯期過了，後臺系統在一定時間內消費完畢不再積壓的話，那就很適合用這種技術方案。
感謝您的閱讀。對文章如有疑問，歡迎提出。望分享的內容對大家有所幫助。蒐集整理了一些Java資料，包括Java進階學習路線以及對應學習資料，還有一些大廠面試題，需要的朋友可以自行領取：Java高級架構學習資料分享+架構師成長之路
順便給大家推薦一個Java技術交流羣：473984645裏面會分享一些資深架構師錄製的視頻資料：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多！