構成センターの紹介
Spring Cloud Config は、分散システムの外部構成のためのサーバー側およびクライアント側のサポート ソリューションを提供します。サーバー側の構成は、すべての環境でアプリケーションの外部プロパティを管理できる中心的な場所です。クライアントとサーバーの Spring Environment と PropertySource の抽象化は同期が保たれ、Spring アプリケーションに適していますが、任意の言語で実行されているアプリケーションで使用できます。アプリケーションが開発からテスト、本番環境へと展開パイプラインを移動する際に、これらの環境間の構成を管理し、アプリケーションが移行時に実行するために必要なものがすべて揃っていることを確認できます。サーバーのストレージ バックエンドのデフォルトの実装は git を使用するため、タグ付きのバージョン管理された構成環境を簡単にサポートし、コンテンツを管理するためのさまざまなツールからアクセスできます。代替実装を追加して、Spring 構成でプラグインするのは簡単です。Spring Cloud Config は、クライアントとサーバーの 2 つの部分で構成されます. サーバーは、構成ファイルのストレージを提供し、構成ファイルの内容をインターフェイスの形式で提供します. クライアントは、インターフェイスを介してデータを取得し、それに基づいて独自のアプリケーションを初期化しますこのデータ。Spring クラウドは git または svn を使用して構成ファイルを保存します。デフォルトでは git が使用されます。
Nacos は Config を置き換えます
Nacos は、Spring、Spring Boot、Spring Cloud と統合でき、Spring Cloud Eureka、Spring Cloud Config を置き換えることができます。動的な構成変更は、Nacos サーバーと spring-cloud-starter-alibaba-nacos-config によって実現されます。
適用シナリオ
システム開発プロセス中、開発者は通常、変更が必要ないくつかのパラメーターと変数をコードから分離して管理し、独立した構成ファイルの形式で存在します。その目的は、静的なシステム アーティファクトまたは成果物 (WAR、JAR パッケージなど) を実際の物理的な動作環境によりよく適合させることです。構成管理は、通常、システム展開のプロセスに含まれ、システム管理者または運用保守担当者によって完了されます。構成の変更は、実行時のシステムの動作を調整する効果的な手段です。統合された構成センターがマイクロサービス アーキテクチャで使用されていない場合、既存の問題: - 構成ファイルがさまざまなプロジェクトに散らばっており、維持するのが不便です - 構成コンテンツのセキュリティと権限 - 構成を更新した後、プロジェクトは nacos を再起動する必要があります構成センター: システム構成 集中管理 (編集、保存、配布)、再起動なしの動的更新、ロールバック構成 (変更管理、履歴バージョン管理、変更監査) およびその他の構成関連の活動。
ナコス使用
まずはこちらでマイクロサービスプロジェクトを用意して練習用プロジェクトを準備
naocs-依存関係
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>構成ファイルで構成します。
まず nacos を起動します。これが nacos のウィンドウ バージョンです。
スタートアッププロジェクト
プロジェクト起動後のポート番号が上記で設定したポートと一致しているか確認
ブラウザにNacos のアクセスアドレスhttp://localhost:8848/nacosを入力し 、デフォルトのアカウントパスワードを入力します (どちらも nacos です)
ログインすると、サービス一覧に、先ほど設定ファイルで設定したサービス名が一覧に表示され、登録が成功したことがわかります
ここで、nacos に構成ファイルを作成します。
ローカル プロジェクトの構成ファイルの内容をすべてコメント アウトします。
サービスの pom ファイルに依存関係を追加する
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>補足：springbootの設定ファイルの読み込み順
実際、yml ファイルとプロパティ ファイルは同じ原理であり、プロジェクトには yml またはプロパティのいずれかがあり、2 つのうちの 1 つが存在します。より簡潔な yml を使用することをお勧めします。org.springframework.cloud spring-cloud-starter-alibaba-nacos-config #設定センターのアドレス spring.cloud.nacos.config.server-addr=127.0.0.1:8848 #spring.profiles.active=dev #この設定は Unity に影響します構成センターの dataId spring.application.name=service-statistics 1 2 3 4 1 2 3 4 5 6 7 ブートストラップとアプリケーション (
1) ロード順 アプリケーションとブートストラップのロード順を中心に説明します。bootstrap.yml (bootstrap.properties) は最初に application.yml (application.properties) をロードし、次にアプリケーション コンテキストのブートストラップ フェーズ用に bootstrap.yml をロードします。bootstrap.yml は、親 Spring ApplicationContext によってロードされます。親の ApplicationContext は、application.yml を使用する前に読み込まれます。
(2) 設定の違い パラメータの設定には、bootstrap.yml と application.yml の両方を使用できます。bootstrap.yml は、システム レベルでのいくつかのパラメーター構成として理解でき、これらのパラメーターは通常変更されません。application.yml を使用して、アプリケーション レベルを定義できます。
bootstrap.properties ファイルを作成する
プロジェクトを再開する
プロジェクトのポート番号が nacos で構成されたポート 8777 を読み取ることがわかります。これは、プロジェクトが nacos の構成ファイルを正常に読み取ったことを示しています。
ブートストラップ構成ファイルで開く
spring.profiles.active=dev
nacos で spring.profiles.active=dev 構成ファイルを作成します。
構成ファイルを発行してプロジェクトを再起動する
この時点で 8666 が読み取られていることがわかります。これは、新しく作成された構成ファイルです。
名前空間切り替え開発構成環境
実際の開発では通常、複数の異なる環境セット (デフォルトは public のみ) が存在するため、この時点で、指定された環境に応じて異なる名前空間を作成できます。 nacos のセットを使用する クラスターは、次の 3 つの異なる名前空間をそれぞれ構築できます。複数環境の分離を実現するために
nacos で 3 つの名前空間 dev test prod を作成します
構成リスト内の構成ファイルの複製
区別を容易にするために、複製したばかりの dev 構成ファイルのポート番号を 8555 に変更しました。
ブートストラップ構成ファイルに読み取り開発構成を追加します
spring.cloud.nacos.config.namespace=795de664-a841-4a11-bf25-3b6acdf90ee6
プロジェクトを再開する
この時のプロジェクトのポート番号は dev のポート 8555 を読み取ることがわかります
複数の構成ファイルをロードする
プロジェクト内の複数の構成ファイルを読み取る必要がある場合があり、各構成ファイルは特定の構成に配置されます
nacos の dev 名前空間で、ポート番号のみを格納する新しい構成ファイル port.properties を作成し、元の dev 構成ファイルのポート番号を今すぐコメント アウトします。
ブートストラップ構成ファイルにポート構成ファイルの読み取りを追加
spring.cloud.nacos.config.ext-config[0].data-id=port.properties spring.cloud.nacos.config.ext-config[0].refresh=true
プロジェクトを再開する
このとき、ポート設定ファイルでポート番号が 8444 になっていることがわかります