HTTP接口和RPC接口都是生產(chǎn)上常用的接口，顧名思義，HTTP接口使用基于HTTP協(xié)議的URL傳參調(diào)用，而RPC接口則基于遠(yuǎn)程過(guò)程調(diào)用。

RPC（即Remote Procedure Call，遠(yuǎn)程過(guò)程調(diào)用）和HTTP（HyperText Transfer Protocol，超文本傳輸協(xié)議），兩者前者是一種方法，后者則是一種協(xié)議。兩者都常用于實(shí)現(xiàn)服務(wù)，在這個(gè)層面最本質(zhì)的區(qū)別是RPC服務(wù)主要工作在TCP協(xié)議之上（也可以在HTTP協(xié)議），而HTTP服務(wù)工作在HTTP協(xié)議之上。由于HTTP協(xié)議基于TCP協(xié)議，所以RPC服務(wù)天然比HTTP更輕量，效率更勝一籌。

兩者都是基于網(wǎng)絡(luò)實(shí)現(xiàn)的，從這一點(diǎn)上，都是基于Client/Server架構(gòu)。

RPC（Remote Procedure Call）服務(wù)

RPC服務(wù)基本架構(gòu)包含了四個(gè)核心的組件，分別是Client、Server、Clent Stub以及Server Stub。

Client （客戶端）：服務(wù)調(diào)用方。

Server（服務(wù)端）：服務(wù)提供方。

Client Stub（客戶端存根）：存放服務(wù)端的地址消息，負(fù)責(zé)將客戶端的請(qǐng)求參數(shù)打包成網(wǎng)絡(luò)消息，然后通過(guò)網(wǎng)絡(luò)發(fā)送給服務(wù)提供方。

Server Stub（服務(wù)端存根）：接收客戶端發(fā)送的消息，再將客戶端請(qǐng)求參數(shù)打包成網(wǎng)絡(luò)消息，然后通過(guò)網(wǎng)絡(luò)遠(yuǎn)程發(fā)送給服務(wù)方。

RPC效率優(yōu)勢(shì)明顯，在實(shí)際開(kāi)發(fā)中，客戶端和服務(wù)端在技術(shù)方案中約定客戶端的調(diào)用參數(shù)和服務(wù)端的返回參數(shù)之后就可以各自開(kāi)發(fā)，任何客戶端只要按照接口定義的規(guī)范發(fā)送入?yún)⒍伎梢哉{(diào)用該RPC服務(wù)，服務(wù)端也能按接口定義的規(guī)范出參返回計(jì)算結(jié)果。這樣既實(shí)現(xiàn)了客戶端和服務(wù)端之間的解耦，也使得RPC接口可以在多個(gè)項(xiàng)目中重復(fù)利用。

RPC調(diào)用分為同步方式和異步方式。同步調(diào)用即客戶端等待調(diào)用完成并返回結(jié)果；異步調(diào)用即客戶端不等待調(diào)用執(zhí)行完成返回結(jié)果，變成單向調(diào)用或者通過(guò)回調(diào)函數(shù)等待接收到返回結(jié)果的通知。

流行的RPC框架

目前流行的RPC框架有很多，下面介紹常見(jiàn)的三種。

gRPC： gRPC是Google公布的開(kāi)源項(xiàng)目，基于HTTP2.0協(xié)議，并支持常見(jiàn)的眾多編程語(yǔ)言。HTTP 2.0協(xié)議是基于二進(jìn)制的HTTP協(xié)議的升級(jí)版本，gRPC底層使用了Netty框架。

Thrift： Thrift是Facebook的一個(gè)開(kāi)源項(xiàng)目，主要是一個(gè)跨語(yǔ)言的服務(wù)開(kāi)發(fā)框架。它有一個(gè)代碼生成器來(lái)對(duì)它所定義的IDL文件自動(dòng)生成服務(wù)代碼框架。Thrift對(duì)于底層的RPC通訊都是透明的，用戶只需要對(duì)其進(jìn)行二次開(kāi)發(fā)即可，省去了一系列重復(fù)的前置基礎(chǔ)開(kāi)發(fā)工作。

Dubbo： Dubbo是阿里集團(tuán)開(kāi)源的一個(gè)極為出名的RPC框架，在很多互聯(lián)網(wǎng)公司和企業(yè)應(yīng)用中廣泛使用。協(xié)議和序列化框架都可以插拔是及其鮮明的特色。

HTTP服務(wù)

通過(guò)HTTP URL調(diào)用的服務(wù)，瀏覽器訪問(wèn)本質(zhì)上也算HTTP服務(wù)，不同的是需要客戶端瀏覽器渲染服務(wù)端返回的結(jié)果。

HTTP服務(wù)開(kāi)發(fā)即開(kāi)發(fā)ERESTful風(fēng)格的服務(wù)接口。在接口不多、系統(tǒng)之間交互較少的情況下，是一種信息傳遞的常用通信手段。

HTTP接口的優(yōu)點(diǎn)是簡(jiǎn)單、直接、開(kāi)發(fā)方便，利用現(xiàn)成的HTTP協(xié)議進(jìn)行傳輸。在服務(wù)開(kāi)發(fā)的時(shí)候，約定一個(gè)接口文檔，嚴(yán)格定義輸入和輸出，明確每一個(gè)接口的請(qǐng)求方法和需要的請(qǐng)求參數(shù)及其格式。

在內(nèi)部子系統(tǒng)較多、接口較多的情況下，RPC框架的好處就凸顯出現(xiàn)了，首先是長(zhǎng)連接，不必每次通信都要像HTTP那樣三次握手，減少了網(wǎng)絡(luò)開(kāi)銷(xiāo)；其次是RPC框架一般都有注冊(cè)中心，有豐富的監(jiān)控發(fā)布方法；RPC接口的發(fā)布、下線、動(dòng)態(tài)擴(kuò)展等對(duì)調(diào)用方是無(wú)感知的、統(tǒng)一化的操作。

Restful

Restful web service是一種常見(jiàn)的rest應(yīng)用，統(tǒng)一用于命名遵循rest風(fēng)格的web服務(wù)。Restful服務(wù)是一種ROA（Resource-Oriented Architecture，面向資源的架構(gòu)）。舉一個(gè)例子就可以理解了：

Restful出現(xiàn)之前的HTTP接口：

http://127.0.0.1/user/query ? GET ?根據(jù)用戶id查詢(xún)用戶數(shù)據(jù)

http://127.0.0.1/user/save ? ?POST 新增用戶

http://127.0.0.1/user/update POST 修改用戶信息

http://127.0.0.1/user/delete ?GET/POST 刪除用戶信息

Restful式HTTP接口:

http://127.0.0.1/user ?GET ?根據(jù)用戶id查詢(xún)用戶數(shù)據(jù)

http://127.0.0.1/user ?POST 新增用戶

http://127.0.0.1/user ?PUT 修改用戶信息

http://127.0.0.1/user ?DELETE 刪除用戶信息

RPC接口和HTTP接口的區(qū)別與聯(lián)系

RPC接口即相當(dāng)于調(diào)用本地接口一樣調(diào)用遠(yuǎn)程服務(wù)的接口；HTTP接口是基于http協(xié)議的post接口和get接口（等等，2.0版本協(xié)議子支持更多）。

傳輸協(xié)議

RPC：可以基于TCP協(xié)議，也可以基于HTTP協(xié)議。

HTTP：基于HTTP協(xié)議。

傳輸效率

RPC：使用自定義的TCP協(xié)議，可以讓請(qǐng)求報(bào)文體積更小，或者使用HTTP2.0協(xié)議，也可以很好地減少報(bào)文體積，提高傳輸效率。

HTTP：如果時(shí)基于HTTP1.1的協(xié)議，請(qǐng)求中會(huì)包含很多無(wú)用的內(nèi)容；如果是基于HTTP2.0，那么簡(jiǎn)單地封裝一下還是可以作為一個(gè)RPC使用的，這時(shí)標(biāo)準(zhǔn)RPC框架更多是服務(wù)治理。

性能消耗

RPC：可以基于thrift實(shí)現(xiàn)高效的二進(jìn)制傳輸

HTTP：大部分是通過(guò)json實(shí)現(xiàn)的，字節(jié)大小和序列化耗時(shí)都比thrift要更消耗性能

負(fù)載均衡

RPC：基本都自帶了負(fù)載均衡策略

HTTP：需要配置Nginx，HAProxy實(shí)現(xiàn)

服務(wù)治理（下游服務(wù)新增，重啟，下線時(shí)如何不影響上游調(diào)用者）

RPC：能做到自動(dòng)通知，不影響上游

HTTP：需要事先通知，修改Nginx/HAProxy配置

RPC主要用于公司內(nèi)部服務(wù)調(diào)用，性能消耗低，傳輸效率高，服務(wù)治理方便。HTTP主要用于對(duì)外的異構(gòu)環(huán)境，瀏覽器調(diào)用，APP接口調(diào)用，第三方接口調(diào)用等等。

RPC和HTTP都可以用于實(shí)現(xiàn)遠(yuǎn)程過(guò)程調(diào)用，如何選擇？

從速度上看，RPC比HTTP更快，雖然底層都是TCP，但是http協(xié)議的信息往往比較臃腫，不過(guò)可以采用gzip壓縮

從難度上看，RPC實(shí)現(xiàn)較為復(fù)雜，http相對(duì)簡(jiǎn)單

從靈活性上看，HTTP更勝一籌，因?yàn)樗魂P(guān)心實(shí)現(xiàn)細(xì)節(jié)，跨平臺(tái)，跨語(yǔ)言

兩者有不同的使用場(chǎng)景：

如果對(duì)效率要求更高，并且開(kāi)發(fā)過(guò)程使用統(tǒng)一的技術(shù)棧，那么RPC還是不錯(cuò)的

如果需要更加靈活，跨語(yǔ)言、跨平臺(tái)，顯然HTTP更合適

再插一句，最近新興的微服務(wù)概念更加強(qiáng)調(diào)獨(dú)立、自治、靈活，而RPC限制較多。因此微服務(wù)框架中，一般都會(huì)采用HTTP的Restful服務(wù)，像在公司內(nèi)部使用hsf協(xié)議，對(duì)接外部系統(tǒng)使用微服務(wù)。

參考文獻(xiàn)

https://www.cnblogs.com/Dong-Ge/articles/9577019.html

https://www.jianshu.com/p/9ccdea882688

https://www.cnblogs.com/111testing/p/11297037.html

編輯：黃飛

?