本人是 r-nacos 作者，在完成 rust 重写 nacos 服务主体功能后，最近在计划用 rust 重写 xxl-job 服务。
本人在写服务端前习惯写个客户端，方便深入理解协议与开发过程中各类场景的验证。
刚才目前 rust 没有 xxl-job 的 sdk 便先写一个 xxl-job rusk sdk 。
sdk 对应的项目是 xxljob-sdk-rs ,目前主体功能已可用，具体使用方式可以参考项目 readme 。感兴趣的 rust 开发可以观注下，如果使用过程中遇到什么问题可以到 github 上提 issues 。
对于用 rust 重写 xxl-job 服务这个项目，大家有什么建议或者期望欢迎一起讨论。

能做什么呀，读 readme 有点没看懂

xxl-job 是一个分布式调度平台，可以简单理解为分布式定时器。

它分服务端调度和客户端执行器，目前完成的 sdk 只是客户端支持接入服务端当做一个执行器，重写服务端正在计划中还没有完成。

r-nacos 确实好用，点个赞

客户端执行器可以自动注册，但是还需要再手动添加，一旦 job 多了，手动在页面上加，体验很糟。
个人建议进一步完善自动注册。

还有异常报警，建议添加 企微/钉钉等目前主流信道

看了下我们测试的 nacos 随便就占了 1G 内存，r-nacos 估计能节省 90%，要是 UI 也能对齐就好了，点个赞，加油

好多小公司的大数据调度任务直接用的就是 xxl

xxl-job 的源码阅读，有推荐的博客吗，想深入了解一下

支持一下

自动注册与报警方式需求收到，自动注册目前协议上是不支持的，后面考虑新增扩展 openapi 支持，不过对应的执行器 sdk 也需要增强才可能可以支持。

另外自动注册的任务会解决少部分信息，可能的需要人工修改补充信息后才可以启用。

没有。xxl-job 代码量不太结构也比较清晰，可以直接看代码。

重新设计一个吧，xxl-job 真不咋样

感谢支持😊

我重写时肯定是会重新设计的，也会增加自己的 openapi 。
只是会第一个兼容 xxl-job 的协议，加入已有的流行生态，项目才能快速启动。

如果有其它流行任务调度协议后面也会考虑兼容支持，这块有推荐的吗？

厉害，r-nacos 很🐂，印象深刻。期待改写效果

可以看下阿里云的 schedulex ，只不是是闭源。但是 api 有提供文档， help.aliyun.com/zh/mse/developer-reference/api-schedulerx2-2019-04-30-createnamespace-mse?spm=a2c4g.11186623.help-menu-123350.d_5_1_0_0_3_1_0.60391509FLhqKg&scm=20140722.H_2848778._.OR_help-T_cn~zh-V_1

最终不管兼容谁的协议，希望加上 namespace 资源隔离

加上 namespace 做资源隔离，这是一个不错的建议，计划会支持。

支持作者，刚刚去看了 rnacos ，把我原先的 nacos 内存从 1011M 降到 8M ，太给力了。同样的 xxl-job 我也有用到，占用了 700M ，如果能像 rnacos 那样节省 99%，真是太棒了。PS：有没有考虑把 elasticsearch 也优化下，这货占了几 G 。

是 rnacos 的作者吗？我当时真有点想在生产环境直接用 rnacos 了，迫于稳定性最终还是没采用。

不如找个国外项目用 Rust 重写, 开捐款, 国产项目纯用爱发电.

重写 xxl-job 节省 99%不一定能达到，节省 95%的把握还是比较大的。

一阶段只能把主要精力投入一个项目，es 就看看其它人是否有兴趣吧。
我印象中已经有用 rust 写的日志服务，不过不是完全兼容协议，感兴趣可以去搜索一下。

表示理解，这个稳定性的确认还是要花一段时间的。
比如测试环境不重启持续测试运行个三个月、半年，大概就可以有较大的把握。
后面还有机会😀

目前基于收到的反馈，现在已经很稳定，所以我才有精力写下一个项目。

目前有正经不需要

目前有正经工作不需要考虑太多，写这个主要动力还是爱好。

写的项目自己也会是用户，国外的没接触过反倒没动力写。

大数据的任务调度用 dolphin scheduler 或者 airflow 比较多吧. xxljob 可能 java spring 项目用的多些吧.

elasticsearch 已经有了用 rust 重写的了

ES 在 pg+插件（比如 paradedb ）之前没有前途了

点赞，之前 rust + docker + mac 开发 + linux 部署 直接劝退，来看看怎么实现的

＃10 建议设计成通用的告警推送的方式，这样可以接入告警中心，方便管理

赞，先收藏了

赞，up 主想法真不错，给 Javaer 一个思路，入坑 Rust

你说的通用告警是指内部还是外部？
内部的话会设计成通用的，已接入告警渠道支持方便切换。
外部的话，目前有什么通用的协议吗？

告警中心是不是也可以理解为像邮箱、企微、钉钉之类的另外一个告警渠道？

欢迎入坑 rust ，用它来写中间件效果确实不错😄

r-nacos 有用过,很牛,支持

为啥没选用 go 来写呢

r-nacos 用在研测环境，真的节省了很多内存空间，很牛，支持

r-nacos 已经在开发环境使用一年。没有什么问题。

用 go 重写应该也可以提前一些但效果应该比 rust 还会差一些。
r-nacos 用 go 写的话应该达不到现在这个效果。

对 go 和 rust 的熟悉度差不多情况下，一般会选效果最好的，何况我现在使用 rust 便顺手一些。

文档啥的，可以在详细丰富一下💪💪💪。比如它的背景，目的，具体的使用场景（比如结合 actix, axum 等 web 框架的最佳使用）

大佬还是强

谢谢，我去看看其文档。

哇塞！现在才看到还有 r-nacos 这个应用，赶紧部署一个试试看。
xxx-job 和 es 目前也是内存大户，属于不得不用的类型，因为看其他竞品要么功能不如它强大，要么还不如它开放。

确实，哪个顺手用哪个，rust 写中间件可能会好些，go 终究还是 web 业务开发会爽些，目前我也在 rust 入门的苦海中

r-nacos 测试环境用的真的很爽，期待大佬的 xxl-job