关于 r-nacos,去年有在本站调研过使用的意愿。
收到反馈是： 个人、小公司等对机器资源敏感的同学相对愿意试用（有人用，有价值，可以继续做）；规模大一些的，可能需要能证明其真的比较稳定可靠后才会考虑（潜在的用户）。
经过一段时间的持续迭代，在项目加入 nacos 官方社区之际，再来 v 站推广并调研下：使用配置中心或注册中心的同学你们会愿意试用用 rust 重写的 r-nacos 吗？

下面是 r-nacos 的说明：
简介
r-nacos 是一个用 rust 实现的 nacos 服务。相较于 java nacos 来说，是一个提供相同功能，启动更快、占用系统资源更小、性能更高、运行更稳定的服务。
其设计上完全兼容最新版本 nacos 面向 client sdk 的协议支持使用 nacos 服务的应用不用修改代码直接平迁到 r-nacos 。
资源使用情况
演示系统中接入接近 5 千个配置，450 个服务实例，服务使用的内存在 15M 左右。
使用反馈与说明

目前已经有部分用户使用于生产环境；比较多有用户使用于测试环境，想要观察一段时间后，如果稳定没有问题再考虑上生产；
用户反馈联系运行几个月都很稳定；
收到的缺陷比较少，有几个是非主链接上的功能问题（因为是用 rust 写的，基本没有遇到非功能性问题）。具体的可以看 github 上的 issues

性能说明

模块
场景
单节点 qps/tps
集群 qps/tps
总结/备注

配置中心
配置写入,集群模式
1.76 万
7.6 千
集群写入压测是在同一台电脑运行 3 个节点,如果换成多个机器部署,tps 应该还能有所提升。

配置中心
配置查询
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.com/nacos-group/r-nacos

正在用

欢迎使用，有什么问题或建议可以到 github 提 issue 。

在用在用，跟动不动占用 1G 多内存的 nacos 相比，r-nacos 几十 M 真的非常推荐。

有个问题，admin 管理界面的验证码能不能设置成可关闭，每次登录都要输入太麻烦了

👍不错

这个目前也是支持的，有个配置 RNACOS_ENABLE_NO_AUTH_CONSOLE 可以开启无校验控制台。具体的你也可以看对应的文档说明。

请问启动更快和占用更小都有数据体现，readme 里的「运行更稳定」是通过什么指标得出的结论？

开发环境准备试试

已经用到开发环境 3 ～ 4 个月了，体验不错

启动更快是指启动后，在一秒内可以正常访问接口，nacos 的话自测差不多在 8 秒左右才能正常访问。（这个是人个使用记录，没有用工具做严格对比）资源占用更小，上面已经给出例子：接入接近 5 千个配置，450 个服务实例，服务使用的内存在 15M 左右。nacos 默认启动后内存就大于 600M 。运行更稳定，在连续长时间运行（超过一个月）和经过压测场景下，r-nacos 的（内存与 cpu ）资源占用都很稳定。nacos 的内存起伏比较大，压测时有时还遇到未及时响应的情况。

＃10 谢谢回答，准备调研一下。

大佬，为啥两类 docker 包会影响运行性能？

天下苦 spring-boot 久已😭

因为 gnu 与 musl 两类包底层的 c 标准库实现不同，一些场景 gnu 比 musl 性能高一些。不过也差不太多，如果对性能不是非常敏感，用哪个都可以。

感谢反馈

spring-boot 写应用除了内存占用比较大，其它的都挺好的。不过中间件的话，人个觉得还是用 rust 更好😀

mark 一下, 很适合当自己的配置中心.

我也在学 rust 。但是作为一个 Java web 开发，发现用 rust 开发一个 web 应用，生态好像还是不行。rust 不适合用来开发这些业务多的 web 项目，例如 BPM 流程引擎、对 office 文件的一些操作库可能是我接触的少，不知道 rust 有哪些好用的库

看了一下介绍以及评论感觉还可以 。开发测试环境可以用来试试。没有 nacos 那些一堆莫名其妙的破问题就好。特别是迭代问题 nacos 真的让人糟心。

alibaba/nacos ?

天下苦 java 久矣

我对 rust 库的了解也不算很多，一般都是以目标场景为导向去找对应的库。有些能找到合适的；有些找到但不完全够用，这时要自己补充；有些就是没有自己直接写一个。目前生态很多库基本都有了 关于 web 开发，我主要以前后端方式写。这种模式，只要使用 http 接口即可。有很多成熟的框架，比如 axum,actix-web 等。你提的流程引擎和 office 操作库，我之前没有用到，没去了解。你可以自己到 crates 去找找。

是的。r-nacos 是用 rust 重写 alilaba/nacos ，协议完全兼容，支持使用 nacos 的应用不改代码直接平迁到 r-nacos 。

欢迎试用，目前从收到的反馈来看，已经比较稳定。主链路基本不会有什么问题。

太好了，真不喜欢 java 那套东西

个人使用受资源限制，占用太大的 nacos 是有点吃不消，r-nacos 能够将占用限制到 10 多 M ，那还是可以先用来做开发试用，看看具体的稳定性，以及会不会出现什么意料之外的 bug ，真的没啥重大问题，稳定后还是可以考虑上生产环境的。

感谢反馈。我个人也是建议先在测试环境使用，经过充分验证其稳定性后，再考虑上生产。欢迎试用，使用过程有问题或建议都可以提 issue 。

这个可以有，生产部署 3 个 java 的 nacos 内存直接 5-6 个 G 了

这资源占用爱了

mark,这类中间件使用 rust 重写真是太棒了

支持一下，看这个占用是很棒的啊。可惜公司的技术栈不是走这个的，不然可以推荐一下给老大了。

早就该用 rust 重写各大中间件了这里点名 kafka ，hdfs ，hbase ，es 。

资源占用低是 r-nacos 最大的优点之一😁

感谢支持与反馈

对比下来，用 rust 重写原 java 写的中间件，确实收益不错😁

正在用，作为个人和小型公司的方案非常合适，给开发者点赞顺便 rust yyds

哇哦. nice !!!

我看了一下项目介绍以及诸位的评论，感觉很不错的样子 。准备在测试环境试试。

感觉 rust 才是真正的 better c .支持大佬使用 rust 重构中间件，确实能起到节省内存效果。

内存占用这么小？果断试一下，开发用的老机子，每一兆内存都是宝贵的，再次声讨一下，垃圾公司

可以，我去给你点个🌟

感谢支持与反馈😁

欢迎试用，过程遇到问题可以反馈或提 issue