摘要：動態腳本支持框架之結構設計篇相關博文動態腳本支持框架整體介紹篇動態腳本支持框架之使用介紹篇前面兩篇博文，主要是整體介紹和如何使用接下來開始進入正題，逐步剖析，這個項目是怎么一步一步搭建起來的本篇博文則主要介紹基本骨架的設計，圍繞項目

相關博文:

180702-QuickTask動態腳本支持框架整體介紹篇

180719-Quick-Task 動態腳本支持框架之使用介紹篇

前面兩篇博文，主要是整體介紹和如何使用；接下來開始進入正題，逐步剖析，這個項目是怎么一步一步搭建起來的；本篇博文則主要介紹基本骨架的設計，圍繞項目的核心點，實現一個基礎的原型系統

整體設計圖如下：

對于上面的圖，得有一個基本的認知，最好是能在腦海中構想出整個框架運行的方式，在正式開始之前，先簡單的過一下這張結構圖

抓要點

即圖中的每個task就表示一個基本的任務，有下面幾個要求

統一的繼承關系（面向對象的設計理念，執行同一個角色的類由某個抽象的接口繼承而來）

任務的執行之間是沒有關系的（即任務在獨立的線程中調度執行）

在圖中表現很明顯了，在內存中會保存一個當前所有執行的任務隊列（或者其他的容器）

這個的目的是什么？

任務腳本更新時，需要卸載舊的任務（因此可以從隊列中找到舊的任務，并停掉）

任務腳本刪除時，需要卸載舊的任務

雖然圖中并沒有明確的說有這么個東西，但也好理解，我們的系統設計目標就是支持多任務的執行和熱加載，那么肯定有個任務管理的角色，來處理這些事情

其要做的事情就一個任務熱加載

包括動態腳本更新，刪除，新增的事件監聽

實現卸載內存中舊的任務并加載執行新的任務

這個與核心功能關系不大，可以先不care，簡單說一下就是為task提供更好的使用的公共類

這里不詳細展開，后面再說

有了上面的簡單認知之后，開始進入正題，編碼環節，省略掉創建工程等步驟，第一步就是設計Task的API

抽象公共的任務接口，從任務的標識區分，和業務調度執行，很容易寫出下面的實現

public interface ITask {
    /**
     * 默認將task的類名作為唯一標識
     *
     * @return
     */
    default String name() {
        return this.getClass().getName();
    }

    /**
     * 開始執行任務
     */
    void run();

    /**
     * 任務中斷
     */
    default void interrupt() {}
}

前面兩個好理解，中斷這個接口的目的何在？主要是出于任務結束時的收尾操作，特別是在使用到流等操作時，有這么個回調就比較好了

任務裝飾類，為什么有這么個東西？出于什么考慮的？

從上面可以知道，所有的任務最終都是在獨立的線程中調度執行，那么我們自己實現的Task肯定都是會封裝到線程中的，在Java中可以怎么起一個線程執行呢？

一個順其自然的想法就是包裝一下ITask接口，讓它集成自Thread，然后就可以簡單的直接將任務丟到線程池中即可

@Slf4j
public class ScriptTaskDecorate extends Thread {
    private ITask task;

    public ScriptTaskDecorate(ITask task) {
        this.task = task;
        setName(task.name());
    }

    @Override
    public void run() {
        try {
            task.run();
        } catch (Exception e) {
            log.error("script task run error! task: {}", task.name());
        }
    }

    @Override
    public void interrupt() {
        task.interrupt();
    }
}

說明：

上面這個并不是必須的，你也完全可以自己在線程池調度Task任務時，進行硬編碼風格的封裝調用，完全沒有問題（只是代碼將不太好看而已）

上面兩個是具體的任務相關定義接口，接下來就是維護這些任務的容器了，最簡單的就是用一個Map來保存，uuid到task的映射關系，然后再需要卸載/更新任務時，停掉舊的，添加新的任務，對應的實現也比較簡單

public class TaskContainer {
    /**
     * key: com.git.hui.task.api.ITask#name()
     */
    private static Map taskCache = new ConcurrentHashMap<>();

    /**
     * key: absolute script path
     *
     * for task to delete
     */
    private static Map pathCache = new ConcurrentHashMap<>();

    public static void registerTask(String path, ScriptTaskDecorate task) {
        ScriptTaskDecorate origin = taskCache.get(task.getName());
        if (origin != null) {
            origin.interrupt();
        }
        taskCache.put(task.getName(), task);
        pathCache.put(path, task);
        AsynTaskManager.addTask(task);
    }

    public static void removeTask(String path) {
        ScriptTaskDecorate task = pathCache.get(path);
        if (task != null) {
            task.interrupt();
            taskCache.remove(task.getName());
            pathCache.remove(path);
        }
    }
}

說明

為什么有兩個map，一個唯一標識name為key，一個是task的全路徑為key？

刪除任務時，是直接刪除文件，所以需要維護一個pathCache

維護name的映射，主要是基于任務的唯一標識出發的，后續可能借此做一些擴展（比如任務和任務之間的關聯等）

前面介紹了任務的定義和裝載任務的容器，接下來可以想到的就是如何發現任務并注冊了，這一塊這里不要詳細展開，后面另起一篇詳解；主要說一下思路

在設計之初，就決定任務采用Groovy腳本來實現熱加載，所以有兩個很容易想到的功能點

監聽Groovy腳本的變動（新增，更新，刪除），對應的類為 TaskChangeWatcher

加載Groovy腳本到內存，并執行，對應的類為 GroovyCompile

有了上面四個是否可以搭建一個原型框架呢？

答案是可以的，整個框架的運行過程

程序啟動，注冊Groovy腳本變動監聽器

加載groovy腳本，注冊到TaskContainer

將groovy腳本丟到線程池中調度執行

執行完畢后，清除和回收現場

當然其他一些輔助的工具類可有可無了，當然從使用的角度出發，有很多東西還是很有必要的，如

通用的日志輸出組件（特別是日志輸出，收集，檢索，經典的ELK場景）

報警相關組件

監控相關

redis緩存工具類

dao工具類

mq消費工具類

http工具類

其他

博文：

180628-動態任務執行框架想法篇

180702-QuickTask動態腳本支持框架整體介紹篇

項目：

https://github.com/liuyueyi/quick-task

一灰灰的個人博客，記錄所有學習和工作中的博文，歡迎大家前去逛逛

盡信書則不如，已上內容，純屬一家之言，因個人能力有限，難免有疏漏和錯誤之處，如發現bug或者有更好的建議，歡迎批評指正，不吝感激

微博地址: 小灰灰Blog

QQ： 一灰灰/3302797840