プログラマーの精神修養への道 - 分散システムにおける最も重要なハブとなるかもしれない

• 分散システムにレジストリが必要なのはなぜですか?
• 分散システム登録センターの落とし穴は何ですか?
• 分散システム登録センターを実装するには？
• 既製のコンポーネントを使用してレジストリを簡単に実装できますか?

タイトルを見ると、何のための登録センターなのかと疑問に思うかもしれません。現在のアーキテクチャのコンポーネントとして、登録センターは確かに非常に一般的です。分散システムの最も典型的な形式であるマイクロサービスは、近年最も人気のある概念の 1 つとなっています。マイクロサービスに関するすべての記事では、レジストリ センターについて多かれ少なかれ言及されていますが、あくまでも簡単に触れられているだけです。分散システムやマイクロサービスアーキテクチャの最も重要な部分なので、詳しく紹介するには別の記事を書く必要があると思い、それがこの記事の目的でもあります。

分散システムの問題点

アーキテクチャの観点から見ると、登録センターは実際には一般的な概念であり、すべての一般的なマイクロサービスではありません。昔、Nginx が負荷分散 (リバース プロキシ) に使用されていたとき、Nginx は構成ファイルに基づいて構成された戦略に従って、各リクエストを特定のバックエンド ハンドラーに送信していました。このプロセスでは、クライアントの観点から見ると、Nginx はゲートウェイに非常に似ており、バックエンド ハンドラーの観点から見ると、Nginx はサービス管理センターに似ています。サービスを提供できるすべてのバックエンド ハンドラー情報を管理し、特定の手段を使用して、サービスのヘルス チェック、サービスの自動登録と削除、およびその他の操作を実現することもできます。

もちろん、現在はマイクロサービスが普及しており、ゲートウェイと登録センターは 2 つの並行した概念とコンポーネントに分割されています。重要度で言えば、ゲートウェイよりも登録センターの方が重要だと思います。現在、モノリシック サービスを分割することが非常に一般的ですが、ここで強調したいのは、モノリシック サービスを分割する必要があるかどうかは、さまざまな状況に基づいて総合的に検討する必要があるということです。結局のところ、小さなマイクロサービスに分割するにはコストがかかります。

昔は、クライアントが複数のバックエンドサービスをリクエストする必要がある場合、多くの場合、バックエンドサービスの情報は、次のようにリクエスト側の構成ファイルに書き込まれていました。

 {
 「サービスA」 :[
 「http://192.168.100.100」 、
 「http://192.168.100.101」 、
 「http://192.168.100.102」  
    ]
 }

このアプローチは確かに解決策ですが、システムがアップグレードされ続けると、多くの問題が発生します。

• システムがバックエンドサーバーを拡張する必要がある場合、クライアント構成ファイルを手動で変更する必要があり、ほとんどの場合、クライアントプロセスを再起動する必要もあります。
• バックエンド サービス ノードに障害が発生した場合は、クライアント構成ファイル内の対応するノードを手動で削除する必要があり、ほとんどの場合、クライアント プロセスを再起動する必要もあります。
• ノードが追加または削除されるたびに手動による介入が必要になるため、メンテナンス コストが大幅に増加します。

以上の理由から、登録センターが誕生しました。

登録センターの役割

登録センターは、サービス ノードの追加と削除の問題を解決するだけでなく、利用可能なサービス ノードを検索するプロセス全体に変更を加えます。サービスヘルスチェックと組み合わせると自動化できます。業界にはZooKeeper、ETCD、Alibabaのマイクロサービス登録センターNacos、Spring CloudのEurekaなど、多くの登録センターがあります。Cai Caiの以前の記事では、ETCDを使用して構成センターを実装することについて書かれています。

サービス登録の検出

サービス登録と検出は、登録センターが提供する最も基本的で重要な機能です。

• 新しいサービス ノードがオンラインになると、登録センターのインターフェイスを通じて登録できます。サービス ノードに障害が発生すると、登録センターは自動的にそのサービス ノードを削除します。
• 登録センターのサービス ノードが変更されると、発信者にタイムリーに通知され、サービス発信者は利用可能なサービス ノード情報をほぼリアルタイムで更新できます。

負荷分散

クライアントは登録センターから利用可能なサービス ノードを取得すると、ラウンドロビンや重みなどのポリシーに基づいてサービスにアクセスできます。このシナリオでは、登録センターはロード バランサーのようなもので、トラフィックを複数の異なるノードに送信します。

負荷分散なので、ある意味サービスの水平展開も実現できます。正直に言うと、これにはまったく問題はありません。原理は Nginx の負荷分散の原理と似ています。

あの穴

サービス センターは全体的なアーキテクチャ モデルの多くの問題を解決しますが、使用中に発生するいくつかの副作用にも対処する必要があり、これらの副作用がシステム全体のクラッシュを引き起こす原因になることもあります。

データの一貫性の問題

データの一貫性はすべてのシステムが直面しなければならない問題のようですが、登録センターも例外ではありません。ここでの一貫性とは、登録センターに保存されている利用可能なノード データと、バックエンドの実際の利用可能なノード、およびクライアントに保存されている利用可能なノードとの間の差異を指します。たとえば、登録センターが 3 つのサービス ノード ABC の情報を格納しており、ノード A が何らかの理由でオフラインになっている場合、登録センターはノード A を適時に削除し、クライアントにもノード A を削除するように通知する必要があります。

理論的に言えば、上記のプロセスは、登録センターと発信者および着信者との間の相互作用プロセスにまたがり、分散システムにおけるトランザクション問題、すなわち分散トランザクション問題に属します。 Cai Cai の以前の記事で述べたように、分散トランザクションで厳密な一貫性を確保しようとすると、必然的に可用性に影響を及ぼします。

分散環境では一貫性が求められる

さらに、現在主流の登録センター技術の観点から見ると、登録センターと両者間の通信プロセスは非同期プロセスであるため、リアルタイムの取引要件を満たすことができません。

現在、登録センターはクライアントの変更の通知をほぼリアルタイムで実現できますが (実際にはリアルタイムではありません)、バックエンド サービス ノードの可用性をほぼリアルタイムで監視することは困難です。その理由は次のとおりです。まず、ネットワークの信頼性の低さにより、ネットワーク通信障害が次回のネットワーク通信障害を意味するわけではありません。 2 つ目は、バックエンド サービスの可用性を監視する方法がリアルタイムではないことです。現在、バックエンド サービスの可用性を検出する一般的な方法は 2 つあります。

登録センターによる能動的な検出

レジストリ センターの多くのコンポーネントがこのメソッドをサポートしています。この方法では、バックエンドの各サービスが検出可能なインターフェースまたはポートを提供する必要があります。レジストリ センターは、構成に応じて定期的にサービス インターフェイスまたはポートを呼び出します。戻りが正常であれば、サービスは正常に動作しているとみなされます。それ以外の場合、サービスは利用できないものとみなされます。利用できない場合は、レジストリ センターが現在のサービスをリストから積極的に削除し、クライアントに通知します。

この方法は完璧に思えますが、まだ落とし穴があります。

• 検出プロセス中に、登録センターでネットワークの問題によるエラーが発生する可能性がありますが、実際にはサービスは正常に動作しているため、誤判定が発生する可能性があります。もちろん、このような問題の場合、単一の検出結果で急いで判断するのではなく、複数の検出結果で判断するように設定することもできます。
• サービス ノードの数が多い場合、登録センターに重い検出タスクの負荷がかかり、登録センターのパフォーマンスに一定の損失が生じ、その可用性に影響を及ぼします。
• サービスがポートの形で検出インターフェースを開く場合、サービスが多数あるとポートのプリエンプションが発生する可能性があります。結局のところ、これらのサービスは異なるチームによって開発されている可能性があります。

バックエンド サービスのアクティブ ハートビート

登録センターのアクティブ検出モードと比較して、サービスのアクティブハートビート報告モードの方が好みです。ハートビート モードを使用する一般的なプロセスは次のとおりです。

• バックエンドの各サービス ノードは、構成に従って一定の間隔で登録センターにハートビート パケットをアクティブに送信します (この構成は変更できます)。ハートビート パケットの内容はネゴシエートできます。たとえば、一部のシステムは ping コマンドのみを送信しますが、他のシステムは CPU 使用率、メモリ使用率、その他の情報など、より詳細なサービス ステータスを送信します。登録センターは、この情報に基づいて、より正確なトラフィック割り当てを行うことができます。たとえば、リソースが豊富なサービス ノードがより多くのトラフィックを処理できるようになります。
• 登録センターは、サービスノードからハートビートパケットを受信した後、スライディングウィンドウの形式でサービスノードの契約時間（生存時間）を更新できます。サービス ノードがハートビート パケットを送信し続けている限り、登録センターはノードが正常に動作していると判断できます。

もちろん、このプロセスでは予期しない状況が発生する可能性があります。たとえば、ネットワークの状態により、サービス ノードがハートビートを報告できませんが、サービスは正常に実行されています。このシナリオでは、最も直接的な解決策は、登録センターがサービスの存続期間がレポート時間間隔よりも長いと判断することです。たとえば、ハートビートの報告時間が 10 秒の場合、登録センターは、サービスが利用できないと判断するための時間枠を 30 秒に設定します。つまり、3 回のハートビート時間内にハートビートが報告されない場合は、サービスが利用できないと判断されます。

もちろん、上記は登録センターの単なる想定です。実際、システムはアクティブ検出を組み合わせて、サービスが利用可能かどうかを判断できます。こうすることで、結果の精度が高まります。つまり、サービスのノードが設定された N ハートビート時間を超えてハートビート データを報告しなかった場合、登録センターはアクティブ検出を使用して、サービスが再び正常に動作しているかどうかを判断できます。もちろん、これにより設計に一定の複雑さが加わり、より多くのコードを記述する必要が生じます。

あまり一般的ではないが、考慮する必要がある別のシナリオがあります。ネットワーク異常によりすべてのサービスノードのハートビート報告がタイムアウトし、アクティブ検出が失敗した場合、契約に従って登録センターはすべてのノード情報を徐々に削除します。その結果、システムには必ず問題が生じます。場合によっては、システムを設計する際に何らかの保護対策を考慮する必要があります。たとえば、削除されたノード情報の数が一定の割合を超えると、削除操作が停止され、アラーム メッセージが送信されます。これにより、登録センターにノードデータが存在しない状況をある程度回避できます。もちろん、クライアントもそのような保護戦略を持つことができます。

通知の嵐

この問題はほとんどの場合問題にはなりませんが、それでも言及する必要があります。プロジェクトがアップグレードされるにつれて、登録センターが引き受けるサービス ノードが増えるにつれて、サービス間の呼び出しチェーンの複雑さも増します。その結果、新しいノードを追加すると数十のクライアントに通知する必要が生じる可能性があり、ノードを削除すると同様の状況が発生する可能性があります。複数のサービスが同時にノードを追加または削除する場合、登録センターはさらに多くのメッセージをプッシュします。このようなシナリオでは、システム設計者はネットワーク ストームを回避するために登録センター サービス ノードの数を制御する必要があります。具体的な数値は、サーバーのピーク帯域幅に基づいて決定できます。

この記事はWeChat公開アカウント「建築家の修行の道」から転載したものです。以下のQRコードからフォローできます。この記事を転載する場合は、「Architect’s Path to Cultivation」の公開アカウントにご連絡ください。