レジストリ: 分散システムへの対応方法

サービス検出の概念は、実際には私たちのプロジェクトで長い間使用されてきましたが、あまり注目されていないかもしれません。 Nginx を例に挙げてみましょう。このよく知られたリバース プロキシ コンポーネントのコア機能の 1 つは、サービス検出メカニズムに依存しています。具体的には、トラフィックをアプリケーション サーバーに正しく転送するには、まず Nginx がこれらのサーバーの特定のアドレスを認識する必要があります。このプロセスは実際にはサービス検出です。

Nginx 実装では、構成ファイルでアプリケーション サーバーのアドレスを詳細に構成することでこれを実現します。この方法は単純かつ直接的ですが、サービス検出の概念の基本的な形式も示しています。

確かに、クライアント コードで RPC サーバー アドレスを直接構成することは、サービスを検出するためのシンプルで簡単な方法ですが、ご存じのとおり、この方法では実際の操作で複数の問題が発生します。これらの問題とその解決策を一つずつ見ていきましょう。

まず、緊急拡大によってもたらされた課題についてです。業務のピーク時や緊急事態が発生した場合、増加した負荷に対応するためにシステムを迅速に拡張する必要がある場合があります。サーバー アドレスがクライアントにハードコードされている場合、拡張ごとにクライアント構成を手動で更新し、クライアント プロセスを再起動する必要があります。これは時間がかかるだけでなく、エラーが発生しやすく、システムの回復力と可用性に影響を与えます。

2 番目は、サーバー障害の処理です。分散環境では、さまざまな理由によりサーバーが突然クラッシュする可能性があります。サービス アドレスが静的に構成されている場合、サーバーに障害が発生すると、手動で構成を変更し、すべてのクライアントを再起動して、障害が発生したノードを排除する必要があります。これでは、自動回復はおろか、迅速な対応も明らかに実現できません。

最後に、サーバーがオンラインおよびオフラインになるときのトラフィック管理の問題があります。サーバーの再起動やメンテナンスが必要な場合、静的構成方法ではスムーズなトラフィック転送を実現できません。クライアントは再起動中のサーバーにリクエストを送信し続けるため、リクエストの遅延や失敗が発生し、ユーザー エクスペリエンスとシステムの安定性に影響を及ぼします。

上記の問題を解決するために、登録センターの導入はより先進的でダイナミックなソリューションとなっています。登録センターを使用すると、サーバーは起動時にアドレス情報を登録センターに登録し、クライアントは登録センターからサービス アドレスを動的に照会します。このメカニズムには、いくつかの重要な利点があります。

動的なサービス検出と負荷分散: クライアントはサーバーの最新のアドレス情報をリアルタイムで取得し、手動介入なしで負荷分散とフェイルオーバーを実現できます。

迅速な容量拡張と障害回復: サーバーのオンラインおよびオフライン ステータスはクライアントに対して透過的であり、容量拡張要件やサービス障害に迅速に対応できるため、システムの可用性が向上します。

スムーズなオンラインとオフライン: 登録センターは、サービス トラフィックをより柔軟に管理し、スムーズなオンラインとオフラインのサービスを実現し、サービスの再起動によるリクエストの失敗を回避できます。

業界には、旧式の ZooKeeper、Kubernetes で使用される ETCD、Alibaba のマイクロサービス登録センター Nacos、Spring Cloud の Eureka など、選択可能な登録センター コンポーネントが多数あります。

写真

サービスステータスの管理方法

サービス登録および検出メカニズムを使用する場合、サーバーは起動時に登録センターに登録し、クライアントは通信のために登録センターを通じてサーバーを見つけます。このように、サービス ノードの追加または削減はクライアントに対して透過的になり、管理が簡素化されます。サービスをスムーズにシャットダウンし、リクエストの処理の失敗を回避するために、サーバーはシャットダウンする前にまず登録センターから登録を解除し、新しいリクエストの受信を停止します。

ただし、突然の停電などによりサーバーが異常終了した場合は、正常にログアウトできず、クライアントは無効なサービスに接続しようとしてエラーが発生します。解決策の 1 つは、登録センターがサーバーがアクセス可能かどうかを定期的に確認し、アクセスできない場合はサービス リストから削除することです。この方法は初期段階では非常に有用ですが、問題もあります。たとえば、検査のために特定のポートを開く必要があり、ポートの競合が発生する可能性があります。サーバーの数が多いと、検査にも多くのリソースが消費され、一定の遅延が発生します。したがって、この方法はサーバーの異常終了の問題を解決できますが、実際の状況に応じて調整および最適化する必要があります。

そのため、後でハートビートモードに変更しました。

登録センターはハートビート メカニズムを使用して、RPC サーバーが稼働しているかどうかを検出します。登録後、サービス ノードは定期的に (たとえば 30 秒ごとに) 登録センターにハートビート パケットを送信します。登録センターはハートビートを受信すると、ノードの更新時間を更新します。ノードが指定された時間内 (90 秒など) にハートビートを送信しない場合、レジストリはそのノードを利用不可としてマークします。このメカニズムはアクティブ検出よりも効率的で、適用範囲も広くなっていますが、登録センターが重要になり、障害やバグが発生するとサービス クラスター全体に影響が及ぶ可能性があります。

サービス ガバナンスは、複雑な問題を解決するためにクラスターを構成する複数のサービス ノードを管理するプロセスです。これを都市管理と比較すると、サービス登録と検出は交通の流れを更新することと同じです。新しいサービス ノードを開始することは新しい道路を開設することと似ており、交通 (車両) に新しい走行可能なルートを通知する必要があります。サービス ノードをシャットダウンするには、ルートを回避するための通知が必要です。サービス監視は、交通状況をリアルタイムで観察する道路監視に似ています。回路遮断と迂回は、道路混雑時の一時的な閉鎖と交通規制に相当します。分散追跡は交通事故を調査するためのフルリンク分析です。負荷分散は交通警官のようなもので、特定の時間にどのルートの方が障害物が少ないかを案内します。このプロセス全体は、サービス クラスター (都市) の効率的かつ円滑な機能の確保を目的としています。