來自：CSDN（作者：浮生憶夢）
原文鏈接：
blog.csdn.net/m0_38110132/article/details/81481454
很長時間以來都沒有怎么好好搞清楚RPC（即Remote Procedure Call宽菜，遠程過程調(diào)用）和HTTP調(diào)用的區(qū)別敞嗡，不都是寫一個服務然后在客戶端調(diào)用么丧枪？這里請允許我迷之一笑~Naive冗锁！本文簡單地介紹一下兩種形式的C/S架構潘悼，先說一下他們最本質(zhì)的區(qū)別洋丐，就是RPC主要是基于TCP/IP協(xié)議的，而HTTP服務主要是基于HTTP協(xié)議的挥等，我們都知道HTTP協(xié)議是在傳輸層協(xié)議TCP之上的友绝，所以效率來看的話，RPC當然是要更勝一籌啦肝劲！下面來具體說一說RPC服務和HTTP服務迁客。
OSI網(wǎng)絡七層模型
在說RPC和HTTP的區(qū)別之前郭宝，我覺的有必要了解一下OSI的七層網(wǎng)絡結構模型（雖然實際應用中基本上都是五層），它可以分為以下幾層：（從上到下）
- 第一層：應用層掷漱。定義了用于在網(wǎng)絡中進行通信和傳輸數(shù)據(jù)的接口粘室；
- 第二層：表示層。定義不同的系統(tǒng)中數(shù)據(jù)的傳輸格式卜范，編碼和解碼規(guī)范等衔统；
- 第三層：會話層。管理用戶的會話海雪，控制用戶間邏輯連接的建立和中斷锦爵；
- 第四層：傳輸層。管理著網(wǎng)絡中的端到端的數(shù)據(jù)傳輸奥裸；
- 第五層：網(wǎng)絡層险掀。定義網(wǎng)絡設備間如何傳輸數(shù)據(jù)；
- 第六層：鏈路層湾宙。將上面的網(wǎng)絡層的數(shù)據(jù)包封裝成數(shù)據(jù)幀樟氢，便于物理層傳輸；
- 第七層：物理層侠鳄。這一層主要就是傳輸這些二進制數(shù)據(jù)埠啃。
實際應用過程中，五層協(xié)議結構里面是沒有表示層和會話層的伟恶。應該說它們和應用層合并了霸妹。我們應該將重點放在應用層和傳輸層這兩個層面。因為HTTP是應用層協(xié)議知押，而TCP是傳輸層協(xié)議叹螟。好，知道了網(wǎng)絡的分層模型以后我們可以更好地理解為什么RPC服務相比HTTP服務要Nice一些台盯！
RPC服務
從三個角度來介紹RPC服務：分別是RPC架構罢绽，同步異步調(diào)用以及流行的RPC框架。
RPC架構
先說說RPC服務的基本架構吧静盅。允許我可恥地盜一幅圖哈~我們可以很清楚地看到良价，一個完整的RPC架構里面包含了四個核心的組件，分別是Client ,Server,Client Stub以及Server Stub蒿叠，這個Stub大家可以理解為存根明垢。分別說說這幾個組件：
- 客戶端（Client），服務的調(diào)用方市咽。
- 服務端（Server）痊银，真正的服務提供者。
客戶端存根施绎，存放服務端的地址消息溯革，再將客戶端的請求參數(shù)打包成網(wǎng)絡消息贞绳，然后通過網(wǎng)絡遠程發(fā)送給服務方。
服務端存根致稀，接收客戶端發(fā)送過來的消息冈闭，將消息解包，并調(diào)用本地的方法抖单。
RPC主要是用在大型企業(yè)里面萎攒，因為大型企業(yè)里面系統(tǒng)繁多，業(yè)務線復雜矛绘，而且效率優(yōu)勢非常重要的一塊耍休，這個時候RPC的優(yōu)勢就比較明顯了。實際的開發(fā)當中是這么做的蔑歌，項目一般使用maven來管理羹应。比如我們有一個處理訂單的系統(tǒng)服務揽碘，先聲明它的所有的接口（這里就是具體指Java中的interface）次屠，然后將整個項目打包為一個jar包，服務端這邊引入這個二方庫雳刺，然后實現(xiàn)相應的功能劫灶，客戶端這邊也只需要引入這個二方庫即可調(diào)用了。為什么這么做掖桦？主要是為了減少客戶端這邊的jar包大小本昏，因為每一次打包發(fā)布的時候，jar包太多總是會影響效率枪汪。另外也是將客戶端和服務端解耦涌穆，提高代碼的可移植性。
同步調(diào)用與異步調(diào)用
什么是同步調(diào)用雀久？什么是異步調(diào)用宿稀？同步調(diào)用就是客戶端等待調(diào)用執(zhí)行完成并返回結果。異步調(diào)用就是客戶端不等待調(diào)用執(zhí)行完成返回結果赖捌，不過依然可以通過回調(diào)函數(shù)等接收到返回結果的通知祝沸。如果客戶端并不關心結果，則可以變成一個單向的調(diào)用越庇。這個過程有點類似于Java中的callable和runnable接口罩锐，我們進行異步執(zhí)行的時候，如果需要知道執(zhí)行的結果卤唉，就可以使用callable接口涩惑，并且可以通過Future類獲取到異步執(zhí)行的結果信息。如果不關心執(zhí)行的結果桑驱，直接使用runnable接口就可以了境氢，因為它不返回結果蟀拷，當然啦，callable也是可以的萍聊，我們不去獲取Future就可以了问芬。
流行的RPC框架
目前流行的開源RPC框架還是比較多的。下面重點介紹三種：
- gRPC是Google最近公布的開源軟件寿桨，基于最新的HTTP2.0協(xié)議此衅，并支持常見的眾多編程語言。我們知道HTTP2.0是基于二進制的HTTP協(xié)議升級版本亭螟，目前各大瀏覽器都在快馬加鞭的加以支持挡鞍。這個RPC框架是基于HTTP協(xié)議實現(xiàn)的，底層使用到了Netty框架的支持预烙。
- Thrift是Facebook的一個開源項目墨微，主要是一個跨語言的服務開發(fā)框架。它有一個代碼生成器來對它所定義的IDL定義文件自動生成服務代碼框架扁掸。用戶只要在其之前進行二次開發(fā)就行翘县，對于底層的RPC通訊等都是透明的。不過這個對于用戶來說的話需要學習特定領域語言這個特性谴分，還是有一定成本的锈麸。
- Dubbo是阿里集團開源的一個極為出名的RPC框架，在很多互聯(lián)網(wǎng)公司和企業(yè)應用中廣泛使用牺蹄。協(xié)議和序列化框架都可以插拔是及其鮮明的特色忘伞。同樣 的遠程接口是基于Java Interface，并且依托于spring框架方便開發(fā)沙兰∶ツ危可以方便的打包成單一文件，獨立進程運行鼎天，和現(xiàn)在的微服務概念一致舀奶。
HTTP服務
其實在很久以前，我對于企業(yè)開發(fā)的模式一直定性為HTTP接口開發(fā)训措，也就是我們常說的RESTful風格的服務接口伪节。的確，對于在接口不多绩鸣、系統(tǒng)與系統(tǒng)交互較少的情況下怀大，解決信息孤島初期常使用的一種通信手段；優(yōu)點就是簡單呀闻、直接化借、開發(fā)方便。利用現(xiàn)成的http協(xié)議進行傳輸捡多。我們記得之前本科實習在公司做后臺開發(fā)的時候蓖康，主要就是進行接口的開發(fā)铐炫，還要寫一大份接口文檔，嚴格地標明輸入輸出是什么蒜焊？說清楚每一個接口的請求方法倒信，以及請求參數(shù)需要注意的事項等。
比如下面這個例子：
POST http://www.httpexample.com/restful/buyer/info/shar
接口可能返回一個JSON字符串或者是XML文檔泳梆。然后客戶端再去處理這個返回的信息鳖悠，從而可以比較快速地進行開發(fā)。但是對于大型企業(yè)來說优妙，內(nèi)部子系統(tǒng)較多乘综、接口非常多的情況下，RPC框架的好處就顯示出來了套硼，首先就是長鏈接卡辰，不必每次通信都要像http一樣去3次握手什么的，減少了網(wǎng)絡開銷邪意；其次就是RPC框架一般都有注冊中心九妈，有豐富的監(jiān)控管理；發(fā)布抄罕、下線接口允蚣、動態(tài)擴展等于颖，對調(diào)用方來說是無感知呆贿、統(tǒng)一化的操作。
總結
RPC服務和HTTP服務還是存在很多的不同點的森渐，一般來說做入，RPC服務主要是針對大型企業(yè)的，而HTTP服務主要是針對小企業(yè)的同衣，因為RPC效率更高竟块，而HTTP服務開發(fā)迭代會更快∧推耄總之浪秘，選用什么樣的框架不是按照市場上流行什么而決定的，而是要對整個項目進行完整地評估埠况，從而在仔細比較兩種開發(fā)框架對于整個項目的影響耸携，最后再決定什么才是最適合這個項目的。一定不要為了使用RPC而每個項目都用RPC辕翰，而是要因地制宜夺衍，具體情況具體分析。
