有了HTTP，為啥還要用RPC

既然有 HTTP 請求，為什么還要用 RPC 呼叫？

一直以來都沒有深究過RPC和HTTP的區別，不都是寫一個服務然后在客戶端呼叫么？

HTTP和RPC最本質的區別，就是 RPC 主要是基于 TCP/IP 協議的，而 HTTP 服務主要是基于 HTTP 協議的，

我們都知道 HTTP 協議是在傳輸層協議 TCP 之上的，所以效率來看的話，RPC 當然是要更勝一籌啦！

HTTP和RPC的相同點是，底層通訊都是基于socket，都可以實作遠程呼叫，都可以實作服務呼叫服務

HTTP 的本質

首先你要明確 HTTP 是一個協議，是一個超文本傳輸協議，

HTTP 它是協議，不是運輸通道，

它基于 TCP/IP 來傳輸文本、圖片、視頻、音頻等，

重點來了，

HTTP 不提供資料包的傳輸功能，也就是資料包從瀏覽器到服務端再來回的傳輸和它沒關系，

這是 TCP/IP 干的，

那 HTTP 有啥用？我們來分析一波，

我們上網要么就是獲取一些資訊來看，要么就是修改一些資訊，

比如你用瀏覽器刷微博就是獲取資訊，發微博就是修改資訊，

所以說瀏覽器需要告知服務器它需要什么，這次的請求是要獲取哪些資訊？發怎么樣的微博，

這就涉及到瀏覽器和服務器之間的通信互動，

而互動就需要一種格式，

像你我之間的談話就用中文，你要突然換成俄語我聽不懂那不就 GG 了，

所以說 HTTP 它規定了一種格式，一種通信格式，大家都用這個格式來交談，

這樣不論你是什么服務器、什么瀏覽器都能順利的交流，減少互動的成本，

就像全世界如果都講中文，那我們不就不需要學英文了，那不就較少互動的成本了，

不像現在我們還得學英文，不然就看不懂檔案等等，

萬一之后俄語又起來了，咱還得對接俄文，這互動成本是不是就上來了，

而網路世界還好，咱們現在的 Web 互動基本上就是 HTTP 了，

其實 HTTP 協議的格式很像我們信封，有個固定的格式，

本文已經收錄到Github倉庫，該倉庫包含計算機基礎、Java基礎、多執行緒、JVM、資料庫、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服務、設計模式、架構、校招社招分享等核心知識點，歡迎star~

Github地址

如果訪問不了Github，可以訪問gitee地址，

gitee地址

左上角寫郵編，右上角貼郵票，然后地址姓名啥的依次來，

因為計算機是很死板的，不像我們人一樣有一種立體掃描感，所以要規定先寫頭、再寫尾，

你要是先寫尾，再寫頭計算機就認不出來了，

所以 HTTP 就規定了請求先搞請求行、再搞請求報頭、再搞請求體，

回應就狀態行、回應報頭、回應體，

所以 HTTP 的本質是什么？

就是客戶端和服務端約定好的一種通信格式，

HTTP 和 RPC 的關系

HTTP 和 RPC 其實是兩個維度的東西， HTTP 指的是通信協議，

而 RPC 則是遠程呼叫，其對應的是本地呼叫，

RPC 的通信可以用 HTTP 協議，也可以自定義協議，是不做約束的，

像之前的單體時代，我們的 service 呼叫就是自己實作的方法，是本地行程內的呼叫，

public User getUserById(Long id) {
       return userDao.getUserById(id); // 這叫本地呼叫
    }

現在都是微服務了，根據業務模塊做了不同的拆分，像用戶的服務不用我這個小組負責，我這小組只要寫訂單服務就行了，

但是我們服務需要用到用戶的資訊，于是我們需要呼叫用戶小組的服務，于是代碼變成了以下這種

public User getUserById(Long id) {
       return userConsumer.getUserById(id); // 這是遠程呼叫，邏輯是用戶小組的服務實作的，
    }

可能還有些小伙伴不太清楚，再來看個圖，

把之前的用戶實作拆分出來弄了一個用戶服務，訂單相關的也拆成了訂單服務，都單獨部署，

這樣訂單相關的服務要獲取用戶的資訊就需要遠程呼叫了，

可以看到 RPC 就是通過網路進行遠程呼叫，訂單服務其實就是客戶端，而用戶服務是服務端，

這又涉及到互動了，所以也需要約定一個格式，至于要不要用 HTTP 這個格式，就是大家自己看著辦，

至此相信你對 HTTP 是啥也清楚了，

RPC 和 HTTP 的之間的關系也清楚了，

最全面的Java面試網站

那為什么要有 RPC？

可能你常聽到什么什么之間是 RPC 呼叫的，那你有沒有想過為什么要 RPC， 我們直接 WebClient HTTP 呼叫不行么？

其實 RPC 呼叫是因為服務的拆分，或者本身公司內部的多個服務之間的通信，

服務的拆分獨立部署，那服務間的呼叫就必然需要網路通信，用 WebClient 呼叫當然可行，但是比較麻煩，

我們想即使服務被拆分了但是使用起來還是和之前本地呼叫一樣方便，

所以就出現了 RPC 框架，來屏蔽這些底層呼叫細節，使得我們編碼上還是和之前本地呼叫相差不多，

并且 HTTP 協議比較的冗余，RPC 都是內部呼叫所以不需要太考慮通用性，只要公司內部保持格式統一即可，

所以可以做各種定制化的協議來使得通信更高效，

比如規定 yes 代表 yes的練級攻略，你看是不是更高效了，少傳輸的 5 個字，

就像特殊行動的暗號，高效簡潔！

所以公司內部服務的呼叫一般都用 RPC，而 HTTP 的優勢在于通用，大家都認可這個協議，

所以三方平臺提供的介面都是通過 HTTP 協議呼叫的，

所以現在知道為什么我們呼叫第三方都是 HTTP ，公司內部用 RPC 了吧？

上面這段話看起來仿佛 HTTP 和 RPC 是對等關系，不過相信大家看了之前的決議心里應該都有數了，

下面來具體說一說 RPC 服務和 HTTP 服務的區別，

OSI 網路七層模型

在說 RPC 和 HTTP 的區別之前，我覺的有必要了解一下 OSI 的七層網路結構模型（

它可以分為以下幾層：（從上到下）

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

實際應用程序中，五層協議結構里面是沒有表示層和會話層的，應該說它們和應用層合并了，

我們應該將重點放在應用層和傳輸層這兩個層面，因為 HTTP 是應用層協議，而 TCP 是傳輸層協議，

好，知道了網路的分層模型以后我們可以更好地理解為什么 RPC 服務相比 HTTP 服務要 Nice 一些！

RPC 服務

從三個角度來介紹 RPC 服務，分別是：

• RPC 架構
• 同步異步呼叫
• 流行的 RPC 框架

RPC 架構

先說說 RPC 服務的基本架構吧，我們可以很清楚地看到，一個完整的 RPC 架構里面包含了四個核心的組件，

分別是：

• Client
• Server
• Client Stub
• Server Stub（這個Stub大家可以理解為存根）

分別說說這幾個組件：

• 客戶端（Client），服務的呼叫方，
• 服務端（Server），真正的服務提供者，
• 客戶端存根，存放服務端的地址訊息，再將客戶端的請求引數打包成網路訊息，然后通過網路遠程發送給服務方，微信搜索公眾號：Linux技術迷，回復：linux 領取資料 ，
• 服務端存根，接收客戶端發送過來的訊息，將訊息解包，并呼叫本地的方法，

RPC 主要是用在大型企業里面，因為大型企業里面系統繁多，業務線復雜，而且效率優勢非常重要的一塊，這個時候 RPC 的優勢就比較明顯了，

比如我們有一個處理訂單的系統服務，先宣告它的所有的介面，然后將整個專案打包，服務端這邊引入，然后實作相應的功能，客戶端這邊也只需要引入就可以呼叫了，

為什么這么做？

主要是為了減少客戶端這邊的包大小，因為每一次打包發布的時候，包太多總是會影響效率，

另外也是將客戶端和服務端解耦，提高代碼的可移植性，

同步呼叫與異步呼叫

什么是同步呼叫？什么是異步呼叫？

同步呼叫就是客戶端等待呼叫執行完成并回傳結果，

異步呼叫就是客戶端不等待呼叫執行完成回傳結果，不過依然可以通過回呼函式等接收到回傳結果的通知，如果客戶端并不關心結果，則可以變成一個單向的呼叫，

流行的 RPC 框架

目前流行的開源 RPC 框架還是比較多的，下面重點介紹三種：

①gRPC 是 Google 最近公布的開源軟體，基于最新的 HTTP2.0 協議，并支持常見的眾多編程語言，

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

這個 RPC 框架是基于 HTTP 協議實作的，底層使用到了 Netty 框架的支持，

②Thrift 是 Facebook 的一個開源專案，主要是一個跨語言的服務開發框架，它有一個代碼生成器來對它所定義的 IDL 定義檔案自動生成服務代碼框架，

用戶只要在其之前進行二次開發就行，對于底層的 RPC 通訊等都是透明的，不過這個對于用戶來說的話需要學習特定領域語言這個特性，還是有一定成本的，

③Dubbo 是阿里集團開源的一個極為出名的 RPC 框架，在很多互聯網公司和企業應用中廣泛使用，協議和序列化框架都可以插拔是及其鮮明的特色，

HTTP 服務

通常，我們的開發模式一直定性為 HTTP 介面開發，也就是我們常說的 RESTful 風格的服務介面，

的確，對于在介面不多、系統與系統互動較少的情況下，解決資訊孤島初期常使用的一種通信手段；優點就是簡單、直接、開發方便，

利用現成的 HTTP 協議進行傳輸，

平時的作業主要就是進行介面的開發，還要寫一大份介面檔案，嚴格地標明輸入輸出是什么？說清楚每一個介面的請求方法，以及請求引數需要注意的事項等，

比如下面這個例子：

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

介面可能回傳一個 JSON 字串或者是 XML 檔案，然后客戶端再去處理這個回傳的資訊，從而可以比較快速地進行開發，

但是對于大型企業來說，內部子系統較多、介面非常多的情況下，RPC 框架的好處就顯示出來了，首先就是長鏈接，不必每次通信都要像 HTTP 一樣去 3 次握手什么的，減少了網路開銷，

其次就是 RPC 框架一般都有注冊中心，有豐富的監控管理；發布、下線介面、動態擴展等，對呼叫方來說是無感知、統一化的操作，

小結

RPC 服務和 HTTP 服務還是存在很多的不同點的，一般來說，RPC 服務主要是針對大型企業的，而 HTTP 服務主要是針對小企業的，因為 RPC 效率更高，而 HTTP 服務開發迭代會更快，

很多RPC框架包含了重試機制，路由策略，負載均衡策略，高可用策略，流量控制策略等等，如果應用行程之間只使用HTTP協議通信，顯然是無法完成上述功能的，

總之，選用什么樣的框架不是按照市場上流行什么而決定的，而是要對整個專案進行完整地評估，從而在仔細比較兩種開發框架對于整個專案的影響，最后再決定什么才是最適合這個專案的，

一定不要為了使用 RPC 而每個專案都用 RPC，而是要因地制宜，具體情況具體分析，

最后給大家分享一個Github倉庫，上面有大彬整理的300多本經典的計算機書籍PDF，包括C語言、C++、Java、Python、前端、資料庫、作業系統、計算機網路、資料結構和演算法、機器學習、編程人生等，可以star一下，下次找書直接在上面搜索，倉庫持續更新中~

Github地址

標籤：Java

上一篇：三方對接「心得」與「體會」

下一篇：java開發規范