亚洲中文久久精品无码软件_精品刺激公共露出_蜜桃秘 免费一区二区三区_欧美日韩福利性插视频_久女女热精品视频在线观看

gRPC 應用指引

時間：2023-04-25 12:40:37     來源：博客園

一、核心概念、架構及生命周期1、服務定義

gRPC 默認使用protocol buffers。

service HelloService {  rpc SayHello (HelloRequest) returns (HelloResponse);}message HelloRequest {  string greeting = 1;}message HelloResponse {  string reply = 1;}

gRPC 可以定義四種類型服務：

Unary RPCs：一次請求，一次回復。


(資料圖片僅供參考)

rpc SayHello(HelloRequest) returns (HelloResponse);

服務端流式請求：客戶端發(fā)送一次請求，服務端流式返回一系列數據。

rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse);

客戶端流式請求：客戶端流式寫入一系列請求，然后發(fā)送到服務端。客戶端寫完請求后，等待服務端接受并返回結果。

rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse);

雙向流式請求：客戶端和服務端雙向發(fā)送數據流，各自獨立?？梢噪S讀隨寫，或者一次性讀完再寫。

rpc BidiHello(stream HelloRequest) returns (stream HelloResponse);
2、API 使用

首先在 .proto 文件中定義一個服務，然后使用 gRPC 提供的 pb 編譯插件來生成客戶端和服務端代碼。

服務端：實現定義的服務，響應客戶端請求。gRPC 框架解碼請求，執(zhí)行服務方法，編碼返回結果?？蛻舳耍罕镜?stub 包含實現的服務方法，客戶端可以直接調用 stub 的相應方法，以 pb 消息類型包裝請求參數發(fā)送到服務器，同時返回服務器返回的結果。3、同步和異步

同步 RPC 請求（發(fā)送請求，阻塞直到服務端返回結果）和我們通常所說的 RPC 定義最為接近。但是，在實際應用中，非阻塞異步請求更適合。

4、RPC 生命周期a）Unary RPC

客戶端發(fā)送一次請求，獲取一次返回。

客戶端請求本地 stub 方法，服務端獲取到通知，并伴隨著客戶端的請求數據，包括客戶端metadata、方法名及deadline。服務端可以直接返回自身的 metadata（必須在業(yè)務結果返回前返回）或者等待客戶端的請求消息（自定義）。服務端收到客戶端請求消息，然后執(zhí)行相應的方法，組裝相應的數據結果，伴隨著請求狀態(tài)信息（狀態(tài)碼及可能狀態(tài)消息）返回給客戶端。如果狀態(tài)為 OK，則客戶端可以獲取到結果進行處理，完成整個調用過程。b）服務端流式 RPC

服務端返回的是一個數據流。在服務端發(fā)送完業(yè)務數據后，會繼續(xù)返回狀態(tài)信息。

c）客戶端流式 RPC

客戶端發(fā)送的是一個請求數據流。

d）雙向流式 RPC

客戶端和服務端雙向發(fā)送數據流，各自獨立?？梢噪S讀隨寫，或者一次性讀完再寫。

5、Deadlines/Timeouts

gRPC 允許客戶端聲明超時（請求 DEADLINE_EXCEEDED 異常之前等待的時間）。服務端可以通過此來判定請求是否超時及剩余處理時間。

6、RPC 終止

gRPC 中客戶端和服務端都可以獨立終止請求。比如服務端已經成功響應請求，但是客戶端超時終止；服務端在接收完客戶端請求數據前限頻校驗終止請求流程。

7、RPC 請求取消

客戶端和服務端都可以在任何時候取消 RPC 流程。

8、Metadata

RPC 請求元數據，kv 列表形式，key 為 string 類型，value 通常為string，也可以為二進制。

key 大小寫敏感，不能以 grpc- 做前綴（保留），二進制 value 的 key 以 -bin 結尾。

gRPC 不會使用用戶自定義的元數據。

元數據使用，不同開發(fā)語言可能不同。

9、Channels

gRPC channel 是客戶端到服務端的鏈接。用以創(chuàng)建客戶端 stub。

channel 提供相應的參數配置控制 gRPC 請求行為，例如交互數據壓縮等。

channel 的狀態(tài)包括已建立鏈接及空閑。

二、最佳實踐

rpc 請求初始化包括：客戶端負載均衡，傳輸層 HTTP/2 請求創(chuàng)建及請求服務端相應的業(yè)務接口。

盡量重用 stubs 和 channels。

2、提供心跳機制以確保 HTTP/2 連接即使在系統(tǒng)業(yè)務不活躍時段仍能保持活躍，避免因 RPC 請求初始化導致的響應延遲。

3、對于可能存續(xù)長時間的數據流請求交互，適宜使用流式處理，避免頻繁的 RPC 初始化。但是流式處理也存在無法動態(tài)均衡負載的及debug 困難的問題。雖然可以在小規(guī)模請求上提升性能，但是會因為負載均衡因素及復雜性降低整體擴展性。（python 除外）

4、每一個 gRPC channel 可以使用 0 個或多個 HTTP/2 鏈接，每個鏈接可以承載一定數量的的并發(fā)數據流。當鏈接上活躍的 RPC 請求達到上限，新進的請求會進入調用端等待隊列。因此，對于高負載或持久的流式請求會因此產生性能問題。對于此，可以使用如下兩種方式處理：

對于此類業(yè)務請求使用額外的 chennel。使用 gRPC 連接池來均衡處理請求（需要特定的處理來避免重復使用同一個 channel）

5、對于 Java 語言

使用非阻塞 stubs 來并行處理 RPC 請求。

提供自定義連接池，根據實際的業(yè)務負載來配置相關參數。

標簽：

最新文章推薦

熱點資訊