記事ディレクトリ
バックグラウンド
モノリシック アーキテクチャでは、構成を構成ファイルに書き込むことができますが、構成を変更するたびにサービスを再起動して有効にする必要があるという欠点があります。
アプリケーション インスタンスが比較的小さい場合にも維持できます。マイクロサービス アーキテクチャに数百または数千のインスタンスがある場合、構成が変更されるたびにすべてのインスタンスを再起動する必要があり、システムの不安定性が増すだけでなく、メンテナンスのコストも増加します。
では、サービスを再起動せずに構成を変更するにはどうすればよいでしょうか? これらすべてから 4 つの基本的な要求が生じます。
動的な構成変更をサポートする必要がある
動的変更はどの程度リアルタイムである必要があるか
グレースケールやロールバックなど、変更後の変更リスクをどのように制御し、より迅速に制御するか。
機密性の高い構成のセキュリティを構成する方法
コンセプト紹介
構成
システム開発プロセス中、変更が必要な一部のパラメータや変数は通常、コードから分離されて独立して管理され、独立した設定ファイルの形式で存在します。その目的は、静的なシステム成果物や成果物 (WAR、JAR パッケージなど) を実際の物理的な動作環境によりよく適応させることです。
構成管理は通常、システム展開のプロセスに含まれており、このステップはシステム管理者または運用保守担当者によって実行されます。構成の変更は、実行時のシステムの動作を調整する効果的な手段の 1 つです。
構成管理
Nacos では、システム内のすべての構成の保存、編集、削除、グレースケール管理、履歴バージョン管理、変更監査などの構成関連のすべてのアクティビティを総称して構成管理と呼びます。
構成サービス
サービスまたはアプリケーションの実行中に動的な構成またはメタデータと構成管理を提供するサービス プロバイダー。
設定項目
特定の構成可能なパラメータとその値の範囲は、通常、param-key = param-value の形式で存在します。
たとえば、システムのログ出力レベル (logLevel = INFO | WARN | ERROR) を構成することがよくあります。これは構成項目です。
構成セット
関連するまたは無関係な構成アイテムの集合を構成セットと呼びます。
システムでは、構成ファイルは通常、システムのあらゆる側面の構成を含む構成セットです。たとえば、構成セットには、データ ソース、スレッド プール、ログ レベルなどの構成アイテムが含まれる場合があります。
名前空間
テナントの詳細な構成の分離に使用されます。同じグループまたはデータ ID の構成は、異なる名前空間に存在できます。
ネームスペースの一般的なシナリオの 1 つは、開発およびテスト環境と運用環境の間のリソース (データベース構成、電流制限しきい値、ダウングレード スイッチなど) の分離など、さまざまな環境の構成を区別して分離することです。
名前空間が指定されていない場合は、デフォルトでパブリック名前空間が使用されます。
構成グループ (グループ)
Nacos の構成セットのセットは、構成ディメンションの 1 つです。同じデータIDを持つ構成セットを区別するために、構成セットを意味のある文字列でグループ化します(ABTestの実験グループと対照グループなど)。
Nacos で構成を作成するときに、構成グループの名前を入力しない場合、構成グループの名前はデフォルトで DEFAULT_GROUP になります。
構成グループ化の一般的なシナリオ: 異なるアプリケーションまたはコンポーネントが、database_url 構成や MQ_Topic 構成などの同じ構成項目を使用します。
構成ID（データID）
Nacos で設定された構成の ID。構成セット ID は、構成を分割するための次元の 1 つです。データ ID は、システムの構成セットを区別するためによく使用されます。
システムまたはアプリケーションには複数の構成セットを含めることができ、各構成セットは意味のある名前で識別できます。データ ID は可能な限りグローバルに一意であることが保証されており、Nacos Spring Cloud の命名規則を参照できます。
${
prefix}-${
spring.profiles.active}-${
file-extension}
構成スナップショット
Nacos のクライアント SDK は、構成のスナップショットをローカルに生成します。クライアントが Nacos Server に接続できない場合、構成スナップショットを使用して、システム全体の災害復旧機能を表示できます。
構成スナップショットは Git のローカル コミットに似ており、適切なタイミングで更新されるキャッシュにも似ていますが、キャッシュの有効期限という概念はありません。
Nacos 構成モデル
ベースモデル
- Nacos は、設定の公開、更新、削除、グレースケール、バージョン管理、その他の機能を実行できるビジュアル コンソールを提供します。
- SDK は、構成の公開、構成の更新、構成の監視などの機能を提供できます。
- SDK は GRPC の長い接続を通じて構成変更を監視し、サーバー側はクライアント側で構成された MD5 がローカル MD5 と等しいかどうかを比較し、等しくない場合は構成変更をプッシュします。
- SDK は構成のスナップショットを保存し、サーバーに問題が発生した場合にそれをローカルに取得します。
リソースモデルを構成する
名前空間はリソースの分離を目的として設計されており、リソースを構成する際には次の 2 つの観点から名前空間を検討できます。
- 単一テナントの観点からは、複数の環境構成を構成する必要があり、さまざまな環境に応じて名前空間を作成できます。たとえば、開発環境、テスト環境、オンライン環境で、対応する名前空間 (dev、test、prod) を作成すると、Nacos が対応する名前空間 ID を自動的に生成します。同じ環境で同じ構成を構成する場合は、グループを使用して区別できます。以下に示すように:
- 複数のテナントの観点から見ると、各テナントは独自の名前空間を持つことができます。ユーザーごとに名前空間を作成し、複数のテナント (zhangsan、lisi、wangwu) などのユーザーに対応するアクセス許可を割り当てることができます。各テナントは独自のマルチ環境構成のセットを必要とします。つまり、各テナントが構成する必要があります。複数の環境。次に、テナントごとに名前空間 (zhangsan、lisi、wangwu) を作成できます。対応する名前空間 ID も生成されます。次に、グループを使用して、さまざまな環境の構成を区別します。以下に示すように
構成保存モデル (ER 図)
Nacos ストレージ構成には、いくつかの重要なテーブルがあります。
config_info 構成情報を格納するためのメインテーブル。dataId、groupId、content、tenantId、encryptedDataKey およびその他のデータが含まれます。
config_info_beta はグレースケールテストの構成情報テーブルであり、格納内容は基本的に config_info と同様です。クライアントが設定を要求したときに、グレースケール IP であるかどうかを判断するための beta _ips フィールドがあります。
config_tags_relation 設定されたタグテーブル。設定の公開時にタグが指定されている場合、タグと設定の間の関連情報がこのテーブルに格納されます。
his_config_info 構成履歴情報テーブルには、構成のリリース、更新、削除などが行われたときにデータが記録され、マルチバージョン管理や迅速なロールバックに使用できます。
