一、七層網(wǎng)絡(luò)結(jié)構(gòu)模型：我們先來(lái)了解一下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ì)話層。管理用戶(hù)的會(huì)話，控制用戶(hù)間邏輯

一、七層網(wǎng)絡(luò)結(jié)構(gòu)模型：

我們先來(lái)了解一下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ì)話層。管理用戶(hù)的會(huì)話，百思特網(wǎng)控制用戶(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ì)話層的。應(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一些！

二、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.test.百思特網(wǎng)com/restful/user/info

接口可能返回一個(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ā)布、下線接口、動(dòng)態(tài)擴(kuò)展等，對(duì)調(diào)用方來(lái)說(shuō)是無(wú)感知、統(tǒng)一化的操作。

三、RPC 架構(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)用本地的方法。

四、 什么時(shí)候需要PRC：

先來(lái)看一下，沒(méi)有RPC的時(shí)候，會(huì)怎么樣：

在過(guò)去是這樣的，包括現(xiàn)在很多對(duì)企業(yè)服務(wù)可能也是這樣，只有一個(gè)包部署在web服務(wù)器里。

那個(gè)時(shí)候，沒(méi)什么需要用到RPC的場(chǎng)景。

然后當(dāng)用戶(hù)量大的時(shí)候呢？漸漸出現(xiàn)了負(fù)載均衡。大概是這個(gè)樣子：

負(fù)載均衡能解決的問(wèn)題很多，但是還是不夠好，比如說(shuō)，只是某一個(gè)功能模塊（假設(shè)是用戶(hù)中心）被訪問(wèn)的次數(shù)特別頻繁，我可不可以把這部分內(nèi)容單獨(dú)拿出去？用戶(hù)中心的機(jī)器獨(dú)立，給它單獨(dú)的帶寬，給他單獨(dú)的服務(wù)器，給他單獨(dú)的數(shù)據(jù)庫(kù)？
不這么干其他的功能模塊都干不下去了啊。

以學(xué)校餐廳舉例：

學(xué)校餐廳，可以容納500人同時(shí)就餐，但是有一家面館，生意特別好，每到飯點(diǎn)來(lái)吃飯的人都有2000人，占滿了餐桌，排隊(duì)好幾百米，餐廳的其他攤位肯定不樂(lè)意了吧？

比如那個(gè)賣(mài)水餃的，雖然每天幾十個(gè)人來(lái)吃飯。百思特網(wǎng)那也是錢(qián)啊。你人這么多，想來(lái)我這吃飯的人都擠不進(jìn)來(lái)了，

大概情景是這樣的：

這樣能看懂吧？

遇到這種場(chǎng)景怎么辦？不可能不讓面館開(kāi)門(mén)營(yíng)業(yè)啊，那最好的方式就是：

“你可不可以搬出去？”

你不搬我們搬也行！（哭泣臉，反正我們是再也不要和你家面館開(kāi)在一起了，必須給我們一個(gè)說(shuō)法）

那么，搬家之后的樣子可能是這樣的。

總結(jié)

以上是生活随笔為你收集整理的prc是什么意思（为啥需要RPC，而不是简单的HTTP？）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。