关于阿里云:Nacos-配置管理最佳实践

53次阅读

共计 5190 个字符,预计需要花费 13 分钟才能阅读完成。

作者:翼严

Nacos 简介

Nacos 是一个更易于构建云原生利用的微服务根底平台,外围蕴含动静服务发现,配置管理,服务治理平台。

配置管理是 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. 配置核心原理

  • 业务利用:nacos 的应用方,通过 nacos-client 实现配置的公布,查问,监听回调的等根底操作。
  • 负载平衡 SLB:与后端的 nacos 服务节点进行交互的地址,在用户自建或者调试的场景下,也能够采纳直连 IP 或者地址服务器 endpoint 的模式。
  • Nacos Server:nacos 服务端存储以后集群全量配置的内存和磁盘缓存,集群节点之间进行程度告诉配置变更事件,和后端数据库进行对账保证数据一致性。
  • Nacos 控制台:治理控制台,能够进行配置查看,配置公布,监听查问等运维性能。商业化 Nacos 反对推送轨迹,监控,事件核心等高级性能。
  • 数据库:配置长久化存储的数据库,个别是主备库架构进行容灾。

用户在接入 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/q…
  • Spring Boot: https://nacos.io/zh-cn/docs/q…
  • Spring Cloud:
    https://nacos.io/zh-cn/docs/q…

4. 日志自助排查

以上介绍两种比拟典型的 nacos 配置核心的接入形式,在日常应用过程中,nacos-client 本地的日志是十分有助于进步问题排查效率。

nacos 在公布配置,监听配置及变更推送时都会在 {user.home}/logs/nacos/config.log 中打印具体的事件日志。以下是客户端运行期打印的几个要害日志:

    • add-listener:   增加监听,只有增加了对配置的监听,能力收到配置变更推送
    • server-push:客户端曾经收到某个配置的变更告诉
    • data-received:收到变更告诉后,客户端向服务端查问到了最新的配置内容
    • notify-listener: nacos 回调了的监听器 Listener,能够看到回调的配置内容 MD5。
    • notify-ok:  回调执行失常,能够查看执行回调的具体监听器 Listener,执行耗时。
    • notify-error: 监听器执行失败,对业务来说可能业务不合乎预期,须要依据异样排查起因。

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

5. 应用须知

  • 小配置

配置核心的次要作用是公布 meta-data,而不是数据的存储服务。咱们对所公布的单个配置数据内容大小 100k 以内。

  • 低频变更

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

  • 低频查问

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

  • 最终一致性

nacos 只保障最初一次推送的值肯定会达到,不保障两头的每一次变更都会送达订阅端。配置在公布胜利后并不是实时推送到客户端,两头有肯定的时延。

  • 幂等性

nacos 可能在网络情况欠佳时会向订阅者发送反复的数据告诉,订阅者对数据告诉的解决应满足幂等性,反对反复推送,雷同配置回调屡次不应产生异样预期外的状况。

  • 轻回调

在回调监听器中,解决逻辑应尽量轻量化,高耗时操作容易梗塞回调线程,影响其余配置的推送。对于重回调的场景,能够自定义业务线程池异步化解决。

错用场景:

  • 配置超过 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/docum…
  • ACM 迁徙 MSE Nacos 详见:
  • https://help.aliyun.com/docum…
  • Applo 等迁徙 MSE Nacos 详见:
  • https://help.aliyun.com/docum…

Nacos 3.0

Nacos3.0 中,在 SDK 能力晋升,界面交互降级,服务端外围能力,可观测可运维,稳定性 & 高可用方面都布局了诸多性能,除了根底通用的产品能力外,其中配置核心布局了社区呼声较高的含糊订阅性能,也将基于长连贯的一致性协定进行降级,晋升以后版本在边界异样场景下的稳定性及可靠性,欢送对 Nacos 感兴趣的社区开发者参加其中。

点击此处查看微服务引擎产品

正文完
 0