Nacos 配置中心用法详细教程
我们这篇文章介绍下 Nacos 作为配置中心的基本用法，首先我们先了解下为什么需要使用配置中心。
正文
一、为什么需要配置中心：
在没有配置中心之前，传统应用配置的存在以下痛点：
（1）采用本地静态配置，无法保证实时性：修改配置不灵活且需要经过较长的测试发布周期，无法尽快通知到客户端，还有些配置对实时性要求很高，比方说主备切换配置或者碰上故障需要修改配置，这时通过传统的静态配置或者重新发布的方式去配置，那么响应速度是非常慢的，业务风险非常大
（2）易引发生产事故：比如在发布的时候，容易将测试环境的配置带到生产上，引发生产事故。
（3）配置散乱且格式不标准：有的用properties格式，有的用xml格式，还有的存DB，团队倾向自造轮子，做法五花八门。
（4）配置缺乏安全审计、版本控制、配置权限控制功能：谁？在什么时间？修改了什么配置？无从追溯，出了问题也无法及时回滚到上一个版本；无法对配置的变更发布进行认证授权，所有人都能修改和发布配置。
而配置中心区别于传统的配置信息分散到系统各个角落的方式，对系统中的配置文件进行集中统一管理，而不需要逐一对单个的服务器进行管理。那这样做有什么好处呢？
（1）通过配置中心，可以使得配置标准化、格式统一化
（2）当配置信息发生变动时，修改实时生效，无需要重新重启服务器，就能够自动感知相应的变化，并将新的变化统一发送到相应程序上，快速响应变化。比方说某个功能只是针对某个地区用户，还有某个功能只在大促的时段开放，使用配置中心后只需要相关人员在配置中心动态去调整参数，就基本上可以实时或准实时去调整相关对应的业务。
（3）通过审计功能还可以追溯问题
二、Nacos配置中心的使用：
微服务中配置中心的主流解决方案主要有三种：Nacos、Apollo、Config+Bus，不过这篇文章我们主要介绍 Nacos 作为配置中心的用法，对其他两种方式感兴趣的读者请自行上网查阅
1、Springboot 整合 Nacos 配置中心：
（1）首先我们声明项目的版本信息：
（2）添加 nacos 配置中心的 maven 依赖：
（3）在 application.properties 文件中添加 nacos 配置中心相关配置：
（4）在 nacos 控制台新建一个 DataID 为 的配置集：
为什么 DataID 的命名为 会在下文介绍
（5）编写测试类：
（6）启动服务验证：
启动项目，访问 接口，可以看到 nacos 配置中心的配置信息已经生效并被成功获取到了
（7）验证动态刷新配置：
配置的动态刷新是配置中心最核心的功能之一，假设我现在需要修改 的值，那么我直接改变 Nacos 中的配置会生效吗？我们试下直接将 Nacos 中的配置修改成 “zhangsan”，如下图：
此时不重启项目并重新访问该接口，结果如下：
我们发现配置已经动态刷新了，这是为什么呢？其实是由于我们在类上添加了 注解而产生的效果。
2、Nacos 的核心概念：
2.1、Data ID：
（1）Data ID 的命名格式：
前面我们演示了在 nacos 控制台新建一个 DataID 为 的数据集，那么这个 Data ID 是什么呢？
Data ID 是配置集的唯一标识，一个应用可以包含多个配置集，每个配置集都需要被一个有意义的名称标识。那么 Data ID 怎么取值呢？格式通俗一点就是 “前缀-环境-扩展名”，如下所示：
① prefix： 前缀，默认是 的值，也可以通过配置项 来配置。
② active： 配置运行环境，即为当前环境对应的 profile。
注意：当 为空时，对应的连接符 ”-“ 也将不存在，dataId 的拼接格式变成
③ file-exetension： 配置文件的类型，默认是 ，也可以通过配置项 来配置，目前支持的类型有
④ 最终配置：
经过前面三个步骤，我们最终在nacos配置中心的控制台新增配置文件就是：
2.2、环境隔离-命名空间Namespace：
Nacos 引入命名空间 Namespace 的概念来进行多环境配置和服务的管理及隔离。
例如，你可能存在本地开发环境dev、测试环境test、生产环境prod 三个不同的环境，那么可以创建三个不同的 Namespace 区分不同的环境。创建方式如下：
创建完成后，就可以在Nacos 控制台的配置列表上面看到不同的命名空间了，如下图：
成功创建新命名空间后，就可以在 springboot 的配置文件配置命名空间的 id 切换到对应的命名空间，并获取对应空间下的配置文件，但在没有指定命名空间配置的情况下，默认的配置都是在 public 空间中，指定命名空间的方式如下：
2.3、业务隔离-Group分组：
Group 也可以实现环境隔离的功能，但 Group 设计的目的主要是做同一个环境中的不同服务分组，把不同的微服务的配置文件划分到同一个分组里面去，Nacos 如果不指定 Group，则默认的分组是 。
如果没有 Group，试想一下这个场景：有两个微服务，一个是订单系统，一个是用户系统，但是他们有着相同的配置，比如 ，那么如何区分呢？这时候 Group 就派上用场了。
上述场景中订单系统、用户系统可以单独分为一个组，比如 ，当然这是比较细粒度的分组，根据企业的业务也可以多个微服务分为一组。
接下来我们演示一下创建配置集时以及集成时如何指定分组，还是前面的例子，新建配置集是在如下位置指定Group分组：
接下来在 文件分组：
3、小结：
Nacos 实现配置管理和动态配置刷新很简单，总结如下步骤：添加对应 依赖使用原生注解 导入配置使用原生注解 刷新配置根据自己业务场景做好多环境配置隔离(Namespace)、不同业务配置隔离(Group)
4、共享配置：
当我们微服务的数量越来越多，势必会有相同的配置，这时我们可以将相同的配置抽取出来作为项目中共有的配置，比如集群中的数据源信息、日志的配置信息，nacos 也是支持这种一个配置中心多个配置集这种写法的。
（1）我们在nacos中新建两个 Data ID 分别是 db.yaml 和 log.yaml 的文件。
（2）在配置文件中分别加入部分配置内容
（3）在 Springboot 项目中添加如下的 nacos 配置：
为了更加清晰的在多个应用间配置共享的 Data Id，官方推荐使用 ，配置如下：
（4）思考：在这2个文件中出现相同配置，nacos如何选取？
当多个 Data Id 同时出现相同的配置时，它的优先级关系是 其中 n 的值越大，优先级越高。注意： 的值必须带文件扩展名，文件扩展名既可支持 properties，又可以支持 yaml/yml。此时 的配置对自定义扩展配置的 Data Id 文件扩展名没有影响。
（5）不同方式配置加载优先级：
Nacos 配置中心目前提供以下三种配置能力从 Nacos 拉取相关的配置，当三种方式共同使用时，他们的一个优先级关系是:A < B < C：
A：通过 支持多个共享 Data Id 的配置
B：通过 的方式支持多个扩展 Data Id 的配置
C：通过内部相关规则(、、)自动生成相关的 Data Id 配置
对此，你有什么想补充的？欢迎在评论区留言~文章配套笔记资料点这个领取文章笔记资料在这里领取
