很長時間以來都沒有怎麼好好搞清楚 RPC（即 Remote Procedure Call，遠程過程調用）和 HTTP 調用的區別，不都是寫一個服務而後在客戶端調用麼？這裏請容許我迷之一笑~Naive！編程
本文簡單地介紹一下兩種形式的 C/S 架構，先說一下他們最本質的區別，就是 RPC 主要是基於 TCP/IP 協議的，而 HTTP 服務主要是基於 HTTP 協議的。瀏覽器
咱們都知道 HTTP 協議是在傳輸層協議 TCP 之上的，因此效率來看的話，RPC 固然是要更勝一籌啦！下面來具體說一說 RPC 服務和 HTTP 服務。restful
OSI 網絡七層模型網絡
在說 RPC 和 HTTP 的區別以前，我覺的有必要了解一下 OSI 的七層網絡結構模型（雖然實際應用中基本上都是五層）。架構
它能夠分爲如下幾層：（從上到下）框架
第一層：應用層。定義了用於在網絡中進行通訊和傳輸數據的接口。
第二層：表示層。定義不一樣的系統中數據的傳輸格式，編碼和解碼規範等。
第三層：會話層。管理用戶的會話，控制用戶間邏輯鏈接的創建和中斷。
第四層：傳輸層。管理着網絡中的端到端的數據傳輸。
第五層：網絡層。定義網絡設備間如何傳輸數據。
第六層：鏈路層。將上面的網絡層的數據包封裝成數據幀，便於物理層傳輸。
第七層：物理層。這一層主要就是傳輸這些二進制數據。異步
實際應用過程當中，五層協議結構裏面是沒有表示層和會話層的。應該說它們和應用層合併了。編程語言
咱們應該將重點放在應用層和傳輸層這兩個層面。由於 HTTP 是應用層協議，而 TCP 是傳輸層協議。函數
好，知道了網絡的分層模型之後咱們能夠更好地理解爲何 RPC 服務相比 HTTP 服務要 Nice 一些！微服務
RPC 服務
從三個角度來介紹 RPC 服務，分別是：
- RPC 架構
- 同步異步調用
- 流行的 RPC 框架
- RPC 架構
先說說 RPC 服務的基本架構吧。咱們能夠很清楚地看到，一個完整的 RPC 架構裏面包含了四個核心的組件。
分別是：
- Client
- Server
- Client Stub
- Server Stub（這個Stub你們能夠理解爲存根）
- 分別說說這幾個組件：
客戶端（Client），服務的調用方。
服務端（Server），真正的服務提供者。
客戶端存根，存放服務端的地址消息，再將客戶端的請求參數打包成網絡消息，而後經過網絡遠程發送給服務方。
服務端存根，接收客戶端發送過來的消息，將消息解包，並調用本地的方法。
RPC 主要是用在大型企業裏面，由於大型企業裏面系統繁多，業務線複雜，並且效率優點很是重要的一塊，這個時候 RPC 的優點就比較明顯了。實際的開發當中是這麼作的，項目通常使用 Maven 來管理。
好比咱們有一個處理訂單的系統服務，先聲明它的全部的接口（這裏就是具體指 Java 中的 Interface），而後將整個項目打包爲一個 jar 包，服務端這邊引入這個二方庫，而後實現相應的功能，客戶端這邊也只須要引入這個二方庫便可調用了。
爲何這麼作？主要是爲了減小客戶端這邊的 jar 包大小，由於每一次打包發佈的時候，jar 包太多老是會影響效率。另外也是將客戶端和服務端解耦，提升代碼的可移植性。
同步調用與異步調用
什麼是同步調用？什麼是異步調用？同步調用就是客戶端等待調用執行完成並返回結果。
異步調用就是客戶端不等待調用執行完成返回結果，不過依然能夠經過回調函數等接收到返回結果的通知。若是客戶端並不關心結果，則能夠變成一個單向的調用。
這個過程有點相似於 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 框架方便開發。能夠方便的打包成單一文件，獨立進程運行，和如今的微服務概念一致。
HTTP 服務
其實在好久之前，我對於企業開發的模式一直定性爲 HTTP 接口開發，也就是咱們常說的 RESTful 風格的服務接口。
的確，對於在接口很少、系統與系統交互較少的狀況下，解決信息孤島初期常使用的一種通訊手段；優勢就是簡單、直接、開發方便。
利用現成的 HTTP 協議進行傳輸。咱們記得以前本科實習在公司作後臺開發的時候，主要就是進行接口的開發，還要寫一大份接口文檔，嚴格地標明輸入輸出是什麼？說清楚每個接口的請求方法，以及請求參數須要注意的事項等。
好比下面這個例子：
POST http://www.httpexample.com/restful/buyer/info/shar
接口可能返回一個 JSON 字符串或者是 XML 文檔。而後客戶端再去處理這個返回的信息，從而能夠比較快速地進行開發。
可是對於大型企業來講，內部子系統較多、接口很是多的狀況下，RPC 框架的好處就顯示出來了，首先就是長連接，沒必要每次通訊都要像 HTTP 同樣去 3 次握手什麼的，減小了網絡開銷。
其次就是 RPC 框架通常都有註冊中心，有豐富的監控管理；發佈、下線接口、動態擴展等，對調用方來講是無感知、統一化的操做。
總結
RPC 服務和 HTTP 服務仍是存在不少的不一樣點的，通常來講，RPC 服務主要是針對大型企業的，而 HTTP 服務主要是針對小企業的，由於 RPC 效率更高，而 HTTP 服務開發迭代會更快。
總之，選用什麼樣的框架不是按照市場上流行什麼而決定的，而是要對整個項目進行完整地評估，從而在仔細比較兩種開發框架對於整個項目的影響，最後再決定什麼纔是最適合這個項目的。
必定不要爲了使用 RPC 而每一個項目都用 RPC，而是要因地制宜，具體狀況具體分析。