目前开发微服务用 nacos 做注册、配置中心的同学多吗？ 如果有一个用系统级语言重写，性能更高、占用资源更小的版本有同学愿意试用吗？
heqingpan 2023 年 9 月 28 日 7160 次点击这是一个创建于 860 天前的主题，其中的信息可能已经有所发展或是发生改变。
我之前用 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 给个星 。
 | 1 imokkkk 2023 年 9 月 28 日 挺好的 加油 |
 | 2 GlobalNPC 2023 年 9 月 28 日 如果名字叫 racos 就更好了 |
 | 3 gclm 2023 年 9 月 28 日 ， 刚本地测试了一下初步感觉效果不错，建议作者搞个微信群或者其他交流渠道，我把个人的小玩意迁移过来，到时候及时交流沟通沟通 |
 | 4 zzl22100048 2023 年 9 月 28 日 原版 1.x 的集群脑裂问题解决了吗 |
 | 5 Kilerd 2023 年 9 月 28 日  1 简单看了下，手搓 raft ，感觉有点慌。 |
 | 6 thetbw /div> 2023 年 9 月 28 日 个人会用 |
 | 7 burymme11 2023 年 9 月 28 日 收藏支持下。下次开新项目我试试。 |
| 8 zzl22100048 2023 年 9 月 28 日 看上去没脑裂问题，就是启动需要 node_id 对 k8s 部署太不友好了，而且 node_id 是从 1 开始，想从 podname 截取都不行 |
 | 9 yrzs 2023 年 9 月 28 日 已 star,下次本地开发部署试试 |
 | 10 javak 2023 年 9 月 28 日 我用的 eureka ，楼主有空了再写个这个 |
 | 11 pannanxu 2023 年 9 月 28 日 5 系统级语言重写，性能更高、占用资源更小 大厂背书、活跃的社区、频繁的更新、强大的生态 仅仅针对这几点来说，个人认为，作者提出的几个问题并不是什么痛点。但还是支持一下。 |
 | 12 coyove 2023 年 9 月 28 日 手搓基建轮子没人用不是很正常吗，你总得说服人家敢用啊 |
 | 13 fanchenio 2023 年 9 月 28 日 赞同二楼，名字修改一下。 |
 | 17 wqhui 2023 年 9 月 28 日 最简单一个问题对于商业应用来说是资源占用少、性能高重要，还是稳定性重要，资源跟性能问题可以堆机器解决，万一这种基础组件不稳定，带来的损失就大多了，而个人应用又很少需要搞微服务的 |
 | 19 heqingpan OP @zzl22100048 node_id 可以不是 1 ，可以不连续，但需要是不唯一的整数。 |
| 20 Kilerd 2023 年 9 月 28 日 5 @pannanxu 终于有人说重点了。 对于「注册中心」这种不会随着业务膨胀而导致资源增长的服务。 足够强的技术支持，社区反馈与改进，强大的生态才是核心痛点。 例如少人用导致 CVE 没有及时上报，CVE 上报了因为生态差没有及时发版修复 因为不会出现资源膨胀，在生产环境里面把单个的 1G 降低到 5M 带来的价值其实不大 |
 | 21 winglight2016 2023 年 9 月 28 日 有 k8s ，nacos 没什么用了。如果只是配置中心，和 spring 的 config server 比有什么优势吗？ |
 | 23 ZeroDu 2023 年 9 月 28 日 @winglight2016 #21 spring 那个估计都没多少人用。nacos 有后台管理面板。配置修改等等都很舒服。而且注册中心+配置中心合一，无缝切换阿里云。 |
| 24 heqingpan OP |
| 25 ZeroDu 2023 年 9 月 28 日 你这个可以联系一下官方社区，看看能否给加个引流连接 |
| 26 heqingpan OP |
 | 28 ex1gtnim7d 2023 年 9 月 28 日 如果只用配置中心的话，单机版的资源占用是多少 |
 | 29 litchinn 2023 年 9 月 28 日 对资源和性能有要求的应该会选择 consul ，你可以放一下你的项目和这两者的 benchmark 对比 |
 | 30 nxcdJaNnmyF9O90X 2023 年 9 月 28 日 为啥不用 go 写 go 明显云原生生态霸主 |
 | 33 shalk 2023 年 9 月 28 日 - 用 rust 实现，反而维护难度更大。 - 配置中心，性能不是问题 - 没有背书 很难有意愿，如果文档特别好，可能会好一些，nacos 的文档写的一般 |
| 34 zzl22100048 2023 年 9 月 28 日 @heqingpan #19 >> 所有的集群节点都需要设置 RNACOS_RAFT_NODE_ID,RNACOS_RAFT_NODE_ADDR ,其中不同节点的 node_id 和 node_addr 不能相同； node_id 为一个正整数，node_addr 为 ip:grpc_port 文档里面说 node_id 要正整数，其实可以为 0 ，对吗 |
| 35 heqingpan OP @kerb15 内存初始 25M 左右，具体和配置内容有关。cpu 默认小于 1% 压测 4 万 qps 时占用 30%左右，具体的和机器有关。 |
| 36 heqingpan OP @zzl22100048 0 其实也是可以的 |
 | 38 allenzhangSB 2023 年 9 月 28 日 @heqingpan #22 稳定性和用什么语言无关 |
 | 39 xzm429438709 2023 年 9 月 28 日 via Android 安全和稳定方面 rust 可以的，但是关键维护很难，出稳定，不懂 rust 怎么办，官方没这么快解决的…… |
| 40 xzm429438709 2023 年 9 月 28 日 via Android 安全和稳定方面 rust 可以的，但是关键维护很难，出问题，不懂 rust 怎么办，官方没这么快解决的…… |
 | 41 panzhc 2023 年 9 月 28 日 第一反应也是名字不突出，也许可以叫 nacos-rs 。 如果生产用的话，主要考虑的是稳定性。 更换或者升级要考虑兼容性，中小规模下性能不是瓶颈。 |
 | 42 pentilun 2023 年 9 月 28 日 名字也可以改叫 macos=r+nacos |
 | 43 simpleisbest 2023 年 9 月 28 日 @shalk 说得到位，补充点 部署到企业生产环境的组件，一般会选择相对成熟稳定的产品，经历过市场考验的，个人尝试可以，如果企业选择，必然要承担未知的风险，一旦出现问题，造成损失也许不可估量 |
| 44 nxcdJaNnmyF9O90X 2023 年 9 月 28 日 @heqingpan 这都是胡扯 k8s 生态 cncf 那么多生态你咋不说 做个配置中心 还关注啥 gc 啊 要啥自行车 你又不是做高频交易 或者做 c++系统编程 对 gc 敏感 |
 | 46 cyndihuifei 2023 年 9 月 28 日 什么叫云原生应用？ |
| 47 winglight2016 2023 年 9 月 28 日 |
 | 48 Nazz 2023 年 9 月 28 日 这种项目很难推广啊, etcd/consul 已经流行了 |
 | 49 wzcloud 2023 年 9 月 28 日 中间件, 要达到 Productoin Ready 的程度, 还有不少路要走... 总而言之, UP 加油 |
| 51 heqingpan OP @lt547670718 听起来你有过经历。 刚想中午建个群就看到你的建议 |
| 52 ZeroDu 2023 年 9 月 28 日 @winglight2016 #47 可能你是大公司，不了解。在很多小公司，无需自己运维直接上阿里云买 nacos 服务，以及兼容 springgateway 的网关是常态。 而且 nacos 对应的 springcloud 体系大多都是这些，用 k8s 的注册发现的我是没看到，部署倒是有使用。 |
| 53 heqingpan OP 开始阶段还是建个群比较方便，如果后面低级问题比较多，再约定回复提问的要求。 我建个群，用于及时沟通使用中遇到的问题。 v2ex 手机不方便放图。 想进群的可以先加我微信，再进群。 微信号：`qingpan2014`，记得备注 rnacos 。 |
| 54 heqingpan OP 晚上我也会把加群方式加到项目 readme 中。 |
 | 55 twinsdestiny 2023 年 9 月 28 日 配置中心该配置能实时生效吗 |
 | 56 kphcdr 2023 年 9 月 28 日 1 挺不错的，我的低配服务器 nacos 和 jenkins 都不敢装，因为 java 比较耗资源。这个东西我会尝试一下 |
 | 57 salmon5 2023 年 9 月 28 日 |
| 58 salmon5 2023 年 9 月 28 日 nacos 2.x 的 grpc 协议性能消耗上降低了很多，只有 1.x 的 几百分之一 吧 |
| 59 salmon5 2023 年 9 月 28 日 nacos 1.x 真的太耗资源了 |
| 60 heqingpan OP @twinsdestiny 能的，这是基本功能。 |
| 61 heqingpan OP @salmon5 在注册中心中，两个协议性能差是挺大的。grpc 用链接本身做心跳，http 每个实列要单独请求做心跳。 |
| 62 wqhui 2023 年 9 月 28 日 @heqingpan 我说的稳定性是指代码逻辑上的 bug ，这种东西很多时候只能靠大量的使用才能发现，还得有活跃社区及时修复，或者公司就有人能排查修复，但 rust 开发者不多见 |
| 63 heqingpan OP @wqhui 理解，一些功能性的 bug 确实只有大量使用才能发现。 而对于非功能问题，rust 编译通过后基本不会有问题。这个就是大家说 rust 安全稳定的原因。 bug 数量不多的话，我还是能比较及时修复的。 |
 | 65 silentsky 2023 年 9 月 28 日 via Android 这种一般很少去迁移 毕竟服务太多 |
| 66 heqingpan OP |
| 67 winglight2016 2023 年 9 月 28 日 1 @ZeroDu #52 我们不是啥大公司，k8s 都是我自己研究引入的，因为我们是 python 后台，没考虑过 spring cloud 。 我们的网关用的是 apisix ，怎么想都比 springgateway 效率高吧？ 个人认为在 k8s 环境完全没有 spring cloud 的存在价值，k8s 环境还要什么服务注册、发现，也没有负载均衡、断路器这种需求。 我们也在考虑换到 java 后台，不过 springboot 已经足够了。我在看 spring security 和 config server ，其他组件都没有什么帮助。 |
 | 68 Naccl 2023 年 9 月 28 日 我真会试一下，nacos 太吃资源了，感觉很有应用场景，回头就把个人项目迁过来 |
| 69 heqingpan OP 欢迎试用，过程如果有遇到问题可以给我提 issues 。 |
| 70 8rmEHZ8WhVHVOb0E 2023 年 9 月 29 日 您说的是 [etcd]( https://etcd.io/) 吗 |
| 71 heqingpan OP @xiaomada 我说的是 nacos 。想确认用的人多不多，其中有多少人愿意试用，其选择背后的考量。 目前大体的信息已收集到，前期个人、小公司等对机器资源敏感的同学相对愿意试用。 （有人用，有价值，可以继续做） 规模大一些的，可能需要能证明其真的比较稳定可靠后才会考虑。（潜在的用户） etcd 是一个键值数据库，从功能上它和 nacos 配置中心比较接近。 它也可以当注册中心来用，不过从原理上性能、可用性会比 nacos 的中心低一些（所以在 nacos 中注册、配置中心是两个不实现的模块）。 只是功能上相同，切换还是需要比较大的改造成本。 rnacos 是在功能和接口协议都做了兼容，切换过程应用是不需要做改造的。 这两个还是有区别的。 |
Select Language