Nacos配置中心搭建及动态刷新配置及踩坑记录

近期有用到阿里的开源配置中心及注册中心nacos,特此记录并分享一些学习笔记及配置踩坑点。

一、Nacos配置中心介绍

从架构图上可以知道,Nacos提供了两种服务,一种是用于服务注册、发现的Naming Service,一种是用于配置中心、动态配置的Config Service,而他们底层均由core模块来支持。

外层提供OpenAPI供客户端使用,并提供了User Console、Admin Console方便用户使用 。

用户通过管理平台发布配置,通过HTTP调用将配置注册到服务端,服务端将之保存在MySQL等持久化存储引擎中;用户通过客户端SDK访问服务端的配置,同时建立HTTP的长轮询监听配置项变更,同时为了减轻服务端压力和保证容灾特性,配置项拉取到客户端之后会保存一份快照在本地文件中,SDK优先读取本地文件里的配置。

当服务端的配置发生变更时,客户端会通过监听机制,拿到变更后的最新配置信息。

简单来说,Nacos 客户端是怎么实时获取到 Nacos 服务端的最新数据的:

Nacos 并不是通过推的方式将服务端最新的配置信息发送给客户端的,而是客户端维护了一个长轮询的任务,定时去拉取发生变更的配置信息,然后将最新的数据推送给 Listener 的持有者。

二、配置中心搭建

1.配置中心启用

首先需要到官网上下载nacos-server,然后将服务跑起来之后。

根据自己的需要,建立几个命名空间,当然使用默认的public的命名空间也是可以的,如图所示。

2.创建配置文件

在配置列表中创建配置文件,其中配置文件命名方式需要注意。

在Nacos-Server中新建配置,其中Data ID它的定义规则是:${prefix}-${spring.profiles.active}.${file-extension}

  • prefix 默认为 spring.application.name 的值,也可以通过配置项 spring.cloud.nacos.config.prefix 来配置。
  • spring.profiles.active 即为当前环境对应的 profile,可以通过配置项 spring.profiles.active 来配置。
  • file-exetension 为配置内容的数据格式,可以通过配置项 spring.cloud.nacos.config.file-extension 来配置。目前只支持 properties 和 yaml 类型。

注意:当 spring.profiles.active 为空时,对应的连接符 - 也将不存在,dataId 的拼接格式变成 prefix.{prefix}.prefix.{file-extension}

在本文中,我的项目名称为vaso-core,配置文件使用的是dev环境,因此我的配置文件如下:

其中的文件内容就是正常的yaml格式的内容填写就行,这边就不具体展示了。

3.工程配置

首先我们需要导入nacos-config的依赖(注:我这边没有使用nacos的注册发现,依旧沿用自身使用的eureka)。

其中依赖版本的对应关系可以在官网中查找。

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

其次我们需要在配置文件中进行配置,采用bootstrap.yml文件进行配置,因为springboot会优先启动bootstrap.yml文件中的配置。其中文件内容如下:

bootstrasp.yml:

spring:
 application:
 name: vaso-core
 cloud:
 nacos:
# discovery:
# server-addr: xx.xx.xxx.xx:8848
# namespace: 8b387ec4-e60d-4878-baf4-f2246e58a1d6
 config:
 server-addr: xx.xx.xxx.xx:8848
 file-extension: yml
 namespace: 8b387ec4-e60d-4878-baf4-f2246e58a1d6
 profiles:
 active: dev

namespace的内容为上文中配置的dev命名空间的id。

最后我们需要引入@refreshscope关键字,保证可以实时刷新配置。在controller层或者要刷新的值所在的类上进行注释就行。

其中我们的demo是如下所示:

三、试验结果

将工程跑起来,可以看到一开始就已经去配置中心读取配置了,如图:

此时将配置中心内容修改,可以看到已经实时刷新了配置。

四、踩坑经历

其实在正式使用之前也碰到过nacos无法试试实时刷新的问题,打断点却发现实际已经读取到本地,通过进入spring的源码中查看,也发现其实已经可以拿到配置了,但是却一直无法刷新配置。

最后通过一个礼拜的定位源码,断点查询才发现一个本质性的问题。欲哭无泪

@RefreshScope与数据源之间存在冲突!!

具体如下:

  • 因为项目是多数据源,所以使用的是自定义数据源配置的DataSource,用@Bean注入。
  • 在SpringBoot 2.0以上默认使用Hikari连接池,一旦连接池启动,就无法再修改HikariDataSource,所以刷新配置时连带数据源一起刷新,于是会报错。

Caused by: java.lang.IllegalStateException: The configuration of the pool is sealed once started. Use HikariConfigMXBean for runtime changes.

解决方法: 在自定义的DataSource上加入注解@RefreshScope,或者使用spring.scloud.refresh.extra-refreshable配置指定classname列表即可。

查看Hikari的默认配置即可发现,这个与刷新配置之间是存在冲突的。

因此在数据源配置类中加入注释,这样每次刷新配置的时候会重新刷新这个Bean,那么就可以保证不会报错,这样的spring的刷新机制就可以顺利执行下去了。

五、总结

通过这次经历,我发现定位问题的过程是一门极高的学问,学会怎么去看源码,懂原理才能更好的更精准的分析问题所在之处。

作者:弱水提沧原文地址:https://blog.csdn.net/qq_42684642/article/details/106454612

%s 个评论

要回复文章请先登录注册