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

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

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

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

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

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

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

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

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

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

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

流行的RPC框架

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

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

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

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

HTTP服務(wù)

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

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

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

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

Restful

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

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

http://127.0.0.1/user/query ? GET ?根據(jù)用戶id查詢用戶數(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查詢用戶數(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)用遠程服務(wù)的接口；HTTP接口是基于http協(xié)議的post接口和get接口（等等，2.0版本協(xié)議子支持更多）。

傳輸協(xié)議

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

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

傳輸效率

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

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

性能消耗

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

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

負載均衡

RPC：基本都自帶了負載均衡策略

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

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

RPC：能做到自動通知，不影響上游

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

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

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

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

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

從靈活性上看，HTTP更勝一籌，因為它不關(guān)心實現(xiàn)細節(jié)，跨平臺，跨語言

兩者有不同的使用場景：

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

如果需要更加靈活，跨語言、跨平臺，顯然HTTP更合適

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

參考文獻

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

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

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

編輯：黃飛

?