宜信微服務任務調度平臺建設實踐|分享實錄

時間 2019-11-07

原文原文鏈接

導讀：現在，不管是互聯網應用仍是企業級應用，都充斥着大量的批處理任務，經常須要一些任務調度系統幫助咱們解決問題。隨着微服務化架構的逐步演進，單體架構逐漸演變爲分佈式、微服務架構。git

在此背景下，不少以前的任務調度平臺已經不能知足業務系統的需求，因而出現了一些基於分佈式的任務調度平臺。這些平臺各有其特色，但也各有不足之處，好比不支持任務編排、與業務高耦合、不支持跨平臺等問題，不是很是符合公司的需求，所以咱們開發了微服務任務調度平臺（SIA-TASK）。本次分享主要圍繞SIA平臺展開，包括研發背景設計思路和技術架構，以及如何支持業務方。github

內容來源：宜信技術學院第4期技術沙龍-線上直播|宜信微服務任務調度平臺建設實踐網絡

主講人：宜信高級架構師開發平臺負責人梁鑫多線程

1、SIA-TASK的產生

1.1 背景

不管是互聯網應用仍是企業級應用，都充斥着大量的批處理任務，經常須要一些任務調度系統幫助咱們解決問題。隨着微服務化架構的逐步演進，單體架構逐漸演變爲分佈式、微服務架構。架構

在這樣的背景下，不少以前的任務調度平臺或組件已經不能知足業務系統的需求，因而出現了一些基於分佈式的任務調度平臺。這些平臺各有其特色，但也各有不足之處，好比不支持任務編排、與業務高耦合、不支持跨平臺等問題。併發

1.2 種類

按照任務與時間的關係，咱們把批處理任務分紅三類，飛機型、地鐵型、公共汽車型。負載均衡

飛機型是指每一年/月/周/天固定某一時刻執行的任務。這種任務在咱們的業務系統中很是常見，好比天天1點要執行一個跑批任務去清理前一天的日誌；每個月10號要給公司全員發工資，這些都屬於飛機型任務。
地鐵型是指每隔固定時間執行任務，不可併發。咱們也常常遇到這樣的批處理任務，第一個任務沒有結束，第二個任務是不能夠執行的，這就是不可併發。
公共汽車型是指每隔固定時間執行任務，可併發。若是是公共汽車型的任務，前一個任務沒有結束，下一個任務也能夠按點開始執行。

1.3 問題

在跑批任務的過程當中會遇到如下問題：框架

遺忘，忘記了還在運行的定時任務。在咱們公司發生過一個這樣的案例，若干年前的一個冬天，咱們的一個項目團隊用3個月的時間作了一個項目，運行一段時間後發現項目的效果並非很理想，便將相關的程序都停掉了，卻忘了有一個跑批任務的節點還在繼續運行，直到兩年後，這個節點產生的日誌把磁盤填滿了，觸發了監控報警，咱們才發現。
單點，就是沒有熱備，跑批任務是一個單點運行的定時任務，出了故障須要轉入手工處理。
依賴，利用時間差來處理依賴反覆形成問題數據。你們知道項目有的時候是須要有依賴關係的。好比某個項目的跑批流程A和跑批流程B存在前後次序，項目組設置跑批流程A在凌晨2點運行，跑批流程B在凌晨4點運行，從時間上保證前後次序，萬一跑批流程A執行時間過長，超過2小時，就會致使數據出現問題，須要手工處理出現問題的數據。

1.4 關係

前文提到任務之間是有關係的，那到底存在哪些關係呢？我認爲主要有如下3種：運維

串行，存在前後關係的兩個任務。即任務B在任務A後執行，要先執行任務A以後再執行任務B。
並行，能夠併發執行的兩個任務。好比任務B和C都要在任務A以後執行，而任務A執行完成後，任務B和C能夠同時執行，那B和C就是並行關係。
分支，根據前置任務的返回結果進行判斷，不一樣的結果執行不一樣的後續任務。好比返回0的時候，執行任務A，返回1的時候執行任務B，這是一種分支的狀況。

1.5 思考

基於上述的幾種關係，咱們在建設任務調度平臺的時候會思考如下兩個方面：異步

平臺化。項目團隊老是但願把更多的精力投入到業務開發中，但願把其它與業務開發無關的事情儘量地放到架構團隊。他們但願有一個執行任務的平臺，僅僅須要把編寫好的業務邏輯放到這個平臺就能夠了，這個平臺會完成全部的工做，項目組只須要關心業務邏輯。
微服務。爲了更好地知足項目的需求，咱們但願能把任務的業務邏輯和任務的編排調度區隔開來，採用註冊和發現機制來建設任務調度平臺，與業務相關的部分交給項目團隊處理，把其餘的部分交給任務平臺來處理。

1.6 因素

除了上述兩個方面的考慮之外，咱們還須要思考如下八個因素。

任務編排。多個業務之間的定時任務存在流程次序，前面提到任務之間有並行的關係、有串行的關係，還有分支的關係，咱們但願平臺能有相應的編排功能去處理和支持這些任務。
任務分片。對於一個大型任務，須要分片並行執行。
跨平臺。除了使用 Java 技術棧（SpringBoot、Spring等）的項目以外，還要可以支持使用其餘語言的應用。
無侵入。業務不但願與調度高耦合，只關注業務的執行邏輯，但願平臺對業務自己代碼是無侵入的，將影響降到最低。
高可用/故障轉移。調度系統自身必須保證高可用，不能有單點，任務執行過程當中遇到問題有補償措施，可以平滑處理，減小人工介入。
可視化。任務調度的操做提供可視化頁面，方便使用。
實時監控。平臺要有實時監控系統，實時獲取任務的執行狀態。
動態編輯。業務的任務時鐘參數可能變更，在可視化的基礎上，對全部任務執行的操做都實時反映到業務系統中去，不須要停機部署。

基於以上的背景與考慮，咱們建設了微服務任務調度平臺SIA-Task。

2、SIA-TASK的核心設計思想

2.1 簡介

SIA是「Simple is Awesome」的簡稱。

SIA-TASK（微服務任務調度平臺）是其中的一項重要產品，SIA-Task契合當前微服務架構模式，具備跨平臺、可編排、高可用、無侵入、一致性、異步並行、動態擴展、實時監控等特色。

SIA-TASK是任務調度的一體式解決方案，對任務進行元數據採集，而後進行任務可視化編排，最終進行任務調度，而且對任務採起全流程監控，簡單易用。對業務徹底無侵入，經過簡單靈活的配置便可生成符合預期的任務調度模型。

SIA-TASK借鑑微服務的設計思想，獲取分佈在每一個任務執行器上的任務元數據，上傳到任務註冊中心。利用在線方式進行任務編排，可動態修改任務時鐘，採用HTTP做爲任務調度協議，統一使用JSON數據格式，由調度中心進行時鐘解析，執行任務流程，進行任務通知。

2.2 術語

簡單介紹一下SIA-TASK的術語。

任務（Task）: 基本執行單元，執行器對外暴露的一個HTTP調用接口;
做業（Job）: 由一個或者多個存在相互邏輯關係（串行/並行）的任務組成，任務調度中心調度的最小單位;
計劃（Plan）: 由若干個順序執行的做業組成，每一個做業都有本身的執行週期，計劃沒有執行週期;
任務調度中心（Scheduler）: 根據每一個的做業的執行週期進行調度，即按照計劃、做業、任務的邏輯進行HTTP請求，它是一個單獨的節點；
任務編排中心（Config）: 編排中心使用任務來建立計劃和做業;
任務執行器（Executer）: 接收HTTP請求進行業務邏輯的執行;
Hunter：Spring項目擴展包，負責執行器中的任務抓取，上傳註冊中心，業務可依賴該組件進行Task編寫。

Job、Task、Plan的關係

Task是業務執行的基本單元，執行器對外暴露的一個HTTP調用接口。若干個Task構成一個Job，而Plan是由若干個順序執行的Job構成。

爲何這裏須要一個Plan？有的時候兩個任務不光有順序關係（就是A任務執行完以後再執行B任務），還須要知足必定的時間要求，好比上午10點執行任務A，下午2點執行任務B，並且必須保證上午10點任務A按時執行完成。

打個比方，今晚8點有一場足球比賽的直播，若是晚上8點我還不能到家，那我就沒辦法看直播，而若是今天我下班早，下午6點多就到家，也必須等到8點才能開始看球賽，這就是Plan計劃的來源。

2.3 組成

SIA-TASK任務調度平臺有如下幾個部分組成：

任務執行器，就是你的業務代碼在哪裏，這是屬於項目組的。
任務註冊中心，咱們用的是ZooKeeper。
任務編排中心
持久存儲，咱們用的是MySQL。
任務調度中心

2.4 運行

接下來詳細介紹SIA-TASK的運行邏輯。

首先，經過註解抓取任務執行器中的任務上報到任務註冊中心。任務執行器在啓動的時候，會有一個叫online Task的註解，只要把這個註解放到control代碼的方法上，就會自動把HTTP接口抓取出來，而後上報到任務註冊中心，這裏咱們用的是ZooKeeper。

任務編排中心從任務註冊中心獲取數據進行編排保存入持久化存儲。也就是說，至關於在執行器裏，把業務調用HTTP接口請求的URL地址、端口等實例抓取出來上傳到ZooKeeper裏，ZooKeeper就拿到了一個個的任務，ZooKeeper會把任務自己的信息抓取出來放到MySQL裏。

這裏要區別一下什麼是任務，什麼是任務實例。任務實例和任務的關係，有點像類和對象的關係，就是一份業務邏輯代碼可能部署在多個節點上，也就是說這些節點的業務邏輯代碼是如出一轍的，在運行階段抓取的時候會把每一個節點上業務邏輯代碼都抓取上來，針對這個業務它就是一個任務，可是每個端口、每一個IP地址對應的可能就是一個任務實例。好比高可用熱備時，咱們會把任務自己的信息通過處理以後保存到持久存儲裏，而實例自己的信息只會停留在ZooKeeper裏。

任務配置中心能夠根據ZooKeeper裏的信息和MySQL裏的信息進行配置，就是根據抓取的任務，給這些Task加時鐘、策略，而後編排出Job和Plan，並把如今的這些信息保存到MySQL裏。

任務調度中心從持久化存儲獲取調度信息，知道編排的Job、Plan、時鐘、策略等邏輯，任務調度中心按照調度邏輯訪問任務執行器，對這些從執行器上抓取來的Task進行調度。

這就是SIA-TASK的運行邏輯，同時咱們會把調度日誌存到Kafka裏。

2.5 特性

1）基於註解自動抓取任務

在暴露成HTTP服務的方法上加入@OnlineTask註解，@OnlineTask會自動抓取方法所在的IP地址、端口、請求路徑、請求方法、請求參數格式等信息上傳到任務註冊中心(zookeeper)，並同步把任務信息寫入持久化存儲中。

2）基於註解無侵入多線程控制

單一任務實例必須保持單線程運行，任務調度框架自動攔截@OnlineTask註解進行單線程運行控制，保持在一個任務運行時不會被再次調度。並且整個控制過程對開發者徹底無感知。

就是在一個任務實例上，要保證任務在運行的時候是單線程狀態。其實這是由用戶本身控制的，若是須要是單線程的，這裏能夠加以控制；若是須要是多線程的，能夠不加控制。這個控制並不須要另加代碼，只須要在註解上去處理。

3）高度靈活任務編排模式

SIA-TASK的設計思想是以任務爲原子，把多個任務按照執行的關係組合起來造成一個做業（Job）。同時運行時分爲任務調度中心和任務編排中心，使得做業的調度和做業的編排分隔開來，互不影響。在咱們須要調整做業的流程時，只須要在編排中心進行處理便可。同時編排中心支持任務按照串行、並行、分支等方式組織關係。在相同任務不一樣任務實例時，也支持多種調度方式進行處理，並且整個的處理編排都是在頁面上完成的，這個功能很是好用，這也是SIA-TASK平臺的一個亮點。

4）調度器自適應任務分配

任務執行過程當中出現失敗、異常時，能夠根據任務定製的策略進行多點從新喚醒任務，保證任務的不間斷執行。咱們設定了不少策略，好比某個Task出現問題了怎麼辦？是再喚醒一次？仍是無論了？仍是人工干預發警報？咱們定製了不少策略去處理這些問題。

2.6 關鍵點

瞭解了平臺特性，咱們來梳理SIA-TASK的技術關鍵點。

任務流。實現任務與任務之間可配置的流向關係，造成有向無環圖(DAG)。任務流可由定時時間(Cron 表達式)或外部請求(提供 API 地址) 開始，根據 DAG 邏輯執行。
元數據管理。微服務中各個任務元數據的管理同步數據抓取、錄入。
智能運維。可視化的任務實時監控，全部監控都是有頁面能夠看到的；實時預警機制，出現問題的時候，會發送郵件或短信給相關人員告警；半智能化的自主修復，嗅探重試，不須要人工干預。
資源隔離。進程間的資源隔離；進程內的資源隔離，提升系統吞吐，提供穩定性。時鐘用的是Core Schedule，一個調度中心對一個項目組用一個Core Schedule，每一個項目組在同一個調度的時候，同一個調度器上都是隔離的，一個項目組出問題，不會影響到其餘的項目組，這就至關於表明了隔離性負載均衡。
負載均衡。調度中心調度任務的時候，任務的執行週期時間不同，可能有的任務須要的時間長一點，有的任務須要的時間短一點，調度器的資源也不太同樣，有的CPU高一點，有的CPU低一點，那如何保證調度負載均衡？如何保證資源隔離的負載均衡？咱們會根據這種任務調度的歷史值（任務耗時）以及機器自己性能的值進行考量，使每個任務調度中心擁有的調度數量差很少、消耗也差很少。這是一種新的負載，而不是簡單的流量負載。

3、SIA-TASK組成模塊

3.1 首頁

任務調度管理首頁主要包括三部分：調度器信息、調度次數、對接項目詳情。

調度器信息：調度中心調度器的數量。
調度次數：調度中心調度Job的歷史累計總數。
對接項目詳情：調度中心對接的項目組總數，Job總數。

目前SIA-Task平臺上已經接入了51個項目，上面跑的Job數有600多個，今年上線的版本，Job已經跑了3000多萬次。

調度器上有幾個值須要瞭解一下，每臺調度器都有三個指標。

Job上限值：所能負載的Job動態閾值;
Job運行數量：該調度器當前運行的Job數量；
Job預警值：當調度器運行的Job數超過預警值時，會發郵件通知管理員。

3.2 調度器管理

關於調度器有幾個信息須要瞭解，如圖所示，點擊某個調度器(柱狀圖),會顯示該調度器所搶佔的Job詳情列表：

JobKey：所配置的Job名稱，每一個Job都有本身的名字。
類型：配置Job的定時任務類型，分爲Cron與fixRate兩類。
Job類型值：若是是Cron表達式，6位時間戳怎麼寫；若是是fixRate，那就是須要間隔多少時間。
預警郵箱：該Job配置的預警郵箱。
描述信息：描述該Job的功能信息，便於管理員可以迅速發現某臺調度器所搶佔的Job詳情。

調度器包括工做調度器、下線調度器、離線調度器、白名單。

工做調度器：這類調度器具備搶佔和調度Job的能力。對某調度器進行下線操做，它會當即失去搶佔Job的能力，已經搶佔的Job執行完畢後會自動釋放，進而被其餘調度器搶佔，調度器下線後會進入下線調度器列表中；工做調度器列表提供下線以及批量下線的功能。簡單來講，工做調度器就是正在工做中的調度器。
下線調度器：這類調度器進程仍然存活，但失去了搶佔Job與參與調度的能力。對這類調度器執行上線操做，會進入工做調度器列表，且開始具備搶佔和調度Job的能力；下線調度器列表提供上線及批量上線的功能。就是說，下線調度器依然活着，只是再也不參與搶佔Job，以前已經有的Job仍是會繼續執行完成，若是點擊上線就從新具有搶佔Job的能力，變成工做調度器。
離線調度器：這類調度器進程再也不存活，當下線調度器進程死亡後，會自動進入離線調度器列表，這類調度器進程從新啓動後，會自動進入下線調度器列表；離線調度器列表也提供刪除及批量刪除的功能。離線調度器通常都是出現問題了，多是進程掛掉了，也多是網絡故障了。
白名單：將某個IP加入白名單以後，它具備調用全部執行器實例的權限；白名單列表提供批量刪除的功能，刪除該IP後自動失去該權限。

3.3 調度監控

上圖所示是SIA-TASK的調度監控頁面，分着的一塊一塊區域屬於不一樣項目組。目前SIA-Task接入了51個項目，準備中的有500多個，正在運行的有25個。

有的Job執行很是快，幾秒鐘就執行完了，有的Job執行很是慢，須要很長的時間，咱們在狀態抓取的時候，只能抓取到時間長的Job，這些被抓取的Job顯示爲正在運行，而時間短的捕捉不到，但它們都處於執行狀態，這些沒有被抓取到的Job就顯示爲準備中。

可能有的Job這段時間不須要運行，能夠手動中止，剩下的就是異常中止的Job，須要發送郵件告警。

咱們也提供了檢索的能力，能夠接受不一樣項目組登陸查詢本身的項目運行狀態。

3.4 Task管理

Task管理界面中，Task按項目組分組顯示，主要提供Task的配置、修改與刪除等功能。Task包含兩部分：一部分Task使用了sia-Task-hunter組件，經過標準註解實現Task的自動抓取，這類Task不容許修改；另一部分Task是由用戶手動添加的，我知道訪問的URL和HTTP地址，手動添加進來，這部分Task支持跨平臺的抓取，並且能夠修改和刪除。

一個Task管理包含如下幾個部份內容：項目名稱、應用名稱、任務名稱、機器地址、描述、以及查看/修改/連通性測試等操做。同一個Task名稱，不一樣的機器地址，表明一個任務和不一樣的任務實例。

3.5 Job管理

前面介紹了一個Job由若干個Task組成，圖中每個不一樣的列表明項目名稱，點擊下拉列表能夠顯示全部的項目，能夠進行過濾、添加、狀態查看等操做。

其中狀態操做能夠手工執行，能夠中止或激活Job，Job配置好以後屬於未激活的狀態，須要激活一下。還能夠修改Job裏的信息，配置Job等。如何添加Job？假如我要添加一個Cron表達式類型的Job，須要添加哪些內容呢？

由於Job是Cron表達式類型的，首先我須要輸入六位表達式內容，還要添加一個預警郵箱，再描述這個Job，每一個Job都有一個key，最後還須要添加Job_key。這樣一個新的Job就添加好了。

回過頭來看，添加Job須要配置Task信息，這是一個比較複雜的過程。一個Job由若干個Task組成，咱們能夠用拖拉拽的方式根據Task之間的關係肯定造成組成Job的全部Task的順序關係。還能夠以不一樣顏色表明不一樣項目進行區分，固然只有管理員纔有權限看到全部項目，各個項目的負責人只能看到本身所屬項目的狀態。

上傳Task的時候會帶一些參數，因此還涉及到參數的處理，好比參數類型、參數值、過時時間等。重點聊聊過時時間。

經過HTTP方式調用會遇到一個問題：到底Task什麼時間會執行完成。爲解決這個問題，就須要設一個Task的過時時間，只要過時時間一到，就會轉入其餘策略，好比放棄或人工處理等。由於做爲異步調用，不可能無休止地等待客戶端返回結果。

固然也可能存在一種狀況：我獲得的結果是超時了，實際上任務是在正確執行，並且再過一段時間給我返回結果了。咱們曾經設計了一種隊列補償機制來處理這個問題，可是好像意義不大。固然，這只是一種可能，平臺上線至今沒有出現過。

目前平臺的Task_選取實例策略包括兩種：