背景：我们是一个 Java 系统，使用的是 xxljob ，最近使用 go 重构。

注意：是 CTO 定下的基调，我无法改变这件事情。

我们在调研 go 时，没有发现好用的定时任务框架，xxljob-go 也是很久没更新了。

github.com/ouqiang/gocron

这个应该够用 简单方便

非常感谢推荐～

正在寻找一个企业级的分布式任务调度框架，hhhh

大道至简
全靠手搓

asynq 挺好用的

＃1 我最开始用本地 corn ，觉得功能不够用切到了 gocron ，还是觉得不够用，现在已经切到 k3s cronjob 了……
宇宙的尽头是 k8s

歪个楼，cto 咋想的要用 go 重构...

我们也在用 xxlgo 目前没找到没其他替代的

最近也在用 xxlgo ，

干嘛要分布式，搞这么复杂

装 B ，我们公司就是，服务架构的很垃圾，用的配件看起来很高级，

大道至简
全靠手搓

＃3

java 1995 年诞生之初就啥都有吗？一个语言的基础设施和生态是无数开发者手搓出来的，虽然不需要 curd 自己手搓、但也需要时间发展，go 还很年轻，如果能有团队站出来添砖加瓦，至少我觉得是好事情。
OP 家的 CTO 让 OP 他们做 go 版本的两面看：

1. 如果团队能力 ok 能做好那是好事情、如果开源我去 star ；
2. 如果团队实力不足以做好那是 CTO 自己装逼了。
   现在只是开头，不了解 OP 团队实力、没看到过程和结果，我不妄加评论，但是希望 OP 加油，这是个提升自己的好机会。

有人可能反驳、xxljob 现成的来为啥要重复造轮子、没必要 go 或者 rust 手搓，那请自己看看 java 的这些被大家用来重复造轮子的原版和新轮子的性能、硬件开销的对比去吧，但凡如果只提升了 5%那这种重复轮子都是浪费时间，但很可惜、每个新的好轮子都不只是这点提升。
另外，很多中小团队，希望避免过多技术栈的引入来保持精简干净，go 的部署也更容易，相比于还要先学习研究下 java 环境各种，如果有 go 自己的轮子，go 开发自己把 devops 的活也干得更轻松开心些。

大道至简从来不是个坏事情，不喜欢的人不懂得把工程搞扎实、但喜欢的人多了去了。
就说 v 站吧，你看看 go 的帖子频率怎样？你门以为越骂越火是因为被骂火的、像娱乐圈一样吗？
很显然不是，而是因为很多喜欢 go 的人不善于归纳总结和反驳因为这需要理中客和技术深度、这样的文字更具难度，这些人在踏踏实实用 go 做事发声少罢了。
但相比之下，嘲讽起哄非常容易、加之跟风的心理学作祟，所以显得骂声很多罢了。
喜欢的人越来越多，所以 go 的份额也在增长和企稳，骂 go 的声音就类似于幸存者偏差。

自己不给社区添砖加瓦没关系因为这从来不是必须，如果能输出好的技术观点骂到点子上那也是好的技术交流，但如果只是无脑嘲讽，并不能抬高自己，一点都不高尚。

强烈支持 Gopher 造轮子，能造好皆大欢喜、社区基础设施越来越丰富，即使造不好就当学习练手了、而且造不好大家不用就是了也没什么损失。
先不说 CTO 是不是装逼，就从这个层面支持团队造轮子我就先支持一票！业余时间为爱发电精力有限太辛苦，有这种支持带薪造轮子是多好的事情啊！很多人羡慕还来不及呢！

背景：我们是一个 Java 系统，使用的是 xxljob ，最近使用 go 重构。

刚才没仔细看，以为是要再造个 go 版的 xxljob 。但是不影响＃11 ＃12 总体观点，补充：不只支持 Gopher 造轮子，也支持适合的项目用 go 重构！尤其那些内存怪，尤其那些换 go 重构之后硬件占用大幅降低的！

试试 dagu ，但是简陋到连登录啥的都省了，可以二开做一些事情
github.com/dagu-org/dagu

xxljob go 不更新也不影响你使用啊，又不是有什么 bug ，执行器本来功能就不多，如果一直更新说明调整多，升级反而麻烦

之前看到得物写过一篇他们内部用的定时任务，看着挺好的，可惜没有开源

k8s 了你还是得考虑跨集群的 DR 还有混合云。。。

以前我会觉得这种重复造轮子不是好的方式。现在不这么觉得了，有事“折腾”是好事。

temporal 也有定时任务功能，不知道你们有没有调研

用海豚调度吧，别费劲了