nacos配置管理改造-拓冰建站

为什么需要配置中心

在单体应用或小规模系统时，通常把配置写在项目里的application.propertites或config.yml文件里，随代码一起打包部署。

会遇到问题：

修改配置需要重启
环境混乱，开发、测试、预发、生产环境各有不同的配置，经常要在不同分支或不同文件里改来改去，一不小心就把测试环境的配置发到了生产，就是严重事故
配置散落各处

当系统拆分为微服务之后，上述问题会演变为灾难：

管理失控：100个服务就有100份配置文件，如果数据库密码需要定期更换，得手动改100次，漏掉一个就导致服务宕机
动态伸缩难：微服务实例会根据流量自动扩缩容，新启动的容器必须能立即拉取到最新的配置，而不能依赖容器镜像里写死的旧配置

因此使用配置中心解决了上述问题：

动态生效：配置中心允许在不重启应用的情况下，实时推送配置变更。例如当发现线上功能有问题，可以立即通过配置中心关掉某个功能开关，或者调高日志级别，几秒钟内全网生效，无需发版
集中管理与权限审计：所有服务的配置都存放在一个统一的web控制台里，可以一目了然的看到订单服务有哪些配置，支付服务有哪些配置，同时可以设置权限，谁改了配置，什么时候改的，改了什么都留有审计日志，出了问题便于追溯
环境隔离与版本控制：配置中心通常支持命令空间Namespace或分组，可以轻松管理dev, test, prod三套环境，同一份配置ID对应不同的值，应用启动时只需指定环境标签即可，彻底杜绝改错环境的问题，并且配置变更支持版本回滚，改错了可以一键恢复
服务感知与健康检查：配置中心通常和服务注册中心配合。当配置变更，能感知到哪些服务实例在运行，并精准推送。如果某个客户端没收到配置，配置中心还能提供配置拉取接口，确保客户端主动轮询，保证最终一致性。

现代配置中心Apollo, Nacos, Consul已经进化成了动态配置管理平台，承载了更多职责：

灰度发布：只让10%的测试用户先应用新配置，没问题再全量推送
依赖解耦：运维和开发分工更清晰，开发只写代码占位符${mysql.host}，运维在配置中心填具体的IP，双方互不干扰

什么是Nacos

Nacos支持几乎所有主流类型的服务的发现、配置和管理。

Kubernetes Service
gRPC, Dubbo RPC Service
Spring Cloud RESTFul Service

Nacos快速开始

Nacos依赖Java环境来运行，

将Spring Cloud微服务接入Nacos进行配置管理，主要涉及服务端准备、客户端依赖引入、配置文件迁移以及代码动态刷新四个步骤。

启动Nacos Server
在各个微服务模块的pom.xml这种，添加nacos配置中心的starter依赖。

引入nacos config依赖，即nacos 配置中心的starter依赖：
在项目根pom.xml中引入，这样各个服务也能从根pom中拿到

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

调整配置文件
每个服务都需要引入spring.config.import，导入nacos配置，不再推荐使用bootstrap.yml，

本地保留application.yml，只放启动必需的配置，

例如用户服务的application.yml保留以下内容；注意添加服务发现的地址，配置中心的地址，

spring:application:name:imagecore-backend-user-serviceprofiles:active:tencentcloud:nacos:discovery:server-addr:xxx:8848config:server-addr:xx:8848file-extension:ymlconfig:import:-nacos:imagecore-backend-user-service-nacos:imagecore-backend-user-service-tencent

迁移配置文件到nacos控制台

在nacos控制台中，进入配置管理——》配置列表，
点击新建配置，Data ID通常命名为your-service-name.yml，与配置中的一致，Group保持默认的DEFAULT-GROUP，配置格式选择YAML，
注意DataID也必须和import里面的一样imagecore-backend-user-service-tencent

同理，picture-service, space-service也是，

这样就修改成功了。