サービス検出は、動的な運用と保守において、サービス アドレスの適時性を継続的に維持するにはどうすればよいでしょうか。

リモート サービスの多様性により、「サービス検出」の概念に対する二重の理解が生まれます。まず、UDDI に代表される「百科事典的」なサービス検出があります。このアプローチは、サービス プロバイダーのビジネス コンテキスト (ビジネス エンティティ、連絡先情報、カテゴリ ディレクトリなど) から特定のサービス プログラム インターフェイスの詳細 (メソッド名、パラメーター、戻り値、技術仕様など) まで、マクロからミクロまでの情報レベルを提供します。サービス検出時の幅広い情報ニーズをカバーします。

一方、DNS に似た「家番号スタイル」のサービス検出も見られます。このアプローチは、サービス プロバイダーの完全修飾名を実際のホスト IP アドレスに変換することに重点が置かれています。このタイプのサービス検出では、サービスの特定のプロバイダーやそのプロバイダーが提供するメソッドの詳細を詳しく調べるのではなく、サービス コンシューマーがすでにこの情報を持っていることを前提としています。ここで、サービスロケーション情報は、「完全修飾名 + ポート番号」の形式に簡略化されます。

しかし、マイクロサービスの人気が高まるにつれて、通常のオンラインおよびオフライン操作だけでなく、異常なサービスのシャットダウンと再起動も頻繁に発生するようになりました。 DNS サーバーやロード バランサーなどのインフラストラクチャだけでは、ますます過負荷になり、サービスの変更のペースに追いつけなくなっています。

分散システムの複雑さが増すにつれて、サービス検出が重大な問題となり、新しいソリューションの探索が求められます。分散キー値ストレージ フレームワークである ZooKeeper は、かつてはサービス登録と検出の問題を解決するための人気のツールでした。これは、マイクロサービスの初期、特にリモート サービス検出の分野で主流でした。ただし、ZooKeeper は低レベルの分散ツールであるため、開発者はサービス検出の特定のニーズを満たすために多くの作業を費やす必要があります。

2014年、Netflix内での長期にわたる実践的なテストを経て、サービス検出専用に設計されたツールであるEurekaがオープンソースとして発表されました。 Eureka のオープンソース ステータスは、その成熟度と信頼性を示すだけでなく、後に Spring Cloud に組み込まれたため、リモート サービス検出における Java 開発者の推奨ソリューションとなり、サービス登録の作業負荷が大幅に軽減されました。

2018 年に Spring Cloud Eureka がメンテナンス モードに入ると、Consul と Nacos という 2 つの新しいサービス検出フレームワークが急速に登場し、Eureka からバトンを引き継ぎました。これらの最新のサービス検出フレームワークの開発は非常に成熟しています。これらは、DNS または HTTP を介したアドレス変換をサポートするだけでなく、サービス ヘルス チェック、集中構成管理、キー値ストレージ、データ センター間のデータ同期などのさまざまな高度な機能も提供し、アプリケーション レベルのサービス検出の頂点を極めます。

クラウドネイティブ時代の到来により、インフラストラクチャの柔軟性が大幅に向上し、インフラストラクチャ自体を使用して透過的なサービス検出を実現することに再び注目が集まり始めました。現在、インフラストラクチャおよびネットワーク プロトコル レベルでアプリケーションにほとんど気づかれない便利なサービス検出を実現する方法の探求が、主な研究方向になっています。

サービス検出では、登録、保守、検出という3つの主要な機能上の問題を解決する必要があります。

サービス検出プロセスには、サービス登録、サービス保守、サービス検出という 3 つの主要なリンクが含まれます。各リンクは、システムの効率的な運用を維持するために重要です。

サービス登録

サービス登録は、サービス検出メカニズムの最初のステップです。サービスが起動すると、何らかの方法 (たとえば、API 呼び出し、イベント メッセージの公開、ZooKeeper または Etcd での場所の記録、データベースへの情報の保存など) で、座標情報をサービス レジストリに登録する必要があります。このプロセスは、特定のアノテーションまたは構成 (Spring Cloud の @EnableDiscoveryClient アノテーションなど) を通じてアプリケーション自体で実行することも、コンテナー管理フレームワーク (Kubernetes など) によって自動的に処理することもできます。

サービスメンテナンス

サービスメンテナンスにより、サービスリストが正確かつ最新の状態に保たれます。多くのサービス検出フレームワークはサービスをシャットダウンするためのメカニズムを提供していますが、すべてのサービスが正常にシャットダウンされることが保証されるわけではなく、障害やネットワークの問題により突然中断される可能性があります。したがって、サービス検出フレームワークは、さまざまな手段 (HTTP、TCP プロトコル、長時間接続、ハートビート検出、プローブ、プロセス ステータス監視など) を通じてサービスの健全性を自動的に監視し、アクセスできないサービス アドレスが消費者に提供されないように、健全でないサービスを自動的にオフラインにする必要があります。

サービス検出

サービス検出とは、消費者がサービスの実際の座標に関する情報を照会して取得するプロセスを指します。これは通常、HTTP API リクエストまたは DNS ルックアップ操作を通じて行われ、消費者はサービス識別子 (Eureka の ServiceID、Nacos のサービス名、または汎用 FQDN など) を通じてサービスの特定のアドレスを見つけることができます。ここではコア機能に重点が置かれていますが、多くのサービス検出フレームワークでは、負荷分散、トラフィック管理、キー値ストレージ、メタデータ管理、ビジネス グループ化など、サービス検出のパワーと柔軟性をさらに強化するさまざまな追加機能も提供されています。

サービス検出が CAP にそれほど関心を持ち、敏感なのはなぜでしょうか?

概念モデルでは、サービス センターの位置付けは次のとおりです。プロバイダーはサービス検出で実際の座標を登録、更新、オフライン化し、コンシューマーは特定のシンボルに基づいてサービス検出から実際の座標を取得します。それらはすべて、システム内で同等のマイクロサービスと見なすことができます。この概念モデル図を見てみましょう。

サービス検出は、すべてのサービスが相互に通信するための基礎となるため、システム内で他のサービスとは異なる役割を果たします。構成センターと同様に、ほぼすべてのサービスがサービス検出に依存しているため、サービス検出は非常に重要になっています。サービスで問題が発見されると、システム全体に影響が及びます。したがって、サービス検出が安定していて信頼できることを保証し、起こり得る問題を防ぐために技術的に準備しておくことが非常に重要です。

したがって、分散システムでは、サービス レジストリは通常、小さな内部クラスターとして展開され、高可用性を確保するために 3 つまたは 5 つのノード (通常は最大 7 つで、それ以上はログ レプリケーションのオーバーヘッドが高くなりすぎるため、通常はそれ以上にはなりません) が提供されます。以下の例をご覧ください。

上で挙げた最も代表的な Eureka と Consul を例に挙げてみましょう。

分散システムの設計では、データの一貫性とシステムの可用性のトレードオフが議論の中心となることが多く、CAP 理論では、一貫性と可用性という 2 つの選択肢にまとめられ、さらにパーティション耐性も考慮されます。 2 つのサービス検出ツールである Consul と Eureka は、異なる設計選択の良い例です。

領事のCPオリエンテーション

Consul は、一貫性を重視したプロトコルである Raft プロトコルを使用します。 Consul の設計では、サービスの登録または変更は、大多数のノードが書き込み操作を確認した場合にのみ確認されます。このアプローチにより、可用性が多少犠牲になる場合でも、クラスター外部から読み取られたサービス検出情報が常に一貫していることが保証されます。極端なケースでは、大多数のノードからの確認が得られない場合、サービス更新操作がブロックされる可能性があります。この設計により、Consul は CAP 理論の CP モデルに属するシステムの一貫性とパーティション耐性を優先します。

ユーレカ AP オリエンテーション

Consul とは異なり、Eureka はシステムの可用性を確保するように設計されています。ノードは非同期レプリケーションを通じてサービス登録情報を交換します。つまり、他のノードに情報が複製されるのを待たずに、サービス登録または変更を現在のノードにすぐに反映できます。この設計によりシステムの応答性と可用性が向上し、一部のノードが利用できない場合でもサービス登録と検出が継続して機能できるようになりますが、一貫性が犠牲になり、異なるノード間の情報が一時的に不整合になる可能性があります。このように、Eureka はシステムの可用性とパーティション耐性を優先します。これは、CAP 理論の AP モデルと一致しています。

マイクロサービス アーキテクチャにおける重要な設計原則は、「サービスによるコンポーネント化」です。マイクロサービスでは、「ライブラリ」ではなく「サービス」を通じてコン​​ポーネントを構築することに重点が置かれています。これは、2 つが非常に異なるためです。ライブラリはコンパイル時にプログラムに静的にリンクされ、ローカル呼び出しを通じて関数を提供します。サービスはプロセス外コンポーネントであり、リモート呼び出しを通じて機能を提供します。