遠程調用服務(RPC)和消息(Message Queue)對比及其適用/不適用場合

dubbo和MQ都是爲了解決分佈式應用之間的通訊問題，dubbo使用的RPC，側重於同步調用，客戶端會依賴服務端提供的接口而後進行調用。MQ使用的是觀察者模式，消息發送者只負責產生併發送消息，消息消費者只負責接收消息並作相應處理，二者並不知道對方的存在，MQ側重於異步通訊，耦合性較低。

我如今比較疑惑的地方時：何時該用dubbo,何時該用MQ

如下轉自阿里技術

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

大部分狀況下，「給定場景下應該使用這兩個產品中哪一個」這個問題，你們都會容易決定，並且不須要多少討論。

我爲何要拿出來討論一下：

一些場景會比較模糊，以爲均可以使用。這時須要知道產品缺點，而不是看到優點。

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

這裏簡單說一下二者的區別。

系統結構

功能特色

在架構上，RPC和Message的差別點是，Message有一箇中間結點Message Queue，能夠把消息存儲。

消息的特色

1：Message Queue把請求的壓力保存一下，逐漸釋放出來，讓處理者按照本身的節奏來處理。
2：Message Queue引入一下新的結點，讓系統的可靠性會受Message Queue結點的影響。
3：Message Queue是異步單向的消息。發送消息設計成是不須要等待消息處理的完成。
因此對於有同步返回需求，用Message Queue則變得麻煩了。

PRC的特色

1：同步調用，對於要等待返回結果/處理結果的場景，RPC是能夠很是天然直覺的使用方式。 
  # RPC也能夠是異步調用。
2：因爲等待結果，Consumer（Client）會有線程消耗。
若是以異步RPC的方式使用，Consumer（Client）線程消耗能夠去掉。但不能作到像消息同樣暫存消息/請求，壓力會直接傳導到服務Provider。

適用場合說明

1：但願同步獲得結果的場合，RPC合適。:
2：但願使用簡單，則RPC；RPC操做基於接口，使用簡單，使用方式模擬本地調用。異步的方式編程比較複雜。
3：不但願發送端（RPC Consumer、Message Sender）受限於處理端（RPC Provider、Message Receiver）的速度時，使用Message Queue。
隨着業務增加，有的處理端處理量會成爲瓶頸，會進行同步調用到異步消息的改造。
這樣的改造實際上有調整業務的使用方式。
好比原來一個操做頁面提交後就下一個頁面會看處處理結果；改造後異步消息後，下一個頁面就會變成「操做已提交，完成後會獲得通知」。

不適用場合說明

RPC同步調用使用Message Queue來傳輸調用信息。
上面分析能夠知道，這樣的作法，發送端是在等待，同時佔用一箇中間點的資源。變得複雜了，但沒有對等的收益。
對於返回值是void的調用，能夠這樣作，由於實際上這個調用業務上每每不須要同步獲得處理結果的，只要保證會處理便可。（RPC的方式能夠保證調用返回即處理完成，使用消息方式後這一點不能保證了。）
返回值是void的調用，使用消息，效果上是把消息的使用方式Wrap成了服務調用（服務調用使用方式成簡單，基於業務接口）。

補記，關於解耦討論

微博上inter12的一些討論，以爲頗有意義補記下來

inter12：這二者能夠拿來比較，可是我的感受並非同一個層面的問題。RPC是分佈式服務之間調用的一種解決方案，是咱們在作架構設計決策時同分布式對象，REST等層面的東西比較，決策的一個方案！ 消息系統更可能是咱們爲了解決系統之間的解耦，以及性能問題等方面所考慮的方案！ 說的有些亂，望鼎哥指點下。
oldratlee：回覆@inter12:你說到不少關鍵點了，「分佈式對象」「解耦」「性能」，這些均可以用來看二者的差別。 若是從兩個機器間數據的傳遞（調用、消息都是數據）角度看，二者效果相同，區別只是使用方式、技術指標：同步異步（好比 是否等反饋 ）、數據是否暫存、強弱類型（好比 有獨立的業務方法，數據類型）等等

nter12提到了「解耦」，「解決系統之間的解耦」使用消息時你們經常說到的一點，一個重要權衡方面！

我的以爲，「解耦」不如「暫存」，是消息相對RPC的關鍵區別，緣由說明以下：

消息的解耦特徵，主要體如今：

消息的發送者，不須要關心接收者的信息。

服務經過註冊中心也能夠作到，即服務調用者到註冊中心查詢服務提供者信息，調用者不需知道。

消息的發送者，不用關心能夠發個幾個關心的消息組件。 

這一點RPC能夠經過服務編排作到。