目录:
(1)Nacos配置管理-添加Nacos配置
(2)微服务配置的拉取
(3)Nacos的配置管理-配置热更新
(4)多环境配置共享
(1)Nacos配置管理-添加Nacos配置
随着微服务越来越多,我们在生产环境中可能会达到数十上百甚至上千台这种服务器的情况,我们的配置文件需要做一些修改,这个配置文件可能跟数十个微服务都由关系,这时候我们得逐个微服务去调整这个配置,很麻烦,调完之后这些微服务都需要重启,一个服务重启带来的影响还是挺大的,我们希望这些配置文件做到统一的管理,比如说我们现在有数十个配置需要修改,我们只在一个地方完成改动,并且我们希望这个服务不需要重启,这些配置就能立马生效,这就是配置的热更新,这就用到配置管理服务
我们把微服务上一些经常变更的配置,放到配置管理服务器上去,而微服务在启动的时候,会去读取配置管理服务器上放好的配置,把它读取下来以后与本地的做结合,作为最终的配置文件,来完成spring容器的初始化,将来如果需要修改配置,我们直接修改配置管理服务,在他上面修改配置就行了,微服务会不断的读取配置管理服务的配置,实现配置的热更新
点击+添加配置:
这里写的配置不是把application.yaml中的配置全部拿过来,只是把有热更新需求的写在这里
(2)微服务配置的拉取
项目启动会县杜曲bootstrap.yml的配置文件它的优先级比application.yml的优先级高,这里面写入nscos的的地址与配置文件有关的信息都放到bootstrap.yml中
找到user-service的pom.xml添加:依赖
创建bootstrap.yml文件:
在application.yml中 重复的配置删掉:
进行读取配置:在UserController添加方法:
重启服务:
浏览器输入:发现格式化完成
(3)Nacos的配置管理-配置热更新
点击编辑配置文件:
我们希望微服务里面立马变化:但是没有发生变化 没有实现配置热更新
需要进行配置:
添加注解@RefreshScope
重启服务:
刷新浏览器:确实发生了改变,但是我们重启服务器了,不是热更新
刷新页面:这里我们没有重启微服务,它自动发生了变化,这就是服务的热更新
这里出现了大量的日志,使我们的服务,在不断的访问Nacos,发现你的远端的配置发现了更新,拉倒本地进行更新
新建一个类专门完成配置的加载:PatternProperties类
这里@ConfigurationProperties(profix=“pattern”)和dateformat进行拼接
注释掉UserController中的中的注解:
注入那个类:
重启服务:
在次改为年月日:
(4)多环境配置共享
现在我们来了解一下微服务的共享问题,在什么情况下会遇到微服务的共享呢?比如说,有一个配置属性,在开发 生产 测试等环境的值是一样的,像这么一个配置,我们去每个配置中都去写一份,是不是有点浪费,如果需要改动的话每个配置都需要改动,这样写是不合适,我们想找到一个地方,我们配一次以后,不管环境怎么变化,这个配置都能够被加载,这就是多环境共享的一个需求了
在新添加一个配置:作为多环境共享的
提交:就有了两个配置文件了,一个是生产dev环境,一个是多环境共享的。多环境共享的是没有带环境的
修改PatternProperties类添加一个读取的属性,刚才新建的共享配置中属性:envShareValue
在UserController中添加一个方法:当访问一个方法时,把这个对象返回给你,springmvc会把它转换为json,返回给页面,就可以看到这个类的的属性
重启服务:重启两个服务,第二个UserService服务改为测试环境,这样就不会在
访问:成功得到两个属性
读取配置环境:dev环境,读到两个属性
8082:test环境只读到一个属性
就可以证明dev环境和test环境都能拿到共享属性
可以在idea中查看日志:
如果两个配置文件中有相同的属性会以谁的为准呢?
测试:在appllication.yml中添加一个内部属性
在给这个类也加一个name属性
重启:这时候远程还没有 加,显示的是本地的
给远程userservice.yaml加一个属性:
重新刷新:发生了改变,是以userservice.yam为准
在给userservice-dev.yam也加上name属性:
是以userservice-dev.yam为准,它的优先级最高
带环境的配置高于不带环境的共享配置高于本地配置