nacos 配置 Ignore the empty nacos configuration and get it based on dataId nacos 配置更新原理

微服务架构系列之Nacos 配置核心概念

nacos数据模型

核心概念

1、配置
为什么需要配置？概念。

在系统开发过程中，开发者通常会将一些需要变更的参数、变量等从代码中分离出来独立管理，以独立的配置文件的形式存在。
目的是让静态的系统工件或者交付物（如 WAR，JAR 包等）更好地和实际的物理运行环境进行适配。
配置管理一般包含在系统部署的过程中，由系统管理员或者运维人员完成。
配置变更是调整系统运行时的行为的有效手段。

2、配置管理
对配置的多维度管理。

系统配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动。

3、配置项
一个键值对 Key = Value。

一个具体的可配置的参数与其值域（一个键值对），通常以 param-key=param-value 的形式存在。
例如我们常配置系统的日志输出级别（logLevel=INFO|WARN|ERROR） 就是一个配置项。

4、配置集
多个键值对，一般指一个配置文件。

一组相关或者不相关的配置项的集合称为配置集（多个键值对/一个配置文件）。
在系统中，一个配置文件通常就是一个配置集，包含了系统各个方面的配置。
例如，一个配置集可能包含了数据源、线程池、日志级别等配置项。

5、配置集 ID
给这个配置文件起一个全局唯一的 ID。

Nacos 中的某个配置集的 ID。
配置集 ID 是组织划分配置的维度之一。
Data ID 通常用于组织划分系统的配置集。
一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。
Data ID 通常采用类 Java 包（如 com.taobao.tc.refund.log.level）的命名规则保证全局唯一性。
此命名规则非强制。

6、配置分组
多个配置文件放在一起，形成组，一般用于区分项目。
例如，某学校多应用之间的区分，教师应用 TEACHER_GROUP，学生应用
STUDENT_GROUP。

Nacos 中的一组配置集，是组织配置的维度之一。
通过一个有意义的字符串（如 Buy 或 Trade ）对配置集进行分组，从而区分 Data ID 相同的配置集。
当您在 Nacos 上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP 。
配置分组的常见场景：不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。

7、配置快照
缓存配置信息。

Nacos 的客户端 SDK 会在本地生成配置的快照。
当客户端无法连接到 Nacos Server 时，可以使用配置快照显示系统的整体容灾能力。
配置快照类似于 Git 中的本地 commit，也类似于缓存，会在适当的时机更新，但是并没有缓存过期（expiration）的概念。

8、命名空间
区分环境，比如：dev、test、prod 等等。

用于进行租户粒度的配置隔离。
不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。
Namespace 的常用场景之一是不同环境的配置的区分隔离。
例如开发测试环境和生产环境的资源（如配置、服务）隔离等。

9、最佳实践

通常我们可以这样定义 Namespace，Group，DataId：
Namespace：代表不同的「环境」，如：开发、测试， 生产等；
Group：代表某个「项目」，如：XX物流项目，XX教育项目；
DataId：每个项目下往往有若干个「应用」，每个配置集(DataId)是一个应用的「主配置文件」

原理

原理总结：
1、Nacos 客户端会循环请求服务端，并且超时时间设置为30s，
服务端会把请求放到一个队列中，使用延时队列来实现，延时设为客户端设置的超时时间减掉500ms，
这里为什么要减掉500ms？是服务端响应客户端时，防止客户端超时。
如果配置一直不变，那么服务端就会等到指定延时时间，然后响应客户端，
但是，当配置发生变化时，服务端就不会等待指定延时时间，而是会直接响应客户端。

2、Nacos 客户端能够实时感知到服务端配置发生了变化。
实时感知是建立在客户端拉和服务端“推”的基础上，
但是这里的服务端“推”需要打上引号，因为服务端和客户端直接本质上还是通过 http 进行数据通讯的，
之所以有“推”的感觉，是因为服务端主动将变更后的数据通过 http 的 response 对象提前写入了。

搭建
本地下载和安装nacos搭建参考这篇