很長(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)看的話(huà)，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ì)話(huà)層。管理用戶(hù)的會(huì)話(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ì)話(huà)層的。應(yīng)該說(shuō)它們和應(yīng)用層合并了。我們應(yīng)該將重點(diǎn)放在應(yīng)用層和傳輸層這兩個(gè)層面。因?yàn)镠TTP是應(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ù)線(xiàn)復(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ō)的話(huà)需要學(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ù)概念一致。偷偷告訴你集團(tuán)內(nèi)部已經(jīng)不怎么使用dubbo啦，現(xiàn)在用的比較多的叫HSF，又名“好舒服”。后面有可能會(huì)開(kāi)源，大家拭目以待。

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)等。比如下面這個(gè)例子：POST http://www.httpexample.com/restful/buyer/info/share 接口可能返回一個(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ā)布、下線(xiàn)接口、動(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)镽PC效率更高，而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，而是要因地制宜，具體情況具體分析。

審核編輯 ：李倩