遠程調用服務(RPC)和消息(Message Queue)對比

　　在阿里的平臺技術部參與開發了Dubbo(遠程調用服務)和Napoli(消息解決方案)，又給網站應用支持這2個產品很長一段時間，了解了這2個產品的實現及應用對這兩個產品的用法。

　　大部分情況下，“給定場景下應該使用這兩個產品中哪個”這個問題，大家都會容易決定，而且不需要多少討論。

　　我為什么要拿出來討論一下：

　　一些場景會比較模糊，覺得都可以使用。這時需要知道產品缺點，而不是看到優勢。

　　一些新人會覺得產品功能是可以替換的，要給說明一下。

　　這里簡單說一下兩者的區別。

　　系統結構

　　功能特點

　　在架構上，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。

　　隨著業務增長，有的處理端處理量會成為瓶頸，會進行同步調用到異步消息的改造。

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

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

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