前回の記事では、登録センターとしてのNacosの使用法を紹介しました。また、Nacosは構成センターとしても使用できます。次に、この記事では、構成センターとしてのNacosの基本的な使用法を紹介します。まず、なぜ使用する必要があるのかを理解しましょう。構成センター。
1.構成センターが必要な理由:
構成センターがなくなる前は、従来のアプリケーション構成には次の問題点があります。
(1)ローカルの静的構成を使用すると、リアルタイムのパフォーマンスは保証されません。構成の変更は柔軟性がなく、長いテストとリリースサイクルが必要であり、クライアントにできるだけ早く通知することはできません。一部の構成では、リアルタイムの要件が高くなります。アクティブスタンバイスイッチング構成などの時間パフォーマンス。または、障害が発生した場合に構成を変更する必要があります。この場合、従来の静的構成または再リリース方法を使用して構成を構成するため、応答速度は次のようになります。非常に遅く、ビジネスリスクは非常に大きいです。
(2)本番環境での事故が発生しやすい:たとえば、公開する場合、テスト環境の構成を本番環境に移行しやすく、本番環境での事故が発生しやすくなります。
(3)構成が散在しており、形式が標準ではありません。プロパティ形式を使用するもの、xml形式を使用するもの、DBを格納するものがあります。チームは独自のホイールを作成する傾向があり、さまざまな方法があります。
(4)構成には、セキュリティ監査、バージョン管理、および構成許可制御機能がありません。誰ですか。何時に?どの構成が変更されましたか?トレースバックする方法はなく、問題が発生した場合に以前のバージョンにロールバックする方法もありません。構成変更のリリースを認証および承認する方法はなく、誰でも構成を変更およびリリースできます。 。
構成センターは、構成情報をシステムの隅々まで配布する従来の方法とは異なり、個々のサーバーを1つずつ管理するのではなく、システム内の構成ファイルを一元的かつ均一に管理します。では、これを行うことの利点は何ですか?
(1)構成センターを通じて、構成の標準化とフォーマットの統一が可能
(2)構成情報が変更されると、変更がリアルタイムで有効になり、サーバーを再起動せずに対応する変更を自動的に検知し、新しい変更を対応するプログラムに統一的に送信して、変更に迅速に対応できます。 。たとえば、特定の機能は特定の地域のユーザー専用であり、特定の機能は大規模なプロモーション期間中にのみ使用できます。構成センターを使用した後は、基本的に、関係者のみが構成センターのパラメーターを動的に調整する必要があります。リアルタイムまたは準リアルタイムで対応するビジネスを調整します。
(3)問題は監査機能を介して追跡することもできます
次に、Nacos構成センターの使用:
マイクロサービスの構成センターには、Nacos、Apollo、Config + Busの3つの主要なソリューションがありますが、この記事では、主に構成センターとしてのNacosの使用法を紹介します。他の2つの方法に関心のある読者は、インターネット自体。
1.SpringbootはNacos構成センターを統合します。
(1)まず、プロジェクトのバージョン情報を宣言します。
<properties>
<spring-boot.version>2.3.2.RELEASE</spring-boot.version>
<spring-cloud.version>Hoxton.SR9</spring-cloud.version>
<spring-cloud-alibaba.version>2.2.6.RELEASE</spring-cloud-alibaba.version>
</properties>
<!-- 只声明依赖,不引入依赖 -->
<dependencyManagement>
<dependencies>
<!-- 声明springBoot版本 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${spring-boot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!-- 声明springCloud版本 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!-- 声明 springCloud Alibaba 版本 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-dependencies</artifactId>
<version>${spring-cloud-alibaba.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
(2)nacos構成センターのMaven依存関係を追加します。
<!-- SpringCloud Ailibaba Nacos Config -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
(3)nacos構成センターの関連する構成をapplication.propertiesファイルに追加します。
spring.profiles.active=dev
spring.application.name=cloud-producer-server
server.port=8080
# nacos 配置中心地址
spring.cloud.nacos.config.server-addr=localhost:8848
# 配置文件的类型
spring.cloud.nacos.config.file-extension=yaml
(4)nacosコンソールでDataIDcloud-producer-server-dev.yamlを使用して新しい構成セットを作成します。
DataIDの名前がcloud-producer-server-dev.yamlである理由を以下に説明します
(5)テストクラスを作成します。
//配置发布之后,动态刷新配置
@RefreshScope
@RestController
@RequestMapping("provider")
public class ProviderController
{
// 使用原生注解@Value()导入配置
@Value("${user.id}")
private String id;
@Value("${user.name}")
private String name;
@Value("${user.age}")
private String age;
@GetMapping("getNacosConfig")
public String providerTest()
{
return "我是provider,已成功获取nacos配置中心的数据:(id:" + id + ",name:" + name + ",age:" + age +")";
}
}
(6)サービス検証を開始します。
プロジェクトを開始し、http:// localhost:8080 / Provider / getNacosConfigインターフェイスにアクセスすると、nacos構成センターの構成情報が有効になり、正常に取得されていることがわかります。
(7)動的リフレッシュ構成を確認します。
構成の動的更新は、構成センターのコア機能の1つです。ここで、user.nameの値を変更する必要がある場合、Nacosの構成を直接変更して有効にしますか?以下に示すように、Nacosの構成を「zhangsan」に直接変更してみましょう。
この時点では、プロジェクトを再起動してインターフェイスに再度アクセスしないでください。結果は次のようになります。
構成が動的に更新されていることがわかりましたが、これはなぜですか?実際、これは@RefreshScopeアノテーションをクラスに追加した効果によるものです。
//配置发布之后,动态刷新配置
@RefreshScope
@RestController
@RequestMapping("provider")
public class ProviderController
2. Nacosのコアコンセプト:
2.1、データID:
(1)データIDの命名形式:
以前、nacosコンソールでDataID cloud-producer-server-dev.yamlを使用して新しいデータセットを作成する方法を示しましたが、このデータIDは何ですか?データIDは、構成セットの一意の識別子です。アプリケーションには複数の構成セットを含めることができ、各構成セットは意味のある名前で識別する必要があります。では、データIDはどのようにして値を取得するのでしょうか。一般的な形式は、次のように「prefix-environment-extension」です。
${spring.cloud.nacos.config.prefix}-${spring.profiles.active}。${spring.cloud.nacos.config.file-extension}
①プレフィックス:プレフィックス。デフォルトはspring.application.nameの値です。または、構成アイテムspring.cloud.nacos.config.prefixを使用して構成できます。
# 若不指定,默认采用应用名的方案
spring.application.name=cloud-producer-server
# 手动指定配置的dataID前缀标识
# spring.cloud.nacos.config.prefix=cloud-producer-server-config
②アクティブ:現在の環境に対応するプロファイルである動作環境を設定します。
注:spring.profiles.activeが空の場合、対応するコネクタ「-」も存在せず、dataIdのスプライシング形式は${prefix}。${file-extension}になります。
# dev表示开发环境
spring.profiles.active=dev
③file-exetension:構成ファイルのタイプ。デフォルトはプロパティです。構成アイテムspring.cloud.nacos.config.file-extensionを使用して構成することもできます。現在サポートされているタイプは、TEXT、JSON、XML、YAML、 HTML、プロパティ
# 指定配置文件类型为yaml文件
spring.cloud.nacos.config.file-extension=yaml
④最終構成:
最初の3つの手順の後、最終的に新しい構成ファイルをnacos構成センターのコンソールに追加しました:cloud-producer-server.yaml
2.2。環境の分離-名前空間の名前空間:
Nacosは、マルチ環境の構成とサービスを管理および分離するための名前空間の概念を導入しています。たとえば、ローカル開発環境dev、テスト環境テスト、および実稼働環境prodの3つの異なる環境がある場合、異なる環境を区別するために3つの異なる名前空間を作成できます。次のように作成されました:
作成が完了すると、以下に示すように、Nacosコンソールの構成リストにさまざまな名前空間が表示されます。
新しい名前空間が正常に作成されたら、springbootの構成ファイルで名前空間のIDを構成して、対応する名前空間に切り替え、対応するスペースで構成ファイルを取得できますが、名前空間の構成が指定されていない場合、デフォルトの構成はIs inパブリックスペースの場合、名前空間を指定する方法は次のとおりです。
# 对应创建的命名空间的ID,此处对应的是dev命名空间
cloud.nacos.config.namespace=483bb765-a42d-4112-90bc-50b8dff768b3
2.3。ビジネスの分離-グループのグループ化:
グループは環境分離の機能も実現できますが、グループ設計の目的は、同じ環境内の異なるサービスをグループ化し、異なるマイクロサービスの構成ファイルを同じグループに分割することです。Nacosがグループを指定しない場合、デフォルトのグループ化DEFAULT_GROUPです。
グループがない場合は、このシナリオを想像してください。1つは注文システムでもう1つはユーザーシステムの2つのマイクロサービスがありますが、datasource-urlなどの構成は同じなので、どのように区別しますか?ここでグループが役に立ちます。上記のシナリオでは、注文システムとユーザーシステムをORDER_GROUP、USER_GROUPなどのグループに分割できます。もちろん、これは比較的きめ細かいグループ化であり、複数のマイクロサービスもビジネスに応じてグループに分割できます。企業の。
次に、構成セットを作成するときと統合するときにグループを指定する方法を示します。前の例では、新しい構成セットは次の場所でグループグループを指定します。
application.propertiesファイルの次のグループ:
spring.cloud.nacos.config.namespace=483bb765-a42d-4112-90bc-50b8dff768b3
3.要約:
Nacosが構成管理と動的構成更新を実装するのは非常に簡単です。手順は次のように要約されます。
- ①対応するspring-cloud-starter-alibaba-nacos-config依存関係を追加します
- ②ネイティブアノテーション@Value()を使用して構成をインポートします
- ③ネイティブアノテーション@RefreshScopeを使用して構成を更新します
- ④独自のビジネスシナリオに応じて、マルチ環境構成の分離(名前空間)とさまざまなビジネス構成の分離(グループ)をうまく実行します
4.共有構成:
マイクロサービスの数が増えると、同じ構成になります。このとき、クラスター内のデータソース情報、クラスター内の構成情報など、プロジェクトの共通構成と同じ構成を抽出できます。ログ、およびnacosもあります。1つの構成センターで複数の構成セットを書き込むこの方法がサポートされています。
(1)nacosにデータIDdb.yamlとlog.yamlの2つのファイルを作成します。
(2)構成ファイルにそれぞれ構成内容を追加します
(3)次のnacos構成をSpringbootプロジェクトに追加します。
spring:
cloud:
nacos:
config:
extension-configs[0]:
data-id: db.yaml
# 默认为DEFAULT_GROUP
group: DEFAULT_GROUP
# 是否动态刷新,默认为false
refresh: true
extension-configs[1]:
data-id: log.yaml
group: DEFAULT_GROUP
refresh: true
複数のアプリケーション間で共有データIDをより明確に構成するために、公式の推奨事項は、shared-configsを使用することです。構成は次のとおりです。
spring:
cloud:
nacos:
config:
shared-configs[0]:
data-id: db.yaml
# 默认为DEFAULT_GROUP
group: DEFAULT_GROUP
# 是否动态刷新,默认为false
refresh: true
shared-configs[1]:
data-id: log.yaml
group: DEFAULT_GROUP
refresh: true
(4)思考:これらの2つのファイルに同じ構成が表示されている場合、nacosを選択するにはどうすればよいですか?
複数のデータIDが同時に同じ構成を持つ場合、それらの優先順位の関係はspring.cloud.nacos.config.extension-configs [n] .data-idになります。ここで、nの値が大きいほど、優先順位が高くなります。
注:spring.cloud.nacos.config.extension-configs [n] .data-idの値には、ファイル拡張子が必要です。ファイル拡張子は、プロパティとyaml/ymlの両方をサポートできます。現時点では、spring.cloud.nacos.config.file-extensionの設定は、カスタム拡張子設定のデータIDファイル拡張子に影響を与えません。
(5)さまざまな方法でロード優先度を構成します。
Nacos Configuration Centerは現在、Nacosから関連する構成をプルするために、次の3つの構成機能を提供しています。3つの方法を一緒に使用する場合、それらの優先関係の1つは次のとおりです。A<B <C:
- A:spring.cloud.nacos.config.shared-configs[n].data-idを介して複数の共有データID構成をサポートします
- B:spring.cloud.nacos.config.extension-configs[n].data-idを介して複数の拡張データIDの構成をサポートします
- C:内部関連ルール(spring.cloud.nacos.config.prefix、spring.cloud.nacos.config.file-extension、spring.cloud.nacos.config.group)を介して関連データID構成を自動的に生成します
参考記事: