RPC 功能目標

RPC 的主要功能目標是讓構(gòu)建分布式計算（應用）更容易雕沿，在提供強大的遠程調(diào)用能力時不損失本地調(diào)用的語義簡潔性虐急。為實現(xiàn)該目標赏参，RPC 框架需提供一種透明調(diào)用機制讓使用者不必顯式的區(qū)分本地調(diào)用和遠程調(diào)用,下面我們將具體細化 stub 結(jié)構(gòu)的實現(xiàn)元践。

RPC 調(diào)用分類

RPC 調(diào)用分以下兩種：

1. 同步調(diào)用

客戶方等待調(diào)用執(zhí)行完成并返回結(jié)果蚯窥。

2. 異步調(diào)用

客戶方調(diào)用后不用等待執(zhí)行結(jié)果返回狈谊，但依然可以通過回調(diào)通知等方式獲取返回結(jié)果喜命。

若客戶方不關心調(diào)用返回結(jié)果，則變成單向異步調(diào)用河劝，單向調(diào)用不用返回結(jié)果。

異步和同步的區(qū)分在于是否等待服務端執(zhí)行完成并返回結(jié)果矛紫。

如果想學習Java工程化赎瞎、高性能及分布式、深入淺出颊咬。微服務务甥、Spring，MyBatis喳篇，Netty源碼分析的朋友可以加我的Java高級交流：787707172敞临，群里有阿里大牛直播講解技術，以及Java大型互聯(lián)網(wǎng)技術的視頻免費分享給大家麸澜。

RPC 結(jié)構(gòu)拆解

《淺出篇》給出了一個比較粗粒度的 RPC 實現(xiàn)概念結(jié)構(gòu)挺尿，這里我們進一步細化它應該由哪些組件構(gòu)成，如下圖所示炊邦。

RPC 服務方通過 RpcServer 去導出（export）遠程接口方法编矾，而客戶方通過 RpcClient 去引入（import）遠程接口方法∧俸Γ客戶方像調(diào)用本地方法一樣去調(diào)用遠程接口方法窄俏，RPC 框架提供接口的代理實現(xiàn)，實際的調(diào)用將委托給代理RpcProxy 碘菜。代理封裝調(diào)用信息并將調(diào)用轉(zhuǎn)交給RpcInvoker 去實際執(zhí)行凹蜈。在客戶端的RpcInvoker 通過連接器RpcConnector 去維持與服務端的通道RpcChannel，并使用RpcProtocol 執(zhí)行協(xié)議編碼（encode）并將編碼后的請求消息通過通道發(fā)送給服務方忍啸。

RPC 服務端接收器 RpcAcceptor 接收客戶端的調(diào)用請求仰坦，同樣使用RpcProtocol 執(zhí)行協(xié)議解碼（decode）。解碼后的調(diào)用信息傳遞給RpcProcessor 去控制處理調(diào)用過程吊骤，最后再委托調(diào)用給RpcInvoker 去實際執(zhí)行并返回調(diào)用結(jié)果缎岗。

RPC 組件職責

上面我們進一步拆解了 RPC 實現(xiàn)結(jié)構(gòu)的各個組件組成部分，下面我們詳細說明下每個組件的職責劃分白粉。

1. RpcServer

負責導出（export）遠程接口

2. RpcClient

負責導入（import）遠程接口的代理實現(xiàn)

3. RpcProxy

遠程接口的代理實現(xiàn)

4. RpcInvoker

客戶方實現(xiàn)：負責編碼調(diào)用信息和發(fā)送調(diào)用請求到服務方并等待調(diào)用結(jié)果返回

服務方實現(xiàn)：負責調(diào)用服務端接口的具體實現(xiàn)并返回調(diào)用結(jié)果

5. RpcProtocol

負責協(xié)議編/解碼

6. RpcConnector

負責維持客戶方和服務方的連接通道和發(fā)送數(shù)據(jù)到服務方

7. RpcAcceptor

負責接收客戶方請求并返回請求結(jié)果

8. RpcProcessor

負責在服務方控制調(diào)用過程传泊，包括管理調(diào)用線程池、超時時間等

9. RpcChannel

數(shù)據(jù)傳輸通道

RPC 實現(xiàn)分析

在進一步拆解了組件并劃分了職責之后鸭巴，這里以在 java 平臺實現(xiàn)該 RPC 框架概念模型為例眷细，詳細分析下實現(xiàn)中需要考慮的因素。

導出遠程接口

導出遠程接口的意思是指只有導出的接口可以供遠程調(diào)用鹃祖，而未導出的接口則不能溪椎。在 java 中導出接口的代碼片段可能如下：

DemoService demo = new ...;

RpcServer server = new ...;

server.export(DemoService.class, demo, options);

我們可以導出整個接口，也可以更細粒度一點只導出接口中的某些方法，如：

// 只導出 DemoService 中簽名為 hi(String s) 的方法

server.export(DemoService.class, demo, "hi", new Class[] { String.class }, options);

java 中還有一種比較特殊的調(diào)用就是多態(tài)校读，也就是一個接口可能有多個實現(xiàn)沼侣，那么遠程調(diào)用時到底調(diào)用哪個？這個本地調(diào)用的語義是通過 jvm 提供的引用多態(tài)性隱式實現(xiàn)的歉秫，那么對于 RPC 來說跨進程的調(diào)用就沒法隱式實現(xiàn)了蛾洛。如果前面DemoService 接口有 2 個實現(xiàn)，那么在導出接口時就需要特殊標記不同的實現(xiàn)雁芙，如：

DemoService demo = new ...;

DemoService demo2 = new ...;

RpcServer server = new ...;

server.export(DemoService.class, demo, options);

server.export("demo2", DemoService.class, demo2, options);

上面 demo2 是另一個實現(xiàn)轧膘，我們標記為 "demo2" 來導出，那么遠程調(diào)用時也需要傳遞該標記才能調(diào)用到正確的實現(xiàn)類兔甘，這樣就解決了多態(tài)調(diào)用的語義谎碍。

導入遠程接口與客戶端代理

導入相對于導出遠程接口，客戶端代碼為了能夠發(fā)起調(diào)用必須要獲得遠程接口的方法或過程定義洞焙。目前蟆淀，大部分跨語言平臺 RPC 框架采用根據(jù) IDL 定義通過 code generator 去生成 stub 代碼，這種方式下實際導入的過程就是通過代碼生成器在編譯期完成的闽晦。我所使用過的一些跨語言平臺 RPC 框架如 CORBAR扳碍、WebService、ICE仙蛉、Thrift 均是此類方式笋敞。

代碼生成的方式對跨語言平臺 RPC 框架而言是必然的選擇，而對于同一語言平臺的 RPC 則可以通過共享接口定義來實現(xiàn)荠瘪。在 java 中導入接口的代碼片段可能如下：

RpcClient client = new ...;

DemoService demo = client.refer(DemoService.class);

demo.hi("how are you?");

在 java 中 'import' 是關鍵字夯巷，所以代碼片段中我們用 refer 來表達導入接口的意思。這里的導入方式本質(zhì)也是一種代碼生成技術哀墓，只不過是在運行時生成趁餐，比靜態(tài)編譯期的代碼生成看起來更簡潔些。java 里至少提供了兩種技術來提供動態(tài)代碼生成篮绰，一種是 jdk 動態(tài)代理后雷，另外一種是字節(jié)碼生成。動態(tài)代理相比字節(jié)碼生成使用起來更方便吠各，但動態(tài)代理方式在性能上是要遜色于直接的字節(jié)碼生成的臀突，而字節(jié)碼生成在代碼可讀性上要差很多。兩者權衡起來贾漏，個人認為犧牲一些性能來獲得代碼可讀性和可維護性顯得更重要候学。

協(xié)議編解碼

客戶端代理在發(fā)起調(diào)用前需要對調(diào)用信息進行編碼，這就要考慮需要編碼些什么信息并以什么格式傳輸?shù)椒斩瞬拍茏尫斩送瓿烧{(diào)用纵散。出于效率考慮梳码，編碼的信息越少越好（傳輸數(shù)據(jù)少）隐圾，編碼的規(guī)則越簡單越好（執(zhí)行效率高）。我們先看下需要編碼些什么信息：

-- 調(diào)用編碼 --

1. 接口方法

包括接口名掰茶、方法名

2. 方法參數(shù)

包括參數(shù)類型暇藏、參數(shù)值

3. 調(diào)用屬性

包括調(diào)用屬性信息，例如調(diào)用附件隱式參數(shù)濒蒋、調(diào)用超時時間等

-- 返回編碼 --

1. 返回結(jié)果

接口方法中定義的返回值

2. 返回碼

異常返回碼

3. 返回異常信息

調(diào)用異常信息

除了以上這些必須的調(diào)用信息叨咖，我們可能還需要一些元信息以方便程序編解碼以及未來可能的擴展。這樣我們的編碼消息里面就分成了兩部分啊胶，一部分是元信息、另一部分是調(diào)用的必要信息垛贤。如果設計一種 RPC 協(xié)議消息的話焰坪，元信息我們把它放在協(xié)議消息頭中，而必要信息放在協(xié)議消息體中聘惦。下面給出一種概念上的 RPC 協(xié)議消息設計格式：

-- 消息頭 --

magic : 協(xié)議魔數(shù)某饰，為解碼設計

header size: 協(xié)議頭長度，為擴展設計

version : 協(xié)議版本善绎，為兼容設計

st : 消息體序列化類型

hb : 心跳消息標記黔漂，為長連接傳輸層心跳設計

ow : 單向消息標記，

rp : 響應消息標記禀酱，不置位默認是請求消息

status code: 響應消息狀態(tài)碼

reserved : 為字節(jié)對齊保留

message id : 消息 id

body size : 消息體長度

-- 消息體 --

采用序列化編碼炬守，常見有以下格式

如果想學習Java工程化、高性能及分布式剂跟、深入淺出减途。微服務、Spring曹洽，MyBatis鳍置，Netty源碼分析的朋友可以加我的Java高級交流：787707172，群里有阿里大牛直播講解技術送淆，以及Java大型互聯(lián)網(wǎng)技術的視頻免費分享給大家税产。

xml : 如 webservie soap

json : 如 JSON-RPC

binary: 如 thrift; hession; kryo 等

格式確定后編解碼就簡單了，由于頭長度一定所以我們比較關心的就是消息體的序列化方式偷崩。序列化我們關心三個方面：

1. 序列化和反序列化的效率辟拷，越快越好。

2. 序列化后的字節(jié)長度环凿，越小越好梧兼。

3. 序列化和反序列化的兼容性，接口參數(shù)對象若增加了字段智听，是否兼容羽杰。

上面這三點有時是魚與熊掌不可兼得渡紫，這里面涉及到具體的序列化庫實現(xiàn)細節(jié)，就不在本文進一步展開分析了考赛。

傳輸服務

協(xié)議編碼之后惕澎，自然就是需要將編碼后的 RPC 請求消息傳輸?shù)椒辗剑辗綀?zhí)行后返回結(jié)果消息或確認消息給客戶方颜骤。RPC 的應用場景實質(zhì)是一種可靠的請求應答消息流唧喉，和 HTTP 類似。因此選擇長連接方式的 TCP 協(xié)議會更高效忍抽，與 HTTP 不同的是在協(xié)議層面我們定義了每個消息的唯一 id八孝，因此可以更容易的復用連接。

既然使用長連接鸠项，那么第一個問題是到底 client 和 server 之間需要多少根連接干跛？實際上單連接和多連接在使用上沒有區(qū)別，對于數(shù)據(jù)傳輸量較小的應用類型祟绊，單連接基本足夠楼入。單連接和多連接最大的區(qū)別在于，每根連接都有自己私有的發(fā)送和接收緩沖區(qū)牧抽，因此大數(shù)據(jù)量傳輸時分散在不同的連接緩沖區(qū)會得到更好的吞吐效率嘉熊。所以，如果你的數(shù)據(jù)傳輸量不足以讓單連接的緩沖區(qū)一直處于飽和狀態(tài)的話扬舒，那么使用多連接并不會產(chǎn)生任何明顯的提升阐肤，反而會增加連接管理的開銷。

連接是由 client 端發(fā)起建立并維持呼巴。如果 client 和 server 之間是直連的泽腮，那么連接一般不會中斷（當然物理鏈路故障除外）。如果 client 和 server 連接經(jīng)過一些負載中轉(zhuǎn)設備衣赶，有可能連接一段時間不活躍時會被這些中間設備中斷诊赊。為了保持連接有必要定時為每個連接發(fā)送心跳數(shù)據(jù)以維持連接不中斷。心跳消息是 RPC 框架庫使用的內(nèi)部消息府瞄，在前文協(xié)議頭結(jié)構(gòu)中也有一個專門的心跳位碧磅，就是用來標記心跳消息的，它對業(yè)務應用透明遵馆。

執(zhí)行調(diào)用

client stub 所做的事情僅僅是編碼消息并傳輸給服務方鲸郊，而真正調(diào)用過程發(fā)生在服務方。server stub 從前文的結(jié)構(gòu)拆解中我們細分了 RpcProcessor 和 RpcInvoker 兩個組件货邓，一個負責控制調(diào)用過程秆撮，一個負責真正調(diào)用。這里我們還是以 java 中實現(xiàn)這兩個組件為例來分析下它們到底需要做什么换况？

java 中實現(xiàn)代碼的動態(tài)接口調(diào)用目前一般通過反射調(diào)用职辨。除了原生的 jdk 自帶的反射盗蟆，一些第三方庫也提供了性能更優(yōu)的反射調(diào)用，因此 RpcInvoker 就是封裝了反射調(diào)用的實現(xiàn)細節(jié)舒裤。

調(diào)用過程的控制需要考慮哪些因素喳资，RpcProcessor 需要提供什么樣地調(diào)用控制服務呢？下面提出幾點以啟發(fā)思考：

1. 效率提升

每個請求應該盡快被執(zhí)行腾供，因此我們不能每請求來再創(chuàng)建線程去執(zhí)行仆邓，需要提供線程池服務。

2. 資源隔離

當我們導出多個遠程接口時伴鳖，如何避免單一接口調(diào)用占據(jù)所有線程資源节值，而引發(fā)其他接口執(zhí)行阻塞。

3. 超時控制

當某個接口執(zhí)行緩慢榜聂，而 client 端已經(jīng)超時放棄等待后察署，server 端的線程繼續(xù)執(zhí)行此時顯得毫無意義。

RPC 異常處理

無論 RPC 怎樣努力把遠程調(diào)用偽裝的像本地調(diào)用峻汉，但它們依然有很大的不同點，而且有一些異常情況是在本地調(diào)用時絕對不會碰到的脐往。在說異常處理之前休吠，我們先比較下本地調(diào)用和 RPC 調(diào)用的一些差異：

1. 本地調(diào)用一定會執(zhí)行，而遠程調(diào)用則不一定业簿，調(diào)用消息可能因為網(wǎng)絡原因并未發(fā)送到服務方瘤礁。

2. 本地調(diào)用只會拋出接口聲明的異常，而遠程調(diào)用還會跑出 RPC 框架運行時的其他異常梅尤。

3. 本地調(diào)用和遠程調(diào)用的性能可能差距很大柜思，這取決于 RPC 固有消耗所占的比重。

正是這些區(qū)別決定了使用 RPC 時需要更多考量巷燥。當調(diào)用遠程接口拋出異常時赡盘，異常可能是一個業(yè)務異常缰揪，也可能是 RPC 框架拋出的運行時異常（如：網(wǎng)絡中斷等）陨享。業(yè)務異常表明服務方已經(jīng)執(zhí)行了調(diào)用，可能因為某些原因?qū)е挛茨苷?zhí)行钝腺，而 RPC 運行時異常則有可能服務方根本沒有執(zhí)行抛姑，對調(diào)用方而言的異常處理策略自然需要區(qū)分。

由于 RPC 固有的消耗相對本地調(diào)用高出幾個數(shù)量級艳狐，本地調(diào)用的固有消耗是納秒級定硝，而 RPC 的固有消耗是在毫秒級。那么對于過于輕量的計算任務就并不合適導出遠程接口由獨立的進程提供服務毫目，只有花在計算任務上時間遠遠高于 RPC 的固有消耗才值得導出為遠程接口提供服務蔬啡。

總結(jié)

至此我們提出了一個 RPC 實現(xiàn)的概念框架诲侮，并詳細分析了需要考慮的一些實現(xiàn)細節(jié)。無論 RPC 的概念是如何優(yōu)雅星爪，但是“草叢中依然有幾條蛇隱藏著”浆西，只有深刻理解了 RPC 的本質(zhì)，才能更好地應用顽腾。

歡迎工作一到八年的Java工程師朋友們加入Java高級交流：787707172

本群提供免費的學習指導 架構(gòu)資料 以及免費的解答

不懂得問題都可以在本群提出來 之后還會有直播平臺和講師直接交流噢