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

目录

• 一、Nacos配置中心介绍
• 二、配置中心搭建
• 1.配置中心启用
• 2.创建配置文件
• 3.工程配置
• 三、试验结果
• 四、踩坑经历
• 五、总结

近期有用到阿里的开源配置中心及注册中心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的刷新机制就可以顺利执行下去了。

五、总结

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

以上为个人经验，希望能给大家一个参考，也希望大家多多支持我们。