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

主講人：宜信高階架構師&開發平臺負責人 梁鑫

導讀：如今，無論是網際網路應用還是企業級應用，都充斥著大量的批處理任務，常常需要一些任務排程系統幫助我們解決問題。隨著微服務化架構的逐步演進，單體架構逐漸演變為分散式、微服務架構。

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

影片回放地址：https://v.qq.com/x/page/s0928gbpaqy.html

一、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。

二、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低一點，那如何保證排程負載均衡？如何保證資源隔離的負載均衡？我們會根據這種任務排程的歷史值（任務耗時）以及機器本身效能的值進行考量，使每一個任務排程中心擁有的排程數量差不多、消耗也差不多。這是一種新的負載，而不是簡單的流量負載。

三、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_選取例項策略包括兩種：

• 隨機，從可選的列表中，隨機選擇例項，即IP+埠；
• 固定IP，指定例項，隨後需要從可選列表中人工指定例項。 平臺支援四種Task_呼叫失敗策略：
• STOP，停止策略，呼叫失敗則整個Job停止，不再執行後續Task；
• IGNORE，忽略策略，呼叫失敗則跳過該Task，繼續執行後續Task；  
• TRANSFER，轉移策略，選取該Task的其他例項執行，如果依然失敗，則使用停止策略；  
• MULTI_CALLS_TRANSFER，多次呼叫再轉移策略，重複呼叫該Task多次，如果依然失敗，則使用轉移策略。

3.6 排程日誌

日誌管理提供了Job的執行日誌相關資訊，按專案組分組顯示，一條Job日誌的關鍵元素包含：

• 執行狀態：表示該Job執行結果；
• 執行時間：表示排程器排程Job的時間；
• 執行完成時間：表示Job執行完成的時間；
• 排程資訊：表示執行Job的排程器例項；
• 執行資訊：Job執行的具體資訊，並且已實現Job與所引用的Task的執行日誌資訊的關聯，日誌預設儲存七天。

四、開源

SIA-TASK作為SIA團隊的一個重要產品，在公司接入了數十個專案，執行著數百個Job，經受住了穩定性的考驗。

SIA-TASK微服務排程平臺於5月已經開源，開源地址：，感興趣的同學可以登入檢視詳細介紹。

分享者：梁鑫

來源：宜信技術學院