web-dev-qa-db-ja.com

サービスディスカバリーとは何ですか、なぜそれが必要なのですか？

私が知る限り、「サービスの発見」とは、クライアントが接続したいサーバー（またはサーバーのクラスター）を見つける方法を意味します。

HTTPやAMQPなどのプロトコルを使用して、他のバックエンドプロセスと通信するWebアプリケーションを構築しました。これらでは、各クライアントには、ホスト名またはサーバーへの接続に必要な情報を含む構成ファイルがあり、Ansibleなどの構成ツールを使用して展開時に設定されます。それは簡単で、かなりうまくいくようです。

サービス検出は、サーバー情報をクライアントの構成ファイルに入れるだけの代替手段ですか？もしそうなら、なぜそれは良いですか？そうでない場合、それはどのような問題を解決しますか？

web-servicesconfigurationarchitecturemicroservices
26
gesgsklw

サービス発見とは何かを確認することから始めましょう-ここに良い説明があります： https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/ （このリンクは尋ねられた問題をかなり明確にします）

そして、これが実際にどのように使用されるかの例を示します：サービスAによって使用されるサービスBがあるとします。サービスB（ [〜＃〜] soa [〜＃〜] のほとんどのサービスと同様）実際には、タイプBのアプリケーションのクラスターです。サービスAはクラスターBのノードの1つを使用する必要がありますが、Bノードのクラスターはdynamicです。つまり、Bサービス全体の負荷に応じて、Bノードが作成および終了されます。ここで、サービスAがサービスBを使用する必要があるたびにライブBノードと通信するようにします。そうするために、サービス検出ツールを使用して提供します任意の時点で、ライブBノードのいずれかのアドレス。

したがって、上記の質問に答えようとして、サービスAの起動時に読み込まれる構成ファイルに静的な構成としてエンドポイントサーバー情報（具体的にはエンドポイントアドレス）を入れても、dynamicsサービスBエンドポイントが絶えず変化する場合があります。

25
S. D.

クラウドサーバーアーキテクチャは、単一の大きなモノリスから移行するWebアプリケーションの構築方法を、マイクロサービスと呼ばれる個別に展開可能な小さなサービスに分割して、大きなアプリケーションを形成する方法を変えています。

サービスが他のサービスと通信する場合のシナリオを考えてみましょう。たとえば、サービスAがサービスBと通信する必要があるとします。 Service-Aは、Service-BのIPアドレスとポート番号を知る必要があります。この問題に対する最も簡単な解決策は、Service-AでService-BへのIPアドレスとポートを保持する構成ファイルを維持することです。このアプローチにはいくつかの短所があります

次の状況を考慮してください。-

  • アプリケーション内のマイクロサービスの数が増加した場合
    • 構成ファイルで管理するのは難しい
    • 管理ミスが発生するとエラーが発生しやすくなります
    • 後でIPまたはポートを変更する柔軟性に欠ける
    • クラウドの機能を利用して、要件に基づいて動的にスケーリングまたは縮小することはできません。

この単純なアプローチはあまりにも静的であり、クラウドをフリーズします新しいソリューションが登場します

代替ソリューション：サービス検出

サービス発見は、方法を提供することにより、上記の問題を解決するのに役立ちます

  • サービスを登録するには、つまり、新しいサービスがオンラインになったときに、IPとポートを使用してサービス検出サービスに登録します
  • サービスが他のサービスを見つけるのを助けます。つまり、サービスAがサービスBを見つけるのを助けます。
  • インスタンスの健全性をチェックし、健全でない場合は削除する健全性チェック。
  • サービスがオフラインになったときに登録を解除します。

したがって、クラウドの全機能を利用して、要件に基づいて動的にスケーリングおよび縮小し、アーキテクチャを相互に疎結合することもできます。

4
Samuel J Mathew

あなたが言った方法は実行可能であることを認めざるを得ませんが、非常に多くのサービスがある場合、管理する必要がある複雑さが増し、サービスリストを手動で設定することも非常にエラーを起こしやすくなります。

サービス検出は、呼び出されるサービスのリストをクライアント構成に入れる簡単な方法ではなく、すべてのサービス自体のインスタンスのリストを保存する方法です。

アクセスするサービスインスタンスのリストを自動的に管理できる登録サービスがあることを簡単に理解できます。サービスを追加するか、サービスを閉じると、登録サービスは自動的にサービスリストを更新します。電話をかけると、登録センターから最新のサービスリストを入手して電話をかけます。パフォーマンスに影響を与えないように、クライアントでサービスリストをキャッシュすることもできます

2
lixinglin

AとBのように2つのマイクロサービスがあり、AがBと通信するようにしたい場合、Aはサービス検出方法（ツール）を使用してマイクロサービスアーキテクチャでBを見つけます。

クライアントからサーバーへの通信だけでなく、同じサーバーで実行される可能性のある2つのマイクロサービスもあります。

それが解決する問題は、クラスター内の2つの異なるノードで実行されている2つのマイクロサービスが、サービスを検出せずに互いに検出できることです。これは不可能でした。

KurbernetesがcoreDNSを使用してDNS経由でサービス検出をサポートする方法を確認できます。 https://kubernetes.io/docs/concepts/services-networking/service/

2
Margach Chris