有了 HTTP,爲什麼還要 RPC?

作者:浮生憶夢 來源:tinyurl.com/y4o875zm

很長時間以來都沒有怎麼好好搞清楚 RPC(即 Remote Procedure Call,遠程過程調用)和 HTTP 調用的區別,不都是寫一個服務然後在客戶端調用麼?這裏請允許我迷之一笑~ Naive!

本文簡單地介紹一下兩種形式的 C/S 架構,先說一下他們最本質的區別,就是 RPC 主要是基於 TCP/IP 協議的,而 HTTP 服務主要是基於 HTTP 協議的。

我們都知道 HTTP 協議是在傳輸層協議 TCP 之上的,所以效率來看的話,RPC 當然是要更勝一籌啦!下面來具體說一說 RPC 服務和 HTTP 服務。

OSI 網絡七層模型

在說 RPC 和 HTTP 的區別之前,我覺的有必要了解一下 OSI 的七層網絡結構模型(雖然實際應用中基本上都是五層)。

它可以分爲以下幾層:(從上到下)

實際應用過程中,五層協議結構裏面是沒有表示層和會話層的。應該說它們和應用層合併了。

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

好,知道了網絡的分層模型以後我們可以更好地理解爲什麼 RPC 服務相比 HTTP 服務要 Nice 一些!

RPC 服務

從三個角度來介紹 RPC 服務,分別是:

RPC 架構

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

分別是:

分別說說這幾個組件:

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 框架一般都有註冊中心,有豐富的監控管理;發佈、下線接口、動態擴展等,對調用方來說是無感知、統一化的操作。

總結

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

總之,選用什麼樣的框架不是按照市場上流行什麼而決定的,而是要對整個項目進行完整地評估,從而在仔細比較兩種開發框架對於整個項目的影響,最後再決定什麼纔是最適合這個項目的。

一定不要爲了使用 RPC 而每個項目都用 RPC,而是要因地制宜,具體情況具體分析。

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/g3Jldfkp88FOf5W_tR93Qw