gRPC：アップ・アンド・ランニング

第3章 gRPC通信パターン

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

最初の 2、3 章では、gRPC のプロセス間通信テクニ ックの基礎を学び、簡単な gRPC ベースのアプリ ケーションを構築する実習を行った。これまでのところ、サービス・インタフェースを定義し、サービスを実装し、gRPCサーバを動作させ、gRPCクライアント・アプリケーションを通してリモートからサービス演算子を呼び出すということを行ってきた。クライアント、サーバ間の通信パターンは単純なリクエスト/レスポンス・スタイルで、1回のリクエストに対して1回のレスポンスを返す。しかし、gRPCでは、単純なリクエスト/レスポンス・パターン以外のさまざまなプロセス間通信パターン（またはRPCスタイル）を利用することができる。

この章では、gRPCベースのアプリケーションで使用される4つの基本的な通信パターン、単項RPC（単純RPC）、サーバ側ストリーミング、クライアント側ストリーミング、双方向ストリーミングについて説明する。それぞれのパターンを紹介するために、いくつかの実際のユースケースを使い、gRPC IDLを使ってサービス定義を定義し、Goを使ってサービス側とクライアント側の両方を実装する。

注

GoとJavaのコードサンプル

一貫性を保つため、この章のコード・サンプルはすべてGoを使って書かれている。しかし、もしあなたがJava開発者なら、本書のソースコードリポジトリで、同じユースケースの完全なJavaコードサンプルを発見することもできる。

シンプルRPC（ユナリーRPC）

gRPCの通信パターンについて、最も単純なRPCスタイルである単純RPC（unary RPCとも呼ばれる）から話を始めよう。単純RPCでは、クライアントがサーバのリモート関数を呼び出すとき、クライアントはサーバに単一のリクエストを送信し、ステータスの詳細と末尾のメタデータとともに送信される単一のレスポンスを取得する。実際、これは第1章と第2章で学んだ通信パターンと全く同じである。実際のユースケースを使って、単純なRPCパターンをさらに理解してみよう。

gRPCをベースとしたオンライン・リテール・アプリケーション用のOrderManagement サービスを構築する必要があるとする。このサービスの一部として実装しなければならないメソッドの1つはgetOrder メソッドであり、クライアントは注文IDを提供することで既存の注文を取得することができる。図3-1に示すように、クライアントはオーダーIDを持つ単一のリクエストを送信し、サービスはオーダー情報を含む単一のレスポンスで応答する。したがって、これは単純なRPCパターンに従っている。

図3-1. 単純/単一RPC

では、このパターンの実装に進もう。最初のステップは、getOrder メソッドでOrderManagement サービスのサービス定義を作成することである。例3-1のコードスニペットに示すように、プロトコルバッファを使用してサービス定義を定義することができる。getOrder リモートメソッドは、単一のリクエストオーダーIDを受け取り、単一のレスポンスで応答し、 ...