https://blog.csdn.net/mindfloating/article/details/39473807
近幾年的項目中，服務(wù)化和微服務(wù)化漸漸成為中大型分布式系統(tǒng)架構(gòu)的主流方式，而 RPC 在其中扮演著關(guān)鍵的作用。在平時的日常開發(fā)中我們都在隱式或顯式的使用 RPC，一些剛?cè)胄械某绦騿T會感覺 RPC 比較神秘，而一些有多年使用 RPC 經(jīng)驗的程序員雖然使用經(jīng)驗豐富，但有些對其原理也不甚了了。缺乏對原理層面的理解，往往也會造成開發(fā)中的一些誤用。
本文分上下兩篇《淺出篇》和《深入篇》，其目標就是想嘗試深入淺出的分析下 RPC 本質(zhì)，我總是這么認為理解了本質(zhì)才能更好的應(yīng)用。
RPC 的全稱是 Remote Procedure Call 是一種進程間通信方式。它允許程序調(diào)用另一個地址空間（通常是共享網(wǎng)絡(luò)的另一臺機器上）的過程或函數(shù)，而不用程序員顯式編碼這個遠程調(diào)用的細節(jié)。即程序員無論是調(diào)用本地的還是遠程的，本質(zhì)上編寫的調(diào)用代碼基本相同。
RPC 這個概念術(shù)語在上世紀 80 年代由?Bruce Jay Nelson?提出。這里我們追溯下當初開發(fā) RPC 的原動機是什么？在 Nelson 的論文?"Implementing Remote Procedure Calls"?中他提到了幾點：
1. 簡單：RPC 概念的語義十分清晰和簡單，這樣建立分布式計算就更容易。
2. 高效：過程調(diào)用看起來十分簡單而且高效。
3. 通用：在單機計算中過程往往是不同算法部分間最重要的通信機制。?
通俗一點說，就是一般程序員對于本地的過程調(diào)用很熟悉，那么我們把 RPC 作成和本地調(diào)用完全類似，那么就更容易被接受，使用起來毫無障礙。Nelson 的論文發(fā)表于 30 年前，其觀點今天看來確實高瞻遠矚，今天我們使用的 RPC 框架基本就是按這個目標來實現(xiàn)的。
Nelson 的論文中指出實現(xiàn) RPC 的程序包括 5 個部分：
1. User
2. User-stub
3. RPCRuntime
4. Server-stub
5. Server
這 5 個部分的關(guān)系如下圖所示
這里 user 就是 client 端，當 user 想發(fā)起一個遠程調(diào)用時，它實際是通過本地調(diào)用 user-stub。user-stub 負責將調(diào)用的接口、方法和參數(shù)通過約定的協(xié)議規(guī)范進行編碼并通過本地的 RPCRuntime 實例傳輸?shù)竭h端的實例。遠端 RPCRuntime 實例收到請求后交給 server-stub 進行解碼后發(fā)起本地端調(diào)用，調(diào)用結(jié)果再返回給 user 端。
Nelson 論文中給出的這個實現(xiàn)結(jié)構(gòu)也成為后來大家參考的標準范本。大約 10 年前，我最早接觸分布式計算時使用的?CORBAR?實現(xiàn)結(jié)構(gòu)基本與此類似。CORBAR 為了解決異構(gòu)平臺的 RPC，使用了 IDL（Interface Definition Language）來定義遠程接口，并將其映射到特定的平臺語言中。后來大部分的跨語言平臺 RPC 基本都采用了此類方式，比如我們熟悉的 Web Service（SOAP），近年開源的 Thrift 等。他們大部分都通過 IDL 定義，并提供工具來映射生成不同語言平臺的 user-stub 和 server-stub，并通過框架庫來提供 RPCRuntime 的支持。不過貌似每個不同的 RPC 框架都定義了各自不同的 IDL 格式，導(dǎo)致程序員的學(xué)習(xí)成本進一步上升（苦逼啊），Web Service 嘗試建立業(yè)界標準，無賴標準規(guī)范復(fù)雜而效率偏低，否則 Thrift 等更高效的 RPC 框架就沒必要出現(xiàn)了。
IDL 是為了跨平臺語言實現(xiàn) RPC 不得已的選擇，要解決更廣泛的問題自然導(dǎo)致了更復(fù)雜的方案。而對于同一平臺內(nèi)的 RPC 而言顯然沒必要搞個中間語言出來，例如 java 原生的 RMI，這樣對于 java 程序員而言顯得更直接簡單，降低使用的學(xué)習(xí)成本。目前市面上提供的 RPC 框架已經(jīng)可算是五花八門，百家爭鳴了。需要根據(jù)實際使用場景謹慎選型，需要考慮的選型因素我覺得至少包括下面幾點：
1. 性能指標
2. 是否需要跨語言平臺
3. 內(nèi)網(wǎng)開放還是公網(wǎng)開放
4. 開源 RPC 框架本身的質(zhì)量、社區(qū)活躍度
《淺出篇》大概就到這里結(jié)束了，《深入篇》會具體深入講解一個 RPC 框架需要實現(xiàn)哪里基本功能，達到什么目標，并以在 java 平臺上去具體實現(xiàn)一個 RPC 框架為例，分析其需要考慮的實現(xiàn)因素。
