什么是耦合?

耦合，是架構中，本來不相干的代碼、模塊、服務、系統因為某些原因聯系在一起，各自獨立性差，影響則相互影響，變動則相互變動的一種架構狀態。

[[419744]]

感官上，怎么發現系統中的耦合?

作為技術人，每每在心中罵上下游，罵兄弟部門，“這個東西跟我有什么關系?為什么需要我來配合做這個事情?”。明明不應該聯動，卻要被動配合，就可能有潛在的耦合。

今天一起來看一個，用錯RPC的耦合場景。

一個架構常識：當調用方需要關心執行結果，通常使用RPC調用。

ret = PassportService::userAuth(name, pass); 
switch(ret){ 
 case(YES) : return YesHTML(); 
 case(NO) : return NoHTML(); 
 case(JUMP) : return 304HTML(): 
 default : return 500HTML(); 
} 

上一篇《明明服務化了，為啥耦合更加嚴重了?》提到，執行結果的處理和業務強相關，則switch case應該放在上游業務方，而不應該放到底層通用服務。

登錄頁面調用passport服務，會根據passport服務的返回結果，區別執行登錄成功，登錄失敗，執行錯誤。調用方關注執行結果時，不宜使用MQ通訊。

如果強行使用MQ通訊，調用方不能直接告之用戶登錄成功又或失敗，阻塞住等待MQ通知回調不但使得編碼復雜，還會引入消息丟失的風險，中間多加入一層，多此一舉，基本沒有人這么玩。

但如果調用方不關心執行結果，卻仍然使用RPC調用，會引發上下游極大的耦合與瓶頸。

場景還原

有一個通用的上游服務，例如“帖子發布”服務，負責公司通用的帖子發布業務。有一些個性化的業務關心“用戶發布帖子”這個事件，例如：

• 用戶發布帖子后，大數據部門要更新用戶的畫像;
• 用戶發布帖子后，信息質量部門要異步檢查帖子是否合規;
• 招聘業務最近在做用戶促活，如果用戶發布的是招聘帖子，要增加積分;
• …

個性化下游關注這個事件，但下游對事件的執行結果，“帖子發布”服務卻并不關心，如果“帖子發布”服務通過RPC的方式去通知下游，就會有很大的問題。

耦合為何存在?

帖子發布服務，這本來應該是一個非常基礎的服務，上游upper通過RPC調用將事件同步給事件關注業務方biz1/biz2/biz3：

(1)一旦有新的業務需求要關注這個事件，修改代碼的是通用上游upper，此時通用服務的owner就在心里罵娘了“為何有需求的是你，修改代碼的卻是我”;

(2)一旦業務側出問題，會影響上游通用基礎服務，此時通用服務的owner又在心里罵娘了“我ca，穩定性的KPI，全被兄弟部門毀了”;

(3)一旦業務側接口升級，上游基礎服務需要配合升級，此時通用服務的owner可能又會抱怨“為何被動升級的人總是我”;

架構不合理，簡直痛不欲生。

如何解耦呢?

如果事件發出方不關心訂閱方的執行結果，不能用RPC，應該用MQ。

MQ能夠做到上下游物理上和邏輯上都解耦：

(1)物理上解耦，增加MQ之后，上游互不知道彼此的存在，不會建立物理連接了，大家都只與MQ建立物理連接;

(2)邏輯上解耦，事件發布方甚至不用知道哪些下游訂閱了這個消息，新增消息的訂閱方只需要連接MQ就行了，不需要上游關注;

MQ是一個非常常見的物理上解耦、邏輯上也解耦的利器。

• 關注下游執行執行結果，用RPC。
• 不關注下游執行結果，用MQ，不用RPC。

這只是一個很小的優化點，但對于通知解耦卻是非常有效。

希望每天收獲一點點，架構就能美好一點點。

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文