如何選型一個合適的框架-分佈式任務調度框架選型

1.背景

定時任務是你們再開發中一個不可避免的業務，好比在一些電商系統中可能會定時給用戶發送生日券，一些對帳系統中可能會定時去對帳。大概再好久之前每一個服務可能就一臺機器，再這臺機器上直接搞個Timerschedule基本上就能知足咱們的業務需求，可是隨着時代的變遷，單臺機器已經遠遠不能知足咱們的須要，這個時候咱們可能須要10臺，20臺甚至更多機器來運行咱們的業務，接受咱們的流量，這就是咱們所說的橫向擴展。可是這裏就有個問題，這麼多臺機器若是還用咱們的Timerschedule去作會發生什麼呢？再上面的電商系統中有可能會給某個用戶發不少張生日券，對公司形成不少損失，因此咱們須要一些其餘方法，讓定時任務在多臺機器上只執行一次。

這裏想問下你們在沒有了解過或使用過度布式任務調度框架以前你們是如何作定時任務的呢？在Spring項目中你們確定都知道Spring-Scheduler，只須要在Spring中的bean的對應方法上加上@Scheduler註解便可完成咱們的定時任務，可是光是用這個註解還遠遠不能保證定時任務執行屢次，咱們須要一些其餘手段的保證，通常來講方法可能不外乎下面幾種（都是基於Spring的項目來講）：

• 一臺機器，咱們能夠將一些不過重要的定時任務，可使用一個專門的服務檯承載，而後使用單機跑，就算掛了只要咱們再可接受的時間以內將其恢復，咱們的業務也不會受到影響。

• 多臺機器，加分佈式鎖，只要咱們執行任務的時候首先獲取一把分佈式鎖，若是獲取失敗那麼久證實有其餘服務已經再運行，若是獲取成功那麼證實沒有服務在運行定時任務，那麼就能夠執行。

• 多臺機器，利用ZooKeeper對Leader機器執行定時任務，有不少業務已經使用了ZK，那麼執行定時任務的時候判斷本身是不是Leader，若是不是則不執行，若是是則執行業務邏輯，這樣也能達到咱們的目的。

目前咱們公司作定時任務也是使用的上面三種方法，在業務初期使用這些方法基本也能大致知足，可是隨着時間的遷移，咱們遇到的問題愈來愈多，這裏和你們分享一下：

• 首先是單機問題，如何劃分一個業務不是很重要，這一塊原本就比較複雜，有可能每一個人都說本身的業務都重要，其次是若是單機掛了 這個掛有多是宕機，有多是其餘的一些狀況，這個時間如何能保證咱們再可接受的範圍之間恢復，這些都是難點。
• 目前咱們使用定時任務的時候，若是想讓它立刻執行一次，這個時候可能就須要額外再寫一個Rest接口或者再另外寫一個單獨的Job。
• 還有個是咱們須要更改定時任務執行時間，好比如今有個需求是從每12個小時執行一次變成每6小時執行一次，咱們又得修改代碼，提交pr，而後打包上線，只是修改一個時間又得花費咱們不少時間。
• 沒法暫停咱們的定時任務，當咱們的定時任務可能出現一些問題，好比一些定時報警的需求，當報警忽然變得不少，這個時候須要暫停一下讓其中止發送報警，這個時候可能咱們能夠用一些分佈式配置的開關去作，再邏輯中判判定時任務開關是否打開，而後來作。這樣作雖然也比較簡單，可是咱們這樣須要新添加一些與任務無關的邏輯。
• 缺乏對定時任務的監控，任務失敗以後開發人員無從得知，有人說不是有Error日誌嗎，若是一個Error日誌就一次報警那大家的服務能受得了嗎，通常來講連續幾回Error纔會觸發報警，而咱們定時任務的週期性的特性是不容易觸發連續的Error。

固然還有一些或多或少的小問題這裏就不一一列舉了，若是你們有這種經歷能夠本身慢慢體會發現。

2. 調研的基本原則

上面第一章講了咱們框架的緣由，不論你要引入或改進什麼，都須要緣由，由於作任何事都有成本，我常常看到一些很小的項目就開始搞引入消息隊列，或者分佈式事務等等，這樣作反而是本末倒置，好比可能有一些博客系統就搞個消息隊列削峯減流，這樣作有可能尚未同步調用來得快。

當咱們有了緣由以後，就能夠着手作一些調研或者技術方案的設計。這裏我講一下個人調研框架一些基本原則，若是你們之後有相似的調研框架的需求均可以往這個裏面來套。

• 簡單-對開發者接入簡單，對使用者使用簡單。
• 豐富的文檔，有不少開源的項目文檔少之又少，固然還有一些開源項目只有英文文檔，若是你英文不是很行，那可能須要考慮中文居多的文檔。
• 有管理界面，很方便執行操做和統計數據。
• 支持主流框架：好比Spring,Springboot等，固然這個至少要支持大家業務中的主流框架。
• 框架輕量級，方便根據本身的需求進行定製化。
• 高性能，高可靠，高可用：不能讓框架成爲業務中的瓶頸。
• 代碼更新頻率和社區使用狀況：使用的公司越多證實其越受更多人的喜好，代碼更新頻率越高證實出現問題就會越少，最好是由大廠開源而且維護。
• 多語言需求：若是在大家業務中有多語言需求，好比大家公司用的開發語言不少，都須要調度框架那麼你須要使用多語言支持。好比Rpc支持多語言的表明就是Thrift。
• 可否解決當前的痛點：這個是最重要的，若是連你問題都解決不了那使用這個還有什麼意義呢？

當咱們有了上述的幾大原則以後，咱們接下來能夠進入調研。

3.調研框架

3.1 TBSchedule

通常調研Java系的一些框架，能夠先看看阿里是否是有開源的，畢竟最近這幾年阿里在開源這一塊作得是很是的好，再網上搜索到阿里在12年開源了一個調度框架叫TBSchedule，如今再去搜索代碼，發現已經人走茶涼，代碼都被清理乾淨了。固然還有一個我的項目將其Fork出來再不斷維護，可是使用者實在是少這裏就不說明了。 github地址：https://github.com/taobao/TBSchedule

3.2 elastic-job

elastic-Job 是噹噹開源的一個分佈式調度解決方案，由兩個相互獨立的子項目 Elastic-Job-Lite 和 Elastic-Job-Cloud 組成。定位爲輕量級無中心化解決方案，使用 jar 包的形式提供分佈式任務的協調服務。支持分佈式調度協調、彈性擴容縮容、失效轉移、錯過執行做業重觸發、並行調度、自診斷和修復等等功能特性。

這個框架大概在2年前很火，當時使用的公司不少，想必不少人也聽過了，可是很惋惜如今已經不在維護了，代碼已經有2年沒有更新了，這裏違反了更新頻率的原則，若是出現問題可能都沒什麼人幫助你，因此咱們並非很推薦使用。 github地址：https://github.com/elasticjob/elastic-job-lite

3.3 一些比較小衆的

在網上有一些比較小衆的github star不多，更新頻率也不多： Uncode-Schedule，LTS,openCron等等，這些也不符合咱們的原則，都不予以考慮

3.4 XXL-JOB

因爲分佈式定時任務如今尚未基金會好比CNCF,Apache等，抉擇起來可能不是那麼難。不像消息隊列再Apache裏面就有好幾個:Kafka,rocketmq,plusar等等，每個的社區都很龐大，可能選擇是比較困難的。那麼咱們基本就還剩下兩個選擇，一個是自研，這種任務調度框架，再研發的困難程度上是遠遠比不上消息隊列的研發，因此其實不少公司都選擇了自研，好比：美團的Crane這些。可是對於一些消息隊列這些複雜的中間件可能會選擇二次開發，好比美團的mafka就是基於kafka二次開發，滴滴的DDMQ也是基於Rocketmq。而咱們目前若是選擇自研再資源上來講是明顯不夠的，這裏咱們仍是使用的是二次開發框架的策略。

固然這裏還剩下一個XXL-Job:http://www.xuxueli.com/xxl-job 的選擇，其基本符合咱們的原則，目前代碼也在持續更新，issue做者也在積極的回覆，使用的公司也有200多家,其中包括以前的點評，同時其餘的原則也很符合。通常來講當你決定選擇某個框架的時候須要詳細的列舉一下優勢，好讓其餘人得以信服。

xxl-job有下面一些特色：

• 簡單：支持經過Web頁面對任務進行CRUD操做，操做簡單，一分鐘上手；
• 動態：支持動態修改任務狀態、啓動/中止任務，以及終止運行中任務，即時生效；
• 調度中心HA（中心式）：調度採用中心式設計，「調度中心」自研調度組件並支持集羣部署，可保證調度中心HA；
• 執行器HA（分佈式）：任務分佈式執行，任務"執行器"支持集羣部署，可保證任務執行HA；
• 註冊中心: 執行器會週期性自動註冊任務, 調度中心將會自動發現註冊的任務並觸發執行。同時，也支持手動錄入執行器地址；
• 彈性擴容縮容：一旦有新執行器機器上線或者下線，下次調度時將會從新分配任務；
• 路由策略：執行器集羣部署時提供豐富的路由策略，包括：第一個、最後一個、輪詢、隨機、一致性HASH、最不常用、最近最久未使用、故障轉移、忙碌轉移等；
• 故障轉移：任務路由策略選擇"故障轉移"狀況下，若是執行器集羣中某一臺機器故障，將會自動Failover切換到一臺正常的執行器發送調度請求。
• 阻塞處理策略：調度過於密集執行器來不及處理時的處理策略，策略包括：單機串行（默認）、丟棄後續調度、覆蓋以前調度；
• 事件觸發：除了"Cron方式"和"任務依賴方式"觸發任務執行以外，支持基於事件的觸發任務方式。調度中心提供觸發任務單次執行的API服務，可根據業務事件靈活觸發。
• 任務進度監控：支持實時監控任務進度；
• Rolling實時日誌：支持在線查看調度結果，而且支持以Rolling方式實時查看執行器輸出的完整的執行日誌

基本上上面的一些特色都是咱們業務中所須要的，因此這裏最後選擇了XXL-JOB

4.總結

俗話說：授人以魚不如授人以漁，以前的文章每次都是介紹某某框架，這一次我偏向於介紹我是如何選擇的這款框架，讓你們再之後調研的過程當中也能夠按照這個思路，若是說你也有好的而且不一樣的調研思路，歡迎留言或者加羣交流。固然通常調研完畢以後，做爲一個調研人若是你不弄清楚這個框架的源碼和實現原理，那麼就是一個不合格的調研人，因此下一篇文章我會詳細的介紹XXL-Job的實現原理。

若是你們以爲這篇文章對你有幫助，你的關注和轉發是對我最大的支持，O(∩_∩)O: