1.緒言
在上一篇文章《蘇寧大數據離線任務開發調度平臺實踐—任務調度模塊(上篇)》中，主要介紹了調度模塊的架構設計、服務管理、重啓恢復服務和web服務的設計細節，限於篇幅問題，今天我們接着詳細闡述任務調度模塊的核心服務—任務調度服務的設計以及開發實踐過程中的關鍵功能點。
2.任務調度服務
主要負責上線任務流的配置檢查、生成任務流執行計劃、按照執行計劃生成任務流與任務實例，生成任務實例狀態機和節點之間的依賴觸發關係。除了這些系統調用主要功能外，還提供人工干預任務執行的服務功能，比如：任務流上下線、任務補數據、任務重跑、任務殺死、失敗重試等。
2.1任務流上線
任務流上線是啓動任務調度執行的第一步，上線不是單純的修改任務流的數據庫狀態，涉及到以下幾個關鍵步驟：
(1) 從數據庫中獲取上線任務流的配置信息：任務流、任務、事件以及節點之間的依賴關係等元數據信息
(2) 檢查任務流的配置是否符合平臺規範
(3) 檢查跨流依賴(事件依賴)是否符合平臺的頻率依賴規則
(4) 建立任務節點的上下依賴關係的DAG圖
(5) 生成任務流的執行計劃
(6) 更新數據庫上線狀態，緩存任務流、任務等元數據信息
(7) 觸發任務實例運行
(8) 對外發布任務實例的狀態（創建狀態）
大體處理流程如下圖所示。
2.1.1 創建任務節點之間的依賴關係
沒有采用複雜的數據結構，基於任務實體對象增加前置任務列表、後置任務列表、前置事件列表。
這種簡單的數據結構開發方便，便於理解，也能滿足調度依賴關係的查找。缺點是無法對循環依賴進行檢查校驗，當出現閉環依賴的時候，整個任務流的調度會出現死循環。目前我們是在前端頁面配置任務流的時候，做閉環檢查。當然也可以參考AirFlow的DAG圖做有向無環圖的數據結構，後期我們也會往這方面進行改造。
2.1.2 創建任務流的執行計劃
基於Quartz做了單機版的任務執行計劃，Quartz集羣在我們平臺不適用，這裏只是藉助Quartz的多線程計劃執行能力，同時也能很好的擴展支持Crontab時間表達式，做到時間調度的靈活性。
2.1.3 補償丟失的任務流實例
任務流上線後，調度計劃只會往前計算，對於一些調度週期較長的任務，比如幾小時、天、周、月的任務，錯過執行計劃可能需要等很長時間才能進行下一次調度執行。對於這種長週期任務，需要在任務流上線後進行一次補償操作。
2.1.4 創建任務(流)實例
到了調度計劃時間的時候，任務流實例和任務實例都是同時生成。平臺限制每個任務流、每個任務 相同數據時間 的實例個數只能有一個。當然這個僅限於未執行結束的任務(流)實例，執行結束後可以再重新生成。
任務(流)實例的概念可以理解爲根據任務(流)的配置信息，在調度執行計劃開始的時候按照配置信息和處理的數據時間生成的執行個體。這個個體除了具備任務的基本屬性外，還有其他額外重要的幾點屬性。
任務流實例的主要屬性有：任務流實體、數據時間、調度方式、運行狀態、創建時間、更新時間。
任務實例的主要屬性有：任務實體、任務流實體、數據時間、調度方式、運行狀態、創建時間、待調度時間、待分配時間、已分配時間、已領取時間、執行開始時間、執行結束時間、更新時間。
這裏需要注意的是，任務如果配置了任務事件（關於任務事件的說明，在上一篇文章中已經闡述過，在此省略），每次任務實例生成的時候，要刪除同一數據時間的事件實例，否則會出現當前批次的任務還沒執行結束（因爲剛生成），而依賴該任務事件的其他任務流的任務已經可以執行，調度上是矛盾的，業務上也是不允許的。
任務實例具備多種狀態，在每次狀態切換都可能伴隨着一定的業務處理邏輯。比如前置節點執行成功，需要通知下游節點去做流控檢查、分配機器執行等；當任務由已分配到待分配狀態變更，需要增加流控計數器等。如何管理這些狀態的變更帶來的多種業務處理，我們引入“狀態機”的概念，類似Yarn裏的狀態機原理來解決這個問題。
伴隨着任務實例的生成，任務實例的狀態機也同時跟着生成，狀態機與具體的任務實例綁定，不是一個任務實體一個狀態機。爲了有效的處理節點之間依賴關係的流轉，狀態機之間的依賴關係需要參考任務的依賴關係進行設定。
2.1.5 數據時間的說明
離線計算平臺的數據處理具有延遲性，因爲處理的數據量比較大，實時性要求不是太高。一般是今天處理昨天的數據，這個小時處理上個小時的數據。任務調度又具備週期性，每次的調度的執行時間都不一樣，不能要求業務代碼每次調度都要修改，因此需要提供一種時間變量，便於業務邏輯隨着調度時間的變更而變更。我們提供了${statis_date}的時間變量，這個變量的數值對於每個調度頻率都有一定的計算規則。
2.2任務流下線
任務流下線主要是停止任務的調度執行計劃。關鍵的第一步是要終止Quartz的Job執行，防止繼續產生新的實例。然後是對 “未結束”（待調度、待分配、已分配、已領取、
執行中）的任務實例進行殺死操作，最後更新數據庫的下線狀態以及一些緩存操作和計數器。主要的操作流程如下圖所示。
對於下線是否需要殺死還沒結束的任務實例，可以根據具體業務場景考慮。有的下線操作只是停止調度計劃的執行，不再生產新的任務實例，對於執行中和未執行的任務實例保持繼續執行，尤其是執行中的任務實例，強制殺死可能導致任務終止而產生髒數據。有的場景就是要終止任務的執行。
2.3 任務狀態機
任務實例具備多種狀態，在每次狀態切換都可能伴隨着一定的業務處理邏輯。比如前置節點執行成功，需要通知下游節點去做流控檢查、分配機器執行等；當任務由已分配到待分配狀態變更，需要增加流控計數器等。如何管理這些狀態的變更帶來的多種業務處理，我們引入“狀態機”的概念，類似Yarn裏的狀態機原理來解決這個問題。
狀態機由一組狀態組成，這些狀態分爲三類：初始狀態、中間狀態和最終狀態。
關於Yarn的狀態機的機制和原理，在這裏不再詳細闡述，有興趣的同學可以自己查閱相關資料。
2.3.1 狀態機管理服務
狀態機不是一個服務，外部服務組件要觸發任務實例狀態機進行工作，需要對外提供統一的狀態機管理服務—JobInstanceManager。其主要結構和內部工作原理如下圖所示。
針對不同的頻率我們設置了不同的處理線程，防止線程不足導致待處理的Event（事件）堆積。分鐘頻率的任務實時性要求比較高，和其他頻率類型的處理線程分開。外部服務組件要觸發狀態機的運轉只要傳遞任務實例編碼（JobInstanceCode），狀態機管理服務根據任務實例編碼找到對應的實例狀態機，根據Event狀態觸發狀態機執行相應的Transition執行具體的業務邏輯。
各個服務與JobInstanceManager的處理交互邏輯入下圖所示。
2.3.2 狀態機的各狀態切換處理設計
系統調用（按照調度計劃每次精準的生成任務實例）、任務補數據或者對任務重跑都會導致任務實例的生成和實例狀態機的生成。實例生成以後，任務實例的生命週期由“新建”到“執行中”再到最後的“執行結束”，每次狀態的切換都需要任務實例狀態機管理（JobInstanceManager）進行驅動各個狀態的切換變化。
檢查前置節點狀態Transition
這裏主要是檢查當前任務的前置節點的狀態，如果前置節點是任務節點，前置任務實例的狀態必須是執行成功狀態，否則當前任務節點會一直掛起，處於待調度狀態。如果前置節點是事件節點，需要根據任務實例生成初期的事件實例生成計劃，來判斷所有計劃內的事件實例是否都已經觸發（或者理解爲都已經存在），有一個事件實例沒觸發，當前節點都會掛起。
關於事件實例執行計劃，我們舉個例子說明一下。比如 天任務依賴一個前置任務事件，該前置事件是另外一個小時的任務生成的。按照計劃，天依賴小時是需要小時的任務00點到23點的批次要全部存在，如果有一個不存在，則當前任務不能執行。這裏的事件實例計劃就是：00點批次、01點批次、02點批次……23點批次。
前置節點沒有執行成功會導致下游節點一直掛起，如果掛起原因不給用戶提示，用戶很難判斷是什麼原因導致的，尤其是在前置節點特別多的情況下，用戶排查原因很困難。因此在這裏需要將後臺的判斷原因展示給用戶。
任務執行結束處理Transition
任務執行結束(殺死、失敗、成功)後，當前任務實例的生命週期就結束了。
其他狀態處理Transition
待分配到已分配的狀態變換，取決於任務分配服務的處理，關於任務實例如何被分配到具體worker,已領取到執行中的狀態變換比較簡單，主要是將任務實例狀態進行更新，轉移已分配隊列，已領取隊裏的實例信息，並進行任務狀態發佈。
3.後續
調度服務是整個調度模塊非常核心的服務組件，除了前文所述的幾點外，任務補數據、任務重跑也是非常核心的功能。限於篇幅和時間問題，本次的調度模塊的分享先寫這麼多，後續會陸續對其他服務組件進行詳細闡述，敬請期待。
整個調度模塊的框架設計經過2年的上線運行，調度性能和執行能力的可擴展性已經得到充分的驗證。上述的設計和實踐經驗完全基於蘇寧大數據離線ETL和任務的開發實際情況，在某些設計上有些場景定製化的地方。如果要做成完全通用化的開發調度平臺還有一段路要走。
作者簡介
桑強，蘇寧易購IT總部大數據平臺研發中心離線計算工具研發部經理。10年軟件行業從業背景，13年開始接觸大數據，有着5年多的大數據應用和平臺開發經驗。現在負責蘇寧大數據基礎工具平臺的研發工作，主要包括離線計算工具、實時計算工具、數據資產與質量平臺的架構、研發和項目管理等工作。在對接大數據底層和大數據業務線之間，如何做好平臺工具化，降低用戶使用難度，支撐大數據應用的實踐和研發上有着豐富的研發經驗。