RPC理解

一、什麼是RPC？

RPC（Remote Procedure Call）中文名「遠程過程調用」，又是一個很蹩腳的翻譯。咱們拆開理解下，「過程」也叫方法或函數，「遠程」就是說方法不在當前進程裏，而是在其餘進程或機器上面，合起來 RPC 就是調用其餘進程或機器上面的函數。

在沒有網絡的時代，程序都是單機版的，全部邏輯都必須在同一個進程裏。進程之間就像高樓大廈裏面陌生的鄰居，你們沒法共享，遇到一樣的功能只能重複實現一次。顯然進程的障礙是逆天的，不符合先進生產力的發展方向，這個時候「進程間通訊」的需求出現了，你們要求進程之間可以相互交流，相互共享和調用。這樣再寫程序，就能夠利用進程間通訊機制來調用和共享已經存在的功能了。隨着網絡的出現，進程的隔閡進一步消除，不光同一棟樓裏的鄰居能夠共享資源，其餘小區、甚至其餘城市的居民均可以經過互聯網互相調用，這就是RPC。概念很容易理解，可是遠程和本地的實現原理有很大區別，架構設計者的職責就是設計一個機制讓遠程調用服務就像調本地服務同樣簡單，這就是RPC框架。

二、基本原理

RPC 首要解決的是通信的問題，主流的 RPC 框架分爲基於 HTTP 和基於 TCP 的兩種。基於 HTTP 的 RPC 調用很簡單，就和咱們訪問網頁同樣，只是它的返回結果更單一（JSON 或 XML）。它的優勢在於實現簡單，標準化和跨語言，比較適合對外提供 OpenAPI 的場景，而它的缺點是 HTTP 協議傳輸效率較低、短鏈接開銷較大（HTTP 2.0 後有很大改進）。而基於 TCP 的 RPC 調用，因爲 TCP 協議處於協議棧的下層，可以更加靈活地對協議字段進行定製，減小網絡開銷，提升性能，實現更大的吞吐量和併發數。可是須要更多地關注底層複雜的細節，跨語言和跨平臺難度大，實現的代價更高，它比較適合內部系統之間追求極致性能的場景。

接下我講的 RPC 都是基於 TCP 的，由於它是目前業界主流 RPC 框架支持的方式，也是阿里的 HSF，螞蟻的 Bolt 採用的方式。首先來看看一個 RPC 調用的基本流程，以便你們對它有宏觀的認識，後面再逐一討論其中的細節

1. 調用方（Client）經過本地的 RPC 代理（Proxy）調用相應的接口
2. 本地代理將 RPC 的服務名，方法名和參數等等信息轉換成一個標準的 RPC Request 對象交給 RPC 框架
3. RPC 框架採用 RPC 協議（RPC Protocol）將 RPC Request 對象序列化成二進制形式，而後經過 TCP 通道傳遞給服務提供方 （Server）
4. 服務端（Server）收到二進制數據後，將它反序列化成 RPC Request 對象
5. 服務端（Server）根據 RPC Request 中的信息找到本地對應的方法，傳入參數執行，獲得結果，並將結果封裝成 RPC Response 交給 RPC 框架
6. RPC 框架經過 RPC 協議（RPC Protocol）將 RPC Response 對象序列化成二進制形式，而後經過 TCP 通道傳遞給服務調用方（Client）
7. 調用方（Client）收到二進制數據後，將它反序列化成 RPC Response 對象，而且將結果經過本地代理（Proxy）返回給業務代碼

參考連接：
https://juejin.im/entry/5b2089def265da6e2f3e39fd

https://www.yuque.com/egg/nodejs/dklip5