MSE Nacos 实践：千里达票务系统微服务注册中心与配置中心
拆成十几个微服务之后，最早期是用 Spring Cloud Eureka 自己搭的注册中心，配置文件散落在各服务的 Git 仓库里。改一个数据库连接串要发版三个服务，节假日半夜改个开关更是心惊胆战。接入阿里云 MSE Nacos 后，注册中心和配置中心全托管，不再自己维护集群。
一、要解决什么
- 服务注册发现：订单服务怎么找到支付服务？
- 配置集中管理：数据库地址、开关、限流阈值改一处生效；
- 配置灰度：先给 10% 实例发新配置，没问题再推全量。
二、MSE Nacos 带来的变化
- 不用自己部署 Nacos 集群，省运维；
- 控制台直接改配置，推送秒级生效；
- 配置变更历史可回滚；
- 服务列表实时看哪个实例挂了。
三、关键实现
3.1 配置示例（application.yml）
spring:
cloud:
nacos:
server-addr: mse-nacos-pre.cn-hangzhou.mse.aliyuncs.com:8848
config:
namespace: ticket-prod
group: TICKET_GROUP
3.2 配置灰度
配置: order.service.timeout = 2000ms
灰度: 先推给 10.0.0.0/24 一个网段(测试实例)
观察 10 分钟无报错 → 推全量
3.3 开关化
- 节假日期间临时关"积分加赠"活动：改 Nacos 一个开关，不用发版；
- 某渠道临时限流：动态改限流阈值。
四、踩坑复盘
- 命名空间混乱：dev/test/prod 全塞一个 namespace。解决：严格分 namespace，环境隔离；
- 配置没版本：早期直接改，改错了回不去。解决：开配置历史，每次改动可回滚；
- 本地缓存：Nacos 挂了服务启动读不到配置。解决：本地留本地快照，降级用上次配置；
- 敏感信息：数据库密码直接明文写 Nacos。解决：接入 KMS 加密配置，运行时解密。
五、效果与总结
MSE Nacos 上线后，配置变更从"发版 30 分钟"变成"控制台点一下"。对微服务架构来说，注册中心和配置中心是底座，自己维护集群性价比低，托管出去让云厂商操心，团队专注业务。
