深入淺出RPC——淺出篇(轉載)

標籤：section   remote   十分   href   隱式   通過   重要   .com   計算   

本文轉載自這裡是原文

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

本文分上下兩篇《淺出篇》和《深入篇》，其目標就是想嘗試深入淺出的分析下 RPC 本質，我總是這麼認為理解了本質才能更好的應用。

RPC是什麼

RPC全稱是Remote Procedure Call是一種處理序間通訊方式。它允許程式調用另外一個地址空間（通常是共用網路的另一台機器）的過程或函數，而不用程式員顯式編碼這個遠程調用的細節。即程式員無論調用本地的還是遠端，本質上編寫的調用代碼基本相同。

RPC起源

RPC 這個概念術語在上世紀 80 年代由 Bruce Jay Nelson 提出。 這裡我們追溯下當初開發 RPC 的原動機是什嗎？ 在 Nelson 的論文 Implementing Remote Procedure Calls 中他提到了幾點：

簡單：RPC 概念的語義十分清晰和簡單，這樣建立分散式運算就更容易。 高效：程序呼叫看起來十分簡單而且高效。 通用：在單機計算中過程往往是不同演算法部分間最重要的通訊機制

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

RPC 結構

User User-stub RPCRuntime Server-stub Serve

這裡 user 就是 client 端，當 user 想發起一個遠程調用時，它實際是通過本地調用 user-stub。 user-stub 負責將調用的介面、方法和參數通過約定的協議規範進行編碼並通過本地的 RPCRuntime 執行個體傳輸到遠端的執行個體。 遠端 RPCRuntime 執行個體收到請求後交給 server-stub 進行解碼後發起本地端調用，調用結果再返回給 user 端。

RPC 實現

Nelson 論文中給出的這個實現結構也成為後來大家參考的標準範本。 大約 10 年前，我最早接觸分散式運算時使用的 CORBAR 實現結構基本與此類似。 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 程式員而言顯得更直接簡單，降低使用的學習成本。 目前市面上提供的 RPC 架構已經可算是五花八門，百家爭鳴了。 需要根據實際使用情境謹慎選型，需要考慮的選型因素我覺得至少包括下面幾點：

• 效能指標
• 是否需要跨語言平台
• 內網開放還是公網開放
• 開源 RPC 架構本身的品質、社區活躍度

總結

《淺出篇》大概就到這裡結束了，《深入篇》會具體深入講解一個 RPC 架構需要實現哪裡準系統，達到什麼目標，並以在 java 平台上去具體實現一個 RPC 架構為例，分析其需要考慮的實現因素。

 

http://daodaoliang.com/blog/2015/08/27/%E6%B7%B1%E5%85%A5%E6%B5%85%E5%87%BARPC(%E6%B5%85%E5%87%BA%E7%AF%87).html

深入淺出RPC——淺出篇(轉載)