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

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

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

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

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

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

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

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

 HTTP請求交互：

一次 HTTP 請求

• 客戶端：你準(zhǔn)備好我要發(fā)送了啊。
• 服務(wù)端：好吧你發(fā)送吧。
• 客戶端：你真的準(zhǔn)備好我真的要發(fā)送了啊。
• 客戶端：發(fā)送請求。
• 服務(wù)端：響應(yī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ù)端返回報文有 "Connection:keep-alive" 表示是一個長連接。
• HTTP 2.0 默認(rèn)打開長連接支持多路復(fù)用，即在一個連接中可發(fā)起多次請求和響應(yīng)。

RPC交互過程：

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

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

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

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

套路是這樣的。

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

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

2、對請求進(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、對請求進(jìn)行 Deserializer 反序列化，還原原始請求。

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

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

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

然后再依次 9.8.7.6.5.4.3.2.1 原路返回。

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

關(guān)于注冊中心

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

未完待續(xù)。。。

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

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