怎么選擇web分布式任務(wù)調(diào)度框架

這篇文章主要講解了“怎么選擇web分布式任務(wù)調(diào)度框架”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“怎么選擇web分布式任務(wù)調(diào)度框架”吧！

1.背景

定時任務(wù)是大家再開發(fā)中一個不可避免的業(yè)務(wù)，比如在一些電商系統(tǒng)中可能會定時給用戶發(fā)送生日券，一些對賬系統(tǒng)中可能會定時去對賬。大概再很久以前每個服務(wù)可能就一臺機(jī)器，再這臺機(jī)器上直接搞個Timerschedule基本上就能滿足我們的業(yè)務(wù)需求，但是隨著時代的變遷，單臺機(jī)器已經(jīng)遠(yuǎn)遠(yuǎn)不能滿足我們的需要，這個時候我們可能需要10臺，20臺甚至更多機(jī)器來運(yùn)行我們的業(yè)務(wù)，接受我們的流量，這就是我們所說的橫向擴(kuò)展。但是這里就有個問題，這么多臺機(jī)器如果還用我們的Timerschedule去做會發(fā)生什么呢？再上面的電商系統(tǒng)中有可能會給某個用戶發(fā)很多張生日券，對公司造成很多損失，所以我們需要一些其他方法，讓定時任務(wù)在多臺機(jī)器上只執(zhí)行一次。

這里想問下大家在沒有了解過或使用過分布式任務(wù)調(diào)度框架之前大家是如何做定時任務(wù)的呢？在Spring項目中大家肯定都知道Spring-Scheduler，只需要在Spring中的bean的對應(yīng)方法上加上@Scheduler注解即可完成我們的定時任務(wù)，但是光是用這個注解還遠(yuǎn)遠(yuǎn)不能保證定時任務(wù)執(zhí)行多次，我們需要一些其他手段的保證，一般來說方法可能不外乎下面幾種（都是基于Spring的項目來說）：

• 一臺機(jī)器，我們可以將一些不太重要的定時任務(wù)，可以使用一個專門的服務(wù)臺承載，然后使用單機(jī)跑，就算掛了只要我們再可接受的時間之內(nèi)將其恢復(fù)，我們的業(yè)務(wù)也不會受到影響。

• 多臺機(jī)器，加分布式鎖，只要我們執(zhí)行任務(wù)的時候首先獲取一把分布式鎖，如果獲取失敗那么久證明有其他服務(wù)已經(jīng)再運(yùn)行，如果獲取成功那么證明沒有服務(wù)在運(yùn)行定時任務(wù)，那么就可以執(zhí)行。

• 多臺機(jī)器，利用ZooKeeper對Leader機(jī)器執(zhí)行定時任務(wù)，有很多業(yè)務(wù)已經(jīng)使用了ZK，那么執(zhí)行定時任務(wù)的時候判斷自己是否是Leader，如果不是則不執(zhí)行，如果是則執(zhí)行業(yè)務(wù)邏輯，這樣也能達(dá)到我們的目的。

目前我們公司做定時任務(wù)也是使用的上面三種方法，在業(yè)務(wù)初期使用這些方法基本也能大體滿足，但是隨著時間的遷移，我們遇到的問題越來越多，這里和大家分享一下：

• 首先是單機(jī)問題，如何劃分一個業(yè)務(wù)不是很重要，這一塊本來就比較復(fù)雜，有可能每個人都說自己的業(yè)務(wù)都重要，其次是如果單機(jī)掛了 這個掛有可能是宕機(jī)，有可能是其他的一些情況，這個時間如何能保證我們再可接受的范圍之間恢復(fù)，這些都是難點。

• 目前我們使用定時任務(wù)的時候，如果想讓它馬上執(zhí)行一次，這個時候可能就需要額外再寫一個Rest接口或者再另外寫一個單獨的Job。

• 還有個是我們需要更改定時任務(wù)執(zhí)行時間，比如現(xiàn)在有個需求是從每12個小時執(zhí)行一次變成每6小時執(zhí)行一次，我們又得修改代碼，提交pr，然后打包上線，只是修改一個時間又得花費我們很多時間。

• 無法暫停我們的定時任務(wù)，當(dāng)我們的定時任務(wù)可能出現(xiàn)一些問題，比如一些定時報警的需求，當(dāng)報警突然變得很多，這個時候需要暫停一下讓其停止發(fā)送報警，這個時候可能我們可以用一些分布式配置的開關(guān)去做，再邏輯中判斷定時任務(wù)開關(guān)是否打開，然后來做。這樣做雖然也比較簡單，但是我們這樣需要新添加一些與任務(wù)無關(guān)的邏輯。

• 缺少對定時任務(wù)的監(jiān)控，任務(wù)失敗之后開發(fā)人員無從得知，有人說不是有Error日志嗎，如果一個Error日志就一次報警那你們的服務(wù)能受得了嗎，一般來說連續(xù)幾次Error才會觸發(fā)報警，而我們定時任務(wù)的周期性的特性是不容易觸發(fā)連續(xù)的Error。

當(dāng)然還有一些或多或少的小問題這里就不一一列舉了，如果大家有這種經(jīng)歷可以自己慢慢體會發(fā)現(xiàn)。

2. 調(diào)研的基本原則

上面第一章講了我們框架的原因，不論你要引入或改進(jìn)什么，都需要原因，因為做任何事都有成本，我經(jīng)?？吹揭恍┖苄〉捻椖烤烷_始搞引入消息隊列，或者分布式事務(wù)等等，這樣做反而是本末倒置，比如可能有一些博客系統(tǒng)就搞個消息隊列削峰減流，這樣做有可能還沒有同步調(diào)用來得快。

當(dāng)我們有了原因之后，就可以著手做一些調(diào)研或者技術(shù)方案的設(shè)計。這里我講一下我的調(diào)研框架一些基本原則，如果大家以后有類似的調(diào)研框架的需求都可以往這個里面來套。

• 簡單-對開發(fā)者接入簡單，對使用者使用簡單。

• 豐富的文檔，有很多開源的項目文檔少之又少，當(dāng)然還有一些開源項目只有英文文檔，如果你英文不是很行，那可能需要考慮中文居多的文檔。

• 有管理界面，很方便執(zhí)行操作和統(tǒng)計數(shù)據(jù)。

• 支持主流框架：比如Spring,Springboot等，當(dāng)然這個至少要支持你們業(yè)務(wù)中的主流框架。

• 框架輕量級，方便根據(jù)自己的需求進(jìn)行定制化。

• 高性能，高可靠，高可用：不能讓框架成為業(yè)務(wù)中的瓶頸。

• 代碼更新頻率和社區(qū)使用情況：使用的公司越多證明其越受更多人的喜愛，代碼更新頻率越高證明出現(xiàn)問題就會越少，最好是由大廠開源并且維護(hù)。

• 多語言需求：如果在你們業(yè)務(wù)中有多語言需求，比如你們公司用的開發(fā)語言很多，都需要調(diào)度框架那么你需要使用多語言支持。比如Rpc支持多語言的代表就是Thrift。

• 能否解決當(dāng)前的痛點：這個是最重要的，如果連你問題都解決不了那使用這個還有什么意義呢？

當(dāng)我們有了上述的幾大原則之后，我們接下來可以進(jìn)入調(diào)研。

3.調(diào)研框架

3.1 TBSchedule

一般調(diào)研Java系的一些框架，可以先看看阿里是不是有開源的，畢竟最近這幾年阿里在開源這一塊做得是非常的好，再網(wǎng)上搜索到阿里在12年開源了一個調(diào)度框架叫TBSchedule，現(xiàn)在再去搜索代碼，發(fā)現(xiàn)已經(jīng)人走茶涼，代碼都被清理干凈了。當(dāng)然還有一個個人項目將其Fork出來再不斷維護(hù)，但是使用者實在是少這里就不說明了。 github地址：https://github.com/taobao/TBSchedule

3.2 elastic-job

elastic-Job 是當(dāng)當(dāng)開源的一個分布式調(diào)度解決方案，由兩個相互獨立的子項目 Elastic-Job-Lite 和 Elastic-Job-Cloud 組成。定位為輕量級無中心化解決方案，使用 jar 包的形式提供分布式任務(wù)的協(xié)調(diào)服務(wù)。支持分布式調(diào)度協(xié)調(diào)、彈性擴(kuò)容縮容、失效轉(zhuǎn)移、錯過執(zhí)行作業(yè)重觸發(fā)、并行調(diào)度、自診斷和修復(fù)等等功能特性。

這個框架大概在2年前很火，當(dāng)時使用的公司很多，想必很多人也聽過了，但是很可惜現(xiàn)在已經(jīng)不在維護(hù)了，代碼已經(jīng)有2年沒有更新了，這里違反了更新頻率的原則，如果出現(xiàn)問題可能都沒什么人幫助你，所以我們并不是很推薦使用。 github地址：https://github.com/elasticjob/elastic-job-lite

3.3 一些比較小眾的

在網(wǎng)上有一些比較小眾的github star很少，更新頻率也很少： Uncode-Schedule，LTS,openCron等等，這些也不符合我們的原則，都不予以考慮

3.4 XXL-JOB

由于分布式定時任務(wù)現(xiàn)在還沒有基金會比如CNCF,Apache等，抉擇起來可能不是那么難。不像消息隊列再Apache里面就有好幾個:Kafka,rocketmq,plusar等等，每一個的社區(qū)都很龐大，可能選擇是比較困難的。那么我們基本就還剩下兩個選擇，一個是自研，這種任務(wù)調(diào)度框架，再研發(fā)的困難程度上是遠(yuǎn)遠(yuǎn)比不上消息隊列的研發(fā)，所以其實很多公司都選擇了自研，比如：美團(tuán)的Crane這些。但是對于一些消息隊列這些復(fù)雜的中間件可能會選擇二次開發(fā)，比如美團(tuán)的mafka就是基于kafka二次開發(fā)，滴滴的DDMQ也是基于Rocketmq。而我們目前如果選擇自研再資源上來說是明顯不夠的，這里我們還是使用的是二次開發(fā)框架的策略。

當(dāng)然這里還剩下一個XXL-Job:http://www.xuxueli.com/xxl-job 的選擇，其基本符合我們的原則，目前代碼也在持續(xù)更新，issue作者也在積極的回復(fù)，使用的公司也有200多家,其中包括之前的點評，同時其他的原則也很符合。一般來說當(dāng)你決定選擇某個框架的時候需要詳細(xì)的列舉一下優(yōu)點，好讓其他人得以信服。

xxl-job有下面一些特點：

• 簡單：支持通過Web頁面對任務(wù)進(jìn)行CRUD操作，操作簡單，一分鐘上手；

• 動態(tài)：支持動態(tài)修改任務(wù)狀態(tài)、啟動/停止任務(wù)，以及終止運(yùn)行中任務(wù)，即時生效；

• 調(diào)度中心HA（中心式）：調(diào)度采用中心式設(shè)計，“調(diào)度中心”自研調(diào)度組件并支持集群部署，可保證調(diào)度中心HA；

• 執(zhí)行器HA（分布式）：任務(wù)分布式執(zhí)行，任務(wù)"執(zhí)行器"支持集群部署，可保證任務(wù)執(zhí)行HA；

• 注冊中心: 執(zhí)行器會周期性自動注冊任務(wù), 調(diào)度中心將會自動發(fā)現(xiàn)注冊的任務(wù)并觸發(fā)執(zhí)行。同時，也支持手動錄入執(zhí)行器地址；

• 彈性擴(kuò)容縮容：一旦有新執(zhí)行器機(jī)器上線或者下線，下次調(diào)度時將會重新分配任務(wù)；

• 路由策略：執(zhí)行器集群部署時提供豐富的路由策略，包括：第一個、最后一個、輪詢、隨機(jī)、一致性HASH、最不經(jīng)常使用、最近最久未使用、故障轉(zhuǎn)移、忙碌轉(zhuǎn)移等；

• 故障轉(zhuǎn)移：任務(wù)路由策略選擇"故障轉(zhuǎn)移"情況下，如果執(zhí)行器集群中某一臺機(jī)器故障，將會自動Failover切換到一臺正常的執(zhí)行器發(fā)送調(diào)度請求。

• 阻塞處理策略：調(diào)度過于密集執(zhí)行器來不及處理時的處理策略，策略包括：單機(jī)串行（默認(rèn)）、丟棄后續(xù)調(diào)度、覆蓋之前調(diào)度；

• 事件觸發(fā)：除了"Cron方式"和"任務(wù)依賴方式"觸發(fā)任務(wù)執(zhí)行之外，支持基于事件的觸發(fā)任務(wù)方式。調(diào)度中心提供觸發(fā)任務(wù)單次執(zhí)行的API服務(wù)，可根據(jù)業(yè)務(wù)事件靈活觸發(fā)。

• 任務(wù)進(jìn)度監(jiān)控：支持實時監(jiān)控任務(wù)進(jìn)度；

• Rolling實時日志：支持在線查看調(diào)度結(jié)果，并且支持以Rolling方式實時查看執(zhí)行器輸出的完整的執(zhí)行日志

感謝各位的閱讀，以上就是“怎么選擇web分布式任務(wù)調(diào)度框架”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對怎么選擇web分布式任務(wù)調(diào)度框架這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！