很長時間以來都沒有怎么好好搞清楚RPC（即Remote Procedure Call，遠程程序呼叫）和HTTP呼叫的區別，不都是寫一個服務然后在客戶端呼叫么？這里請允許我迷之一笑~Naive！
本文簡單地介紹一下兩種形式的C/S架構，先說一下他們最本質的區別，就是RPC主要是基于TCP/IP協議的，而HTTP服務主要是基于HTTP協議的，我們都知道HTTP協議是在傳輸層協議TCP之上的，所以效率來看的話，RPC當然是要更勝一籌啦！下面來具體說一說RPC服務和HTTP服務，整理了一份Java面試寶典完整版PDF
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 www.httpexample.com/restful/buy…
介面可能回傳一個JSON字串或者是XML檔案，
然后客戶端再去處理這個回傳的資訊，從而可以比較快速地進行開發，
但是對于大型企業來說，內部子系統較多、介面非常多的情況下，RPC框架的好處就顯示出來了，
首先就是長鏈接，不必每次通信都要像http一樣去3次握手什么的，減少了網路開銷；
其次就是RPC框架一般都有注冊中心，有豐富的監控管理；發布、下線介面、動態擴展等，對呼叫方來說是無感知、統一化的操作，
總結
RPC服務和HTTP服務還是存在很多的不同點的，一般來說，RPC服務主要是針對大型企業的，而HTTP服務主要是針對小企業的，因為RPC效率更高，而HTTP服務開發迭代會更快，
總之，選用什么樣的框架不是按照市場上流行什么而決定的，而是要對整個專案進行完整地評估，從而在仔細比較兩種開發框架對于整個專案的影響，最后再決定什么才是最適合這個專案的，
一定不要為了使用RPC而每個專案都用RPC，而是要因地制宜，具體情況具體分析，整理了一份Java面試寶典完整版PDF
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/250031.html
標籤：Java
上一篇：JDBC基本操作
下一篇：史上最全Java8日期時間工具類