我们先思考下面几个业务场景的解决方案:
- 财务系统每天生成前一天的报表，每月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，网上相关代码又很多，要学会炒出自己的风格。我的任务执行程序还没有做好，做好后会和大家分享一下设计思路。