专做定制的网站,建设部网站首页,seo批量建站,代理网上注册公司本文主要介绍一下任务调度框架Flowjob的整体结构#xff0c;以及整体的心路历程。 功能介绍
flowjob主要用于搭建统一的任务调度平台#xff0c;方便各个业务方进行接入使用。 项目在设计的时候#xff0c;考虑了扩展性、稳定性、伸缩性等相关问题#xff0c;可以作为公司… 本文主要介绍一下任务调度框架Flowjob的整体结构以及整体的心路历程。 功能介绍
flowjob主要用于搭建统一的任务调度平台方便各个业务方进行接入使用。 项目在设计的时候考虑了扩展性、稳定性、伸缩性等相关问题可以作为公司的任务调度中间件被使用。
当前项目的主要稳定版本为2.x并且在2.x版本中提供了相应的前端页面配合使用。
项目地址
https://github.com/limbo-world/flowjob
在线试用
在线试用
账号flowjob
密码fjdemo
功能介绍
flowjob主要分为以下几个部分
Broker管控节点对配置好的任务在集群进行负载调度任务并下发Agent同时管理和维护Agent/Worker节点注册等。Agent代理节点接收下发的Job信息生成Task下发给Worker执行处理Job的生命周期比如工作流流转等。可以独立部署也可以依赖宿主启动。 同时此节点可以减少广播/Map/MapReduce等分片任务导致Broker存在的数据/性能压力以及云原生环境下一些启停导致的数据问题。Worker工作节点主要负责Task的具体执行。Console通过Broker提供的Api进行任务创建/更新等一些管控操作。Registry注册中心目前使用DB做为注册中心。提供了对应接口可以基于其它组件如zk、nacos等进行灵活的封装。Datasource数据库用于持久化运行数据 调度类型
固定速度作业创建后每次调度下发后间隔固定时间长度后再次触发作业调度。固定延迟作业创建后每次作业下发执行完成成功或失败后间隔固定时间长度后再次触发作业调度。CRON通过CRON表达式指定作业触发调度的时间点。
负载策略
随机将作业随机下发给某一个worker执行。轮询将任务逐个分配给worker。最不经常使用将作业下发给一个时间窗口内接收作业最少的worker。最近最少使用将作业下发给一个时间窗口内最长时间没有接受worker的worker。一致性hash同样参数的作业将始终下发给同一台机器。指定节点让作业指定下发到某个worker执行。
节点过滤方式
执行器任务只会下发给包含任务对应执行器的worker。标签任务只会下发给包含指定标签的worker。容量基于worker的任务队列/CPU/内存使用情况过滤
任务触发方式
API通过指定api触发任务执行。调度Broker自动组装数据调度对应的任务。
任务类型
按大体配置分为
普通任务只会执行一个Job。工作流任务DAG视图可以串联Job
按Job类型分为
普通对应某个执行器执行结束任务结束。广播在下发的时间点对每个可下发的节点下发任务所以子任务执行完成当前任务才执行完成。Map分为sharding和map两个步骤。sharding的时候进行分片map则对每个拆分任务进行执行。MapReduce相比于Map多了Reduce过程可以对所有Map任务的执行结果进行一个汇总。
经历分享
会接触任务调度系统也是因为工作原因。其实在平时工作中很多时候接触比较多的是Quartz、xxl-job这两款框架。然后之前工作中我们组内使用的是light-task-scheduler此框架也是当时项目组的前辈做的。但是在使用过程中我们发现存在一些不太便利的问题比如没法动态进行配置有些时候可能需要高配置节点跑数据没法指定节点我们的任务存在关联关系当时只能通过代码写逻辑来实现等等。所以和之前同事也是在后面慢慢开始打算自己着手搞一个出来。
项目兜兜转转也是经历和好几年的时间才终于能有一个相对满意的2.x版本出来。开发这样一个分布式系统其实耗费的精力十分大由于是工作之余进行整体方案设计和功能开发总会被这样那样的事情打断中间因为一些个人原因以及时间分配问题也是中断了好多次。
项目过程中你要考虑分布式场景下如何保证任务的重试如何判断长时间的任务是否还在正常执行还得考虑任务越来越多节点压力过高的挑战。
希望本项目可以帮助大家理解分布式系统中存在的问题和如何解决这类问题。代码中有很多不足也是希望大家能帮忙指出一起进步。后续有时间会继续更新项目中存在的难点以及项目中的解决思路。
