我們先思考下面幾個業務場景的解決方案:
- 財務系統每天生成前一天的報表，每月1號生成前一個月報表。
- 每天早上六點將公司運營數據報表發送到經理或老板的郵箱。
- 每個一段時間檢測服務器、站點、服務、數據庫等，查看運行及性能是否正常，若不正常郵件報警。
為什么我們需要定時任務
很多業務場景需要我們某一特定的時刻去做某件任務，定時任務解決的就是這種業務場景。一般來說，系統可以使用消息傳遞代替部分定時任務，兩者有很多相似之處，可以相互替換場景。如，上面發貨成功發短信通知客戶的業務場景，我們可以在發貨成功后發送MQ消息到隊列，然后去消費mq消息，發送短信。
但在某些場景下不能互換：
- 時間驅動/事件驅動：內部系統一般可以通過時間來驅動，但涉及到外部系統，則只能使用時間驅動。如怕取外部網站價格，每小時爬一次
- 批量處理/逐條處理：批量處理堆積的數據更加高效，在不需要實時性的情況下比消息中間件更有優勢。而且有的業務邏輯只能批量處理。如移動每個月結算我們的話費
- 實時性/非實時性：消息中間件能夠做到實時處理數據，但是有些情況下並不需要實時，比如：CRM系統客戶評分。
- 系統內部/系統解耦：定時任務調度一般是在系統內部，而消息中間件可用於兩個系統間。
任務調度系統設計圖
業務場景
- 生成報表：這應該是最常見的定時任務了，每天凌晨生成報表，然后將報表（圖表）郵件發送給相關領導，領導每天早上打開自己的郵箱就可以知道公司前一天的運營情況，幫助管理層盡快發現公司問題，提供決策依據。
- 性能監控、心跳檢測：服務器CPU消耗、服務接口運行情況、數據庫性能監控，宕機或性能降低造成系統運行卡頓，及時報警。
- 日志記錄：將日志記錄在Redis中，然后每隔五分鍾批量從Redis中取數據，並將其存儲在Sql Server中，並進行錯誤日志分析及相關的郵件通知。
任務調度中心代碼結構圖
任務調度中心程序結構：
- Sln.TaskSchedule.DispatchCenter為任務調度中心的代碼實現，設計目的是將核心代碼抽離出來，從而可以讓任務調度中心可以輕松的寄宿在MvcApi或者WCF服務上，也可以寄宿在某個exe程序上。
- Sln.TaskSchedule.MvcApi 與 Sln.TaskSchedule.Service 是 任務調度中心的宿主，他為web程序或者exe程序提供服務接口。
- Sln.TaskSchedule.Web 任務調度系統的可視化Web程序
總結
讀者可以參考我的代碼結構自己開發一個任務調度中心的程序，我用的任務調度第三方插件是Quartz.Net，網上相關代碼又很多，要學會炒出自己的風格。我的任務執行程序還沒有做好，做好后會和大家分享一下設計思路。