直觀講解一下RPC調(diào)用和HTTP調(diào)用的區(qū)別_第1頁
直觀講解一下RPC調(diào)用和HTTP調(diào)用的區(qū)別_第2頁
直觀講解一下RPC調(diào)用和HTTP調(diào)用的區(qū)別_第3頁
直觀講解一下RPC調(diào)用和HTTP調(diào)用的區(qū)別_第4頁
直觀講解一下RPC調(diào)用和HTTP調(diào)用的區(qū)別_第5頁
已閱讀5頁,還剩1頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

直觀講解一下RPC調(diào)用和HTTP調(diào)用的區(qū)別很長(zhǎng)時(shí)間以來都沒有怎么好好搞清楚RPC(即RemoteProcedureCall,遠(yuǎn)程過程調(diào)用)和HTTP調(diào)用的區(qū)別,不都是寫一個(gè)服務(wù)然后在客戶端調(diào)用么?這里請(qǐng)?jiān)试S我迷之一笑~Naive!本文簡(jiǎn)單地介紹一下兩種形式的C/S架構(gòu),先說一下他們最本質(zhì)的區(qū)別,就是RPC主要是基于TCP/IP協(xié)議的,而HTTP服務(wù)主要是基于HTTP協(xié)議的,我們都知道HTTP協(xié)議是在傳輸層協(xié)議TCP之上的,所以效率來看的話,RPC當(dāng)然是要更勝一籌啦!下面來具體說一說RPC服務(wù)和HTTP服務(wù)。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)镠TTP是應(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,ClientStub以及ServerStub,這個(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è)二方庫,然后實(shí)現(xiàn)相應(yīng)的功能,客戶端這邊也只需要引入這個(gè)二方庫即可調(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é)議,并支持常見的眾多編程語言。我們知道HTTP2.0是基于二進(jìn)制的HTTP協(xié)議升級(jí)版本,目前各大瀏覽器都在快馬加鞭的加以支持。這個(gè)RPC框架是基于HTTP協(xié)議實(shí)現(xiàn)的,底層使用到了Netty框架的支持。Thrift是Facebook的一個(gè)開源項(xiàng)目,主要是一個(gè)跨語言的服務(wù)開發(fā)框架。它有一個(gè)代碼生成器來對(duì)它所定義的IDL定義文件自動(dòng)生成服務(wù)代碼框架。用戶只要在其之前進(jìn)行二次開發(fā)就行,對(duì)于底層的RPC通訊等都是透明的。不過這個(gè)對(duì)于用戶來說的話需要學(xué)習(xí)特定領(lǐng)域語言這個(gè)特性,還是有一定成本的。Dubbo是阿里集團(tuán)開源的一個(gè)極為出名的RPC框架,在很多互聯(lián)網(wǎng)公司和企業(yè)應(yīng)用中廣泛使用。協(xié)議和序列化框架都可以插拔是及其鮮明的特色。同樣的遠(yuǎn)程接口是基于JavaInterface,并且依托于spring框架方便開發(fā)??梢苑奖愕拇虬蓡我晃募?,獨(dú)立進(jìn)程運(yùn)行,和現(xiàn)在的微服務(wù)概念一致。

偷偷告訴你集團(tuán)內(nèi)部已經(jīng)不怎么使用dubbo啦,現(xiàn)在用的比較多的叫HSF,又名“好舒服”。后面有可能會(huì)開源,大家拭目以待。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/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)一化的操作。總結(jié)RPC服務(wù)和HTTP服務(wù)還是存在很多的不同點(diǎn)的,一般來說,RPC服務(wù)主要是針對(duì)大型企業(yè)的,而HTTP服務(wù)主要是針對(duì)小企業(yè)的,因?yàn)镽PC效率更高,而

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論