Nacos 配置中心用法詳細教程
我們這篇文章介紹下 Nacos 作爲配置中心的基本用法，首先我們先了解下爲什麼需要使用配置中心。
一、爲什麼需要配置中心
在沒有配置中心之前，傳統應用配置的存在以下痛點：
（1）採用本地靜態配置，無法保證實時性：修改配置不靈活且需要經過較長的測試發佈週期，無法儘快通知到客戶端，還有些配置對實時性要求很高，比方說主備切換配置或者碰上故障需要修改配置，這時通過傳統的靜態配置或者重新發布的方式去配置，那麼響應速度是非常慢的，業務風險非常大
（2）易引發生產事故：比如在發佈的時候，容易將測試環境的配置帶到生產上，引發生產事故。
（3）配置散亂且格式不標準：有的用 properties 格式，有的用 xml 格式，還有的存 DB，團隊傾向自造輪子，做法五花八門。
（4）配置缺乏安全審計、版本控制、配置權限控制功能：誰？在什麼時間？修改了什麼配置？無從追溯，出了問題也無法及時回滾到上一個版本；無法對配置的變更發佈進行認證授權，所有人都能修改和發佈配置。
而配置中心區別於傳統的配置信息分散到系統各個角落的方式，對系統中的配置文件進行集中統一管理，而不需要逐一對單個的服務器進行管理。那這樣做有什麼好處呢？
（1）通過配置中心，可以使得配置標準化、格式統一化
（2）當配置信息發生變動時，修改實時生效，無需要重新重啓服務器，就能夠自動感知相應的變化，並將新的變化統一發送到相應程序上，快速響應變化。比方說某個功能只是針對某個地區用戶，還有某個功能只在大促的時段開放，使用配置中心後只需要相關人員在配置中心動態去調整參數，就基本上可以實時或準實時去調整相關對應的業務。
（3）通過審計功能還可以追溯問題
二、Nacos 配置中心的使用
微服務中配置中心的主流解決方案主要有三種：Nacos、Apollo、Config+Bus，不過這篇文章我們主要介紹 Nacos 作爲配置中心的用法，對其他兩種方式感興趣的讀者請自行上網查閱
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）在 application.properties 文件中添加 nacos 配置中心相關配置：
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 控制檯新建一個 DataID 爲 cloud-producer-server-dev.yaml 的配置集：
爲什麼 DataID 的命名爲 cloud-producer-server-dev.yaml 會在下文介紹
//配置發佈之後，動態刷新配置
@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 配置中心的配置信息已經生效並被成功獲取到了
配置的動態刷新是配置中心最核心的功能之一，假設我現在需要修改 user.name 的值，那麼我直接改變 Nacos 中的配置會生效嗎？我們試下直接將 Nacos 中的配置修改成 “zhangsan”，如下圖：
@RefreshScope 註解而產生的效果。
//配置發佈之後，動態刷新配置
@RefreshScope
@RestController
@RequestMapping("provider")
public class ProviderController2、Nacos 的核心概念：
2.1、Data ID：
（1）Data ID 的命名格式：
前面我們演示了在 nacos 控制檯新建一個 DataID 爲 cloud-producer-server-dev.yaml 的數據集，那麼這個 Data ID 是什麼呢？
Data ID 是配置集的唯一標識，一個應用可以包含多個配置集，每個配置集都需要被一個有意義的名稱標識。那麼 Data ID 怎麼取值呢？格式通俗一點就是 “前綴 - 環境 - 擴展名”，如下所示：
${spring.cloud.nacos.config.prefix}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}① prefix： 前綴，默認是 spring.application.name 的值，也可以通過配置項 spring.cloud.nacos.config.prefix 來配置。
# 若不指定，默認採用應用名的方案
spring.application.name=cloud-producer-server
# 手動指定配置的dataID前綴標識
# spring.cloud.nacos.config.prefix=cloud-producer-server-config② active： 配置運行環境，即爲當前環境對應的 profile。
注意：當 spring.profiles.active 爲空時，對應的連接符 ”-“ 也將不存在，dataId 的拼接格式變成 ${prefix}.${file-extension}
# dev表示開發環境
spring.profiles.active=dev③ file-exetension： 配置文件的類型，默認是 properties，也可以通過配置項 spring.cloud.nacos.config.file-extension 來配置，目前支持的類型有 TEXT、JSON、XML、YAML、HTML、Properties
# 指定配置文件類型爲yaml文件
spring.cloud.nacos.config.file-extension=yaml④ 最終配置：
經過前面三個步驟，我們最終在 nacos 配置中心的控制檯新增配置文件就是：cloud-producer-server.yaml
2.2、環境隔離 - 命名空間 Namespace：
Nacos 引入命名空間 Namespace 的概念來進行多環境配置和服務的管理及隔離。擴展：Java 面試題精選（題庫彙總）
例如，你可能存在本地開發環境 dev、測試環境 test、生產環境 prod 三個不同的環境，那麼可以創建三個不同的 Namespace 區分不同的環境。創建方式如下：
# 對應創建的命名空間的ID，此處對應的是dev命名空間
cloud.nacos.config.namespace=483bb765-a42d-4112-90bc-50b8dff768b32.3、業務隔離 - Group 分組：
Group 也可以實現環境隔離的功能，但 Group 設計的目的主要是做同一個環境中的不同服務分組，把不同的微服務的配置文件劃分到同一個分組裏面去，Nacos 如果不指定 Group，則默認的分組是 DEFAULT_GROUP。
如果沒有 Group，試想一下這個場景：有兩個微服務，一個是訂單系統，一個是用戶系統，但是他們有着相同的配置，比如 datasource-url，那麼如何區分呢？這時候 Group 就派上用場了。
上述場景中訂單系統、用戶系統可以單獨分爲一個組，比如 ORDER_GROUP、USER_GROUP，當然這是比較細粒度的分組，根據企業的業務也可以多個微服務分爲一組。
接下來我們演示一下創建配置集時以及集成時如何指定分組，還是前面的例子，新建配置集是在如下位置指定 Group 分組：
application.properties 文件分組：
spring.cloud.nacos.config.namespace=483bb765-a42d-4112-90bc-50b8dff768b33、小結：
Nacos 實現配置管理和動態配置刷新很簡單，總結如下步驟：
-
添加對應
spring-cloud-starter-alibaba-nacos-config依賴 -
使用原生註解
@Value()導入配置 -
使用原生註解
@RefreshScope刷新配置 -
根據自己業務場景做好多環境配置隔離 (Namespace)、不同業務配置隔離 (Group)
4、共享配置：
當我們微服務的數量越來越多，勢必會有相同的配置，這時我們可以將相同的配置抽取出來作爲項目中共有的配置，比如集羣中的數據源信息、日誌的配置信息，nacos 也是支持這種一個配置中心多個配置集這種寫法的。
（1）我們在 nacos 中新建兩個 Data ID 分別是 db.yaml 和 log.yaml 的文件。
（2）在配置文件中分別加入部分配置內容
（3）在 Springboot 項目中添加如下的 nacos 配置：
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爲了更加清晰的在多個應用間配置共享的 Data 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 如何選取？
當多個 Data Id 同時出現相同的配置時，它的優先級關係是 spring.cloud.nacos.config.extension-configs[n].data-id 其中 n 的值越大，優先級越高。
注意：
spring.cloud.nacos.config.extension-configs[n].data-id的值必須帶文件擴展名，文件擴展名既可支持 properties，又可以支持 yaml/yml。此時spring.cloud.nacos.config.file-extension的配置對自定義擴展配置的 Data Id 文件擴展名沒有影響。
（5）不同方式配置加載優先級：
Nacos 配置中心目前提供以下三種配置能力從 Nacos 拉取相關的配置，當三種方式共同使用時，他們的一個優先級關係是: A < B < C：
A：通過 spring.cloud.nacos.config.shared-configs[n].data-id 支持多個共享 Data Id 的配置
B：通過 spring.cloud.nacos.config.extension-configs[n].data-id 的方式支持多個擴展 Data Id 的配置
C：通過內部相關規則 (spring.cloud.nacos.config.prefix、spring.cloud.nacos.config.file-extension、spring.cloud.nacos.config.group) 自動生成相關的 Data Id 配置
原文：blog.csdn.net/a745233700/article/details/122916208
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/I6t-G0bCBlaXL5w1XWPxhA