HTTP與RPC（Thrift）

什么是RPC

從網絡協議來說，Http協議與Rpc同屬於應用層， 他們的底層都是tcp協議。

      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
原文：https://blog.csdn.net/mou_it/article/details/79873612
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！

 

 

 

image.png

從概念上來說，RPC是遠程過程調用，而其實Http其實也是屬於RPC調用的一種。RPC是一種網絡編程的模式，是我們程序員將對遠程服務器調用的抽象，而且一般需要實現服務注冊發現機制、序列化反序列化機制、方法派發機制，這些一般都需要我們使用的RPC框架（比如Thrift）默認實現的。

為什么要使用RPC

http協議其實是屬於面向桌面瀏覽器的一個通信協議，對於緩存，冪等或者Cookies相關的方面做了很多的事情。但是對於服務器之間直接的交互，Rpc就能夠體現出來他的優勢了。

• 自定義協議，減少數據傳輸：我們大概看一下http協議。請求行，請求頭部，請求數據，空行。很明顯對於遠程調用場景，我們對於請求行的依賴不是特別的強，那么這一部分在我們應用場景下，將會成為負擔，但是http協議又是固定的，我們也不可能隨便修改協議的格式。所以，通過rpc協議我們可以精簡請求的數據，來盡可能少的傳輸我們的數據。當前，rpc也可以通過http協議來進行傳輸。

 

image.png

• 使用長連接：直接基於socket進行連接，不用每個請求都重新走三次握手的流程

• Thrift默認提供了數據與實體類的轉換，不需要我們顯示的進行數據與實體類的轉換。

• 性能差距：https://cnodejs.org/topic/553a1cad63b7692e48bbb715。我們這里借用一下這篇文章的結論：
  

   

  

  圖片來源網絡，侵刪

   

OSI網絡結構的七層模型

各層的具體描述如下：

　　第七層：應用層     定義了用於在網絡中進行通信和數據傳輸的接口 - 用戶程式；提供標准服務，比如虛擬終端、文件以及任務的傳輸 和處理； 
　　第六層：表示層     掩蓋不同系統間的數據格式的不同性； 指定獨立結構的數據傳輸格式； 數據的編碼和解碼；加密和解密；壓縮和 解壓縮 
　　第五層：會話層     管理用戶會話和對話； 控制用戶間邏輯連接的建立和掛斷；報告上一層發生的錯誤 
　　第四層：傳輸層     管理網絡中端到端的信息傳送； 通過錯誤糾正和流控制機制提供可靠且有序的數據包傳送； 提供面向無連接的數 據包的傳送； 
　　第三層：網絡層     定義網絡設備間如何傳輸數據； 根據唯一的網絡設備地址路由數據包；提供流和擁塞控制以防止網絡資源的損耗 
　　第二層：數據鏈路層 定義操作通信連接的程序； 封裝數據包為數據幀； 監測和糾正數據包傳輸錯誤 
　　第一層：物理層      定義通過網絡設備發送數據的物理方式； 作為網絡媒介和設備間的接口；定義光學、電氣以及機械特性。

 在上述7層中，http協議是應用層協議。HTTP協議是超文本傳送協議(HyperText Transfer Protocol)的縮寫，它是萬維網(World Wide Web,www,也簡稱為Web)的基礎。HTTP協議設計之初就是為了實現Web的想法。HTTP協議位於TCP/IP協議棧的應用層。基於HTTP協議的客戶/服務器模式的信息交換過程，分四個過程：建立連接、發送請求信息、發送響應信息、關閉連接。

而關於RPC的基本概念介紹如下：

英文原義：Remote Procedure Call Protocol
中文釋義：（RFC-1831）遠過程調用協議
　　 注解：一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。RPC協議假定某些傳輸協議的存在，如TCP或UDP，為通信程序之間攜帶信息數據。在OSI網絡通信模型中，RPC跨越了傳輸層和應用層。RPC使得開發包括網絡分布式多程序在內的應用程序更加輕易。
　　 RPC采用客戶機/服務器模式。請求程序就是一個客戶機，而服務提供程序就是一個服務器。首先，調用進程發送一個有進程參數的調用信息到服務進程，然后等待應答信息。在服務器端，進程保持睡眠狀態直到調用信息的到達為止。當一個調用信息到達，服務器獲得進程參數，計算結果，發送答復信息，然后等待下一個調用信息，最后，客戶端調用過程接收答復信息，獲得進程結果，然后調用執行繼續進行。
RPC信息協議由兩個不同結構組成：調用信息和答復信息。

 

同時也注意到 了 這樣的信息

遠程通信的幾種選擇（RPC，Webservice，RMI，JMS的區別）

幾種基於HTTP協議的RPC性能比較

RPC和Socket的區別

http://blog.163.com/fanning_7213/blog/static/249650520113124540501/

RPC(Remote Procedure Call，遠程過程調用)是建立在Socket之上的,出於一種類比的願望,在一台機器上運行的主程序,可以調用另一台機器上准備好的子程序,就像LPC(本地過程調用).

    越底層，代碼越復雜、靈活性越高、效率越高；越上層，抽象封裝的越好、代碼越簡單、效率越差。Socket和RPC的區別再次說明了這點。

不論是程序員在編寫基於C/S(客戶端服務器)的程序時,還是網絡工程師在處理RPC問題時,他們問的最多的就是RPC和Socket有什么區別和聯系? 
　 　RPC(Remote Procedure Call，遠程過程調用)是建立在Socket之上的,出於一種類比的願望,在一台機器上運行的主程序,可以調用另一台機器上准備好的子程序,就像 LPC(本地過程調用).RPC帶來了開發C/S程序的簡單可靠的手段,它通過一種叫XDR的數據表達方法描述數據,程序員書寫偽代碼,然后由 rpcgen程序翻譯為真正的可編譯的C語言源代碼,再編譯成真正的Client端和Server端程序。 
　　RPC作為普遍的C/S開發方 法,開發效率高效,可靠.但RPC方法的基本原則是－－以模塊調用的簡單性忽略通訊的具體細節,以便程序員不用關心C/S之間的通訊協議,集中精力對付實 現過程.這就決定了 RPC生成的通訊包不可能對每種應用都有最恰當的處理辦法,與Socket方法相比,傳輸相同的有效數據,RPC占用更多的網絡帶寬. 
　　RPC是在Socket的基礎上實現的,它比socket需要更多的網絡和系統資源.另外,在對程序優化時,程序員雖然可以直接修改由rpcgen產生的令人費解的源程序,但對於追求程序設計高效率的RPC而言,獲得的簡單性則被大大削弱. 
RPC與是Socket的類比

 
參考：HTTP與RPC（Thrift）

參考：rpc與http的區別

參考：Http和RPC區別