为什么需要配置中心在单体应用或小规模系统时通常把配置写在项目里的application.propertites或config.yml文件里随代码一起打包部署。会遇到问题修改配置需要重启环境混乱开发、测试、预发、生产环境各有不同的配置经常要在不同分支或不同文件里改来改去一不小心就把测试环境的配置发到了生产就是严重事故配置散落各处当系统拆分为微服务之后上述问题会演变为灾难管理失控100个服务就有100份配置文件如果数据库密码需要定期更换得手动改100次漏掉一个就导致服务宕机动态伸缩难微服务实例会根据流量自动扩缩容新启动的容器必须能立即拉取到最新的配置而不能依赖容器镜像里写死的旧配置因此使用配置中心解决了上述问题动态生效配置中心允许在不重启应用的情况下实时推送配置变更。例如当发现线上功能有问题可以立即通过配置中心关掉某个功能开关或者调高日志级别几秒钟内全网生效无需发版集中管理与权限审计所有服务的配置都存放在一个统一的web控制台里可以一目了然的看到订单服务有哪些配置支付服务有哪些配置同时可以设置权限谁改了配置什么时候改的改了什么都留有审计日志出了问题便于追溯环境隔离与版本控制配置中心通常支持命令空间Namespace或分组可以轻松管理dev, test, prod三套环境同一份配置ID对应不同的值应用启动时只需指定环境标签即可彻底杜绝改错环境的问题并且配置变更支持版本回滚改错了可以一键恢复服务感知与健康检查配置中心通常和服务注册中心配合。当配置变更能感知到哪些服务实例在运行并精准推送。如果某个客户端没收到配置配置中心还能提供配置拉取接口确保客户端主动轮询保证最终一致性。现代配置中心Apollo, Nacos, Consul已经进化成了动态配置管理平台承载了更多职责灰度发布只让10%的测试用户先应用新配置没问题再全量推送依赖解耦运维和开发分工更清晰开发只写代码占位符${mysql.host}运维在配置中心填具体的IP双方互不干扰什么是NacosNacos支持几乎所有主流类型的服务的发现、配置和管理。Kubernetes ServicegRPC, Dubbo RPC ServiceSpring Cloud RESTFul ServiceNacos快速开始Nacos依赖Java环境来运行将Spring Cloud微服务接入Nacos进行配置管理主要涉及服务端准备、客户端依赖引入、配置文件迁移以及代码动态刷新四个步骤。启动Nacos Server在各个微服务模块的pom.xml这种添加nacos配置中心的starter依赖。引入nacos config依赖即nacos 配置中心的starter依赖在项目根pom.xml中引入这样各个服务也能从根pom中拿到dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-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也是这样就修改成功了。