一、七層網絡結構模型：

我們先來了解一下OSI的七層網絡結構模型（雖然實際應用中基本上都是五層），它可以分為以下幾層：（從上到下）

• 第一層：應用層。定義了用于在網絡中進行通信和傳輸數據的接口；
• 第二層：表示層。定義不同的系統中數據的傳輸格式，編碼和解碼規范等；
• 第三層：會話層。管理用戶的會話，控制用戶間邏輯連接的建立和中斷；
• 第四層：傳輸層。管理著網絡中的端到端的數據傳輸；
• 第五層：網絡層。定義網絡設備間如何傳輸數據；
• 第六層：鏈路層。將上面的網絡層的數據包封裝成數據幀，便于物理層傳輸；
• 第七層：物理層。這一層主要就是傳輸這些二進制數據。

實際應用過程中，五層協議結構里面是沒有表示層和會話層的。應該說它們和應用層合并了。我們應該將重點放在應用層和傳輸層這兩個層面。因為HTTP是應用層協議，而TCP是傳輸層協議。好，知道了網絡的分層模型以后我們可以更好地理解為什么RPC服務相比HTTP服務要Nice一些！

二、HTTP 服務：

其實在很久以前，我對于企業開發的模式一直定性為HTTP接口開發，也就是我們常說的RESTful風格的服務接口。的確，對于在接口不多、系統與系統交互較少的情況下，解決信息孤島初期常使用的一種通信手段；優點就是簡單、直接、開發方便。利用現成的http協議進行傳輸。我們記得之前實習在公司做后臺開發的時候，主要就是進行接口的開發，還要寫一大份接口文檔，嚴格地標明輸入輸出是什么？說清楚每一個接口的請求方法，以及請求參數需要注意的事項等。比如下面這個例子：

POST http://www.test.com/restful/user/info

接口可能返回一個JSON字符串或者是XML文檔。然后客戶端再去處理這個返回的信息，從而可以比較快速地進行開發。但是對于大型企業來說，內部子系統較多、接口非常多的情況下，RPC框架的好處就顯示出來了，首先就是長鏈接，不必每次通信都要像http一樣去3次握手什么的，減少了網絡開銷；其次就是RPC框架一般都有注冊中心，有豐富的監控管理；發布、下線接口、動態擴展等，對調用方來說是無感知、統一化的操作。

三、RPC 架構：

一個完整的RPC架構里面包含了四個核心的組件，分別是Client ,Server,Client Stub以及Server Stub，這個Stub大家可以理解為存根。分別說說這幾個組件：

• 客戶端（Client），服務的調用方。
• 服務端（Server），真正的服務提供者。
• 客戶端存根，存放服務端的地址消息，再將客戶端的請求參數打包成網絡消息，然后通過網絡遠程發送給服務方。
• 服務端存根，接收客戶端發送過來的消息，將消息解包，并調用本地的方法。

四、 什么時候需要PRC：

先來看一下，沒有RPC的時候，會怎么樣：

在過去是這樣的，包括現在很多對企業服務可能也是這樣，只有一個包部署在web服務器里。

那個時候，沒什么需要用到RPC的場景。

然后當用戶量大的時候呢？漸漸出現了負載均衡。大概是這個樣子：

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

以學校餐廳舉例：

學校餐廳，可以容納500人同時就餐，但是有一家面館，生意特別好，每到飯點來吃飯的人都有2000人，占滿了餐桌，排隊好幾百米，餐廳的其他攤位肯定不樂意了吧？

比如那個賣水餃的，雖然每天幾十個人來吃飯。那也是錢啊。你人這么多，想來我這吃飯的人都擠不進來了，

大概情景是這樣的：

這樣能看懂吧？

遇到這種場景怎么辦？不可能不讓面館開門營業啊，那最好的方式就是：

“你可不可以搬出去？”

你不搬我們搬也行！（哭泣臉，反正我們是再也不要和你家面館開在一起了，必須給我們一個說法）

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

嗯啊。分是分開了，然后餐卡什么的還是在一起，還是和其他窗口一樣，給大家提供就餐的功能。這就是分而治之，哪怕你面館關門了，也不影響我，這又叫分布式。（“分布式”劃重點）

說到分布式，就問題就來了。
可不可以互相調用？其實細分下去，買菜，切菜，結賬這些都是獨立的流程，我們能不能都把它們獨立出來？
當然是可以的，但是帶來的問題就是，如何通信？大家都不在一個進程里。
這種通信的方式，就叫做RPC，在今天，RPC已經不僅僅是遠程，這個遠程，確切來說，就是指不在一個進程內，只能通過其他協議來完成，通常都是TCP或者是Http。
好了，RPC講清楚了，再看RPC的重點是什么。
不能太慢，對不對？如果太慢了，怎么辦？
這種性能的要求，要做到什么程度？希望是和在同一個進程里，一致的體驗。
Http能做到這種程度么？
不行。Http（TCP）本身的三次握手協議，就會帶來大概1MS的延遲（emmm，這個數據其實我有點不確定了，也可能是幾微秒，很早之前做過測試）。
每發送一次請求，都會有一次建立連接的過程，加上Http報文本身的龐大，以及Json的龐大，都需要作一些優化。
一般的場景下，沒什么問題，但是對于google這種級別的公司，他們接受不了。
幾MS的延遲可能就導致多出來幾萬臺服務器，所以他們想盡辦法去優化，優化從哪方面入手？
1.減少傳輸量。
2.簡化協議。
3.用長連接，不再每一個請求都重新走三次握手流程
Http的協議就注定了，在高性能要求的下，不適合用做線上分布式服務之間互相使用的通信協議。

五、總結

RPC服務和HTTP服務還是存在很多的不同點的，一般來說，RPC服務主要是針對大型企業的，而HTTP服務主要是針對小企業的，因為RPC效率更高，而HTTP服務開發迭代會更快。總之，選用什么樣的框架不是按照市場上流行什么而決定的，而是要對整個項目進行完整地評估，從而在仔細比較兩種開發框架對于整個項目的影響，最后再決定什么才是最適合這個項目的。一定不要為了使用RPC而每個項目都用RPC，而是要因地制宜，具體情況具體分析。