本文適合有 Java 基礎知識的人群

作者：HelloGitHub-Salieri

HelloGitHub 推出的《講解開源專案》系列。經過幾番的努力和溝通，終於邀請到分散式任務排程與計算框架：PowerJob 的作者 Salieri，加入 HG 的開源講解系列，開啟了他的 PowerJob 講解系列。後續每週三將更新一篇，歡迎大家持續關注，希望你能從本系列學到真本事。

專案地址：https://github.com/KFCFans/PowerJob

一、緣起

大家好我是 PowerJob 的作者 Salieri，關於 PowerJob 故事要從一年前說起了。

一年前，我前往阿里巴巴集團，開啟了自己的暑期實習。機緣巧合的是，我接到的第一個正式的開發類任務，就與分散式任務排程與計算緊密相關。

當時，集團內部研發出了一款全新的任務排程中介軟體（SchedulerX 2.0，也就是 README 中提到的本框架的參考物件），需要從老版本的 DTS 遷移到 SchedulerX 2.0。而這個光榮而偉大的任務，自然也被師兄委派到了我身上。也從那時候開始我開始正式接觸並使用這種分散式任務排程與計算中介軟體。

遷移完畢後很長一段時間內，算是我和 SchedulerX 的蜜月期，不得不說 SchedulerX 的設計理念極其先進，比如通過控制檯或 OpenAPI 動態傳遞執行時引數能讓傳統的任務變得非常靈活，無需更改程式碼即可實現不同的功能，再比如 MapReduce 處理器的存在使得開發者只需要寥寥數行程式碼就能實現分散式計算，解決大量資料的處理需求。然而好景不長，在即將迎來雙十一之際，發生了兩個比較悲傷的故事。

雙十一臨近，由於需要處理的資料量激增，之前在 SchedulerX 上執行完美的離線任務開始頻頻失敗，整個雙十一前夕報警電話的頻率甚至能超過微信提醒的頻率（好吧有一部分原因是沒人找我 T_T）。經過與相關開發人員的一通排查，初步斷定問題的原因在於我們的應用記憶體佔用過高，導致 SchedulerX 沒有足夠的記憶體去完成必要的任務，進而導致任務失敗。這個鍋，SchedulerX 顯然是不背的，也很合理，不符合最低執行要求嘛，就好比你買一臺 Macbook Air 裝個 Windows 準備玩 PUBG 結果發現連歡迎介面都看不到，你能說什麼呢？人家最低執行要求寫的明明白白，達不到配置要求無法執行只能怪你自己，你能做的只有接受。最後實在沒辦法，只能拆東牆補西牆勉勉強強撐過了雙十一。

另一件事是限流。為了監控任務的執行狀態，我在另一個應用單獨寫了輪詢查詢 SchedulerX 任務執行狀態的邏輯，該功能一直四平八穩地執行著。直到某一天，我完成一個微小改動的釋出後，本著安全生產的原則，登上線上日誌平臺檢視應用的執行時日誌。不看不知道一看嚇一跳，滿螢幕的 RuntimeException 甚至讓我懷疑我是不是不小心刪掉了某個模組，還是不小心把資料庫刪了，還是不小心釋出錯程式碼分支了。慌亂過後冷靜下來看異常資訊，才發現一直以來我呼叫的 SchedulerX 提供的檢視任務執行狀態介面報錯了，被限流了。理由是雙十一保障。嗯，因為需要保障雙十一穩定性所以先弄掛一個雖然不在雙十一圈內但好歹站在邊上的應用。溝通無果，只能一頓魔改程式碼，自己去實現任務的狀態監控。

其實這兩件事情呢，SchedulerX 團隊確實沒有什麼問題。畢竟服務於整個集團所有業務線，不做一些限制任由大家肆無忌憚使用是不可能的。但是中臺模式下，某些個體的需求無法得到滿足也是確實存在的現象。對於大部分接入使用者來說，只需要依賴個 Jar 包，寫點程式碼，去控制檯一配置，任務就能跑起來，使用體驗極好。畢竟，並不是所有使用者都有我們這種動輒幾百萬子任務的變態需求......

雙十一過後，實習期滿，我也就從阿里離職回家，開啟混吃等死模式，每天不是在打遊戲就是在想怎麼打遊戲，對了，還有告訴自己明天一定要好好學習。

渾渾噩噩過了 N 個月後，終於想起還有畢業論文這事。沒辦法，為了卑微的學位，我只能暫時金盆洗手，投入到論文的撰寫之中去。寫完論文，疫情差不多結束了，一起“送人頭”的小夥伴都差不多上班去了，構成我充滿打遊戲慾望的條件（人數==5）被破壞，我也就徹底閒了下來。重拾自己的傳統藝能——Reading。

在看了很多本奇奇怪怪的書（甚至包括一本言情小說）以後，終於想起了以前一直想做但是一直被慵懶的自己所擱置的事情：自研一個 SchedulerX，萬一哪天 SchedulerX 滿足不了需求，至少還能自己就自己搶救一下～於是，OhMyScheduler（沒錯，一開始叫 OhMyScheduler），後面改名為 PowerJob 誕生了～

二、初見

實在是沒事兒幹了，也是時候扛起是“新一代分散式任務排程與計算框架”的大旗了（當然要走的路還很長），廢話不多說接下來開始正文。

2.1 任務排程框架

定時任務相信大家都接觸過，比如經典的 Linux crontab。定時排程、定時執行已經漸漸成為了各個系統普遍需要依賴的中間系統。在 Java 領域，也出現了許多優秀的任務排程框架。

當前市面上流行的作業排程框架有老牌的 Quartz、基於 Quartz 的 elastic-job 和原先基於 Quartz 後面移除依賴的 xxl-job，這裡分別談一些這些框架現存的缺點。

Quartz 可以視為第一代任務排程框架，基本上是現有所有分散式排程框架的“祖宗”。由於歷史原因，它不提供Web介面，只能通過API完成任務的配置，使用起來不夠方便和靈活，同時它僅支援任務的單機執行，無法有效利用整個叢集的計算能力。 同時，Quartz 需要的排程和執行耦合在同一個應用中，沒有平臺化服務的能力。

xxl-job 可以視為第二代任務排程框架，在一定程度上解決了 Quartz 的不足，在過去幾年中是個非常優秀的排程框架，不過放到今天來看，還是存在著一些不足的，具體如下：

• 資料庫支援單一：僅支援 MySQL，使用其他DB需要自己魔改程式碼
• 有限的分散式計算能力：僅支援靜態分片，無法很好的完成複雜任務的計算
• 不支援工作流：無法配置各個任務之間的依賴關係，不適用於任務之間存在複雜依賴的場景

正所謂長江後浪推前浪，在如今這個資料量日益增長、業務越來越複雜的年代，急需一款更為強大的任務排程框架來解決上訴問題，而 PowerJob 因此應運而生。

2.2 PowerJob 閃亮登場

PowerJob 可以被認為是第三代任務排程框架，在任務排程的基礎上，還額外提供了分散式計算和工作流功能，其主要特性如下：

• 使用簡單：提供 Web 介面，允許開發者視覺化地完成排程任務的管理（增、刪、改、查）、任務執行狀態監控和執行日誌檢視等功能。
• 定時策略完善：支援 CRON 表示式、固定頻率、固定延遲和API四種定時排程策略。
• 執行模式豐富：支援單機、廣播、Map、MapReduce 四種執行模式，其中 Map/MapReduce 處理器能使開發者寥寥數行程式碼便獲得叢集分散式計算的能力。
• 工作流（workflow）支援：支援線上配置任務依賴關係，視覺化得對任務進行編排，同時還支援上下游任務間的資料傳遞
• 執行器支援廣泛：支援 Spring Bean、內建/外接 Java 類、Shell、Python 等處理器，應用範圍廣。
• 運維便捷：支援線上日誌功能，執行器產生的日誌可以在前端控制檯頁面實時顯示，降低 debug 成本，極大地提高開發效率。
• 依賴精簡：最小僅依賴關係型資料庫（MySQL/PostgreSQL/Oracle/MS SQLServer 等），同時支援所有 Spring Data JPA 所支援的關係型資料庫。
• 高可用&高效能：排程伺服器經過精心設計，一改其他排程框架基於資料庫鎖的策略，實現了無鎖化排程。部署多個排程伺服器可以同時實現高可用和效能的提升（支援無限的水平擴充套件）。
• 故障轉移與恢復：任務執行失敗後，可根據配置的重試策略完成重試，只要執行器叢集有足夠的計算節點，任務就能順利完成。

2.3 PowerJob 適用場景

綜上所述，PowerJob 是全新一代分散式排程與計算框架，能讓您輕鬆完成任務的排程與繁雜任務的分散式計算。適用於各個有任務排程需求的企業，統一部署 Server 做為整個公司的公共排程平臺，成為分散式排程的中介軟體。

• 有定時執行需求的業務場景：如每天凌晨全量同步資料、生成業務報表等。
• 有需要全部機器一同執行的業務場景：如使用廣播執行模式清理叢集日誌。
• 有需要分散式處理的業務場景：比如需要更新一大批資料，單機執行耗時非常長，可以使用 Map/MapReduce 處理器完成任務的分發，調動整個叢集加速計算。

三、大綱

後面會逐步從上手使用講到核心技術剖析，希望大家可以從中有所收穫，同時歡迎小夥伴們可以貢獻程式碼哦！大綱太長了（10+篇）簡單羅列一部分：

• 快速上手
• PowerJob 技術綜述
• 技術剖析：Akka 框架
  • Actor模型
  • Akka-remote 簡化通訊程式碼
  • Akka API 介紹
• 技術剖析：任務的排程與派發
  • 時間輪演演算法
  • 排程層：OmsSchedulerService
  • 派發層：DispatchService
• 技術剖析：Spring AOP 技術的應用
  • 攔截
  • exclude
• 等等

四、總結與預告

本章主要闡述了 PowerJob 誕生的故事，同時簡單介紹了 PowerJob 這個框架的功能和適用場景，本系列的大綱。下一章節，我將會介紹 PowerJob 的快速入門，幫助大家快速熟悉並使用這款強大的分散式任務排程與計算框架。

那我們下期再見嘍～

HelloGitHub 交流群現已全面開放（作者在 Java 群），新增微訊號：HelloGitHub 為好友入群，可同前端、Java、Go 等各界大佬談笑風生、切磋技術~