HTTP與RPC有哪些區別

這篇文章主要介紹“HTTP與RPC有哪些區別”，在日常操作中，相信很多人在HTTP與RPC有哪些區別問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”HTTP與RPC有哪些區別”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

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 的優勢就比較明顯了。實際的開發當中是這么做的，項目一般使用 Maven 來管理。

比如我們有一個處理訂單的系統服務，先聲明它的所有的接口（這里就是具體指 Java 中的 Interface），然后將整個項目打包為一個 jar 包，服務端這邊引入這個二方庫，然后實現相應的功能，客戶端這邊也只需要引入這個二方庫即可調用了。

為什么這么做？主要是為了減少客戶端這邊的 jar 包大小，因為每一次打包發布的時候，jar 包太多總是會影響效率。另外也是將客戶端和服務端解耦，提高代碼的可移植性。

同步調用與異步調用
什么是同步調用？什么是異步調用？同步調用就是客戶端等待調用執行完成并返回結果。

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

這個過程有點類似于 Java 中的 Callable 和 Runnable 接口，我們進行異步執行的時候，如果需要知道執行的結果，就可以使用 Callable 接口，并且可以通過 Future 類獲取到異步執行的結果信息。

如果不關心執行的結果，直接使用 Runnable 接口就可以了，因為它不返回結果，當然啦，Callable 也是可以的，我們不去獲取 Future 就可以了。

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

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

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

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

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

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

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

同樣的遠程接口是基于 Java Interface，并且依托于 Spring 框架方便開發。可以方便的打包成單一文件，獨立進程運行，和現在的微服務概念一致。

HTTP 服務

其實在很久以前，我對于企業開發的模式一直定性為 HTTP 接口開發，也就是我們常說的 RESTful 風格的服務接口。

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

利用現成的 HTTP 協議進行傳輸。我們記得之前本科實習在公司做后臺開發的時候，主要就是進行接口的開發，還要寫一大份接口文檔，嚴格地標明輸入輸出是什么？說清楚每一個接口的請求方法，以及請求參數需要注意的事項等。

比如下面這個例子：

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

接口可能返回一個 JSON 字符串或者是 XML 文檔。然后客戶端再去處理這個返回的信息，從而可以比較快速地進行開發。

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

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

到此，關于“HTTP與RPC有哪些區別”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！