Nacos配置中心

为什么需要配置中心

在没有配置中心之前，传统应用配置的存在以下痛点：

（1）采用本地静态配置，无法保证实时性：修改配置不灵活且需要经过较长的测试发布周期，无法尽快通知到客户端，还有些配置对实时性要求很高，比方说主备切换配置或者碰上故障需要修改配置，这时通过传统的静态配置或者重新发布的方式去配置，那么响应速度是非常慢的，业务风险非常大

（2）易引发生产事故：比如在发布的时候，容易将测试环境的配置带到生产上，引发生产事故。

（3）配置散乱且格式不标准：有的用properties格式，有的用xml格式，还有的存DB，团队倾向自造轮子，做法五花八门。

（4）配置缺乏安全审计、版本控制、配置权限控制功能：谁？在什么时间？修改了什么配置？无从追溯，出了问题也无法及时回滚到上一个版本；无法对配置的变更发布进行认证授权，所有人都能修改和发布配置。

而配置中心区别于传统的配置信息分散到系统各个角落的方式，对系统中的配置文件进行集中统一管理，而不需要逐一对单个的服务器进行管理。那这样做有什么好处呢？

（1）通过配置中心，可以使得配置标准化、格式统一化

（2）当配置信息发生变动时，修改实时生效，无需要重新重启服务器，就能够自动感知相应的变化，并将新的变化统一发送到相应程序上，快速响应变化。比方说某个功能只是针对某个地区用户，还有某个功能只在大促的时段开放，使用配置中心后只需要相关人员在配置中心动态去调整参数，就基本上可以实时或准实时去调整相关对应的业务。

（3）通过审计功能还可以追溯问题

Nacos配置管理

统一配置管理

当微服务部署的实例越来越多，达到数十、数百时，逐个修改微服务配置就会让人抓狂，而且很容易出错。我们需要一种统一配置管理方案，可以集中管理所有实例的配置。

配置获取的步骤如下：

bootstrap.yml的优先级比较高，里面先存储nacos的相关信息，如nacos地址。

读取bootstrap.yml ==> 读取nacos配置文件 ==> 读取本地配置文件application.yml ==> 将nacos配置文件与本地配置文件合并 ==> 创建spring容器 ==> 加载bean

微服务配置拉取

配置热更新

热更新即自动更新

当Nacos中的配置文件变更后，微服务无需重启就可以感知，不过需要通过下面两种配置实现

方式一

在@Value注入的变量所在类上添加注解@RefreshScope

方式二

@ConfigurationProperties

注意事项

不是所有的配置都适合放到配置中心，维护起来比较麻烦

建议将一些关键参数、需要运行时调整的参数放到nacos配置中心，一般是自定义配置

多环境配置共享

微服务启动时，会去nacos读取多个配置文件，例如：

• [spring.application.name]-[spring.profiles.active].yaml，例如：userservice-dev.yaml，环境配置
• [spring.application.name].yaml，例如：userservice.yaml，默认配置，多环境共享

而[spring.application.name].yaml不包含环境，因此可以被多个环境共享。

案例

添加userservice.yaml文件，默认配置，放多环境共享的配置

在user-service中读取共享配置，修改PatternProperties类，添加要共享的属性

在user-service服务中，修改UserController，添加一个方法：

运行两个UserApplication，使用不同的profile，给两个UserApplication配置不同的环境

Shift+F4打开Edit Configuration，修改UserApplication2这个启动项，改变其profile为test

UserApplication : 8081的环境为dev，UserApplication:8082 的环境为test，启动两个UserApplication，访问http://localhost:8081/user/prop与http://localhost:8082/user/prop

配置共享的优先级

小结

集群搭建

通过Nginx实现负载均衡

各个Nacos结点需要数据共享，红色部分为MySQL数据库集群，我们让各个Nacos结点都访问数据库集群，来实现数据共享