在阿里的平臺技術部參與開發了Dubbo（遠程調用服務）和Napoli（消息解決方案），又給網站應用支持這2個產品很長一段時間，瞭解了這2個產品的實現及應用對這兩個產品的用法。
大部分情況下，“給定場景下應該使用這兩個產品中哪個”這個問題，大家都會容易決定，而且不需要多少討論。
我爲什麼要拿出來討論一下：
- 一些場景會比較模糊，覺得都可以使用。這時需要知道產品缺點，而不是看到優勢。
- 一些新人會覺得產品功能是可以替換的，要給說明一下。
這裏簡單說一下兩者的區別。
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則方向。
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成了服務調用（服務調用使用方式成簡單，基於業務接口）。
PS： 也發在個人博客 遠程調用服務(RPC)和消息(Message Queue)對比及其適用/不適用場合