消息隊列解耦是騙小孩兒的

有一個觀點已經被說爛了：使用 MQ 可以幫助業務系統解耦。

想法很簡單，在業務狀態流轉時，如果沒有 MQ，那麼其它系統想要知道狀態變了，那就需要核心流程系統去主動做通知。

比如電商系統裏訂單從創建到處理中狀態切換了，客服系統需要知道，風控系統需要知道，用戶系統也需要知道。

一個典型的依賴關係

這裏的通知通過 RPC 來進行，下游系統需要的數據可以在這次 RPC 裏攜帶上，也可以在請求的時候讓下游系統自己去查。

下游系統增加的時候，核心業務的代碼也需要修改，比如新做了一個積分系統，現在訂單狀態流轉積分系統也想知道。

下游增加新系統時

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

當下遊系統發生事故時，很容易讓核心系統也跟着一起躺了：

下游炸了上游也得炸

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

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

用消息隊列解除上游對下游的依賴

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

有了消息隊列時下游增加新系統

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

雙向依賴

核心系統依賴下游系統是因爲調用關係，下游系統依賴核心系統是因爲下游系統要使用核心系統的數據。

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

有一個方向的依賴被解除了

這樣下游系統在崩潰的時候，也就不太容易影響到核心系統的穩定性。

隱式依賴導致事故

但下游系統對核心系統的數據依賴是不可能解除的，如果核心繫統修改了產生 domain event 的代碼，還是會導致下游系統出故障，很多情況下出故障都是一死死一片：

上游的 domain event 出問題的時候

大點的互聯網公司經常是核心服務一做重構，下游服務哀鴻遍野。

數據依賴對於核心系統來說並不是一個可以顯式看到的依賴，所以對於核心系統來說，這是外部對我的隱式依賴。

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

雖然夢做的很好，但核心系統在服務用戶的過程中，往往也是要給用戶返回一些實時計算的數據的，這部分數據從哪裏來？

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

隨着業務的發展，我們最初解除掉的依賴，又重新被建立了。

回到原點

環形依賴回來了！這下兩個系統可能又會變成你掛我也掛的情況了。兜兜轉轉，我們重新回到了原點。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/O0KGm3nVUSWMSKwHlPiJpg