1、簡介
RPC全稱是Remote Procedure Call，它是一種進程間通信方式。允許像調用本地服務一樣調用遠程服務，它的具體實現方式可以不同，例如Spring的HTTP Invoker，Facebook的Thrift
二進制私有協議通信。
RPC概念術語在上世紀80年代由Bruce Jay Nelson提出，在他的論文中對RPC進行了如下總結。
- 簡單：RPC概念的語義十分清晰和簡單，這樣建立分佈式計算就更容易。
- 高效：過程調用看起來十分簡單且高效。
- 通用：在單機計算中過程往往是不同算法和API，跨進程調用最重要的通用的通信機制。
2、RPC框架原理
RPC框架的目標就是讓遠程過程（服務）調用更加簡單、透明。RPC框架負責屏蔽底層的傳輸方式（TCP/UDP）、序列化方式（XML/JSON/二進制）和通信細節。框架使用者只需要瞭解誰在什麼位置提供了什麼樣的遠程服務接口即可，開發者不需要關心通信細節和調用過程。
因此一個RPC的設計需要考慮：傳輸方式、序列化、通信等方面。
RPC框架調用原理如下圖：
RPC框架實現的幾個核心技術點如下：
- 遠程服務提供者需要以某種形式提供服務調用相關的信息，包括但不限於服務接口定義、數據結構、或者中間態的服務定義文件，如Thrift的IDL文件，WS-RPC的WSDL文件定義，甚至也可以實服務端的接口說明文檔；服務調用者需要通過一定的途徑獲取遠程服務調用相關信息，例如服務端接口定義Jar包導入，獲取服務端IDL文件等。
- 遠程代理對象：服務調用者調用的服務實際是遠程服務的本地代理，對應Java語言，它的實現就是JDK的動態代理，通過動態代理的攔截機制，將本地調用封裝成遠程服務調用。
- 通信：RPC框架和具體的協議無關。
- 序列化：遠程通信，需要將對象轉換成二進制碼流進行網絡傳輸，不同的序列化框架，支持的數據類型、數據包大小、異常類型及性能都不同，不同的RPC框架應用場景不同，因此技術選擇也會存在很大差異。一些RPC框架，可以支持多種序列化方式，有的甚至支持用戶自定義序列化框架（Hadoop Avro）。
- 要解決通訊的問題，主要是通過在客戶端和服務器之間建立TCP連接，遠程過程調用的所有交換的數據都在這個連接裏傳輸。連接可以是按需連接，調用結束後就斷掉，也可以是長連接，多個遠程過程調用共享同一個連接。
- 要解決尋址的問題，也就是說，A服務器上的應用怎麼告訴底層的RPC框架，如何連接到B服務器（如主機或IP地址）以及特定的端口，方法的名稱名稱是什麼，這樣才能完成調用。比如基於Web服務協議棧的RPC，就要提供一個endpoint URI，或者是從UDDI服務上查找。如果是RMI調用的話，還需要一個RMI Registry來註冊服務的地址。
- 當A服務器上的應用發起遠程過程調用時，方法的參數需要通過底層的網絡協議如TCP傳遞到B服務器，由於網絡協議是基於二進制的，內存中的參數的值要序列化成二進制的形式，也就是序列化（Serialize）或編組（marshal），通過尋址和傳輸將序列化的二進制發送給B服務器。
- B服務器收到請求後，需要對參數進行反序列化（序列化的逆操作），恢復爲內存中的表達方式，然後找到對應的方法（尋址的一部分）進行本地調用，然後得到返回值。
- 返回值還要發送回服務器A上的應用，也要經過序列化的方式發送，服務器A接到後，再反序列化，恢復爲內存中的表達方式，交給A服務器上的應用。
3、主流RPC框架
- 由Facebook開發的RPC框架Apache Thrift
- Hadoop的子項目Avro-RPC
- caucho提供的基於binary-RPC框架Hessian
- Google開源的基於HTTP/2和ProtocolBuf的RPC框架gRPC