What features do you expect from Nacos 3.0?

[yanlinly]

What features do you expect from Nacos 3.0?

Read write separation？
Flow control?
Support DNS Server /XDS Server？
Gateway integration（Tengine / Nginx）？
Multi language（Rust / Dapr）？
Tools（Benchmarks / CLI ）？
Improve consistency agreement？
Rich Metrics？
arm cpu？
ipv6？
dragonwell + jdk 11？
oceanbase / PG ？
Document？
UT/IT？

[myifeng]

Please update the documentation!

[MajorHe1]

1、鉴权支持到Group级别的插件实现
2、分布式锁插件实现
想起来更多的再补充。。。。。。。

[realJackSun]

Read/Write Splitting

[CherishCai]

Multi language（Rust / Dapr）➕ 1⃣️

---

Rust 版客户端，申请参与，个人空余时间在写 Nacos2.x 的 grpc 交互客户端，期望后续基本完备后可以并入 nacos-group

[realJackSun]

支持从K8S的ConfigMap中，实时地拉取数据，并同步数据到Nacos配置中心
该Feature欢迎这里讨论：#9134

[li-xiao-shuang]

Multi language（Rust / Dapr）➕ 1⃣️

Rust 版客户端，申请参与，个人空余时间在写 Nacos2.x 的 grpc 交互客户端，期望后续基本完备后可以并入 nacos-group

看起来不错哦

[five111]

支持按组监听配置
解决的问题主要是：
客户端想监听某个一组下面的配置 比如 data_id为 nacos.common开头 group为 product开头的所有配置
当满足这个条件的配置发生了 新增 修改 删除 可以通知到客户端
（社区看看是否感兴趣 我们已经做了一套实现）

[YunaiV]

Please update the documentation!

Couldn't agree more, the NACOS documentation is poor

[onewe]

个人空余时间在写 Nacos2.x 的 grpc 交互客户端

大佬带带我

[CherishCai]

大佬带带我
@onewe 大佬请一起来参与玩玩，Rust 太难上手了，几个月了现在终于有点儿上道。

[onewe]

@CherishCai 😂, 我花了一个月时间, rust 入了个旋转门.

[realJackSun]

支持按组监听配置 解决的问题主要是： 客户端想监听某个一组下面的配置 比如 data_id为 nacos.common开头 group为 product开头的所有配置 当满足这个条件的配置发生了 新增 修改 删除 可以通知到客户端 （社区看看是否感兴趣 我们已经做了一套实现）

建议很不错，这个社区有很多朋友也有类似需求

[zz630]

Support DNS Server

[five111]

支持按组监听配置 解决的问题主要是： 客户端想监听某个一组下面的配置 比如 data_id为 nacos.common开头 group为 product开头的所有配置 当满足这个条件的配置发生了 新增 修改 删除 可以通知到客户端 （社区看看是否感兴趣 我们已经做了一套实现）

建议很不错，这个社区有很多朋友也有类似需求，可以考虑开一个ISSUE来搞哦

#9146
先建个issue 稍后几天 我将目前实现的思路和细节贴上来 然后讨论下适合社区发展的思路

[KomachiSion]

支持按组监听配置 解决的问题主要是： 客户端想监听某个一组下面的配置 比如 data_id为 nacos.common开头 group为 product开头的所有配置 当满足这个条件的配置发生了 新增 修改 删除 可以通知到客户端 （社区看看是否感兴趣 我们已经做了一套实现）

建议很不错，这个社区有很多朋友也有类似需求，可以考虑开一个ISSUE来搞哦

#9146 先建个issue 稍后几天 我将目前实现的思路和细节贴上来 然后讨论下适合社区发展的思路

目前先进行需求收集，还没有决定是否落地实现，等到时候再提新issue提方案吧。

[five111]

支持按组监听配置 解决的问题主要是： 客户端想监听某个一组下面的配置 比如 data_id为 nacos.common开头 group为 product开头的所有配置 当满足这个条件的配置发生了 新增 修改 删除 可以通知到客户端 （社区看看是否感兴趣 我们已经做了一套实现）

建议很不错，这个社区有很多朋友也有类似需求，可以考虑开一个ISSUE来搞哦

#9146 先建个issue 稍后几天 我将目前实现的思路和细节贴上来 然后讨论下适合社区发展的思路

目前先进行需求收集，还没有决定是否落地实现，等到时候再提新issue提方案吧。

ok 如果最终有这方面诉求 可以@我

[caqhy]

Hello, I'm a user of nacos. Currently, ShardingSphere mainly uses Zookeeper and Etcd as the configuration center. ShardingSphere also expects to complete the integration of Nacos and use its configuration center to complete the subscription and publication of configured CURDs and events to complete the sharing and synchronization of status and rules in cluster mode.

But I'm currently stuck with the following features that haven't been supported yet

1. Support getting configuration according to the dataId prefix range, and return dataId, group, content.
2. Support publish ephemeral configuration which is deleted when the session is disconnected.
3. Support range watch, the callback parameter contains the configuration that matches the dataId prefix.
4. Support the listener callback parameter contains more information, such as the value before the configuration change, the value after the configuration change, and the configuration change type.
5. Support deleting configurations according to the dataId prefix range.
6. Support distributed locks. The data of the nacos is persistent in the database. It should be possible to implement distributed locks based on the database.

I expect nacos have these features.

Thanks.

[caqhy]

Hello, I'm a user of nacos. Currently, ShardingSphere mainly uses Zookeeper and Etcd as the configuration center. ShardingSphere also expects to complete the integration of Nacos and use its configuration center to complete the subscription and publication of configured CURDs and events to complete the sharing and synchronization of status and rules in cluster mode.

But I'm currently stuck with the following features that haven't been supported yet

1. Support getting configuration according to the dataId prefix range, and return dataId, group, content.
2. Support publish ephemeral configuration which is deleted when the session is disconnected.
3. Support range watch, the callback parameter contains the configuration that matches the dataId prefix.
4. Support the listener callback parameter contains more information, such as the value before the configuration change, the value after the configuration change, and the configuration change type.
5. Support deleting configurations according to the dataId prefix range.
6. Support distributed locks. The data of the nacos is persistent in the database. It should be possible to implement distributed locks based on the database.

I expect nacos have these features.

Thanks.

#9262

[hujun-w-2]

很多用户升级时都会担心新版本不稳定，再加上Nacos更新迭代很快，期望提升UT/IT/ST能力

[john1337]

nacos客户端失败重连机制，现在nacos客户端连接失败后不会进行重试，在k8s部署时存在服务比nacos-server先启动的情况，这是肯定连接不上nacos-server，现在是连接抛出异常后就不会进行连接了，这样导致的问题很严重，觉得nacos客户端有必要加上失败重试的机制

[mxsm]

Increase observability

[IJiaPu]

加我一个
期望增加Arm支持！

[githubcheng2978]

配置抽取成配置类，like ConfigurationProperties.

[liuxinwen]

In my opinion, the gateway integration is very important.

[Liang-Dongxing]

配置乱七八糟的，一会取vm配置，一会spring配置文件里的配置

[guochen2]

Support DNS Server

[fyuan1316]

rich metrics

• Add more indicators/metrics, such as service registration failure

[DorChen]

Support edge scenario, application runs on edge node with unstable network.

[lazeyliu]

发布时候 配置格式校验提示
diff 对比更精准一些

[moonciki]

配置文件可以通过git管理，该问题已经在多个issues 中提及：
#5797
#3476
#5116
#9129 (comment)
并且目前已经实现了相应接口及逻辑的开发，只差界面的修改了，由于vue 并不是特别熟悉，加上pr 合并难度，此问题搁置了一段时间，如果有需要，可以随时进行相关交流。
实现的方式如下：https://www.cnblogs.com/moonciki/articles/16566937.html

[985492783]

配置文件可以通过git管理，该问题已经在多个issues 中提及： #5797 #3476 #5116 #9129 (comment) 并且目前已经实现了相应接口及逻辑的开发，只差界面的修改了，由于vue 并不是特别熟悉，加上pr 合并难度，此问题搁置了一段时间，如果有需要，可以随时进行相关交流。 实现的方式如下：https://www.cnblogs.com/moonciki/articles/16566937.html

我认为不应该是提供额外的接口来支持git
而是要先将存储层抽象出来

config-->DatabaseStorage-->mysql | pq | dm | derby
--------->GitStorage---> github | gitee
--------->xxStorage

[moonciki]

这两个问题不冲突，存储层是存储层，以nacos 目前的架构来说，数据库层是用来保存系统运行所有数据集的最终持久层，抽离也好，不抽离也好，其实对新增git 支持影响不大。

而git 只是用来管理配置文件，最终他也会将配置文件通过类似 jekins 拉取的方式，导入至数据库内。

由于现在的界面式配置文件操作起来很不方便，而且各个版本的配置文件也不易于管理，再加上现有的变更记录功能也比较简单，而 git 天生具备这些特性，添加git支持只是在原有导入功能的基础上做了丰富。

有了git，我可以提前准备好相关的配置，上线时，直接推送对应分支，然后在系统内手动点击同步即可，他其实类似导入的功能，只不过是把原来的文件导入，改成了从 git 拉取导入。并且可以在 git 看到每次的变更记录，而且也可以精确到某项配置是谁添加的，这么多优点何乐而不为呢？

说到数据库层，我倒觉得多数据库类型的支持挺鸡肋的，毕竟安装一个mysql 并不是多复杂的事，而且数据库可以通过网络方式访问。至于其他需要支持的pg（nacos 对数据库性能要求不高，其实与mysql 没多大区别） 也好，dm (政治产物)也好，derby （必要性更低）也好，意义真的并不大，反倒是现有代码为了适配多数据库（如derby） 的支持，搞得代码规范一团糟。

没有其他优点的软件才要求把大而全当做优点，才要求支持多数据库，大而全不一定好，小而精才是美。毕竟 nacos 优点并不在于多数据库支持。

配置文件可以通过git管理，该问题已经在多个issues 中提及： #5797 #3476 #5116 #9129 (comment) 并且目前已经实现了相应接口及逻辑的开发，只差界面的修改了，由于vue 并不是特别熟悉，加上pr 合并难度，此问题搁置了一段时间，如果有需要，可以随时进行相关交流。 实现的方式如下：https://www.cnblogs.com/moonciki/articles/16566937.html

我认为不应该是提供额外的接口来支持git 而是要先将存储层抽象出来

config-->DatabaseStorage-->mysql | pq | dm | derby
--------->GitStorage---> github | gitee
--------->xxStorage

[wuqtao]

1、建议将内置数据库集群模式做稳定，一般中间件产品都不依赖第三方组件的，比如redis、mysql、es等，很多公司有paas平台，便于直接申请nacos实例
2、建议支持独立启动naming模块，且默认只使用distro协议

[felix021]

给配置增加版本号，在 UI 和 API 中都体现出来，避免出现并发 read-modify-save 导致配置被覆盖。

[Chionanthus]

支持按组监听配置 解决的问题主要是： 客户端想监听某个一组下面的配置 比如 data_id为 nacos.common开头 group为 product开头的所有配置 当满足这个条件的配置发生了 新增 修改 删除 可以通知到客户端 （社区看看是否感兴趣 我们已经做了一套实现）

建议很不错，这个社区有很多朋友也有类似需求，可以考虑开一个ISSUE来搞哦

#9146 先建个issue 稍后几天 我将目前实现的思路和细节贴上来 然后讨论下适合社区发展的思路

@five111 你好，Nacos将会在未来支持这个功能，方便讨论一下你的实现思路和细节吗

[five111]

支持按组监听配置 解决的问题主要是： 客户端想监听某个一组下面的配置 比如 data_id为 nacos.common开头 group为 product开头的所有配置 当满足这个条件的配置发生了 新增 修改 删除 可以通知到客户端 （社区看看是否感兴趣 我们已经做了一套实现）

建议很不错，这个社区有很多朋友也有类似需求，可以考虑开一个ISSUE来搞哦

#9146 先建个issue 稍后几天 我将目前实现的思路和细节贴上来 然后讨论下适合社区发展的思路

@five111 你好，Nacos将会在未来支持这个功能，方便讨论一下你的实现思路和细节吗

欢迎 简单说下大体的思路 如果对细节感兴趣 稍后我们专门开个贴讨论

目标

让nacos支持按组监听 类似于etcd或者zk那种前缀监听
比如我们定义一组配置 这些配置是系统设置 data_id 以system.config 开头 ex：system.config.language ，system.config.timezone ；group_id 以某个分组 如 system.service ，现在我们有个服务需要监听所有system.config开头 group_id为system.service的配置 当然希望一个接口能监听所有 包括后续新增的

客户端实现大体思路

定义一个如下接口
@param localConfigs 本地已有配置
@param prefixCondition 前缀相关信息
@param prefixedConfigsListener 监听配置处理器
void addPrefixListener(List<ConfigDto> localConfigs, PrefixConditionDto prefixCondition, PrefixedConfigsListener prefixedConfigsListener)
本地配置是指的本地已知的配置 这些配置将用来和服务端的配置进行比较
前缀相关信息 指的是本次监听的前缀信息 如上文所指的类似于下面
{ "prefixConditionKey": "system.config", "prefixConditionGroup": "system.service" "tenant": "" }
监听配置处理器 为监听回调接口 设计了如下几个方法
`
void onAdd(ConfigDto configInfo);

void onDelete(ConfigDto configInfo);

void onUpdate(ConfigDto configInfo);`

localConfigs中没有而服务端有的配置会触发onAdd回调函数，localconfigs中的配置content与服务端content不一致的会触发onUpdate回调函数，localconfigs中有而服务端没有的配置会触发onDelete回调函数

服务端实现大体思路

与普通监听类似 维护以下几个关系

• 将grpc连接的connection_id 与其监听的前缀
• 某个前缀与其前缀下所有配置的关系
  通过nacos的事件机制 来进行更新

[yanlongma]

recommended that officials adapt SpringBoot 3 in a timely manner

[Rance29]

What features do you expect from Nacos 3.0?

Read write separation？ Flow control? Support DNS Server /XDS Server？ Gateway integration（Tengine / Nginx）？ Multi language（Rust / Dapr）？ Tools（Benchmarks / CLI ）？ Improve consistency agreement？ Rich Metrics？ arm cpu？ ipv6？ dragonwell + jdk 11？ oceanbase / PG ？ Document？ UT/IT？

[IJiaPu]

What features do you expect from Nacos 3.0?
Read write separation？ Flow control? Support DNS Server /XDS Server？ Gateway integration（Tengine / Nginx）？ Multi language（Rust / Dapr）？ Tools（Benchmarks / CLI ）？ Improve consistency agreement？ Rich Metrics？ arm cpu？ ipv6？ dragonwell + jdk 11？ oceanbase / PG ？ Document？ UT/IT？

我也在想数据库的问题，按照现在的路线，再支持其他数据库，会越来越累赘，维护成本也会越来越高。不支持又会不会跟不上技术潮流

[Cloud-Yao]

个人觉得Nacos作为一个配置中心，存储配置的地方，应该自身具备高可用的数据存储能力，而不是依赖其他的外部持久化组件，这样也能减少一定的维护成本。

[tinnkm]

建议openapi添加获取namespace下所有服务的接口，和获取namespace下所有配置一样，目前获取服务列表必须要穿group，但是openapi中没有提供获取group列表的接口，所有导致必须要明确知道group的情况下，才能获取到所有的服务。

[shalk]

• support JDK 17 or JDK 21
• remove spring (this is big dependency, which make nacos like a spring application)

[ly641921791]

Table name prefix

[KunxiSun]

希望API文档写好点
搜个OpenAPI文档，搜出来两份

1. https://nacos.io/docs/v2/guide/user/open-api/#2.3
2. https://nacos.io/zh-cn/docs/open-api.html

希望可以做好文档的版本管理
v2版本上的nacos很多v1版本的接口也能用

v2版本的OpenAPI接口没有心跳接口，但是可以用v1版本的心跳接口...
诸如此类..

[ROMYIM]

支持某个组下的新服务首次上线通知。
即某一个组下，新（新的ServiceName）服务实例首次连上nacos服务，对其他在同一个组下的客户端发出广播通知。
现在只能用定时任务不断读取nacos服务列表，然后和本地的缓存作比较，再去刷新本地的服务列表。

[herodotus-ecosystem]

不知道是否考虑 Sentinel Dashboard 或者 Sentinel 与 Nacos 整合为一个产品。就像隔壁 PolarisMesh 一样。至少融合一下 Sentinel 规则持久化 Nacos 的问题

[JavaLionLi]

boot3 + 虚拟线程

[vnobo]

多数据库支持，

[codeLikeO]

多数据库支持