Nacos 在这套系统里承担“服务台账”的角色:服务启动时注册自己的地址,调用方通过服务名拿到可用实例。它不参与业务请求转发,真正的转发由 Gateway、OpenFeign 和 LoadBalancer 完成。
一、公共认证配置
spring:
cloud:
nacos:
discovery:
username: nacos
password: nacos
config:
enabled: false
这份公共配置把边界说得很清楚: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" 依赖的都是这个名字。
因此服务名一旦确定,就不能随意改。它不是包名,也不是工程显示名,而是运行期服务发现契约。
四、避坑点
- 服务注册成功不代表业务健康,健康状态要结合 Actuator。
- Nacos 地址、网络分区、认证失败表现不同,排查时要分层看。
- 只调用服务不需要感知实例 IP,调试时再查 Nacos 控制台。
- 使用 Nacos Config 前要先想清楚配置刷新边界,当前项目刻意没有使用。
五、经验总结
Nacos 让多实例部署从“配置 IP 清单”变成“按服务名发现”。这个项目保持它只做注册与发现,配置仍由本地 Profile 管理,边界简单,问题也更容易定位。