記事ディレクトリ
サービス (Service) とサービス インスタンス (インスタンス)
- サービス ディスカバリでは、サービスはアプリケーションによって提供されるソフトウェア機能 (ログインや支払いなど) を抽象化したものです。サービスはアプリケーションとは異なり、適用範囲が広く、アプリケーション包含関係に属し、アプリケーションは複数のサービスを提供できます。
- サービスをきめ細かいレベルで区別して制御するために、Nacos はレジストリの最も基本的な概念としてサービスを選択します。
- サービス インスタンスは、サービスの特定のプロバイダー ノードです。インスタンスは 1 つのサービスのみに属し、サービスには 1 つ以上のインスタンスを含めることができます。
- 多くのシナリオでは、インスタンスはサービス プロバイダーとも呼ばれ、サービスを使用するインスタンスはサービス コンシューマーです。
- Nacos はサービスを登録センターの基本単位とみなし、インスタンスはサービスの特定のプロバイダー ノードです。インスタンスは 1 つのサービスにのみ属し、サービスには複数のインスタンスを含めることができます。
- インスタンスはサービスプロバイダーとも呼ばれ、インスタンスを使用する人はサービスコンシューマーです。
サービスを定義する
- ネームスペース(ネームスペース): Nacos データ モデルの最上位かつ最も包括的な概念。環境やテナントなどの強制的な分離が必要なシナリオで定義するために使用されます。Nacos サービスも分離のために名前空間を使用する必要があります。
- グループ化(グループ): 名前空間よりも劣る Nacos データ モデルの分離概念。名前空間の必須分離属性とは異なり、グループ化は弱い分離概念であり、主に一部のサービス使用シナリオまたは異なるアプリケーションを論理的に区別するために使用されます。同じ名前のサービスを使用する場合、最も一般的に使用されるケースは、同じサービスのテスト グループと運用グループ、または異なるアプリケーションによって提供されるサービスが同じ名前を持つことを防ぐためにアプリケーション名をグループとして使用する場合です。
- サービス名(名前): サービスの実際の名前。通常、サービスが特定の機能または機能を提供することを説明するために使用されます。
一般に、サービスの自然な一意性を確保するために、名前空間として動作環境、グループとしてアプリケーション名、サービス名としてサービス機能を組み合わせて使用することをお勧めします。もちろん、ユーザーは名前空間とグループ化を無視することもできます。、サービスの一意性としてサービス名のみを使用します。これには、ユーザーがサービス名を定義するときに独自のルールを追加して、間違ったサービスを見つけることなく使用中のサービスを一意に特定できるようにする必要があります。
サービスメタデータ
サービス定義は、サービスを説明し、便利かつ迅速にサービスを見つけるために、サービスのいくつかの基本情報を設定するだけですが、サービス メタデータは、Nacos 内のサービスの詳細な属性と説明情報をさらに定義します。主に以下が含まれます：
- 健全性保護しきい値 (ProtectThreshold): インスタンスの障害が多すぎると、すべてのトラフィックが残りのインスタンスに流れ込み、トラフィックの圧力が残りのインスタンスを圧倒して雪崩効果を形成することを防ぐため。健康保護のしきい値は、0 ～ 1 の浮動小数点数として定義する必要があります。サービス インスタンス全体に対するドメイン名の正常なインスタンスの割合がこの値より小さい場合、インスタンスが正常であるかどうかに関係なく、インスタンスがクライアントに返されます。この方法で一部のトラフィックが失われますが、クラスター内の残りの正常なインスタンスが正常に動作できることが保証されます。
- インスタンス セレクター (セレクター): サービス配下のインスタンス リストを取得する際に、インスタンスをフィルター処理するために使用されます。セレクターはルーターとも呼ばれます。現在、Nacos は、一部のインスタンス情報を外部メタデータ管理 CMDB に保存し、CMDB に保存されているメタデータ タグを使用してサービスを検出するときにフィルターする機能をサポートしています。
- 拡張データ (extendData): ユーザーがインスタンスを登録するときに拡張メタデータの内容を KV 形式でカスタマイズするために使用されます。サービス内のサービスのメタデータ情報を拡張できます。これは、ユーザーが独自のカスタム ロジックを実装するのに便利です。
インスタンスを定義する
サービス インスタンスは特にサービスを提供するノードであるため、Nacos はインスタンスの定義を設計するときに主にインスタンスの基本的なネットワーク関連情報を保存する必要があります。これには主に次の内容が含まれます。
- ネットワーク IP アドレス: インスタンスの IP アドレス。Nacos2.0 バージョン以降はドメイン名として設定できます。
- ネットワークポート: インスタンスのポート情報。
- 健全: インスタンスが健全な状態にあるかどうかを示すために使用され、ヘルス チェックを通じて Nacos で維持されます。特定の内容については、Nacos ヘルス チェック メカニズムの章で詳しく説明されます。読者は、次の内容の意味のみを必要とします。プレゼントできます。
- クラスター (クラスター): インスタンスがどの論理クラスターに属しているかをマークするために使用されます。
- 拡張データ (extendData): KV 形式のユーザー定義拡張子のメタデータ コンテンツ。インスタンスのメタデータ情報はインスタンス内で展開できるため、ユーザーが独自のカスタム ロジックを実装してインスタンスをマークするのに便利です。
インスタンスのメタデータ
インスタンスメタデータは、サービスメタデータとは異なり、主にインスタンスの運用や保守に関するデータ情報に使用されます。主に以下が含まれます：
- 重み: インスタンスレベルの構成。重みは、0 ～ 10000 の範囲の浮動小数点数です。重みが大きいほど、インスタンスに割り当てられるトラフィックも大きくなります。
- オンライン ステータス (有効): インスタンスがトラフィックを受け入れるかどうかをマークします。優先度は重量や健全性ステータスよりも高くなります。これは、インスタンス自体を変更せずに、サービスからインスタンスを迅速かつ手動で削除するために運用および保守担当者によって使用されます。
- 拡張データ(extendData): インスタンス定義の拡張データとは異なり、運用保守担当者がインスタンス自体を変更することなく、インスタンスの拡張データを迅速に修正・追加することで、インスタンスの役割を実現するための拡張データです。運用および保守インスタンス。
Nacos2.0 バージョンでは、インスタンス データはインスタンス定義とインスタンス メタデータに分割されています。これは主に、これら 2 種類のデータが実際には同じインスタンスの 2 つの異なるシナリオ (開発および運用シナリオと運用および保守シナリオ) であるためです。
オンライン、オフライン、重みなどの属性については、インスタンスがすでに実行されている場合、運用および保守担当者がデータを手動で変更および保守する必要があると一般に考えられています。
ただし、通常の状況では、インスタンスが起動して登録された後は、IP、ポート、クラスターなどの情報は変更されません。
データのこれら 2 つの部分をマージすると、インスタンスの完全な情報を取得できます。これは Nacos1.0 バージョンのインスタンス データ構造でもあります。
永続的なプロパティ
Nacos は、永続的サービスと非永続的サービスの 2 種類のサービスを提供しており、それぞれ DNS のような基本的なサービス コンポーネント シナリオと上位層の実際のビジネス サービス シナリオで使用されます。
サービスがどのタイプのサービスであるかを示すために、サービスの作成時にサービスの永続属性を選択する必要があります。現在の動的サービス検出シナリオのほとんどが非永続サービス タイプ (Spring Cloud、Dubbo、Service Mesh など) であることを考慮して、Nacos はデフォルト値を非永続サービスに設定します。
Nacos2.0以降、永続属性の定義はサービスに抽象化されています。サービスは永続サービスまたは非永続サービスとしてのみ定義できます。一度定義が完了すると、サービス寿命が終了するまで変更できません。サイクル、永続的なプロパティ。
永続属性は、サービスとインスタンスのデータが Nacos によって永続的に保存されるかどうかに影響します。永続として設定すると、インスタンスは自動的に削除されなくなり、ユーザーは手動でインスタンスを削除する必要があります。
集まる
クラスターは、Nacos のサービス インスタンスのグループを論理的に抽象化したもので、サービスとインスタンスの間にあり、一部のサービス属性のシンクとインスタンス属性の抽象化です。
クラスターを定義する
Nacos では、ヘルスチェックに関する一部の情報とデータは主にクラスターに保存されます。
-
ヘルス チェック タイプ (HealthCheckType): 使用するヘルス チェックのタイプ (現在サポートされている: TCP、HTTP、MySQL)。ヘルス チェックをオフにするには NONE に設定します。
-
ヘルスチェックポート(HealthCheckPort): ヘルスチェックに使用するポートを設定します。
-
ヘルスチェックにインスタンスポートを使用するかどうか(UseInstancePort): インスタンスポートをヘルスチェックに使用する場合、上記で設定したヘルスチェックポートではなく、インスタンス定義のネットワークポートがヘルスチェックに使用されます。
-
拡張データ (extendData): KV 形式のユーザー定義拡張子のメタデータ コンテンツ。クラスターのメタデータ情報をカスタマイズおよび拡張できます。これは、ユーザーが独自のカスタム ロジックを実装してクラスターをマークするのに便利です。
[サービス&クラスター&インスタンス]
ライフサイクル
レジストリでは、インスタンス データはサービス インスタンスの状態にバインドされているため、サービス インスタンスの状態によって、レジストリ内のインスタンス データのライフ サイクルが直接決まります。サービスはインスタンスを抽象化したものであるため、ライフサイクルもサービス インスタンスの状態によって決まります。
サービスのライフサイクル
サービスのライフサイクルは比較的単純で、ユーザーが登録センターに対してサービス登録要求を開始することから始まります。
Nacosでは、サービスの登録を開始する方法として、サービスを直接作成する方法と、インスタンス登録時にサービスを自動作成する方法があり、前者は開始者がサービスのメタデータ情報の一部を指定することができます。作成中、後者のみ サービスはデフォルトのメタデータを使用して作成されます。
ライフサイクル中、ユーザーはサービスにサービス インスタンスを追加および削除でき、サービスのメタデータを変更することもできます。
ユーザーがサービスの削除リクエストを開始した場合、または一定期間内にサービスの下にインスタンスが存在しない場合 (正常かどうかに関係なく)、サービスはライフサイクルを終了し、次の作成を待ちます。
インスタンスのライフサイクル
インスタンスのライフサイクルは、インスタンスの登録リクエストから始まります。ただし、異なる永続属性に応じて、インスタンスのその後のライフサイクルは異なります。
-
永続インスタンスは、ヘルス チェックの状態を通じて正常な状態を維持しますが、インスタンスのライフ サイクルは自動的に終了しません。ライフ サイクルが終了する前に、永続インスタンスはデータを変更したり、その健全性を積極的に変更したりすることができます。州。永続インスタンスのライフサイクルを終了する唯一の方法は、インスタンスからログアウトする要求です。
-
永続的ではないインスタンスは、バージョンに応じてさまざまな方法で正常な状態を維持します。
Nacos1.0 のバージョンでは、定期的なハートビート リクエストを通じてコントラクトを更新しますが、一定期間内にコントラクトを更新するためのハートビートがない場合、非永続インスタンスはライフ サイクルを終了します。
Nacos2.0 のバージョンは、gRPC の長時間接続を通じて状態を維持します。接続が中断されると、非永続インスタンスはライフサイクルを終了します。
もちろん、非永続インスタンスは、インスタンスからのログアウト要求を通じてライフ サイクルをアクティブに終了することもできますが、長時間の接続とハートビートの更新が存在するため、以前のインスタンス データのライフ サイクルが長くなる可能性があります。終了および削除され、すぐにハートビートと永続的な接続の補償リクエストにより、インスタンスのライフサイクルが再び開始され、ログアウトが失敗したように見えます。
クラスターのライフサイクル
クラスターのライフ サイクルは比較的複雑で、クラスターはサービスとインスタンスの中間層であるため、クラスターのライフ サイクルはインスタンスとサービスの両方のライフ サイクルに関連します。
クラスターのライフサイクルは、クラスターの最初のインスタンスのライフサイクルと同時に始まります。インスタンスは、デフォルトのクラスターであってもクラスターに属している必要があるため、最初のインスタンスのライフサイクルが始まると、クラスターはライフサイクルの始まり。
クラスター内にインスタンスがない場合、クラスターのライフサイクルはすぐには終了しませんが、サービスのライフサイクルが終了するまで待ってからライフサイクルを一緒に終了します。
メタデータのライフサイクル
メタデータとそれに対応するデータ モデルは密接に関連しているため、メタデータのライフ サイクルは基本的に対応するデータ モデルと一致します。
ただし、メタデータは通常、運用保守担当者によってアクティブに操作されるデータであり、Nacos によって一定期間記憶されるため、メタデータのライフサイクルの終了は、対応するデータのライフサイクルの終了よりも遅れます。
この遅延期間中に対応するデータがライフ サイクルを再開した場合、メタデータのライフ サイクルはすぐにリセットされ、終了しません。
【各データのライフサイクル図】
