一直在說，但是沒有系統的文件理解過。

1.本質

　　目前有很多Java的RPC框架，有基於Json的，有基於XML，也有基於二進位制物件的。

　　他們最本質的區別，就是RPC主要是基於TCP/IP協議的，而HTTP服務主要是基於HTTP協議的，我們都知道HTTP協議是在傳輸層協議TCP之上的，所以效率來看的話，RPC當然是要更勝一籌。

　　論複雜度，RPC框架肯定是高於簡單的HTTP介面的。但毋庸置疑，HTTP介面由於受限於HTTP協議，需要帶HTTP請求頭，導致傳輸起來效率或者說安全性不如RPC。

2.使用場景對比

　　http介面是在介面不多、系統與系統互動較少的情況下，解決資訊孤島初期常使用的一種通訊手段；優點就是簡單、直接、開發方便。利用現成的http協議 進行傳輸。

　　但是如果是一個大型的網站，內部子系統較多、介面非常多的情況下，RPC框架的好處就顯示出來了，首先就是長連結，不必每次通訊都要像http 一樣去3次握手什麼的，減少了網路開銷；其次就是RPC框架一般都有註冊中心，有豐富的監控管理；釋出、下線介面、動態擴充套件等，對呼叫方來說是無感知、統 一化的操作。第三個來說就是安全性。最後就是最近流行的服務化架構、服務化治理，RPC框架是一個強力的支撐

3.RPC原理目的核心

　　RPC:遠端過程呼叫。

　　RPC的核心並不在於使用什麼協議。

　　RPC的目的是讓你在本地呼叫遠端的方法，而對你來說這個呼叫是透明的，你並不知道這個呼叫的方法是部署哪裡。

　　通過RPC能解耦服務，這才是使用RPC的真正目的。

　　RPC的原理主要用到了動態代理模式，至於http協議，只是傳輸協議而已。簡單的實現可以參考spring remoting，複雜的實現可以參考dubbo。

4.區別

　　RPC 是 遠端過程呼叫，RPC 包含傳輸協議和編碼協議。

　　http是超文字傳輸協議，RPC 也可以用http作為傳輸協議，但一般是用 tcp作為傳輸協議。用json作為編碼協議。RPC的主要用在內部服務間的通訊。

5.聯絡

　　看完RPC的基本概念，那麼它與HTTP有何種聯絡，HTTP與RPC有什麼關聯嗎？

　　其實，HTTP協議也可以用來實現RPC框架，但是HTTP1.1協議的TCP報文包含太多沒用的資訊，如果使用HTTP1.1協議來實現RPC框架，顯然效率太低了。這也是為什麼那麼多的RPC框架都使用自有的協議進行封裝，以提高效能。

　　但是如今的HTTP2.0的編碼效率已大大優化，Google的grpc框架便是基於HTTP2.0協議實現。

　　所以，我們可以這麼理解，所謂RPC呼叫實際上與平常的HTTP呼叫過程相似，不同的是它更多的是封裝了“服務發現”，“異常監控”，"重試機制"等面向服務的高階特性。

6.常見的RPC

　　常見的RPC框架有Google的grpc、阿里的dubbo、Facebook的thrift以及Twitter的finagle等，它們不僅僅將複雜的呼叫過程的細節封裝遮蔽，更重要的提供了一整套大型分散式系統必備的高階服務特性。

7.什麼使用用Http

　　RPC服務主要是針對大型企業的，而HTTP服務主要是針對小企業的，因為RPC效率更高，而HTTP服務開發迭代會更快。