Error message here!

Hide Error message here!

忘记密码?

Error message here!

请输入正确邮箱

Hide Error message here!

密码丢失?请输入您的电子邮件地址。您将收到一个重设密码链接。

Error message here!

返回登录

Close

Quartz.NET 3.0.7 + MySql 动态调度作业+动态切换版本+多作业引用同一程序集不同版本+持久化+集群(一)

热敷哥 2019-01-26 21:50:00 阅读数:189 评论数:0 点赞数:0 收藏数:0

 

Quartz.NET 3.0.7 + MySql 动态调度作业+动态切换版本+多作业引用同一程序集不同版本+持久化+集群(二)

Quartz.NET 3.0.7 + MySql 动态调度作业+动态切换版本+多作业引用同一程序集不同版本+持久化+集群(三)

Quartz.NET 3.0.7 + MySql 动态调度作业+动态切换版本+多作业引用同一程序集不同版本+持久化+集群(四)

 

 

前端时间,接到任务,写了一个调度框架.今天决定把心路历程记录在这里.做个纪念.也方便提供给我这样的新手朋友,避免大家踩同样的坑.

在生活中,"经验教训"常常一起出现,但在如今的快餐年代,太多人往往只关注经验,希望可以一步登天.

在巨人的肩膀上固然可以看得更高,更远,但任何事物都应该辩证的看.

经验固然可以让人走捷径,

但教训可以让人少走弯路.

希望这篇"心路历程"能让大家有所收获,也希望各位前辈留下宝贵意见.

需求

拆分需求

在博客园看了几篇 Quartz.NET 的入门贴后,对该框架有了一个大致的了解.接下来就开始设计了.

正所谓路要一步一步走,饭要一口一口吃.

于是,我将需求划分成如下几个功能点和需要解决的问题:

1.利用反射动态创建Job;

2.调度服务如何知道有新的任务来了?是调度服务轮询数据库?还是管理后台通知调度服务?又或者远程代理?

3.需要一个管理后台,提供启动,暂停,恢复,停止等功能;

4.至于集群,Quartz.NET 本身就提供该功能,只不过要使用它的持久化方案而已.这个点只需要在配置文件上做做手脚就可以了,并不需要怎么开发.

5.管理后台如何实现启动,暂停,恢复,停止等功能?靠远程代理?还是通过其他方式?

开始干

要想通过 dll 方式灵活添加必然要用到反射.这点毋庸置疑.

Quartz.NET 创建一个Job的核心代码如下:

 IJobDetail jobDetail = JobBuilder.Create(typeof(Job)).Build()

同时,Job 类需要实现 IJob 接口,实现Execute() 方法.(关于 Quartz.NET 的基础知识本篇就不介绍了,博客园有很多前辈写了很多好文章)

那么,我只要能拿到 Type 不就完事儿了么?

这不 so easy.... 么

有新的调度任务了,就新建一个类库,Nuget 安装 Quartz.NET ,然后新建类,实现IJob接口,实现 Execute() 方法,调度服务里面反射加载程序集,拿到 type ,完事儿...

于是乎,我提笔就干,写下了如下代码:

 Assembly assembly = Assembly.LoadFile("程序集物理路径");
Type type = assembly.GetType("类型完全限定名");

至于调度服务怎么知道有新的调度任务来了,这个属于管理后台如何与调度服务通信的问题,这个问题不是当前需要解决的,暂时放一边,后面再考虑.

上面代码写完后,测试了下,没问题,运行正常.

但是,问题来了.

1.我这个调度任务要切换版本怎么办?

2.我好几个调度任务引用了同一个程序集的不同版本怎么办?

3.我这个调度任务里面要用自己的配置文件怎么办?

如果有朋友没有理解到上面这3个问题,我再举例说明一下:

第一个问题:

现在有两个调度任务

1. 类库项目 TestJob1.dll  ,定义了一个类型: Job1 ,其完全限定名为 TestJob1.Job1

2. 类库项目 TestJob2.dll  ,定义了一个类型: Job2 ,其完全限定名为 TestJob2.Job2

现在调度服务已经运行起来了,我通过某种方式通知到调度服务,并且已经成功反射加载了上述两个程序集.

如果这时候, TestJob1.dll 需要更新.怎么办?直接覆盖?不行的,会提示你:

 

"把调度服务关了,再覆盖"

这个可以有...

但是,我这个调度服务还管理者 Job2 ...实际工作中,可能有更多.为了更新某一个调度任务的版本就关闭整个调度服务,让所有的调度任务都停摆?Boss会砍死你的.

"我的调度任务都是每天凌晨运行,白天关一下没问题".------ What are you talking about ?

第二个问题:

同样以 TestJob1.dll 和 TestJob2.dll 举例.

假如这两个调度任务都引用了同一个程序集 Tools.dll ,但是版本不一样.TestJob1.dll 引用 Tools.dll  v1.0.0.0 ,TestJob2.dll 引用的是 v1.0.0.1

那么如果反射加载 TestJob1.dll 和 TestJob2.dll 的时候到底会加载哪个版本的 Tools.dll 呢?

谁先加载,就会加载谁引用的版本.

比如,如果先反射加载了TestJob1.dll ,那么会加载Tools.dll v1.0.0.0 .这时候再反射加载 TestJob2.dll 时,不会再加载 Tools.dll 了.

我曾奢望用什么骚操作能加载同一个程序集的不同版本,或者说更新到高版本也行;最终以失败而告终.

所以,如果TestJob2.dll 用到了 v1.0.0.1 里面的新方法,那么很遗憾,调度服务运行时会报错,大概提示是:"未在程序集 Tools.dll v1.0.0.0 中找到方法 ......."

第三个问题:

依然以 TestJob1.dll 为例.

我在该类库项目中,新建应用程序配置文件:

<configuration>
<appSettings>
<add key="name" value="释放自我"/>
</appSettings>
</configuration>
 public class Job1
{
public string Name = System.Configuration.ConfigurationManager.AppSettings["name"];
}

大家觉得反射后,创建的 Job1 的实例能拿到"释放自我"么?肯定是拿不到了啦...除非你把配置写在 调度服务 的配置文件中..但是不可能我每加一个调度任务,都去调度服务的配置文件中添加配置吧..而且还有可能重名.当然,你要用File读取,当我没说...

那么,能不能在程序集用的时候加载它,用完就卸载.再用的时候再引用呢?

这时候,我想到<CLR via C#  第4版>这本书提到过:

"程序集加载后不能卸载,只能通过卸载 AppDomain 来卸载程序集".

于是乎,我翻开 <CLR via C#  第4版> ,依葫芦画瓢,天真而充满自信的写出如下代码:    

TestJob1.dll :

 public class Job1 : MarshalByRefObject, IJob
{ public Task Execute(IJobExecutionContext context)
{
Console.WriteLine("我不会写PPT,只会干活");
return Task.FromResult(0);
}
}

 

TestConsole.exe (调度服务):

 string assemblyPath = @"H:\0开发项目\Go.Job.QuartzNET\TestJob1\bin\1\TestJob1.dll";
AppDomainSetup setup = new AppDomainSetup();
setup.ShadowCopyFiles = "true";//这句话非常重要,核心中的核心,没有它,就算跨域也没有价值.这句代码的效果是:你看到的程序集并不是正在用的程序集.用的是 它们的 Shadow.
setup.ApplicationBase = System.IO.Path.GetDirectoryName(assemblyPath); 
 AppDomain appDomain = AppDomain.CreateDomain("newDomain", null, setup);
object job = appDomain.CreateInstanceFromAndUnwrap(assemblyPath, "TestJob1.Job1");
Type type = job.GetType();
IScheduler scheduler = StdSchedulerFactory.GetDefaultScheduler().Result;
scheduler.Start();
IJobDetail jobDetail = JobBuilder.Create(type).WithIdentity("job1", "job1").Build();
ITrigger trigger = TriggerBuilder.Create()
.WithIdentity("trigger1", "trigger1")
.WithSimpleSchedule(s => s.WithIntervalInSeconds(3)
.RepeatForever()).StartNow()
.Build();
scheduler.ScheduleJob(jobDetail, trigger);

结果运行报错,错在这一行: 

 

注意看 type ,是 MarshalByRefObject 类型.这类型,让 Quartz.NET 怎么创建 JobDetail...

于是,我又稍微改了改,让 调度服务 添加 TestJob1.dll 的引用

同时,跨域按"引用"封送过来后,强转为 Job1:

运行,没毛病...

修改一下Job1,复制一下,看会不会报错,居然OK了,没有像上面提到的第一个问题那样,报下面这个错误.

这意味这代码可以在不关闭 调度服务的情况切换版本了...

但是仔细一想,不对啊! 调度服务运行起来后,我怎么添加引用......再说了,我怎么知道要转成哪个 Job 类型?

这时候,一句名言涌上心头:

凡是能用技术问题解决的问题,都可以通过包一层来解决.

于是乎我改了一下代码:

新建了一个BaseJob类库,通过 Nuget 安装 Quartz.NET

三个类库的引用关系为:

TestConsole(调度服务)引用 BaseJob,两者都需要安装 Quartz.NET

TestJob1 引用 BaseJob.

TestConsole 没有引用 TestJob1

 

 public abstract class BaseJob : MarshalByRefObject, IJob
{
public Task Execute(IJobExecutionContext context)
{
Run();
return Task.FromResult(0);
}
protected abstract void Run();
}

 

 public class Job1 : BaseJob.BaseJob
{
protected override void Run()
{
Console.WriteLine("版本1");
}
}

调度服务中,跨域按"引用"封送后强转成 BaseJob 

 

运行一下,看看效果: 

肯定是扯蛋的嘛!

调度服务都没有引用 TestJob1 怎么可能拿得到 Job1 的 Type,拿到的 Type 只会是 BaseJob

什么?关闭调度服务,把 TestJob1.dll copy到 调度服务的运行目录下.嗯,这个方法能解决问题.

但是,我想说一句:

"what are you talking about"

我彻底懵逼了......

长时间的挣扎后,终于,在博客园找到一位大神2年前的一篇文章:https://www.cnblogs.com/zhuzhiyuan/p/6180870.html

当时看了不到几行,"作业管理(运行)池" 几个字简直让我醍醐灌顶!!!

至于后面的故事,大家可以看大神的文章了......

不过我这里还是继续写,算是对自己开发过程的一个总结.

要用"池"的概念,就必须提到Quartz.NET 框架的两个知识点:

为了更好的理解,我们先新建一个 JobCenter , 它是整个调度器执行Job的唯一入口,是也我这个框架用的到类:

 public class JobCenter: IJob
{
public async Task Execute(IJobExecutionContext context)
{ 
 //在Job池中,找到当前 JobCenter 对象的逻辑Job
//执行逻辑Job
await Task.FromResult(0);
}
}

第一个知识点:

我们在创建一个JobDetail 的时候,需要通过 WithIdentity 方法注册"名称"和"分组",如:

 IJobDetail jobDetail = JobBuilder.Create<JobCenter>()
.WithIdentity("测试名称","测试组")
.Build();

这段代码并没有真正的创建一个 JobCenter 的实例.而只是注册了"身份"而已.

真正创建 JobCenter 的实例是在每次触发器触发的时候.

也就是说,触发器每次触发时,都会创建一个 JobCenter 的实例!!!这点很重要!!

所以,并不是说定义了一个 JobCenter 类型,那它就是一个 JobDetail 了.

Job 和 JobDetail 的关系 == 类型 和 类型实例 的关系

JobDetail 的身份信息 == 类型的构造函数的两个入参.

大家完全可以这样理解:

就当下面的红色代码被"某种"神秘力量隐藏了,每次创建一个 JobCenter 的实例时,都将注册的身份信息:"测试名称"和"测试组"传给了构造函数.

 public class JobCenter : IJob
{
private readonly string _name;
private readonly string _group;
public JobCenter(string name, string group)
{
_name = name;
_group = group;
}
public async Task Execute(IJobExecutionContext context)
{
//在Job池中,找到当前 JobCenter 对象的逻辑Job
//执行逻辑Job
await Task.FromResult(0); } }

第二个知识点:

我们创建一个 JobDetail 的时候,是可以通过 SetJobData(...) 方法来保存数据的,比如红色部分:

 var data = new Dictionary<string, object>()
{
["jobInfo"] = new JobInfo()//JobInfo 这个类后面会讲到 };
IJobDetail jobDetail = JobBuilder.Create<JobCenter>()
 .WithIdentity("测试名称","测试组")
 .SetJobData(new JobDataMap(data))
.Build();

这两个知识点 + 作业池+跨 AppDomain 按"引用"封送就构成了整个框架的核心.

由于定义了一个JobCenter,并且用到了池,所以 BaseJob 也不需要继承 IJob 了:

 /// <summary>
/// 逻辑Job基类
/// </summary>
public abstract class BaseJob : MarshalByRefObject
{ /// <summary>
/// 具体逻辑
/// </summary>
protected abstract void Execute();
/// <summary>
/// 将对象生存期更改为永久,因为CLR默认5分钟内没有通过代理发出调用,对象会实效,下次垃圾回收会释放它的内存.
/// </summary>
/// <returns></returns>
public override object InitializeLifetimeService()
{
return null;
}
}

核心伪代码:

 //定义一个Job池.
//在创建 jobDetail 前,先创建逻辑job,即通过跨域按"引用"封送,拿到逻辑job的代理对象的引用.
//然后在创建 jobDetail 的时候,将该 jobDetail 的信息 jobInfo 存入 JobDataMap 永久保存起来.
//同时,将该 jobDetail 执行时所要正真调用的 逻辑job(也就是 BaseJob 的子类)信息存入 job 池. //trigger 触发时, //从该 jobDetail 保存的数据中取出 jobInfo //根据 jobInfo 从 job 池中查找 对应的 逻辑job. //调用 逻辑job 的 Execute()方法执行具体逻辑. 再简单讲就是,触发器触发一个作业时,作业先去作业池找到属于它自己的逻辑作业,然后再执行逻辑作业.

这里提前讲一点:

作业池是在内存中,如果宕机是会丢失的;

而 JobDetail 和 Trigger 的数据都是在数据库中,不会丢失.(框架采用了官方的持久化方案).

所以需要写代码来处理这种意外情况.

终于...上面提到的3个问题被完全解决了...万里长征终于迈出了第一步!!!

 

版权声明
本文为[热敷哥]所创,转载请带上原文链接,感谢
https://www.cnblogs.com/refuge/p/10324578.html

编程之旅,人生之路,不止于编程,还有诗和远方。
阅代码原理,看框架知识,学企业实践;
赏诗词,读日记,踏人生之路,观世界之行;

支付宝红包,每日可领