在微服務中，我應該使用pub/sub而不是RPC來獲得更鬆散的情侶架構？

Question

我目前使用RPC調用通過TCP的另一個微服務並獲得響應，但我認爲我可以這樣做：

沒有發出RPC調用，我可以使用pub/sub發送到一個服務，發佈等request_user和訂閱等object_user_response，然後被訂閱此request_user其他服務的信道，信道的一些發佈object_user_response。

就像是：

Service A <-- (sub)object_user_response <------ Redis 
Service A --> (pub)request_user -------------> Redis 

Service B <-- (sub)request_user <--------------- Redis 
Service B --> (pub) object_user_response ------> Redis 

在如果用戶的ID是一樣的，該功能已經請求接收object_user_response，服務A檢查。

我應該使用RPC還是Pub/sub？ 將數據發送到微服務並從鬆散耦合體系結構獲得響應的最正確方法是使用RPC調用還是使用兩個pub/sub進行請求，另一個用於響應？

Answer 1

其實這個問題沒有人回答。它取決於:-)

使用RPC從一方面你有更多的綁定服務之間的關係，但從另一方面你有更簡單的請求/響應通信模型。所以，一個服務發送請求需要來自另一個服務的響應或者如果它不可訪問則超時。 RPC與TCP也有會話和雙向通信方式。

通過pub/sub模型，一個服務發送一些關於發生的事件的消息，而不關心這個消息如何被另一個服務處理。或服務發送消息給一個特定的服務，並不期望從它的響應 - （單向請求）。當然，第二個服務可能會向第一個服務發送消息，也會傳遞一些工作結果。

鬆散耦合本身並不是一個目標 - 這是一種如何使系統更可靠，穩定，可擴展的方法，但它帶有一些價格，工作開銷，在某些情況下是不可能的或者根本就沒有必要。

因此，根據您的需要，您可以選擇第一種或第二種方法。當您不能簡單地發送請求並忘記或沒有意義時，使用RPC，無論如何您都需要響應。 RPC更容易實現。 Pub/sub適用於某些類型的「繁重」後臺作業，如圖像，視頻，文件處理，發送電子郵件等等，您將發送請求並在隊列中處理。藉助pub/sub，您可以更高效地利用資源。

Answer 2

取決於您的用例，並且與「解耦」無關。如果來自生產服務的呼叫必須等待消費服務的響應，則應使用同步消息（RPC）。當生產服務發送消息被另一個服務使用並且在不等待或者甚至需要響應的情況下繼續進行其結婚方式時，就使用像pub/sub這樣的異步通信形式。

在微服務世界中，當您可以避開它時，異步通信形式更可取，因爲阻塞的線程和等待響應的代價很高。良好的體系結構將幫助解耦服務之間的運行時間依賴關係，從而儘可能地獨立運行，而不直接依賴其他服務來完成它所分配的工作。