Open zlzforever opened 6 years ago
想法挺好。
消息队列推送,那也只是推送,消费的话还是业务代码自行消费。 是这个意思吗?
是的,真正做到全公司只需要一个调度管理。而且将来还可以做成SAAS服务也许~~~
很多时候想法比技术本身更重要,666!
消息队列推送感觉太重了,难道是在这边跑的MQ的Client么?这么多MQ都要接一次? 真正重要的消息真的会频繁调用Job来触发么?
明确一下这个项目的目的,这是做的是一个调度...
另一个想法(大坑):热加载Job...
参见阿里云SchedulerX, 我司90%的程序都需要调度,并且都不是web程序,使用http callback无法满足。此项目做的应该是触发事件后,通过各个job配置好的http(get, post...)回调到各应用程序,并不是说你写好一个程序上传到平台,然后定时运行这个job.
@liguobao 我个人觉得 1、我个人觉得楼上@zlzforever 说的有道理,HTTP回调只是一种,MQ只是另外一种。程序也不全是Web。可能是桌面也可能是服务或者其他,通过MQ也不失为一种有效方式。 2、你说的热加载Job具体是指什么,详细聊聊?
quartz做quartz的事情,MQ做MQ的事情,我是觉得不应该放一起的.
我们去看下阿里的SchedulerX做了什么事情.
SchedulerX 是阿里中间件团队开发的一款分布式任务调度产品,在阿里内部有着广泛的使用,经过集团内上千个业务应用历经多年打磨而成。每天非常稳定的运行着集团内几十万个任务以及完成每天几亿次的任务调度。 您可以在应用中依赖 SchedulerX-Client,并在 EDAS 控制台创建定时任务,进行相应的参数配置后,启动该应用就可以接收到定时任务的周期调度。SchedulerX-Server 集群为调度触发提供高可用性和高稳定性的保证,并且可以实现对您的客户端机器集群进行分布式调度。
这个思路是没问题的,不过项目建议改名....
理想的类热加载是直接扔一个Class 文件上去(Job接口的一个实现),然后直接就跑了. @zhaopeiym
@liguobao 热加载这个好这样可以自己写一些业务逻辑。 以前的一个ETL项目就是这样的,支持数据库(sql语句,存储过程)[mssql\oracle\mysql]、自定义插件(热加载)、webservice、rest api等。当然这个注重的是数据采集等,但是前面任务的设置, 楼主可以参考。另外在传递的参数那里,建议可以加一些表达式,比如时间的表达式等,这样触发任务的时候可以按照表达式解析出具体参数然后传参(类似格式{DateTime.Now.ToString("yyyy-MM")}这样),使调用更加多样化。
最好还可以集群分布式调度,hangfire是靠数据库的,job一多,非常容易出现死锁的提示
希望可以加上用户验证,
最近在研究分布式调度,分享一下自己的经验和想法。
在这里首先贴一下google的分布式调度的介绍distributed-periodic-scheduling, 我觉得应该自己去设计一个job系统,可以基于cron这些类库做成分布式的。 先说说前期的我们是怎么做的把? 版本一: 基于cron类库做一些改造,支持分布式的job调度。利用etcd的分布式锁对job抢占。 ,而job的执行的方式只支持执行shell的。整体架构就是用的etcd存储要跑的node节点, 然后需要执行的job的等一些主要的元数据,然后日志丢到mongodb去做。这是我们最初的 版本设计。 版本一遇到一些问题:
版本二进行了重新设计:
以上一些设计和想法,可以和你们多多交流,或者可以分享一下你们的想法。
希望可以加上用户验证,
简单的用户验证可以用nginx实现吧。
可以考虑下结合 elsa 工作流 实现一个类似 airflow的产品, 实现IJOB基类中 加入个 防止重入的功能
这是要造个调度中心的轮子吗?xxl-job已经实现了分布式调度中心,但对.Net接入不是很友好。