GRPC

モノリシック アーキテクチャでは、コンポーネントはメモリ内のメソッド呼び出しを介して通信します。これは瞬時に行われ、信頼性が高くなります。ただし、マイクロサービス アーキテクチャに移行すると、これらのコンポーネントはネットワーク境界によって分離されます。通信はアウトプロセス ネットワーク呼び出し (プロセス間通信、つまり IPC) になります。 長年にわたり、JSON ペイロードを使用した HTTP/1.1 経由の REST (Representational State Transfer) が、Web API を構築するためのデフォルトの標準となってきました。 REST は、公開 Web サービスやクライアントとサーバー間の対話には優れていますが、高頻度で低遅延の内部サービス間通信に使用すると、重大なボトルネックが発生します。 このため、最新のマイクロサービスは gRPC (Google Remote Procedure Call) に急速に移行しています。この記事では、REST の制限を分析し、gRPC のアーキテクチャの柱を詳しく分析し、Java での gRPC サービスの完全な実装について説明します。 1. マイクロサービスにおける REST のボトルネック REST は 20 年以上にわたって Web を支えてきました。ただし、その基盤となるテクノロジーは、内部分散アーキテクチャ用に最適化されていません。 A. プレーンテキスト JSON のオーバーヘッド JSON は人間が判読できるため、デバッグが容易ですが、マシン間の通信には非常に非効率です。 シリアル化/逆シリアル化のコスト: テキスト文字列トークンを解析してオブジェクトに変換すると、かなりの CPU サイクルが消費されます。 大きなペイロード サイズ: JSON キーは単一のリクエストごとに繰り返されます (例: {"transactionId": "123", "amount": 99.99})。 1 秒あたり何百万ものリクエストを処理するシステムの場合、この冗長なメタデータは膨大なネットワーク帯域幅を浪費します。 B. HTTP/1.1 接続の制限 REST は通常、HTTP/1.1 上で実行されますが、これにはいくつかの構造的非効率性があります。