收到反馈是： 个人、小公司等对机器资源敏感的同学相对愿意试用（有人用，有价值，可以继续做）；规模大一些的，可能需要能证明其真的比较稳定可靠后才会考虑（潜在的用户）。
经过一段时间的持续迭代，在项目加入 nacos 官方社区之际，再来 v 站推广并调研下：使用配置中心或注册中心的同学你们会愿意试用用 rust 重写的 r-nacos 吗？
下面是 r-nacos 的说明：
简介
r-nacos 是一个用 rust 实现的 nacos 服务。相较于 java nacos 来说，是一个提供相同功能，启动更快、占用系统资源更小、性能更高、运行更稳定的服务。
其设计上完全兼容最新版本 nacos 面向 client sdk 的协议支持使用 nacos 服务的应用不用修改代码直接平迁到 r-nacos 。
资源使用情况
演示系统中接入接近 5 千个配置，450 个服务实例，服务使用的内存在 15M 左右。
使用反馈与说明
性能说明
[td]模块[/td]
[td]场景[/td]
[td]单节点 qps/tps[/td]
[td]集群 qps/tps[/td]
[td]总结/备注[/td]
配置中心
配置写入,集群模式
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 是节点的倍数
项目地址
https://github.com/nacos-group/r-nacos
