點擊上方 "程序員小樂"關注, 星標或置頂一起成長
每天凌晨00點00分, 第一時間與你相約
每日英文
Apologies do not always imply that you are wrong and the other side is right. Sometimes, it implies that you treasure the relationship of you two.
道歉並不總意味著你是錯的，對方是對的。有時它只是意味著相對自我而言，你更珍視你們之間的關係。
每日掏心話
我是一個反應遲鈍的人，事物總要在我身邊掠過很久以後，才會在我這裡發生振盪，回應，疼痛的感覺同樣如此，它緩慢，因之它也持久。
鏈接：toutiao.com/i6752793853293494798
程序員小樂(ID:study_tech)第 809 次推文 圖片來自百度
往日回顧：面試官問：瀏覽器輸入 URL 回車之後發生了什麼？
正文
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框架還是比較多的。下面重點介紹三種：1、gRPC是Google最近公佈的開源軟件，基於最新的HTTP2.0協議，並支持常見的眾多編程語言。我們知道HTTP2.0是基於二進制的HTTP協議升級版本，目前各大瀏覽器都在快馬加鞭的加以支持。這個RPC框架是基於HTTP協議實現的，底層使用到了Netty框架的支持。2、Thrift是Facebook的一個開源項目，主要是一個跨語言的服務開發框架。它有一個代碼生成器來對它所定義的IDL定義文件自動生成服務代碼框架。用戶只要在其之前進行二次開發就行，對於底層的RPC通訊等都是透明的。不過這個對於用戶來說的話需要學習特定領域語言這個特性，還是有一定成本的。3、Dubbo是阿里集團開源的一個極為出名的RPC框架，在很多互聯網公司和企業應用中廣泛使用。協議和序列化框架都可以插拔是及其鮮明的特色。同樣 的遠程接口是基於Java Interface，並且依託於spring框架方便開發。可以方便的打包成單一文件，獨立進程運行，和現在的微服務概念一致。HTTP服務其實在很久以前，我對於企業開發的模式一直定性為HTTP接口開發，也就是我們常說的RESTful風格的服務接口。的確，對於在接口不多、系統與系統交互較少的情況下，解決信息孤島初期常使用的一種通信手段；優點就是簡單、直接、開發方便。利用現成的http協議進行傳輸。我們記得之前本科實習在公司做後臺開發的時候，主要就是進行接口的開發，還要寫一大份接口文檔，嚴格地標明輸入輸出是什麼？說清楚每一個接口的請求方法，以及請求參數需要注意的事項等。比如下面這個例子：POST httpexample.com/restful/buyer/info/share接口可能返回一個JSON字符串或者是XML文檔。然後客戶端再去處理這個返回的信息，從而可以比較快速地進行開發。但是對於大型企業來說，內部子系統較多、接口非常多的情況下，RPC框架的好處就顯示出來了，首先就是長鏈接，不必每次通信都要像http一樣去3次握手什麼的，減少了網絡開銷；其次就是RPC框架一般都有註冊中心，有豐富的監控管理；發佈、下線接口、動態擴展等，對調用方來說是無感知、統一化的操作。
總之RPC服務和HTTP服務還是存在很多的不同點的，一般來說，RPC服務主要是針對大型企業的，而HTTP服務主要是針對小企業的，因為RPC效率更高，而HTTP服務開發迭代會更快。總之，選用什麼樣的框架不是按照市場上流行什麼而決定的，而是要對整個項目進行完整地評估，從而在仔細比較兩種開發框架對於整個項目的影響，最後再決定什麼才是最適合這個項目的。一定不要為了使用RPC而每個項目都用RPC，而是要因地制宜，具體情況具體分析。
歡迎在留言區留下你的觀點，一起討論提高。如果今天的文章讓你有新的啟發，學習能力的提升上有新的認識，歡迎轉發分享給更多人。
猜你還想看
阿里、騰訊、百度、華為、京東最新面試題彙集
SpringBoot2.x炫酷吊炸天前後端分離的後臺管理系統實例
再無包夜！網絡遊戲或實行宵禁，午夜之前關閉服務器，你贊同嗎？
面試官我：什麼是NIO？NIO的原理是什麼機制？我竟然沒回答上來...
關注訂閱號「程序員小樂」，收看更多精彩內容
嘿，你在看嗎？
閱讀更多 程序員小樂 的文章
