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

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

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

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

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

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

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

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

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

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

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

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

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

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

隱式依賴導(dǎo)致事故

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

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

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

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

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

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

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

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

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