這篇文章主要介紹“HTTP與RPC有哪些區(qū)別”，在日常操作中，相信很多人在HTTP與RPC有哪些區(qū)別問題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”HTTP與RPC有哪些區(qū)別”的疑惑有所幫助！接下來，請(qǐng)跟著小編一起來學(xué)習(xí)吧！

10年積累的成都網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先做網(wǎng)站后付款的網(wǎng)站建設(shè)流程，更有昌都免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

OSI 網(wǎng)絡(luò)七層模型

在說 RPC 和 HTTP 的區(qū)別之前，我覺的有必要了解一下 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ì)話，控制用戶間邏輯連接的建立和中斷。
第四層：傳輸層。管理著網(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)用過程中，五層協(xié)議結(jié)構(gòu)里面是沒有表示層和會(huì)話層的。應(yīng)該說它們和應(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è)角度來介紹 RPC 服務(wù)，分別是：

• RPC 架構(gòu)

• 同步異步調(diào)用

• 流行的 RPC 框架

• RPC 架構(gòu)
  先說說 RPC 服務(wù)的基本架構(gòu)吧。我們可以很清楚地看到，一個(gè)完整的 RPC 架構(gòu)里面包含了四個(gè)核心的組件。

分別是：

• Client

• Server

• Client Stub

• Server Stub（這個(gè)Stub大家可以理解為存根）

• 分別說說這幾個(gè)組件：

客戶端（Client），服務(wù)的調(diào)用方。
服務(wù)端（Server），真正的服務(wù)提供者。
客戶端存根，存放服務(wù)端的地址消息，再將客戶端的請(qǐng)求參數(shù)打包成網(wǎng)絡(luò)消息，然后通過網(wǎng)絡(luò)遠(yuǎn)程發(fā)送給服務(wù)方。
服務(wù)端存根，接收客戶端發(fā)送過來的消息，將消息解包，并調(diào)用本地的方法。
RPC 主要是用在大型企業(yè)里面，因?yàn)榇笮推髽I(yè)里面系統(tǒng)繁多，業(yè)務(wù)線復(fù)雜，而且效率優(yōu)勢(shì)非常重要的一塊，這個(gè)時(shí)候 RPC 的優(yōu)勢(shì)就比較明顯了。實(shí)際的開發(fā)當(dāng)中是這么做的，項(xiàng)目一般使用 Maven 來管理。

比如我們有一個(gè)處理訂單的系統(tǒng)服務(wù)，先聲明它的所有的接口（這里就是具體指 Java 中的 Interface），然后將整個(gè)項(xiàng)目打包為一個(gè) jar 包，服務(wù)端這邊引入這個(gè)二方庫(kù)，然后實(shí)現(xiàn)相應(yīng)的功能，客戶端這邊也只需要引入這個(gè)二方庫(kù)即可調(diào)用了。

為什么這么做？主要是為了減少客戶端這邊的 jar 包大小，因?yàn)槊恳淮未虬l(fā)布的時(shí)候，jar 包太多總是會(huì)影響效率。另外也是將客戶端和服務(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é)果，則可以變成一個(gè)單向的調(diào)用。

這個(gè)過程有點(diǎn)類似于 Java 中的 Callable 和 Runnable 接口，我們進(jìn)行異步執(zhí)行的時(shí)候，如果需要知道執(zhí)行的結(jié)果，就可以使用 Callable 接口，并且可以通過 Future 類獲取到異步執(zhí)行的結(jié)果信息。

如果不關(guān)心執(zhí)行的結(jié)果，直接使用 Runnable 接口就可以了，因?yàn)樗环祷亟Y(jié)果，當(dāng)然啦，Callable 也是可以的，我們不去獲取 Future 就可以了。

流行的 RPC 框架
目前流行的開源 RPC 框架還是比較多的。下面重點(diǎn)介紹三種：

①gRPC 是 Google 最近公布的開源軟件，基于最新的 HTTP2.0 協(xié)議，并支持常見的眾多編程語(yǔ)言。

我們知道 HTTP2.0 是基于二進(jìn)制的 HTTP 協(xié)議升級(jí)版本，目前各大瀏覽器都在快馬加鞭的加以支持。

這個(gè) RPC 框架是基于 HTTP 協(xié)議實(shí)現(xiàn)的，底層使用到了 Netty 框架的支持。

②Thrift 是 Facebook 的一個(gè)開源項(xiàng)目，主要是一個(gè)跨語(yǔ)言的服務(wù)開發(fā)框架。它有一個(gè)代碼生成器來對(duì)它所定義的 IDL 定義文件自動(dòng)生成服務(wù)代碼框架。

用戶只要在其之前進(jìn)行二次開發(fā)就行，對(duì)于底層的 RPC 通訊等都是透明的。不過這個(gè)對(duì)于用戶來說的話需要學(xué)習(xí)特定領(lǐng)域語(yǔ)言這個(gè)特性，還是有一定成本的。

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

同樣的遠(yuǎn)程接口是基于 Java Interface，并且依托于 Spring 框架方便開發(fā)?？梢苑奖愕拇虬蓡我晃募?，獨(dú)立進(jìn)程運(yùn)行，和現(xiàn)在的微服務(wù)概念一致。

HTTP 服務(wù)

其實(shí)在很久以前，我對(duì)于企業(yè)開發(fā)的模式一直定性為 HTTP 接口開發(fā)，也就是我們常說的 RESTful 風(fēng)格的服務(wù)接口。

的確，對(duì)于在接口不多、系統(tǒng)與系統(tǒng)交互較少的情況下，解決信息孤島初期常使用的一種通信手段；優(yōu)點(diǎn)就是簡(jiǎn)單、直接、開發(fā)方便。

利用現(xiàn)成的 HTTP 協(xié)議進(jìn)行傳輸。我們記得之前本科實(shí)習(xí)在公司做后臺(tái)開發(fā)的時(shí)候，主要就是進(jìn)行接口的開發(fā)，還要寫一大份接口文檔，嚴(yán)格地標(biāo)明輸入輸出是什么？說清楚每一個(gè)接口的請(qǐng)求方法，以及請(qǐng)求參數(shù)需要注意的事項(xiàng)等。

比如下面這個(gè)例子：

POST http://www.httpexample.com/restful/buyer/info/shar

接口可能返回一個(gè) JSON 字符串或者是 XML 文檔。然后客戶端再去處理這個(gè)返回的信息，從而可以比較快速地進(jìn)行開發(fā)。

但是對(duì)于大型企業(yè)來說，內(nèi)部子系統(tǒng)較多、接口非常多的情況下，RPC 框架的好處就顯示出來了，首先就是長(zhǎng)鏈接，不必每次通信都要像 HTTP 一樣去 3 次握手什么的，減少了網(wǎng)絡(luò)開銷。

其次就是 RPC 框架一般都有注冊(cè)中心，有豐富的監(jiān)控管理；發(fā)布、下線接口、動(dòng)態(tài)擴(kuò)展等，對(duì)調(diào)用方來說是無感知、統(tǒng)一化的操作。

到此，關(guān)于“HTTP與RPC有哪些區(qū)別”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！

分享文章：HTTP與RPC有哪些區(qū)別
轉(zhuǎn)載注明：http://www.rwnh.cn/article6/pcopig.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站制作、電子商務(wù)、定制開發(fā)、虛擬主機(jī)、企業(yè)網(wǎng)站制作、外貿(mào)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)