有了HTTP，為什么還要RPC？

RPC：Remote Procedure Call，遠程過程調用

一直以來都沒有深究過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 協議的格式很像我們信封，有個固定的格式。

 

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

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

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

所以 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 的之間的關系也清楚了。

那為什么要有 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），真正的服務提供者。

• 客戶端存根，存放服務端的地址消息，再將客戶端的請求參數打包成網絡消息，然后通過網絡遠程發送給服務方。

• 服務端存根，接收客戶端發送過來的消息，將消息解包，并調用本地的方法。

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，而是要因地制宜，具體情況具體分析。