Nacos 配置中心与注册中心实战

为什么选择 Nacos

在我的项目中，Nacos 同时承担服务注册和配置管理两个角色。相比单独部署 Eureka（注册）+ Spring Cloud Config（配置），Nacos 在一个组件中解决了两个问题，运维成本低一半。

我在虚拟机上部署了 Nacos 3.2.2 集群（路径 /root/ai-infra/nacos/standalone/nacos-3.2.2/），通过 bin/startup.sh 启动，控制台位于 /nacos 端口 8080。

服务注册

Java_Online 服务启动后会自动注册到 Nacos：

spring:
  cloud:
    nacos:
      discovery:
        server-addr: 192.168.8.133:8848
        heart-beat-interval: 5000
        heart-beat-timeout: 15000

注册原理：服务启动后向 Nacos 发送心跳（默认 5 秒一次），Nacos 如果在 15 秒内未收到心跳则标记实例不健康。消费者通过服务名从 Nacos 获取可用实例列表，支持：

• 权重路由：给高性能机器分配更高权重
• 保护阈值：当健康实例比例低于阈值时，不摘除全部实例，保证少量流量能继续处理
• 命名空间隔离：不同环境（dev/test/prod）用不同 Namespace，互不干扰

配置管理

这是 Nacos 在日常开发中最常用的功能。以 Java_Online 为例，配置优先级是：

java-online-service.yaml > common.yaml > 本地 application.yml

多环境隔离

Nacos 使用三层结构隔离配置：

1. Namespace：环境隔离（dev/test/prod）
2. Group：业务模块分组（DEFAULT_GROUP）
3. Data ID：单个配置文件（如 java-online-service.yaml）

动态刷新

配置修改后不需要重启服务。Spring Cloud Nacos 通过长轮询机制实现实时刷新：

@ConfigurationProperties(prefix = "app")
@RefreshScope
public class AppConfig {
    private int threadPoolSize;
    // 修改 Nacos 中的值后自动生效
}

实际生产中，修改 Nacos 配置后会有短暂的延迟（1-2 秒），然后 /actuator/refresh 可以看到属性值已更新。

版本管理

每次修改配置 Nacos 都会保存历史版本，可以随时回滚到之前的版本。这在排查"修改配置引发的故障"时非常有用——一条命令回到上一个稳定版本。

生产经验

配置优先级坑：最初在本地 application.yml 中设置了 server.tomcat.threads.max=10，但发现不生效。排查后发现 Nacos 配置 java-online-service.yaml 中的值覆盖了本地配置。后来统一在 Nacos 中管理所有环境差异配置，本地配置文件只保留不变的通用配置和本地开发覆盖。

YAML 缩进：Nacos Web 控制台编辑 YAML 时缩进容易出错（控制台不是 IDE，没有语法高亮和校验）。一个错误的缩进会让整段配置失效。我的做法是在本地 IDE 编辑好再粘贴到 Nacos 控制台。

总结

Nacos 解决了微服务架构中最基本的两个问题：服务发现和配置管理。一个集群部署就能覆盖这些基础能力，对于中小团队来说性价比很高。如果项目规模增大，可以配合 Spring Cloud Gateway 做更细粒度的路由控制。