基於 RPC 通信的微服務架構，其特點是一個服務依賴於其他服務返回的結果，只有依賴服務執行成功並返回後，這個服務才算調用成功。這種架構適用於用户請求是讀請求的情況，就像下圖所描述的那樣，比如用户的一次 Feed API 請求，會調用 Feed RPC 獲取關注人，調用 Card RPC 獲取視頻、文章等多媒體卡片信息，還會調用 User RPC 獲取關注人的暱稱和粉絲數等個人詳細信息，只有在這些信息都獲取成功後，這次用户的 Feed API 請求才算調用成功。

而基於 MQ 消息隊列通信的架構，其特點是服務之間的交互是通過消息發佈與訂閲的方式來完成的，一個服務往 MQ 消息隊列發佈消息，其他服務從 MQ 消息隊列訂閲消息並處理，發佈消息的服務並不等待訂閲消息服務處理的結果，而是直接返回調用成功。

這種架構適用於用户請求是寫請求的情況，就像下圖所描述的那樣，比如用户的寫請求，無論是發文、評論還是贊都會首先調用 Feed API，然後 Feed API 將用户的寫請求消息發佈到 MQ 中，然後就返回給用户請求成功。如果是發文請求，發文服務就會從 MQ 中訂閲到這條消息，然後更新用户發文列表的緩存和數據庫；如果是評論請求，評論服務就會從 MQ 中訂閲到這條消息，然後更新用户發出評論的緩存和數據庫，以及評論對象收到評論的緩存和數據庫；如果是贊請求，贊服務就會從 MQ 中訂閲到這條消息，然後更新用户發出讚的緩存和數據庫，以及贊對象收到的讚的緩存和數據庫。這樣設計的話，就把寫請求的返回與具體執行請求的服務進行解耦，給用户的體驗是寫請求已經執行成功，不需要等待具體業務邏輯執行完成。

總結一下就是，基於 RPC 通信和基於 MQ 消息隊列通信的方式都可以實現微服務的拆分，兩者的使用場景不同，RPC 主要用於用户讀請求的情況，MQ 主要用於用户寫請求的情況。對於大部分互聯網業務來説，讀請求要遠遠大於寫請求，所以針對讀請求的基於 RPC 通信的微服務架構的討論也更多一些，但並不代表基於 MQ 消息隊列不能實現，而是要區分開它們不同的應用場景。