未分類
15 6 月 2020

OhMyScheduler – 强大的分布式调度与计算框架

OhMyScheduler – 强大的分布式调度与计算框架

資深大佬 : tjq 13

简介

OhMyScheduler 是基于 Akka 架构的新一代分布式调度与计算框架，支持 CRON 、API 、固定频率、固定延迟四种调度策略，提供工作流（ DAG ）来编排任务解决依赖关系，使用简单，功能强大，文档齐全，能够让你轻松完成作业的调度与繁杂任务的分布式计算。

主要功能特性

  • 使用简单：提供前端 Web 界面，允许开发者可视化地完成调度任务的管理、任务运行状态监控和运行日志查看等功能。
  • 定时策略完善：支持 CRON 表达式、固定频率、固定延迟和 API 四种定时调度策略。
  • 执行模式丰富：支持单机、广播、Map 、MapReduce四种执行模式，其中Map/MapReduce 处理器能使开发者寥寥数行代码便获得集群分布式计算的能力。
  • DAG 工作流支持：支持在线配置任务依赖关系，可视化得对任务进行编排，同时还支持上下游任务间的数据传递
  • 执行器支持广泛：支持 Spring Bean 、内置 /外置 Java 类、Shell 、Python 等处理器，应用范围广。
  • 运维便捷：支持在线日志功能，执行器产生的日志可以在前端控制台页面实时显示，降低 debug 成本，极大地提高开发效率。
  • 依赖精简：最小仅依赖关系型数据库（ MySQL/Oracle/PostgreSQL/MS SQLServer…），同时兼容当面所有主流数据库！
  • 高可用&高性能&故障转移与恢复

适用场景

  • 有定时执行需求的业务场景：如每天凌晨全量同步数据、生成业务报表等。
  • 有需要全部机器一同执行的业务场景：如使用广播执行模式清理集群日志。
  • 有需要分布式处理的业务场景：比如需要更新一大批数据，单机执行耗时非常长，可以使用 Map/MapReduce 处理器完成任务的分发，调动整个集群加速计算。

同类产品对比

OhMyScheduler - 强大的分布式调度与计算框架

传送门

项目地址： https://github.com/KFCFans/OhMyScheduler

文档地址： https://www.yuque.com/ohmyscheduler/guidence/ztn4i5

在线使用： https://www.yuque.com/ohmyscheduler/guidence/hnbskn

觉得还不错的话，可以点个 Star 支持一下～

大佬有話說 (19)

  • 資深大佬 : 0312birdzhang

    quartz 不支持分布式任务？不对吧，人家可以用数据库来做分布式

  • 資深大佬 : crystom

    跟 airflow 有什么区别

  • 主 資深大佬 : tjq

    @0312birdzhang TAB 名称写错了，我应该写“分布式计算”的，也就是任务派发后只有一台机器能执行还是有多台机器能共从参与运算～
    感谢指正～

  • 主 資深大佬 : tjq

    @crystom 立足点和面向的领域不同。

    像 airflow 、dolphinscheduler 这类框架主要面向大数据处理领域，其核心需求是按照规定流程（ DAG ）跑一堆脚本去完成一些数据任务。因此这类框架提供的处理器一般都很简单（比如 Airflow 其实就是用 bash 去执行 shell 、python 脚本或者用 HTTP 去触发），其主要功能或者亮点在于如何生成并发布数据处理方法（像 dolphinscheduler （基于 airflow 二次开发的框架）内置了 MySQL 、Spark 、Hive 、Hadoop 等等各种数据源客户端，用户可以直接在线写 SQL 、HQL 等完成数据擦操作）。

    而 OhMyScheduler 最初是面向业务应用设计的，核心需求是解决那些需要通过代码做一些复杂的数据处理的任务的调度，同时在计算量很大单机难以支撑的情况下提供分布式计算能力。这个场景显然是 airflow 系无法解决的。

    简单概括，airflow 系的主战场是跑脚本跑 SQL 类任务，而 OhMyScheduler 的主战场是业务相关的需要写代码完成的计算任务，当然，也顺手支持脚本的运行。

  • 資深大佬 : kifile

    感觉左侧栏目有些多，很多页面可以融合在一起更高效。

  • 資深大佬 : zuston

    高可用怎么实现的？高性能体现在什么地方？文档中没找到设计架构图

  • 主 資深大佬 : tjq

    @kifile emmm 主要是功能比较强大和丰富，就有那么多栏目了哈哈哈～

    用熟了其实还好，毕竟是面向开发者的后台，而不是面向普通用户的前端～

    感谢建议～

  • 主 資深大佬 : tjq

    @zuston 通过集群部署+服务发现实现的。

    原理分析性的文档后续会补上去，目前还在推广阶段，光写用户文档就已经很费事费力了 hhh

  • 資深大佬 : zuston

    @tjq 架构说明还是很重要的

  • 主 資深大佬 : tjq

    @zuston 确实，这几天我抽时间好好弄个架构图出来～
    感谢您的建议哈～

  • 資深大佬 : Suclogger

    hhh，冲着项目题图给个星

  • 主 資深大佬 : tjq

    @Suclogger 哈哈哈昨天群里的老哥让我赶紧换个 LOGO，说这样上不了生产 hhh

  • 資深大佬 : tlday

    说实话，我觉得名字和 LOGO 都可以换换…假如有心把差异化做大项目做出来的话，换个单个单词的名字要好得多。

  • 資深大佬 : hantsy

    在 Spring 开发中，好久以前开始用 JDK 自带的 Timer Task 代替了，更简单，无需配置。绝大部分时间我们用不到 Quartz 的一些高级功能。

  • 資深大佬 : hantsy

    谈到任务的，定时任务很多是批处理，Spring 中一些任务都是 Delegate 到 Spring Batch 中去执行。Timer/Scheduler 只是一个定时触发器而已。

  • 資深大佬 : hantsy

    我是搞不定国内对这种带界面的东西都这么大兴趣，什么各种 Admin 界面，什么用户 CRUD，什么任务管理界面。

  • 主 資深大佬 : tjq

    @tlday 收到了太多类似的反馈，前几天和群友认真讨论了一下，就决定改名了。
    目前把项目名称改成了 PowerJob （灵感来源于微软的 PowerShell ），LOGO 也换了。
    有兴趣可以去 GitHub 再看看哈哈～

  • 主 資深大佬 : tjq

    @hantsy Java 和 Spring 自带的定时调度功能非常有限，用起来也十分不方便，你应该是还没有接触到需要分布式调度的业务场景，接触到后你就会发现意义所在。

    带界面只是方便用户使用，在线监控、运维都是能极大提升开发效率的。任何一个框架只有足够简单易用才能吸引别人去使用～

  • 資深大佬 : hantsy

    国内这些东西太多了，没兴趣。不管是 Spring 还是 Java EE/Jakarta EE，都是可以用 JDK 自带的实现 cron, fixed initial, interval 定时任务等等。

    运维用界面都是比较 Low 才会用。高级 DevOps 都脚本语言和各种开放 API 操作，写一些 Scripts 结合 CI 触发机制，实现完全自动化。系统运行监控中界面算是一部分功能，但是一个系统在运行过程中，更重要的是要有很好的预警和有效的通知机制，而不是出现什么问题去打开界面查看。