Nacos配置管理

301 阅读5分钟

Nacos统一配置管理

持续创作,加速成长!这是我参与「掘金日新计划 · 10 月更文挑战」的第8天,点击查看活动详情

Nacos配置管理的基本用法

想象一个场景,我们的微服务部署在很多台服务器上,每台服务器都有自己的数据库连接配置,规定月份配置等,如果说,我们要同时改很多集群的配置,那么我们难道还要每个微服务都下载下来然后再去修改配置文件再重启吗?在生产环境下,服务的重启代价是很大的。

这个时候,我们就希望去弄一个配置的统一管理,并且这个配置去实现一修改,就能生效的效果(热更新),让配置中心的配置和每个服务中的配置结合

image-20221007155021266.png

下面来开始实战

首先,我们在本地启动nacos

image-20221007155653581.png

然后,在idea通过改端口的方式启动了俩userservice和一个orderservice,在配置里将两个服务注册到nacos中

image-20221007155813928.png

userservice: 我们这里配置了userservice的名称,注册的nacos地址,和所属集群的名字。

image-20221007155958682.png

orderservice:不仅配置了名称和nacos地址,还将orderservice注册到了SH集群,并且开辟了独属于它自己的命名空间(这个id是在nacos服务器里面创建并且自动生成的,你粘贴就好)。

image-20221007160238649.png

另外,在这个里面,由于orderservice用到了userservice里面的服务,我们还给userserver配置了ribbon负载均衡的规则,这个规则会优先调用本集群的服务。

下面的那个配置则是对于userservice进行的饥饿加载,那么什么是饥饿加载呢?

我们都知道,Ribbon默认采用的是懒加载,也就是第一次访问的时候才会取创建LoadBalanceClient,第一个访问的人请求时间会很长,而饥饿加载就会在项目启动的时候就创建连接,从而降低第一次访问时候的耗时

好了,讲解完了两个服务的配置,我们就可以开始在nacos中去新建我们共同的配置了.

先启动俩userApplication和一个orderApplication

image-20221008140533871.png

在nacos中我们可以看到

image-20221008144627822.png

在public的namespace里面启动了俩用户服务,因为没有配置命名空间,所以自动到了public的空间中

image-20221008144652205.png

在dev中我们则是配置了namespace,所以不在public中

然后我们进入配置管理的配置列表

image-20221008144800357.png

先配置号用户的集群配置,格式是yaml,我们测试一下,在配置内容里面写一个日期格式化的配置

配置完了以后,有的人可能会好奇,我们的服务是怎么读取这个配置的呢?

原来,在项目启动的时候,原本我们会先读取本地配置文件,但是现在我们是先从nacos中读取,之后再从本地读取配置。

但这个时候又有一个矛盾了,我们的服务注册就是从本地配置中读取的,而我们现在要先读取nacos中的配置文件,那两者顺序岂不是颠倒了?

因此我们需要找到一个优先级更高的配置文件去读取nacos服务注册的配置

整个流程:

image-20221008145435797.png

首先,我们在userservice引入统一nacos配置管理的依赖

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

之后创建bootstrap.yml文件

image-20221008150438826.png

然后写入三要素:

spring:
  application:
    name: userservice
  profiles:
    active: dev
  cloud:
    nacos:
      server-addr: localhost:8848
      config:
        file-extension: yaml
      discovery:
        cluster-name: HZ  # 集群名称

分别是配置名称 运行环境 和 文件扩展名,对应

image-20221008150534765.png 才能读取配置。

之后我们把application.yml中的相同配置给他删掉就可以了

下面我们来读取一个配置来证明我们是否应用了bootstrap引导到的nacos配置文件

我们在controller里面写一个日期测试方法

 @Value("${pattern.dateformat}")
    private String dataformat;
​
    @GetMapping("now")
    public String now(){
        return LocalDateTime.now().format(DateTimeFormatter.ofPattern(dataformat));
    }

然后应用到了nacos中的yaml的配置文件进行测试

然而,当我们继续修改配置文件(nacos中的)的时候,发现,日期格式并没有按我们想象中的改变

原来,我们还没有实现配置的热更新

image-20221008152104792.png

加个@RefreshScope即可

或者,我们不用value注解,换一种方式

新定义一个类

@Data
@Component
@ConfigurationProperties(prefix = "pattern")
public class PatternProperties {
    private String dateformat;
}

把它注册成组件,springboot会拼接 pattern 和 dateformat去自动找到这个配置

然后我们在controller里面使用

@Autowired
    private PatternProperties patternProperties;
​
    @GetMapping("now")
    public String now(){
        return LocalDateTime.now().format(DateTimeFormatter.ofPattern(patternProperties.getDateformat()));
    }

这样也可以读取配置

多环境配置共享

场景:如果一个配置属性,在开发生产测试环境的值都是一样的,如果每个环境都去写一遍配置,那么毫无疑问是很臃肿浪费的,因此我们需要找到一种方法,就是在一个地方配置一遍,不管是哪个环境都可以去加载,这就是多环境共享

上面我们提到,springboot在启动的时候,会被bootstrap,yml文件引导去读取nacos里面的yaml配置文件:

1.[spring.application.name] - [spring.profiles.active].yaml,就像我们上面写的 userservice-dev.yaml

2.[spring.application.name].yaml

无论profile,也就是环境如何变化,第二个文件都会去加载,对吧?

因此我们就可以在这个文件里去改公共的配置了!

image-20221008154244630.png

我们在第二个文件里面创建了一个测试用的配置

image-20221008154335256.png

然后,我们把active改为prod

image-20221008154828003.png

然后访问,可以访问得到。,说明我们的公共配置文件生效了

那么现在遇到一个问题,三个配置文件的优先级

服务名-profile.yaml > 服务名称.yaml > 本地配置

\