有了HTTP，為什么還要RPC？
很長時間以來都沒有怎么好好搞清楚 RPC（即 Remote Procedure Call，遠程過程調(diào)用）和 HTTP 調(diào)用的區(qū)別，不都是寫一個服務(wù)然后在客戶端調(diào)用么？這里請允許我迷之一笑~Naive！
本文簡單地介紹一下兩種形式的 C/S 架構(gòu)，先說一下他們最本質(zhì)的區(qū)別，就是 RPC 主要是基于 TCP/IP 協(xié)議的，而 HTTP 服務(wù)主要是基于 HTTP 協(xié)議的。
我們都知道 HTTP 協(xié)議是在傳輸層協(xié)議 TCP 之上的，所以效率來看的話，RPC 當(dāng)然是要更勝一籌啦！下面來具體說一說 RPC 服務(wù)和 HTTP 服務(wù)。
OSI 網(wǎng)絡(luò)七層模型
在說 RPC 和 HTTP 的區(qū)別之前，我覺的有必要了解一下 OSI 的七層網(wǎng)絡(luò)結(jié)構(gòu)模型（雖然實際應(yīng)用中基本上都是五層）。
它可以分為以下幾層：（從上到下）
第一層：應(yīng)用層。定義了用于在網(wǎng)絡(luò)中進行通信和傳輸數(shù)據(jù)的接口。
第二層：表示層。定義不同的系統(tǒng)中數(shù)據(jù)的傳輸格式，編碼和解碼規(guī)范等。
第三層：會話層。管理用戶的會話，控制用戶間邏輯連接的建立和中斷。
第四層：傳輸層。管理著網(wǎng)絡(luò)中的端到端的數(shù)據(jù)傳輸。
第五層：網(wǎng)絡(luò)層。定義網(wǎng)絡(luò)設(shè)備間如何傳輸數(shù)據(jù)。
第六層：鏈路層。將上面的網(wǎng)絡(luò)層的數(shù)據(jù)包封裝成數(shù)據(jù)幀，便于物理層傳輸。
第七層：物理層。這一層主要就是傳輸這些二進制數(shù)據(jù)。
實際應(yīng)用過程中，五層協(xié)議結(jié)構(gòu)里面是沒有表示層和會話層的。應(yīng)該說它們和應(yīng)用層合并了。
我們應(yīng)該將重點放在應(yīng)用層和傳輸層這兩個層面。因為 HTTP 是應(yīng)用層協(xié)議，而 TCP 是傳輸層協(xié)議。
好，知道了網(wǎng)絡(luò)的分層模型以后我們可以更好地理解為什么 RPC 服務(wù)相比 HTTP 服務(wù)要 Nice 一些！
RPC 服務(wù)
從三個角度來介紹 RPC 服務(wù)，分別是：
RPC 架構(gòu)
同步異步調(diào)用
流行的 RPC 框架
RPC 架構(gòu)
先說說 RPC 服務(wù)的基本架構(gòu)吧。我們可以很清楚地看到，一個完整的 RPC 架構(gòu)里面包含了四個核心的組件。
分別是：
Client
Server
Client Stub
Server Stub（這個Stub大家可以理解為存根）
分別說說這幾個組件：
客戶端（Client），服務(wù)的調(diào)用方。
服務(wù)端（Server），真正的服務(wù)提供者。
客戶端存根，存放服務(wù)端的地址消息，再將客戶端的請求參數(shù)打包成網(wǎng)絡(luò)消息，然后通過網(wǎng)絡(luò)遠程發(fā)送給服務(wù)方。
服務(wù)端存根，接收客戶端發(fā)送過來的消息，將消息解包，并調(diào)用本地的方法。
RPC 主要是用在大型企業(yè)里面，因為大型企業(yè)里面系統(tǒng)繁多，業(yè)務(wù)線復(fù)雜，而且效率優(yōu)勢非常重要的一塊，這個時候 RPC 的優(yōu)勢就比較明顯了。實際的開發(fā)當(dāng)中是這么做的，項目一般使用 Maven 來管理。
比如我們有一個處理訂單的系統(tǒng)服務(wù)，先聲明它的所有的接口（這里就是具體指 Java 中的 Interface），然后將整個項目打包為一個 jar 包，服務(wù)端這邊引入這個二方庫，然后實現(xiàn)相應(yīng)的功能，客戶端這邊也只需要引入這個二方庫即可調(diào)用了。
為什么這么做？主要是為了減少客戶端這邊的 jar 包大小，因為每一次打包發(fā)布的時候，jar 包太多總是會影響效率。另外也是將客戶端和服務(wù)端解耦，提高代碼的可移植性。
同步調(diào)用與異步調(diào)用
什么是同步調(diào)用？什么是異步調(diào)用？同步調(diào)用就是客戶端等待調(diào)用執(zhí)行完成并返回結(jié)果。
異步調(diào)用就是客戶端不等待調(diào)用執(zhí)行完成返回結(jié)果，不過依然可以通過回調(diào)函數(shù)等接收到返回結(jié)果的通知。如果客戶端并不關(guān)心結(jié)果，則可以變成一個單向的調(diào)用。
這個過程有點類似于 Java 中的 Callable 和 Runnable 接口，我們進行異步執(zhí)行的時候，如果需要知道執(zhí)行的結(jié)果，就可以使用 Callable 接口，并且可以通過 Future 類獲取到異步執(zhí)行的結(jié)果信息。
如果不關(guān)心執(zhí)行的結(jié)果，直接使用 Runnable 接口就可以了，因為它不返回結(jié)果，當(dāng)然啦，Callable 也是可以的，我們不去獲取 Future 就可以了。
流行的 RPC 框架
目前流行的開源 RPC 框架還是比較多的。下面重點介紹三種：
①gRPC?是 Google 最近公布的開源軟件，基于最新的 HTTP2.0 協(xié)議，并支持常見的眾多編程語言。
我們知道 HTTP2.0 是基于二進制的 HTTP 協(xié)議升級版本，目前各大瀏覽器都在快馬加鞭的加以支持。
這個 RPC 框架是基于 HTTP 協(xié)議實現(xiàn)的，底層使用到了 Netty 框架的支持。
②Thrift?是 Facebook 的一個開源項目，主要是一個跨語言的服務(wù)開發(fā)框架。它有一個代碼生成器來對它所定義的 IDL 定義文件自動生成服務(wù)代碼框架。
用戶只要在其之前進行二次開發(fā)就行，對于底層的 RPC 通訊等都是透明的。不過這個對于用戶來說的話需要學(xué)習(xí)特定領(lǐng)域語言這個特性，還是有一定成本的。
③Dubbo?是阿里集團開源的一個極為出名的 RPC 框架，在很多互聯(lián)網(wǎng)公司和企業(yè)應(yīng)用中廣泛使用。協(xié)議和序列化框架都可以插拔是及其鮮明的特色。
同樣的遠程接口是基于 Java Interface，并且依托于 Spring 框架方便開發(fā)?？梢苑奖愕拇虬蓡我晃募毩⑦M程運行，和現(xiàn)在的微服務(wù)概念一致。
HTTP 服務(wù)
其實在很久以前，我對于企業(yè)開發(fā)的模式一直定性為 HTTP 接口開發(fā)，也就是我們常說的 RESTful 風(fēng)格的服務(wù)接口。
的確，對于在接口不多、系統(tǒng)與系統(tǒng)交互較少的情況下，解決信息孤島初期常使用的一種通信手段；優(yōu)點就是簡單、直接、開發(fā)方便。
利用現(xiàn)成的 HTTP 協(xié)議進行傳輸。我們記得之前本科實習(xí)在公司做后臺開發(fā)的時候，主要就是進行接口的開發(fā)，還要寫一大份接口文檔，嚴格地標(biāo)明輸入輸出是什么？說清楚每一個接口的請求方法，以及請求參數(shù)需要注意的事項等。
POST?http://www.httpexample.com/restful/buyer/info/shar
接口可能返回一個 JSON 字符串或者是 XML 文檔。然后客戶端再去處理這個返回的信息，從而可以比較快速地進行開發(fā)。
但是對于大型企業(yè)來說，內(nèi)部子系統(tǒng)較多、接口非常多的情況下，RPC 框架的好處就顯示出來了，首先就是長鏈接，不必每次通信都要像 HTTP 一樣去 3 次握手什么的，減少了網(wǎng)絡(luò)開銷。
其次就是 RPC 框架一般都有注冊中心，有豐富的監(jiān)控管理；發(fā)布、下線接口、動態(tài)擴展等，對調(diào)用方來說是無感知、統(tǒng)一化的操作。
總結(jié)
RPC 服務(wù)和 HTTP 服務(wù)還是存在很多的不同點的，一般來說，RPC 服務(wù)主要是針對大型企業(yè)的，而 HTTP 服務(wù)主要是針對小企業(yè)的，因為 RPC 效率更高，而 HTTP 服務(wù)開發(fā)迭代會更快。
總之，選用什么樣的框架不是按照市場上流行什么而決定的，而是要對整個項目進行完整地評估，從而在仔細比較兩種開發(fā)框架對于整個項目的影響，最后再決定什么才是最適合這個項目的。
一定不要為了使用 RPC 而每個項目都用 RPC，而是要因地制宜，具體情況具體分析。