http://www.ihowandwhy.com/z/%E6%B6%88%E6%81%AF%E4%BB%A3%E7%90%86%E4%B8%8ERPC%E6%A1%86%E6%9E%B6%E6%9C%89%E4%BB%80%E4%B9%88%E5%8C%BA%E5%88%AB%E5%92%8C%E8%81%94%E7%B3%BB%EF%BC%9F
我了解一下protocol buffer ，ThriftRPC框架 和 ActiveMQ，RabbitMQ消息代理框架， 有點弄不清它們的應用場景 和 它們之間的聯系與區別。 望 大家 指點迷津！ 謝謝！
總的來說，消息代理和RPC框架就像ReadFileEx和ReadFile的區別
就是個消息池，不固化消息形式，你用什么協議取，消息池就返回給你什么樣的數據形式，這樣不同系統間就可以無縫通信了
MQ 是生產者消費者模式。
RPC 是請求響應模式。
MQ 是面向數據的。
RPC 是面向動作的。
protocol buffer 只是一個序列化方式，並不是 RPC。
rpc讓你遠程調用象本地調用，一般是同步的，例如，你讀一個文件，象調用本地的函數，就是時間久點。
消息代理框架一般是異步的，一個線程send，另外一個線程recv
pb只是協議包裝，thrift才是真正的rpc框架
protool buffer 是一種序列化方式，google開源的gPRC則是一個基於Protocol Buffers序列化的RPC框架，Thrift也是個RPC框架 ，這兩個都是跨平台RPC框架
RPC一般用於同步場景
ActiveMQ，RabbitMQ是流行的消息隊列（消息中間件），消息隊列一般用於異步場景
protocol buffer 是二進制序列化方式，類似json(文本)，題主說的應該是grpc吧
主要的區別就是消息隊列適用於異步場景，而rpc是遠程同步調用
就像你去餐廳吃飯，
消息隊列:不急不急，來了先放碗里，我和朋友聊着，有空在吃~
rpc:快點啊！我等了好久了- -
最大的區別是，rpc沒有broker, 而消息隊列是需要管理消息的存儲的，rpc沒有存儲，只有通信。
不管是消息隊列還是rpc調用都是 分布式下面的 通信方式。
消息隊列最容易理解的方式就是生產者消費者模式，使兩個應用解耦。mq等框架就是對這的具體實現。
rpc中主要有兩點，一是消息的傳輸格式(文本或二進制)，二是消息傳輸方式(http或tcp)。有的框架是對前者實現，如probuffer，有的是對后面實現，如netty，還有的就是一個整體實現，如thrift。
不管怎樣，他們都是為了實現通信。
消息隊列是系統級、模塊級的通信。RPC是對象級、函數級通信。
什么是RPC
提到RPC(Remote Procedure Call)，就躲不開提到分布式，這個促使RPC誕生的領域。
假設你有一個Calculator，以及它的實現類CalculatorImpl，那么單體應用時，要調用Calculator的add方法來執行一個加運算，你可以方法中直接使用，因為在同一個地址空間，或者說在同一塊內存，這個稱為本地函數調用。
現在，將系統改造為分布式應用，接口調用和實現分別在兩個子系統內，
服務A里頭並沒有CalculatorImpl這個類，那它要怎樣調用服務B的CalculatorImpl的add方法呢?可以模仿B/S架構的調用方式，在B服務暴露一個Restful接口，然后A服務通過調用這個Restful接口來間接調用CalculatorImpl的add方法。
這樣，已經很接近RPC了，不過，像這種每次調用時，是不是都需要寫一串發起http請求的代碼呢?比如httpClient.sendRequest...之類的，能不能簡單一下，像本地方法調用一樣，去發起遠程調用，讓使用者感知不到遠程調用的過程。
屏蔽的工作，可以使用代理模式解決，生成一個代理對象，而這個代理對象的內部，就是通過httpClient來實現RPC遠程過程調用的。
這就是很多RPC框架要解決的問題和解決的思路，比如阿里的Dubbo。
總結一下，RPC要解決的兩個問題：
1. 解決分布式系統中，服務之間的調用問題。
2. 遠程調用時，要能夠像本地調用一樣方便，讓調用者感知不到遠程調用的邏輯。
RPC是一種技術的概念名詞
RPC=Remote Produce Call 是一種技術的概念名詞，HTTP是一種協議,RPC可以通過 HTTP 來實現,也可以通過Socket自己實現一套協議來實現.所以題目可以換一種理解,為何 RPC 還有除 HTTP 之外的實現法,有何必要，畢竟除了HTTP實現外,私有協議不具備通用性.
RPC框架好處
http接口是在接口不多、系統與系統交互較少的情況下，解決信息孤島初期常使用的一種通信手段;
優點就是簡單、直接、開發方便。
如果是一個大型的網站，內部子系統較多、接口非常多的情況下，RPC框架的好處就顯示出來了：
首先就是長鏈接，不必每次通信都要像http一樣去3次握手什么的，減少了網絡開銷;
其次就是RPC框架一般都有注冊中心，有豐富的監控管理;發布、下線接口、動態擴展等，對調用方來說是無感知、統一化的操作。
最后是安全性。
rpc是一種概念，http也是rpc實現的一種方式。
論復雜度，dubbo/hessian用起來是超級簡單的。
至於為什么用dubbo/hessian，有幾點：
一是調用簡單，真正提供了類似於調用本地方法一樣調用接口的功能 。
二是參數返回值簡單明了 參數和返回值都是直接定義在jar包里的，不需要二次解析。
三是 輕量，沒有多余的信息。
四是便於管理，基於dubbo的注冊中心。
RPC能解耦服務
RPC:遠程過程調用。RPC的核心並不在於使用什么協議。RPC的目的是讓你在本地調用遠程的方法，而對你來說這個調用是透明的，你並不知道這個調用的方法是部署哪里。
通過RPC能解耦服務，這才是使用RPC的真正目的。RPC的原理主要用到了動態代理模式，至於http協議，只是傳輸協議而已。簡單的實現可以參考spring remoting，復雜的實現可以參考dubbo。
rpc=socket + 動態代理
服務器通訊原理就是一台socket服務器A,另一台socket客戶端B,現在如果要通訊的話直接以流方式寫入或讀出。這樣能實現通訊，但有個問題。如何知道更多信息?
比如需要發送流大小，編碼，Ip等。這樣就有了協議，協議就是規范，就是發送的流中攜帶了很多的內容。那回到剛剛的問題。發送的內容就是文本類型，客戶端就得序列化，那么常用的就有json，xml之類，如果想把內容變得更小，那就有二進制了。把文本變成二進制傳遞。
說到 rpc 與http接口，不要太復雜了。rpc 協議更簡單內容更小，那么來說效率是要高一點
rpc 是什么?就是socket 加動態代理。
總結
學技術應該是知其然知其所以然，我們得明白什么場景，或者什么業務需要它，它能解決其他技術不能解決或者不方便解決的問題。
RPC是一個軟件結構概念，是構建分布式應用的理論基礎。就好比為啥你家可以用到發電廠發出來的電?是因為電是可以傳輸的。至於用銅線還是用鐵絲還是其他種類的導線，也就是用http還是用其他協議的問題了。這個要看什么場景，對性能要求怎么樣。
在java中的最基本的就是RMI技術，它是java原生的應用層分布式技術。我們可以肯定的是在傳輸性能方面，RMI的性能是優於HTTP的。
那為啥很少用到這個技術?那是因為用這個有很多局限性，首先它要保證傳輸的兩端都要要用java實現，且兩邊需要有相同的對象類型和代理接口，不需要容器，但是加大了編程的難度，在應用內部的各個子系統之間還是會看到他的身影，比如EJB就是基於rmi技術的。
這就與目前的bs架構的軟件大相徑庭。用http必須要服務端位於http容器里面，這樣減少了網絡傳輸方面的開發，只需要關注業務開發即可。所以在架構一個軟件的時候，不能一定根據需求選定技術。