gRPC 爲什麼這麼快？

RPC（Remote Procedural Call, 遠程過程調用）之所以被稱爲 remote，因爲在微服務架構下，RPC 可以實現遠程服務之間的通信。從服務調用者的角度來看，它就像一個本地函數調用。

下圖說明了 gRPC 的數據流。

• 步驟 1：客戶前端發出 REST 調用。請求體通常爲 JSON 格式。

• 步驟 2-4：訂單服務（gRPC 客戶端）接收 REST 調用，對其進行轉換，然後向支付服務發出 RPC 調用。gPRC 將 client stub 編碼爲二進制格式，並將其發送到底層傳輸層。

• 步驟 5：gRPC 通過 HTTP2 在網絡上發送數據包。由於採用了二進制編碼和網絡優化，gRPC 據說比 JSON 快 5 倍。

• 步驟 6 - 8：支付服務（gRPC 服務器）接收來自網絡的數據包，解碼後調用服務器應用程序。

• 步驟 9 - 11：結果從服務器應用程序返回，經過編碼後發送到傳輸層。

• 步驟 12 - 14：訂單服務接收數據包、解碼並將結果發送給客戶端應用程序。

和廣泛用於前後端通信的 REST 相比，gRPC 普遍用於服務間通信。並且，REST 不是一個協議，它只是一個基於 HTTP 協議的設計範式。gRPC 針對傳輸層和數據編解碼都進行了優化，使得它的效率更高。

雖然 RPC 調用在微服務中被廣泛採用，神書 DDIA (Designing Data-Intensive Applications) 中列舉了一些 RPC 的侷限性：

1. 本地函數調用的結果是可預測的，而 RPC 需要經過網絡傳輸，數據在中途可能因爲各種原因丟失。

2. RPC 調用有可能超時，編寫程序時需要考慮該情況。

3. 重試一個失敗的 RPC 調用有可能造成數據重複，需要考慮冪等。

4. 由於傳輸數據時需要序列化和反序列化，RPC 在傳輸複雜對象時會不太方便。

正是因爲這些原因，讓遠程調用看上去像是一個本地調用的編程思想值得商榷。開發者在使用 RPC 時需要有針對性地進行容錯處理。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/MVGT_J5qlnTKqx-ZDL062A