动态配置管理是 Nacos 的三大功能之一，通过动态配置服务，我们可以在所有环境中以集中和动态的方式管理所有应用程序或服务的配置信息。
动态配置中心可以实现配置更新时无需重新部署应用程序和服务即可使相应的配置信息生效，这极大了增加了系统的运维能力。
配置中心的架构
配置中心本身并不复杂，前提是你先将 CAP 的取舍问题晾在一边的话。配置中心最基础的功能就是存储一个键值对，用户发布一个配置（configKey），然后客户端获取这个配置项（configValue）；进阶的功能就是当某个配置项发生变更时，将变更告知客户端刷新旧值。
下方的架构图，简要描述了一个配置中心的大致架构，用户可以通过管理平台发布配置，通过 HTTP 调用将配置注册到服务端，服务端将之保存在 MySQL 等持久化存储引擎中；用户通过客户端 SDK 访问服务端的配置，同时建立 HTTP 的长轮询监听配置项变更，同时为了减轻服务端压力和保证容灾特性，配置项拉取到客户端之后会保存一份快照在本地文件中，SDK 优先读取文件里的内容。
这里省略了许多细节问题，例如配置分层设计，权限校验，客户端长轮询的间隔设置，服务端每次查询都需要访问 MySQL 么，配置变更是主动推送还是等定时轮询触发等，还有就是运维高可用方面的工作（私以为这个是配置中心的精华），例如节点跨地域部署，网络分区时配置如何保证可写可推送变更等。真正实现一个高质量的配置中心，还是需要长时间打磨的。
使用
使用非常简单
try {
// 传递配置
String serverAddr = "{serverAddr}";
String dataId = "{dataId}";
String group = "{group}";
Properties properties = new Properties();
properties.put("serverAddr", serverAddr);
// 新建 configService
ConfigService configService = NacosFactory.createConfigService(properties);
String content = configService.getConfig(dataId, group, 5000);
System.out.println(content);
// 注册监听器
configService.addListener(dataId, group, new Listener() {
@Override
public void receiveConfigInfo(String configInfo) {
System.out.println("recieve1:" + configInfo);
}
@Override
public Executor getExecutor() {
return null;
}
});
} catch (NacosException e) {
// TODO
-generated catch block
e.printStackTrace();
}serverAddr 传递的是配置中心服务端的地址列表，被内部名为 ServerListManager 的类解析成地址列表进行管理，进行 HTTP 调用时会从中选择存活的机器拼接成 URL 完成调用，一旦在调用时该地址抛异常，则客户端会有一些处理措施，例如转换下次选择的节点等。值得注意的是，通常在实践中不会采取这种硬编码的方式，可以将其配置在 Zookeeper 或者注册发现中心上，在启动时动态拉取。
Nacos 客户端解析
获取配置的主要方法是 NacosConfigService 类的 getConfigInner 方法，通常情况下该方法直接从本地文件中取得配置的值，如果本地文件不存在或者内容为空，则再通过 HTTP GET 方法从远端拉取配置，并保存到本地快照中。
当通过 HTTP 获取远端配置时，Nacos 提供了两种熔断策略，一是超时时间，二是最大重试次数，默认重试三次。
配置长轮询
ClientWorker 通过其下的两个线程池完成配置长轮询的工作，一个是单线程的 executor，每隔 10ms 按照每 3000 个配置项为一批次捞取待轮询的 cacheData 实例，将其包装成为一个 LongPollingTask 提交进入第二个线程池 executorService 处理。
该长轮询任务内部主要分为四步：
- 检查本地配置，忽略本地快照不存在的配置项，检查是否存在需要回调监听器的配置项
- 如果本地没有配置项的，从服务端拿，返回配置内容发生变更的键值列表
- 每个键值再到服务端获取最新配置，更新本地快照，补全之前缺失的配置
- 检查
MD5 标签是否一致，不一致需要回调监听器
值得注意的是：nacos config的配置必须配置在bootstrap.properties文件中，不然无法加载
spring.profiles.active=prod
spring.application.name=order-service
spring.cloud.nacos.discovery.server-addr=localhost:8848
spring.cloud.nacos.config.server-addr=localhost:8848
#谁在越后面有优先级越高
spring.cloud.nacos.config.shared-configs[0]=common1.properties
spring.cloud.nacos.config.shared-configs[1]=common2.properties
引入配置
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
nacos上配置如下：
与apollo对比
界面
在界面上对2个对比，个人感觉2者都差不多，nacos可能看起来比较简洁，直接把所有项目和配置都直接展示出来了，但是apollo再项目划分概念上就比较清晰，进入后首先需要选择项目，选择项目后跳转才可以看到里面的配置，在配置上与nacos不同，apollo将每个配置项都分开解析出来了，每个配置项都有单独的发布和未发布的提示，个人感觉比nacos会更加清晰，更加适合生产项目的配置和公共项上的配置。
功能
功能上对nacos以及apollo进行了对比，配置中心所需要的基本功能2者都有，总体说apoolo的功能会更加全面一些。
关注公众号 soft张三丰
