有了HTTP，為什麼還要RPC？

點選上方“Java基基”，選擇“設為星标”

做積極的人，而不是積極廢人！

源碼精品專欄

• 原創 | Java 2020 超神之路，很肝~
• 中文詳細注釋的開源項目
• RPC 架構 Dubbo 源碼解析
• 消息中間件 RocketMQ 源碼解析
• 資料庫中間件 Sharding-JDBC 和 MyCAT 源碼解析
• 作業排程中間件 Elastic-Job 源碼解析
• 分布式事務中間件 TCC-Transaction 源碼解析
• Eureka 和 Hystrix 源碼解析
• Java 并發源碼

article/details/81481454

• 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協定進行傳輸。我們記得之前大學實習在公司做背景開發的時候，主要就是進行接口的開發，還要寫一大份接口文檔，嚴格地标明輸入輸出是什麼？說清楚每一個接口的請求方法，以及請求參數需要注意的事項等。

  比如下面這個例子：POST http://www.httpexample.com/restful/buyer/info/shar

  接口可能傳回一個JSON字元串或者是XML文檔。然後用戶端再去處理這個傳回的資訊，進而可以比較快速地進行開發。

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

  其次就是RPC架構一般都有注冊中心，有豐富的監控管理；釋出、下線接口、動态擴充等，對調用方來說是無感覺、統一化的操作。

  總結

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

  總之，選用什麼樣的架構不是按照市場上流行什麼而決定的，而是要對整個項目進行完整地評估，進而在仔細比較兩種開發架構對于整個項目的影響，最後再決定什麼才是最适合這個項目的。一定不要為了使用RPC而每個項目都用RPC，而是要因地制宜，具體情況具體分析。

  歡迎加入我的知識星球，一起探讨架構，交流源碼。加入方式，長按下方二維碼噢：

  

  已在知識星球更新源碼解析如下：

  

  

  

  

  最近更新《芋道 SpringBoot 2.X 入門》系列，已經 20 餘篇，覆寫了 MyBatis、Redis、MongoDB、ES、分庫分表、讀寫分離、SpringMVC、Webflux、權限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能測試等等内容。

  提供近 3W 行代碼的 SpringBoot 示例，以及超 4W 行代碼的電商微服務項目。

  擷取方式：點“在看”，關注公衆号并回複 666 領取，更多内容陸續奉上。

  文章有幫助的話，在看，轉發吧。
  謝謝支援喲 (*^__^*）