- 兼容性好，需要定时的任务只依赖于控制台命令，能在命令行中执行的程序都可以执行。意味着可以定时执行包括exe在内的，python，nodejs，甚至matlab等程序
- 扩展性强，目前可以直接通过对数据库的操作来修改各个任务的具体情况，并且提供了webapi
- EntityFramework 用于从数据库读取任务
- Microsoft.AspNet.WebApi.SelfHost （已弃用） 用于提供数据接口
- Quartz 定时任务
- Topshelf 用于编写易于调试易于安装的windows服务
- csredis 用于查询任务的执行状态
- helpRun 执行器 用来作为各种程序的中间层，为了解决被调用程序的日志，耗时等功能而存在的。使用执行器模式以后， 相较于原来。执行各种程序更加灵活，可配置。获取程序状态和日志更加方便
- helpRunTest 执行器的测试
- TimeSystem 主体的定时系统。移除了初始版本的webapi，所有交互通过redis来完成。并且添加了对sqlserver的数据监听 一旦数据库有数据变动，自动更新定时任务
- TimeSystemManageWeb 管理网站很久没有弄啦，这个慢慢来
这些扩展功能绝大部分会以新的定时执行程序形式添加进系统，非常灵活。
- 关键指标检测，定时检查关键指标，若异常则可以使用报警模块
- 报警模块，接受消息，给配置用户报警，暂定使用邮件，也可以用短信等第三方
- 垃圾清理，定时清理redis里的日志型数据
- 自动化部署
- 队列执行，对定时任务有顺序要求的情况
- 新增加了监工模块，用于检测系统指标，业务指标等是否正常。
- 需求上来说，逻辑会特别灵活，所以采用灵活一点的JavaScript来做
- 只需要在rules文件夹中放入检测规则代码就可以每次执行的时候自动检测对应指标啦
- 不过现在异步什么的还有问题，用promise可以解决，但今天我不想写了哈哈哈哈😄
- 重做了邮件模块，但现在有个问题就是如果发送邮件的时候出错会导致pop出的数据就没有了。 用专门的消息队列会好一点，但是如果用redis现在还没有想清楚有没有什么好的解决方案
这是我在看开源服务框架之前所写的内容，未必正确，只是记录当时的看法，欢迎指正
核心的定时框架是使用topshelf和quartz来做的一个windows服务，在做初版的时候，定时和执行还是在一起的，但是在一起有这样几个问题。
- 程序调试非常艰难，问题多出在执行程序时，任务出错或是命令不对等等，暂时还没有遇到topshelf和quartz不稳定的情况。比如最早遇到的调用python程序失败，可以在调试环境运行，但是一旦安装到了windows服务，就执行失败，实在是百思不得其解。当然其实问题也很简单，python这个命令只被安装到里系统的用户路径里，没有按照在系统路径，这就导致以用户身份使用调试项目时能成功，但是安装以后确失败，结合在一起很难调试
- 被调用程序有许多限制，为了能够获取到被调用程序的状态，执行周期等这些信息，在老版本中是需要在被调用程序中额外写的，这无疑增大了工作量，使用一个执行器，就可以在调用程序时就可以监控被调用程序的状态。当然如果说状态这类信息需求如果变化不大，执行器倒确实可以做在核心定时服务里，但是为了能够适应需求，还是拆开吧。等需求稳定了再改进去不迟。
完全就是一拍脑袋设计出来的，没有过多的思考，最近看了一点这方面的书。在下一个版本中会规划存储的设计问题
最开始采用到nodejs的时候是觉得，监视的规则会非常杂，监视的内容也会非常灵活，所以采用了js这样较为灵活的语言。但是在写示例监控关键指标的时候遇到了一些问题，例如如果每个指标的检测周期不同怎么办，像垃圾清理预警这种可能一周都用不到一次 和其他的高频的一起执行，效率可能会有点低。所以这就意味着需要不同的检测规则配备不同的执行周期，这又回到里整个系统最核心的那个定时系统的地方，就目前而言，我觉得每单独有一个新的需要监测的规则 就作为一个新的程序运行在定时系统里，就目前而言是开发效率比较高的//毕竟一个总体的检测模块个人感觉也没有少多少事情。