今天在看分布式任务工具 找来找去看到 3 个，xxl-job, powerjob, elasticjob 然后我发现居然全是国产的，类似产品竟然没有国外的，我寻思不应该啊 （不是说国外的就好什么的，但是这种中间件没有的话确实感到奇怪） 问了 AI 得到如下回答
XXL-JOB 、ElasticJob 这类工具在中国特别火，是由中国互联网特定的技术土壤决定的
国外用 Quartz ，它是祖师爷，国内工具大多是对 Quartz 的二次封装（加了 UI 、加了分片、加了 RPC ）。国外老项目仍大量直接用 Quartz 。
国外云原生走得更早，很多简单的定时任务直接交给 Kubernetes CronJob 或云厂商的 Serverless 服务了，不需要额外部署一个 XXL-JOB ，复杂的任务则是选择 Airflow 这样的工作流平台
国内的 ElasticJob 和 XXL-JOB 实际上是卡在了“简单 Cron”和“复杂编排”中间的一个完美生态位：它比 Quartz 好用，比 Airflow 简单，又完美契合 Java 生态
如果真是这样那感觉还是挺有意思的，居然这样奇怪的产生了一个技术生态位
 |
1
a33291 3 天前
dolphinscheduler 也还可以
|
 |
2
Yanickkk 3 天前
技术是有局部性的，中国公司的很多技术栈和海外不太一样……
|
 |
3
pangdundun996 3 天前
temporal 了解一下
|
 |
4
litchinn OP |
|
5
litchinn OP 按照这种说法就是国外发展比较快，国内云原生引入慢，于是产生了部分场景更深入的技术工具，不知道国外会不会回头发现有些工具还挺好用的，也拿去用，我想应该会吧
以及还有没有其它类似的例子 |
 |
6
JYii 3 天前
看起来 k8s CronJob 方案更好，云原生时代，需要时创建资源，用完即销毁，非常符合定时任务特性
|
 |
7
0x663 3 天前
用 dolphinscheduler 多一些
|
 |
8
Ketteiron 3 天前
拿 xxl-job 和 airflow 比较很奇怪，它们是完全不同的东西。
xxl-job 踩在了过于简单与过于复杂中间，且对 javaer 友好，让一些屎山项目能够顺利迭代下去。 xxl-job 之类的工具是基于微服务且明确违反微服务设计哲学的实用性妥协方案，它实际反映出很多公司是为了使用微服务而使用微服务，而不是需要使用微服务而使用微服务，如果是后者居多，那么并不需要这么一个"分布式调度中心"。 对于更复杂的分布式调度，不应该采用高入侵性方案，而是应该搭建一个调度平台 https://github.com/temporalio/temporal |
 |
9
HaibaraDP 3 天前
不知道是不是错觉，在技术上他们喜欢大而全的，生活上喜欢小而精的，我们则相反
|
 |
10
wxiao333 3 天前  3
欧美的公司不管大小，一般直接用 saas ，直接 azure ，aws ，gcp 三选一，什么分布式任务这种问题，是供应商解决的。
|
|
11
litchinn OP @HaibaraDP
我这些年慢慢感觉区别在于国外的技术发展往往很学术，国内的更多从实际需求场景出发 这导致有些时候同样功能的东西你刚上手觉得国内的很好用很方便（往往学习成本很低），当用了一段时间后需求发生变化业务变复杂之后，国外的那种偏学术对于用户不太友好的慢慢显出优势，它们往往有更强的可扩展性稳定性 |
 |
12
ratazzi 3 天前
ruby 的 solid_queue, good_job 了解下，确实感觉很多理念或这侧重点不一样
我也参照 solid_queue 挖了个坑 https://github.com/ratazzi/quebec |
 |
13
Gilfoyle26 3 天前
因为国内大多公司倾向于自建，国外的公司比较相信平台。国内公司骨子里是不相信其他公司提供的服务的。
|
 |
14
exonuclease 3 天前
根本没遇到过需要这种东西的场景。。。云服务商提供了类似的替代品吧 而且很多是为特定场景优化的 比如说 data factory 就是专门用来跑数据处理的 task 通用的话也有 lambda 之类的
|
|
15
wxiao333 3 天前 2
@Gilfoyle26 不是不相信，主要是考虑成本，saas 跟自建比 还是挺贵的，然后欧美程序员人工成本太高了，自己建自己维护都要成本，但是国内就不一样了，另外一些大厂也会考虑数据安全的问题，可能 saas 供应商的子公司就是他们竞争对手。
|
 |
16
635925926 3 天前
Kubernetes CronJob 是不是相当于一个项目打 2 个包（服务本体包+job 包），然后 job 包复用服务本体里的数据库等能力？
|
 |
17
LccU 3 天前
用回 Quartz 了，因为支持多时区
|
 |
18
thinszx 3 天前
我觉得是国内头部更不愿意对外付费，而且程序员更便宜，量大管饱，什么都可以自建，每个大厂都有一套自己的轮子
|
 |
19
zhanshen1614 3 天前
有些国内的技术团队不用云厂商的服务其实是“自主可控”的幻觉，本质是架构设计和产品规划的问题，多个功能相互交叉，主流框架无法支持只能自研框架，无法接入云服务，最后只能全部自研。
之前我工作过的公司，其定时任务经常用系统自带的 CronTab 或者自研任务调度器，后者时间间隔经常差一两秒，时不时来个 Too many connections 。 我最近在用 golang 做个人微服务项目准备转型 Go 开发，计划引入 Prometheus 监控，结果服务器快爆了改成代理模式，用阿里云的云监控，剩余空间腾出来装 redis 和 Grafana ，如果强行按原计划那么这 2 个就弄不了了。总之组件没有绝对的好坏，适合的才是最好的。 |
 |
20
coefu 2 天前
@635925926
使用的角度来说，你把 cronjob 理解为 Linux 的 crontab 即可，你想让 os 帮你定时跑任务，crontab -e ，写入时间和执行的命令，cronjob 一样。好处是，cronjob 可以调度到分散的机器上去执行和特定 machine/os 解耦;crontab 和 特定 machine/os 耦合,一旦 machine/os crack ，你的 cron job 就跟着 crack. |
|
21
coefu 2 天前
因为艰难的轮子可以自己造。你让国内造 Redis ，elasticsearch 看看？
|
 |
22
NoKey 2 天前 2
有个比较明显的差异
国外的很多 app ，支撑的用户数，没那么大 国内稍微一个知名的 app ，用户量级超过了国外很多 app 面临的技术难点不在一个地方 就正如。。。 你如果没进入过一个把公司搞的跟政府一样的大型公司，你永远不知道他们的 oa 系统要做的多复杂。。。。 |
Select Language