記事ディレクトリ
序文
サービス ディスカバリは古いトピックですが、サービス ディスカバリは、アプリケーションがスタンドアロン マシンから実行およびアクセスし始めたときに生まれました。現在のネットワーク アーキテクチャでは、各ホストが独立した IP アドレスを持っているため、サービス ディスカバリは基本的にサービスによって展開された IP アドレスを何らかの方法で取得します。DNS プロトコルは、ネットワーク名をネットワーク IP に変換する最も古いプロトコルです。最初のアーキテクチャ選択では、DNS+LVS+Nginx で基本的にすべての RESTful サービス検出を満たすことができます。このとき、サービス IP リストは通常、nginx またはLVS。その後、RPC サービスが登場し、オンラインとオフラインのサービスが頻繁に使用されるようになり、動的なオンラインとオフラインをサポートし、IP リストの変更をプッシュできる登録センター製品が求められるようになりました。
インターネット ソフトウェア業界では、オープン ソース製品のコードが透明であり、共同構築に参加でき、コミュニケーションと学習のためのコミュニティがあるため、一般にオープン ソース製品が好まれます。もちろん、さらに重要なことに、それらは無料です。個人の開発者や中小企業は、オープンソース製品を最初の選択肢として選択することがよくあります。Zookeeper は古典的なサービス レジストリ製品であり (本来の位置づけはここではありませんが)、長い間、中国人が RPC サービス レジストリについて考えるときに思い浮かべる唯一の選択肢でした。中国でのダボの人気に貢献します。Consul と Eureka はどちらも 2014 年に登場しました。Consul の設計には、サービスの登録、ヘルスチェック、構成管理、サービス メッシュなどをサポートできる分散サービス ガバナンスに必要な多くの機能が含まれています。Eureka は、マイクロサービスの概念の人気と SpringCloud エコロジーの緊密な統合により、多くのユーザーを獲得しました。昨年オープンソース化された Nacos は、アリババの大規模なサービス制作の経験を継承し、サービス登録と構成管理の市場でユーザーに新しい選択肢を提供しようとしました。
オープンソース製品の利点は、開発者がソース コードを読んで製品の機能設計とアーキテクチャ設計を理解し、同時にローカル展開を通じてパフォーマンスをテストし、その後、さまざまな製品の比較記事を作成できることです。しかし、現状の登録センターの比較は表面的な機能の比較にとどまっていることが多く、アーキテクチャや性能についてはあまり踏み込んだ議論が行われていません。
もう 1 つの現象は、サービス レジストリがサイレント サポートされる製品としてサービス フレームワークの背後に隠れていることがよくあることです。優れたサービス フレームワークでは、複数の構成センターがサポートされることがよくありますが、登録センターの選択は依然としてサービス フレームワークに強く関連しており、サービス フレームワークにデフォルトのサービス登録センターがあることがよくあります。これによりユーザーは機種選択の手間が省けますが、単一の登録センターでは限界があるため、複数のサービスフレームワークを利用する場合には全く異なる登録センターを複数導入することになり、登録センター間のデータ連携も課題となります。
この記事では、Nacos レジストリの設計原則をさまざまな角度から深く紹介し、サービス レジストリの製品設計において遵守および考慮すべき主なポイントを、私たちの経験と調査に基づいて要約して説明します。
1. データモデル
登録センターのコア データは、サービスの名前とそれに対応するネットワーク アドレスです。サービスが複数のインスタンスを登録する場合、インスタンスの特性に応じて、異常なインスタンスをフィルタリングするか、トラフィックを分散する必要があります。正常性ステータスや重量がその上に保管されます。サービス規模の拡大に伴い、サービスレベル全体でいくつかの権限ルールや、すべてのインスタンスに有効なスイッチを設定する必要が生じ、一部の属性がサービスレベルで設定されることになります。その後、単一のサービス インスタンスを複数のサブセットに分割する必要があることがわかりました。たとえば、サービスが複数のコンピュータ ルームに展開されている場合、各コンピュータ ルームの異なるインスタンスを構成する必要がある場合があります。別のデータ レベルが間に設定されます。サービスとインスタンス。
Zookeeper はサービス検出用のデータ モデルを設計していませんが、そのデータはより抽象的なツリー型の KV に編成されているため、理論的にはあらゆるセマンティクスのデータを保存できます。Eureka と Consul はどちらもインスタンス レベルのデータ拡張を実現しており、ほとんどのシナリオを満たすことができますが、大規模な複数環境のサービス データ ストレージには対応できません。Nacos が長年の社内運用経験を経て抽出したデータ モデルは、サービス-クラスター-インスタンスの 3 層モデルです。前述したように、これは基本的に、すべてのシナリオでデータの保存とサービスの管理を満たすことができます。
Nacos のデータ モデルは比較的複雑ですが、その中のすべてのデータを使用する必要はありません。ほとんどのシナリオでは、これらのデータ属性を無視することを選択できます。この時点で、ディメンションを同じデータ モデルに減らすことができます。エウレカと執政として。
もう 1 つ考慮すべきことは、データ分離モデルです。共有サービス コンポーネントとして、複数のユーザーまたはビジネス パーティが使用するときにデータの分離とセキュリティを確保できる必要があります。これは、このシーンで非常に一般的な、やや大規模なビジネスです。一方、サービス レジストリはクラウド上での展開をサポートすることが多く、その際、サービス レジストリのデータ モデルはクラウド上の一般的なモデルに適応できる必要があります。Zookeeper、Consul、および Eureka には、オープンソース レベルでのサービス分離のための明確なモデルがありません。Nacos は、ユーザーが多次元でデータを分離し、同時に対応するサービスにスムーズに移行できるようにする方法を最初から検討してきました。 Alibaba Cloudの商用製品。
Nacos は 4 層のデータ ロジック分離モデルを提供します。ユーザー アカウントは企業または独立した個人に対応する場合があります。通常、このデータはサービス レジストリに透過的に送信されません。ユーザー アカウントは複数の名前空間を作成でき、各名前空間はクライアント インスタンスに対応します。この名前空間に対応するレジストリの物理クラスターはルールに従ってルーティングできるため、レジストリの内部アップグレードと移行を制御できます。感知できないと同時に、ユーザーのレベルに応じてサービスレベルの異なる物理クラスターを提供できます。さらにその下には、サービス グループとサービス名で構成される 2 次元のサービス識別子があり、インターフェイス レベルでのサービス分離を満たすことができます。
Nacos 1.0.0 で導入されたもう 1 つの新機能は、一時インスタンスと永続インスタンスです。一時インスタンスと永続インスタンスを定義的に区別する鍵となるのは、ヘルス チェックの実行方法です。一時インスタンスはクライアント側のレポート モードを使用し、永続インスタンスはサーバー側の逆検出モードを使用します。一時インスタンスは、永続ストレージ インスタンスを使用せずに異常なインスタンスを自動的に削除できる必要があるため、そのようなインスタンスはゴシップのようなプロトコルに適しています。右側の永続インスタンスはサーバー側検出のヘルスチェック方式を使用しています。これは、クライアントがハートビートを報告しないため、当然のことながら、オフライン インスタンスを自動的に削除することは不可能です。
大企業と中堅企業では、両方のタイプのサービスが利用できることがよくあります。データベースやキャッシュなどの一部の基本コンポーネントはハートビートを報告できないことが多く、この種のサービスを登録する場合は、永続インスタンスとして登録する必要があります。マイクロサービスや Dubbo サービスなどの上位レベルのビジネス サービスの場合、サービスのプロバイダー側はハートビートをレポートするためのロジックの追加をサポートしており、このとき、動的サービス登録メソッドを使用できます。
Nacos 2.0 は引き続き永続設定と非永続設定を使用しますが、いくつかの調整が加えられています。Nacos 1.0 の永続属性と非永続属性は、インスタンスのメタデータとして保存および識別されます。その結果、永続インスタンスと非永続インスタンスの両方が同じサービスの下に存在できます。しかし、実際に使用してみると、このモードは運用保守担当者に大きな混乱と複雑さをもたらすと同時に、システム アーキテクチャの観点から、サービスには永続インスタンスと非永続インスタンスの両方が存在することがわかりました。現場の矛盾。これは、この能力が広く使用されていないという事実につながります。Nacos のサービス データ モデルを簡素化し、運用および保守担当者の複雑さを軽減し、Nacos の使いやすさを向上させるために、Nacos2.0 では永続データがサービス レベルに抽象化され、サービスを許可しなくなります。インスタンスと非永続インスタンスでは、インスタンスの永続属性はサービスの永続属性を継承します。
2. データの一貫性
データの一貫性は分散システムにおける永遠のテーマであり、Paxos プロトコルの複雑さにより、データの一貫性はプログラマが自慢できる共通のテーマとなっています。しかし、協定の観点から見ると、一貫性の選択には長い間新しいメンバーが参加していませんでした。現時点では、基本的に 2 つのタイプに分類できます。1 つはリーダーベースの非ピア展開に基づくシングルポイント書き込み一貫性、もう 1 つはピアツーピア展開のマルチ書き込み一貫性です。サービス登録センターを選択する場合、すべてのシナリオをカバーできるプロトコルはありません。たとえば、登録されたサービス ノードが定期的に登録センターにハートビートを送信しない場合、強力なコンセンサス プロトコルが唯一の選択肢であるように見えます。 pass ハートビートはデータ補償登録を実行するために使用され、最初の登録ではデータが失われないことを保証する必要があります。そして、クライアントが定期的にハートビートを送信して正常性状態を報告する場合、最初の登録の成功率はそれほど重要ではありません (もちろんそれも重要ですが、比較的に言えば、少量のデータ書き込み失敗は許容されます)。 -up はまだ通過できます ハートビートがデータを補正する場合、Paxos プロトコルの単一点ボトルネックは費用対効果が高くありません。これが、Eureka が Paxos プロトコルを使用せず、カスタム Renew メカニズムを使用する理由です。
これら 2 つのデータ整合性プロトコルには独自の使用シナリオがあり、サービス登録の要件が異なると、使用するプロトコルも異なります。ここで、Dubbo システムの下で Zookeeper が示す動作は、実際には Eureka の Renew メカニズムを使用する方が適切であることがわかります。これは、Dubbo サービスが一時ノードとして Zookeeper に登録され、ノードを更新するために定期的に Zookeeper にハートビートを送信する必要があるためです。オンラインの場合は、Zookeeper 上の対応するノードを削除します。Zookeeper は強力なデータ一貫性を確保するために ZAB プロトコルを使用していますが、コンピューター室の災害復旧機能が欠けており、一部の大規模なシナリオには適応できません。
Nacos は、複数のサービス タイプの登録をサポートする必要があり、コンピューター ルームの災害復旧やクラスター拡張などの重要な機能を備えているため、1.0.0 で AP と CP コンセンサス プロトコルの共存を正式にサポートしています。1.0.0 では、データの読み取り、書き込み、および同期ロジックが再構築され、ビジネス関連の CRUD が基礎となる整合性同期ロジックから分離されました。次に、ビジネスの読み取りと書き込み (読み取りではビジネス層のキャッシュを直接使用するため、主に書き込み) を Nacos によって定義されたデータ型に抽象化し、データ同期のために整合性サービスを呼び出します。CP と AP のどちらの整合性を使用するかを決定する場合は、プロキシを使用して、制御可能なルールを通じて転送します。
現在のコンセンサス プロトコルの実装は、簡略化された Raft に基づく CP の一貫性と、自社開発プロトコル Distro に基づく AP の一貫性です。言うまでもなく、Raft プロトコルは Leader に基づいて記述されており、CP は厳密ではありませんが、見た目の一貫性の半分は保証されており、データ損失の可能性は小さいです。Distro プロトコルは、内部の ConfigServer とオープン ソースの Eureka を参照し、サードパーティのストレージを使用せずに基本的に同じことを実現します。Distro の焦点は、ロジックの最適化とパフォーマンスのチューニングを行うことです。
3. 負荷分散
厳密に言えば、負荷分散は従来のレジストリの機能ではありません。一般的に、サービス検出の完全なプロセスは、最初にレジストリからサービス インスタンスのリストを取得し、次に独自のニーズに応じてインスタンスの一部を選択するか、特定のトラフィック分散メカニズムに従ってさまざまなサービス プロバイダーにアクセスする必要があります。登録センター自体は通常、サービス利用者のアクセス戦略を定義しません。Consul を含む Eureka、Zookeeper は、構成可能でスケーラブルな負荷分散メカニズムを実装していません。Eureka の負荷分散はリボン (最新の SpringCloud 公式作業のみ) によって行われますが、Consul は Fabio によって行われます。
アリババグループ内では逆の考え方が使われています。サービス利用者は多くの場合、訪問するサービス プロバイダーの負荷分散については気にせず、最も効率的かつ正確なアクセスでサービス プロバイダーのサービスにアクセスすることだけを気にします。一方、サービスプロバイダーは自社のトラフィックの展開に細心の注意を払っており、その第一の理由は、アリババグループの内部サービスアクセストラフィックが膨大であり、少し不注意をすると異常なトラフィックが発生し、サービスプロバイダーのサービスを圧倒してしまうことです。 。したがって、サービス プロバイダーは、サービスのトラフィック割り当てを完全に制御し、動的に調整できる必要があります。
サーバー側の負荷分散により、サービス プロバイダーはより強力なフロー制御権限を得ることができますが、異なる負荷分散戦略を使用したいさまざまな消費者のニーズを満たすことはできません。ただし、異なる負荷分散戦略を使用したシナリオも存在します。クライアント側の負荷分散はこの柔軟性を提供し、ユーザー拡張に対するよりフレンドリーなサポートを提供します。ただし、クライアントの負荷分散戦略が適切に構成されていない場合、サービス プロバイダーのホットスポットが発生したり、サービス プロバイダーがまったく存在しなくなる可能性があります。
負荷分散がサービス プロバイダーに実装されているか、サービス コンシューマに実装されているかに関係なく、現在の負荷分散には重み、サービス プロバイダーの負荷、応答時間、およびタグに基づいた戦略があることがわかります。その中で、Ribbon によって設計されたクライアント負荷分散メカニズムは、主に、適切な既存の IRule、ServerListFilter、およびその他のインターフェイスを選択して実装するか、これらのインターフェイスを独自に継承して独自のフィルタリング ロジックを実現します。ここのリボンでは、2 段階の負荷分散を使用しています。最初の手順では、使用されないサービス プロバイダー インスタンスをフィルターで除外し、第 2 段階では、フィルターされたサービス プロバイダー インスタンスに負荷分散戦略を実装します。リボンに組み込まれた負荷分散戦略は比較的強力であり、ユーザーによる拡張が可能であるため、これは比較的優れた設計であると言えます。
タグベースの負荷分散戦略は非常に柔軟です。Kubernetes と Fabio はどちらもタグを使用してリソースをフィルタリングしています。タグを使用すると、任意の比率と重みでサービス トラフィックの割り当てをほぼ実現できます。ただし、タグ自体が登録センター自体に配置されているか、サードパーティの CMDB に接続されているかに関係なく、タグ自体には別のストレージと読み取りおよび書き込み機能が必要です。
Nacos バージョン 0.7.0 では、ヘルスチェックと重み付けに基づくロード バランシングの提供に加え、サードパーティの CMDB に基づく新しいラベル ロード バランサーも提供します (詳細については、CMDB の機能紹介記事を参照してください)。タグベースのロードバランサーを使用すると、現在、同じタグへのアクセスを優先するトラフィック スケジューリング ポリシーを実装することができます。実際のアプリケーション シナリオでは、近くのサービスへのアクセスを実現するために使用できます。これは、サービスは複数のリージョンにデプロイされます。このラベルのロード バランサーを使用すると、多くのシナリオをサポートできますが、この記事では詳しく説明しません。Nacos でサポートされるラベル式は現時点では豊富ではありませんが、サポートされる構文は徐々に拡張される予定です。さらに、Nacos は、負荷分散のための統一された抽象化として Selector を定義します。Selectorについては紙面の都合上、別記事で紹介させていただきます。
理想的な負荷分散の実装はどのようなものであるべきでしょうか? 人によって答えも異なります。Nacos がやろうとしているのは、特定のメカニズムを通じてサーバー側の負荷分散とクライアント側の負荷分散を組み合わせ、ユーザーにスケーラビリティを提供し、ユーザーに完全な自律性と簡単な使用法を提供することです。負荷分散は大きなテーマですが、登録センターが提供する負荷分散戦略に注目する場合、登録センターが自分に必要な負荷分散方法を備えているか、使用方法が複雑かどうかに注意する必要があります。そうでない場合、必要な負荷分散戦略を達成するために簡単に拡張できるでしょうか。
4. 健康チェック
Zookeeper と Eureka はどちらも TTL メカニズムを実装しています。つまり、クライアントが一定期間内にレジストリにハートビートを送信しない場合、クライアントは削除されます。Eureka の優れている点は、サービスの登録時に自身のステータスを確認するためのヘルスチェック方法をカスタマイズできることです。これは、サービス インスタンスがハートビート レポートを維持できるシナリオでは比較的良好な体験であり、Dubbo と SpringCloud の 2 つの主要なシステムにおいても、ユーザーの心のデフォルトの動作として培われてきました。Nacos もこの TTL メカニズムをサポートしていますが、Alibaba の ConfigServer の内部メカニズムとは多少異なります。Nacos は現在、アクティビティを維持するためにハートビート レポート方法を使用する一時インスタンスをサポートしています。デフォルトのハートビート送信サイクルは 5 秒です。Nacos サーバーは、ハートビートを受信しない 15 秒後にインスタンスを異常として設定し、30 秒後に一時インスタンスを削除します。 。
ただし、前述したように、一部のサービスはハートビートを報告できませんが、外部検出用の検出インターフェイスを提供できます。このようなサービスも広く存在しており、私たちの経験では、これらのサービスにはサービスの検出と負荷分散に対する強いニーズもあります。サーバー側ヘルス チェックの最も一般的な方法は、TCP ポート検出と HTTP インターフェイス リターン コード検出です。これら 2 つの検出方法は、プロトコルの汎用性により、ほとんどのヘルス チェック シナリオをサポートできます。他のいくつかの特別なシナリオでは、サービスが利用可能かどうかを判断するために特別なインターフェイスを実装する必要がある場合があります。たとえば、データベースのマスターとバックアップがデプロイされている場合、特定の状況下でデータベースのマスターとバックアップが切り替わる可能性があるため、現在アクセスしているデータベースがマスター データベースであることを確認するために、サービス名を介して外部アクセスを提供する必要があります。 。このときのヘルスチェックインターフェースは、データベースがメインデータベースであるかどうかをチェックするためのMYSQLコマンドであってもよい。
クライアント側のヘルスチェックとサーバー側のヘルスチェックには、いくつかの異なる懸念事項があります。クライアントの健全性チェックは、クライアントがハートビートを報告する方法と、サーバーが異常なクライアントを削除するメカニズムに主に焦点を当てています。サーバー側のヘルスチェックは、クライアントの検出方法と感度、およびクライアントのヘルスステータスを設定するメカニズムに焦点を当てています。実装の複雑さの点では、サーバー側の検出はより複雑になる必要があります。サーバーは、登録サービスによって構成されたヘルスチェックメソッドに従って対応するインターフェイスを実行し、対応する戻り結果を判断し、適切な再試行メカニズムとスレッドを作成する必要があるからです。プール管理。これは、ハートビートを待って TTL を更新するだけでよいクライアント検出とは異なります。同時に、サーバー側のヘルス チェックでは異常なインスタンスを削除できません。つまり、登録されたサービス インスタンスが積極的にログアウトするためにインターフェイスを呼び出さない限り、これらのサービス インスタンスはヘルス チェックの検出タスクを維持する必要があります。クライアントはいつでも異常なインスタンスを削除できるため、サーバー側の負荷が軽減されます。
Nacos はクライアント側のヘルス チェックとサーバー側のヘルス チェックの両方をサポートしており、同じサービスでヘルス チェック モードを切り替えることができます。私たちは、さまざまなタイプのサービスをサポートし、これらのサービスが Nacos の負荷分散機能を使用できるように、このヘルスチェック方法の多様性が非常に重要であると考えています。Nacos の次のステップは、サーバー側の検出かクライアント側の検出であるかに関係なく、ヘルス チェック メソッドのユーザー拡張メカニズムを実装することです。これにより、ユーザーがビジネス セマンティクスのリクエストを渡すことがサポートされ、Nacos がそれを実行してヘルス チェックをカスタマイズします。
5. パフォーマンスと容量
Zookeeper は絶妙に設計されていますが、これは明らかに一連の前提条件があるためです。まず第一に、Zookeeper の書き込みロジックは KV を記述することであり、内部に集計はありません。第 2 に、Zookeeper はヘルス チェックやフレンドリーなクエリ インターフェイスなどのサービス検出の基本機能を放棄します。これらの機能をサポートする場合、明らかに次のことを行う必要があります。ロジックを追加したり、既存のデータ構造を放棄したりすることもできます。最終的には、Paxos プロトコル自体が Zookeeper クラスターのサイズを制限し、3 つまたは 5 つのノードでは大規模なサービスのサブスクリプションとクエリを処理できません。
キャパシティを評価する際には、企業の既存のサービス規模を評価するだけでなく、今後3～5年の拡張規模を予測する必要があります。アリババのミドルウェアは、グループの数百万レベルのサービス インスタンスを内部でサポートしており、キャパシティの点で直面する課題は、どのインターネット企業にも劣らないと言えます。この容量には、全体として登録されているインスタンス数だけでなく、単一サービスのインスタンス数、全体の加入者数、クエリの QPS も含まれます。ナコス社内で Zookeeper と Eureka を排除するプロセスにおいて、キャパシティは非常に重要な要素です。
Zookeeper の容量は、ストレージ ノードの数で言えば 100 万レベルに達する可能性があります。ただし、前述したように、これはすべての容量を表すわけではなく、多数のインスタンスがオフラインになると、Zookeeper のパフォーマンスが不安定になり、同時にプッシュ メカニズムの欠陥により、クライアントのリソース使用量が増加します。 、パフォーマンスが大幅に低下します。
Eurekaのサービスインスタンスの規模が5000程度になると、すでにサービスが利用できない問題が発生しており、ストレステストの過程でも同時スレッド数が多すぎるとEurekaがクラッシュしてしまいます。ただし、サービス規模が 1000 程度であれば、現在のレジストリはほぼすべて満たすことができます。結局のところ、私たちは Eureka を SpringCloud の登録センターとみなしており、中国では容量やパフォーマンスの問題に関する広範な報告を見たことがありません。
Nacos のオープンソース バージョンでは、サービス インスタンス登録のサポートは約 100 万で、サービスの数は 100,000 を超える場合があります。実際のデプロイメント環境では、マシンとネットワークの構成および JVM パラメーターの違いにより、この数値は異なる場合があります。図 9 は、バージョン 1.0.0 を使用した Nacos ストレス テストの結果の概要を示しています。これには、容量、同時実行性、スケーラビリティ、遅延に関するテストと統計が含まれます。
6. 使いやすさ
使いやすさもユーザーが重視するコンテンツです。製品の機能特性や性能が非常に優れていても、ユーザーの使用コストが非常に高ければ、ユーザーの意欲を削ぐことにもなります。使いやすさには、API とクライアントへのアクセスが簡単かどうか、ドキュメントが完全で理解しやすいかどうか、コンソール インターフェイスが完璧かどうかなど、作業のさまざまな側面が含まれます。オープンソース製品の場合、コミュニティが活発かどうかも要因となります。使いやすさの観点から Nacos、Eureka、Zookeeper のパフォーマンスを比較する場合、コミュニティのユーザーは全面的なフィードバックを提供することを心から歓迎します。結局のところ、アリババ グループ内では、Eureka と Zookeeper の使用シナリオは限られているからです。 。経験と調査によれば、Zookeeper は使いにくい、Zookeeper のクライアントは使い方が複雑、サービス検出とそれに対応する API カプセル化のためのモデル設計がなく、依存者が処理する必要がある。多言語のサポートはあまり充実しておらず、運用や保守管理のための使いやすいコンソールもありません。
Zookeeper と比較すると、Eureka と Nacos は大幅に改善されており、これら 2 つの製品には、サービスの登録と検出のためのクライアントのほか、SpringCloud システムに基づくスターターが含まれており、ユーザーが認識することなく非常に低コストでサービスの登録と検出を支援します。同時に、多言語およびクロスプラットフォームのアクセスをサポートする標準の HTTP インターフェイスも公開します。Eureka と Nacos はどちらも、サービスの登録ステータスを照会するための公式コンソールを提供しています。ただし、Eureka 2.0 が開発終了を発表したため、Eureka はユーザーの使用の最適化に比較的大きな投資を行うべきではなく、Nacos はまだ開発中です。現在サポートされている使いやすさ機能に加えて、フォローアップは継続されます。コンソールの機能を強化し、コンソールのログインと権限の管理と制御を強化し、システムとメトリクスの公開を監視し、公式 Web サイトやその他のチャネルを通じてドキュメントの使用を継続的に改善し、多言語 SDK を開発します。
コミュニティ活動の観点から見ると、Zookeeper と Eureka は既存ユーザーが多いため、多くのチュートリアルやトラブルシューティングがコミュニティで見つかりますが、この点で、新たにオープンソースとなった Nacos は時間をかけて蓄積し続ける必要があります。
7、クラスターのスケーラビリティ
集群扩展性和集群容量以及读写性能关系紧密。当使用⼀个比较小的集群规模就可以支撑远高于现有数量的服务注册及访问时，集群的扩展能力暂时就不会那么重要。从协议的层面上来说，Zookeeper 使用的 ZAB 协议，由于是单点写，在集群扩展性上不具备优势。Eureka 在协议上来说理论上可以扩展到很大规模，因为都是点对点的数据同步，但是从我们对 Eureka 的运维经验来看，Eureka 集群在扩容之后，性能上有很大问题。
クラスターのスケーラビリティのもう 1 つの側面は、マルチリージョン展開と災害復旧のサポートです。クラスターの高可用性と安定性、およびネットワーク上のリージョン間の遅延を考慮すると、各リージョンにクラスターを展開する必要があります。当社の既存のソリューションでは、マルチルームのディザスター リカバリー、異なる場所でのマルチアクティブ、および複数のクラスターを備えています。 -データセンター。
1 つ目は、デュアル コンピューター ルームのディザスター リカバリーです。これは、リーダーが作成したプロトコルに基づいた変更を加えなければサポートできません。つまり、Zookeeper は手動介入なしではデュアル コンピューター ルームのディザスター リカバリーを実現できません。単一のコンピュータ室がネットワークから切断された場合、コンピュータ室でサービスを利用できるようにすることは難しくありませんが、ネットワーク切断が回復した後にデータをどのように集約するかが問題になります。Zookeeper のシングルポイント書き込みモードでは、データが保持されます。ネットワーク切断が回復した後の調整の問題。Eureka は純粋に一時的なインスタンスの登録モードを使用するため、永続性はなく、すべてのデータはクライアントのハートビート レポートを通じて補正できるため、Eureka のデプロイメント モードは当然、マルチ コンピュータ ルームの災害復旧をサポートします。上で述べたように、一時インスタンスと永続インスタンスの両方にそれぞれのアプリケーション シナリオがあります。これら 2 つのシナリオと互換性を持たせるために、Nacos は 2 つの展開モードをサポートしています。1 つは Eureka と同じ AP プロトコルの展開です。このモードは一時インスタンスのみをサポートします。インスタンスは、現在の Zookeeper と Eureka を完全に置き換えることができ、コンピューター ルームの災害復旧をサポートします。もう 1 つは永続インスタンスをサポートする CP モードで、この場合、デュアルルームの災害復旧はサポートされません。
リモート マルチアクティブに関して言えば、多くのビジネス コンポーネントのリモート マルチアクティブが、トラフィック スケジューリングやクラスター アクセス ルールの変更を含むサービス レジストリと構成センターによって実現されるのは偶然の一致です。コンピューター室での災害復旧は、さまざまな場所でのマルチアクティブの一部ですが、企業がサービス レジストリにアクセスするときにアクセスするクラスター ノードを動的に調整できるようにするには、ルーティング用のサードパーティ コンポーネントが必要です。さまざまな場所でのマルチアクティブは、すべての製品ラインを含む全体的な計画であることが多く、単一の製品がさまざまな場所でのマルチアクティブをサポートしているかどうかを判断することは困難です。
実際、マルチデータセンターは、さまざまな場所でのマルチリビングの一部とみなすことができます。単一の製品という観点から見ると、Zookeeper と Eureka は正式なマルチデータセンター ソリューションを提供していませんでした。Alibaba の内部経験に基づいて、Nacos は、Nacos-Sync コンポーネントを使用してデータセンター間でデータを同期するソリューションを提供します。これは、各データセンターの Nacos クラスターに複数のデータセンターからの完全なデータが含まれることを意味します。Nacos-Sync は、Nacos エコロジカル コンポーネントの重要な部分であり、Nacos クラスターと Nacos クラスター間のデータ同期を実行するだけでなく、Nacos クラスターと Eureka、Zookeeper、Kubernetes、および Consul の間のデータ同期も実行します。
8. ユーザーの拡張性
フレームワークの設計では、スケーラビリティが重要な設計原則です。Spring、Dubbo、Ribbon などのフレームワークは、ユーザーのスケーラビリティの点で比較的優れた設計を行っています。これらのフレームワークの拡張性では、多くの場合、ユーザー拡張インターフェイスを実行し、ユーザー定義ロジックを実装するために、インターフェイス指向や動的クラス読み込みなどのテクノロジが使用されます。サーバーの設計では、ユーザー拡張はより慎重になります。ユーザー拡張コードの導入は、元のサーバー サービスの可用性に影響を与える可能性があり、問題が発生した場合のトラブルシューティングがより困難になるためです。SPI を適切に設計することは可能ですが、その結果生じる安定性と運用上のリスクを慎重に考慮する必要があります。オープン ソース ソフトウェアでは、ユーザー拡張機能はコードを直接提供することによって実現されることが多く、優れた拡張機能は多くの人によって継続的に更新され、保守されます。これは比較的優れた開発モデルでもあります。Zookeeper と Eureka は現在、サーバー側でのユーザー拡張をサポートしていません。ユーザー拡張をサポートするサービス ディスカバリ製品は CoreDNS です。CoreDNS のアーキテクチャ全体はプラグインを介して直列に接続されており、プラグインのコードを CoreDNS プロジェクト配下に合意に配置して再構築することで、coreDNS 全体の機能リンクにプラグインを追加することができます。
では、そのような拡張性は必要なのでしょうか? 前述の例を挙げると、新しいヘルス チェック メソッドを追加し、データベースに接続して MySQL コマンドを実行する場合、コードに MySQL タイプのヘルス チェック メソッドを追加し、ビルド、テスト、および実行するのが一般的な方法です。ついにリリース。しかし、ユーザーが jar パッケージをアップロードしてサーバー展開ディレクトリのどこかに置くことが許可されており、サーバーがこの新しいヘルス チェック方法を自動的にスキャンして認識する場合はどうなるでしょうか? これはクールなだけでなく、拡張プロセス全体がサーバー コードから切り離され、非常にシンプルになります。したがって、システムの一部の機能については、注意深く設計することで実行時に拡張できるようにユーザーに公開できるのであれば、なぜそうしないのでしょうか。結局のところ、拡張サポートを追加しても、元の機能が失われることはありません。
すべての製品は、ユーザー ランタイム拡張機能をサポートするために最善を尽くす必要があります。そのためには、サーバー側の SPI メカニズムが十分に堅牢でフォールト トレラントになるように設計されている必要があります。この点で、Nacos はサードパーティ CMDB の拡張サポートを開始し、ヘルス チェックやロード バランシングなどのコア機能のユーザー拡張機能をまもなくオープンする予定です。ユーザーのさまざまなニーズを分離してサポートできるようにすることが目的です。
終わり
この記事は Nacos の機能を紹介する記事ではないため、Nacos の一部の機能については記事で取り上げていませんが、これらの機能は、Nacos がサポートする DNS プロトコルやカスタム ラベルなど、実際には Nacos を他のレジストリと区別する重要な側面です。他の機能。Nacos に少し詳しい読者は、Nacos の全体的なアーキテクチャが Consul のアーキテクチャにいくらか似ていることに気づくかもしれませんが、実際には、構成管理とサービス検出を一緒に展開することを除いて、Nacos と Consul には基本的に類似点はありません。 Consul との違いについては別の記事で説明します。Nacos のアーキテクチャと機能は、アリババ内での 10 年間の運用と進化の経験から導き出されたものであるため、両者を比較すると、両者の位置付けと進化の方向性がまったく異なることがわかるでしょう。
Nacos 2.0はGA版をリリースしており、今後もコミュニティとの共同構築という形で新機能をアウトプットし続け、サービスディスカバリと構成管理の2つの分野での育成を続けてまいります。最適なサービス検出および構成管理プラットフォームを構築できます。