1. 序章

マイクロサービスを扱う場合、サービスが正確な場所を知らなくても別のサービスを使用できるようにするメカニズムが必要になります。 このチュートリアルでは、サービスディスカバリの概念について説明します。

2. サービスディスカバリとは何ですか？

多かれ少なかれ複雑なアプリケーションを構成するいくつかのマイクロサービスを想像してみましょう。 これらは何らかの形で相互に通信します（例： API Rest 、 gRPC ）。

マイクロサービスベースのアプリケーションは通常、仮想化またはコンテナ化された環境で実行されます。 サービスのインスタンスの数とその場所は動的に変化します。 リクエストがターゲットマイクロサービスに到達できるようにするには、これらのインスタンスがどこにあるか、およびそれらの名前を知る必要があります。 ここで、サービスディスカバリなどの戦術が役立ちます。

サービスディスカバリメカニズムは、各インスタンスがどこにあるかを知るのに役立ちます。 このように、Service Discoveryコンポーネントは、すべてのインスタンスのアドレスが追跡されるレジストリとして機能します。 インスタンスには動的に割り当てられたネットワークパスがあります。 したがって、クライアントがサービスに要求を行う場合は、サービス検出メカニズムを使用する必要があります。

3. サービスディスカバリの必要性

マイクロサービスは、通信するすべてのサービスの場所（IPアドレスとポート）を知る必要があります。サービス検出メカニズムを採用しないと、サービスの場所が結合され、システムの保守が困難になります。 。 従来のアプリケーションでは、場所を配線したり、構成を介してそれらを挿入したりできますが、この種の最新のクラウドベースのアプリケーションではお勧めしません。

アプリケーションサービスの場所を動的に決定することは簡単なことではありません。 サービスの新しいインスタンスを絶えず破壊して配布している環境を考えると、事態はさらに複雑になります。 これは、ピーク負荷に対応するための水平方向の自動スケーリング、または新しいバージョンのリリースのために継続的に変化するクラウドベースのアプリケーションの場合によく当てはまります。 したがって、サービス検出メカニズムの必要性。

4. サービスディスカバリはどのように機能しますか？

Service Discoveryは、2つの部分で処理を行います。 まず、インスタンスが登録して「私はここにいます！」と言うメカニズムを提供します。次に、登録後にサービスを見つける方法を提供します。

これまでに説明した概念を例を挙げて明確にしましょう。サービスコンシューマーとサービスプロバイダー（ REST API を公開するサービス）です。 サービスコンシューマーは、データの読み取りと書き込みを行うためにサービスプロバイダーを必要とします。

次の図は、通信フローを示しています。

 

図に示されている手順を説明しましょう。

  1. サービスプロバイダーの場所は、サービスレジストリ（利用可能なすべてのサービスインスタンスの場所を含むデータベース）に送信されます。
  2. サービスコンシューマーは、サービスディスカバリサーバーにサービスプロバイダーの場所を尋ねます。
  3. サービスプロバイダーの場所は、内部データベースのサービスレジストリによって検索され、サービスコンシューマーに返されます。
  4. サービスコンシューマーは、サービスプロバイダーに直接リクエストできるようになりました。

主なサービス検出パターンには、クライアント側検出とサーバー側検出の2つがあります。 それらを明確にしましょう。

5. サービスディスカバリの実装

5.1. クライアント側のサービスディスカバリ

クライアント側の検出を使用する場合、サービスコンシューマーは、使用可能なサービスインスタンスのネットワークロケーションを決定し、それらの間で要求を負荷分散する責任があります。クライアントはサービスレジスタにクエリを実行します。 次に、クライアントは負荷分散アルゴリズムを使用して、使用可能なサービスインスタンスの1つを選択し、要求を実行します。

次の図は、今説明したパターンを示しています。

 

クライアント側の負荷分散に責任を与えることは、負担であると同時に利点でもあります。 これは、専用のロードバランサーを使用した場合の余分なホップを節約できるという利点があります。 Service Consumerは負荷分散ロジックを実装する必要があるため、これは不利です。

また、サービスコンシューマとサービスレジストリは完全に結合していることも指摘できます。 つまり、クライアント側の検出ロジックは、サービスコンシューマーが使用するプログラミング言語とフレームワークごとに実装する必要があります。

クライアント側の検出を明確にしたので、サーバー側の検出を見てみましょう。

5.2. サーバー側のサービス検出

Service Discoveryの代替アプローチは、サーバー側検出モデルです。これは、ロードバランサーとして機能する仲介者を使用します。クライアントは、オーケストレーターとして機能するロードバランサーを介してサービスに要求を行います。 ロードバランサーはサービスレジストリにクエリを実行し、各リクエストを利用可能なサービスインスタンスにルーティングします。

次の図は、通信がどのように行われるかを示しています。

このアプローチでは、専用のアクターであるロードバランサーがロードバランシングの役割を果たします。 これがこのアプローチの主な利点です。 実際、このレベルの抽象化を作成すると、ルックアップ手順を処理する必要がないため、サービスコンシューマーが軽くなります。実際のところ、言語ごとに個別に検出ロジックを実装する必要はありません。およびサービスコンシューマーが使用するフレームワーク。

一方、ロードバランサーが既に展開環境で提供されていない限り、ロードバランサーをセットアップして管理する必要があります。

検出メカニズムへのさまざまなアプローチについて詳しく説明したので、次に登録メカニズムに移りましょう。

6. サービスレジストリとは何ですか？

これまでのところ、サービスレジストリは各マイクロサービスの場所をすでに知っていると想定してきました。 しかし、この登録および登録解除操作はどのように行われますか？

サービスレジスタは、サービス識別の重要な部分です。 これは、サービスインスタンスのネットワークロケーションを含むデータベースです。サービスレジストリは、高可用性で最新のものである必要があります。 クライアントは、サービスレジストリから取得したネットワークパスをキャッシュできます。 ただし、この情報は最終的には廃止され、クライアントはサービスインスタンスに到達しなくなります。 したがって、サービスレジストリは、レプリケーションプロトコルを使用して整合性を維持するサーバーのクラスタで構成されます。

それをより詳細に見て、2つの可能なアプローチを説明しましょう。

7. サービス登録オプション

7.1. 自己登録

自己登録モデルを使用する場合、サービスインスタンスはサービスレジストリへの登録と登録解除を担当します。さらに、必要に応じて、サービスインスタンスはハートビートリクエストをその登録を存続させてください。 次の図は、このパターンの構造を示しています。

自己登録モデルには、いくつかの長所と短所があります。 1つの利点は、比較的単純であり、仲介者として他のシステムコンポーネントを必要としないことです。 ただし、重大な欠点は、サービスインスタンスをサービスレジストリに結合することです。つまり、使用する各言語とフレームワークで登録コードを実装する必要があります。

サービスをサービスレジストリから切り離す別のアプローチは、サードパーティの登録スキームです。

7.2. サードパーティの登録

サードパーティの登録モデルを使用する場合、サービスインスタンスはサービスレジストリへの登録を担当しません。 代わりに、サービスレジスタと呼ばれる別のシステムコンポーネントが登録を担当します。 サービスレジスタは、展開環境をポーリングするか、イベントをサブスクライブすることにより、実行中のインスタンスへの変更を追跡します。新しく利用可能なサービスインスタンスを検出すると、データベースに記録します。 サービスレジストリは、終了したサービスインスタンスの登録も解除します。 次の図はこれを示しています。

自己登録と同様に、サードパーティの登録スキームにもさまざまな長所と短所があります。 主な利点の1つは、サービスがサービスレジストリから分離されていることです。 プログラミング言語やフレームワークごとにサービス登録ロジックを実装する必要はありません。 代わりに、サービスインスタンスの登録は、専用サービス内で一元的に管理されます。

このモデルの欠点の1つは、展開環境に組み込まれていない限り、セットアップと管理が必要なもう1つの高可用性システムコンポーネントであるということです。

8. 結論

この記事では、マイクロサービスアプリケーションに、動的な変更で実行される複数のサービスインスタンスがどのように含まれるかについて概説します。 これらのインスタンスには動的なネットワークロケーションがあり、通信またはロケーションを特定する方法が必要です。 したがって、クライアントが要求を行うには、サービスディスカバリなどのメカニズムが必要です。

Service Discoveryは、使用可能なサービスインスタンスのデータベースを提供することで役立ち、使用状況に基づいてサービスを検出、登録、および登録解除できます。