V2EX › heqingpan 的所有回复 › 第 1 页 / 共 6 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6

❮

❯

16 天前

回复了 CodeCaster 创建的主题 › Java › 使用 Java 写了一版 LangChain，想听听大家的意见

样例看起来还是比较简洁的，后面有空会愿意试试。
star+1

23 天前

回复了 heqingpan 创建的主题 › 程序员 › rust 重写 xxl-job 服务项目 ratch-job，第一个可测试运行 alpha 版本发布，感兴趣的同学欢迎试用。

@zhenjiachen 两个场景定位有所不同，xxl-job 这类执行器是嵌入应用进程中，支持直接调用进程内部代码。他这个架构应该主要是以独立的进程调用脚本任。

23 天前

回复了 heqingpan 创建的主题 › 程序员 › rust 重写 xxl-job 服务项目 ratch-job，第一个可测试运行 alpha 版本发布，感兴趣的同学欢迎试用。

@viking602 有上一个项目的开发经验，加上使用的 ai 助手，开发速度还算不错😀

23 天前

回复了 heqingpan 创建的主题 › 程序员 › rust 重写 xxl-job 服务项目 ratch-job，第一个可测试运行 alpha 版本发布，感兴趣的同学欢迎试用。

@aispring
1. 文档后续会补充，这个阶段主要精力投入开发。
2. 后面会提供 docker 镜像，beta 版本后就提供
3. 项目本身会实现 raft 协议，数据直接持久化到自身集群，然后支持把数据导出到 sqlite 数据库。具体可以参考 r-nacos （我写的另一个已经稳定可投入生产的项目）。

24 天前

回复了 heqingpan 创建的主题 › 程序员 › rust 重写 xxl-job 服务项目 ratch-job，第一个可测试运行 alpha 版本发布，感兴趣的同学欢迎试用。

@5waker
年前当时承诺：在年后尽快发一个最小可用版本出来，所以最近赶了些进度。

目前核心功能已基本完成，资源占用与性能应该和最终版本差别不太大。

目前只是内存版本，后面接入 raft 协议后，会同时支持持久化与集群部署。有在 r-nacos 接入 raft 经验，这个在两周内应该可以完成。完成后会发个 beta 版本出来。

51 天前

回复了 heqingpan 创建的主题 › 程序员 › 最近在计划用 rust 重写 xxl-job 服务，顺便写了一个 xxl-job 的 rusk sdk: xxljob-sdk-rs

@dddd1919 DAG 这个只和服务端有关，后面倒是可以支持。

51 天前

回复了 heqingpan 创建的主题 › 程序员 › 最近在计划用 rust 重写 xxl-job 服务，顺便写了一个 xxl-job 的 rusk sdk: xxljob-sdk-rs

@ingnoscemihi
@cornorj6
@viking602

感谢这么多人支持与期待，我更有动力了😄。
会尽快设计并写一个最小可用版本出来，快的话过完年不久可以完成第一个版本。

51 天前

回复了 heqingpan 创建的主题 › 程序员 › 最近在计划用 rust 重写 xxl-job 服务，顺便写了一个 xxl-job 的 rusk sdk: xxljob-sdk-rs

@dddd1919

我刚查了一下 dophinscheduler 的架构。它分 master 和 worker ，然后基于 zk 做集群。

它与 xxl-job 架构上区别比较明显；它的 worker 是独立的进程； xxl-job 执行器是嵌入业务服务进程中，与业主系统连接更紧密；它们算两个类型的调度系统。

本次暂不考虑支持 dophinscheduler 这类模式。

51 天前

回复了 heqingpan 创建的主题 › 程序员 › 最近在计划用 rust 重写 xxl-job 服务，顺便写了一个 xxl-job 的 rusk sdk: xxljob-sdk-rs

@cornorj6 这个日志问题已收到，感谢反馈。

关于服务端日志的问题，重写的服务可以避免这个可能问题。
重写后不依赖日志做任务状态的判断，任务状态计划会放在内存中；日志只有用户查看时才会去查询。日志支持按最长时间或最大数量保存。

关于执行器的日志，目前这个是由 sdk 控制，同时目前的协议也不支持从服务端发起删除执行器的日志，所以这个问题本次无法解决。
后续可以考虑通过扩展 sdk 方式解决。

51 天前

回复了 heqingpan 创建的主题 › 程序员 › 最近在计划用 rust 重写 xxl-job 服务，顺便写了一个 xxl-job 的 rusk sdk: xxljob-sdk-rs

@5261 是的中间件模型逻辑都比较稳定，对性能稳定性要求较高，用 rust 刚好合适。
业务需求变化比较大，更关心快速变化的场景下开发效率，性能再其次，用 go 、java 之类比较合适。

51 天前

回复了 heqingpan 创建的主题 › 程序员 › 最近在计划用 rust 重写 xxl-job 服务，顺便写了一个 xxl-job 的 rusk sdk: xxljob-sdk-rs

@3085570450tt 目前 r-nacos 的文档主要是使用说明，其它方面的后面有空慢慢补。

51 天前

回复了 heqingpan 创建的主题 › 程序员 › 最近在计划用 rust 重写 xxl-job 服务，顺便写了一个 xxl-job 的 rusk sdk: xxljob-sdk-rs

@PaulSamuelson 应用本身不会直接和 k8s 耦合，然后也是支持部署到 k8s 中。目前 r-nacos 是支持 k8s helm 方式部署的。

51 天前

回复了 heqingpan 创建的主题 › 程序员 › 最近在计划用 rust 重写 xxl-job 服务，顺便写了一个 xxl-job 的 rusk sdk: xxljob-sdk-rs

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

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