轉自http://mp.weixin.qq.com/s?__biz=MzAxMTEyOTQ5OQ==&mid=2650610547&idx=1&sn=2cae08dbf62d9a6c2f964ffd440c0077&scene=21#wechat_redirect

今天分布式應用、云計算、微服務大行其道候址，作為其技術基石之一的 RPC 你了解多少阴挣？一篇 RPC 的技術總結文章随静，數了下 5k+ 字孵淘，略長，可能也不適合休閑的碎片化時間閱讀，可以先收藏抽空再細讀 :)

全文目錄如下：

定義

起源

目標

分類

結構

模型

拆解

組件

實現(xiàn)

導出

導入

協(xié)議

編解碼

消息頭

消息體

傳輸

執(zhí)行

異常

總結

參考

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

近幾年的項目中，服務化和微服務化漸漸成為中大型分布式系統(tǒng)架構的主流方式灌旧，而 RPC 在其中扮演著關鍵的作用绑咱。 在平時的日常開發(fā)中我們都在隱式或顯式的使用 RPC，一些剛入行的程序員會感覺 RPC 比較神秘枢泰，而一些有多年使用 RPC 經驗的程序員雖然使用經驗豐富羡玛，但有些對其原理也不甚了了。 缺乏對原理層面的理解宗苍，往往也會造成開發(fā)中的一些誤用稼稿。

定義

RPC 的全稱是 Remote Procedure Call 是一種進程間通信方式薄榛。 它允許程序調用另一個地址空間（通常是共享網絡的另一臺機器上）的過程或函數，而不用程序員顯式編碼這個遠程調用的細節(jié)让歼。即程序員無論是調用本地的還是遠程的函數敞恋，本質上編寫的調用代碼基本相同。

起源

RPC 這個概念術語在上世紀 80 年代由 Bruce Jay Nelson（參考[1]）提出谋右。 這里我們追溯下當初開發(fā) RPC 的原動機是什么硬猫？在 Nelson 的論文?Implementing Remote Procedure Calls（參考[2]） 中他提到了幾點：

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

高效：過程調用看起來十分簡單而且高效啸蜜。

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

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

目標

RPC 的主要目標是讓構建分布式計算（應用）更容易，在提供強大的遠程調用能力時不損失本地調用的語義簡潔性霉翔。?為實現(xiàn)該目標睁蕾，RPC 框架需提供一種透明調用機制讓使用者不必顯式的區(qū)分本地調用和遠程調用。

分類

RPC 調用分以下兩種：

同步調用：客戶端等待調用執(zhí)行完成并獲取到執(zhí)行結果债朵。

異步調用：客戶端調用后不用等待執(zhí)行結果返回子眶，但依然可以通過回調通知等方式獲取返回結果。若客戶端不關心調用返回結果葱弟，則變成單向異步調用，單向調用不用返回結果猜丹。

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

結構

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

模型

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

User

User-stub

RPCRuntime

Server-stub

Server

這 5 個部分的關系如下圖所示：

這里 User 就是 Client 端射窒。當 User 想發(fā)起一個遠程調用時藏杖，它實際是通過本地調用 User-stub。 User-stub 負責將調用的接口脉顿、方法和參數通過約定的協(xié)議規(guī)范進行編碼并通過本地的 RPCRuntime 實例傳輸到遠端的實例蝌麸。 遠端 RPCRuntime 實例收到請求后交給 Server-stub 進行解碼后發(fā)起向本地端 Server 的調用，調用結果再返回給 User 端艾疟。

拆解

上面給出了一個比較粗粒度的 RPC 實現(xiàn)理論模型概念結構来吩，這里我們進一步細化它應該由哪些組件構成敢辩，如下圖所示。

RPC 服務端通過RpcServer去導出（export）遠程接口方法弟疆，而客戶端通過RpcClient去導入（import）遠程接口方法戚长。客戶端像調用本地方法一樣去調用遠程接口方法怠苔，RPC 框架提供接口的代理實現(xiàn)同廉，實際的調用將委托給代理RpcProxy。代理封裝調用信息并將調用轉交給RpcInvoker去實際執(zhí)行柑司。在客戶端的?RpcInvoker?通過連接器RpcConnector去維持與服務端的通道RpcChannel迫肖，并使用RpcProtocol執(zhí)行協(xié)議編碼（encode）并將編碼后的請求消息通過通道發(fā)送給服務端。

RPC 服務端接收器RpcAcceptor接收客戶端的調用請求攒驰，同樣使用RpcProtocol執(zhí)行協(xié)議解碼（decode）蟆湖。

解碼后的調用信息傳遞給RpcProcessor去控制處理調用過程，最后再委托調用給RpcInvoker去實際執(zhí)行并返回調用結果讼育。

組件

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

RpcServer

負責導出（export）遠程接口

RpcClient

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

RpcProxy

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

RpcInvoker

客戶端：負責編碼調用信息和發(fā)送調用請求到服務端并等待調用結果返回

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

RpcProtocol

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

RpcConnector

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

RpcAcceptor

負責接收客戶端請求并返回請求結果

RpcProcessor`

負責在服務端控制調用過程奶段，包括管理調用線程池饥瓷、超時時間等

RpcChannel

數據傳輸通道

實現(xiàn)

Nelson 論文中給出的這個概念模型也成為后來大家參考的標準范本。十多年前痹籍，我最早接觸分布式計算時使用的 CORBAR（參考[3]）實現(xiàn)結構基本與此基本類似呢铆。CORBAR 為了解決異構平臺的 RPC，使用了 IDL（Interface Definition Language）來定義遠程接口蹲缠，并將其映射到特定的平臺語言中棺克。

后來大部分的跨語言平臺 RPC 基本都采用了此類方式，比如我們熟悉的 Web Service（SOAP）线定，近年開源的 Thrift 等娜谊。 他們大部分都通過 IDL 定義，并提供工具來映射生成不同語言平臺的 User-stub 和 Server-stub斤讥，并通過框架庫來提供 RPCRuntime 的支持纱皆。 不過貌似每個不同的 RPC 框架都定義了各自不同的 IDL 格式，導致程序員的學習成本進一步上升芭商。而 Web Service 嘗試建立業(yè)界標準派草，無賴標準規(guī)范復雜而效率偏低，否則 Thrift 等更高效的 RPC 框架就沒必要出現(xiàn)了铛楣。

IDL 是為了跨平臺語言實現(xiàn) RPC 不得已的選擇近迁，要解決更廣泛的問題自然導致了更復雜的方案。 而對于同一平臺內的 RPC 而言顯然沒必要搞個中間語言出來簸州，例如 Java 原生的 RMI鉴竭，這樣對于 Java 程序員而言顯得更直接簡單歧譬，降低使用的學習成本。

在上文進一步拆解了組件并劃分了職責之后拓瞪，下面就以在 Java 平臺實現(xiàn)該 RPC 框架概念模型為例缴罗，詳細分析下實現(xiàn)中需要考慮的因素。

導出

導出是指暴露遠程接口的意思祭埂，只有導出的接口可以供遠程調用面氓，而未導出的接口則不能。 在 Java 中導出接口的代碼片段可能如下：

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

Java 中還有一種比較特殊的調用就是多態(tài)，也就是一個接口可能有多個實現(xiàn)泰演，那么遠程調用時到底調用哪個呻拌？這個本地調用的語義是通過 JVM 提供的引用多態(tài)性隱式實現(xiàn)的，那么對于 RPC 來說跨進程的調用就沒法隱式實現(xiàn)了睦焕。如果前面 DemoService 接口有 2 個實現(xiàn)藐握，那么在導出接口時就需要特殊標記不同的實現(xiàn)，如下：

上面 demo2 是另一個實現(xiàn)垃喊，我們標記為 demo2 來導出猾普，那么遠程調用時也需要傳遞該標記才能調用到正確的實現(xiàn)類，這樣就解決了多態(tài)調用的語義本谜。

導入

導入相對于導出而言初家，客戶端代碼為了能夠發(fā)起調用必須要獲得遠程接口的方法或過程定義。目前乌助，大部分跨語言平臺 RPC 框架采用根據 IDL 定義通過 code generator 去生成 User-stub 代碼溜在，這種方式下實際導入的過程就是通過代碼生成器在編譯期完成的。我所使用過的一些跨語言平臺 RPC 框架如 CORBAR他托、WebService掖肋、ICE、Thrift 均是此類方式赏参。

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

在 Java 中導入接口的代碼片段可能如下：

在 Java 中?import?是關鍵字登刺，所以代碼片段中我們用 refer 來表達導入接口的意思籽腕。 這里的導入方式本質也是一種代碼生成技術嗡呼，只不過是在運行時生成纸俭，比靜態(tài)編譯期的代碼生成看起來更簡潔些。Java 里至少提供了兩種技術來提供動態(tài)代碼生成南窗，一種是 JDK 動態(tài)代理揍很，另外一種是字節(jié)碼生成郎楼。 動態(tài)代理相比字節(jié)碼生成使用起來更方便，但動態(tài)代理方式在性能上是要遜色于直接的字節(jié)碼生成的窒悔，而字節(jié)碼生成在代碼可讀性上要差很多呜袁。兩者權衡起來，作為一種底層通用框架简珠，個人更傾向于選擇性能優(yōu)先阶界。

協(xié)議

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

編解碼

客戶端代理在發(fā)起調用前需要對調用信息進行編碼，這就要考慮需要編碼些什么信息并以什么格式傳輸到服務端才能讓服務端完成調用祭玉。 出于效率考慮氧映，編碼的信息越少越好（傳輸數據少），編碼的規(guī)則越簡單越好（執(zhí)行效率高）脱货。

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

調用編碼

接口方法

包括接口名岛都、方法名

方法參數

包括參數類型、參數值

調用屬性

包括調用屬性信息振峻，例如調用附加的隱式參數臼疫、調用超時時間等

返回編碼

返回結果

接口方法中定義的返回值

返回碼

異常返回碼

返回異常信息

調用異常信息

消息頭

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

magic

協(xié)議魔數湾盗，為解碼設計

header size

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

version

協(xié)議版本立轧，為兼容設計

st

消息體序列化類型

hb

心跳消息標記格粪，為長連接傳輸層心跳設計

ow

單向消息標記，

rp

響應消息標記氛改，不置位默認是請求消息

status code

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

reserved

為字節(jié)對齊保留

message id

消息 id

body size

消息體長度

消息體

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

xml

如 webservie SOAP

json

如 JSON-RPC

binary

如 thrift; hession; kryo 等

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

效率：序列化和反序列化的效率疆导，越快越好。

長度：序列化后的字節(jié)長度葛躏，越小越好澈段。

兼容：序列化和反序列化的兼容性悠菜，接口參數對象若增加了字段，是否兼容败富。

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

傳輸

協(xié)議編碼之后芬骄，自然就是需要將編碼后的 RPC 請求消息傳輸到服務端，服務方執(zhí)行后返回結果消息或確認消息給客戶端鹦聪。RPC 的應用場景實質是一種可靠的請求應答消息流德玫，這點和 HTTP 類似。因此選擇長連接方式的 TCP 協(xié)議會更高效椎麦，與 HTTP 不同的是在協(xié)議層面我們定義了每個消息的唯一 id宰僧，因此可以更容易的復用連接。

既然使用長連接观挎，那么第一個問題是到底客戶端和服務端之間需要多少根連接琴儿？實際上單連接和多連接在使用上沒有區(qū)別，對于數據傳輸量較小的應用類型嘁捷，單連接基本足夠造成。單連接和多連接最大的區(qū)別在于，每根連接都有自己私有的發(fā)送和接收緩沖區(qū)雄嚣，因此大數據量傳輸時分散在不同的連接緩沖區(qū)會得到更好的吞吐效率晒屎。

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

連接是由客戶端發(fā)起建立并維持的骇吭，如果客戶端和服務端之間是直連的，那么連接一般不會中斷（當然物理鏈路故障除外）歧寺。如果客戶端和服務端連接經過一些負載中轉設備燥狰，有可能連接一段時間不活躍時會被這些中間設備中斷。為了保持連接有必要定時為每個連接發(fā)送心跳數據以維持連接不中斷斜筐。心跳消息是 RPC 框架庫使用的內部消息龙致，在前文協(xié)議頭結構中也有一個專門的心跳位，就是用來標記心跳消息的顷链，它對業(yè)務應用透明目代。

執(zhí)行

客戶端 stub 所做的事情僅僅是編碼消息并傳輸給服務方，而真正調用過程發(fā)生在服務端。服務端 stub 從前文的結構拆解中我們細分了?RpcProcessor?和?RpcInvoker?兩個組件像啼，一個負責控制調用過程，一個負責真正調用潭苞。 這里我們還是以 Java 中實現(xiàn)這兩個組件為例來分析下它們到底需要做什么忽冻？

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

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

效率提升

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

資源隔離

當我們導出多個遠程接口時，如何避免單一接口調用占據所有線程資源眠菇，而引發(fā)其他接口執(zhí)行阻塞边败。

超時控制

當某個接口執(zhí)行緩慢，而客戶端已經超時放棄等待后捎废，服務端的線程繼續(xù)執(zhí)行此時顯得毫無意義笑窜。

異常

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

本地調用一定會執(zhí)行辐益，而遠程調用則不一定断傲，調用消息可能因為網絡原因并未發(fā)送到服務方。

本地調用只會拋出接口聲明的異常智政，而遠程調用還會跑出 RPC 框架運行時的其他異常艳悔。

本地調用和遠程調用的性能可能差距很大，這取決于 RPC 固有消耗所占的比重女仰。

正是這些區(qū)別決定了使用 RPC 時需要更多考量猜年。 當調用遠程接口拋出異常時，異臣踩蹋可能是一個業(yè)務異常乔外，也可能是 RPC 框架拋出的運行時異常（如：網絡中斷等）。業(yè)務異常表明服務方已經執(zhí)行了調用一罩，可能因為某些原因導致未能正常執(zhí)行杨幼，而 RPC 運行時異常則有可能服務方根本沒有執(zhí)行，對調用方而言的異常處理策略自然需要區(qū)分。

由于 RPC 固有的消耗相對本地調用高出幾個數量級差购，本地調用的固有消耗是納秒級四瘫，而 RPC 的固有消耗是在毫秒級。那么對于過于輕量的計算任務就并不適合導出遠程接口由獨立的進程提供服務欲逃，只有花在計算任務上的時間遠遠高于 RPC 的固有消耗才值得導出為遠程接口提供服務找蜜。

總結

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

看到這里的同學也許會想按這個概念模型和實現(xiàn)解析真得能開發(fā)實現(xiàn)一個 RPC 框架庫么？這個問題我能肯定的回答陈惰，真得可以畦徘。因為我就按這個模型開發(fā)實現(xiàn)了一個最小化的 RPC 框架庫來學習驗證，相關的代碼放在 Github 上抬闯，感興趣的同學可以自己去閱讀旧烧。這是我自己的一個實驗性質的學習驗證用開源項目，地址是https://github.com/mindwind/craft-atom画髓，其中的craft-atom-rpc即是按這個模型實現(xiàn)的微型 RPC 框架庫掘剪，代碼量相對工業(yè)級使用的 RPC 框架庫少的多，方便閱讀學習奈虾。

最后夺谁，讀到這里的肯定都是好學不倦的同學，謝謝大家的時間肉微，讓我寫作的意義更多了一點:)匾鸥。

參考

[1] Wikipedia. [Bruce Jay Nelson](https://en.wikipedia.org/wiki/Bruce_Jay_Nelson)

[2] BIRRELL, NELSON. [Implementing Remote Procedure Calls](http://birrell.org/andrew/papers/ImplementingRPC.pdf). 1983

[3] CORBAR. [CORBAR](https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture)

[4] DUBBO. [DUBBO](http://dubbo.io/)