直觀講解一下 RPC 呼叫和 HTTP 呼叫的區別!
很長時間以來都沒有怎麼好好搞清楚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架構裡面包含了四個核心的元件,分別是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協議進行傳輸。我們記得之前本科實習在公司做後臺開發的時候,主要就是進行介面的開發,還要寫一大份介面文件,嚴格地標明輸入輸出是什麼?說清楚每一個介面的請求方法,以及請求引數需要注意的事項等。
介面可能返回一個JSON字串或者是XML文件。然後客戶端再去處理這個返回的資訊,從而可以比較快速地進行開發。
但是對於大型企業來說,內部子系統較多、介面非常多的情況下,RPC框架的好處就顯示出來了,首先就是長連結,不必每次通訊都要像http一樣去3次握手什麼的,減少了網路開銷;
其次就是RPC框架一般都有註冊中心,有豐富的監控管理;釋出、下線介面、動態擴充套件等,對呼叫方來說是無感知、統一化的操作。
總結
RPC服務和HTTP服務還是存在很多的不同點的,一般來說,RPC服務主要是針對大型企業的,而HTTP服務主要是針對小企業的,因為RPC效率更高,而HTTP服務開發迭代會更快。
總之,選用什麼樣的框架不是按照市場上流行什麼而決定的,而是要對整個專案進行完整地評估,從而在仔細比較兩種開發框架對於整個專案的影響,最後再決定什麼才是最適合這個專案的。一定不要為了使用RPC而每個專案都用RPC,而是要因地制宜,具體情況具體分析。
以上就是本次分享的所有內容,想要了解更多 python 知識歡迎前往公眾號:Python 程式設計學習圈 ,傳送 “J” 即可免費獲取,每日干貨分享
- 位元組一面:Redis主節點宕機,如何處理?
- 如何使用 Redis 實現 “附近的人” 這個功能?
- 介紹一款能取代 Scrapy 的爬蟲框架 - feapder
- 直觀講解一下 RPC 呼叫和 HTTP 呼叫的區別!
- MySQL 億級資料分頁的優化
- Python 多執行緒小技巧:比 time.sleep 更好用的暫停寫法!
- Python面試官:請說說併發場景鎖怎麼用?
- Python如何非同步傳送日誌到遠端伺服器?
- Python 中的數字到底是什麼?
- 如何建立一個完美的 Python 專案?
- 詳解 Python 的二元算術運算,為什麼說減法只是語法糖?
- Python 為什麼沒有 main 函式?為什麼我不推薦寫 main 函式?
- Bug分析,假刪除導致文章釋出成功卻打不開的問題
- Python 進階:queue 佇列原始碼分析
- Python例項篇:自動操作Excel檔案(既簡單又特別實用)
- 誰說程式設計師不懂浪漫,當代碼遇到文學..
- Python 為什麼沒有 void 關鍵字?
- 程式語言中分號“;”的簡明歷史
- Python 什麼情況下會生成 pyc 檔案?
- 函式和方法的裝飾器