目前开发微服务用 nacos 做注册、配置中心的同学多吗？ 如果有一个用系统级语言重写，性能更高、占用资源更小的版本有同学愿意试用吗？

[heqingpan]

我之前用 rust 重写了 nacos ，开源一段时间，收到的反馈不多。

想确认是用 nacos 的人不多，还是不知道或者知道但没有试用动力的人比较多。

---

下面附上我重写 nacos 版本简介：

https://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 给个星 。

[imokkkk]

挺好的 加油

[infun]

如果名字叫 racos 就更好了

[gclm]

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

[zzl22100048]

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

[Kilerd]

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

[thetbw]

个人会用

[burymme11]

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

[zzl22100048]

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

[yrzs]

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

[javak]

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

[pannanxu]

系统级语言重写，性能更高、占用资源更小❌

大厂背书、活跃的社区、频繁的更新、强大的生态✔

仅仅针对这几点来说，个人认为，作者提出的几个问题并不是什么痛点。但还是支持一下。

[coyove]

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

[fanchenio]

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

[pannanxu]

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

[heqingpan]

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

[heqingpan]

@gclm 好建议，我晚点建一个。

[wqhui]

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

[heqingpan]

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

[heqingpan]

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

[Kilerd]

@pannanxu 终于有人说重点了。

对于「注册中心」这种不会随着业务膨胀而导致资源增长的服务。 足够强的技术支持，社区反馈与改进，强大的生态才是核心痛点。
例如少人用导致 CVE 没有及时上报，CVE 上报了因为生态差没有及时发版修复

因为不会出现资源膨胀，在生产环境里面把单个的 1G 降低到 5M 带来的价值其实不大

[winglight2016]

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

[heqingpan]

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

[ZeroDu]

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

[heqingpan]

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

[ZeroDu]

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

[heqingpan]

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

[pannanxu]

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

[kerb15]

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

[litchinn]

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

[xingjue]

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

[heqingpan]

@kerb15 25M 内存

[heqingpan]

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

[shalk]

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

[zzl22100048]

@heqingpan #19
>> 所有的集群节点都需要设置 RNACOS_RAFT_NODE_ID,RNACOS_RAFT_NODE_ADDR ,其中不同节点的 node_id 和 node_addr 不能相同； node_id 为一个正整数，node_addr 为 ip:grpc_port

文档里面说 node_id 要正整数，其实可以为 0 ，对吗

[heqingpan]

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

[heqingpan]

@zzl22100048 0 其实也是可以的

[heqingpan]

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

[allenzhangSB]

@heqingpan #22 稳定性和用什么语言无关

[xzm429438709]

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

[xzm429438709]

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

[panzhc]

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

[pentilun]

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

[simpleisbest]

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

[xingjue]

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

[heqingpan]

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

[cyndihuifei]

什么叫云原生应用？

[winglight2016]

@ZeroDu #23 后台面板没什么用，而且配置修改自己开发可以实现更好的效果。注册中心对于 k8s 的意义是 0 ，跟阿里云也没什么关系呀。


@heqingpan 我们自己用 go 开发了一个配置中心，基于 etcd 存储，也完全够用了

[Nazz]

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

[wzcloud]

中间件, 要达到 Productoin Ready 的程度, 还有不少路要走...

总而言之, UP 加油

[Lambdua]

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

[heqingpan]

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

[ZeroDu]

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

[heqingpan]

开始阶段还是建个群比较方便，如果后面低级问题比较多，再约定回复提问的要求。

我建个群，用于及时沟通使用中遇到的问题。

v2ex 手机不方便放图。
想进群的可以先加我微信，再进群。
微信号：`qingpan2014`，记得备注 rnacos 。

[heqingpan]

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

[twinsdestiny]

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

[kphcdr]

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

[salmon5]

https://github.com/microsoft/windows-drivers-rs

[salmon5]

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

[salmon5]

nacos 1.x 真的太耗资源了

[heqingpan]

@twinsdestiny 能的，这是基本功能。

[heqingpan]

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

[wqhui]

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

[heqingpan]

@wqhui
理解，一些功能性的 bug 确实只有大量使用才能发现。
而对于非功能问题，rust 编译通过后基本不会有问题。这个就是大家说 rust 安全稳定的原因。

bug 数量不多的话，我还是能比较及时修复的。

[ice]

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

[silentsky]

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

[heqingpan]

@silentsky
这个只需要换 nacos 服务。

验证通过后，kill 老服务，启动新服务。一分钟内完成切换。

[winglight2016]

@ZeroDu #52 我们不是啥大公司，k8s 都是我自己研究引入的，因为我们是 python 后台，没考虑过 spring cloud 。

我们的网关用的是 apisix ，怎么想都比 springgateway 效率高吧？

个人认为在 k8s 环境完全没有 spring cloud 的存在价值，k8s 环境还要什么服务注册、发现，也没有负载均衡、断路器这种需求。

我们也在考虑换到 java 后台，不过 springboot 已经足够了。我在看 spring security 和 config server ，其他组件都没有什么帮助。

[Naccl]

我真会试一下，nacos 太吃资源了，感觉很有应用场景，回头就把个人项目迁过来

[heqingpan]

欢迎试用，过程如果有遇到问题可以给我提 issues 。

[xiaomada]

您说的是 [etcd]( https://etcd.io/) 吗

[heqingpan]

@xiaomada

我说的是 nacos 。想确认用的人多不多，其中有多少人愿意试用，其选择背后的考量。

目前大体的信息已收集到，前期个人、小公司等对机器资源敏感的同学相对愿意试用。 （有人用，有价值，可以继续做）
规模大一些的，可能需要能证明其真的比较稳定可靠后才会考虑。（潜在的用户）

etcd 是一个键值数据库，从功能上它和 nacos 配置中心比较接近。
它也可以当注册中心来用，不过从原理上性能、可用性会比 nacos 的中心低一些（所以在 nacos 中注册、配置中心是两个不实现的模块）。

只是功能上相同，切换还是需要比较大的改造成本。
rnacos 是在功能和接口协议都做了兼容，切换过程应用是不需要做改造的。

这两个还是有区别的。