V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
heqingpan
V2EX  ›  Java

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

  •  
  •   heqingpan · 154 天前 · 4628 次点击
    这是一个创建于 154 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我之前用 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 给个星 。

    71 条回复    2023-09-29 17:31:05 +08:00
    imokkkk
        1
    imokkkk  
       154 天前
    挺好的 加油
    infun
        2
    infun  
       154 天前
    如果名字叫 racos 就更好了
    gclm
        3
    gclm  
       154 天前
    🐂,💪🏻 刚本地测试了一下初步感觉效果不错,建议作者搞个微信群或者其他交流渠道,我把个人的小玩意迁移过来,到时候及时交流沟通沟通
    zzl22100048
        4
    zzl22100048  
       154 天前
    原版 1.x 的集群脑裂问题解决了吗
    Kilerd
        5
    Kilerd  
       154 天前   ❤️ 1
    简单看了下,手搓 raft ,感觉有点慌。
    thetbw
        6
    thetbw  
       154 天前
    个人会用
    burymme11
        7
    burymme11  
       154 天前
    收藏支持下。下次开新项目我试试。
    zzl22100048
        8
    zzl22100048  
       154 天前
    看上去没脑裂问题,就是启动需要 node_id 对 k8s 部署太不友好了,而且 node_id 是从 1 开始,想从 podname 截取都不行
    yrzs
        9
    yrzs  
       154 天前
    已 star,下次本地开发部署试试
    javak
        10
    javak  
       154 天前
    我用的 eureka ,楼主有空了再写个这个
    pannanxu
        11
    pannanxu  
       154 天前   ❤️ 5
    系统级语言重写,性能更高、占用资源更小❌

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

    仅仅针对这几点来说,个人认为,作者提出的几个问题并不是什么痛点。但还是支持一下。
    coyove
        12
    coyove  
       154 天前
    手搓基建轮子没人用不是很正常吗,你总得说服人家敢用啊
    fanchenio
        13
    fanchenio  
       154 天前
    赞同二楼,名字修改一下。
    pannanxu
        14
    pannanxu  
       154 天前
    @pannanxu 或者改名叫 nacos4rust 把,你这个名字不仔细看总是看错
    heqingpan
        15
    heqingpan  
    OP
       154 天前 via Android
    @infun 最开始也想用这个,结果在 crate 被点用了。
    heqingpan
        16
    heqingpan  
    OP
       154 天前 via Android
    @gclm 好建议,我晚点建一个。
    wqhui
        17
    wqhui  
       154 天前
    最简单一个问题对于商业应用来说是资源占用少、性能高重要,还是稳定性重要,资源跟性能问题可以堆机器解决,万一这种基础组件不稳定,带来的损失就大多了,而个人应用又很少需要搞微服务的
    heqingpan
        18
    heqingpan  
    OP
       154 天前 via Android
    @Kilerd 是基与一个 rust raft 库实现的。
    heqingpan
        19
    heqingpan  
    OP
       154 天前 via Android
    @zzl22100048
    node_id 可以不是 1 ,可以不连续,但需要是不唯一的整数。
    Kilerd
        20
    Kilerd  
       154 天前   ❤️ 5
    @pannanxu 终于有人说重点了。

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

    因为不会出现资源膨胀,在生产环境里面把单个的 1G 降低到 5M 带来的价值其实不大
    winglight2016
        21
    winglight2016  
       154 天前
    有 k8s ,nacos 没什么用了。如果只是配置中心,和 spring 的 config server 比有什么优势吗?
    heqingpan
        22
    heqingpan  
    OP
       154 天前 via Android
    @wqhui rust 写的比 java 写稳定性上会更好。
    ZeroDu
        23
    ZeroDu  
       154 天前
    @winglight2016 #21 spring 那个估计都没多少人用。nacos 有后台管理面板。配置修改等等都很舒服。而且注册中心+配置中心合一,无缝切换阿里云。
    heqingpan
        24
    heqingpan  
    OP
       154 天前 via Android
    @pannanxu
    @Kilerd
    感谢反馈。
    社区、生态确定比较重要。
    这是一个循环依赖问题,生态好了用的人会多,用的人多了反过来生态也会变好。
    ZeroDu
        25
    ZeroDu  
       154 天前
    你这个可以联系一下官方社区,看看能否给加个引流连接
    heqingpan
        26
    heqingpan  
    OP
       154 天前 via Android
    @winglight2016
    功能上比 config server 强的多。
    rnacos 在占用资源、性能、稳定性上都比它好很多。
    pannanxu
        27
    pannanxu  
       154 天前
    @heqingpan #24 作者可以看看腾讯的 polaris mesh ,一站式解决方案。但是感觉没啥人用自己也不敢在生产尝试。
    kerb15
        28
    kerb15  
       154 天前
    如果只用配置中心的话,单机版的资源占用是多少
    litchinn
        29
    litchinn  
       154 天前
    对资源和性能有要求的应该会选择 consul ,你可以放一下你的项目和这两者的 benchmark 对比
    xingjue
        30
    xingjue  
       154 天前
    为啥不用 go 写 go 明显云原生生态霸主
    heqingpan
        31
    heqingpan  
    OP
       154 天前 via Android
    @kerb15 25M 内存
    heqingpan
        32
    heqingpan  
    OP
       154 天前 via Android
    @xingjue go 有 gc ,性能上比不过 rust 。
    rust 写云原生应用也很合适的。
    shalk
        33
    shalk  
       154 天前
    - 用 rust 实现,反而维护难度更大。
    - 配置中心,性能不是问题
    - 没有背书
    很难有意愿,如果文档特别好,可能会好一些,nacos 的文档写的一般
    zzl22100048
        34
    zzl22100048  
       154 天前
    @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
        35
    heqingpan  
    OP
       154 天前 via Android
    @kerb15 内存初始 25M 左右,具体和配置内容有关。cpu 默认小于 1% 压测 4 万 qps 时占用 30%左右,具体的和机器有关。
    heqingpan
        36
    heqingpan  
    OP
       154 天前 via Android
    @zzl22100048 0 其实也是可以的
    heqingpan
        37
    heqingpan  
    OP
       154 天前 via Android
    @shalk
    确定,熟悉 rust 的开发者相对较少;开发效率上其实还可以的。
    感谢反馈,文档会持续完善。
    allenzhangSB
        38
    allenzhangSB  
       154 天前
    @heqingpan #22 稳定性和用什么语言无关
    xzm429438709
        39
    xzm429438709  
       154 天前 via Android
    安全和稳定方面 rust 可以的,但是关键维护很难,出稳定,不懂 rust 怎么办,官方没这么快解决的……
    xzm429438709
        40
    xzm429438709  
       154 天前 via Android
    安全和稳定方面 rust 可以的,但是关键维护很难,出问题,不懂 rust 怎么办,官方没这么快解决的……
    panzhc
        41
    panzhc  
       154 天前
    第一反应也是名字不突出,也许可以叫 nacos-rs 。
    如果生产用的话,主要考虑的是稳定性。
    更换或者升级要考虑兼容性,中小规模下性能不是瓶颈。
    pentilun
        42
    pentilun  
       154 天前
    名字也可以改叫 macos=r+nacos
    simpleisbest
        43
    simpleisbest  
       154 天前
    @shalk 说得到位,补充点
    部署到企业生产环境的组件,一般会选择相对成熟稳定的产品,经历过市场考验的,个人尝试可以,如果企业选择,必然要承担未知的风险,一旦出现问题,造成损失也许不可估量
    xingjue
        44
    xingjue  
       154 天前
    @heqingpan 这都是胡扯 k8s 生态 cncf 那么多生态你咋不说 做个配置中心 还关注啥 gc 啊 要啥自行车 你又不是做高频交易 或者做 c++系统编程 对 gc 敏感
    heqingpan
        45
    heqingpan  
    OP
       154 天前 via Android
    @panzhc 这么多人都觉得名字不好,我改,找到合适的就改😂
    cyndihuifei
        46
    cyndihuifei  
       154 天前
    什么叫云原生应用?
    winglight2016
        47
    winglight2016  
       154 天前
    @ZeroDu #23 后台面板没什么用,而且配置修改自己开发可以实现更好的效果。注册中心对于 k8s 的意义是 0 ,跟阿里云也没什么关系呀。


    @heqingpan 我们自己用 go 开发了一个配置中心,基于 etcd 存储,也完全够用了
    Nazz
        48
    Nazz  
       154 天前
    这种项目很难推广啊, etcd/consul 已经流行了
    wzcloud
        49
    wzcloud  
       154 天前
    中间件, 要达到 Productoin Ready 的程度, 还有不少路要走...

    总而言之, UP 加油
    Lambdua
        50
    Lambdua  
       154 天前
    @heqingpan 最好别建群,会消耗你大量的精力和时间解决很低等的问题
    heqingpan
        51
    heqingpan  
    OP
       154 天前 via Android
    @lt547670718 听起来你有过经历。
    刚想中午建个群就看到你的建议😂
    ZeroDu
        52
    ZeroDu  
       154 天前
    @winglight2016 #47 可能你是大公司,不了解。在很多小公司,无需自己运维直接上阿里云买 nacos 服务,以及兼容 springgateway 的网关是常态。
    而且 nacos 对应的 springcloud 体系大多都是这些,用 k8s 的注册发现的我是没看到,部署倒是有使用。
    heqingpan
        53
    heqingpan  
    OP
       154 天前 via Android
    开始阶段还是建个群比较方便,如果后面低级问题比较多,再约定回复提问的要求。

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

    v2ex 手机不方便放图。
    想进群的可以先加我微信,再进群。
    微信号:`qingpan2014`,记得备注 rnacos 。
    heqingpan
        54
    heqingpan  
    OP
       154 天前 via Android
    晚上我也会把加群方式加到项目 readme 中。
    twinsdestiny
        55
    twinsdestiny  
       154 天前
    配置中心该配置能实时生效吗
    kphcdr
        56
    kphcdr  
       154 天前   ❤️ 1
    挺不错的,我的低配服务器 nacos 和 jenkins 都不敢装,因为 java 比较耗资源。这个东西我会尝试一下
    salmon5
        58
    salmon5  
       154 天前
    nacos 2.x 的 grpc 协议性能消耗上降低了很多,只有 1.x 的 几百分之一 吧
    salmon5
        59
    salmon5  
       154 天前
    nacos 1.x 真的太耗资源了
    heqingpan
        60
    heqingpan  
    OP
       154 天前 via Android
    @twinsdestiny 能的,这是基本功能。
    heqingpan
        61
    heqingpan  
    OP
       154 天前 via Android
    @salmon5 在注册中心中,两个协议性能差是挺大的。grpc 用链接本身做心跳,http 每个实列要单独请求做心跳。
    wqhui
        62
    wqhui  
       154 天前
    @heqingpan 我说的稳定性是指代码逻辑上的 bug ,这种东西很多时候只能靠大量的使用才能发现,还得有活跃社区及时修复,或者公司就有人能排查修复,但 rust 开发者不多见
    heqingpan
        63
    heqingpan  
    OP
       154 天前 via Android
    @wqhui
    理解,一些功能性的 bug 确实只有大量使用才能发现。
    而对于非功能问题,rust 编译通过后基本不会有问题。这个就是大家说 rust 安全稳定的原因。

    bug 数量不多的话,我还是能比较及时修复的。
    ice
        64
    ice  
       154 天前
    @pentilun rn 看着确实如 m,但是 macos 碰到 mac 了
    silentsky
        65
    silentsky  
       154 天前 via Android
    这种一般很少去迁移 毕竟服务太多
    heqingpan
        66
    heqingpan  
    OP
       154 天前 via Android
    @silentsky
    这个只需要换 nacos 服务。

    验证通过后,kill 老服务,启动新服务。一分钟内完成切换。
    winglight2016
        67
    winglight2016  
       154 天前
    @ZeroDu #52 我们不是啥大公司,k8s 都是我自己研究引入的,因为我们是 python 后台,没考虑过 spring cloud 。

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

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

    我们也在考虑换到 java 后台,不过 springboot 已经足够了。我在看 spring security 和 config server ,其他组件都没有什么帮助。
    Naccl
        68
    Naccl  
       154 天前
    我真会试一下,nacos 太吃资源了,感觉很有应用场景,回头就把个人项目迁过来
    heqingpan
        69
    heqingpan  
    OP
       153 天前
    欢迎试用,过程如果有遇到问题可以给我提 issues 。
    xiaomada
        70
    xiaomada  
       153 天前
    您说的是 [etcd]( https://etcd.io/) 吗
    heqingpan
        71
    heqingpan  
    OP
       153 天前
    @xiaomada

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

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

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

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

    这两个还是有区别的。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3321 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 11:42 · PVG 19:42 · LAX 03:42 · JFK 06:42
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.