一.前言

Nacos简介

二.Nacos配置中心发展历程

Nacos配置中心是从阿里集团内配置中心Diamond孵化而来，其整体发展分为三个阶段：

1.阿里集团内部孵化期

nacos配置中心诞生于阿里巴巴集团内部的配置中心Diamond，前期主要服务于集团内部对动态配置的需求。

2.开源&商业化探索尝试

集团Diamond经历了从开源再到闭源的过程，发布了商业化产品ACM，并在2018年以Nacos配置中心为载体再次开源，期间对配置中心的开源及商业化进行了探索。

3.三位一体融合发展

明确三位一体发展战略，以开源Nacos为内核，插件化支持集团Diamond&商业化MSE定制的配置中心，三位一体融合发展。

开源：以开源Nacos 2.0 为内核，重构通信协议，性能扩展性提升10倍，支持10w级实例规模，提升开放性，联合开源微服务生态共同发展。

商业化：支持Nacos2.0和专业版，目前20%用户升级到Nacos2.0，并且支持配置鉴权和加密能力，推送轨迹等高级功能。

集团：关注性能和高可用能力，支持大促1小时建站，10分钟支持响应；完成Diamond Over Nacos2.0架构演进，扩展性提升1倍，支持500w实例规模。

三.应用场景&双十一实践

Nacos 配置管理应用场景

配置中心在业务域，基础技术域都有着广泛的应用，包括业务应用的开关，微服务生态的服务路由及元数据，高可用生态的预案，切流规则及降级开关等，前端生态的各类文案公告，数据库生态的核心配置参数，动态切库等配置。

在每年阿里集团的双十一大促中，配置中心也是一个不可或缺的基础组件，包括前期热点商品推送，大促氛围活动标调整，大促期间数据库主备切换开关，核心功能降级，各类名单调整，预案限流调整，各种基础中间件的核心参数动态，大促结束后各类预案的恢复，大促态到日常态的状态切换，都是配置中心所支持的场景。

四.配置中心使用指引

1.配置中心原理

1、业务应用：nacos的使用方，通过nacos-client实现配置的发布，查询，监听回调的等基础操作。
2、负载均衡SLB：与后端的nacos服务节点进行交互的地址，在用户自建或者调试的场景下，也可以采用直连IP或者地址服务器endpoint的模式。
3、Nacos Server：nacos服务端存储当前集群全量配置的内存和磁盘缓存，集群节点之间进行水平通知配置变更事件，和后端数据库进行对账保证数据一致性。
4、Nacos控制台：管理控制台，可以进行配置查看，配置发布，监听查询等运维功能。商业化Nacos支持推送轨迹，监控，事件中心等高级功能。
5、数据库：配置持久化存储的数据库，一般是主备库架构进行容灾。

用户在接入nacos主要有两种模式，一种是通过原生nacos-client的ConfigService组件的基础API接入，第二种是通过Spring框架或者其他类似框架组件接入，包括SpringCloud和SpringBoot等。

2.基础API接入

nacos配置中心以NacosConfigService接口对外提供基础API，包括配置发布，查询，监听，回调等基础功能。

在构建ConfigService时需要指定Nacos的服务端地址，需要访问的命名空间。更多的API使用细节，可参照官方文档。

Properties properties = new Properties();
properties.put(PropertyKeyConst.SERVER_ADDR, "127.0.0.1");
properties.put(PropertyKeyConst.NAMESPACE, "namespaceId");
final ConfigService configService = new NacosConfigService(properties);
final String dataId = "my-config-dataId";
final String group = "group";
//初始化查询配置，并添加监听器，监听后续变更
String config = configService.getConfigAndSignListener(dataId, group, 3000L, new Listener() {
    @Override
    public Executor getExecutor() {
        //如果回调逻辑比较耗时，建议自定义线程池，以免堵塞推送回调线程
        return null;
    }
    @Override
    public void receiveConfigInfo(String configInfo) {
        handleBusinessLogic(configInfo);
    }
});
//初始化业务逻辑.
handleBusinessLogic(config);

3.SpringCloud接入

新增bootstrap.yml,配置nacos相关参数，包括nacos地址，命令空间等参数，具体可参照com.alibaba.cloud.nacos.NacosConfigProperties属性类。

spring:
  application:
    name: nacos-config-demo
  cloud:
    nacos:
      config:
        server-addr: 127.0.0.1:8848
        namespace: namespaceid-对应nacos服务端的命名空间ID,public填空
        group: group-demo
        file-extension: yml
        refresh-enabled: true
        accessKey: xxx
        secretKey: xxx

在配置中心对应那么下创建dataId=nacos-config-demo.yml,group=group-demo的配置

使用@Value注解引用nacos中的参数值，当nacos中配置值发生变化时，value的值会自动更新

@Configuration
@RefreshScope
public class ConfigBean {
    @Value("${cache.useLocalCache:false}")
    private boolean useLocalCache;
    public boolean isUseLocalCache() {
        return useLocalCache;
    }
}

通过Value注解可以实现属性值的自动更新，如果希望在配置内容变更时触发回调方法执行，在SpringCloud也可以通过

NacosConfigManager#getConfigService获取springboot内置的NacosConfigService进行基础API操作。

更多的接入指引可参照官方文档。

Spring:https://nacos.io/zh-cn/docs/quick-start-spring.html
Spring Boot:https://nacos.io/zh-cn/docs/quick-start-spring-boot.html
Spring Cloud:https://nacos.io/zh-cn/docs/quick-start-spring-cloud.html

4.日志自助排查

以上介绍两种比较典型的nacos配置中心的接入方式，在日常使用过程中，nacos-client本地的日志是非常有助于提高问题排查效率。nacos在发布配置，监听配置及变更推送时都会在{user.home}/logs/nacos/config.log中打印详细的事件日志。以下是客户端运行期打印的几个关键日志：

1、add-listener: 添加监听，只有添加了对配置的监听，才能收到配置变更推送
2、server-push：客户端已经收到某个配置的变更通知
3、data-received：收到变更通知后，客户端向服务端查询到了最新的配置内容
4、notify-listener: nacos回调了的监听器Listener，可以看到回调的配置内容MD5。
5、notify-ok: 回调执行正常，可以查看执行回调的具体监听器Listener，执行耗时。
6、notify-error:监听器执行失败，对业务来说可能业务不符合预期，需要根据异常排查原因。

如果有notify-listener日志，但是没有notify-ok日志，则可能是监听器执行堵塞。如果想确认回调线程是否阻塞，可以通过jstack命令查看线程堆栈，jstack {pid} | grep -20 'nacos' ，通过堆栈判断导致线程堵塞的原因，对应解决即可。

5.使用须知

1、小配置

配置中心的主要作用是发布meta-data，而不是数据的存储服务。我们对所发布的单个配置数据内容大小100k以内。

2、低频变更

nacos是个配置管理系统，不是流量链路产品，配置变更需小于1次/分钟。

3、低频查询

nacos与redis等缓存产品有着本质上区别，所以请不要在流量链路内查询配置，正常情况下应用启动时查询一次配置进行业务初始化，后续只需监听配置变化即可。

4、最终一致性

nacos只保证最后一次推送的值一定会到达，不保证中间的每一次变更都会送达订阅端。配置在发布成功后并不是实时推送到客户端，中间有一定的时延。

5、幂等性

nacos可能在网络状况欠佳时会向订阅者发送重复的数据通知，订阅者对数据通知的处理应满足幂等性，支持重复推送，相同配置回调多次不应产生异常预期外的情况。

6、轻回调

在回调监听器中，处理逻辑应尽量轻量化，高耗时操作容易堵塞回调线程，影响其他配置的推送。对于重回调的场景，可以自定义业务线程池异步化处理。

常见错用场景：

配置超过1M，频繁变更导致配置中心数据库可用性下降
配置频繁变更，导致对客户端造成推送风暴，造成客户端应用cpu,gc压力。
客户端在流量链路中调用getConfig方法查询配置，业务请求上涨时，配置中心服务端压力上涨，可用性下降
回调方法中处理远程RPC，IO操作，锁等待等造成回调方法执行堵塞，进而堵塞其他配置变更推送，影响业务

五.配置中心高可用

1.客户端容灾

容灾目录

当服务端不可用时且短时无法恢复时，用户可以在本地的容灾目录中手动更新配置内容，以达到模拟服务端配置发生变更的场景。容灾目录中的配置内容具有最高优先级，配置的查询&监听逻辑都将返回容灾配置内容，因此当远程nacos服务端恢复正常时，需要将容灾目录中的内容发布到远端，然后删除本地容灾目录。

容灾目录地址：

public命名空间：{user.home}/nacos/config/{servername}_nacos/data/config-data
非public命名空间：{user.home}/nacos/config/{servername}_nacos/data/config-data-tenant

本地缓存

nacos向服务端查询一次配置内容时，会将内容同步到本地磁盘，当下一次访问服务端接口失败时，会读取本地配置内容，以最大程度保证客户端可用。

缓存目录地址：

public命名空间：{user.home}/nacos/config/{servername}_nacos/snapshot
非public命名空间:{user.home}/nacos/config/{servername}_nacos/snapshot-tenant

2.服务端反脆弱

在上一章节中的使用须知里，我们分享了使用nacos配置中心的一些使用限制及误用场景，而当客户端错用已经发生时，服务端的反脆弱机制保证了客户端的错用不会影响服务端的可用性。

服务端的反脆弱机制包括连接限流，频繁变更限流，配置发布流量限流等机制来保证可用性。

六.商业化MSE优势

微服务引擎MSE是一个面向业界主流开源微服务框架SpringCloud、Dubbo以及多语言等一站式微服务平台，支持服务网格生态，标准、灵活、精准的控制流量，帮助提升系统整体的可用性，并且MSE在高可用、性能、安全方面大量增强，让您的应用获得企业级的保障。

MSE Nacos和自建Nacos对比

*迁移指引

自建Nacos迁移Mse Nacos

详见：https://help.aliyun.com/document_detail/460944.html

ACM迁移MSE Nacos

详见：https://help.aliyun.com/document_detail/312705.html

Applo等迁移MSE Nacos

详见：https://help.aliyun.com/document_detail/460717.html

七.Nacos3.0

Nacos3.0中，在SDK能力提升，界面交互升级，服务端核心能力，可观测可运维，稳定性&高可用方面都规划了诸多功能，除了基础通用的产品能力外，其中配置中心规划了社区呼声较高的模糊订阅功能，也将基于长连接的一致性协议进行升级，提升当前版本在边界异常场景下的稳定性及可靠性，欢迎对Nacos感兴趣的社区开发者参与其中。

Nacos 配置管理最佳实践