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

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

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

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

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

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

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

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

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

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

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

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

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

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

隱式依賴導致事故

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

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

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

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

核心系統對下游系統重新建立依賴

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

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

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

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