次の方法で共有


マイクロサービスのアドレス指定可能性とサービス レジストリ

ヒント

このコンテンツは、.NET Docs で入手できる、またはオフラインで読み取ることができる無料のダウンロード可能な PDF として入手できる、コンテナー化された .NET アプリケーションの電子ブックである .NET マイクロサービス アーキテクチャからの抜粋です。

コンテナー化された .NET アプリケーションの .NET マイクロサービス アーキテクチャの電子ブックの表紙サムネイル。

各マイクロサービスには、その場所の解決に使用される一意の名前 (URL) があります。 マイクロサービスは、実行される場所に関係なく、アドレス指定できるものでなければなりません。 特定のマイクロサービスを実行しているコンピューターについて考える必要がある場合は、すぐに問題が起きる可能性があります。 DNS が特定のコンピューターへの URL を解決するのと同じ方法で、マイクロサービスは現在の場所を検出できるように一意の名前を持つ必要があります。 マイクロサービスには、実行されているインフラストラクチャから独立したアドレス指定可能な名前が必要です。 このアプローチは、サービスレジストリが必要であるため、サービスのデプロイ方法と検出方法の間に相互作用があることを意味 します。 同じ静脈では、コンピューターで障害が発生した場合、レジストリ サービスは、サービスが現在実行されている場所を示すことができる必要があります。

サービス レジストリ パターンは、サービス検出の重要な部分です。 レジストリは、サービス インスタンスのネットワークの場所を含むデータベースです。 サービス レジストリは高可用性で、up-to-date である必要があります。 クライアントは、サービス レジストリから取得したネットワークの場所をキャッシュできます。 ただし、その情報は最終的に古くなり、クライアントはサービス インスタンスを検出できなくなります。 そのため、サービス レジストリは、一貫性を維持するためにレプリケーション プロトコルを使用するサーバーのクラスターで構成されます。

一部のマイクロサービス デプロイ環境 (後のセクションで説明するクラスターと呼ばれます) では、サービス検出が組み込まれています。 たとえば、Azure Kubernetes Service (AKS) 環境では、サービス インスタンスの登録と登録解除を処理できます。 また、サーバー側探索ルーターの役割を果たす各クラスター ホストでプロキシを実行します。

その他のリソース