gRPCロングリンク、Nacos2.0アーキテクチャ設計および新しいモデルの詳細な解釈をサポート

著者| Yang Yi（Schiwon）NacosPMC
出典| AlibabaCloudネイティブパブリックNo.

ナコス入門

Nacosは、2008年にAlibabaのCobblestoneプロジェクトから始まりました。このプロジェクトは、マイクロサービスの分割とビジネスの中間段階の構築を完了しました。クラウドコンピューティングとオープンソース環境の台頭に伴い、2018年にオープンソースソフトウェア業界の影響を深く感じたため、決定しました。オープンソースのNacosは、Aliのサービス発見と配管管理の10年間の蓄積をエクスポートし、マイクロサービス業界の発展を促進し、企業のデジタル変革を加速します。

現在、Nacosは、主流のマイクロサービス開発言語と主流のサービスフレームワーク、およびDubooやSCAなどの構成管理フレームワークをサポートしており、coreDNSやsentinelなどのクラウドネイティブコンポーネントともドッキングしています。

クライアント言語は、Javaやgo pythonなどの主流言語と、リリースされたばかりのC＃およびC ++の公式バージョンをサポートしています。すべてのコミュニティ貢献者のサポートに感謝します。

Nacosは2年以上オープンソースであるため、より重要なマイルストーンバージョンのいくつかを含め、合計34のバージョンがリリースされました。Nacosはまだ非常に若く、改善の余地がたくさんあります。コミュニティとあらゆる分野のリーダーが一緒に構築することを歓迎します。

Nacos1.Xの構造と問題

次に、nacos1.xアーキテクチャと、より重要な問題の分析について説明します。まず、アーキテクチャ図を見てください。

Nacos1.Xアーキテクチャレベル

Nacos 1.Xは、アクセス、通信、機能、同期、永続性の5つのレイヤーに大別されます。

アクセスレイヤーは、ユーザーにとって最も直接的なインタラクションレイヤーであり、主にNacosクライアント、クライアントに依存するDubboとSCA、およびユーザー操作用のコンソールで構成されます。クライアントとコンソールは、サービスと構成の操作を実行し、HTTPOpenAPIを介して通信要求を開始します。

通信層は主にHTTPの短い接続要求モデルに基づいており、一部のプッシュ機能はUDPを介して通信します。

現在、機能にはサービスの検出と構成の管理が含まれています。このレイヤーは、実際にサービスと構成を管理するビジネスレイヤーです。

同期レイヤーには、データ同期用のAPモードDistroとCPモードRaftがあり、さまざまな用途を持つ最も単純なレベルの通知Notifyがあります。

• Distro：非永続サービスの同期モード。
• Raft：永続サービスの同期モード、およびDerbyを構成ストレージとして使用する場合の同期構成操作。
• 通知：MySQLを構成ストレージとして使用する場合は、他のノードにキャッシュを更新して構成プッシュを開始するように通知します。

永続性レイヤーNacosは、データ永続性構成情報、ユーザー情報、アクセス許可情報がMySQLまたはDerbyデータベースに保存され、永続的なサービス情報とサービスおよびインスタンスのメタデータ情報がローカルファイルシステムに保存されるように、MySQL、Derby、およびローカルファイルシステムを使用します。 。

Nacos1.Xアーキテクチャでのサービスモデル

サービス検出プロセスを通じて、Nacos1.Xアーキテクチャと現在のアーキテクチャに基づくNacosサービス検出モデルについて知ることができます。

Nacosクライアント登録サービスはOpenAPIを介してHttp登録サービスのリクエストを送信します。リクエストの内容はサービス情報とインスタンス情報をもたらします。通常、このステップはマイクロサービスフレームワークSCAとdubboによって完了されます。

サーバーはリクエストを受信すると、最初にContollerのデータ（IPが有効かどうか、サービス名が正しいかどうかなど）を読み取って検証します。検証に合格した後、サービスが初めて登録されると、Nacosはサーバー上にServiceオブジェクトを生成し、登録されたインスタンス情報をServiceオブジェクトに格納します。NacosサーバーにすでにServiceオブジェクトがある場合は、次に、新しく登録されたインスタンス情報がオブジェクトに直接保存されます。このサービスオブジェクトは、名前名+グループ+サービスの組み合わせによって一意性を保証します。

インスタンスがサービスに保存されると、2つのイベントがトリガーされます。イベントの1つはデータ同期に使用されます。Nacosサーバーは、DistroまたはRaftプロトコルを使用して、サービスが一時オブジェクトであるかどうかに応じて同期し、他のNacosに通知します。ノードのサービスが変更されました。別のイベントが、Nacosサービスノードでサービスにサブスクライブしたサブスクライバーに通知し、サブスクライバー情報に基づいてUDPを介してサブスクライバークライアントに最新のサービスリストをプッシュします。これでサービス登録プロセスは完了です。

さらに、永続サービスとして定義されているすべての情報について、raftプロトコルを使用して、ファイルシステムに書き込み、永続化できるようにします。

最後に、他のNacosノードもイベントをトリガーして、同期によってサービスが変更されたときにサブスクライバーに通知します。これにより、他のNacosサービスノードでサービスにサブスクライブするサブスクライバーもプッシュを受信できます。

1.Xアーキテクチャの問題

Nacos1.Xのアーキテクチャとサービス検出モデルの大まかな紹介、およびNacos1.Xアーキテクチャが直面するより重要な問題のいくつかを分析します。

一言で言えば、多くのハートビート、多くの無効なクエリ、ハートビート更新の認識の遅い変化、高い接続消費、および深刻なリソースの浪費があります。

• ハートビートの数が非常に多いため、TPSは高いままです

ハートビートの更新により、サービスの規模が大きくなると、特にDubboのようなインターフェイスレベルのサービスが増えると、ハートビートと構成メタデータのポーリング数が多くなり、クラスター内のTPSが高くなり、システムリソースの消費量が多くなります。

• ハートビートの更新、時間の延長を通じてサービスの変化を認識します

ハートビートの更新は、削除されてサブスクライバーに通知される前に、タイムアウト期間に達する必要があります。デフォルトは15秒で、時間の遅延が長く、適時性が低くなっています。タイムアウト期間が短くなると、ネットワークがジッターするときに変更プッシュが頻繁にトリガーされ、クライアントとサーバーの損失が大きくなります。

• UDPプッシュは信頼性が低く、QPSが高いままになります

UDPは信頼性が低いため、クライアントは定期的に調整クエリを実行して、クライアントによってキャッシュされたサービスリストのステータスが正しいことを確認する必要があります。サブスクリプションクライアントのサイズが大きくなると、クラスターQPSは非常に高くなりますが、ほとんどのサービスリストは実際にはそうではありません。頻繁に変更されるため、クエリが無効になり、リソースが浪費されます。

• HTTPショート接続モデルに基づくと、TIME_WAIT状態の接続が多すぎます

HTTPショート接続モデル、各クライアント要求はTCPリンクを作成および破棄し、TCPプロトコル破棄のリンク状態はWAIT_TIMEです。完全に解放されるまでに時間がかかります。TPSとQPSが高い場合、サーバーとクライアントには多くのWAIT_TIMEステータスリンクにより、接続タイムアウトエラーが発生するか、要求されたアドレスを割り当てることができませんという問題が発生します。

• 構成モジュールの30秒の長いポーリングによって引き起こされる頻繁なGC

構成モジュールは、HTTPショート接続ブロッキングモデルを使用してロング接続通信をシミュレートしますが、実際のロング接続モデルではないため、30秒ごとに要求とデータ間のコンテキスト切り替えが必要です。各切り替えによりメモリが浪費され、サーバー側で頻繁にGC。

Nacos2.0アーキテクチャと新しいモデル

Nacos2.0アーキテクチャレベル

Nacos 2.Xは、古いクライアントとopenAPIのコア機能のサポートを維持しながら、1.Xアーキテクチャに基づく永続接続モデルのサポートを追加します。

通信層は現在、gRPCとRsocketを介して長距離接続RPC呼び出しとプッシュ機能を実装しています。

サーバー側のテストでは、新しいリンクレイヤーが追加され、さまざまなタイプの要求要求とさまざまなクライアントからのさまざまな種類の要求が同じセマンティック機能データ構造に変換され、ビジネス処理ロジックが再利用されます。同時に、フロー制御や負荷分散などの将来の機能もリンク層で処理されます。

他のアーキテクチャレイヤーはほとんど変更されていません。

Nacos2.0の新しいサービスモデル

Nacos 2.0のアーキテクチャレベルはそれほど変更されていませんが、特定のモデルの詳細が大幅に変更されており、登録サービスプロセスは引き続き使用されており、Nacos2.0サービスモデルの変更についてより深く理解しています。

通信はRPC方式を使用するため、特定のクライアントのすべての要求（登録またはサブスクリプションに関係なく）は、HTTPを介した以前の接続とは異なり、同じリンクおよび同じサービスノードを介して実行されます。各要求は異なるNacosノードで要求される場合があります。その結果、サービスによって検出されたデータコンテンツは、ステートレスから、接続状態にバインドされた一種のステートフルデータに変更されました。この変更に対応するには、データモデルを変更する必要があります。そのため、新しいデータ構造が抽象化され、このリンクを介して同じクライアントによって公開およびサブスクライブされたコンテンツが関連付けられ、一時的にClientという名前になります。このクライアントはクライアントを意味するのではなく、このクライアントに関連するデータコンテンツを意味します。リンクはクライアントに対応します。

クライアントがサービスを公開すると、クライアントによって公開されたすべてのサービスとサブスクライバー情報が、クライアントリンクに対応するクライアントオブジェクトに更新され、イベントメカニズムを介してインデックス情報の更新がトリガーされます。このインデックス情報は、クライアントリンクとサービスのインデックスであり、プッシュする必要のあるサービス範囲のデータの迅速な集約と生成を容易にします。

インデックス情報が更新されると、プッシュイベントがトリガーされます。このとき、サービスに関連するすべてのクライアントオブジェクトは、新しく生成されたインデックス情報を介して集約されます。データ集約が完了すると、クライアントリンクがフィルタリングされ、サービスにサブスクライブされます。サブスクライバーのクライアントリンクは、リンクを介してデータをプッシュバックします。このようにして、変更を公開するためのメインリンクが完成します。

データ同期を振り返ると、クライアントがサービスを公開したときに実際に更新されたオブジェクトが元のサービスからクライアントオブジェクトに変更されたため、同期が必要なコンテンツもクライアントオブジェクトになり、同時にサーバー間の通信方法もRPCに変更されます。ここでは、クライアントによって実際に更新されたClientオブジェクトのみが同期をトリガーし、同期によって更新されたClientオブジェクトは再び同期をトリガーしません。

最後に、メタデータを見てください。メタデータは、サービスのメタデータラベル、インスタンスのオンラインとオフラインのステータス、重み、メタデータラベルなど、1.Xバージョンのサービスオブジェクトとインスタンスオブジェクトから分離されたいくつかの属性です。これらのメタデータは、openAPIによって個別に変更でき、データが集約されたときに有効になります。メタデータが基本データから分離されている理由は、ipポート、サービス名などの基本データは公開後に変更してはならず、公開時の情報が優先されるためですが、その他の元のデータ（通常、オンラインとオフラインのステータスと重みは操作中に動的に調整されます。したがって、分離後は、2つの異なる処理ワークフローに分割する方が合理的です。

Nacos2.0アーキテクチャの長所と短所

Nacos 2.0のアーキテクチャと新しいモデルの仕組みを簡単に紹介しました。次に、このような変更の長所と短所を分析しましょう。

利点

• クライアントはインスタンスのハートビートを定期的に送信する必要がなくなり、接続を維持するためにキープアライブメッセージを使用できるようにするだけで済みます。繰り返されるTPSを大幅に減らすことができます。

• TCP接続の切断をすばやく検出できるため、応答速度が向上します。

• 長い接続でのストリーミングプッシュはUDPよりも信頼性が高く、nioのメカニズムはスループットが高く、信頼性の高いプッシュにより、クライアントの調整サービスリストの時間を長くし、関連する要求を削除することさえできます。繰り返される無効なQPSを大幅に減らすことができます。

• 長い接続は頻繁な接続オーバーヘッドを回避し、TIME_WAITの問題を大幅に軽減できます。

• 本当に長い接続は、構成モジュールのGCの問題を解決します。

• よりきめ細かい同期コンテンツにより、サービスノード間の通信圧力が軽減されます。

不利益

特効薬の解決策がなければ、新しいアーキテクチャはいくつかの新しい問題も引き起こします。

• 内部構造の複雑さが増し、接続ステータスが管理され、接続の負荷バランスを管理する必要があります。

• 元のステートレスデータは接続にバインドされたステートフルデータになり、プロセスリンクは長くなります。

• RPCプロトコルはHTTPほど観察可能ではありません。gRPCがHTTP2.0Streamに基づいて実装されている場合でも、HTTPプロトコルを直接使用するほど直感的ではありません。

Nacos2.X計画

次に、Nacos 2.Xのその後の計画について簡単に説明します。これは、主にドキュメント、品質、ロードマップに分かれています。

ドキュメントと品質の点で、Nacos1.Xはあまりうまくいきませんでした。ドキュメントの内容は小さく、使いやすいだけです。バージョンとは関係がなく、更新もタイムリーではありません。技術的な内容の説明がなく、投稿に参加するのは困難です。codeStyleはcheckstyleを使用して検証されており、コミュニティの共同レビューが開始されていますが、コードの品質とテストの品質はそれほど高くありません。しかし、これでは十分とは言えません。Nacos 2.Xは、公式Webサイトのドキュメントを徐々に更新および改良し、電子書籍を通じて技術的な詳細を分析し、Githubを通じて技術的なソリューションを表示して、議論と貢献を促進します。また、多数のコードの再構築とUTおよびITガバナンスの作業、将来的には、ベンチマークはオープンソースユーザーのストレステストを容易にするためにオープンソースにもなります。

RoadMapに関しては、Nacos 2.Xはプロジェクトを大幅にリファクタリングし、最初のプラグインを完了し、負荷分散や可観測性など、2.0アーキテクチャのいくつかの欠点を改善します。

著者について

ヤン・イー、花の名前はシー・ウェン。Nacos PMCは、主にサービス検出モジュールに関与し、カーネルのリファクタリングとアップグレードを行います。モジュールを主に担当し、参加しているApache SharadingSphere PMCには、ルーティングモジュール、分散トランザクション、データ同期、およびエラスティック拡張が含まれます。