Nacos 服务注册与发现

代码环境

• 仓库：https://github.com/springvortex/spring-cloud-alibaba.git
• 分支：release/v1.0.0
• JDK：21
• Spring Boot：4.1.0

Nacos 在这套系统里承担“服务台账”的角色：服务启动时注册自己的地址，调用方通过服务名拿到可用实例。它不参与业务请求转发，真正的转发由 Gateway、OpenFeign 和 LoadBalancer 完成。

一、公共认证配置

spring:
  cloud:
    nacos:
      discovery:
        username: nacos
        password: nacos
      config:
        enabled: false

https://github.com/springvortex/spring-cloud-alibaba/blob/release/v1.0.0/service-provider/src/main/resources/config/application-nacos.yaml

这份公共配置把边界说得很清楚：Discovery 开启，Config 显式关闭。也就是说，当前项目不用 Nacos 下发业务配置，配置仍随服务包内的 Profile 分发。

二、地址按环境拆分

application-dev.yaml 和 application-prod.yaml 只维护 Nacos 地址差异；账号、密码和“关闭 Config”的规则放在公共 Profile。这样环境差异不会把公共规则复制出多份。

三、服务名是协作契约

Provider、Consumer、Gateway、Mail 都通过 spring.application.name 注册。Gateway 的 lb://service-provider、Feign 的 name = "service-provider" 依赖的都是这个名字。

因此服务名一旦确定，就不能随意改。它不是包名，也不是工程显示名，而是运行期服务发现契约。

四、避坑点

1. 服务注册成功不代表业务健康，健康状态要结合 Actuator。
2. Nacos 地址、网络分区、认证失败表现不同，排查时要分层看。
3. 只调用服务不需要感知实例 IP，调试时再查 Nacos 控制台。
4. 使用 Nacos Config 前要先想清楚配置刷新边界，当前项目刻意没有使用。

五、经验总结

Nacos 让多实例部署从“配置 IP 清单”变成“按服务名发现”。这个项目保持它只做注册与发现，配置仍由本地 Profile 管理，边界简单，问题也更容易定位。