新的一年、旧的方式，这一次就从一个需求开发的角度和大家分享监控系统的开发。
前段时间与大家分享了定时任务调用平台xxl-job，也简单地讲了讲平台的结构模式、调度方法。
【进阶之路】定时任务调用平台xxl-job
调用任务的过程中，如果xxl-job的代码能够顺利执行，但是本身需要执行的任务没有顺利执行成功，或者因为一些问题导致任务延迟执行甚至没有执行，xxl-job并不会正常报错通知。这个时候，我们就需要用一些其他的方法来协助监控定时任务的执行。
在大佬的要求下，我这边设计了一个方案，如图所示：
定时任务监控体系分为三个部分（其实如果将消息中间件换成异步请求也可以，只是在处理任务比较多又比较集中的时候，对监控系统的压力比较大，监控系统本身业务无关，是不应该占用过多的系统资源的）。
执行任务模式，我采用的是桥接模式，将抽象的类与实现类分离，使它们可以独立变化。我们在自己设计的过程中，也可以根据不同的情况采用不同的方法来实现信息推送的功能。
在此模块中，主要目的是要能够准确的获取任务执行情况，然后将任务推送给指定的MQ，内部记录的数据可以根据自己的要求来确定，但是不推荐将那种一天内需要非常多次轮训的任务也进行监控。
定时任务监控系统中，主要需要实现以下几个功能：
1、接受并处理由MQ中分配而来的任务，包括执行失败时进行通知需要通知的人
2、处理在应该收到通知的时没有收到通知的任务
3、根据要求生成需要通知的任务清单，用以判断需要执行的任务是否正确、按时、高效的执行
4、漂亮的展示页面，可以清晰地展示任务是否处理完毕
这一点我主要考虑使用定时任务来解决问题，而且不需要考虑再次监控的问题（不然就无限套娃了）。
生成清单的时候，要考虑不同任务的场景，比如有的任务是一天分批次执行（比如一些批量任务），有的任务是每天执行一次（比如对账任务），还有的任务是几天甚至更长时间才执行一次（比如周的差错）。这个时候，生成任务清单，包括处理任务清单的时候也需要考虑到，这里我就自己的任务给大家分享一下我的任务清单。
众所周知，如果没有一个漂亮并且看让人看一眼就会能完全掌握使用方法的页面，那就代表开发人员需要自己来操作进行模板数据的增减修改，这无疑是很不可取的，所以，一个完善的任务监控系统也需要一个完善的UI控制界面，不仅方便运维人员操作，也可以清晰地展示每个任务的执行情况与执行效率，报警的任务需要负责人员进行处理并手动解除警报，这样，一个土生土长地任务监控系统就完成了。
如果任务量小、且多为单机任务单、亦或是项目中没有消息中间件的话，可以尝试使用http请求（针对非分布式）或者声明式的web service（feign）,这样只需要将监控系统部署在私服中，再引入需要的项目中即可。
在定时任务执行成功之后，开启一个线程来调用就能解决问题。当然，在设计之初我也考虑了这个问题，所以预留了接口有备无患。
因为业务过于耦合的问题，可以考虑使用切面进行开发，不过目前的线上的定时任务并不需要24小时执行，所以我没有选择这个方案（偷懒了），但是在开发前期也在部分接口中使用了切面进行开发。
对比桥接模式，切面的开发方法对于代码的侵入大幅下降，但是代码的复用性会降低，因为针对不同的任务需要考虑不同的执行方案。
同时，因为使用切面难以对复杂的定时任务项目进行开发： 业务并不是二极管，只有成功与失败，还有各种各样的情况，就拿我熟悉的还款计划来说，有计划已经执行，有计划改变，甚至某一条计划出现问题，这些情况一样是执行成功，但是使用切面方法就很难掌握具体情况了。
什么时候需要报警，这是一个问题。
之前在代码中，我设计了以下情况作直接忽略报警，而且都是在实际的生产中遇到的一些需要忽略警情的问题：
I、是否需要操作、是否需要报警为否 。
II、结果已经处理 。
III、已经报警且结果为正常或者过期、同时执行时间不为空
IV、重复报警通知。
大家好，我是练习java两年半时间的南橘，下面是我的微信，需要之前的导图或者想互相交流经验的小伙伴可以一起互相交流哦。 有需要的同学可以加我的公众号，以后的最新的文章第一时间都在里面，也可以找我要思维导图
【进阶之路】任务调度监控开发详解