[[181522]]

今天分布式應(yīng)用、云計(jì)算、微服務(wù)大行其道，作為其技術(shù)基石之一的 RPC 你了解多少?一篇 RPC 的技術(shù)總結(jié)文章，數(shù)了下 5k+ 字，略長，可能也不適合休閑的碎片化時(shí)間閱讀，可以先收藏抽空再細(xì)讀 :)

全文目錄如下：

• 定義
• 起源
• 目標(biāo)
• 分類
• 結(jié)構(gòu)
• 模型
• 拆解
• 組件
• 實(shí)現(xiàn)
• 導(dǎo)出
• 導(dǎo)入
• 協(xié)議
• 編解碼
• 消息頭
• 消息體
• 傳輸
• 執(zhí)行
• 異常
• 總結(jié)
• 參考

兩年前寫過兩篇關(guān)于 RPC 的文章，如今回顧發(fā)現(xiàn)結(jié)構(gòu)和邏輯略顯凌亂，特作整理重新整合成一篇，想了解 RPC 原理的同學(xué)可以看看。

近幾年的項(xiàng)目中，服務(wù)化和微服務(wù)化漸漸成為中大型分布式系統(tǒng)架構(gòu)的主流方式，而 RPC 在其中扮演著關(guān)鍵的作用。 在平時(shí)的日常開發(fā)中我們都在隱式或顯式的使用 RPC，一些剛?cè)胄械某绦騿T會(huì)感覺 RPC 比較神秘，而一些有多年使用 RPC 經(jīng)驗(yàn)的程序員雖然使用經(jīng)驗(yàn)豐富，但有些對其原理也不甚了了。 缺乏對原理層面的理解，往往也會(huì)造成開發(fā)中的一些誤用。

定義

RPC 的全稱是 Remote Procedure Call 是一種進(jìn)程間通信方式。 它允許程序調(diào)用另一個(gè)地址空間(通常是共享網(wǎng)絡(luò)的另一臺(tái)機(jī)器上)的過程或函數(shù)，而不用程序員顯式編碼這個(gè)遠(yuǎn)程調(diào)用的細(xì)節(jié)。即程序員無論是調(diào)用本地的還是遠(yuǎn)程的函數(shù)，本質(zhì)上編寫的調(diào)用代碼基本相同。

起源

RPC 這個(gè)概念術(shù)語在上世紀(jì) 80 年代由 Bruce Jay Nelson(參考[1])提出。 這里我們追溯下當(dāng)初開發(fā) RPC 的原動(dòng)機(jī)是什么?在 Nelson 的論文 Implementing Remote Procedure Calls(參考[2]) 中他提到了幾點(diǎn)：

簡單：RPC 概念的語義十分清晰和簡單，這樣建立分布式計(jì)算就更容易。

高效：過程調(diào)用看起來十分簡單而且高效。

通用：在單機(jī)計(jì)算中「過程」往往是不同算法部分間最重要的通信機(jī)制。

通俗一點(diǎn)說，就是一般程序員對于本地的過程調(diào)用很熟悉，那么我們把 RPC 做成和本地調(diào)用完全類似，那么就更容易被接受，使用起來毫無障礙。 Nelson 的論文發(fā)表于 30 年前，其觀點(diǎn)今天看來確實(shí)高瞻遠(yuǎn)矚，今天我們使用的 RPC 框架基本就是按這個(gè)目標(biāo)來實(shí)現(xiàn)的。

目標(biāo)

RPC 的主要目標(biāo)是讓構(gòu)建分布式計(jì)算(應(yīng)用)更容易，在提供強(qiáng)大的遠(yuǎn)程調(diào)用能力時(shí)不損失本地調(diào)用的語義簡潔性。 為實(shí)現(xiàn)該目標(biāo)，RPC 框架需提供一種透明調(diào)用機(jī)制讓使用者不必顯式的區(qū)分本地調(diào)用和遠(yuǎn)程調(diào)用。

分類

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

• 同步調(diào)用：客戶端等待調(diào)用執(zhí)行完成并獲取到執(zhí)行結(jié)果。
• 異步調(diào)用：客戶端調(diào)用后不用等待執(zhí)行結(jié)果返回，但依然可以通過回調(diào)通知等方式獲取返回結(jié)果。若客戶端不關(guān)心調(diào)用返回結(jié)果，則變成單向異步調(diào)用，單向調(diào)用不用返回結(jié)果。

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

結(jié)構(gòu)

下面我們對 RPC 的結(jié)構(gòu)從理論模型到真實(shí)組件一步步抽絲剝繭。

模型

最早在 Nelson 的論文中指出實(shí)現(xiàn) RPC 的程序包括 5 個(gè)理論模型部分：

• User
• User-stub
• RPCRuntime
• Server-stub
• Server

這 5 個(gè)部分的關(guān)系如下圖所示：

這里 User 就是 Client 端。當(dāng) User 想發(fā)起一個(gè)遠(yuǎn)程調(diào)用時(shí)，它實(shí)際是通過本地調(diào)用 User-stub。 User-stub 負(fù)責(zé)將調(diào)用的接口、方法和參數(shù)通過約定的協(xié)議規(guī)范進(jìn)行編碼并通過本地的 RPCRuntime 實(shí)例傳輸?shù)竭h(yuǎn)端的實(shí)例。 遠(yuǎn)端 RPCRuntime 實(shí)例收到請求后交給 Server-stub 進(jìn)行解碼后發(fā)起向本地端 Server 的調(diào)用，調(diào)用結(jié)果再返回給 User 端。

拆解

上面給出了一個(gè)比較粗粒度的 RPC 實(shí)現(xiàn)理論模型概念結(jié)構(gòu)，這里我們進(jìn)一步細(xì)化它應(yīng)該由哪些組件構(gòu)成，如下圖所示。

RPC 服務(wù)端通過 RpcServer 去導(dǎo)出(export)遠(yuǎn)程接口方法，而客戶端通過 RpcClient 去導(dǎo)入(import)遠(yuǎn)程接口方法?？蛻舳讼裾{(diào)用本地方法一樣去調(diào)用遠(yuǎn)程接口方法，RPC 框架提供接口的代理實(shí)現(xiàn)，實(shí)際的調(diào)用將委托給代理 RpcProxy。代理封裝調(diào)用信息并將調(diào)用轉(zhuǎn)交給 RpcInvoker 去實(shí)際執(zhí)行。在客戶端的 RpcInvoker 通過連接器 RpcConnector 去維持與服務(wù)端的通道 RpcChannel，并使用 RpcProtocol 執(zhí)行協(xié)議編碼(encode)并將編碼后的請求消息通過通道發(fā)送給服務(wù)端。

RPC 服務(wù)端接收器 RpcAcceptor 接收客戶端的調(diào)用請求，同樣使用 RpcProtocol執(zhí)行協(xié)議解碼(decode)。

解碼后的調(diào)用信息傳遞給 RpcProcessor 去控制處理調(diào)用過程，***再委托調(diào)用給 RpcInvoker 去實(shí)際執(zhí)行并返回調(diào)用結(jié)果。

組件

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

1.RpcServer

負(fù)責(zé)導(dǎo)出(export)遠(yuǎn)程接口

2.RpcClient

負(fù)責(zé)導(dǎo)入(import)遠(yuǎn)程接口的代理實(shí)現(xiàn)

3.RpcProxy

遠(yuǎn)程接口的代理實(shí)現(xiàn)

4.RpcInvoker

客戶端：負(fù)責(zé)編碼調(diào)用信息和發(fā)送調(diào)用請求到服務(wù)端并等待調(diào)用結(jié)果返回

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

5.RpcProtocol

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

6.RpcConnector

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

7.RpcAcceptor

負(fù)責(zé)接收客戶端請求并返回請求結(jié)果

8.RpcProcessor`

負(fù)責(zé)在服務(wù)端控制調(diào)用過程，包括管理調(diào)用線程池、超時(shí)時(shí)間等

9.RpcChannel

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

實(shí)現(xiàn)

Nelson 論文中給出的這個(gè)概念模型也成為后來大家參考的標(biāo)準(zhǔn)范本。十多年前，我最早接觸分布式計(jì)算時(shí)使用的 CORBAR(參考[3])實(shí)現(xiàn)結(jié)構(gòu)基本與此基本類似。CORBAR 為了解決異構(gòu)平臺(tái)的 RPC，使用了 IDL(Interface Definition Language)來定義遠(yuǎn)程接口，并將其映射到特定的平臺(tái)語言中。

后來大部分的跨語言平臺(tái) RPC 基本都采用了此類方式，比如我們熟悉的 Web Service(SOAP)，近年開源的 Thrift 等。 他們大部分都通過 IDL 定義，并提供工具來映射生成不同語言平臺(tái)的 User-stub 和 Server-stub，并通過框架庫來提供 RPCRuntime 的支持。 不過貌似每個(gè)不同的 RPC 框架都定義了各自不同的 IDL 格式，導(dǎo)致程序員的學(xué)習(xí)成本進(jìn)一步上升。而 Web Service 嘗試建立業(yè)界標(biāo)準(zhǔn)，無賴標(biāo)準(zhǔn)規(guī)范復(fù)雜而效率偏低，否則 Thrift 等更高效的 RPC 框架就沒必要出現(xiàn)了。

IDL 是為了跨平臺(tái)語言實(shí)現(xiàn) RPC 不得已的選擇，要解決更廣泛的問題自然導(dǎo)致了更復(fù)雜的方案。 而對于同一平臺(tái)內(nèi)的 RPC 而言顯然沒必要搞個(gè)中間語言出來，例如 Java 原生的 RMI，這樣對于 Java 程序員而言顯得更直接簡單，降低使用的學(xué)習(xí)成本。

在上文進(jìn)一步拆解了組件并劃分了職責(zé)之后，下面就以在 Java 平臺(tái)實(shí)現(xiàn)該 RPC 框架概念模型為例，詳細(xì)分析下實(shí)現(xiàn)中需要考慮的因素。

導(dǎo)出

導(dǎo)出是指暴露遠(yuǎn)程接口的意思，只有導(dǎo)出的接口可以供遠(yuǎn)程調(diào)用，而未導(dǎo)出的接口則不能。 在 Java 中導(dǎo)出接口的代碼片段可能如下：

我們可以導(dǎo)出整個(gè)接口，也可以更細(xì)粒度一點(diǎn)只導(dǎo)出接口中的某些方法，如下：

Java 中還有一種比較特殊的調(diào)用就是多態(tài)，也就是一個(gè)接口可能有多個(gè)實(shí)現(xiàn)，那么遠(yuǎn)程調(diào)用時(shí)到底調(diào)用哪個(gè)?這個(gè)本地調(diào)用的語義是通過 JVM 提供的引用多態(tài)性隱式實(shí)現(xiàn)的，那么對于 RPC 來說跨進(jìn)程的調(diào)用就沒法隱式實(shí)現(xiàn)了。如果前面 DemoService 接口有 2 個(gè)實(shí)現(xiàn)，那么在導(dǎo)出接口時(shí)就需要特殊標(biāo)記不同的實(shí)現(xiàn)，如下：

上面 demo2 是另一個(gè)實(shí)現(xiàn)，我們標(biāo)記為 demo2 來導(dǎo)出，那么遠(yuǎn)程調(diào)用時(shí)也需要傳遞該標(biāo)記才能調(diào)用到正確的實(shí)現(xiàn)類，這樣就解決了多態(tài)調(diào)用的語義。

導(dǎo)入

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

代碼生成的方式對跨語言平臺(tái) RPC 框架而言是必然的選擇，而對于同一語言平臺(tái)的 RPC 則可以通過共享接口定義來實(shí)現(xiàn)。

在 Java 中導(dǎo)入接口的代碼片段可能如下：

在 Java 中 import 是關(guān)鍵字，所以代碼片段中我們用 refer 來表達(dá)導(dǎo)入接口的意思。 這里的導(dǎo)入方式本質(zhì)也是一種代碼生成技術(shù)，只不過是在運(yùn)行時(shí)生成，比靜態(tài)編譯期的代碼生成看起來更簡潔些。Java 里至少提供了兩種技術(shù)來提供動(dòng)態(tài)代碼生成，一種是 JDK 動(dòng)態(tài)代理，另外一種是字節(jié)碼生成。 動(dòng)態(tài)代理相比字節(jié)碼生成使用起來更方便，但動(dòng)態(tài)代理方式在性能上是要遜色于直接的字節(jié)碼生成的，而字節(jié)碼生成在代碼可讀性上要差很多。兩者權(quán)衡起來，作為一種底層通用框架，個(gè)人更傾向于選擇性能優(yōu)先。

協(xié)議

協(xié)議指 RPC 調(diào)用在網(wǎng)絡(luò)傳輸中約定的數(shù)據(jù)封裝方式，包括三個(gè)部分：編解碼、消息頭 和 消息體。

編解碼

客戶端代理在發(fā)起調(diào)用前需要對調(diào)用信息進(jìn)行編碼，這就要考慮需要編碼些什么信息并以什么格式傳輸?shù)椒?wù)端才能讓服務(wù)端完成調(diào)用。 出于效率考慮，編碼的信息越少越好(傳輸數(shù)據(jù)少)，編碼的規(guī)則越簡單越好(執(zhí)行效率高)。

我們先看下需要編碼些什么信息：

調(diào)用編碼

1.接口方法

包括接口名、方法名

2.方法參數(shù)

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

3.調(diào)用屬性

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

返回編碼

1.返回結(jié)果

接口方法中定義的返回值

2.返回碼

異常返回碼

3.返回異常信息

調(diào)用異常信息

消息頭

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

• magic

協(xié)議魔數(shù)，為解碼設(shè)計(jì)

• header size

協(xié)議頭長度，為擴(kuò)展設(shè)計(jì)

• version

協(xié)議版本，為兼容設(shè)計(jì)

• st

消息體序列化類型

• hb

心跳消息標(biāo)記，為長連接傳輸層心跳設(shè)計(jì)

• ow

單向消息標(biāo)記，

• rp

響應(yīng)消息標(biāo)記，不置位默認(rèn)是請求消息

• status code

響應(yīng)消息狀態(tài)碼

• reserved

為字節(jié)對齊保留

• message id

消息 id

• body size

消息體長度

消息體

消息體常采用序列化編碼，常見有以下序列化方式：

• xml

如 webservie SOAP

• json

如 JSON-RPC

• binary

如 thrift; hession; kryo 等

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

1. 效率：序列化和反序列化的效率，越快越好。
2. 長度：序列化后的字節(jié)長度，越小越好。
3. 兼容：序列化和反序列化的兼容性，接口參數(shù)對象若增加了字段，是否兼容。

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

傳輸

協(xié)議編碼之后，自然就是需要將編碼后的 RPC 請求消息傳輸?shù)椒?wù)端，服務(wù)方執(zhí)行后返回結(jié)果消息或確認(rèn)消息給客戶端。RPC 的應(yīng)用場景實(shí)質(zhì)是一種可靠的請求應(yīng)答消息流，這點(diǎn)和 HTTP 類似。因此選擇長連接方式的 TCP 協(xié)議會(huì)更高效，與 HTTP 不同的是在協(xié)議層面我們定義了每個(gè)消息的唯一 id，因此可以更容易的復(fù)用連接。

既然使用長連接，那么***個(gè)問題是到底客戶端和服務(wù)端之間需要多少根連接?實(shí)際上單連接和多連接在使用上沒有區(qū)別，對于數(shù)據(jù)傳輸量較小的應(yīng)用類型，單連接基本足夠。單連接和多連接***的區(qū)別在于，每根連接都有自己私有的發(fā)送和接收緩沖區(qū)，因此大數(shù)據(jù)量傳輸時(shí)分散在不同的連接緩沖區(qū)會(huì)得到更好的吞吐效率。

所以，如果你的數(shù)據(jù)傳輸量不足以讓單連接的緩沖區(qū)一直處于飽和狀態(tài)的話，那么使用多連接并不會(huì)產(chǎn)生任何明顯的提升，反而會(huì)增加連接管理的開銷。‘

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

執(zhí)行

客戶端 stub 所做的事情僅僅是編碼消息并傳輸給服務(wù)方，而真正調(diào)用過程發(fā)生在服務(wù)端。服務(wù)端 stub 從前文的結(jié)構(gòu)拆解中我們細(xì)分了 RpcProcessor 和 RpcInvoker 兩個(gè)組件，一個(gè)負(fù)責(zé)控制調(diào)用過程，一個(gè)負(fù)責(zé)真正調(diào)用。 這里我們還是以 Java 中實(shí)現(xiàn)這兩個(gè)組件為例來分析下它們到底需要做什么?

Java 中實(shí)現(xiàn)代碼的動(dòng)態(tài)接口調(diào)用目前一般通過反射調(diào)用。除了原生 JDK 自帶的反射，一些第三方庫也提供了性能更優(yōu)的反射調(diào)用，因此 RpcInvoker 就是封裝了反射調(diào)用的實(shí)現(xiàn)細(xì)節(jié)。

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

1.效率提升

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

2.資源隔離

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

3.超時(shí)控制

當(dāng)某個(gè)接口執(zhí)行緩慢，而客戶端已經(jīng)超時(shí)放棄等待后，服務(wù)端的線程繼續(xù)執(zhí)行此時(shí)顯得毫無意義。

異常

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

1. 本地調(diào)用一定會(huì)執(zhí)行，而遠(yuǎn)程調(diào)用則不一定，調(diào)用消息可能因?yàn)榫W(wǎng)絡(luò)原因并未發(fā)送到服務(wù)方。
2. 本地調(diào)用只會(huì)拋出接口聲明的異常，而遠(yuǎn)程調(diào)用還會(huì)跑出 RPC 框架運(yùn)行時(shí)的其他異常。
3. 本地調(diào)用和遠(yuǎn)程調(diào)用的性能可能差距很大，這取決于 RPC 固有消耗所占的比重。

正是這些區(qū)別決定了使用 RPC 時(shí)需要更多考量。 當(dāng)調(diào)用遠(yuǎn)程接口拋出異常時(shí)，異?？赡苁且粋€(gè)業(yè)務(wù)異常，也可能是 RPC 框架拋出的運(yùn)行時(shí)異常(如：網(wǎng)絡(luò)中斷等)。業(yè)務(wù)異常表明服務(wù)方已經(jīng)執(zhí)行了調(diào)用，可能因?yàn)槟承┰驅(qū)е挛茨苷?zhí)行，而 RPC 運(yùn)行時(shí)異常則有可能服務(wù)方根本沒有執(zhí)行，對調(diào)用方而言的異常處理策略自然需要區(qū)分。

由于 RPC 固有的消耗相對本地調(diào)用高出幾個(gè)數(shù)量級(jí)，本地調(diào)用的固有消耗是納秒級(jí)，而 RPC 的固有消耗是在毫秒級(jí)。那么對于過于輕量的計(jì)算任務(wù)就并不適合導(dǎo)出遠(yuǎn)程接口由獨(dú)立的進(jìn)程提供服務(wù)，只有花在計(jì)算任務(wù)上的時(shí)間遠(yuǎn)遠(yuǎn)高于 RPC 的固有消耗才值得導(dǎo)出為遠(yuǎn)程接口提供服務(wù)。

總結(jié)

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

看到這里的同學(xué)也許會(huì)想按這個(gè)概念模型和實(shí)現(xiàn)解析真得能開發(fā)實(shí)現(xiàn)一個(gè) RPC 框架庫么?這個(gè)問題我能肯定的回答，真得可以。因?yàn)槲揖桶催@個(gè)模型開發(fā)實(shí)現(xiàn)了一個(gè)最小化的 RPC 框架庫來學(xué)習(xí)驗(yàn)證，相關(guān)的代碼放在 Github 上，感興趣的同學(xué)可以自己去閱讀。這是我自己的一個(gè)實(shí)驗(yàn)性質(zhì)的學(xué)習(xí)驗(yàn)證用開源項(xiàng)目，地址是 https://github.com/mindwind/craft-atom，其中的 craft-atom-rpc 即是按這個(gè)模型實(shí)現(xiàn)的微型 RPC 框架庫，代碼量相對工業(yè)級(jí)使用的 RPC 框架庫少的多，方便閱讀學(xué)習(xí)。

***，讀到這里的肯定都是好學(xué)不倦的同學(xué)，謝謝大家的時(shí)間，讓我寫作的意義更多了一點(diǎn):)。

【本文是51CTO專欄作者胡峰的原創(chuàng)文章，轉(zhuǎn)載請聯(lián)系作者本人獲取授權(quán)】

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