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://github.com/wjire/Go.Job.QuartzNET3X
由於日志用的公司自己的,沒去改它,所以下載下來要報錯,手動換一下就可以了