話說上個(gè)系列好像朋友們都表示有點(diǎn)難理解，難道是數(shù)學(xué)公式太多了？大數(shù)據(jù)計(jì)數(shù)原理1+0=1這你都不會(huì)算(十) 。希望這次可以寫簡單點(diǎn)，像大蕉這樣的小小白都可以理解那種。上一篇文章我們講到一些關(guān)于企業(yè)系統(tǒng)間交互，順便開了一下坑。企業(yè)神奇中間件-RPC

拷一段過來先，回顧一下。

RPC（Remote Procedure Call），遠(yuǎn)程過程調(diào)用，從最簡單最抽象的模式來看，就是下面這個(gè)圖這樣?？蛻舳苏{(diào)用某個(gè)方法，然后中間經(jīng)過一系列的過程，調(diào)用到服務(wù)端的某個(gè)方法。服務(wù)端進(jìn)行處理之后，做出相應(yīng)，然后逐層原路返回到客戶端。

是不是很簡單，一般來說，開發(fā)者只需要關(guān)注藍(lán)色（ functions ）部分，而至于紅色部分（ stub句柄 ） 和黃色部分（socket 網(wǎng)絡(luò)）部分呢，框架層面會(huì)把它解決掉。藍(lán)色部分，服務(wù)端開發(fā)者要做的事情就是定義某個(gè)接口，客戶端開發(fā)者要做的事情就是調(diào)用某個(gè)接口，一切開發(fā)模式都跟本地調(diào)用無差別。

RPC 在企業(yè)內(nèi)部有三個(gè)非常非常重要的作用。

1、拋棄厚重的 HTTP 頭，減少網(wǎng)絡(luò)帶寬消耗。

2、默認(rèn)使用信任的 TCP 長連接，減少各種身份確認(rèn)以及網(wǎng)絡(luò)握手消耗。

3、面向開發(fā)者友好，開發(fā)者可以跟開發(fā)本地程序一樣調(diào)用別人的服務(wù)。

 HTTP請(qǐng)求交互：

一次 HTTP 請(qǐng)求

• 客戶端：你準(zhǔn)備好我要發(fā)送了啊。
• 服務(wù)端：好吧你發(fā)送吧。
• 客戶端：你真的準(zhǔn)備好我真的要發(fā)送了啊。
• 客戶端：發(fā)送請(qǐng)求。
• 服務(wù)端：響應(yīng)請(qǐng)求。
• 客戶端：你準(zhǔn)備好我要關(guān)閉了啊。
• 服務(wù)端：好吧你關(guān)閉吧。
• 服務(wù)端：我關(guān)閉連接了。
• 客戶端：好的我知道你關(guān)閉了。

ps:

• HTTP 1.0 默認(rèn)不打開長連接，客戶端想持有長連接要加上"Connection:keep-alive"的 header。
• HTTP  1.1 默認(rèn)打開長連接，服務(wù)端返回報(bào)文有 "Connection:keep-alive" 表示是一個(gè)長連接。
• HTTP 2.0 默認(rèn)打開長連接支持多路復(fù)用，即在一個(gè)連接中可發(fā)起多次請(qǐng)求和響應(yīng)。

RPC交互過程：

• 客戶端：你準(zhǔn)備好我要發(fā)送了啊。
• 服務(wù)端：好吧你發(fā)送吧。
• 客戶端：你真的準(zhǔn)備好我真的要發(fā)送了啊。
• 客戶端：發(fā)送請(qǐng)求。
• 服務(wù)端：響應(yīng)請(qǐng)求。
• 客戶端：發(fā)送請(qǐng)求。
• 服務(wù)端：響應(yīng)請(qǐng)求。
• 客戶端：發(fā)送請(qǐng)求。
• 服務(wù)端：響應(yīng)請(qǐng)求。

連接永遠(yuǎn)不會(huì)有連接關(guān)閉的一天，除非目標(biāo)機(jī)器掛了通道崩了之類的。

連接的打開和關(guān)閉是一個(gè)成本，雖然 HTTP 已經(jīng)支持了長連接，但是拋去這些不講，繁重的 HTTP 頭也是會(huì)把網(wǎng)絡(luò)搞崩。HTTP 全名 HyperText Transfer Protocol - 超文本傳輸協(xié)議，顧名思義，這個(gè)應(yīng)該是用來完成一些請(qǐng)求很少但是響應(yīng)文本比較多的協(xié)議，而對(duì)于高效率高并發(fā)的企業(yè)級(jí)應(yīng)用來說，還是需要使用一些私有化的協(xié)議來進(jìn)行系統(tǒng)間的交互，以減少一大堆在這個(gè)場景沒有用處的頭信息浪費(fèi)帶寬。

好目光繼續(xù)回到 RPC 本身，先來講講現(xiàn)在各種 RPC 框架的套路。根據(jù)我的觀察，現(xiàn)在各種 RPC 框架無論支持多少協(xié)議，無論是用什么語言實(shí)現(xiàn)的，一般都離不開下面這種套路。先明確一個(gè)觀念，在 RPC 中我們把調(diào)用方叫 Consumer 消費(fèi)者，服務(wù)端叫 Provider 生產(chǎn)者。

套路是這樣的。

關(guān)于 RPC 的調(diào)用路徑

1、Consumer 調(diào)用代理 Proxy，無論是主動(dòng)調(diào)用還是被動(dòng)調(diào)用，都是調(diào)用。

2、對(duì)請(qǐng)求進(jìn)行序列化 Serializer。

3、序列化完再轉(zhuǎn)成二進(jìn)制，交給 Socket 或者 其他網(wǎng)絡(luò) IO 層。

4、將二進(jìn)制寫入 Channal 通道中。

5、Channal 直接飛到 服務(wù)端。

6、服務(wù)端 Socket 讀取 Channal 獲得二進(jìn)制體。

7、對(duì)請(qǐng)求進(jìn)行 Deserializer 反序列化，還原原始請(qǐng)求。

8、然后將請(qǐng)求交給服務(wù)端的代理 Proxy。

9、代理調(diào)用到真正的 Provider 。

10、Provider 對(duì)請(qǐng)求做出相應(yīng)。

然后再依次 9.8.7.6.5.4.3.2.1 原路返回。

綜上所述，所以完整的是交互這樣的，藍(lán)色是請(qǐng)求，紅色是響應(yīng)。

關(guān)于注冊(cè)中心

當(dāng)然，類似 Dubbo 這類框架呢，還會(huì)提供一小部分服務(wù)治理的能力，比如搞一個(gè)注冊(cè)中心，Provider 在啟動(dòng)的時(shí)候向注冊(cè)中心暴露自己的ip和端口和各種服務(wù)的地址。然后 Consumer 在調(diào)用的時(shí)候，先問一下 Register 注冊(cè)中心有哪些機(jī)器是我能調(diào)用的，這個(gè)時(shí)候會(huì)有一層路由策略或者 HA 的策略。獲取到地址列表之后呢，Consumer 再根據(jù)自己路由策略進(jìn)行第二波路由。嗯，好像穩(wěn)了。謹(jǐn)記喔，即使沒有注冊(cè)中心，上邊這套機(jī)制也是可以正常工作的喔，只要能以各種方式發(fā)現(xiàn)目標(biāo)服務(wù)的存在。

未完待續(xù)。。。

【本文為51CTO專欄作者“大蕉”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過作者微信公眾號(hào)“一名叫大蕉的程序員”獲取授權(quán)】

戳這里，看該作者更多好文