Nacos 配置模型

在单体架构的时候我们可以将配置写在配置文件中，但有⼀个缺点就是每次修改配置都需要重启服
务才能生效。

当应用程序实例比较少的时候还可以维护。如果转向微服务架构有成百上千个实例，每修改⼀次配
置要将全部实例重启，不仅增加了系统的不稳定性，也提高了维护的成本。

那么如何能够做到服务不重启就可以修改配置？所有就产生了四个基础诉求：

 需要支持动态修改配置
 需要动态变更有多实时
 变更快了之后如何管控控制变更风险，如灰度、回滚等
 敏感配置如何做安全配置

配置(Configuration)

在系统开发过程中通常会将⼀些需要变更的参数、变量等从代码中分离出来独立管理，以独立的配
置文件的形式存在。目的是让静态的系统工件或者交付物（如WAR，JAR 包等）更好地和实际的物
理运行环境进行适配。配置管理⼀般包含在系统部署的过程中，由系统管理员或者运维人员完成这
个步骤。配置变更是调整系统运行时的行为的有效手段之⼀。
配置管理(Configuration Management)
在Nacos 中，系统中所有配置的存储、编辑、删除、灰度管理、历史版本管理、变更审计等所有
与配置相关的活动统称为配置管理。
配置服务(Configuration Service)
在服务或者应用运行过程中，提供动态配置或者元数据以及配置管理的服务提供者。

配置项（Configuration Item）
⼀个具体的可配置的参数与其值域，通常以param-key = param-value 的形式存在。例如我们常
配置系统的日志输出级别（logLevel = INFO | WARN | ERROR） 就是⼀个配置项。
配置集（Configuration Set）
⼀组相关或者不相关的配置项的集合称为配置集。在系统中，⼀个配置文件通常就是⼀个配置集，
包含了系统各个方面的配置。例如，⼀个配置集可能包含了数据源、线程池、日志级别等配置项。
命名空间（Namespace）
用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的Group 或Data ID 的配置。
Namespace 的常用场景之⼀是不同环境的配置的区分隔离，例如开发测试环境和生产环境的资源
（如数据库配置、限流阈值、降级开关）隔离等。如果在没有指定Namespace 的情况下，默认使
用public 命名空间。
配置组（Group）
Nacos中的⼀组配置集，是配置的维度之⼀。通过⼀个有意义的字符串（如ABTest 中的实验组、
对照组）对配置集进行分组，从而区分Data ID 相同的配置集。当您在Nacos 上创建⼀个配置时，
如果未填写配置分组的名称，则配置分组的名称默认采用DEFAULT_GROUP 。配置分组的常见场
景：不同的应用或组件使用了相同的配置项，如database_url 配置和MQ_Topic 配置。

配置ID（Data ID）
Nacos 中的某个配置集的ID。配置集ID 是划分配置的维度之⼀。Data ID 通常用于划分系统的配
置集。⼀个系统或者应用可以包含多个配置集，每个配置集都可以被⼀个有意义的名称标识。Data
ID 尽量保障全局唯⼀，可以参考Nacos Spring Cloud 中的命名规则：

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