Http、REST和RPC區別

轉載自:https://blog.csdn.net/mou_it/article/details/79873612

 

RPC(即Remote Procedure Call,遠程過程調用)和HTTP(HyperText Transfer Protocol,超文本傳輸協議)他們最本質的區別,就是RPC主要工作在TCP協議之上,而HTTP服務主要是工作在HTTP協議之上,我們都知道HTTP協議是在傳輸層協議TCP之上的,所以效率來看的話,RPC當然是要更勝一籌。

1、RPC服務

(1)RPC架構
      先說說RPC服務的基本架構吧。一個完整的RPC架構裏面包含了四個核心的組件,分別是Client ,Server,Client Stub以及Server Stub,這個Stub大家可以理解爲存根。分別說說這幾個組件:
    1)客戶端(Client),服務的調用方。
    2)服務端(Server),真正的服務提供者。
    3)客戶端存根,存放服務端的地址消息,再將客戶端的請求參數打包成網絡消息,然後通過網絡遠程發送給服務方。
    4)服務端存根,接收客戶端發送過來的消息,將消息解包,並調用本地的方法。

      RPC主要是用在大型企業裏面,因爲大型企業裏面系統繁多,業務線複雜,而且效率優勢非常重要的一塊,這個時候RPC的優勢就比較明顯了。實際的開發當中是這麼做的,項目一般使用maven來管理。比如我們有一個處理訂單的系統服務,先聲明它的所有的接口(這裏就是具體指Java中的interface),然後將整個項目打包爲一個jar包,服務端這邊引入這個二方庫,然後實現相應的功能,客戶端這邊也只需要引入這個二方庫即可調用了。爲什麼這麼做?主要是爲了減少客戶端這邊的jar包大小,因爲每一次打包發佈的時候,jar包太多總是會影響效率。另外也是將客戶端和服務端解耦,提高代碼的可移植性。

(2)同步調用與異步調用
      什麼是同步調用?什麼是異步調用?同步調用就是客戶端等待調用執行完成並返回結果。異步調用就是客戶端不等待調用執行完成返回結果,不過依然可以通過回調函數等接收到返回結果的通知。如果客戶端並不關心結果,則可以變成一個單向的調用。這個過程有點類似於Java中的callable和runnable接口,我們進行異步執行的時候,如果需要知道執行的結果,就可以使用callable接口,並且可以通過Future類獲取到異步執行的結果信息。如果不關心執行的結果,直接使用runnable接口就可以了,因爲它不返回結果,當然啦,callable也是可以的,我們不去獲取Future就可以了。

(3)流行的RPC框架

    目前流行的開源RPC框架還是比較多的。下面重點介紹三種:
    1)gRPC是Google最近公佈的開源軟件,基於最新的HTTP2.0協議,並支持常見的衆多編程語言。 我們知道HTTP2.0是基於二進制的HTTP協議升級版本,目前各大瀏覽器都在快馬加鞭的加以支持。 這個RPC框架是基於HTTP協議實現的,底層使用到了Netty框架的支持。
    2)Thrift是Facebook的一個開源項目,主要是一個跨語言的服務開發框架。它有一個代碼生成器來對它所定義的IDL定義文件自動生成服務代碼框架。用戶只要在其之前進行二次開發就行,對於底層的RPC通訊等都是透明的。不過這個對於用戶來說的話需要學習特定領域語言這個特性,還是有一定成本的。
    3)Dubbo是阿里集團開源的一個極爲出名的RPC框架,在很多互聯網公司和企業應用中廣泛使用。協議和序列化框架都可以插拔是及其鮮明的特色。同樣 的遠程接口是基於Java Interface,並且依託於spring框架方便開發。可以方便的打包成單一文件,獨立進程運行,和現在的微服務概念一致。

2、HTTP服務

(1)HTTP接口
      相比RPC,HTTP接口開發也就是我們常說的RESTful風格的服務接口。的確,對於在接口不多、系統與系統交互較少的情況下,解決信息孤島初期常使用的一種通信手段;優點就是簡單、直接、開發方便。利用現成的http協議進行傳輸。做後臺接口開發的時候,需要寫一份接口文檔,嚴格地標明輸入輸出是什麼?說清楚每一個接口的請求方法,以及請求參數需要注意的事項等。
      比如這個例子:POST http://www.httpexample.com/restful/buyer/info/share
      接口可能返回一個JSON字符串或者是XML文檔。然後客戶端再去處理這個返回的信息,從而可以比較快速地進行開發。但是對於大型企業來說,內部子系統較多、接口非常多的情況下,RPC框架的好處就顯示出來了,首先就是長鏈接,不必每次通信都要像http一樣去3次握手什麼的,減少了網絡開銷;其次就是RPC框架一般都有註冊中心,有豐富的監控管理;發佈、下線接口、動態擴展等,對調用方來說是無感知、統一化的操作。

(2)restful:
      對應的中文是rest式的;Restful web service是一種常見的rest的應用,是遵守了rest風格的web服務;rest式的web服務是一種ROA(The Resource-Oriented Architecture)(面向資源的架構)。爲什麼會出現Restful?
    1)在Restful之前的操作:
    http://127.0.0.1/user/query   GET  根據用戶id查詢用戶數據
    http://127.0.0.1/user/save    POST 新增用戶
    http://127.0.0.1/user/update POST 修改用戶信息
    http://127.0.0.1/user/delete  GET/POST 刪除用戶信息
    2)RESTful用法:
    http://127.0.0.1/user  GET  根據用戶id查詢用戶數據
    http://127.0.0.1/user  POST 新增用戶
    http://127.0.0.1/user  PUT 修改用戶信息
    http://127.0.0.1/user  DELETE 刪除用戶信息
    之前的操作是沒有問題的,大神認爲是有問題的,有什麼問題呢?你每次請求的接口或者地址,都在做描述,例如查詢的時候用了query,新增的時候用了save,其實完全沒有這個必要,我使用了get請求,就是查詢.使用post請求,就是新增的請求,我的意圖很明顯,完全沒有必要做描述,這就是爲什麼有了restful。

3、總結

    RPC服務和HTTP服務還是存在很多的不同點的,一般來說,RPC服務主要是針對大型企業的,而HTTP服務主要是針對小企業的,因爲RPC效率更高,而HTTP服務開發迭代會更快。總之,選用什麼樣的框架不是按照市場上流行什麼而決定的,而是要對整個項目進行完整地評估,從而在仔細比較兩種開發框架對於整個項目的影響,最後再決定什麼纔是最適合這個項目的。一定不要爲了使用RPC而每個項目都用RPC,而是要因地制宜,具體情況具體分析。


————————————————
版權聲明:本文爲CSDN博主「蓬萊道人」的原創文章,遵循CC 4.0 BY-SA版權協議,轉載請附上原文出處鏈接及本聲明。
原文鏈接:https://blog.csdn.net/mou_it/article/details/79873612

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章