RPC 的概念模型與實現解析

時間 2019-11-05

標籤 rpc 概念模型實現解析欄目微服務简体版

原文原文鏈接

今天分佈式應用、雲計算、微服務大行其道，做爲其技術基石之一的 RPC 你瞭解多少？一篇 RPC 的技術總結文章，數了下 5k+ 字，略長，可能也不適合休閒的碎片化時間閱讀，能夠先收藏抽空再細讀:)git

全文目錄以下：程序員

定義github
起源web
目標算法
分類json
結構微信
- 模型網絡
- 拆解架構
- 組件框架
實現
- 導出
- 導入
- 協議
  - 編解碼
  - 消息頭
  - 消息體
- 傳輸
- 執行
- 異常
總結
參考

兩年前寫過兩篇關於 RPC 的文章，現在回顧發現結構和邏輯略顯凌亂，特做整理從新整合成一篇，想了解 RPC 原理的同窗能夠看看。

近幾年的項目中，服務化和微服務化漸漸成爲中大型分佈式系統架構的主流方式，而 RPC 在其中扮演着關鍵的做用。在平時的平常開發中咱們都在隱式或顯式的使用 RPC，一些剛入行的程序員會感受 RPC 比較神祕，而一些有多年使用 RPC 經驗的程序員雖然使用經驗豐富，但有些對其原理也不甚了了。缺少對原理層面的理解，每每也會形成開發中的一些誤用。

定義

RPC 的全稱是 Remote Procedure Call 是一種進程間通訊方式。它容許程序調用另外一個地址空間（一般是共享網絡的另外一臺機器上）的過程或函數，而不用程序員顯式編碼這個遠程調用的細節。即程序員不管是調用本地的仍是遠程的函數，本質上編寫的調用代碼基本相同。

起源

RPC 這個概念術語在上世紀 80 年代由 Bruce Jay Nelson（參考[1]）提出。這裏咱們追溯下當初開發 RPC 的原動機是什麼？在 Nelson 的論文 _Implementing Remote Procedure Calls_（參考[2]）中他提到了幾點：

簡單：RPC 概念的語義十分清晰和簡單，這樣創建分佈式計算就更容易。
高效：過程調用看起來十分簡單並且高效。
通用：在單機計算中「過程」每每是不一樣算法部分間最重要的通訊機制。

通俗一點說，就是通常程序員對於本地的過程調用很熟悉，那麼咱們把 RPC 作成和本地調用徹底相似，那麼就更容易被接受，使用起來毫無障礙。 Nelson 的論文發表於 30 年前，其觀點今天看來確實高瞻遠矚，今天咱們使用的 RPC 框架基本就是按這個目標來實現的。

目標

RPC 的主要目標是讓構建分佈式計算（應用）更容易，在提供強大的遠程調用能力時不損失本地調用的語義簡潔性。 爲實現該目標，RPC 框架需提供一種透明調用機制讓使用者沒必要顯式的區分本地調用和遠程調用。

結構

下面咱們對 RPC 的結構從理論模型到真實組件一步步抽絲剝繭。

模型

最先在 Nelson 的論文中指出實現 RPC 的程序包括 5 個理論模型部分：

User
User-stub
RPCRuntime
Server-stub
Server

這 5 個部分的關係以下圖所示：

這裏 User 就是 Client 端。當 User 想發起一個遠程調用時，它實際是經過本地調用 User-stub。 User-stub 負責將調用的接口、方法和參數經過約定的協議規範進行編碼並經過本地的 RPCRuntime 實例傳輸到遠端的實例。遠端 RPCRuntime 實例收到請求後交給 Server-stub 進行解碼後發起向本地端 Server 的調用，調用結果再返回給 User 端。

拆解

上面給出了一個比較粗粒度的 RPC 實現理論模型概念結構，這裏咱們進一步細化它應該由哪些組件構成，以下圖所示。

RPC 服務端經過 RpcServer 去導出（export）遠程接口方法，而客戶端經過 RpcClient 去導入（import）遠程接口方法。客戶端像調用本地方法同樣去調用遠程接口方法，RPC 框架提供接口的代理實現，實際的調用將委託給代理 RpcProxy 。代理封裝調用信息並將調用轉交給 RpcInvoker 去實際執行。在客戶端的 RpcInvoker 經過鏈接器 RpcConnector 去維持與服務端的通道 RpcChannel，並使用 RpcProtocol 執行協議編碼（encode）並將編碼後的請求消息經過通道發送給服務端。

RPC 服務端接收器 RpcAcceptor 接收客戶端的調用請求，一樣使用 RpcProtocol 執行協議解碼（decode）。
解碼後的調用信息傳遞給 RpcProcessor 去控制處理調用過程，最後再委託調用給 RpcInvoker 去實際執行並返回調用結果。

組件

上面咱們進一步拆解了 RPC 實現結構的各個組件組成部分，下面咱們詳細說明下每一個組件的職責劃分。

RpcServer
負責導出（export）遠程接口
RpcClient
負責導入（import）遠程接口的代理實現
RpcProxy
遠程接口的代理實現
RpcInvoker
客戶端：負責編碼調用信息和發送調用請求到服務端並等待調用結果返回
服務端：負責調用服務端接口的具體實現並返回調用結果
RpcProtocol
負責協議編/解碼
RpcConnector
負責維持客戶端和服務端的鏈接通道和發送數據到服務端
RpcAcceptor
負責接收客戶端請求並返回請求結果
RpcProcessor
負責在服務端控制調用過程，包括管理調用線程池、超時時間等
RpcChannel
數據傳輸通道

實現

Nelson 論文中給出的這個概念模型也成爲後來你們參考的標準範本。十多年前，我最先接觸分佈式計算時使用的 CORBAR（參考[3]）實現結構基本與此基本相似。CORBAR 爲了解決異構平臺的 RPC，使用了 IDL（Interface Definition Language）來定義遠程接口，並將其映射到特定的平臺語言中。

後來大部分的跨語言平臺 RPC 基本都採用了此類方式，好比咱們熟悉的 Web Service（SOAP），近年開源的 Thrift 等。他們大部分都經過 IDL 定義，並提供工具來映射生成不一樣語言平臺的 User-stub 和 Server-stub，並經過框架庫來提供 RPCRuntime 的支持。不過貌似每一個不一樣的 RPC 框架都定義了各自不一樣的 IDL 格式，致使程序員的學習成本進一步上升。而 Web Service 嘗試創建業界標準，無賴標準規範複雜而效率偏低，不然 Thrift 等更高效的 RPC 框架就不必出現了。

IDL 是爲了跨平臺語言實現 RPC 不得已的選擇，要解決更普遍的問題天然致使了更復雜的方案。而對於同一平臺內的 RPC 而言顯然不必搞箇中間語言出來，例如 Java 原生的 RMI，這樣對於 Java 程序員而言顯得更直接簡單，下降使用的學習成本。

在上文進一步拆解了組件並劃分了職責以後，下面就以在 Java 平臺實現該 RPC 框架概念模型爲例，詳細分析下實現中須要考慮的因素。

導出

導出是指暴露遠程接口的意思，只有導出的接口能夠供遠程調用，而未導出的接口則不能。在 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 中還有一種比較特殊的調用就是多態，也就是一個接口可能有多個實現，那麼遠程調用時到底調用哪一個？這個本地調用的語義是經過 JVM 提供的引用多態性隱式實現的，那麼對於 RPC 來講跨進程的調用就無法隱式實現了。若是前面 DemoService 接口有 2 個實現，那麼在導出接口時就須要特殊標記不一樣的實現，以下：

DemoService demo   = new ...;
DemoService demo2  = new ...;
RpcServer   server = new ...;
server.export(DemoService.class, demo, options);
server.export("demo2", DemoService.class, demo2, options);

上面 demo2 是另外一個實現，咱們標記爲 demo2 來導出，
那麼遠程調用時也須要傳遞該標記才能調用到正確的實現類，這樣就解決了多態調用的語義。

導入

導入相對於導出而言，客戶端代碼爲了可以發起調用必需要得到遠程接口的方法或過程定義。目前，大部分跨語言平臺 RPC 框架採用根據 IDL 定義經過 code generator 去生成 User-stub 代碼，這種方式下實際導入的過程就是經過代碼生成器在編譯期完成的。我所使用過的一些跨語言平臺 RPC 框架如 CORBAR、WebService、ICE、Thrift 均是此類方式。

代碼生成的方式對跨語言平臺 RPC 框架而言是必然的選擇，而對於同一語言平臺的 RPC 則能夠經過共享接口定義來實現。
在 Java 中導入接口的代碼片斷可能以下：

RpcClient client = new ...;
DemoService demo = client.refer(DemoService.class);
demo.hi("how are you?");

在 Java 中 import 是關鍵字，因此代碼片斷中咱們用 refer 來表達導入接口的意思。這裏的導入方式本質也是一種代碼生成技術，只不過是在運行時生成，比靜態編譯期的代碼生成看起來更簡潔些。Java 裏至少提供了兩種技術來提供動態代碼生成，一種是 JDK 動態代理，另一種是字節碼生成。動態代理相比字節碼生成使用起來更方便，但動態代理方式在性能上是要遜色於直接的字節碼生成的，而字節碼生成在代碼可讀性上要差不少。二者權衡起來，做爲一種底層通用框架，我的更傾向於選擇性能優先。

協議

協議指 RPC 調用在網絡傳輸中約定的數據封裝方式，包括三個部分：編解碼、消息頭 和 消息體。

編解碼

客戶端代理在發起調用前須要對調用信息進行編碼，這就要考慮須要編碼些什麼信息並以什麼格式傳輸到服務端才能讓服務端完成調用。出於效率考慮，編碼的信息越少越好（傳輸數據少），編碼的規則越簡單越好（執行效率高）。

咱們先看下須要編碼些什麼信息：

調用編碼

接口方法
包括接口名、方法名
方法參數
包括參數類型、參數值
調用屬性
包括調用屬性信息，例如調用附加的隱式參數、調用超時時間等

返回編碼

返回結果
接口方法中定義的返回值
返回碼
異常返回碼
返回異常信息
調用異常信息

消息頭

除了以上這些必須的調用信息，咱們可能還須要一些元信息以方便程序編解碼以及將來可能的擴展。這樣咱們的編碼消息裏面就分紅了兩部分，一部分是元信息、另外一部分是調用的必要信息。若是設計一種 RPC 協議消息的話，元信息咱們把它放在協議消息頭中，而必要信息放在協議消息體中。下面給出一種概念上的 RPC 協議消息頭設計格式：

magic
協議魔數，爲解碼設計
header size
協議頭長度，爲擴展設計
version
協議版本，爲兼容設計
st
消息體序列化類型
hb
心跳消息標記，爲長鏈接傳輸層心跳設計
ow
單向消息標記，
rp
響應消息標記，不置位默認是請求消息
status code
響應消息狀態碼
reserved
爲字節對齊保留
message id
消息 id
body size
消息體長度

消息體

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

xml
如 webservie SOAP
json
如 JSON-RPC
binary
如 thrift; hession; kryo 等

格式肯定後編解碼就簡單了，因爲頭長度必定因此咱們比較關心的就是消息體的序列化方式。序列化咱們關心三個方面：

__效率__：序列化和反序列化的效率，越快越好。
__長度__：序列化後的字節長度，越小越好。
__兼容__：序列化和反序列化的兼容性，接口參數對象若增長了字段，是否兼容。

上面這三點有時是魚與熊掌不可兼得，這裏面涉及到具體的序列化庫實現細節，就不在本文進一步展開分析了。

傳輸

協議編碼以後，天然就是須要將編碼後的 RPC 請求消息傳輸到服務端，服務方執行後返回結果消息或確認消息給客戶端。RPC 的應用場景實質是一種可靠的請求應答消息流，這點和 HTTP 相似。所以選擇長鏈接方式的 TCP 協議會更高效，與 HTTP 不一樣的是在協議層面咱們定義了每一個消息的惟一 id，所以能夠更容易的複用鏈接。

既然使用長鏈接，那麼第一個問題是到底客戶端和服務端之間須要多少根鏈接？實際上單鏈接和多鏈接在使用上沒有區別，對於數據傳輸量較小的應用類型，單鏈接基本足夠。單鏈接和多鏈接最大的區別在於，每根鏈接都有本身私有的發送和接收緩衝區，所以大數據量傳輸時分散在不一樣的鏈接緩衝區會獲得更好的吞吐效率。

因此，若是你的數據傳輸量不足以讓單鏈接的緩衝區一直處於飽和狀態的話，那麼使用多鏈接並不會產生任何明顯的提高，反而會增長鏈接管理的開銷。

鏈接是由客戶端發起創建並維持的，若是客戶端和服務端之間是直連的，那麼鏈接通常不會中斷（固然物理鏈路故障除外）。若是客戶端和服務端鏈接通過一些負載中轉設備，有可能鏈接一段時間不活躍時會被這些中間設備中斷。爲了保持鏈接有必要定時爲每一個鏈接發送心跳數據以維持鏈接不中斷。心跳消息是 RPC 框架庫使用的內部消息，在前文協議頭結構中也有一個專門的心跳位，就是用來標記心跳消息的，它對業務應用透明。

執行

客戶端 stub 所作的事情僅僅是編碼消息並傳輸給服務方，而真正調用過程發生在服務端。服務端 stub 從前文的結構拆解中咱們細分了 RpcProcessor 和 RpcInvoker 兩個組件，一個負責控制調用過程，一個負責真正調用。這裏咱們仍是以 Java 中實現這兩個組件爲例來分析下它們到底須要作什麼？

Java 中實現代碼的動態接口調用目前通常經過反射調用。除了原生 JDK 自帶的反射，一些第三方庫也提供了性能更優的反射調用，所以 RpcInvoker 就是封裝了反射調用的實現細節。

調用過程的控制須要考慮哪些因素，RpcProcessor 須要提供什麼樣地調用控制服務呢？下面提出幾點以啓發思考：

效率提高
每一個請求應該儘快被執行，所以咱們不能每請求來再建立線程去執行，須要提供線程池服務。
資源隔離
當咱們導出多個遠程接口時，如何避免單一接口調用佔據全部線程資源，而引起其餘接口執行阻塞。
超時控制
當某個接口執行緩慢，而客戶端已經超時放棄等待後，服務端的線程繼續執行此時顯得毫無心義。

異常

不管 RPC 怎樣努力把遠程調用假裝的像本地調用，但它們依然有很大的不一樣點，並且有一些異常狀況是在本地調用時絕對不會碰到的。在說異常處理以前，咱們先比較下本地調用和 RPC 調用的一些差別：

本地調用必定會執行，而遠程調用則不必定，調用消息可能由於網絡緣由並未發送到服務方。
本地調用只會拋出接口聲明的異常，而遠程調用還會跑出 RPC 框架運行時的其餘異常。
本地調用和遠程調用的性能可能差距很大，這取決於 RPC 固有消耗所佔的比重。

正是這些區別決定了使用 RPC 時須要更多考量。當調用遠程接口拋出異常時，異常多是一個業務異常，也多是 RPC 框架拋出的運行時異常（如：網絡中斷等）。業務異常代表服務方已經執行了調用，可能由於某些緣由致使未能正常執行，而 RPC 運行時異常則有可能服務方根本沒有執行，對調用方而言的異常處理策略天然須要區分。

因爲 RPC 固有的消耗相對本地調用高出幾個數量級，本地調用的固有消耗是納秒級，而 RPC 的固有消耗是在毫秒級。那麼對於過於輕量的計算任務就並不適合導出遠程接口由獨立的進程提供服務，只有花在計算任務上的時間遠遠高於 RPC 的固有消耗才值得導出爲遠程接口提供服務。

總結

至此咱們提出了一個 RPC 實現的概念框架，並詳細分析了須要考慮的一些實現細節。不管 RPC 的概念是如何優雅，可是「草叢中依然有幾條蛇隱藏着」，只有深入理解了 RPC 的本質，才能更好地應用。

看到這裏的同窗也許會想按這個概念模型和實現解析真得能開發實現一個 RPC 框架庫麼？這個問題我能確定的回答，真得能夠。由於我就按這個模型開發實現了一個最小化的 RPC 框架庫來學習驗證，相關的代碼放在 Github 上，感興趣的同窗能夠本身去閱讀。這是我本身的一個實驗性質的學習驗證用開源項目，地址是 https://github.com/mindwind/craft-atom，其中的 craft-atom-rpc 便是按這個模型實現的微型 RPC 框架庫，代碼量相對工業級使用的 RPC 框架庫少的多，方便閱讀學習。

最後，讀到這裏的確定都是好學不倦的同窗，謝謝你們的時間，讓我寫做的意義更多了一點:)。