RPC（即Remote Procedure Call，遠程過程調用）
他們最本質的區別，就是RPC主要是基於TCP/IP協議的，而HTTP服務主要是基於HTTP協議的，HTTP協議是在傳輸層協議TCP之上的，所以效率來看的話，RPC當然是要更勝一籌！
RPC服務
從三個角度來介紹RPC服務：分別是RPC架構，同步異步調用以及流行的RPC框架。
RPC架構
先說說RPC服務的基本架構吧。一個完整的RPC架構裏面包含了四個核心的組件，分別是Client ,Server,Client Stub以及Server Stub，這個Stub大家可以理解爲存根。分別說說這幾個組件：
- 客戶端（Client），服務的調用方。
- 服務端（Server），真正的服務提供者。
- 客戶端存根，存放服務端的地址消息，再將客戶端的請求參數打包成網絡消息，然後通過網絡遠程發送給服務方。
- 服務端存根，接收客戶端發送過來的消息，將消息解包，並調用本地的方法。
RPC主要是用在大型企業裏面，因爲大型企業裏面系統繁多，業務線複雜，而且效率優勢非常重要的一塊，這個時候RPC的優勢就比較明顯了。
同步調用與異步調用
什麼是同步調用？什麼是異步調用？同步調用就是客戶端等待調用執行完成並返回結果。異步調用就是客戶端不等待調用執行完成返回結果，不過依然可以通過回調函數等接收到返回結果的通知。如果客戶端並不關心結果，則可以變成一個單向的調用。這個過程有點類似於Java中的callable和runnable接口，我們進行異步執行的時候，如果需要知道執行的結果，就可以使用callable接口，並且可以通過Future類獲取到異步執行的結果信息。如果不關心執行的結果，直接使用runnable接口就可以了，因爲它不返回結果，當然啦，callable也是可以的，我們不去獲取Future就可以了。
流行的RPC框架
目前流行的開源RPC框架還是比較多的。下面重點介紹三種：
- gRPC是Google最近公佈的開源軟件，基於最新的HTTP2.0協議，並支持常見的衆多編程語言。 我們知道HTTP2.0是基於二進制的HTTP協議升級版本，目前各大瀏覽器都在快馬加鞭的加以支持。 這個RPC框架是基於HTTP協議實現的，底層使用到了Netty框架的支持。
- Thrift是Facebook的一個開源項目，主要是一個跨語言的服務開發框架。它有一個代碼生成器來對它所定義的IDL定義文件自動生成服務代碼框架。用戶只要在其之前進行二次開發就行，對於底層的RPC通訊等都是透明的。不過這個對於用戶來說的話需要學習特定領域語言這個特性，還是有一定成本的。
- Dubbo是阿里集團開源的一個極爲出名的RPC框架，在很多互聯網公司和企業應用中廣泛使用。協議和序列化框架都可以插拔是及其鮮明的特色。同樣 的遠程接口是基於Java Interface，並且依託於spring框架方便開發。可以方便的打包成單一文件，獨立進程運行，和現在的微服務概念一致。
總結
RPC服務和HTTP服務還是存在很多的不同點的，一般來說，RPC服務主要是針對大型企業的，而HTTP服務主要是針對小企業的，因爲RPC效率更高，而HTTP服務開發迭代會更快。總之，選用什麼樣的框架不是按照市場上流行什麼而決定的，而是要對整個項目進行完整地評估，從而在仔細比較兩種開發框架對於整個項目的影響，最後再決定什麼纔是最適合這個項目的。一定不要爲了使用RPC而每個項目都用RPC，而是要因地制宜，具體情況具體分析。