ナコスのロングリンク
1. 現状と背景
Nacos 1.x バージョンの Config/Naming モジュールのそれぞれのプッシュ チャネルは、独自の設計モデルに従って実装されます。
構成およびサーバーモジュールのデータプッシュチャネルは均一ではなく、http の短い接続のパフォーマンスプレッシャーは非常に大きいため、将来的には、Nacos は構成とサービスを同時にサポートできる長い接続チャネルを構築し、再構築する必要があります標準通信モデルを使用したプッシュ チャネル。
2. シーン分析
1. 構成
接続のシナリオ分析を構成する
SDKとサーバーの間
-
クライアント SDK はサービス ノードのリストを認識し、特定の戦略に従って接続するノードの 1 つを選択する必要があります。
基になる接続が切断された場合は、再接続するサーバーを切り替える必要があります。 -
クライアントは、
現在利用可能なロング リンクに基づいて、クエリ、解放、削除、監視、監視のキャンセルなどの構成フィールドで RPC セマンティック インターフェイス通信を実行します。 -
構成変更メッセージを認識するには、現在リッスンしているクライアントに構成変更メッセージ通知をプッシュする必要があります。ネットワークが不安定な場合、クライアントはメッセージの受信に失敗するため、再プッシュをサポートしてアラームを発する必要があります
。 -
クライアントの切断イベントを認識し、接続をログアウトし、リスニング情報コンテキストのクリアなど、接続に対応するコンテキストをクリアします
。
サーバー間の通信
-
単一サーバーはクラスター内のすべてのサーバーのリストを取得し、サーバーごとに独立した長いリンクを作成する必要があります。接続が切断された場合は再接続する必要があり、サーバーのリストが変更された場合は長いリンクを作成する必要があります。新しいノードの長いリンクを破棄します。
-
構成変更情報の同期、現在の接続数情報、システム負荷情報の同期、負荷調整情報の同期など、サーバー間のデータ同期が必要です。
2. サービス
SDKとサーバーの間
- クライアント SDK はサービス ノードのリストを認識し、特定の戦略に従って接続するノードの 1 つを選択する必要があります。基になる接続が切断された場合は、再接続するサーバーを切り替える必要があります。
- 現在利用可能な長いリンクに基づいてクライアントによって設定される、クエリ、登録、ログアウト、サブスクリプション、サブスクリプション解除などのサービス ディスカバリの分野における RPC セマンティック インターフェイス通信
- サービスの変更を感知し、サービス データに変更があった場合、サーバーは新しいデータをクライアントにプッシュする必要があります。プッシュ ACK は、サーバーによるメトリクスの実行や再プッシュの判断などを容易にするために必要です。
- クライアントの切断イベントを認識し、接続をログアウトし、クライアント接続の登録サービスや購読サービスなど、接続に対応するコンテキストをクリアします。
サーバー間の通信
- サーバーは、長い接続を通じてピアの生存ステータスを認識し、長い接続を通じてサービスのステータスを報告する必要があります (同期 RPC 機能)。
- サーバー間の AP Distro データ同期には、ack 機能を備えた非同期 RPC が必要です
3. 長いリンクの中核となる要件
1. 機能要件
クライアント
接続の確立と接続の切断イベントを含む、接続のライフサイクルをリアルタイムで認識します。
クライアントは、同期ブロッキング、非同期 Future、非同期 CallBack の 3 つのモードをサポートするためにサーバーを呼び出します。
下部接続自動切り替え機能。
接続切り替えサーバの接続リセットメッセージに応答します。
サイトの選択/サービスの検出。
サーバ
接続の確立と接続の切断イベントを含む、接続のライフサイクルをリアルタイムで認識します。
サーバーはデータをクライアントにアクティブにプッシュします。クライアントは信頼性の高いプッシュをサポートするために Ack を返す必要があり、失敗した場合は再試行する必要があります。
サーバーは負荷調整機能を積極的にプッシュします。
2. 性能要件
数百万もの長いリンクの規模とリクエストとプッシュの量をサポートでき、十分に安定している必要があります。
3. 負荷分散
一般的な負荷分散戦略: ランダム、ハッシュ、ラウンドロビン、重み、最小接続数、最速の応答速度など。
-
短い接続と長い接続のロード バランシングの類似点と相違点: 短い接続では、接続の確立と切断がすぐに行われるため、「ランダム、ハッシュ、ポーリング、ウェイト」の 4 つの方法で全体のバランスを大まかに保つことができ、再起動が行われます。サーバーはバランス全体に影響を与えません。「最小接続数、最速の応答速度」がステートフル アルゴリズムである理由は、データ遅延が蓄積効果を引き起こす可能性が高いためです。接続が長いのは、接続が確立された後、接続が確立されていない場合に発生するためです。異常な状況では、接続は常に維持されます。新しいサービス ノードを再選択する必要があります。サービス ノードが公開して再起動すると、最終的な接続のバランスが崩れます。「ランダム、ラウンドロビン、重み付け」戦略は次のとおりです。クライアントが再接続して切り替えるときに使用され、「最小接続数、最速の応答速度」 短い接続と同様に、蓄積効果を引き起こすデータ遅延も発生します。長い接続と短い接続の主な違いの 1 つは、接続全体が安定している場合、サーバーはクラスターの観点から接続数を再シャッフルして割り当てるための再バランス メカニズムを必要とし、別の安定した状態に向かう傾向があることです。
-
クライアントのランダム + サーバーの柔軟な調整: 中核となる戦略は、クライアント + サーバーの双方向調整戦略、つまりクライアントのランダムな選択 + サーバーのランタイムの柔軟な調整です。
クライアントランダム
クライアントは起動時にサービスリストを取得し、ランダムなルールに従ってノードを選択するロジックは比較的単純で、全体としてはランダムを保つことができます。
サーバー側の柔軟なチューニング
(現在実装されているバージョン) 手動制御方式
- クラスタの観点から見たシステム負荷コンソールは、接続数、負荷などのビューを提供し（新しく追加された接続数、負荷、CPU などの情報を拡張し、クラスタ間でレポートを同期します）、手動調整を実現します。各サーバー ノードの接続数を調整し、手動でリバランスをトリガーし、手動で山を切り、谷を埋めます。
- クラスターの観点からロード コンソールを提供します。ノードの総数、ロング リンクの総数、平均数、およびシステム負荷情報が表示されます。
- 各ノードのアドレス、ロングリンク数、平均数との差、正負の値。
- 平均値を超えるノード数を規制し、その数の上限(一時的および永続的)を設定し、切り替えるサービスノードを指定します。
(将来の最終状態バージョン) 自動化制御ソリューション
- 各サーバー間の接続数と負荷に基づいて、適切なノードの接続数を自動的に計算し、自動的にリバランスをトリガーし、自動的に山を切り、谷を埋めます。実装サイクルは長くなり、アルゴリズムの精度に大きく依存します。
4. 接続のライフサイクル
ハートビートキープアライブメカニズム
私たちは何が必要なのか
低コストで高速な認識: クライアントは、サーバーが利用不能になったときにできるだけ早く新しいサービス ノードに切り替え、利用できない時間を短縮し、基礎となる接続切り替えイベントを認識してコンテキストをリセットできる必要があります。クライアントの切断時に接続する必要がある 構成監視、サービス サブスクリプション コンテキストなどのクライアント接続に対応するコンテキストを削除し、クライアント接続に対応するインスタンスをオフラインに処理します。
- クライアントは通常どおり再起動します。クライアントは積極的に接続を閉じ、サーバーはそれをリアルタイムで認識します。
- サーバーは通常どおり再起動します。サーバーは積極的に接続を閉じ、クライアントはそれをリアルタイムで認識します。
手ぶれ補正：
- 一時的なネットワークの利用不能: クライアントは短期的なネットワーク ジッターを受け入れることができる必要があり、クラスター ジッターを防ぐために特定の再試行メカニズムが必要です。しきい値を超えた後は、サーバーを自動的に切り替える必要がありますが、リクエスト ストームを防ぐ必要があります。 。
ネットワーク切断訓練：
- ネットワークが切断された場合は、適切な頻度で再試行し、ネットワークの切断が終了するとすぐに再接続して回復できます。
5. セキュリティ
基本認証とデータ暗号化機能をサポートします。
6. 低コストで多言語化を実現
クライアントレベルでは、できるだけ多くの言語をサポートする必要があり、クライアントが複数の主流言語でアクセスできる少なくとも 1 つの Java サーバー接続チャネルをサポートする必要があり、さまざまな言語を実装するコストを考慮する必要があります。多言語実装のコストを削減するためにシン SDK を検討する
長いリンク選択の比較
長いリンクに基づく一貫性モデル
1. 整合性モデルを構成する
SDKサーバーの一貫性
サーバー間の一貫性
サーバー間で同期メッセージを受信して処理し、再試行が失敗した場合にアラームを監視する軽量の実装。
ネットワーク切断: ネットワーク切断が長すぎて、再試行タスク キューがいっぱいの場合、排除戦略はありません。
2. サービス一貫性モデル
SDKサーバー間の一貫性
サーバー間の一貫性
コアモデルのコンポーネント設計
