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