調用：RPC MQ

調用是系統的血液循環，只有有了調用，系統各部分才能產生關係，數據才能流動，邏輯才能完成。

為什麼調用如此關鍵？這是因為無論是架構設計還是代碼開發，結構都是分層或者分散式。分層的目的是高內聚低耦合，但不能彼此孤立，所以就需要上游調用下游。

常見的調用關係以下幾種：

1. 類之間的調用鏈
2. 模塊之間的調用鏈
3. 機器之間的調用鏈（網路調用，遠程調用）

這裡說下機器之間的調用，常見的有兩種調用方式：

1. RPC（Remote Procedure Call）
2. MQ（Message Queue）

這種方式到底有什麼不同呢？分別適合什麼場景呢？

以上架構是登錄系統調用驗證系統，使用兩種不同的調用方式。其中第一種是正確設計。如果上游關心（貨依賴）下游返回結果，那麼使用RPC，因為上游會根據返回結果進行相關處理，比如：

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

如果此時使用MQ，多了一個中間層，毫無必要，反而可能會帶來消息丟失等問題。

MQ適用於上游不關係或不依賴下游的情況，此時能做到上下游的解耦，尤其一個上游對應多個下游的情況。（比如上游產生一份數據或者消息，供N個下游消費）

以上架構，上游產生消息使用RPC通知多個下游，此時會產生以下耦合

1. 下游出現問題，會影響上游的調用；
2. 下游水平擴展，那麼上游也需要修改；
3. 下游修改或者升級介面，上游也需要修改

此時宜使用MQ去除耦合，MQ能使上下游做到物理解耦和邏輯解耦。

1. 物理解耦：去掉上下游的物理連接，只需要連接MQ即可。
2. 邏輯解耦：去掉上下游的邏輯依賴，彼此不知道對方的存在，相忘於江湖。

總結：上游關注和依賴下游的響應，宜用RPC；上游不關注不依賴下游的響應，宜用MQ。

重點要理解RPC有哪些耦合，以及MQ如何解耦。

參考資料：MQ，互聯網架構解耦神器

推薦閱讀：