一、遠程過程調用協議簡介
1、RPC 的本質
首先，我們探討一下什麼是 RPC。RPC，縮寫為 Remote Procedure Call Protocol，直譯來看就是遠程過程調用協議。
講得通俗一些：
- RPC 是一種通信機制
- RPC 實現了客户端/服務器通信模型
官方的定義可能會這樣解釋：它是一種協議，可以使程序能在網絡上請求遠程計算機上的服務，而無須關心底層網絡技術細節。
RPC 的構架可以分為三個層次：
- 用户與服務器（負責業務邏輯，並調用本地的存根程序）
- 存根程序（Stub）（負責封裝和解封裝約定語法和語義）
- RPC運行時（RPCRuntime）（管理網絡通信的最底層）
下面的示意圖説明了典型的開發情景：前端代碼調用後端服務
2、RPC 解決的核心問題
RPC 的設計解決了幾個關鍵問題：
- 協議一致性問題： 舉例來説，如何確保前端和後端能夠就“0為是，1為否”的約定達成共識。
- 傳輸協議的彈性： 當面對網絡錯誤、數據重傳、丟失或性能瓶頸時，RPC 如何應對。
- 服務的發現機制： 客户端應如何發現可用的服務器服務、訪問哪個端口等。服務器可能會啓動多個遠程調用服務，監聽在隨機端口，客户端需要一種機制來探測這些服務。
3、RPC 的使用場景
兩個經典的應用示例包括：
- 即時通訊軟件
- 微服務架構
4、RPC 的工作流程*
從調用到結果接收，RPC 的過程概述如下：
- 調用方（Client）發起本地調用式的遠程請求；
- 客户端存根（Client stub）接收請求，將調用的方法名、參數等序列化為可網絡傳輸的消息；
- 客户端存根發送序列化後的消息給服務端；
- 服務端存根（Server stub）接受消息並反序列化，以獲取調用的方法名和參數；
- 服務端存根執行本地調用獲取結果；
- 服務端返回執行結果給它的存根；
- 服務端存根序列化執行結果，發送回客户端；
- 客户端存根反序列化結果，並返回給客户端調用方；
- 調用方（Client）得到最終的RPC調用執行結果。
5、RPC 與 HTTP 的差異點
RPC 和 HTTP 對比不完全是同等級別的比較，更恰當的是將 RPC 和 "HTTP + RestFul" 放在一起對比。
傳輸協議方面
RPC 不限於 HTTP，它還可以選擇 TCP 進行傳輸，而 HTTP 只工作在自身的協議之上。
傳輸效率方面
RPC 包含了 HTTP2 的特性，使得它在傳輸效率上優於標準的 HTTP1。
性能消耗方面
得益於 HTTP2 的特性（如二進制傳輸、頭部壓縮等），RPC 在性能上的消耗相較於 HTTP1 會更低。
負載均衡方面
大多數 RPC 框架自帶負載均衡策略，而傳統的 HTTP 方案則通常需要通過 Nginx/HAProxy 等工具實現。
服務治理方面
RPC 框架 能實現自動通知和服務調整，而 HTTP 則往往需要手動通知和修改配置。
二、深入瞭解 gRPC
1、gRPC 概述
簡單來説，gRPC 是一個開源的RPC框架，它建立在 HTTP2 的基礎設施之上，因而自然具備了HTTP2 的一系列優勢：
- 二進制分幀的數據傳輸
- 多路複用
- 服務端推送
- 頭部壓縮
2、gRPC 的通信流程
如下圖所示，通過 gRPC 進行遠程服務調用時，客户端（client）僅需 gRPC 存根，通過 Proto Request 請求 gRPC 服務器，服務器則通過 Proto Response(s) 返回結果。
三、瞭解 JSON-RPC 接口
JSON-RPC 是一種簡潔的使用JSON格式數據的RPC傳輸協議，它通過HTTP進行通信。Postman 是API開發中常用的工具，能夠輕鬆實現 JSON-RPC 接口的測試與使用。
四、如何調試 gRPC
Apifox 提供基於 .proto 文件的 gRPC 接口調試功能，支持包含一元調用和流式調用。項目創建時，選擇「gRPC項目」並導入 .proto 文件，即可開始調試，無需編寫額外代碼。
導入 .proto 文件之前，需要確認是否有其他依賴的.proto文件，並添加相應的依賴路徑。
一元調用
通過將 gRPC URL 填入地址欄並點擊「調用」按鈕，即可實現一元調用。
流式調用
流式調用包括服務端流、客户端流和雙向流。調用成功後，用户可以在消息標籤區編寫併發送消息。Apifox 展示了時間線視圖，按順序分佈顯示調用狀態、發送的消息和收到的消息。點擊具體消息可以方便地查看詳細信息。
知識擴展：
- REST API 簡介 - RESTful Web 服務
- 分佈式系統框架對比：gRPC vs Dubbo
