PowerJob 的故事開始：「玩夠了，纔有精力寫開源啊！」

時間 2020-07-09

標籤 powerjob 故事開始夠了纔有精力開源简体版

原文原文鏈接

本文適合有 Java 基礎知識的人羣前端

做者：HelloGitHub-Salierigit

HelloGitHub 推出的《講解開源項目》系列。通過幾番的努力和溝通，終於邀請到分佈式任務調度與計算框架：PowerJob 的做者 Salieri，加入 HG 的開源講解系列，開啓了他的 PowerJob 講解系列🎉。後續每週三將更新一篇，歡迎你們持續關注，但願你能從本系列學到真本事。github

項目地址：https://github.com/KFCFans/PowerJobweb

1、緣起

你們好我是 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、初見

實在是沒事兒幹了，也是時候扛起是「新一代分佈式任務調度與計算框架」的大旗了（固然要走的路還很長），廢話很少說接下來開始正文。

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 所支持的關係型數據庫。
高可用&高性能：調度服務器通過精心設計，一改其餘調度框架基於數據庫鎖的策略，實現了無鎖化調度。部署多個調度服務器能夠同時實現高可用和性能的提高（支持無限的水平擴展）。
故障轉移與恢復：任務執行失敗後，可根據配置的重試策略完成重試，只要執行器集羣有足夠的計算節點，任務就能順利完成。