摘要：任務退出碼任務正常退出批跑模塊會接受到為，因為異常退出會接收到。主要注意的檢查項為連接未關閉等。每次任務退出后，批跑系統會檢測其是否為空，不為空則移動到目錄目錄下，并以版本號為文件夾存儲，以方便備份查看。

隨著node的出現與發展，前端承擔了越來越多的職責。

前端也有越來越多的場景需要使用批跑腳本

利用爬蟲或者接口定時同步數據到DB

線上配置文件、數據文件定時批跑生成并發布到線上

切實的影響到業務，因此需要一套高可靠與及時告警的批跑管理系統。

本文將批跑管理的系統封裝為一個npm模塊，可以方便使用，并且提供一套簡單的web管理系統進行管理。

1.安裝

npm install schedule_task_monitor --save

gihub鏈接 https://github.com/WilsonLiu9...

2.引入模塊并輸入參數

// init.js
var { run, eventEmitter, app } = require("sche_task_monitor");
run({
    mysql_config: { // mysql連接配置
        host: "localhost",
        port: "3306",
        user: "root",
        password: "1234",
        database: "db_lct_schedule", // 請先建立該數據庫
    },
    task_root_path: "/data/web/schedule/task/", // 任務腳本的根路徑
    defaultRtx: "wilsonsliu" // 告警默認傳送對象
});
// 啟動
node init.js

3.啟動web管理系統

web系統在8017端口打開: http://127.0.0.1:8017

node  ./node_mudule/sche_task_monitor/webSystem/app.js

4.新建任務文件

任務名稱為test，此時需要可在/data/web/schedule/task/新建一個test目錄，并新建/data/web/schedule/task/test/index.js;

var fs = require("fs-extra");
var path = require("path");
console.log("測試啦")
fs.writeFileSync(path.join(__dirname,"publish","a.txt"),"sdsds")

5.web系統新增任務
在web系統新增任務，例如如下配置

{
    task_name: "test",
    rule: "*/30 * * * * *",
    rtx_list: "wilsonliuxyz@gmail.com;test@qq.com", // 告警時的相關責任人
    title: "測試",
    description: "測試描述" 
}

此時，批跑管理系統將按照設定的任務規則運行，每15S進行一次。

模塊對外暴露了eventEmitter，可以通過監聽task_start,task_end,notify事件來執行用戶相應的代碼。

  eventEmitter.on("task_start", function ({ task_name, task_version }) {});
  // 任務結束
  eventEmitter.on("task_end", function ({ task_name, exit_code, task_version, error_log_list }) {});
  // 監聽告警
  eventEmitter.on("notify", function ({ title, content, task_name,notify_list }) {});
}

通過監聽notify事件來實現自己的告警。用戶可以自行選擇自己方便的方式，最好能夠通過多類方式進行告警。例如微信，郵件，郵箱等等。達到高時效

notify如果沒有task_name,那么notify_list，則使用初始化傳入的defaultRtx進行。

對于任務中生成的文件，規范放在對應的任務publish目錄。實現自己的發布函數，在任務中進行調用。

任務正常退出 批跑模塊 會接受到 exit_code 為0，因為異常退出會接收到 1。當退出碼為非0值時，將觸發告警。用戶可以通過process.exit(101)，來觸發告警

task_name唯一，且可以寫為monitor/logline的方式，則執行路徑變為monitor/logline/index.js。即入口文件為拼接的方式可多層級。不建議過深，不方便管理與查看。

對于非node的批跑腳本，我們可以在入口文件中對其他腳本再次進行調用的方式進行既可以。

說到批跑，第一個想到的肯定是利用linux自帶的crontab來完成定時批跑這一目的。
但依賴這種方式這樣存在以下問題，

每個任務都需要自行去crontab去新增一條規則，久而久之難以維護

任務執行的各種告警實現困難，漏執行，超時，異常退出等等

作為一個前端，當然是能夠用JS實現的就全部就JS(node)來實現。

node本身有豐富的npm模塊，node-schedule便是一個定時任務模塊，有4300+的star。
你可以像crontab一樣，編輯定時的rule，在rule指定的時間，會執行相應的回調函數。

通過表t_task_list來進行管理任務，主要錄入每個任務的rule、timeout、last_start_time、last_end_time、last_warning_time來實現任務的管理

通過批跑系統統一對任務管理與監控，以便對各種任務進行告警

批跑系統的目的是為了管理所有的批跑任務，并且對批跑任務進行監控。
同時，因為是會直接影響到線上的系統，所以在穩定性方面有高要求。

高穩定性

弱侵入性(盡量減少批跑系統對相應任務的侵入)

便利的基礎設施服務

定時運行

各種異常情形下進行告警

日志輸出

版本備份

任務執行數據入庫與統計

task的入口腳本統一放在task目錄進行管理，而每個任務的關鍵信息task_name、rule等具體信息則錄入表t_task_list，進行管理。

以下示例中task_name為gold，則批跑系統去數據庫中找到task_name=gold這一條記錄并按照，對應的rule進行掛在定時器，gold/index.js則為對應的任務入口文件，系統通過node task/gold/index.js執行特定任務。

src
├── index.js // 入口文件
├── lib
│   ├── execTask.js // 執行具體某個任務的代碼
│   ├── hook.js // 開始與結束任務的鉤子函數
│   ├── initDB.js // 初始化DB
│   └── monitorHelper.js // 5個監控小助手
├── webSystem // GUI的批跑管理系統
├── task // 指定該目錄為任務根目錄
|   └── gold // 具體某一個定時任務
|         └── index.js // 某一個任務的入口文件
|         └—— logs // 本任務留下的日志文件
│              └── 201711 // 某個月
│                  ├── 23_213854.log // 按照 day_HHmmss構建目錄存放歷史版本
|         └—— publish // 每次任務發布的文件夾，發布到線上需要手動調用發布函數，任務退出后批跑系統會自動將本目錄下的文件備份到history目錄
|         └—— history // 目錄下文件按照 gold_profit.201711231015.json 即 name + time(精確到分鐘) + 尾綴的形式保存
│              └── 201711 // 某一月份的歷史發布文件
│                  ├── 23_213854 // 按照 day_HHmmss構建目錄存放歷史版本
│                  │   ├── currentYearPrice.json

模塊化、簡單化。通過批跑系統模塊化，并保證每個模塊代碼精簡與健壯，以此來提高批跑系統的穩定性。

批跑系統與任務隔離。批跑系統通過child_process.spawn子進程來運行任務，以保證批跑系統與具體任務之間進行隔離，任務的異常不會導致批跑系統的崩潰。

兜底，pm2管理。任何系統都難以避免掛掉，如果系統掛掉則通過PM2自動重啟任務。

通過利用child_process.spawn的方式執行任務，規定task/task_name/index.js為任務的入口文件，相當于node task/task_name/index.js。

優點：

批跑腳本任務代碼無需做任何改造，可以選擇自己喜歡的方式去編寫代碼。

非通過require的方式進行引入，每次任務更新時不需要重啟批跑系統，只需要部署自己的任務的代碼文件即可

需要注意的2點

任務不可以一直掛起，任務執行完成需退出。主要注意的檢查項為mysql連接未關閉等。

批跑系統通過監聽任務子進程的close事件，來了解任務是否執行完成。當exit_code為非0值時，批跑系統將進行告警(關于process.exit可以閱讀文末的參考鏈接3)

未catch住的異常導致的退出將會吐出exit_code=1，catch住異常后，可通過process.exit(exit_code)來指定自己定義的exit_code(100以內為批跑系統保留狀態碼)

子任務正常執行會吐出0

利用開源的node-schedule模塊，該模塊可完成類似crontab的功能，并且支持crontab的語法規則。主要用到scheduleJob這個接口進行定時任務掛載。

系統啟動時，去數據庫的t_task_list將所有任務的task_name、rule數據取出，并遍歷進行掛載。同時，掛載后的句柄存儲在全局對象G_task_schedule_list。

    const schedule = require("node-schedule");
    // 全局保存任務定時器的句柄 G_task_schedule_list
    G_task_schedule_list[task_name] = schedule.scheduleJob(rule, function () {
      // 回調函數中執行具體的任務
      execTask(task_name, app);
    });

在以下5種情況時，對任務相關責任人進行告警。

任務執行超時告警(t_task_list表中每個任務可指定超時時間為多少秒timeout)

exit_code非0，即異常退出

漏執行告警(cron-parser解析rule得到上次應該運行時間，通過與任務的last_start_time比較確定是否漏執行)

數據庫中任務被刪除通知(通過將目前掛載的任務G_task_schedule_list與數據庫中任務進行比對，發現是否有任務被刪除)

批跑模塊內部異常

父進程通過監聽子進程的stdout,stderr兩個輸出流，得到子進程的日志輸出。

日志將會存放在task/logs/YYYYMM/DD/HHmmss.log目錄下，按照任務執行的時間存放，同時將stderr的信息入庫(為保護批跑系統，做限制，只錄入前100條)，用以在UI界面展示與告警時輸出。用戶如果需要詳細的日志還是需要查閱日志文件。

stderr可以通過console.error輸出，另外如果進程異常退出也會輸出到stderr，建議在catch住異常后通過console.error進行輸出。

每次任務執行的時候，可以將文件寫入到對應任務的的publish目錄，如果需要發布上線可以手動調用Helper中的發布函數，針對目前部分強耦合于其他系統中的發布功能，可以以接口的形式批跑調用，并在接口中返回發布的內容，任務再將其寫入publish目錄以進行版本的備份。

每次任務退出后，批跑系統會檢測其publish是否為空，不為空則移動到history目錄目錄下，并以版本號為文件夾存儲，以方便備份查看。

批跑系統掛載一個每3S執行一次的監控小助手，達到準實時監控的效果。

小助手1：已存在的任務：數據庫更新rule，cancel定時任務 并設置掛載新規則的定時任務；新增任務：按照rule進行掛載

小助手2：用戶設置task_status為2，則殺死當前進程

小助手3：根據數據庫中的timeout字段，進行超時提醒

小助手4：任務漏執行，告警通知

小助手5：任務在數據庫中被刪除告警用戶

hook.js包含startExecTask, endExecTask兩個函數在任務開始結束時運行。

startExecTask 執行如下動作

置空任務的發布文件夾 task/task_name/publish

更新任務表中的last_start_time,task_version(任務的版本號根據運行時間生成const task_version = moment().format("YYYYMM/DD/HHmmss");)

插入一條任務執行記錄到t_task_exec_list

endExecTask執行如下動作

設置退出的事件與退出碼

版本備份 ：備份本次執行的發布文件夾task/task_name/publish到task/task_name/history/task_version

更新任務運行記錄(包括錄入logs、發布的文件路徑數組)

批跑系統作為一個基礎設施與其他系統最大的不同在于需要高穩定性且需要準確的監控告警以避免任務出現各種情況導致線上問題，卻后知后覺。

本系統的設計基本滿足了設計目標，同時提供一套便于管理的web系統，可以方便的進行任務的管理，與歷史執行情況的查看。

node-schedule

解析crontab的rule規則 cron-parser

process對象與exit_code