OhMyScheduler 是基于 Akka 架构的新一代分布式调度与计算框架,支持 CRON 、API 、固定频率、固定延迟四种调度策略,提供工作流( DAG )来编排任务解决依赖关系,使用简单,功能强大,文档齐全,能够让你轻松完成作业的调度与繁杂任务的分布式计算。
项目地址: https://github.com/KFCFans/OhMyScheduler
文档地址: https://www.yuque.com/ohmyscheduler/guidence/ztn4i5
在线使用: https://www.yuque.com/ohmyscheduler/guidence/hnbskn
觉得还不错的话,可以点个 Star 支持一下~
1
0312birdzhang 2020-06-12 08:46:14 +08:00 via iPhone
quartz 不支持分布式任务?不对吧,人家可以用数据库来做分布式
|
2
crystom 2020-06-12 08:48:34 +08:00
跟 airflow 有什么区别
|
3
tjq OP @0312birdzhang TAB 名称写错了,我应该写“分布式计算”的,也就是任务派发后只有一台机器能执行还是有多台机器能共从参与运算~
感谢指正~ |
4
tjq OP @crystom 立足点和面向的领域不同。
像 airflow 、dolphinscheduler 这类框架主要面向大数据处理领域,其核心需求是按照规定流程( DAG )跑一堆脚本去完成一些数据任务。因此这类框架提供的处理器一般都很简单(比如 Airflow 其实就是用 bash 去执行 shell 、python 脚本或者用 HTTP 去触发),其主要功能或者亮点在于如何生成并发布数据处理方法(像 dolphinscheduler (基于 airflow 二次开发的框架)内置了 MySQL 、Spark 、Hive 、Hadoop 等等各种数据源客户端,用户可以直接在线写 SQL 、HQL 等完成数据擦操作)。 而 OhMyScheduler 最初是面向业务应用设计的,核心需求是解决那些需要通过代码做一些复杂的数据处理的任务的调度,同时在计算量很大单机难以支撑的情况下提供分布式计算能力。这个场景显然是 airflow 系无法解决的。 简单概括,airflow 系的主战场是跑脚本跑 SQL 类任务,而 OhMyScheduler 的主战场是业务相关的需要写代码完成的计算任务,当然,也顺手支持脚本的运行。 |
5
kifile 2020-06-12 10:33:29 +08:00
感觉左侧栏目有些多,很多页面可以融合在一起更高效。
|
6
zuston 2020-06-12 10:51:30 +08:00
高可用怎么实现的?高性能体现在什么地方?文档中没找到设计架构图
|
7
tjq OP |
8
tjq OP |
11
Suclogger 2020-06-12 14:53:38 +08:00
hhh,冲着项目题图给个星
|
13
tlday 2020-06-13 14:33:57 +08:00
说实话,我觉得名字和 LOGO 都可以换换...假如有心把差异化做大项目做出来的话,换个单个单词的名字要好得多。
|
14
hantsy 2020-06-14 09:16:36 +08:00
在 Spring 开发中,好久以前开始用 JDK 自带的 Timer Task 代替了,更简单,无需配置。绝大部分时间我们用不到 Quartz 的一些高级功能。
|
15
hantsy 2020-06-14 09:18:24 +08:00
谈到任务的,定时任务很多是批处理,Spring 中一些任务都是 Delegate 到 Spring Batch 中去执行。Timer/Scheduler 只是一个定时触发器而已。
|
16
hantsy 2020-06-14 09:19:56 +08:00
我是搞不定国内对这种带界面的东西都这么大兴趣,什么各种 Admin 界面,什么用户 CRUD,什么任务管理界面。
|
17
tjq OP @tlday 收到了太多类似的反馈,前几天和群友认真讨论了一下,就决定改名了。
目前把项目名称改成了 PowerJob (灵感来源于微软的 PowerShell ),LOGO 也换了。 有兴趣可以去 GitHub 再看看哈哈~ |
18
tjq OP @hantsy Java 和 Spring 自带的定时调度功能非常有限,用起来也十分不方便,你应该是还没有接触到需要分布式调度的业务场景,接触到后你就会发现意义所在。
带界面只是方便用户使用,在线监控、运维都是能极大提升开发效率的。任何一个框架只有足够简单易用才能吸引别人去使用~ |
19
hantsy 2020-06-14 18:15:54 +08:00
国内这些东西太多了,没兴趣。不管是 Spring 还是 Java EE/Jakarta EE,都是可以用 JDK 自带的实现 cron, fixed initial, interval 定时任务等等。
运维用界面都是比较 Low 才会用。高级 DevOps 都脚本语言和各种开放 API 操作,写一些 Scripts 结合 CI 触发机制,实现完全自动化。系统运行监控中界面算是一部分功能,但是一个系统在运行过程中,更重要的是要有很好的预警和有效的通知机制,而不是出现什么问题去打开界面查看。 |
20
tjq OP @hantsy 你没有接触过需要这种作业调度框架的场景,所以想像不到意义。
你口口声声说 JDK 自带的调度机制也只是在单机的情况下能够完成部分功能。举个例子,在整个集群中我只需要某台机器去执行某个任务,通过 JDK 自带的 Scheduler 怎么实现,用分布式锁?那不就是额外的中间件成本和开发成本吗?需求再变态点,我需要指定集群中具体的某几台机器去执行某个任务,这个 JDK 自带的 Scheduler 又怎么实现呢? 运维界面你看不上也可以不用。你完全可以通过我提供的 OpenAPI 操作整个系统,像 AWS 这类不也是同时提供网页和 CLI 工具吗?难不成你给 AWS 提供 advice 说用户界面太 low 啦,我们都是 CLI 党,强烈建议下架 AWS 控制台? 预警和有效的通知机制当然是有的,但这和前端界面完全不是一个层面的东西。就像 AWS 的控制台和 AWS 实例报警通知,是一回事吗? 最后,本框架的主题是调度和分布式计算,主打功能是分布式计算,你一直纠结在前端页面上也是让我没想到的...... |
21
hantsy 2020-06-16 09:42:08 +08:00
@tjq 嗯,我接触的少。之前一个项目需要银行对账,调用第三方支付接口对比,还要每天生成各种报表,用的 Spring JDK Timer 和 Spring Batch 。还有一个海外支付项目,有大量定时批处理任务,基本是用到 Spring Batch,Spring Integration,Spring Cloud 下多个项目,还有 Spring 下一些不多见(短命的)的项目,Spring Plugin,Spring Sync 等。我接触到的国外的项目,用 AWS 的 DevOps 人员,几乎只是开始的时候,登录 AWS 建一些必要的资源,然后基本都是客户端命令操作,自己写一些 Scripts (有的结合 CI ),来执行任务,后来基本上不需要登录 AWS,真正在实施 Infrastructure as Code 。我以前也傻傻问老外,为什么不用 Aws 界面操作,他们说很多操作是界面没有,而且也不如 CLI 便捷。我自己玩 OpenShift 的时候才知道,很多功能只有通过 CLI 才能操作。
自从 Spring 集成了 JDK timer 后,我不再用 Quartz 。已经说过,定时器仅仅是触发任务执行, 任务的定义和执行用 Spring Batch 。之前 Spring 官方有一个 Spring Batch Admin (现在已经不维护了) 用户界面( https://github.com/spring-attic/spring-batch-admin ),来管理批处理任务。SBA 这个项目后来衍生出了 Spring Cloud Data Flow,https://spring.io/projects/spring-cloud-dataflow#overview,当然这个项目方向上有点不一样,主要是 Streams 数据分析,另一方面也保留了 Batch task 执行。我关注的是任务细分,开发的工作范围是一条命令(比如 Serverless ),一个大的任务由 SCDF 这样统一的中心来装配调度,搜集执行结果反馈出来。 你的设计这个产品和现代的云计算架构根本就不在一条线上,我不知道有什么场景用上。至于还用个列表,来讨论与 Quartz 的差别,显示自己的优势,我就有点反感了。从代码质量讲,你的代码(大概浏览了一下)根本就和 Quartz 没法比,属于我实在看不下去那种 XX 。 |
22
tjq OP @hantsy 你离题很严重。
我的第一句话是“你没有接触过需要这种作业调度框架的场景”,你举的那些你自己的项目经验无非是你自己的应用场景,也许你接触过的业务确实不需要用到第三方调度框架就能完成调度,然后配上一些数据流处理框架就能完成业务需求。但这也不代表这个世界上所有的业务场景都能这样解决啊。比如我刚才上面举的两个例子,你能用自带的 Timer 或 Scheduler 来解决吗?我已经给出了反例,你不否定我的反例而是举出了一堆无关的例子,显然没有任何说服力。 第二大段你自己也说了,面向的场景不一样,就不深入探讨了。我只能说 Spring Batch 也好,Spring Cloud Data Flow 也好,和我的框架不是一个定位一个层次的东西,他们也许和 Apache-DolphinScheduler 的定位有点类似。 “你的设计这个产品和现代的云计算架构根本就不在一条线上”这句话倒是没什么问题,确实不在一条线上,也没办法在一条线上。云级别的解决方案不是个人框架玩得转的,都需要提供一整套的解决方案。我这个框架要上云可太简单了,Server 直接由云服务商提供,Processor 全部 FaaS 化,执行器以函数为单元部署,即可拥有云上调度云上执行自动弹缩的划时代体验,但是条件呢?阿里云是我家开的还是 AWS 是我家开的? 关于列表对比 Quartz,内容全部真材实料实事求是,没有任何捏造,没有任何抹黑,如果这样的对比你都觉得有问题,那我也无话可说。 关于代码质量,我虚心求教,你觉得哪里有问题或者写的不好,十分欢迎你把问题贴出来反馈给我。但是不接受像现在这样毫无依据的 diss 。 |
23
hantsy 2020-06-16 13:31:44 +08:00
嗯,跑题了。
|
24
tikazyq 2020-06-17 23:00:45 +08:00
如果有一些实用场景就好了,例如 Crawlab,实际上也是一个调度平台,不过是针对爬虫程序的,这样会比较聚焦一些。建议楼主用这个框架多给几个实际应用场景的例子,具体解决什么问题,跟 xxl-jobs 之类的相比有什么优势,这样可能会更受欢迎一些
顺便安利下我的开源项目: https://github.com/crawlab-team/crawlab |