nacos配置中心（Nacos配置中心支持增量更新吗）

1. Nacos配置中心使用

官方文档： https://github.com/alibaba/spring-cloud-alibaba/wiki/Nacos-config

nacos 配置中心动态更新RedisConfig_Data

1.1 快速开始准备配置，nacos server中新建nacos-config.properties

nacos 配置中心动态更新RedisConfig_微服务_02

nacos 配置中心动态更新RedisConfig_Data_03

1.2 搭建nacos-config服务

通过 Nacos Server 和 spring-cloud-starter-alibaba-nacos-config 实现配置的动态变更

1）引入依赖

2）添加bootstrap.properties

启动服务，测试微服务是否使用配置中心的配置

nacos 配置中心动态更新RedisConfig_spring cloud_04

1.3 Config相关配置

nacos 配置中心动态更新RedisConfig_Data_05

支持配置的动态更新

支持profile粒度的配置

spring-cloud-starter-alibaba-nacos-config 在加载配置的时候，不仅仅加载了以 dataid 为 $nacos 配置中心动态更新RedisConfig_spring cloud_06$ {file-extension:properties} 为前缀的基础配置，还加载了dataid为 $nacos 配置中心动态更新RedisConfig_spring_07$ {profile}.${file-extension:properties} 的基础配置。在日常开发中如果遇到多套环境下的不同配置，可以通过Spring 提供的 ${spring.profiles.active} 这个配置项来配置。

支持自定义 namespace 的配置

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

在没有明确指定 ${spring.cloud.nacos.config.namespace} 配置的情况下，默认使用的是 Nacos 上 Public 这个namespace。如果需要使用自定义的命名空间，可以通过以下配置来实现：

支持自定义 Group 的配置

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

在没有明确指定 ${spring.cloud.nacos.config.group} 配置的情况下，默认是DEFAULT_GROUP 。如果需要自定义自己的 Group，可以通过以下配置来实现：

支持自定义扩展的 Data Id 配置

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

通过自定义扩展的 Data Id 配置，既可以解决多个应用间配置共享的问题，又可以支持一个应用有多个配置文件。

1.4 配置的优先级

Spring Cloud Alibaba Nacos Config 目前提供了三种配置能力从 Nacos 拉取相关的配置。

A: 通过 spring.cloud.nacos.config.shared-configs 支持多个共享 Data Id 的配置
B: 通过 spring.cloud.nacos.config.ext-config[n].data-id 的方式支持多个扩展 Data Id 的配置
C: 通过内部相关规则(应用名、应用名+ Profile )自动生成相关的 Data Id 配置

当三种方式共同使用时，他们的一个优先级关系是:A < B < C

优先级从高到低：

nacos-config-product.yaml 精准配置
nacos-config.yaml 同工程不同环境的通用配置
ext-config: 不同工程扩展配置
shared-dataids 不同工程通用配置

1.5 @RefreshScope

@Value注解可以获取到配置中心的值，但是无法动态感知修改后的值，需要利用@RefreshScope注解

2. Nacos配置中心源码分析

https://www.processon.com/view/link/603f3d2fe401fd641adb51f1

2.1 配置中心的架构

nacos 配置中心动态更新RedisConfig_spring cloud_08

nacos 配置中心动态更新RedisConfig_微服务_09

2.2 nacos config client源码分析

nacos 配置中心动态更新RedisConfig_java_10

2.2.1 获取配置 获取配置的主要方法是 NacosConfigService 类的 getConfig 方法，通常情况下该方法直接从本地文件中取得配置的值，如果本地文件不存在或者内容为空，则再通过 HTTP GET 方法从远端拉取配置，并保存到本地快照中。当通过 HTTP 获取远端配置时，Nacos 提供了两种熔断策略，一是超时时间，二是最大重试次数，默认重试三次。

nacos 配置中心动态更新RedisConfig_spring cloud_11

2.2.2 注册监听器

配置中心客户端会通过对配置项注册监听器达到在配置项变更的时候执行回调的功能。

nacos 配置中心动态更新RedisConfig_java_12

nacos 配置中心动态更新RedisConfig_Data_13

2.2.3 配置长轮询

nacos 配置中心动态更新RedisConfig_spring cloud_14

2.3 nacos config server源码分析
2.3.1 配置dump

nacos 配置中心动态更新RedisConfig_spring_15

全量 dump 当然先清空磁盘缓存，然后根据主键 ID 每次捞取一千条配置刷进磁盘和内存。增量 dump 就是捞取最近六小时的新增配置（包括更新的和删除的），先按照这批数据刷新一遍内存和文件，再根据内存里所有的数据全量去比对一遍数据库，如果有改变的再同步一次，相比于全量 dump 的话会减少一定的数据库 IO 和磁盘 IO 次数。

2.3.2 配置发布

nacos 配置中心动态更新RedisConfig_Data_16

2.3.3 处理长轮询 客户端会有一个长轮询任务，拉取服务端的配置变更，服务端处理逻辑在LongPollingService类中，其中有一个 Runnable 任务名为ClientLongPolling，服务端会将受到的轮询请求包装成一个 ClientLongPolling 任务，该任务持有一个 AsyncContext 响应对象，通过定时线程池延后 29.5s 执行。比客户端 30s 的超时时间提前 500ms 返回是为了最大程度上保证客户端不会因为网络延时造成超时。

nacos 配置中心动态更新RedisConfig_java_17

到此这篇nacos配置中心（Nacos配置中心支持增量更新吗）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！

上一篇：肃州区人力资源配置中心代理部（肃州区人力资源配置中心代理部主任）

下一篇：配置中心（nacos配置中心）

版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/qkl-jr/22168.html

相关文章：