GRPC核心概念、架構和生命週期

GRPC核心概念、架構和生命週期

標籤（空格分隔）： go,grpc

官網地址：https://grpc.io/docs/what-is-grpc/core-concepts/

概述

與許多 RPC 系統一樣，gRPC 基於定義服務的思想，指定可以使用其參數和返回類型遠程調用的方法。默認情況下，gRPC 使用協議緩衝區作爲接口定義語言 （IDL） 來描述服務接口和有效負載消息的結構。如果需要，可以使用其他替代方案

gRPC 允許您定義四種服務方法

• 一元 RPC
  其中客戶端向服務器發送單個請求並返回單個響應，就像普通函數調用一樣
  rpc SayHello(HelloRequest) returns (HelloResponse);
• 服務器流式處理 RPC
  其中客戶端向服務器發送請求並獲取流以讀回消息序列。客戶端從返回的流中讀取，直到沒有更多消息。gRPC 保證單個 RPC 調用中的消息排序
  rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse);
• 客戶端流式處理 RPC
  其中客戶端寫入一系列消息並將其發送到服務器，再次使用提供的流。客戶端完成消息寫入後，它將等待服務器讀取消息並返回其響應。同樣，gRPC 保證單個 RPC 調用中的消息排序
  rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse);
• 雙向流式處理 RPC
  其中雙方使用讀寫流發送一系列消息。這兩個流獨立運行，因此客戶端和服務器可以按照它們喜歡的任何順序進行讀取和寫入：例如，服務器可以等待接收所有客戶端消息，然後再寫入響應，或者它可以交替讀取消息然後寫入消息，或者讀取和寫入的某種其他組合。保留每個流中消息的順序
  rpc BidiHello(stream HelloRequest) returns (stream HelloResponse);

使用接口

從 .proto 文件中的服務定義開始，gRPC 提供了生成客戶端和服務器端代碼的協議緩衝區編譯器插件。gRPC 用戶通常在客戶端調用這些 API，並在服務器端實現相應的 API

 - 在服務器端，服務器實現服務聲明的方法，並運行 gRPC 服務器來處理客戶端調用。gRPC
   基礎結構解碼傳入請求、執行服務方法並對服務響應進行編碼

 - 在客戶端，客戶端有一個稱爲存根的本地對象（對於某些語言，首選術語是客戶端），它實現與服務相同的方法。然後，客戶端可以在本地對象上調用這些方法，這些方法將調用的參數包裝在適當的協議緩衝區消息類型中，將請求發送到服務器，並返回服務器的協議緩衝區響應

RPC 生命週期

在本部分中，你將詳細瞭解當 gRPC 客戶端調用 gRPC 服務器方法時會發生什麼情況。有關完整的實現詳細信息，請參閱特定於語言的頁面

Unary RPC【一元RPC】

首先考慮最簡單的 RPC 類型，其中客戶端發送單個請求並返回單個響應

• 客戶端調用存根方法後，將通知服務器已使用此調用的客戶端元數據、方法名稱和指定的截止時間（如果適用）調用了 RPC
• 然後，服務器可以立即發回自己的初始元數據（必須在任何響應之前發送），也可以等待客戶端的請求消息。首先發生，是特定於應用程序的
• 一旦服務器獲得客戶端的請求消息，它就會執行創建和填充響應所需的任何工作。然後，響應（如果成功）連同狀態詳細信息（狀態代碼和可選狀態消息）和可選的尾隨元數據一起返回給客戶端
• 如果響應狀態爲“正常”，則客戶端將獲得響應，從而在客戶端完成調用

Server streaming RPC【服務器流RPC】

服務器流式處理 RPC 類似於一元 RPC，不同之處在於服務器返回消息流以響應客戶端的請求。發送所有消息後，服務器的狀態詳細信息（狀態代碼和可選狀態消息）和可選的尾隨元數據將發送到客戶端。這樣就完成了服務器端的處理。客戶端在擁有服務器的所有消息後完成

Client streaming RPC【客戶端流RPC】

客戶端流式處理 RPC 類似於一元 RPC，不同之處在於客戶端向服務器發送消息流而不是單個消息。服務器使用單個消息（以及其狀態詳細信息和可選的尾隨元數據）進行響應，通常但不一定要在收到所有客戶端的消息之後

Bidirectional streaming RPC【雙向流RPC】

    在雙向流式處理 RPC 中，調用由調用該方法的客戶端和接收客戶端元數據、方法名稱和截止時間的服務器發起。服務器可以選擇發回其初始元數據或等待客戶端開始流式傳輸消息

    客戶端和服務器端流處理是特定於應用程序的。由於這兩個流是獨立的，因此客戶端和服務器可以按任意順序讀取和寫入消息。例如，服務器可以等到它收到客戶端的所有消息後再寫入其消息，或者服務器和客戶端可以玩“乒乓球”——服務器收到請求，然後發回響應，然後客戶端根據響應發送另一個請求，依此類推

截止時間/超時

    gRPC 允許客戶端指定在 RPC因DEADLINE_EXCEEDED錯誤終止之前，他們願意等待 RPC 完成的時間。在服務器端，服務器可以查詢特定 RPC 是否已超時, 或者還剩下多少

時間來完成 RPC

RPC 終止

    在 gRPC 中，客戶端和服務器都對調用是否成功做出獨立的本地確定，它們的結論可能不匹配。這意味着，例如，您可能有一個在服務器端成功完成的 RPC（“我已經發送了我所有的響應！”），但在客戶端失敗（“響應在我的截止日期之後到達！”）。服務器也可以在客戶端發送所有請求之前決定完成

取消 RPC

    客戶端或服務器可以隨時取消 RPC。取消會立即終止 RPC，以便不再執行任何進

一步的工作