[讨论] 做一个更大的整体设计

[zlzforever]

1. 底层调度是基于Hangfire | Quart.NET 我并不关心
2. 回调方式抽象，HTTP回调只是一种, 但有局限性，需要调度的程序也不全是Web. 可以是消息队列推送等

[zhaopeiym]

想法挺好。

消息队列推送，那也只是推送，消费的话还是业务代码自行消费。 是这个意思吗？

[zlzforever]

是的，真正做到全公司只需要一个调度管理。而且将来还可以做成SAAS服务也许~~~

[zhaopeiym]

很多时候想法比技术本身更重要，666！

[liguobao]

消息队列推送感觉太重了,难道是在这边跑的MQ的Client么?这么多MQ都要接一次?
真正重要的消息真的会频繁调用Job来触发么?

[liguobao]

明确一下这个项目的目的,这是做的是一个调度...

[liguobao]

另一个想法(大坑):热加载Job...

[zlzforever]

参见阿里云SchedulerX, 我司90%的程序都需要调度，并且都不是web程序，使用http callback无法满足。此项目做的应该是触发事件后，通过各个job配置好的http(get, post...)回调到各应用程序，并不是说你写好一个程序上传到平台，然后定时运行这个job.

[zhaopeiym]

@liguobao 我个人觉得
1、我个人觉得楼上@zlzforever 说的有道理，HTTP回调只是一种，MQ只是另外一种。程序也不全是Web。可能是桌面也可能是服务或者其他，通过MQ也不失为一种有效方式。
2、你说的热加载Job具体是指什么，详细聊聊？

[liguobao]

quartz做quartz的事情,MQ做MQ的事情,我是觉得不应该放一起的.

我们去看下阿里的SchedulerX做了什么事情.

SchedulerX 是阿里中间件团队开发的一款分布式任务调度产品，在阿里内部有着广泛的使用，经过集团内上千个业务应用历经多年打磨而成。每天非常稳定的运行着集团内几十万个任务以及完成每天几亿次的任务调度。
您可以在应用中依赖 SchedulerX-Client，并在 EDAS 控制台创建定时任务，进行相应的参数配置后，启动该应用就可以接收到定时任务的周期调度。SchedulerX-Server 集群为调度触发提供高可用性和高稳定性的保证，并且可以实现对您的客户端机器集群进行分布式调度。

这个思路是没问题的,不过项目建议改名....

[liguobao]

理想的类热加载是直接扔一个Class 文件上去(Job接口的一个实现),然后直接就跑了.
@zhaopeiym

[xb594328980]

@liguobao 热加载这个好这样可以自己写一些业务逻辑。
以前的一个ETL项目就是这样的，支持数据库（sql语句，存储过程）[mssql\oracle\mysql]、自定义插件（热加载）、webservice、rest api等。当然这个注重的是数据采集等，但是前面任务的设置， 楼主可以参考。另外在传递的参数那里，建议可以加一些表达式，比如时间的表达式等，这样触发任务的时候可以按照表达式解析出具体参数然后传参(类似格式{DateTime.Now.ToString("yyyy-MM")}这样)，使调用更加多样化。

[linkinshi]

最好还可以集群分布式调度，hangfire是靠数据库的，job一多，非常容易出现死锁的提示

[DUWENINK]

希望可以加上用户验证,

[withlin]

最近在研究分布式调度，分享一下自己的经验和想法。

在这里首先贴一下google的分布式调度的介绍distributed-periodic-scheduling,
我觉得应该自己去设计一个job系统，可以基于cron这些类库做成分布式的。
先说说前期的我们是怎么做的把?
版本一:
基于cron类库做一些改造，支持分布式的job调度。利用etcd的分布式锁对job抢占。
,而job的执行的方式只支持执行shell的。整体架构就是用的etcd存储要跑的node节点，
然后需要执行的job的等一些主要的元数据，然后日志丢到mongodb去做。这是我们最初的
版本设计。
版本一遇到一些问题:

• 没有对执行器抽象(例如只支持shell)
• 不能选定节点调度(比如我有a,b,c节点进行抢占)
• 多个节点跑job(如果想做成主备的job,由于一些job太快会导致每个节点都在跑)
• 不支持节点自动调度(比如，我有三个节点，a,b,c，和作业j，a的机器资源(cpu,内存)，而job跑的需要更* * 大的资源，我需要把作业j首先放到a节点跑，然后a挂了，自动跑到b或者c跑，然后a起来了，自动跑到a上跑。而不在b和c。)
• 日志有进行抽象，只是存储在mongodb。不可扩展。
• 不支持依赖job(比如有三个job，a,b,c，我需要执行的依赖先等c执行完在再执行a再执行b)

版本二进行了重新设计:

• 架构分成 agent 和manager的设计。manager管理job，下发job 到agent(可以指定)，通信采用的grpc。manager用的etcd做的选举。agent也可以选举。之间成员变更状态同步用的gossip。
• 执行器抽象，做成了插件的机制，但是这个插件也是用的grpc做的同行，agent通过grpc和执行器通信，在manager配置。
• 日志也进行抽象，做成了插件的的形式。同上
• 能选中agent 调度。
• 支持job依赖，本质是agent调度，按顺序维护在内存队列进行依赖调度。就算死了也不怕，启动起来，从etcd加载job有对应的关系。
• 目前还在研究一些算法能动态感知服务的性能，或者用job的执行时间区判断。

以上一些设计和想法，可以和你们多多交流，或者可以分享一下你们的想法。

[jinweijie]

希望可以加上用户验证,

简单的用户验证可以用nginx实现吧。

[LostAsk]

可以考虑下结合 elsa 工作流 实现一个类似 airflow的产品, 实现IJOB基类中 加入个 防止重入的功能

[lic0914]

这是要造个调度中心的轮子吗？xxl-job已经实现了分布式调度中心，但对.Net接入不是很友好。