RPC和Message Queue對比
RPC、MQ的結構對比：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | RPC系統結構：+----------+ +----------+| Consumer | <=> | Provider |+----------+ +----------+Consumer調用的Provider提供的服務。Message Queue系統結構：+--------+ +-------+ +----------+| Sender | <=> | Queue | <=> | Receiver |+--------+ +-------+ +----------+Sender發送消息給Queue；Receiver從Queue拿到消息來處理。來源： <http://www.cnblogs.com/xiazh/archive/2013/03/17/2964203.html>
|
功能特點
在架構上，RPC和Message的差異點是，Message有一箇中間結點Message Queue，可以把消息存儲。
消息的特點
Message Queue把請求的壓力保存一下，逐漸釋放出來，讓處理者按照自己的節奏來處理。
Message Queue引入一下新的結點，讓系統的可靠性會受Message Queue結點的影響。
Message Queue是異步單向的消息。發送消息設計成是不需要等待消息處理的完成。
所以對於有同步返回需求，Message Queue則方向。
PRC的特點
同步調用，對於要等待返回結果/處理結果的場景，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成了服務調用（服務調用使用方式成簡單，基於業務接口）。