（Nacos）Nacos Config配置中心
目录
1. 微服务配置中心背景
1.1 微服务配置文件问题
1.2 配置中心解决思路
1.3 配置中心架构图
1.4 业界开源配置中心举例
2. Nacos Config配置中心概念
2.1 Namespace命名空间
2.1.1 概念
2.1.2 场景
2.2 Group
2.2.1 概念
2.2.2 场景
2.3 DataId
3. Nacos配置动态刷新
3.1 硬编码方式
3.2 注解方式（推荐使用）
4. Nacos配置共享
4.1 同一微服务，不同场景（namespace）下共享配置
4.1.1 实现步骤
4.1.2 实现案例
4.2 不同微服务之间共享共享配置
4.2.1 实现步骤
4.2.2 实现案例
1. 微服务配置中心背景
1.1 微服务配置文件问题
配置文件相对分散。在一个微服务架构下，配置文件会随着微服务的增多变的越来越多，而且分散在各个微服务中，不好统一配置和管理。
配置文件无法区分环境。微服务项目可能会有多个环境，例如：测试环境、预发布环境、生产环境。每一个环境所使用的配置理论上都是不同的，一旦需要修改，就需要我们去各个微服务下手动维护，这比较困难。
配置文件无法实时更新。我们修改了配置文件之后，必须重新启动微服务才能使配置生效，这对一个正在运行的项目来说是非常不友好的。
1.2 配置中心解决思路
首先把项目中各种配置全部都放到一个集中的地方进行统一管理，并提供一套标准的接口。
当各个服务需要获取配置的时候，就来配置中心的接口拉取自己的配置。
当配置中心中的各种参数有更新的时候，也能通知到各个服务实时的过来同步最新的信息，使之动态更新。
1.3 配置中心架构图
1.4 业界开源配置中心举例
Apollo
Apollo是由携程开源的分布式配置中心。特点有很多，比如：配置更新之后可以实时生效，支持灰度发布功能，并且能对所有的配置进行版本管理、操作审计等功能，提供开放平台API。并且资料也写的很详细。
Disconf
Disconf是由百度开源的分布式配置中心。它是基于Zookeeper来实现配置变更后实时通知和生效的。
SpringCloud Confifig
这是Spring Cloud中带的配置中心组件。它和Spring是无缝集成，使用起来非常方便，并且它的配置存储支持Git。不过它没有可视化的操作界面，配置的生效也不是实时的，需要重启或去刷新。
Nacos
这是SpingCloud alibaba技术栈中的一个组件，前面我们已经使用它做过服务注册中心。其实它也集成了服务配置的功能，我们可以直接使用它作为服务配置中心。
2. Nacos Config配置中心概念
Nacos Config 主要通过 dataId 和 group 来唯一确定一条配置.
Nacos Client 从 Nacos Server 端获取数据时，调用的是此接口 ConfigService.getConfig(String dataId, String group, long timeoutMs)。
。
2.1 Namespace命名空间
2.1.1 概念
用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离，例如开发测试环境和生产环境的资源（如配置、服务）隔离等。默认namespace=public的保留空间,不支持删除;默认情况下。
2.1.2 场景
Nacos给的最佳实践表明，最外层的namespace是可以用于区分部署环境的，比如test，dev，prod等。同时，也有一个商业利用价值：多租户(以后会介绍)。以namespace为单位，给用户开辟使用空间。
命名空间可用于进行不同环境的配置隔离。一般一个环境划分到一个命名空间
2.2 Group
2.2.1 概念
Nacos 中的一组配置集，是组织配置的维度之一。通过一个有意义的字符串（如 Buy 或 Trade ）对配置集进行分组，从而区分 Data ID 相同的配置集。当您在 Nacos 上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用DEFAULT_GROUP 。
2.2.2 场景
不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。
可以通过 spring.cloud.nacos.config.group 配置
配置分组用于将不同的服务可以归类到同一分组。一般将一个项目的配置分到一组
2.3 DataId
Nacos 中的某个配置集的 ID。配置集 ID 是组织划分配置的维度之一。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。
在系统中，一个配置文件通常就是一个配置集。一般微服务的配置就是一个配置集
在 Nacos Config Starter 中，dataId 的拼接格式如下
${prefix} - ${spring.profiles.active} . ${file-extension}
（1）prefix 默认为 spring.application.name 的值，也可以通过配置项 spring.cloud.nacos.config.prefix来配置。（2）spring.profiles.active 即为当前环境对应的 profile，详情可以参考 Spring Boot文档
（3）file-extension 为配置内容的数据格式，可以通过配置项 spring.cloud.nacos.config.file-extension来配置。目前只支持 properties 和 yaml 类型。
注意，当 activeprofile 为空时，对应的连接符 - 也将不存在，dataId 的拼接格式变成 {prefix}.{file-extension}
3. Nacos配置动态刷新
实现在配置中心修改配置文件内容后，程序内部引用可以自动刷新
我们可以在自己创建的DataId配置文件中，更改项：
config:
appName: product
通过两种方式实现程序中动态修改。
3.1 硬编码方式
@RestController
public class NacosConfigController {
@Autowired
private ConfigurableApplicationContext applicationContext;
@GetMapping( "/nacos-config-test1" )
public String nacosConfingTest1(){
return (applicationContext.getEnvironment().getProperty( "config.appName" ) );
}
}
3.2 注解方式（推荐使用）
@RestController
@RefreshScope /* 只需要在需要动态读取配置的类上添加此注解就可以 */
public class NacosConfigController {
@Value( "${config.appName}" )
private String appName;
/* 2 注解方式 */
@GetMapping("/nacos-config-test2")
public String nacosConfingTest2(){
return(appName);
}
}
4. Nacos配置共享
当配置越来越多的时候，我们就发现有很多配置是重复的，这时候就考虑可不可以将公共配置文件提取出来，然后实现共享。共享存在两种场景：同一微服务，不同场景（namespace）下共享；不同微服务之间共享
4.1 同一微服务，不同场景（namespace）下共享配置
4.1.1 实现步骤
例如统一为服务 jeecg，在dev，test环境下 共享同一数据配置信息
（1）dev的namespace环境下
jeecg-dev.yaml
（2）test的namesapce环境下
jeecg-test.yaml
（3）抽取共享配置： jeecg.yaml
4.1.2 实现案例
https://blog.csdn.net/rxh811/article/details/106762708/?utm_medium=distribute.pc_relevant.none-task-blog-baidujs_title-0&spm=1001.2101.3001.4242
4.2 不同微服务之间共享共享配置
4.2.1 实现步骤
不同为服务之间实现配置共享的原理类似于文件引入，就是定义一个公共配置，然后在当前配置中引入。
（1）核心配置就是将共享配置内容单独建立配置文件:jeecg-common.yaml
（2）bootstrap.yml中引入该共享配置文件以及相关设置。
4.2.2 实现案例
https://blog.csdn.net/rxh811/article/details/106762708/?utm_medium=distribute.pc_relevant.none-task-blog-baidujs_title-0&spm=1001.2101.3001.4242