新的一年、舊的方式，這一次就從一個需求開發的角度和大家分享監控系統的開發。
前段時間與大家分享了定時任務調用平台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兩年半時間的南橘，下面是我的微信，需要之前的導圖或者想互相交流經驗的小夥伴可以一起互相交流哦。 有需要的同學可以加我的公衆号，以後的最新的文章第一時間都在裡面，也可以找我要思維導圖
【進階之路】任務排程監控開發詳解