記事ディレクトリ
Nacos にコンセンサスプロトコルが必要な理由
Nacos は、ユーザーの導入、運用および保守のコストを可能な限り削減するため、ユーザーは 1 つのパッケージだけでNacos をスタンドアロン モードまたはクラスター モードですぐに起動できます。
また、Nacos はデータを保存する必要があるコンポーネントであるため、この目的を達成するには、Nacos 内にデータ ストレージを実装する必要があります。
- 実際、単一マシンではこれは大きな問題ではなく、単純な組み込みリレーショナル データベースで十分です。
- しかし、クラスタモードでは、各ノード間のデータの整合性とデータの同期をどのように確保するかを考慮する必要があり、この問題を解決するには、各ノード間のデータの整合性を確保するためのコンセンサスアルゴリズムを導入する必要があります。
Nacos が Raft と Distro を選んだ理由
Nacos が CP プロトコルと AP プロトコルの両方を単一のクラスターで実行するのはなぜですか? これは実際には Nacos シナリオから始まります: Nacos はサービス登録の検出と構成管理を統合するコンポーネントです。したがって、クラスター内の各ノード間のデータ整合性保証の問題については、2 つの側面に分割する必要があります。
サービスレジストリ検出から
サービスが互いのサービスを認識し、正常にサービスを提供できるインスタンス情報は、サービス ディスカバリ登録センターから取得する必要があるため、サービス登録ディスカバリ センター コンポーネントの可用性に対して高い要件が提示されます。登録検出機能は外部サービスを提供できます。
同時に、Nacosのサービス登録検出設計は、ハートビートがサービスデータの補償を自動的に完了できるメカニズムを採用しています。データが失われた場合、このメカニズムによりデータ損失を迅速に補うことができます。
したがって、サービス ディスカバリ レジストリの可用性を満たすために、外部サービスを提供するための強整合性コンセンサス アルゴリズムの要件があるため、強整合性コンセンサス アルゴリズムはここには適していません。半分以上の場合、アルゴリズム全体が直接「ストライク」し、コンセンサスアルゴリズムが最終的に合意されると、サービスの可用性がより保証され、ノード間のデータが確実に到達できるようになります。一定期間内の合意。
上記はすべて、Nacos サービス検出登録の非永続サービスに関するものです (つまり、クライアントはサービス インスタンスを更新するためにハートビートを報告する必要があります)。
Nacos サービス検出登録の永続サービスの場合、すべてのデータは Nacos サーバーを呼び出すことによって直接作成されるため、Nacos は各ノード間のデータの強整合性を確保する必要があるため、このタイプのサービス
構成管理の観点から
構成データは、Nacos サーバー上で直接作成および管理されます。構成が正常に保存されたとみなすには、ほとんどのノードで構成データが保存されていることを確認する必要があります。そうしないと、構成の変更が失われます。これが発生した場合、問題は非常に深刻です。重要な構成変更がリリースされ、変更アクションが失われると、重大なライブネットワーク障害が発生する可能性があります。そのため、構成データの管理には、クラスター内のほとんどのノードが必要です。強力な一貫性が必要であり、ここでは強力なコンセンサス コンセンサス アルゴリズムのみを使用できます。
なぜ Raft と Distro なのか?
ラフト（CPモード）
強力なコンセンサス コンセンサス アルゴリズムとしては、Raft プロトコルが現在の工業生産で最もよく使用されています。Raft プロトコルの方が理解しやすく、次のような成熟した工業用アルゴリズムの実装が多数あります。
- Ant Financial の JRaft
- 動物園飼育員のZAB
- 領事のいかだ
- 百度の製品
- アパッチラット
Nacos は Java テクノロジー スタックであるため、JRaft、ZAB、および Apache Ratis の中からのみ選択できますが、ZAB は Zookeeper と強く結合しており、Raft アルゴリズム ライブラリのサポート チームと通信することを希望しているため、JRaft を選択し、JRaft これは、JRaft が複数の RaftGroup をサポートしているためでもあり、これにより、Nacos の背後で複数のデータ断片化が発生する可能性が生じます。
ディストリビューション (AP モード)
Distroプロトコルは Alibaba が自社開発した結果整合性プロトコルであり、Gossip や Eureka のデータ同期アルゴリズムなど、結果整合性プロトコルは数多くあります。Distro アルゴリズムは、Gossip プロトコルと Eureka プロトコルの利点を統合することによって最適化されています。オリジナルの Gossip では、メッセージを送信するノードがランダムに選択されるため、同じノードにメッセージが繰り返し送信されることは避けられず、ネットワークの送信量が増加します。また、圧力はメッセージ ノードに追加の処理負荷をもたらします。Distroアルゴリズムでは権威サーバーの概念が導入され、各ノードがデータの一部を担当し、自身のデータを他のノードに同期することで、メッセージの冗長性の問題が効果的に軽減されます
。
Nacos 整合性プロトコルの進化
初期の Nacos コンセンサスプロトコル
初期のNaocsバージョンのアーキテクチャを見てください。
-
初期の Nacos アーキテクチャでは、サービス登録と構成管理の一貫性プロトコルが分離されており、一般的な機能の進化として Nacos カーネル モジュールに組み込まれることはありませんでした。
-
サービス検出モジュールの整合性プロトコルの実装は、サービス登録検出モジュールのロジックと強く結合されており、サービス登録検出のいくつかの概念が組み込まれています。
-
これにより、Nacos のサービス登録検出モジュールのロジックが複雑になり、保守が困難になり、整合性プロトコル層のデータ ステータスが結合され、コンピューティングとストレージを完全に分離することが困難になり、また、サービスの無制限の水平拡張機能にも一定の影響を及ぼします。コンピューティング層。
したがって、この問題を解決するには、Nacos の整合性プロトコルを抽象化してシンクしてコア モジュール機能にし、サービス登録検出モジュールがコンピューティング パワーとしてのみ機能できるようにする必要があります。外部データベースに保存される構成モジュールの基礎 アーキテクチャの基本。
Nacos の現在の整合性プロトコル層
前述したように、現在の Nacos カーネルでは、Nacos のコア機能として整合性プロトコルをカーネル モジュールに完全に組み込む機能を実現しており、これはサービス登録検出モジュールと構成管理モジュールに適しています。現在の Nacos アーキテクチャでは。
新しい Nacos アーキテクチャでは、一貫性プロトコルが元のサービス登録検出モジュールからカーネル モジュールにシンクされ、統一された抽象インターフェイスが可能な限り提供されていることがわかります。そのため、上位層のサービス登録検出はモジュールと構成管理モジュールを一貫性セマンティクスと組み合わせる必要がなくなり、抽象化レイヤーを分離した後、各モジュールが急速に進化し、パフォーマンスと使いやすさが大幅に向上します。
Nacos はどのようにして一貫性のあるプロトコル シンキングを実現するのか
Nacos は、AP および CP プロトコルをカーネル モジュールにシンクし、可能な限り同じユーザー エクスペリエンスを維持することに成功しました。では、Nacos はどのようにしてこのコンセンサスプロトコルの沈没を達成したのでしょうか?
コンセンサスプロトコルの抽象化
-
実際、整合性プロトコルはデータの整合性を確保するために使用され、データの生成には書き込みアクションが必要です。
-
同時に、データを読み取ることができること、データを読み取る動作と得られるデータ結果を保証し、整合性プロトコルによって保証されることも必要です。
したがって、整合性プロトコルの 2 つの最も基本的なメソッドは、書き込みアクションと読み取りアクションです。
- コンセンサス プロトコルを使用する場合は、getData メソッドと write メソッドのみを使用する必要があります。
- 同時に、整合性プロトコルは整合性パッケージ内で抽象化されており、Nacos はその中で AP と CP の整合性プロトコル インターフェイスの抽象化を使用し、特定の整合性プロトコルを実装する場合はプラグイン可能なプラグインを使用します。 、コンセンサス プロトコルの実装ロジックは、サービス登録の検出と構成管理の 2 つのモジュールからさらに分離されています。
実際、整合性プロトコルの抽象化を完了するだけでは十分ではありません。これを行うだけでも、サービス登録の検出と構成管理は依然として整合性プロトコルのインターフェイスに依存する必要があり、ステートフル インターフェイスはこの 2 つのインターフェイスの間に結合されます。コンピューティングモジュール。
さらに、比較的高レベルの整合性プロトコルの抽象化が行われていますが、サービス モジュールと構成モジュールは依然として、独自のコード モジュールで整合性プロトコルを処理するための読み取りおよび書き込み要求ロジックを表示する必要があり、実際には、整合性プロトコルのストレージに接続するのは適切ではありません。サービス検出および構成モジュールは、データの保存方法、データの整合性を確保する方法、データ ストレージ、およびマルチノードの整合性の問題ではなく、データの使用と計算に重点を置く必要があります。ストレージ層によって保証されます。
サービス登録検出と構成管理の 2 つのモジュールに現れる一貫性プロトコルの頻度をさらに減らし、可能な限り一貫性プロトコルがカーネル モジュール内でのみ認識されるようにするために、Nacos はここで別の仕事、つまりデータ ストレージを実行しました。概要。
データストレージの抽象化
整合性プロトコルは、データの整合性を確保するために使用されます。整合性プロトコルを使用してストレージを実装する場合、サービス モジュールと構成モジュールは、整合性プロトコル インターフェイスへの依存からストレージ インターフェイスへの依存に変わります。
ストレージ インターフェイスの背後にある特定の実装は整合性プロトコルよりもはるかに豊富であり、サービス モジュールと構成モジュールは整合性プロトコルに直接依存するために冗長なコーディング作業 (スナップショット、ステート マシン実装、データ同期) を行う必要がありません。) これにより、これら 2 つのモジュールはコア ロジックにさらに集中できるようになります。
データの抽象化について、ここでは例としてサービス登録検出モジュールのみを取り上げます。
-
Nacos のサービス モジュール ストレージは、主に 1 つまたは複数の一意のキーに基づいて列挙操作を実行するため、Key-Value タイプのストレージ インターフェイスが最適です。
-
Key-Value ストレージ インターフェイスが定義されると、それは実際にはこの KVStore の具体的な実装になります。KVStore の実装は、Redis に直接接続することも、DB に直接接続することも、Nacos カーネル モジュールの整合性プロトコルに直接基づいて行うこともでき、これに基づいて、メモリまたは永続的な分散型の強い (弱い) 整合性の KV を実現できます。
-
Nacos プロセスは、機能境界を介してコンピューティング ロジック層とストレージ ロジック層にさらに分離されており、コンピューティング層とストレージ層の間の相互作用は、データ操作グルー コードの薄い層のみを介して行われるため、コンピューティングは 2 つのコンポーネントで実現されます。単一の Nacosプロセス ロジックとストレージ
同時に、ストレージ層については、プラグイン設計がさらに実装され、運用および保守コストの要件がある中小企業は、Nacos の組み込み分散ストレージ コンポーネントを直接使用して、セットを導入できます。サービス インスタンスのデータと構成データの量が多く、比較的優れた Paas レイヤー サービスがある場合は、既存のストレージ コンポーネントを再利用して、Nacos のコンピューティング レイヤーとストレージ レイヤーを完全に分離できます。
