本篇內容介紹了“MQ能不能幫消息隊列解耦”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供來賓網(wǎng)站建設、來賓做網(wǎng)站、來賓網(wǎng)站設計、來賓網(wǎng)站制作等企業(yè)網(wǎng)站建設、網(wǎng)頁設計與制作、來賓企業(yè)網(wǎng)站模板建站服務，十載來賓做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡服務。

有一個觀點已經(jīng)被說爛了：使用 MQ 可以幫助業(yè)務系統(tǒng)解耦。

想法很簡單，在業(yè)務狀態(tài)流轉時，如果沒有 MQ，那么其它系統(tǒng)想要知道狀態(tài)變了，那就需要核心流程系統(tǒng)去主動做通知。

比如電商系統(tǒng)里訂單從創(chuàng)建到處理中狀態(tài)切換了，客服系統(tǒng)需要知道，風控系統(tǒng)需要知道，用戶系統(tǒng)也需要知道。

這里的通知通過 RPC 來進行，下游系統(tǒng)需要的數(shù)據(jù)可以在這次 RPC 里攜帶上，也可以在請求的時候讓下游系統(tǒng)自己去查。

下游系統(tǒng)增加的時候，核心業(yè)務的代碼也需要修改，比如新做了一個積分系統(tǒng)，現(xiàn)在訂單狀態(tài)流轉積分系統(tǒng)也想知道。

核心系統(tǒng)需要不停地增加調用關系來迎合下游新增的業(yè)務方需求。這些邊邊角角的計算邏輯和訂單系統(tǒng)本身沒啥關系，但是因為下游需要拿到這些數(shù)據(jù)，我們就需要自己用  RPC 去調用下游的接口。這確實不太合理。

當下游系統(tǒng)發(fā)生事故時，很容易讓核心系統(tǒng)也跟著一起躺了：

這種情況下，核心系統(tǒng)對下游系統(tǒng)的依賴主要是因為 core system mentions downstream  system，和單系統(tǒng)內的耦合是一樣的。

解決這種耦合的最簡單的方法，在單模塊的情況是用依賴反轉，在分布式場景下，就是引入消息隊列：

在修改之后，每次訂單流轉只要將 domain event 發(fā)送到消息隊列就可以了。下游系統(tǒng)有計算需求，自己去訂閱相關的 topic 即可。

講到這里就結束，那就是童話故事了。在一開始的圖中，我們存在的依賴是雙向的：

核心系統(tǒng)依賴下游系統(tǒng)是因為調用關系，下游系統(tǒng)依賴核心系統(tǒng)是因為下游系統(tǒng)要使用核心系統(tǒng)的數(shù)據(jù)。

我們使用 MQ 只是解開了單個方向上的依賴，核心系統(tǒng)沒有對下游系統(tǒng)的調用了。

這樣下游系統(tǒng)在崩潰的時候，也就不太容易影響到核心系統(tǒng)的穩(wěn)定性。

隱式依賴導致事故

但下游系統(tǒng)對核心系統(tǒng)的數(shù)據(jù)依賴是不可能解除的，如果核心系統(tǒng)修改了產(chǎn)生 domain event  的代碼，還是會導致下游系統(tǒng)出故障，很多情況下出故障都是一死死一片：

大點的互聯(lián)網(wǎng)公司經(jīng)常是核心服務一做重構，下游服務哀鴻遍野。

數(shù)據(jù)依賴對于核心系統(tǒng)來說并不是一個可以顯式看到的依賴，所以對于核心系統(tǒng)來說，這是外部對我的隱式依賴。

看不見的依賴是很可怕的，所有人都會慢慢地逐漸忽視它，直到事故發(fā)生的那一天。

核心系統(tǒng)對下游系統(tǒng)重新建立依賴

雖然夢做的很好，但核心系統(tǒng)在服務用戶的過程中，往往也是要給用戶返回一些實時計算的數(shù)據(jù)的，這部分數(shù)據(jù)從哪里來?

很多就是從下游計算系統(tǒng)來，比如說，我的訂單流轉系統(tǒng)，現(xiàn)在要在用戶積分達到某個條件的時候，做一些特殊邏輯。

隨著業(yè)務的發(fā)展，我們最初解除掉的依賴，又重新被建立了。

環(huán)形依賴回來了!這下兩個系統(tǒng)可能又會變成你掛我也掛的情況了。兜兜轉轉，我們重新回到了原點。

“MQ能不能幫消息隊列解耦”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質量的實用文章！