一. AntScheduler 2.0 背景

在上一篇 「AntScheduler 1.0之消息時代」 已經介紹過消息任務的一些缺點：

基於消息異步模式，結果無感知，給運維帶來困難。
無漏觸發重試等功能
無法支持路由策略，這塊主動權交給 msgbroker 處理。
不能提供人工干預操作，如暫停、恢復、取消等。
三層分發無流控功能
功能單一

雖然存在以上缺點，但螞蟻主站長期以這種模式運行基本也滿足訴求，也有個別業務在三層分發框架上做了改造提供限流能力。因此這些也不是 2.0 誕生的主要原因。螞蟻三大戰略包括科技賦能，雲上也需要提供調度產品賦能外部用戶，同時當時存在多個版本的調度平臺(主站版本、獨佔版本、中樞臺版本等) 也希望有一套產品能夠統一所有版本。任務調度2.0 AntScheduler 就是在這個背景下誕生，肩負內外融合、功能豐富、雲上建設等使命下破土而出。

二. AntScheduler 2.0 的功能和介紹

相對 1.0， 2.0 提供了更加強大、豐富的功能，同時兼容老版本消息任務。 AntScheduler 2.0 主要是以RPC調度為主體，提供了多種類型的任務，包括消息任務(兼容老平臺)、簡單任務、集群任務、拓撲編排。RPC 調度指的是原來通過 MSG 通道下發調度指令給客戶端，改成了服務端直接通過 RPC 方式調用客戶端。

RPC的任務對每次調度落庫、對結果感知，因此可以提供更強的可視化管理能力，支持豐富的人工干預操作：暫停、恢復、取消、限流等。

簡單任務
簡單RPC任務就是提供最基本的 RPC 調度功能，每次調度按路由策略只調度一臺業務客戶端。
為了提供並行處理能力還提供了分片能力，及一次調度可以按分片次數調度多次，並攜帶分片id。
對結果感知，可以進行人工干預、路由選擇、漏觸發補償等。
支持自定義參數

執行狀態管理：

客戶端管理：

集群任務
集群任務和三層分發一樣，都是為了解決單點運行瓶頸，充分利用集群資源，提高任務處理性能和效率。 集群任務與三層分發類似，提供了： 拆分層和執行層。 與三層分發不同，集群任務的加載層是在執行層內，集群任務將執行階段分為 read/process/write 三個階段，提供了流控、人工干預等功能。

所以不能完整的將三層分發的每一層一一對應到集群任務這邊的每一層，這樣會導致 load 出來數據都導出一個 分片，落庫到antscheduler，間接將業務的數據落到調度平臺，導致存儲瓶頸。

提供了豐富的控制檯管理功能，分片結果感知和展示等。 具體詳情使用：

Http 任務
考慮主站語言多樣性，提供了 http 觸發任務，解決異構問題。

任務編排
主站很多定時任務之間是有依賴關係，一個任務的執行依賴某個特定任務的結果。任務調度 2.0 提供了強大的任務編排能力，提供了多種網關節點如：條件網關、並行網關、分片網關、跨zone 網關等。可以有效幫助業務組織整個任務編排。同時還提供了豐富的人工干預功能，如重試、暫停、取消、加鎖、重置等。

三. 架構及原理

介紹完AntScheduler 2.0 的主要功能以後，本部分主要介紹 AntScheduler 的架構和原理。

3.1 整體架構

任務調度核心採用 Quartz 實現定時調度，quartz 根據cron 表達式觸發，根據任務類型選擇不同的 執行器和通訊方式。 最後將觸發時間下發到業務客戶端。

單機模式處理的任務數量有限，同時難以應對容災問題。任務調度分佈式模式有利於提高容災能力、提升任務管理數量。 antscheduler 在分佈式模式下，選舉master 來管理集群任務的分配調度，做到一個任務有且只被一臺機器調度執行。 master 的作用是合理均衡地將任務分配到各個機器上去執行和調度，並監控各slave 狀態負責集群間的容災機制。一旦某個 slave 宕機則將該機器上的任務分配給其他正常的機器去管理和調度。

考慮 LDC 架構，及控制zone 級別的容災能力。 任務調度系統以zone為單位，構建一個zone維度的集群。 客戶端以zone 級別註冊到 antscheduler 上，向該zone 上的所有antscheduler 註冊連接。每個zone 上的 antscheduler 則負責管理該zone 下的客戶端任務調度。

集群的容災能力也針對zone粒度進行管理，在金融雲單機房模式下，就簡化為單zone, 即整個環境只有一個任務調度集群。

3.2 master 選舉
考慮金融雲最小化輸出，所以選舉部分沒有選擇 ZK 等比較重的組件，而是採用數據庫DB 搶鎖方式實現 master 選舉。

antscheduler 的master 選舉完全依賴數據庫mysql, 利用mysql 管理服務、及服務狀態，並利用數據庫的唯一鍵來完成master 的競爭。antschduler 中的 server 表類似一個服務註冊表，管理所有zone 下的antscheduler 服務。記錄服務ip地址、心跳、服務狀態、所在zone、以及master標誌。

3.3 分片調度

在分佈式任務調度系統中，將所有的任務分配給多臺機器執行，可以提高調度負載能力。AntSchduler 架構支持水平擴容能力，當增加任務調度服務器時，可以減輕原有服務壓力，將任務均衡分配到各個機器上。

AntSchduler 採用一致性 hash 算法將任務均衡分配到機器集群中的各個機器上，一致性hash 算法可以減少分配的任務抖動性，避免一個機器的上下線導致整個集群任務重新洗牌，造成一些任務的漏觸發。通過一致性hash 算法可以減少抖動性，也降低漏觸發風險。

整個集群的任務由 master 負責分配，master 會監聽所有 slave 的狀態，一旦發現有 slave 上線或下線，則會將 更新 hash 環上的 server 節點，並重新計算 任務的hash。

如果是上線， 則將整個集群中的任務重新計算一次hash，目的是將任務分配到新的機器上
如果是服務下線，計算下線服務的負責的任務 計算hash ，將下線機器任務分配給其他機器。

3.4 failover策略

1.master 心跳超時或下線
所有的 slave 會監聽 master 的心跳狀態，如果一旦發現master 心跳超時，則更新master 狀態。開啟一個次 master 競選。

競選成功後，會通知master進行角色降級。 新的master 連接所有的 slave, 監聽各個 slave 狀態。 競選成功後 master 開啟任務分配，以及本機任務加載。

2.slave 服務上線/下線
master 會監聽所有的 slave 狀態，當slave 上下線或心跳超時時，master 會重新分配任務，保證任務正常觸發。

假設原來只有兩臺機器，S1 和 S2。 整個集群有三個任務 job1, job2 和 job3。 job1 分配給 S1 調度，job2 、job3 分別分配給 S2 調度。

擴容了一臺 S3，master 監聽到有新的服務上線，則重新分配集群中的任務。 將任務 job3 分配給了 S3，而 job1和 job 2 不變化。 對於整個集群來說，抖動很小，隻影響了 job3 任務。

服務下線過程剛好反過來，master 監聽到有服務下線，則將該機器上的任務重新分配給其他機器。

3.任務加載
master 負責任務分配，將數據庫中的任務狀態修改為 MODIFY，以及修改負責加載調度的機器ip。 此刻 各個 server 如何感知呢？ 任務調度通過兩種機制保障任務被及時加載到機器上調度。

master 通知機制。master 會通過 RPC 方式同時所有的slave 機器去加載和刷新任務。並通過事件機制通知本機加載。
加載監聽器(兜底策略)。 避免因為網絡等原因，沒有通知到各個機器，各server 內置加載監聽器，定時輪詢 DB中自己負責的狀態為MODIFY的任務，將這些任務加載並放置到調度器中，後續執行。

4.執行中任務處理
rpc 任務執行過程中涉及到結果回調處理，在故障之前，任務1被服務器S1調度，並在在客戶端執行，因網絡或服務發佈等原因任務被分配到 S2 調度。此刻回調以後如何處理結果呢？

簡單任務
客戶端回調成功結果時，S1 服務正常。 因為任務的執行記錄狀態都保持在數據庫中，因此回調 S1 時，S1 可以通過數據庫獲取記錄修改記錄狀態。
如果回調返回時，S1 進程已經不在。 那麼客戶端回調失敗，本次觸發會通過超時監控器將其設置為超時狀態。對於業務方而言，該任務已經被觸發。當然業務方也是可以配置超時策略，重試三次以保障這次調度。

集群任務
集群任務按 chunk維度執行，如果服務下線 master 則會將這臺機器上的所有 chunk 設置為 CASH 狀態。 通過一致性 hash 將任務分配給其他機器執行。負責故障恢復的機器則會將該任務下的所有分片重新加載。

和簡單任務一樣，因為狀態都存放在數據庫，因此客戶端不管回調到那臺機器上，都可以修改狀態。集群任務與簡單任務不同的地方在於執行中的chunk，還會被下發一次，因此可能存在兩次回調。目前集群任務chunk 的執行結果以最後一次為準，以最後一次反饋上來的狀態為最終狀態，這塊需要做冪等處理。

3.5 可擴展性

antschduler 通過一致性 hash 算法分配任務到各個機器上調度，保證一個任務在一臺服務器上調度。通過集群分擔任務調度負載，當然任務調度也支持靈活的擴容和縮容、支持水平擴展。當增加機器後，master 會將集群中其他服務器的調度任務分擔給新加入集群的機器。在分片過程中採用一致hash 算法，減少分配過程中整個集群任務的抖動性。

小結

AntScheduler 2.0 以 RPC 任務為主要通道，提供了簡單任務、集群任務、拓撲任務等。RPC 任務解決消息任務 存在的問題，可以做到對結果感知、過程干預、任務編排等。

考慮主站 LDC 模式，AntScheduler 在各個zone 內形成小集群負責集群任務調度。通過一致性hash算法將任務分片到不同機器執行，提高調度性能，實現水平擴展等。

雖然 RPC 任務有眾多好處，但還是存在一些不足和問題。 針對這些問題，我們在 serverless task 中做了進一步的優化。詳情看後續文章 「AntScheduler 3.0 之Serverless Task」。