系統結構

RPC系統結構：

+----------+     +----------+
| Consumer | <=> | Provider |
+----------+     +----------+
Consumer呼叫的Provider提供的服務。


Message Queue系統結構：

+--------+     +-------+     +----------+
| Sender | <=> | Queue | <=> | Receiver |
+--------+     +-------+     +----------+
Sender傳送訊息給Queue；Receiver從Queue拿到訊息來處理。
 

功能特點

在架構上，RPC和Message的差異點是，Message有一箇中間結點Message Queue，可以把訊息儲存。

訊息的特點

• Message Queue把請求的壓力儲存一下，逐漸釋放出來，讓處理者按照自己的節奏來處理。
• Message Queue引入一下新的結點，讓系統的可靠性會受Message Queue結點的影響。
• Message Queue是非同步單向的訊息。傳送訊息設計成是不需要等待訊息處理的完成。

所以對於有同步返回需求，用Message Queue則變得麻煩了。

RPC的特點

• 同步呼叫，對於要等待返回結果/處理結果的場景，RPC是可以非常自然直覺的使用方式。
  # RPC也可以是非同步呼叫。
• 由於等待結果，Consumer（Client）會有執行緒消耗。

如果以非同步RPC的方式使用，Consumer（Client）執行緒消耗可以去掉。但不能做到像訊息一樣暫存訊息/請求，壓力會直接傳導到服務Provider。

適用場合說明

• 希望同步得到結果的場合，RPC合適。
• 希望使用簡單，則RPC；RPC操作基於介面，使用簡單，使用方式模擬本地呼叫。非同步的方式程式設計比較複雜。
• 不希望傳送端（RPC Consumer、Message Sender）受限於處理端（RPC Provider、Message Receiver）的速度時，使用Message Queue。

隨著業務增長，有的處理端處理量會成為瓶頸，會進行同步呼叫到非同步訊息的改造。

這樣的改造實際上有調整業務的使用方式。

比如原來一個操作頁面提交後就下一個頁面會看到處理結果；改造後非同步訊息後，下一個頁面就會變成“操作已提交，完成後會得到通知”。

不適用場合說明

RPC同步呼叫使用Message Queue來傳輸呼叫資訊。 上面分析可以知道，這樣的做法，傳送端是在等待，同時佔用一箇中間點的資源。變得複雜了，但沒有對等的收益。

對於返回值是void的呼叫，可以這樣做，因為實際上這個呼叫業務上往往不需要同步得到處理結果的，只要保證會處理即可。（RPC的方式可以保證呼叫返回即處理完成，使用訊息方式後這一點不能保證了。）

返回值是void的呼叫，使用訊息，效果上是把訊息的使用方式Wrap成了服務呼叫（服務呼叫使用方式成簡單，基於業務介面）。

轉自：http://oldratlee.com/post/2013-02-01/synchronous-rpc-vs-asynchronous-message