1. 程式人生 > >阿里新一代分散式任務排程平臺Schedulerx2.0破土而出

阿里新一代分散式任務排程平臺Schedulerx2.0破土而出

1. 產品簡介

Schedulerx2.0是阿里中介軟體自研的基於Akka架構的新一代分散式任務排程平臺,提供定時、任務編排、分散式跑批等功能。使用Schedulerx2.0,您可以在控制檯配置管理您的定時任務,查詢歷史執行記錄,檢視執行日誌。藉助Schedulerx2.0,您還可以通過工作流進行任務編排和資料傳遞。Schedulerx2.0還提供了簡單易用的分散式程式設計模型,簡單幾行程式碼就可以將海量資料分散式到多臺機器上執行。

Schedulerx2.0提供了任務排程與執行的一整套解決方案,在阿里巴巴集團內部廣泛使用並久經考驗,具有高可靠、海量任務、秒級別排程等能力。

2. 背景

Schedulerx2.0是Schedulerx1.0(DTS)的下一代產品,採用全新的架構,是全新自研的下一代分散式任務排程平臺,不但解決了老產品的效能瓶頸,還提供了更多更快更強的能力。

  • 更多:支援多種時間表達式,任務編排,支援更多的業務場景。單叢集支援上千萬任務,一天上十億次排程,支援更多的任務數。
  • 更快:支援秒級別排程,處理準實時業務。
  • 更強:支援日誌查詢、原地重跑、重刷資料等多種操作,提供更強的運維能力和排錯手段,解決為什麼沒跑,為什麼失敗,為什麼跑得慢等問題。

3. 功能

3.1 強大的定時排程器

3.1.1 Crontab

支援unix crontab表示式,不支援秒級別。

3.1.2 Fixed rate

眾所周知,crontab必須被60整除,比如想每隔40分鐘跑一次,cron不支援。Fixed rate專門用來做定期輪詢,表示式簡單,不支援秒級別。

3.1.3 Fixed delay

適合對實時性要求比較高的業務,比如每次執行完成隔10秒再跑,那麼second delay非常適合你。並且second delay能支援到秒級別。

3.1.4 日曆

支援多種日曆,還可以自定義匯入日曆。比如金融業務需要在每個交易日執行。

3.1.5 時區

跨國的業務,需要在每個國家的時區定時執行某個任務。

3.2 任務編排

支援工作流(DAG)進行任務編排,操作簡單,前端直接單手操作拖拖拽拽即可。詳細的任務狀態圖能一目瞭然看到下游任務為什麼沒跑。

3.3 任務型別

支援多種任務型別,可以無限擴充套件。

  • java:可以跑在使用者程序中,也可以上傳jar包動態載入。
  • shell:前端直接寫shell指令碼。
  • python:前端直接寫python指令碼,需要機器有python環境。
  • go:前端直接寫go指令碼,需要機器有go環境。
  • 自定義:使用者甚至可以自定義任務型別,然後實現一個plugin就行了。

3.4 執行方式&分散式程式設計模型

3.4.1 執行方式

  • 單機:隨機挑選一臺機器執行
  • 廣播:所有機器同時執行且等待全部結束
  • 平行計算:map/mapreduce模型,1~300個子任務,有子任務列表。
  • 記憶體網格:map/mapreduce模型,10W以下子任務,無子任務列表,基於記憶體計算,比網格計算快。
  • 網格計算:map/mapreduce模型,100W以下子任務,無子任務列表,基於檔案H2計算。

3.4.2 分散式程式設計模型

  • Map模型:類似於hadoop mapreduce裡的map。只要實現一個map方法,簡單幾行程式碼就可以將海量資料分散式到客戶自己的多臺機器上執行,進行跑批。
  • MapReduce模型:MapReduce模型是Map模型的擴充套件,新增reduce介面,所有子任務完成後會執行reduce方法,可以在reduce方法中返回該任務例項的執行結果,或者回調業務。

3.5 強大的運維能力

  • 資料大盤:控制檯提供了執行記錄大盤和執行列表,可以看到每個任務的執行歷史,並提供操作。
  • 檢視日誌:每條執行記錄,都可以詳情中的日誌頁面實時看到日誌。如果任務執行失敗了,前端直接就能看到錯誤日誌,非常方便。
  • 原地重跑:任務失敗,修改完程式碼釋出後,可以點選原地重跑。
  • 標記成功:任務失敗,如果後臺把資料處理正確了,重跑又需要好幾個小時,直接標記成功就好了。
  • Kill:實現JobProcessor的kill()介面,你就可以在前端kill正在執行的任務,甚至子任務。

3.6 資料時間

Schedulerx2.0可以處理有資料狀態的任務。建立任務的時候可以填資料偏移。比如一個任務是每天00:30執行,但是實際上要處理上一天的資料,就可以向前偏移一個小時。執行時間不變,執行的時候通過context.getDataTime()獲得的就是前一天23:30。

3.7 重刷資料

既然任務具有了資料時間,一定少不了重刷資料。比如一個任務/工作流最終產生一個報表,但是業務發生變更(新增一個欄位),或者發現上一個月的資料都有錯誤,那麼就需要重刷過去一個月的資料。

通過重刷資料功能,可以重刷某些任務/工作流的資料(只支援天級別),每個例項都是不同的資料時間。

3.8 失敗自動重試

  • 例項失敗自動重試:在任務管理的高階配置中,可以配置例項失敗重試次數和重試間隔,比如重試3次,每次間隔30秒。如果重試3次仍舊失敗,該例項狀態才會變為失敗,併發送報警。
  • 子任務失敗自動重試:如果是分散式任務(平行計算/內網網格/網格計算),子任務也支援失敗自動重試和重試間隔,同樣可以通過任務管理的高階配置進行配置。

3.9 支援原生Spring

之前的老產品Schedulerx1.0(DTS)和spring的結合非常暴力,對bean的命名有強要求,經常遇到注入失敗的問題。Schedulerx2.0支援原生spring語法,接入更加的方便。

3.10 報警監控

  • 失敗報警
  • 超時報警
  • 報警方式:簡訊

作者:黃曉萌

原文連結

本文為雲棲社群原創內容,未經允許不得轉