效率篇-定時任務管理系統,替代crontab

linux的運維者，逃脫不了定時任務的命題，最常用和快捷簡單的是crontab，在少量機器的情況下，crontab效率還是比較高和比較便捷。但當機器越多、應用越多的情況下，繼續使用crontab進行定時任務的管理配置，那嚴重影響工作效率。

機器多、服務多的情況下，就會遇到以下問題：

1.不知道哪個定時任務沒配置好，瞎跑；

2.運維人員需要登錄服務進行配置和管理；

3.運維人員需要全場參與到定時任務的生命周期；

4.定時任務運行異常告警難以統一對接；

5. 任務A和任務B如果存在互斥關係，crontab就很難進行互斥處理；

6.難於信息管理；運維管理者可能都不知道線上跑了多個定時任務，每個定時任務什麼時候運行，屬於哪個應用和哪個開發負責。

基於這些問題，我們就決定做一個定時任務管理系統。

當我們做完這個系統的時候，在某次運維大會上，發現暴風也存在這樣的系統，有興趣大家可以猛戳http://chuansong.me/n/1940814

實現目標：

1. 信息化管理；

2.開發同事自助管理，無需運維同事進行介入；

3.系統需要有分散式功能和冗餘功能，提供高並發和冗災能力；

4.具有定時任務的執行數據圖表；

5.支持運行失敗告警，同時支持多種類告警（微信、郵件、公司IM通信工具）；

6.與crontab的時間格式需一致，滿足現用戶使用習慣。

7.引入審核流程，開發pm需要審核非pm開發創建的定時任務。

8.遠程應用本地程序運行，需要支持用戶自上傳定時任務代碼包。

9.進行安全性檢測，執行許可權、代碼包風險性檢查、危險行為檢查等。

定時任務對象：

1.web介面模式，該模式只需要進行web調用就能進行定時任務的調動；

2.本地運行模式，有些定時任務需要運行到應用本地，以腳本(shell python java等等)形式存在。

效果：

定時任務列表

自助配置頁

定時任務類型：調用介面（web api調用）；調用腳本（遠程腳本的運行）

依賴任務：本任務運行是否依賴其它任務，如果選擇，本任務則需要在依賴任務運行完後才能運行，如果超出本次運行開始時間則本次不執行。

告警：可以設置檢測到關鍵字才進行告警。

調用腳本：用戶選擇該相則同時需要上傳代碼包。

執行結果列表：

單次執行結果：

整個任務執行數據統計

整體架構

1.用戶web把定時任務信息寫入資料庫中；

2.主控端讀取db中定時任務信息，並進行相應封裝；

3.主控把對應的任務發送到不同的消息隊列中（介面:web api調用;遠程本地:應用伺服器中的常駐內存進程每分鐘進行隊列查詢 ）；

4.web：http調用；遠程：常駐內存程序每分鐘進行隊列查詢，如果存在本應用定時任務則執行。（隊列進行了相關分散式封裝）

6.結果寫入結果隊列（5忘記寫了）;

7.主控端讀取結果隊列數據；

8.主控端進行結果寫入。

主控端邏輯

隊列後端的數據流

隊列：選用httpsqs；

nginx：進行分散式任務分派，使得httpsqs冗餘和協同工作。

總結：

1.系統上存在1k+個定時任務配置。

2.運行了兩年，不怎麼需要人力維護，也和之前提到代碼更新系統一樣處於放養狀態。

3.運維同事已經基本不用介入定時任務的生命周期中，開發同事自助。

4.能快速統計定時任務相關信息，例如：某某12調整，只需一點就能查詢到12點運行的定時任務有哪些。

5.定時任務信息化、實時告警化，相關任務能實時掌握到定時任務的異常情況。

更多內容請關註：輕量運維
推薦閱讀：