Skip to content
Home
Go back

Spring Cloud Nacos 配置中心:改了配置不必重启

回顾:配置分散的现状

到上一篇为止,我们的微服务架构里有三个角色:order-servicepayment-service,以及 Nacos 注册中心。每个服务的 application.yml 里都写着自己的配置:

# payment-service
spring:
  application:
    name: payment-service
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848
server:
  port: 8081
# order-service
spring:
  application:
    name: order-service
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848
server:
  port: 8082

现阶段只有两个服务,看不出什么问题。但想象一下:你有 20 个微服务,Nacos 地址从测试环境迁移到生产环境,意味着要改 20 份配置文件、重新打包、重新部署。如果在配置里写了一个第三方 API 的密钥,密钥泄露后要紧急轮换——又是 20 个服务的发布流程。

配置中心就是来终结这种噩梦的。

配置中心解决什么

统一管理

所有配置集中存储在一个地方(对,就是 Nacos),每个服务启动时从配置中心拉取自己的那份配置。要改一个公共服务级别的配置,只需在配置中心改一次,所有引用它的服务都能感知到。

动态刷新

这一点尤其重要。传统的做法是改配置文件 → 重新打包 → 重新部署。配置中心允许你修改后,运行中的服务自动拉取最新值,不需要重启,不需要发布。

环境隔离

Nacos 通过 Namespace 区分环境。你可以创建 devtestprod 三个命名空间,同一个配置项在不同空间里值不同。服务启动时指定自己属于哪个命名空间,就自动拿到对应环境的配置。

Nacos 配置中心是怎么工作的

三个核心概念

Nacos 用一个三元组定位一份配置:

要素说明示例
Data ID配置文件名,通常是 服务名.yamlpayment-service.yaml
Group配置分组,默认 DEFAULT_GROUPDEFAULT_GROUP
Namespace环境隔离dev / prod

长轮询机制

Nacos 的配置刷新不是定时轮询(那样会浪费大量网络请求),也不是简单的推模式。它的做法是长轮询:

  1. 服务启动时拉取一次配置
  2. 之后发一个长连接请求到 Nacos,说「我等着,配置变了通知我」
  3. Nacos 把请求 hold 住(默认 30 秒),这期间如果配置有变更,立即返回最新值
  4. 如果 30 秒内没变更,返回空,客户端立刻发下一个长轮询请求

本质上像一个「长连接 + 定时兜底」的混合机制,既保证了变更的实时性,又不会对 Nacos 服务器造成压力。

动手:把 payment-service 的配置迁到 Nacos

引入依赖

payment-servicepom.xml 中加入配置中心依赖:

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

配置 bootstrap

Spring Cloud 的配置加载有一个关键区别:

创建 bootstrap.yml

spring:
  application:
    name: payment-service
  cloud:
    nacos:
      config:
        server-addr: localhost:8848
        file-extension: yaml

application.yml 精简为:

spring:
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848
server:
  port: 8081

在 Nacos 控制台创建配置

打开 http://localhost:8848/nacos → 配置管理 → 配置列表 → 新建配置:

custom:
  message: Hello from Nacos config

在代码中使用并支持动态刷新

@RestController
@RefreshScope
public class PaymentController {

    @Value("${custom.message}")
    private String message;

    @GetMapping("/pay")
    public String pay() {
        return "Payment successful. " + message;
    }
}

关键在于 @RefreshScope。没有它,@Value 注入的是启动时的值,之后不会变。加上它之后,当 Nacos 配置变更,Spring 会在下一次访问时重新注入最新值。

验证:在线改配置,服务不重启

启动 payment-service,访问 http://localhost:8081/pay

Payment successful. Hello from Nacos config

现在去 Nacos 控制台,把 custom.message 改成 Hello from Nacos config, updated!,点击发布。

等几秒后再次访问:

Payment successful. Hello from Nacos config, updated!

服务没有重启,配置已生效。改配置从「发版流程」变成了「点一下控制台」。

小结与下篇预告

这一篇我们补齐了 Nacos 的另一个核心能力——配置中心:

  1. 配置中心的三大价值:统一管理、动态刷新、环境隔离
  2. Nacos 的数据模型:Data ID + Group + Namespace 三元组
  3. 长轮询机制如何在实时性和性能之间取得平衡
  4. 动手:bootstrap.yml 引导配置 + @RefreshScope 动态刷新,一行 @Value 即可拿到实时配置

现在服务发现(注册中心)和服务配置(配置中心)都由 Nacos 统一管理了。但我们的整个系统还缺少一个对外的大门——外部请求如何进入微服务体系?

下一篇,我们用 Spring Cloud Gateway 搭一个统一的 API 网关。



Previous Post
搭建 AI Gateway:从概念到部署(LiteLLM)
Next Post
Spring Cloud OpenFeign:让远程调用像本地方法