我之前用 rust 重写了 nacos ，开源一段时间，收到的反馈不多。
想确认是用 nacos 的人不多，还是不知道或者知道但没有试用动力的人比较多。

下面附上我重写 nacos 版本简介：
github.com/heqingpan/rnacos
rnacos 是一个用 rust 实现的 nacos 服务。
rnacos 包含注册中心、配置中心、web 管理控制台功能，支持单机、集群部署。
rnacos 设计上完全兼容最新版本 nacos 面向 client sdk 的协议（包含 1.x 的 http OpenApi ，和 2.x 的 grpc 协议）, 支持使用 nacos 服务的应用平迁到 rnacos 。
rnacos 相较于 java nacos 来说，是一个提供相同功能，启动更快、占用系统资源更小、性能更高、运行更稳定的服务。
性能：

模块
场景
单节点 qps
集群 qps
总结

配置中心
配置写入,单机模式
1.5 万
1.5 万

配置中心
配置写入,集群模式
1.8 千
1.5 千
接入 raft 后没有充分优化,待优化,理论上可接近单机模式

配置中心
配置查询
8 万
n*8 万
集群的查询总 qps 是节点的倍数

注册中心
服务实例注册,http 协议
1.2 万
1.0 万
注册中心单机模式与集群模式写入的性能一致

注册中心
服务实例注册,grpc 协议
1.2 万
1.2 万
grpc 协议压测工具没有支持，目前没有实际压测，理论不会比 http 协议低

注册中心
服务实例心跳,http 协议
1.2 万
1.0 万
心跳是按实例计算和服务实例注册一致共享 qps

注册中心
服务实例心跳,grpc 协议
8 万以上
n*8 万
心跳是按请求链接计算,且不过注册中心处理线程,每个节点只需管理当前节点的心跳，集群总心跳 qps 是节点的倍数

注册中心
查询服务实例
3 万
n*3 万
集群的查询总 qps 是节点的倍数

收到用户反馈信息，会给我更多的动力。
如果试用过程中有问题可以到 github 给我提 issues 。
如果愿意试用或喜欢的同学就到 github rnacos 给个星 。

挺好的 加油

如果名字叫 racos 就更好了

🐂，💪🏻 刚本地测试了一下初步感觉效果不错，建议作者搞个微信群或者其他交流渠道，我把个人的小玩意迁移过来，到时候及时交流沟通沟通

原版 1.x 的集群脑裂问题解决了吗

简单看了下，手搓 raft ，感觉有点慌。

个人会用

收藏支持下。下次开新项目我试试。

看上去没脑裂问题，就是启动需要 node_id 对 k8s 部署太不友好了，而且 node_id 是从 1 开始，想从 podname 截取都不行

已 star,下次本地开发部署试试

我用的 eureka ，楼主有空了再写个这个

系统级语言重写，性能更高、占用资源更小❌大厂背书、活跃的社区、频繁的更新、强大的生态✔仅仅针对这几点来说，个人认为，作者提出的几个问题并不是什么痛点。但还是支持一下。

手搓基建轮子没人用不是很正常吗，你总得说服人家敢用啊

赞同二楼，名字修改一下。

或者改名叫 nacos4rust 把，你这个名字不仔细看总是看错

最开始也想用这个，结果在 crate 被点用了。

好建议，我晚点建一个。

最简单一个问题对于商业应用来说是资源占用少、性能高重要，还是稳定性重要，资源跟性能问题可以堆机器解决，万一这种基础组件不稳定，带来的损失就大多了，而个人应用又很少需要搞微服务的

是基与一个 rust raft 库实现的。

node_id 可以不是 1 ，可以不连续，但需要是不唯一的整数。

终于有人说重点了。对于「注册中心」这种不会随着业务膨胀而导致资源增长的服务。 足够强的技术支持，社区反馈与改进，强大的生态才是核心痛点。 例如少人用导致 CVE 没有及时上报，CVE 上报了因为生态差没有及时发版修复因为不会出现资源膨胀，在生产环境里面把单个的 1G 降低到 5M 带来的价值其实不大

有 k8s ，nacos 没什么用了。如果只是配置中心，和 spring 的 config server 比有什么优势吗？

rust 写的比 java 写稳定性上会更好。

＃21 spring 那个估计都没多少人用。nacos 有后台管理面板。配置修改等等都很舒服。而且注册中心+配置中心合一，无缝切换阿里云。

感谢反馈。社区、生态确定比较重要。这是一个循环依赖问题，生态好了用的人会多，用的人多了反过来生态也会变好。

你这个可以联系一下官方社区，看看能否给加个引流连接

功能上比 config server 强的多。rnacos 在占用资源、性能、稳定性上都比它好很多。

＃24 作者可以看看腾讯的 polaris mesh ，一站式解决方案。但是感觉没啥人用自己也不敢在生产尝试。

如果只用配置中心的话，单机版的资源占用是多少

对资源和性能有要求的应该会选择 consul ，你可以放一下你的项目和这两者的 benchmark 对比

为啥不用 go 写 go 明显云原生生态霸主

25M 内存

go 有 gc ，性能上比不过 rust 。rust 写云原生应用也很合适的。

• 用 rust 实现，反而维护难度更大。- 配置中心，性能不是问题- 没有背书很难有意愿，如果文档特别好，可能会好一些，nacos 的文档写的一般

  ＃19 >> 所有的集群节点都需要设置 RNACOS_RAFT_NODE_ID,RNACOS_RAFT_NODE_ADDR ,其中不同节点的 node_id 和 node_addr 不能相同； node_id 为一个正整数，node_addr 为 ip:grpc_port文档里面说 node_id 要正整数，其实可以为 0 ，对吗

  内存初始 25M 左右，具体和配置内容有关。cpu 默认小于 1% 压测 4 万 qps 时占用 30%左右，具体的和机器有关。

  0 其实也是可以的

  确定，熟悉 rust 的开发者相对较少；开发效率上其实还可以的。感谢反馈，文档会持续完善。

  ＃22 稳定性和用什么语言无关

安全和稳定方面 rust 可以的，但是关键维护很难，出稳定，不懂 rust 怎么办，官方没这么快解决的……

安全和稳定方面 rust 可以的，但是关键维护很难，出问题，不懂 rust 怎么办，官方没这么快解决的……

第一反应也是名字不突出，也许可以叫 nacos-rs 。如果生产用的话，主要考虑的是稳定性。更换或者升级要考虑兼容性，中小规模下性能不是瓶颈。

名字也可以改叫 macos=r+nacos

说得到位，补充点部署到企业生产环境的组件，一般会选择相对成熟稳定的产品，经历过市场考验的，个人尝试可以，如果企业选择，必然要承担未知的风险，一旦出现问题，造成损失也许不可估量

这都是胡扯 k8s 生态 cncf 那么多生态你咋不说 做个配置中心 还关注啥 gc 啊 要啥自行车 你又不是做高频交易 或者做 c++系统编程 对 gc 敏感

这么多人都觉得名字不好，我改，找到合适的就改😂

什么叫云原生应用？

＃23 后台面板没什么用，而且配置修改自己开发可以实现更好的效果。注册中心对于 k8s 的意义是 0 ，跟阿里云也没什么关系呀。 我们自己用 go 开发了一个配置中心，基于 etcd 存储，也完全够用了

这种项目很难推广啊, etcd/consul 已经流行了

中间件, 要达到 Productoin Ready 的程度, 还有不少路要走...总而言之, UP 加油

最好别建群，会消耗你大量的精力和时间解决很低等的问题

听起来你有过经历。刚想中午建个群就看到你的建议😂

＃47 可能你是大公司，不了解。在很多小公司，无需自己运维直接上阿里云买 nacos 服务，以及兼容 springgateway 的网关是常态。而且 nacos 对应的 springcloud 体系大多都是这些，用 k8s 的注册发现的我是没看到，部署倒是有使用。

开始阶段还是建个群比较方便，如果后面低级问题比较多，再约定回复提问的要求。我建个群，用于及时沟通使用中遇到的问题。v2ex 手机不方便放图。想进群的可以先加我微信，再进群。微信号：qingpan2014，记得备注 rnacos 。

晚上我也会把加群方式加到项目 readme 中。

配置中心该配置能实时生效吗

挺不错的，我的低配服务器 nacos 和 jenkins 都不敢装，因为 java 比较耗资源。这个东西我会尝试一下

github.com/microsoft/windows-drivers-rs

nacos 2.x 的 grpc 协议性能消耗上降低了很多，只有 1.x 的 几百分之一 吧

nacos 1.x 真的太耗资源了

能的，这是基本功能。

在注册中心中，两个协议性能差是挺大的。grpc 用链接本身做心跳，http 每个实列要单独请求做心跳。

我说的稳定性是指代码逻辑上的 bug ，这种东西很多时候只能靠大量的使用才能发现，还得有活跃社区及时修复，或者公司就有人能排查修复，但 rust 开发者不多见

理解，一些功能性的 bug 确实只有大量使用才能发现。而对于非功能问题，rust 编译通过后基本不会有问题。这个就是大家说 rust 安全稳定的原因。bug 数量不多的话，我还是能比较及时修复的。

rn 看着确实如 m,但是 macos 碰到 mac 了

这种一般很少去迁移 毕竟服务太多

这个只需要换 nacos 服务。验证通过后，kill 老服务，启动新服务。一分钟内完成切换。

＃52 我们不是啥大公司，k8s 都是我自己研究引入的，因为我们是 python 后台，没考虑过 spring cloud 。我们的网关用的是 apisix ，怎么想都比 springgateway 效率高吧？个人认为在 k8s 环境完全没有 spring cloud 的存在价值，k8s 环境还要什么服务注册、发现，也没有负载均衡、断路器这种需求。我们也在考虑换到 java 后台，不过 springboot 已经足够了。我在看 spring security 和 config server ，其他组件都没有什么帮助。