Nacos 登録センターの設計原則: アプリケーションで効率的な登録と検出を簡単に実現できるようにすることです。

サービスディスカバリは、アプリケーションが単一マシンの外部で実行され、アクセスされるようになったときに誕生しました。現在のネットワークアーキテクチャでは、各ホストが独立した IP アドレスを持ち、サービスディスカバリは基本的にサービスによって展開された IP アドレスを何らかの方法で取得します。

DNS プロトコルは、ネットワーク名をネットワーク IP に変換する最も古いプロトコルです。初期のアーキテクチャ選択では、DNS+LVS+Nginx は基本的にすべての RESTful サービスの検出を満たします。このとき、サービス IP リストは通常 nginx で構成されます。またはLVS。その後、RPC サービスが登場し、オンラインとオフラインのサービスが頻繁に使用されるようになり、動的なオンラインとオフラインをサポートし、IP リストの変更をプッシュできる登録センター製品が求められるようになりました。

インターネットソフトウェア業界は一般にオープンソース製品を好みます。オープンソース製品のコードは透明であり、共同構築に参加でき、コミュニケーションと学習のためのコミュニティがあり、そしてもちろん、さらに重要なのは無料であるためです。個人の開発者や中小企業は、オープンソース製品を最初の選択肢として選択することがよくあります。

1 オープンソース製品

1.1 動物園の飼育員

古典的なサービスレジストリ製品 (ただし、その当初の位置付けはここではありません) は、長い間、中国の人々が RPC サービスレジストリについて言及するときに思い浮かべる唯一の選択肢であり、これは中国で人気のある Dubbo とほぼ同じです。

1.2 執政官とエウレカ

どちらも 2014 年に登場しました。

Consul は、分散サービスガバナンスに必要な多くの機能を含むように設計されており、サービスの登録、ヘルスチェック、構成管理、サービスメッシュなどをサポートできます。
Eureka はマイクロサービスの概念で人気があり、SpringCloud エコロジーとの密接な統合も多くのユーザーを獲得しています

1.3 ナコス

アリババの大規模なサービス制作の経験を引き継ぎ、サービス登録と構成管理の市場においてユーザーに新しい選択肢を提供しようとしています。

図 1 サービスの検出:

1.4 オープンソース製品の利点

開発者はソースコードを読んで製品の機能設計とアーキテクチャ設計を理解すると同時に、ローカル展開を通じてパフォーマンスをテストし、その後、さまざまな製品の比較記事を読むことができます。

しかし、現在の登録センターの比較は表面的な機能の比較にとどまり、アーキテクチャやパフォーマンスについての深い議論が行われていないことがよくあります。

1.5 問題点

サービスレジストリは、サイレントサポートされる製品としてサービスフレームワークの背後に隠されることがよくあります。優れたサービスフレームワークでは、複数の構成センターがサポートされることがよくありますが、登録センターの選択は依然としてサービスフレームワークに強く関連しており、サービスフレームワークにデフォルトのサービス登録センターがあることがよくあります。これによりユーザーは機種選択の手間が省けますが、単一の登録センターでは限界があるため、複数のサービスフレームワークを利用する場合には全く異なる登録センターを複数導入することになり、登録センター間のデータ連携も課題となります。

この記事では、Nacos レジストリの設計原則をさまざまな角度から深く紹介し、サービスレジストリの製品設計において遵守および考慮すべき主なポイントを、私たちの経験と調査に基づいて要約して説明します。

2 データモデル

登録センターのコアデータ:

サービス名
対応するネットワークアドレス

サービスが複数のインスタンスを登録する場合、インスタンスの特性に基づいて異常なインスタンスをフィルタリングしたり、トラフィックを分散したりする必要があるため、インスタンスに健全性ステータスや重みなどのいくつかの属性を保存する必要があります。サービスの規模が拡大するにつれて、サービスレベル全体でいくつかの権限ルールを設定したり、すべてのインスタンスに有効ないくつかのスイッチを設定したりする必要が生じるため、一部の属性はサービスレベルで設定されます。その後、単一のサービスインスタンスを複数のサブセットに分割する必要があることがわかりました。たとえば、サービスが複数のコンピュータルームに展開されている場合、各コンピュータルームの異なるインスタンスを構成する必要がある場合があります。別のデータレベルが間に設定されます。サービスとインスタンス。

比較した

Zookeeper はサービス検出のためのデータモデルを設計していません。そのデータはより抽象的なツリー KV に編成されているため、理論的にはあらゆるセマンティックデータを保存できます。
Eureka と Consul はどちらもインスタンスレベルのデータ拡張を実現しており、ほとんどのシナリオに対応できますが、大規模な複数環境のサービスデータストレージには対応できません。
Nacos が長年の社内運用経験を経て抽出したデータモデルは、サービス-クラスター-インスタンスの 3 層モデルです。基本的に、すべてのシナリオにおけるデータの保存とサービスの管理を満たします。

Nacos のデータモデルは比較的複雑ですが、その中のすべてのデータを使用する必要はありません。ほとんどのシナリオでは、これらのデータ属性を無視することを選択できます。現時点では、Nacos と同じデータモデルに減らすことができます。エウレカと執政官。

データ分離モデル

共有サービスコンポーネントとして、複数のユーザーまたはビジネスパーティが使用するときにデータの分離とセキュリティを確保できる必要があります。これは、やや大規模なビジネスシナリオでは非常に一般的です。一方、サービスレジストリはクラウド上での展開をサポートすることが多く、その際、サービスレジストリのデータモデルはクラウド上の一般的なモデルに適応できる必要があります。

Zookeeper、Consul、および Eureka には、オープンソースレベルでのサービス分離のための明確なモデルがありません。Nacos は、ユーザーが多次元でデータを分離し、同時に対応するサービスにスムーズに移行できるようにする方法を最初から検討してきました。 Alibaba Cloudの商用製品。

図 3 サービスの 4 層データロジック分離モデル:

ユーザーアカウントは企業または独立した個人に対応する場合がありますが、通常、このデータはサービス登録センターに透過的に送信されません。ユーザーアカウントは複数の名前空間を作成でき、各名前空間はクライアントインスタンスに対応します。この名前空間に対応するレジストリの物理クラスターはルールに従ってルーティングできるため、レジストリの内部アップグレードと移行を制御できます。同時に、ユーザーのレベルに応じて、サービスレベルの異なる物理クラスターがユーザーに提供されます。

さらにその下には、サービスグループとサービス名で構成される 2 次元のサービス識別子があり、インターフェイスレベルでのサービス分離を満たすことができます。

Nacos 1.0.0 で導入されたもう 1 つの新機能は、一時インスタンスと永続インスタンスです。一時インスタンスと永続インスタンスを定義的に区別する鍵となるのは、ヘルスチェックの実行方法です。一時インスタンスはクライアント側のレポートモードを使用し、永続インスタンスはサーバー側の逆検出モードを使用します。一時インスタンスは、永続ストレージインスタンスを使用せずに異常なインスタンスを自動的に削除できる必要があるため、そのようなインスタンスはゴシップのようなプロトコルに適しています。右側の永続インスタンスはサーバー側検出のヘルスチェック方式を使用しています。これは、クライアントがハートビートを報告しないため、当然のことながら、オフラインインスタンスを自動的に削除することは不可能です。

図 4 一時インスタンスと永続インスタンス:

中規模および大企業の場合、両方のタイプのサービスが利用可能です。

データベースやキャッシュなどの一部の基本コンポーネントは、ハートビートを報告できないことがよくあります。このタイプのサービスを登録する場合は、永続インスタンスとして登録する必要があります。
マイクロサービスや Dubbo サービスなどの上位レベルのビジネスサービスの場合、サービスのプロバイダー側はハートビートをレポートするためのロジックの追加をサポートし、動的なサービス登録メソッドを使用できます。

Nacos 2.0 は永続設定と非永続設定を使用しますが、調整が必要です。Nacos 1.0 の永続属性と非永続属性は、インスタンスのメタデータとして保存および識別されます。その結果、永続インスタンスと非永続インスタンスの両方が同じサービスの下に存在できます。しかし、実際に使用すると、このモードは次のようになります。

運用および保守担当者に大きな混乱と複雑さをもたらすでしょう。
システムアーキテクチャの観点から見ると、サービスに永続インスタンスと非永続インスタンスの両方があるシナリオには特定の矛盾があります。

結果として、この能力は実際には広く使用されていません。Nacos のサービスデータモデルを簡素化し、運用とメンテナンスの複雑さを軽減し、Nacos の使いやすさを向上させるために、Nacos2.0 では次のことが行われます。

永続データがサービスレベルに抽象化されているかどうか
サービスが永続インスタンスと非永続インスタンスを同時に持つことは許可されなくなり、インスタンスの永続属性はサービスの永続属性を継承します。

3 データの一貫性

分散システムは永遠のテーマですが、プロトコルレベルの観点から見ると、一貫性の選択には長い間新しいメンバーが参加していませんでした。現時点では、基本的な

次の 2 つに属することができます。

リーダーベースの非ピア展開のシングルポイント書き込み一貫性
ピアツーピア導入のための複数書き込みの一貫性

サービス登録センターを選択する場合、次のようなすべてのシナリオをカバーできるプロトコルはありません。

登録されたサービスノードが定期的に登録センターにハートビートを送信しない場合、ハートビートを通じてデータ補償登録を実行できず、最初の登録でデータが失われないことを保証する必要があるため、強力なコンセンサスプロトコルが唯一の選択肢であると思われます。
そして、クライアントが定期的にハートビートを送信して正常性状態を報告する場合、最初の登録の成功率はそれほど重要ではありません (もちろんそれも重要ですが、比較的に言えば、少量のデータ書き込み失敗は許容されます)。 -up はまだ通過できますハートビートがデータを補正する場合、Paxos プロトコルの単一点ボトルネックはコスト効率が悪くなります。これが、Eureka が Paxos プロトコルを使用せず、カスタム Renew メカニズムを使用する理由です。

これら 2 つのデータ整合性プロトコルには独自の使用シナリオがあり、サービス登録の要件が異なるため、使用するプロトコルも異なります。Dubbo システムでの Zookeeper の動作は、実際には Eureka の Renew メカニズムを使用する方が適切です。これは、Dubbo サービスが一時ノードとして Zookeeper に登録され、ノードを更新するため、およびサービスがオフラインのときに Zookeeper に定期的にハートビートを送信する必要があるためです。、Zookeeper 対応するノードを削除します。Zookeeper はデータの強力な整合性を確保するために ZAB を使用していますが、そのコンピュータルームには災害復旧機能が不足しており、一部の大規模なシナリオに適応できません。

Nacos 1.0.0 は、複数のサービスタイプの登録をサポートする必要があり、コンピュータルームのディザスタリカバリやクラスタ拡張などの重要な機能を備えているため、AP と CP という 2 つの整合性プロトコルの共存を正式にサポートしています。1.0.0 データの読み取り/書き込みおよび同期ロジックを再構築し、ビジネス関連の CRUD を基礎となる整合性同期ロジックから分離しました。次に、ビジネスの読み取りと書き込み (読み取りではビジネス層のキャッシュを直接使用するため、主に書き込み) を Nacos によって定義されたデータ型に抽象化し、データ同期のために整合性サービスを呼び出します。CP と AP のどちらの整合性を使用するかを決定する場合は、プロキシを使用して、制御可能なルールを通じて転送します。

現在のコンセンサスプロトコルの実装は、簡略化された Raft に基づく CP の一貫性と、自社開発プロトコル Distro に基づく AP の一貫性です。言うまでもなく、Raft プロトコルは Leader に基づいて記述されており、CP は厳密ではありませんが、見た目の一貫性の半分は保証されており、データ損失の可能性は小さいです。Distro プロトコルは、内部の ConfigServer とオープンソースの Eureka を参照し、サードパーティのストレージを使用せずに基本的に同じことを実現します。Distro の焦点は、ロジックの最適化とパフォーマンスのチューニングを行うことです。

図 5 Nacos 整合性プロトコル:

この記事は、ブログ用のマルチポストプラットフォームであるOpenWriteによって公開されています。