サービス検出メカニズムとサービス登録センター

著者: 禅とコンピュータープログラミングの芸術

1 はじめに

Service Discovery と Service Registry はマイクロサービスアーキテクチャの重要な部分であり、サービス情報を一元管理し、サービスカタログを提供することで、各マイクロサービスが相互に検出して呼び出し、クロスサービスコミュニケーションを実現します。この記事では、まずサービス検出メカニズムとその基本概念を簡単に紹介し、次にサービス検出の 2 つの実装方法である静的構成と動的監視について詳しく説明します。次に、主にサービス登録センターの機能と役割を紹介し、サービス登録、キャンセル、サブスクリプション、フィードバックなどを含むいくつかの重要な問題を提起します。最後に、サービス登録センターのいくつかの課題と対策について説明します。この記事の紹介を通じて、読者がマイクロサービスアーキテクチャにおけるサービスディスカバリメカニズムとサービス登録センターの役割をより深く理解し、実際の開発においてサービスガバナンスを実現するために適切なサービスディスカバリソリューションとサービス登録センターソリューションを選択する方法を習得できることを願っています。サービス検出のための高可用性。

2. 基本的な概念と用語の説明

2.1 サービス検出メカニズム

サービス検出メカニズムは、分散システムでネットワークサービスの場所を見つけるために使用されるテクノロジです。これにより、分散クライアントアプリケーションは、サービス名またはその他の位置情報に基づいて特定のネットワークサービスエンドポイントを見つけることができます。

2.1.1 サービス検出モード

クライアント/サーバーモードクライアント/サーバーモードでは、サービス検出メカニズムは登録サーバーまたはセントラルノードに依存します。このノードは完全なサービスリストを保存します。クライアントが特定のサービスを要求する必要がある場合、クライアントはノードに要求を送信します。サービスリストを取得し、呼び出す対応するサービスを選択します。このモデルの利点はシンプルで使いやすいことですが、欠点は、中央ノードがダウンするとシステム全体が使用できなくなる可能性があることです。
DNS モード DNS モードでは、サービス検出メカニズムは DNS プロトコルを使用してドメイン名を解決し、サービスアドレスを取得します。DNS ドメイン名の解決は、通常、ローカルドメインネームサーバーによって完了します。サービス検出メカニズムを通じて、サービスアドレスをローカル DNS サーバーに記録し、クライアントアプリケーションによる直接解決を行うことができます。このモデルの利点は、集中度が低く、サービスプロバイダーが独自にサービスの IP アドレスを選択できることですが、欠点は、解決速度が遅く、DNS サーバーに依存することです。
API モード API モードはパブリッシュ/サブスクライブモデルを採用しています。クライアントアプリケーションは、関心のあるサービスについてサービス登録センターにサブスクライブします。登録センターがサブスクリプションを受信すると、登録されているすべてのクライアントアプリケーションに通知され、クライアントアプリケーションはアクティブに接続できるようになります。プロバイダーがサービス呼び出しを行います。このモデルの利点は、DNS 解決に依存する必要がなく、便利で高速に使用できることですが、欠点は、集中管理がなく、通知メカニズムを自分で実装する必要があることです。
2.2 サービス登録センター
サービスディレクトリとも呼ばれるサービスレジストリは、分散システム内の独立したコンポーネントであり、サービス情報を保存および管理し、地域、環境、組織、さらには事業分野に基づいたサービス検索機能を提供するために使用されます。サービス登録センターはマイクロサービスアーキテクチャにおけるインフラストラクチャ層であり、すべてのマイクロサービスはサービス登録センターに登録され、起動時に独自のサービス情報をセンターに登録する必要があります。
2.3 CAPの原則
CAP 原則 (一貫性、可用性、パーティショントレランス) は、分散コンピューティングシステムの理論を指します。これは、一貫性 (一貫性)、可用性 (可用性)、およびパーティションフォールトトレランス (パーティショントレランス) を同時に満たす必要があることを意味します。システムの堅牢性。
C: 一貫性
一貫性とは、データが正常に更新された後、複数のプロセスまたはスレッドによって同時に読み取られたデータが同じであることを意味します。通常、一貫性はシステム設計の最初から考慮する必要があります。データの一貫性を維持するために、システムは多くの場合、強い一貫性を採用しますが、このアプローチではパフォーマンスが犠牲になるため、弱い一貫性が採用されます。
A：可用性
可用性は、システムがサービスを提供し続ける時間の割合を表します。システムに障害が発生しても、影響を受けるのは少数のユーザーのみであり、深刻な影響はありません。可用性を確保するには、通常、システムに冗長フォールトトレランスが必要です。つまり、特定の特殊な状況下でもシステムが正常に動作できるようにする必要があります。
P: パーティションフォールトトレランス
パーティショントレランスは、パーティション障害が発生したときの分散システムの動作を記述します。パーティションの耐障害性には 2 つの側面があり、1 つはシステムが外部に対して同時に十分なサービスを提供できること、もう 1 つはパーティション間の通信が異常な場合でもシステムが動作し続けることができることです。パーティションのフォールトトレランスを実現するには、通常、データを別のマシンにコピーする必要がありますが、このアプローチではさらに複雑さも生じます。

3. 静的構成と動的モニタリング

3.1 静的構成

静的構成とは、以下の図に示すように、構成ファイルにサービスアドレスを書き込むことを意味します: この方法は比較的単純で粗雑です。単純なシナリオではうまく機能しますが、多数のマイクロサービスの場合、構成が面倒で、変更が難しくなります。他の質問には当てはまりません。

3.2 動的モニタリング

動的監視では、次の図に示すように、起動時に指定されたレジストリが自動的にスキャンされ、サービスアドレスがローカルルーティングテーブルに動的に追加されます: この方法はより柔軟であり、操作中にいつでもサービスを追加、削除、および変更できます。システムを再起動します。

4. サービス登録センター

サービス登録センターは、サービスの登録、サブスクリプション、およびクエリを担当します。サービス登録プロセスには、サービスプロバイダーが、サービスプロバイダー識別子とサービスインスタンスのメタデータ (IP アドレス、ポート番号、サービス名など) をキーとして、提供するサービス情報をサービス登録センターに書き込むことが含まれます。 ) を値として保存します。

サービス加入プロセスには、指定されたサービスに加入するクライアントアプリケーション、サービスリストを返す登録センターが含まれており、クライアントアプリケーションは呼び出すサービスの 1 つを選択できます。

サービスクエリプロセスには、サービス名を通じてサービスをクエリするクライアントアプリケーション、対応するサービスのメタデータを返す登録センター、およびこれらのメタデータを通じてサービス呼び出しを行うクライアントアプリケーションが含まれます。

サービスのライフサイクルの管理に加えて、サービス登録センターは、サービスの検出をより便利、迅速、信頼性の高いものにするために、優れたスケーラビリティ、堅牢性、高可用性も備えている必要があります。

サービス登録センターの機能を例を挙げて見てみましょう。

4.1 サービス登録

新しいサービスがオンラインになると、まずサービス登録インターフェイスを通じてそのメタデータをサービス登録センターに報告する必要があります。サービス登録インターフェイスは通常、HTTP や gRPC などのプロトコルをサポートし、クライアントからの登録要求を受け入れます。サービス登録センターは、登録要求を受信すると、まずクライアントが他のサービスに登録されているかどうかを確認し、登録されている場合には、以前のサービス情報をクリアしてから、新しいサービス情報を保存します。

たとえば、クライアント A がサービス foo を登録し、リクエストパラメーターは次のとおりです。

{
    "serviceName": "foo",
    "host": "localhost",
    "port": 8080
}

リクエストを受信したサービス登録センターは、クライアント A が他のサービスに既に登録しているかどうかを確認し、既に他のサービスに登録している場合は、以前のサービス情報をクリアします。次に、クライアント A によって登録された foo サービスの情報 (serviceName、host、port などの情報を含む) をサービス登録センターのストレージ領域に書き込みます。

4.2 サービスのログアウト

サービスがオフラインになると、まずサービス登録センターに提供するサービスからログアウトする必要があります。クライアントはログアウト要求をアクティブに開始する必要があり、要求パラメータには serviceName が含まれます。リクエストを受信した後、サービス登録センターはサービスに保存されているメタデータを削除します。

4.3 サービスの購読

クライアントは、サービスサブスクリプションインターフェイスを通じてサービスにサブスクライブします。サービスサブスクリプションインターフェイスは、HTTP や gRPC などのプロトコルをサポートし、クライアントからのサブスクリプション要求を受け入れます。クライアントがサブスクリプション要求を開始すると、次のようなサブスクライブするサービス名が渡されます。

["foo"]

サービス登録センターはサブスクリプション要求を受信すると、次のようなサービスのすべてのインスタンスのメタデータを返します。

[
  {
    "id": "[email protected]:8080",
    "serviceName": "foo",
    "host": "127.0.0.1",
    "port": 8080
  }
]

クライアント A は、サービスサブスクリプション応答を受信した後、呼び出すサービスの 1 つを選択できます。

4.4 サービスのフィードバック

クライアントは、サービスフィードバックインターフェイスを通じて、サービスの可用性ステータスをサービス登録センターにフィードバックできます。クライアントからフィードバックされたサービス可用性ステータスを受信した後、サービス登録センターは、対応するメタデータの可用性ステータスを更新できます。

5. サービス登録センターの課題と対策

5.1 データの一貫性

サービスメタデータをサービスレジストリに保存するときは、データの整合性を考慮する必要があります。サービス登録センターは通常、分散トランザクション処理テクノロジーを使用して、サービスメタデータの強力な一貫性を確保します。ただし、ネットワークの理由、ハードウェア障害、ソフトウェアエラー、その他の要因によって引き起こされる不安定性を完全に回避することはできないため、サービス登録センター内の異なるノード間でデータの不一致が依然として発生する可能性があります。

データの一貫性の問題を解決するには、サービス登録センターを設計するときに、メッセージキューやデータベーストランザクションを使用して強力なデータの一貫性を確保するなど、サービスのメタデータに対して明確な制約を設ける必要があります。さらに、サービス登録センターはキャッシュ層を導入してデータベースへのアクセス頻度を減らすこともでき、それによってシステム全体のパフォーマンスが向上します。

5.2 可用性

サービスレジストリは独立したコンポーネントであるため、その可用性がマイクロサービスアーキテクチャ全体の可用性を直接決定します。したがって、サービス登録センターは高可用性を確保する必要があります。そうしないと、マイクロサービスアーキテクチャの麻痺につながります。

サービス登録センターの場合、高可用性を確保するには通常、次の方法が必要です。

サービス登録センターのクラスター展開。それぞれ異なる容量とトラフィック量を持つ複数のサービス登録センターノードを展開して、サービス登録センターの高可用性を確保します。
メッセージキューまたは MySQL データベースクラスターを使用してサービスメタデータを保存します。これらのクラスターは、高可用性を確保するために、専任の運用および保守チームによって保守されています。
サービス登録センターとクライアント間のネットワーク伝送には、非同期かつノンブロッキング方式が採用されています。非同期ノンブロッキングネットワーク送信を使用すると、クライアントの遅延やネットワークの輻輳によって引き起こされるサービス検出タイムアウトを効果的に防止し、サービス登録センターの高可用性を確保できます。
サービス登録センターにサービス正常性検出メカニズムを実装します。サービスに障害が発生すると、登録センターは対応するサービス情報を即座に更新し、他のサービスが障害を迅速に特定してリソースを再割り当てできるようにします。
サービス登録センターの監視機能を提供し、管理者によるシステムの稼働状況の把握、異常の予兆・回避、システムの信頼性向上を実現します。

上記の方法により、サービス登録センターの可用性を効果的に向上させることができます。

5.3 分散型コンセンサスアルゴリズム

サービスレジストリを実装するときは、サービスメタデータの分散一貫性を考慮する必要があります。最も一般的に使用される分散コンセンサスアルゴリズムは、Paxos アルゴリズムと Raft アルゴリズムです。

Paxos アルゴリズムは、分散システムの調整と一貫性の問題を解決するためのソリューションであり、メッセージパッシングに基づくコンセンサスアルゴリズムです。Paxos アルゴリズムは主に、複数のノード間で値またはログに関する決定をどのように実行するかという問題を解決するために使用されます。実際のエンジニアリングアプリケーションでは、Paxos アルゴリズムは単一意思決定タイプと多値意思決定タイプの 2 つのカテゴリに分類できます。

単一のデシジョンクラスは、マスターノードの選出など、サービス登録センターの選出シナリオで使用できます。このシナリオにおける典型的な問題は、分散ロックです。複数値の意思決定シナリオには、Raft アルゴリズムに基づく分散ログレプリケーション、共有リースなどが含まれます。

どちらの分散コンセンサスアルゴリズムにも長所と短所があります。Paxos アルゴリズムは強力な正確性を備えており、効率を犠牲にすることなくデータの強力な一貫性を保証できます。ただし、Paxos アルゴリズムの実装は複雑で、特にスケーラビリティとセキュリティの点で多くの詳細を考慮する必要があります。

Raft アルゴリズムは比較的シンプルで実装が簡単です。これは、多くのオープンソースフレームワークやソフトウェアで見られる、非常に古典的な分散コンセンサスアルゴリズムです。ただし、Raft アルゴリズムは Paxos のようなアトミックコミットプロトコルではないため、その可用性と一貫性は Paxos に匹敵しません。したがって、実際のエンジニアリングアプリケーションでは、実際のニーズに基づいて適切な分散コンセンサスアルゴリズムを選択する必要があります。