gRPC は、分散システムでマイクロサービスを構築するための高性能のオープンソース リモート プロシージャ コール フレームワークです。 gRPC を使用する場合、よくある質問は、クライアントにマイクロサービスのサービス IP アドレスを知らせる方法です。まず、PHP エディターの Shinichi 氏が、インターフェイス定義言語としてプロトコル バッファーを使用し、トランスポート プロトコルとして HTTP/2 を使用する gRPC の仕組みについて説明しました。次に、編集者は、サービス IP アドレスの問題を解決するために一般的に使用される 2 つの方法、静的構成とサービス検出を紹介しました。静的構成では、クライアント コードにサービスの IP アドレスをハードコードします。この方法はシンプルで簡単ですが、構成を手動で更新する必要があります。サービス ディスカバリは、Consul や Etcd などのサービス登録およびディスカバリ ツールを使用して、サービスの IP アドレスを動的に取得することです。このアプローチはより柔軟で自動化されていますが、追加の展開とメンテナンスが必要です。どの方法を選択する場合でも、gRPC が正常に動作するように、サービスの IP アドレスを取得するための対応するロジックをクライアント コードに実装する必要があります。
Google Cloud Platformのマイクロサービスデモから始めました。サービスがコンテナにデプロイされているときに grpc スタブがどのように機能するか興味があります。
私が理解している限り、特定のサービスのコンテナは、yaml 構成ファイルで指定されたサービス IP によってアドレス指定されます。それでは、サービスの grpc サーバーはサービス IP をリッスンする必要がありますか?しかし、次のコードスニペットを見つけました:
リーリーサーバーが IP のないアドレスをどのようにリッスンするのか知りたいですか?
:{ポート}
は「IPのないアドレス」ではありません。
Listen のドキュメントには、「アドレス パラメーターのホストが空であるか、リテラルの未指定 IP アドレスの場合、Listen はローカル システム上で使用可能なすべてのユニキャストおよびエニーキャスト IP アドレスをリッスンします。」と記載されています。
したがって、この場合、ホスト アドレスがない場合、有効なアドレスは 0.0.0.0
となり、これはすべてのインターフェイスに対応します。必然的に、コンテナーを使用するときによくある間違いは、コードを localhost
(127.0.0.1
) にバインドして、コンテナーの外部からそのコードにアクセスできなくなることです。
0.0.0.0
の使用は、アドレス バインディングをコンテナ ランタイムに効果的に委任するため、特にコンテナを使用する場合に一般的な (良い) プラクティスです。
したがって、アプリケーションはコンテナ内のすべてのインターフェイスの {port}
で実行されます。次に、コンテナー ランタイムは、これらのインターフェイスの 1 つ以上をホストのインターフェイスと、たとえば、クライアント コードはホストの IP アドレスに接続します。
コンテナが Kubernetes によって管理されている場合、Kubernetes はアプリケーションを実行しているコンテナに IP アドレスを割り当てます。これらのコンテナは通常、Kubernetes サービス リソースを使用して他のサービスに公開されます。Kubernetes サービス リソースには IP アドレスだけでなく、クラスタ DNS も含まれます。
として定義した
{port} インターフェイス上のコンテナ ランタイムからのトラフィックを受け入れます。
以上がgRPC はどのようにしてマイクロサービスのサービス IP アドレスを知るのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。