長期存在的 GRPC 調用

Question

我想知道長期 GRPC 調用的最佳實踐。

我有一個典型的客戶端 --> 服務器調用（都是 golang），服務器處理可能需要大約 20-30 秒才能完成。 在我繼續之前，我需要客戶等到它完成。 我看到的選項（我不喜歡其中任何一個）：

1. 將超時設置為荒謬的長度（例如 1 分鍾），然后等待。 這感覺就像一個 hack，而且我希望在我的服務網格中遇到類似這樣的事情的奇怪行為。
2. 使用 stream - 我仍然需要在這里執行選項#1，它真的對我沒有多大幫助，因為我的反應實際上只是一元，而 stream 對我沒有多大好處
3. 輪詢 - （我實現了它並且它有效，但我不喜歡它） - 我做大部分處理異步並讓我的原始 GRPC 調用返回一個存儲在 Redis 中的事務 ID，並保存事務的 state。 我創建了一個不同的 GRPC 端點來循環輪詢事務的狀態。
4. 隊列或 Stream（例如 Kafka 流） - 將客戶端設置為類似於 Kafka 主題的偵聽器，並讓我的服務器在完成時通知（隊列 || 流），以便我的客戶端將其接收。 我認為這會起作用，但似乎設計過度了。

選項#3 對我有用，但肯定感覺很臟。 我也 100% 依賴 Redis。 鑒於 GRPC 是基於 HTTP2 構建的，那么我認為可能存在某種服務器推送選項，但我沒有找到任何選項。

我擔心我忽略了一種處理這個問題的簡單方法。

謝謝

Answer 1

長壽命的 gRPC 通道是一個重要的用例，並得到完全支持。 但是，一個 gRPC 通道可能有多個 TCP 連接，並且 TCP 可能由於不活動而斷開連接。 您可以使用 keep-alive 或 HTTP/2 ping 來保持 TCP 處於活動狀態。 有關更多詳細信息，請參閱 此線程。 您提到的所有選項都沒有解決您的服務器需要一段時間才能響應的問題。 除非我缺少某些東西，否則您的問題中沒有任何內容是 gRPC 問題。