序
由于公司老项目的重构，希望对定时任务这一大块也进行一番“修整”，但是又不想用开源的分布式定时任务框架（因为公司对于自己的所有系统都有一个配置中心工程，领导希望将定时任务的功能嵌入到这个工程）。
于是就需要自己写一套定时任务的增删改查页面。实现定时任务的动态的增删改。
故此有了此篇文章。
我的思路
springboot的定时任务虽然没有动态新增修改开启关闭的功能，但是它的模板给的很好，值得我们去学习一下它的实现原理，看是否能做相应修改实现我们想要的功能。于是我带着这样的想法阅读了springboot定时任务的源码，也确实深受启发。
springboot是如何实现定时任务的？
大白话
springboot扫描spring中所有的bean如果对象的方法上有@Scheduled的注解，则拉取注解中的时间相关信息，将bean以及方法分装成runnable对象，将时间信息以及runnable对象放入ScheduledThreadPoolExecutor任务线程池中，时间一到则执行任务（反射实现）。
源码解析
一切的入口@EnableScheduling注解。
每个spring容器中的bean对象初始化后都要做一波检测是否方法有@Scheduled注解。
开始封装方法对象以及执行的时间，注册到ScheduledTaskRegistrar。
@Scheduled注解里面定时任务种类很多，这里主要以分析cron表达式做列子分析。
ScheduledAnnotationBeanPostProcessor 实现类spring监听器接口，在容器初始化后调用相关方法结束注册。
在finishRegistration方法中调用taskRegister的afterPropertiesSet
再次走到scheduleCronTask方法
再次封装runnable对象并且放入定时任务线程池
总结
其实说来也简单，主要是Doug Lea大神的定时任务线程池太好用了，基础思想全来自于此。
spring就是利用反射执行相关任务，cronTrigger计算下次执行时间。基于此目的做了一套自己的东西。
执行定时任务以后再次计算下次的执行时间再放入定时任务线程池即可。
这样站在spring和Doug Lea巨人的肩膀上做三次开发就显得简单了很多。
我的实现
1.spring容器启动后，抓取数据库相关定时任务信息（主要有类名、方法名、cron表达式），封装成runnable，同样通过反射实现。一套东西都可以复用spring容器的东西（本人亲测可行）。
2.当需要修改定时任务的时间时，根据类名+方法名删除对应的定时任务，新增新的定时任务即可。
3.利用aop记录相关定时任务信息，例如：执行结果，执行时间，错误原因等等。
这里只是大致的思路，具体的细节本文暂不讨论。
其他思考
架构的相关思考
写这个组件的时候我思考了两种实现。
1.类似于xxl-job的实现，配置中心工程类似于一个触发器，定时任务池在配置中心中，执行时间一到则调取相应的服务利用反射执行定时任务。
2.定时任务池仍在各自的项目之中，配置中心只做开启关闭修改的接口调用。
各自的优劣：
第一种方式的实现明显更加简单，且不消耗各自项目的线程池资源，只做触发器。但如果配置中心服务挂了则所有项目的定时任务也就挂了。所以不得不做配置中心的集群，如果配置中心做了集群，那又需要考虑很多东西，如：如何保证修改定时任务打到集群的各个节点。。。
第二种方式则更加消耗资源，每个项目都要有定时任务线程池。且在集群情况下依旧要考虑很多问题，比如：集群下保证定时任务只执行一次，配置中心开启关闭修改定时任务，如何打到集群的各个节点。。。
集群模式下的相关思考
不管是第一种还是第二种方式其实都是要考虑集群问题的。但是考虑的侧重点不同。
第一种考虑的是配置中心的集群问题。第二种则是考虑各个项目服务的集群问题。
在微服务的整体架构之下其实都是可以获取对应服务各个节点的ip端口，但是如何实现可靠的修改则需要好好思考了，本文并不讨论。
还有就是服务的各个节点如何只执行一次定时任务，分布式锁是个不错的选择。
尾
非常感谢读到这里的jym，文中若有错误，请不吝赐教！非常感谢！
如需具体实现细节，可联系本人讨论。