RPC

轉(zhuǎn)載：http://blog.csdn.net/mindfloating/article/details/39474123

1.主要框架

近幾年的項(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)豐富，但有些對(duì)其原理也不甚了了。缺乏對(duì)原理層面的理解，往往也會(huì)造成開發(fā)中的一些誤用。

本文分上下兩篇《淺出篇》和《深入篇》，其目標(biāo)就是想嘗試深入淺出的分析下 RPC 本質(zhì)，我總是這么認(rèn)為理解了本質(zhì)才能更好的應(yīng)用。

RPC 是什么？

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)程的，本質(zhì)上編寫的調(diào)用代碼基本相同。

RPC 起源

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

\1. 簡(jiǎn)單：RPC 概念的語義十分清晰和簡(jiǎn)單，這樣建立分布式計(jì)算就更容易。
\2. 高效：過程調(diào)用看起來十分簡(jiǎn)單而且高效。
\3. 通用：在單機(jī)計(jì)算中過程往往是不同算法部分間最重要的通信機(jī)制。

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

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

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

\1. User
\2. User-stub
\3. RPCRuntime
\4. Server-stub
\5. Server

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

img

這里 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í)例收到請(qǐng)求后交給 server-stub 進(jìn)行解碼后發(fā)起本地端調(diào)用，調(diào)用結(jié)果再返回給 user 端。

RPC 實(shí)現(xiàn)

Nelson 論文中給出的這個(gè)實(shí)現(xiàn)結(jié)構(gòu)也成為后來大家參考的標(biāo)準(zhǔn)范本。大約 10 年前，我最早接觸分布式計(jì)算時(shí)使用的 CORBAR 實(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，并通過框架庫(kù)來提供 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ù)雜的方案。而對(duì)于同一平臺(tái)內(nèi)的 RPC 而言顯然沒必要搞個(gè)中間語言出來，例如 java 原生的 RMI，這樣對(duì)于 java 程序員而言顯得更直接簡(jiǎn)單，降低使用的學(xué)習(xí)成本。目前市面上提供的 RPC 框架已經(jīng)可算是五花八門，百家爭(zhēng)鳴了。需要根據(jù)實(shí)際使用場(chǎng)景謹(jǐn)慎選型，需要考慮的選型因素我覺得至少包括下面幾點(diǎn)：
\1. 性能指標(biāo)
\2. 是否需要跨語言平臺(tái)
\3. 內(nèi)網(wǎng)開放還是公網(wǎng)開放
\4. 開源 RPC 框架本身的質(zhì)量、社區(qū)活躍度

2.細(xì)節(jié)

RPC 功能目標(biāo)

RPC 的主要功能目標(biāo)是讓構(gòu)建分布式計(jì)算（應(yīng)用）更容易，在提供強(qiáng)大的遠(yuǎn)程調(diào)用能力時(shí)不損失本地調(diào)用的語義簡(jiǎn)潔性。為實(shí)現(xiàn)該目標(biāo)，RPC 框架需提供一種透明調(diào)用機(jī)制讓使用者不必顯式的區(qū)分本地調(diào)用和遠(yuǎn)程調(diào)用，在前文《淺出篇》中給出了一種實(shí)現(xiàn)結(jié)構(gòu)，基于 stub 的結(jié)構(gòu)來實(shí)現(xiàn)。下面我們將具體細(xì)化 stub 結(jié)構(gòu)的實(shí)現(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é)果。

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

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

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

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

img

RPC 服務(wù)方通過 RpcServer 去導(dǎo)出（export）遠(yuǎn)程接口方法，而客戶方通過 RpcClient 去引入（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）并將編碼后的請(qǐng)求消息通過通道發(fā)送給服務(wù)方。

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

RPC 組件職責(zé)

上面我們進(jìn)一步拆解了 RPC 實(shí)現(xiàn)結(jié)構(gòu)的各個(gè)組件組成部分，下面我們?cè)敿?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  
   客戶方實(shí)現(xiàn)：負(fù)責(zé)編碼調(diào)用信息和發(fā)送調(diào)用請(qǐng)求到服務(wù)方并等待調(diào)用結(jié)果返回  
   服務(wù)方實(shí)現(xiàn)：負(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é)接收客戶方請(qǐng)求并返回請(qǐng)求結(jié)果  
8. RpcProcessor  
   負(fù)責(zé)在服務(wù)方控制調(diào)用過程，包括管理調(diào)用線程池、超時(shí)時(shí)間等  
9. RpcChannel  
   數(shù)據(jù)傳輸通道  

RPC 實(shí)現(xiàn)分析

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

導(dǎo)出遠(yuǎn)程接口

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

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

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

// 只導(dǎo)出 DemoService 中簽名為 hi(String s) 的方法  
server.export(DemoService.class, demo, "hi", new Class<?>[] { String.class }, options); 

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)的，那么對(duì)于 RPC 來說跨進(jìn)程的調(diào)用就沒法隱式實(shí)現(xiàn)了。如果前面DemoService 接口有 2 個(gè)實(shí)現(xiàn)，那么在導(dǎo)出接口時(shí)就需要特殊標(biāo)記不同的實(shí)現(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 是另一個(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)入遠(yuǎn)程接口與客戶端代理

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

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

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

在 java 中 'import' 是關(guān)鍵字，所以代碼片段中我們用 refer 來表達(dá)導(dǎo)入接口的意思。這里的導(dǎo)入方式本質(zhì)也是一種代碼生成技術(shù)，只不過是在運(yùn)行時(shí)生成，比靜態(tài)編譯期的代碼生成看起來更簡(jiǎn)潔些。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è)人認(rèn)為犧牲一些性能來獲得代碼可讀性和可維護(hù)性顯得更重要。

協(xié)議編解碼

客戶端代理在發(fā)起調(diào)用前需要對(duì)調(diào)用信息進(jìn)行編碼，這就要考慮需要編碼些什么信息并以什么格式傳輸?shù)椒?wù)端才能讓服務(wù)端完成調(diào)用。出于效率考慮，編碼的信息越少越好（傳輸數(shù)據(jù)少），編碼的規(guī)則越簡(jiǎn)單越好（執(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é)議頭長(zhǎng)度，為擴(kuò)展設(shè)計(jì)  
version    : 協(xié)議版本，為兼容設(shè)計(jì)  
st         : 消息體序列化類型  
hb         : 心跳消息標(biāo)記，為長(zhǎng)連接傳輸層心跳設(shè)計(jì)  
ow         : 單向消息標(biāo)記，  
rp         : 響應(yīng)消息標(biāo)記，不置位默認(rèn)是請(qǐng)求消息  
status code: 響應(yīng)消息狀態(tài)碼  
reserved   : 為字節(jié)對(duì)齊保留  
message id : 消息 id  
body size  : 消息體長(zhǎng)度  
  
-- 消息體 --  
采用序列化編碼，常見有以下格式  
xml   : 如 webservie soap  
json  : 如 JSON-RPC  
binary: 如 thrift; hession; kryo 等  

格式確定后編解碼就簡(jiǎn)單了，由于頭長(zhǎng)度一定所以我們比較關(guān)心的就是消息體的序列化方式。序列化我們關(guān)心三個(gè)方面：
\1. 序列化和反序列化的效率，越快越好。
\2. 序列化后的字節(jié)長(zhǎng)度，越小越好。
\3. 序列化和反序列化的兼容性，接口參數(shù)對(duì)象若增加了字段，是否兼容。
上面這三點(diǎn)有時(shí)是魚與熊掌不可兼得，這里面涉及到具體的序列化庫(kù)實(shí)現(xiàn)細(xì)節(jié)，就不在本文進(jìn)一步展開分析了。

傳輸服務(wù)

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

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

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

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

client stub 所做的事情僅僅是編碼消息并傳輸給服務(wù)方，而真正調(diào)用過程發(fā)生在服務(wù)方。server 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 自帶的反射，一些第三方庫(kù)也提供了性能更優(yōu)的反射調(diào)用，因此 RpcInvoker 就是封裝了反射調(diào)用的實(shí)現(xiàn)細(xì)節(jié)。

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

1. 效率提升  
   每個(gè)請(qǐng)求應(yīng)該盡快被執(zhí)行，因此我們不能每請(qǐng)求來再創(chuàng)建線程去執(zhí)行，需要提供線程池服務(wù)。  
2. 資源隔離  
   當(dāng)我們導(dǎo)出多個(gè)遠(yuǎn)程接口時(shí)，如何避免單一接口調(diào)用占據(jù)所有線程資源，而引發(fā)其他接口執(zhí)行阻塞。  
3. 超時(shí)控制  
   當(dāng)某個(gè)接口執(zhí)行緩慢，而 client 端已經(jīng)超時(shí)放棄等待后，server 端的線程繼續(xù)執(zhí)行此時(shí)顯得毫無意義。

RPC 異常處理

無論 RPC 怎樣努力把遠(yuǎn)程調(diào)用偽裝的像本地調(diào)用，但它們依然有很大的不同點(diǎn)，而且有一些異常情況是在本地調(diào)用時(shí)絕對(duì)不會(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í)行，對(duì)調(diào)用方而言的異常處理策略自然需要區(qū)分。

由于 RPC 固有的消耗相對(duì)本地調(diào)用高出幾個(gè)數(shù)量級(jí)，本地調(diào)用的固有消耗是納秒級(jí)，而 RPC 的固有消耗是在毫秒級(jí)。那么對(duì)于過于輕量的計(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)用。