Spring Cloud - Nacos 动态配置管理

微服务架构 —— Nacos 动态配置管理

1. 核心理论：什么是配置中心？

在微服务架构中，随着服务数量的增多，每个服务都有自己的配置文件。如果每次修改配置（如数据库密码、第三方 API 的 Key），都需要去修改每个服务的配置文件，然后重新打包、部署，这将是一场灾难。

配置中心就是为了解决这个问题而生的。它提供一个统一的、中心化的地方来管理所有服务的配置。

• 核心思想: 将配置从应用程序中抽离出来，由配置中心统一管理和下发。

• 动态刷新: 配置中心最大的魅力在于，当配置发生变更时，它能够主动通知相关的微服务，使其无需重启就能加载到最新的配置。

• 生活比喻:

  • 没有配置中心: 就像给公司里的每个员工都发了一份纸质的“行为准则”手册。如果公司修改了某条准则，就需要把所有旧手册收回来，再给每个人发一份新的。效率极低。
  • 有配置中心 (Nacos): 就像公司使用了一个在线的共享文档（如 Google Docs）作为“行为准-则”。当 HR 在这个在线文档上修改了任何条款时，所有员工的电脑上都会立即看到更新后的内容，无需任何操作。

---

2. Nacos 配置模型

Nacos 配置管理有几个核心概念：

• Namespace (命名空间): 用于进行环境隔离。例如，可以创建 dev, test, prod 三个命名空间，分别存放开发、测试、生产环境的配置。默认是 public。
• Group (分组): 用于对配置集进行分组，区分不同的项目或模块。默认是 DEFAULT_GROUP。
• Data ID: 配置集（一个配置文件）的唯一标识。通常采用 应用名-环境.文件后缀 的格式，例如 order-service-dev.yaml。

一个完整的配置定位路径: Namespace + Group + Data ID。

---

3. 代码示例：从 Nacos 读取配置并实现动态刷新

3.1 引入依赖 (pom.xml)

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>

3.2 编写配置文件 (bootstrap.yml)

极其重要: Nacos 作为配置中心，它的连接信息（如 Nacos Server 的地址）必须在应用启动的早期就被加载，这样它才能从 Nacos Server 拉取其他配置。因此，这些核心配置必须写在 bootstrap.yml 文件中，而不是 application.yml。

bootstrap.yml 的加载优先级高于 application.yml。

注意：Spring Boot 2.4+ 版本变更
从 Spring Boot 2.4 开始，推荐使用 spring.config.import 属性来导入外部配置。旧的 spring.cloud.nacos.config.* 等方式已不推荐。

在 src/main/resources 目录下创建 bootstrap.yml：

server:
  port: 8082

spring:
  application:
    name: order-service
  cloud:
    nacos:
      # Nacos Server 地址
      server-addr: 127.0.0.1:8848
      config:
        # 文件扩展名
        file-extension: yml 
        # 可以不指定 group，默认为 DEFAULT_GROUP
        # group: DEFAULT_GROUP 
  config:
    # [重点] 使用 import 导入 Nacos 配置
    # 格式为: nacos:<data-id>[?group=<group-name>]
    import: nacos:order-service.yml

根据以上配置，Spring Boot 会去 Nacos 的 DEFAULT_GROUP 中查找 Data ID 为 order-service.yml 的配置。

3.3 在 Nacos 控制台创建配置

1. 登录 Nacos 控制台 (http://localhost:8848/nacos)。
2. 进入 “配置管理” -> “配置列表”。
3. 点击右侧的 “+” 号，新建配置。
4. Data ID: order-service.yml
5. Group: DEFAULT_GROUP
6. 配置格式: YAML
7. 配置内容:

   order:
     payment-timeout: 30
     create-frequency: 10
   

8. 点击“发布”。

3.4 在代码中读取配置

创建一个 Controller，使用 @Value 或 @ConfigurationProperties 来读取配置。

package com.study.nacosconfig;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.cloud.context.config.annotation.RefreshScope;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
// 使用 @RefreshScope 注解，可以使该类在接收到配置变更通知时，动态地刷新 Bean
@RefreshScope
public class OrderController {

    // 使用 @Value 读取单个配置
    @Value("${order.payment-timeout}")
    private Integer paymentTimeout;

    @GetMapping("/order/config")
    public String getOrderConfig() {
        return "Payment timeout is: " + paymentTimeout + " minutes.";
    }
}

• @RefreshScope: 这是实现配置动态刷新的关键。当 Nacos 配置发生变更时，Nacos Client 会收到通知，所有被 @RefreshScope 注解的 Bean 将会被销毁并重新创建，从而加载到最新的配置值。

---

4. 运行与验证

1. 先确保 Nacos Server 正在运行。
2. 再启动 NacosConfigApplication。
3. 访问 http://localhost:8082/order/config，页面应显示 “Payment timeout is: 30 minutes.”。
4. 回到 Nacos 控制台，修改 order-service.yml 的配置，将 payment-timeout 改为 15，然后点击“发布”。
5. 无需重启应用，稍等片刻，再次访问 http://localhost:8082/order/config。
6. 页面应显示 “Payment timeout is: 15 minutes.”。

• 效果: 这证明了 Nacos 配置中心成功地实现了对应用配置的动态管理和热更新。

---

5. Nacos 配置核心问题解析

5.1 为什么 Nacos 的配置需要写在 bootstrap.yml 而不是 application.yml？

这涉及到 Spring Cloud 的一个核心概念：引导上下文 (Bootstrap Context)。

• 加载顺序：在一个 Spring Cloud 应用中，存在两个上下文：一个是 bootstrap 上下文，另一个是 application 上下文。bootstrap 上下文是 application 上下文的父上下文，并且先于 application 上下文被加载。

• 职责分离：bootstrap 上下文专门负责加载外部的、远程的配置（例如来自 Nacos、Consul 或 Spring Cloud Config Server 的配置）。而 application 上下文则负责使用这些配置来创建我们自己定义的 Bean。

• 必要性：试想一下，如果获取 Nacos 地址的配置信息写在 application.yml 里，那么应用在启动时，必须先加载 application.yml 才能知道 Nacos Server 的地址。但此时，application 上下文已经开始初始化了，它在创建 Bean 的时候可能就需要用到那些本该从 Nacos 获取的配置项，这就导致了一个“先有鸡还是先有蛋”的问题。

因此，Spring Cloud 规定，将连接远程配置中心（如 Nacos）的配置信息放在 bootstrap.yml 中。这样，bootstrap 阶段会先启动，连接到 Nacos，拉取配置，当 application 阶段启动时，所有远程配置都已准备就绪，可以被安全地注入和使用了。

5.2 @RefreshScope 注解的工作原理是什么？

@RefreshScope 是 Spring Cloud 实现配置动态刷新魔法的核心。它的工作原理可以概括为“销毁重建”。

• 代理机制：当一个 Bean（比如我们的 OrderController）被标记为 @RefreshScope 时，Spring 容器在创建这个 Bean 时，实际上创建的是一个代理对象。我们注入和使用的，都是这个代理。

• 事件监听：Nacos 客户端会监听 Nacos Server 上的配置变更。当它检测到配置发生变化时，它会在 Spring 应用内部发布一个 RefreshScopeRefreshedEvent 事件。

• 销毁缓存：@RefreshScope 所在的 Bean 会监听这个事件。当事件发生时，这个作用域会清空其内部的 Bean 缓存。这意味着，那个被代理的真实的 OrderController 对象被销毁了。

• 惰性重建：此时，代理对象依然存在，但它所代理的真实对象已经没了。当下一次有请求访问 /order/config 时，请求会通过代理对象。代理发现自己没有真实的目标对象了，于是它会重新创建一个新的 OrderController 实例。

• 重新注入：在创建这个新的 OrderController 实例时，Spring 会重新执行依赖注入逻辑，此时它会用最新的配置（已经从 Nacos 更新）来填充 @Value 注解的字段。

总结：@RefreshScope 就像一个“懒汉式”的刷新开关。它并不在配置变更时立刻重建所有 Bean，而是在配置变更后，将这些 Bean 标记为“脏” (dirty)，等到下一次被使用时，才销毁旧实例、创建新实例并注入新配置。