導(dǎo)語

對于定時任務(wù)大家應(yīng)該都不會陌生，從骨灰級別的Crontab到Spring Task，從QuartZ到xxl-job，隨著業(yè)務(wù)場景越來越多樣復(fù)雜，定時任務(wù)框架也在不斷的升級進化。

那么今天就來跟大家從以下三個方面聊一聊分布式任務(wù)調(diào)度：從單機定時任務(wù)到分布式任務(wù)調(diào)度平臺的演進過程、騰訊云分布式任務(wù)調(diào)度平臺TCT是如何應(yīng)運而生的、TCT具體落地案例情況和解決了哪些核心問題。

作者簡介

?崔凱

騰訊云 CSIG 微服務(wù)產(chǎn)品中心產(chǎn)品架構(gòu)師

多年分布式、高并發(fā)電子商務(wù)系統(tǒng)的研發(fā)、系統(tǒng)架構(gòu)設(shè)計經(jīng)驗，擅長主流微服務(wù)架構(gòu)技術(shù)平臺的落地和實施。

目前專注于微服務(wù)架構(gòu)相關(guān)中間件的研究推廣和最佳實踐的沉淀，致力于幫助企業(yè)完成數(shù)字化轉(zhuǎn)型。

場景類型

定時任務(wù)的場景千千萬，但它的本質(zhì)模型是個啥，怎么來理解定時任務(wù)呢，此處好有一比。

定時任務(wù)其實就是老師給學(xué)生布置作業(yè)，比如：

每天晚上7點準(zhǔn)時開始寫作業(yè)，寫完了讓家長檢查簽字。

“每天晚上7點準(zhǔn)時”是對時間精度和周期性的要求，是7點不是8點，是每天不是每周；“寫作業(yè)”是對任務(wù)執(zhí)行內(nèi)容的明確，是寫作業(yè)不是看奧特曼；“寫完了讓家長檢查簽字”使得“寫作業(yè)”和“家長檢查簽字”可以解耦為兩個邏輯動作，在孩子寫作業(yè)的時候家長還能看個看書啥的。

言歸正傳，定時任務(wù)的典型落地場景在各行業(yè)中非常普遍：電商中定時開啟促銷活動入口、15天未確認(rèn)收貨則自動確認(rèn)收貨、定點掃描未付款訂單進行短信提醒等；金融保險行業(yè)中也有營銷人員傭金計算、終端營銷報表制作、組織關(guān)系定時同步、日清月清結(jié)算等場景?？偨Y(jié)下來，筆者按照“時間驅(qū)動、批量處理、異步解耦”三個維度來劃分定時任務(wù)的場景類型。

時間驅(qū)動型

以電商場景中定時開啟活動入口為例，一般情況會在后臺配置好活動需要的各種參數(shù)，同時將活動狀態(tài)的動態(tài)配置設(shè)置為關(guān)閉，當(dāng)?shù)竭_執(zhí)行時間后定時任務(wù)自動觸發(fā)后開啟促銷活動。

可見，在時間驅(qū)動型場景中，相比執(zhí)行內(nèi)容而言，業(yè)務(wù)更關(guān)注的是任務(wù)是定時執(zhí)行還是周期執(zhí)行、執(zhí)行具體時間點準(zhǔn)確性、周期頻率的長短等時間因素。

批量處理型

批量處理型任務(wù)的特點在于需要`同時對大量`積累的業(yè)務(wù)對象進行處理。此時，可能有的朋友會問，為什么不使用消息隊列處理？原因是某些特定的場景下，消息隊列并不能夠進行簡單替代，因為消息隊列更多的是通過每個消息進行事件驅(qū)動，偏向更實時的處理。

以保險中傭金結(jié)算業(yè)務(wù)說明，比如營銷人員的傭金計算。營銷人員會從投保人繳納的保費中獲得一定比例的提成，并且這個比例會根據(jù)投保年限、險種的不同而變化，另外可能還會疊加公司的一些傭金激勵政策等。這樣的場景就需要積累一定量的數(shù)據(jù)之后，定時的進行批量計算，而不能每個事件都進行計算。

異步解耦型

說到系統(tǒng)的異步解耦一定又會想到消息隊列，但消息隊列并不能適用某些外部系統(tǒng)數(shù)據(jù)的獲取，比如證券行業(yè)中股票軟件公司對于交易所股票價格的抓取，由于股票價格對于股票軟件公司是外部數(shù)據(jù)，使用消息隊列是很難進行內(nèi)外部系統(tǒng)間異步通訊的。所以，一般情況會通過批處理任務(wù)定時抓取數(shù)據(jù)并存儲，然后后端系統(tǒng)再對數(shù)據(jù)進行分析整理，使得外部數(shù)據(jù)獲取和內(nèi)部數(shù)據(jù)分析處理兩部分邏輯解耦。

前世今生

單機定時任務(wù)

單機定時任務(wù)是最常見的，也是比較傳統(tǒng)的任務(wù)執(zhí)行方式，比如linux內(nèi)置的Crontab。其通過cron表達式中分、時、日、月、周五種時間維度，實現(xiàn)單機定時任務(wù)的執(zhí)行。

# 每晚的21:30重啟smb30 21 * * * /etc/init.d/smb restart

另外，在java中也有內(nèi)置的定時任務(wù)，比如java.util.Timer類和它的升級版ScheduledThreadPoolExecutor，另外在Spring體系中也提供了Spring Task這種通過注解快速實現(xiàn)支持cron表達式的單機定時任務(wù)框架。

@EnableScheduling@Servicepublic class ScheduledConsumerDemo {

    @Value("${consumer.request.echoUrl}")    private String echoUrl;

    /**     * 間隔1秒請求provider的echo接口     *     * @throws InterruptedException     */    @Scheduled(fixedDelayString = "${consumer.auto.test.interval:1000}")    public void callProviderPer1Sec() throws InterruptedException {        String response = restTemplate.getForObject(echoUrl, String.class);    }}

顯而易見的，單機定時任務(wù)在應(yīng)對簡單的業(yè)務(wù)場景是很方便的，但在分布式架構(gòu)已然成為趨勢的現(xiàn)在，單機定時任務(wù)并不能滿足企業(yè)級生產(chǎn)以及工業(yè)化場景的訴求，主要體現(xiàn)在集群任務(wù)配置統(tǒng)一管理、單點故障及單點性能、節(jié)點間任務(wù)的通訊及協(xié)調(diào)、任務(wù)執(zhí)行數(shù)據(jù)匯總等方面。為了滿足企業(yè)級生產(chǎn)的訴求，各類任務(wù)調(diào)度平臺逐步興起。

中心化調(diào)度

典型的中心化調(diào)度框架quartz，其作為任務(wù)調(diào)度界的前輩和帶頭大哥，通過優(yōu)秀的調(diào)度能力、豐富的API接口、Spring集成性好等優(yōu)點，使其一度成為任務(wù)調(diào)度的代名詞。

quartz架構(gòu)中使用數(shù)據(jù)庫鎖保障多節(jié)點任務(wù)執(zhí)行時的唯一性，解決了單點故障的問題。但數(shù)據(jù)庫鎖的集中性也產(chǎn)生了嚴(yán)重的性能問題，比如大批量任務(wù)場景下，數(shù)據(jù)庫成為了業(yè)務(wù)整體調(diào)度的性能瓶頸，同時在應(yīng)用側(cè)還會造成部分資源的等待閑置，另外還做不到任務(wù)的并行分片。

另一款出自大眾點評的框架xxl-job，主要特點在于簡單、易集成、有可視化控制臺，相比quartz主要差異在于：

自研調(diào)度模塊：xxl-job將調(diào)度模塊和任務(wù)模塊解耦的異步化設(shè)計，解決了調(diào)度任務(wù)邏輯偏重時，調(diào)度系統(tǒng)性能大大降低的問題。其中，調(diào)度模塊主要負責(zé)任務(wù)參數(shù)的解析及調(diào)用發(fā)起，任務(wù)模塊則負責(zé)任務(wù)內(nèi)容的執(zhí)行，同時異步調(diào)度隊列和異步執(zhí)行隊列的優(yōu)化，使得有限的線程資源也可支撐一定量的job并發(fā)。
調(diào)度優(yōu)化：通過調(diào)度線程池、并行調(diào)度的方式，極大減小了調(diào)度阻塞的概率，同時提高了調(diào)度系統(tǒng)的承載量。
高可用保障：調(diào)度中心的數(shù)據(jù)庫中會保存任務(wù)信息、調(diào)度歷史、調(diào)度日志、節(jié)點注冊信息等，通過MySQL保證數(shù)據(jù)的持久化和高可用。任務(wù)節(jié)點的故障轉(zhuǎn)移（failover）模式和心跳檢測，也會動態(tài)感知每個執(zhí)行節(jié)點的狀態(tài)。

但由于xxl-job使用了跟quartz類似的數(shù)據(jù)庫鎖機制，所以同樣不能避免數(shù)據(jù)庫成為性能瓶頸以及中心化帶來的其它問題。

去中心化調(diào)度

為了解決中心化調(diào)度存在的各種問題，國內(nèi)開源框架也是八仙過海、盡顯神通，比如口碑還不錯的powerjob、當(dāng)當(dāng)?shù)膃lastic-job、唯品會的saturn。saturn整體上是基于開源的elastic-job進行改進優(yōu)化的，所以本文只針對powerjob和elastic-job做簡要介紹。

powerjob誕生于2020年4月，其中包含了一些比較新的思路和元素，比如支持基于MapReduce的分布式計算、動態(tài)熱加載Spring容器等。在功能上，多任務(wù)工作流編排、MapReduce執(zhí)行模式、延遲執(zhí)行是亮點，同時宣稱所有組件都支持水平擴展，其核心組件說明如下：

powerjob-server：調(diào)度中心，統(tǒng)一部署，負責(zé)任務(wù)調(diào)度和管理；
powerjob-worker：執(zhí)行器，提供單機執(zhí)行、廣播執(zhí)行和分布式計算；
powerjob-client：可選組件，OpenAPI客戶端。

powerjob在解決中心化調(diào)度時的無鎖調(diào)度設(shè)計思路值得借鑒，核心邏輯是通過appName作為業(yè)務(wù)應(yīng)用分組的key，將powerjob-server和powerjob-worker以分組key進行邏輯綁定，即確保每個powerjob-worker集群在運行時只會連接到一臺powerjob-server，這樣就不需要鎖機制來防止任務(wù)被多臺server同時拿到，從而造成重復(fù)執(zhí)行的問題。

雖然powerjob在各方面分析下來相對優(yōu)秀，但畢竟產(chǎn)品迭代周期比較短，仍需要通過市場大規(guī)模應(yīng)用來不斷打磨產(chǎn)品細節(jié)，以驗證產(chǎn)品的性能、易用性和穩(wěn)定性。

elasticjob包含elasticjob-lite和elasticjob-cloud兩個獨立子項目，本文主要以elasticjob-lite為例展開。

elasticjob-lite定位為輕量級無中心化解決方案，在繼承quartz的基礎(chǔ)上，同時使用了zookeeper作為注冊中心。在產(chǎn)品設(shè)計層面上，個人理解elasticjob相比其他分布式任務(wù)調(diào)度框架，更加側(cè)重數(shù)據(jù)處理和計算，主要體現(xiàn)在如下兩方面：

elasticjob-lite的無中心化：

沒有調(diào)度中心的設(shè)計，在業(yè)務(wù)程序引入elasticjob的jar包后，由jar包進行任務(wù)的調(diào)度、狀態(tài)通訊、日志落盤等操作。
每個任務(wù)節(jié)點間都是對等的，會在zookeeper中注冊任務(wù)相關(guān)的信息（任務(wù)名稱、對等實例列表、執(zhí)行策略等），同時依賴zookeeper的選舉機制進行執(zhí)行實例的選舉。

elasticjob-lite的彈性分片：

基于zookeeper，任務(wù)執(zhí)行實例之間可以近乎實時的感知到對方的上下線狀態(tài)，使得任務(wù)分片的分配可以隨著任務(wù)實例數(shù)量的調(diào)整而調(diào)整，并且保證負載相對均勻。
在任務(wù)實例上下線時，并不會影響當(dāng)前的任務(wù)，會在下次任務(wù)調(diào)度的時候重新分片，以避免任務(wù)的重復(fù)執(zhí)行。

通過上述分析，elasticjob更多的是針對分布式任務(wù)計算場景設(shè)計，更適合做大量數(shù)據(jù)的分片計算或處理，尤其對資源利用率有要求的場景下更有優(yōu)勢。

演進過程

在粗略的介紹了各個主流的分布式任務(wù)調(diào)度框架后，一個問題出現(xiàn)了：是哪些主要因素推動了框架一步步發(fā)展演進？筆者簡要概括為如下4個因素：

業(yè)務(wù)復(fù)雜性：原先的業(yè)務(wù)復(fù)雜性低，2、3行代碼就可以搞定；隨著業(yè)務(wù)復(fù)雜性提高，任務(wù)的組織形態(tài)和執(zhí)行內(nèi)容都發(fā)生了很大變化，逐步衍生出任務(wù)編排、框架生態(tài)融合、多語言及多終端支持等訴求。
場景多樣性：不再僅僅是簡單的定時任務(wù)執(zhí)行，類似批量計算、業(yè)務(wù)解耦等場景的問題，也逐步開始使用分布式任務(wù)調(diào)度框架解決。對框架能力的要求在于，更豐富的任務(wù)執(zhí)行策略、動態(tài)分片計算的支持、豐富的任務(wù)治理能力等方面上。

分布式架構(gòu)：分布式架構(gòu)趨勢的全面到來，是最重要的推進因素?？蚣艿恼w設(shè)計須以分布式架構(gòu)為前提，在任務(wù)節(jié)點及調(diào)度中心間的通訊、調(diào)度平臺的高可用、任務(wù)節(jié)點的故障處理及恢復(fù)、任務(wù)調(diào)度可視化運維等方面，都是全新的挑戰(zhàn)。
海量數(shù)據(jù)并發(fā)：當(dāng)海量的業(yè)務(wù)數(shù)據(jù)及并發(fā)調(diào)用成為常態(tài)，就使得分布式任務(wù)調(diào)度平臺需要在執(zhí)行器性能、執(zhí)行時間精準(zhǔn)度、任務(wù)的并行及異步處理、節(jié)點資源彈性管控等方面推進優(yōu)化，以幫助提升平臺整體的吞吐量。

分布式任務(wù)調(diào)度框架的演進，是業(yè)務(wù)系統(tǒng)從單體架構(gòu)向分布式架構(gòu)演進的一個分支。分布式任務(wù)調(diào)度平臺能力的不斷完善，與業(yè)務(wù)架構(gòu)的微服務(wù)化演進不可分割。

同理，目前各行業(yè)的業(yè)務(wù)系統(tǒng)逐步遷移上云，企業(yè)數(shù)字化轉(zhuǎn)型趨勢明顯，未來分布式任務(wù)調(diào)度平臺的演進過程同樣離不開云原生產(chǎn)業(yè)環(huán)境，平臺的整體架構(gòu)需要深度融合云原生體系，才能滿足未來多方面不斷變化的產(chǎn)業(yè)訴求。

“云上”的TCT

分布式任務(wù)調(diào)度服務(wù)（Tencent Cloud Task）是騰訊云自主研發(fā)的一款輕量級、高可靠的分布式任務(wù)調(diào)度平臺。通過指定時間規(guī)則，嚴(yán)格觸發(fā)調(diào)度任務(wù)，保障調(diào)度任務(wù)的可靠、有序執(zhí)行。該服務(wù)支持國際通用的時間表達式、執(zhí)行生命周期管理，解決傳統(tǒng)定時調(diào)度任務(wù)的單點故障及可視化程度低等問題。同時，支持任務(wù)分片、工作流編排等復(fù)雜調(diào)度任務(wù)處理能力，覆蓋廣泛的任務(wù)調(diào)度應(yīng)用場景，如數(shù)據(jù)備份、日志切分、運維監(jiān)控、金融日切等。

功能介紹

TCT在功能方面主要分為三個部分：調(diào)度管理平臺、任務(wù)調(diào)度服務(wù)、開發(fā)集成（SDK）。調(diào)度管理平臺提供優(yōu)雅的可視化界面交互，任務(wù)調(diào)度服務(wù)實現(xiàn)分布式場景下的任務(wù)調(diào)度，開發(fā)集成深度融合開源框架，其中詳細功能特點說明如下

豐富的任務(wù)配置

多種執(zhí)行方式：支持隨機節(jié)點、廣播、分片執(zhí)行方式，滿足不同應(yīng)用場景。
多種觸發(fā)策略：支持定時觸發(fā)、周期觸發(fā)、工作流觸發(fā)、人工手動觸發(fā)策略。
完善的容錯機制：支持異常重試、超時中斷、手動停止等多種任務(wù)容錯保護機制。

可視化的任務(wù)管理

任務(wù)管理視圖：展示任務(wù)的執(zhí)行狀態(tài)，提供新增任務(wù)、編輯任務(wù)、刪除任務(wù)、手動執(zhí)行、啟動/停用任務(wù)等操作能力。
執(zhí)行記錄視圖：展示所有常規(guī)任務(wù)、工作流任務(wù)的執(zhí)行批次詳情列表，支持依據(jù)所屬任務(wù)、部署組為查詢過濾條件。
執(zhí)行列表視圖：展示選定任務(wù)的執(zhí)行批次詳情列表，支持針對任務(wù)批次的停止、重新執(zhí)行操作。
執(zhí)行詳情視圖：展示任務(wù)執(zhí)行批次的執(zhí)行實例列表，支持針對執(zhí)行實例的停止、重新執(zhí)行、日志查詢操作。
工作流管理視圖：展示工作流任務(wù)的執(zhí)行狀態(tài)，提供工作流任務(wù)新建、可視化流程編排、啟動/停用工作流任務(wù)等操作能力。

完善的任務(wù)運行監(jiān)控告警

立體化監(jiān)控：提供任務(wù)運行狀態(tài)、任務(wù)執(zhí)行批次狀態(tài)、執(zhí)行實例運行狀態(tài)的立體化監(jiān)控，支持針對執(zhí)行實例的線上日志查看能力。
靈活告警策略：集成云監(jiān)控能力提供任務(wù)執(zhí)行批次、執(zhí)行實例異常告警，工作流任務(wù)執(zhí)行批次、批次任務(wù)、執(zhí)行實例異常告警能力，支持靈活的指標(biāo)告警及事件告警配置。

架構(gòu)原理

TCT各組件簡介如下：

觸發(fā)器：解析任務(wù)的觸發(fā)規(guī)則
調(diào)度器：派發(fā)需要執(zhí)行的任務(wù)、管理任務(wù)狀態(tài)等
監(jiān)控：任務(wù)執(zhí)行相關(guān)的監(jiān)控數(shù)據(jù)上報
控制臺：管理員的控制臺界面
接入層：任務(wù)下發(fā)、狀態(tài)上報等消息的信道管理器
接入網(wǎng)關(guān)：統(tǒng)一對接接入層及SDK的網(wǎng)關(guān)
SDK：和業(yè)務(wù)進程運行在一起，負責(zé)執(zhí)行任務(wù)中定義的一段具體代碼邏輯

首先，由觸發(fā)器解析用戶在控制臺配置并存入DB的任務(wù)信息，并將解析后的執(zhí)行信息投入到MQ中。其次，由調(diào)度器消費執(zhí)行信息并通過接入層下發(fā)到具體的執(zhí)行器節(jié)點上（接入層中有具體的節(jié)點注冊信息，包括IP地址等）。最后，當(dāng)SDK所在節(jié)點完成任務(wù)的執(zhí)行后（成功、失敗、未響應(yīng)等），會將執(zhí)行結(jié)果通過TCP長連接傳回給調(diào)度器，然后調(diào)度器會跟DB進行交互完成任務(wù)狀態(tài)的變更，同時上報任務(wù)執(zhí)行情況到監(jiān)控模塊。

通過功能簡介可以發(fā)現(xiàn)TCT基本涵蓋了常見的任務(wù)調(diào)度場景中所需功能，尤其在可視化視圖方面做了大量的工作，同時依托騰訊云完備的基礎(chǔ)設(shè)施建設(shè)，在高可用保障和減少運維成本方面也提供了極大保障。此外，TCT源于TSF技術(shù)平臺，對TSF應(yīng)用天然集成，支撐組件可以很方便的獲取TSF應(yīng)用的相關(guān)信息，如TSF部署組ID、節(jié)點IP、應(yīng)用ID等，因此在任務(wù)執(zhí)行效率上也會更高。

不過，由整體架構(gòu)圖發(fā)現(xiàn)TCT采用中心化調(diào)度方案，調(diào)度器、觸發(fā)器及控制臺組件無狀態(tài)，支持水平擴展，組件及SDK間通過TCP長連接通訊；而數(shù)據(jù)流依賴DB及MQ，在任務(wù)數(shù)量大、執(zhí)行頻率高的大規(guī)模落地場景下，DB和MQ的吞吐量就會成為性能卡點，即使可以優(yōu)化也會有明顯上限。所以根據(jù)目前TCT的產(chǎn)品形態(tài)，其更多的適用于輕量級任務(wù)調(diào)度場景。

分片執(zhí)行案例

背景概述

分片執(zhí)行模式是大批量數(shù)據(jù)處理場景下經(jīng)常用到的執(zhí)行方式，本案例以保險行業(yè)中子公司每天向總公司匯總當(dāng)天營銷數(shù)據(jù)的業(yè)務(wù)場景為例進行說明。

從上圖可見，匯總營銷數(shù)據(jù)的服務(wù)（后文稱summarydata）每天凌晨2：00定時調(diào)用34個子公司提供的營銷數(shù)據(jù)查詢API。之所以使用分片執(zhí)行方式，是因為匯總營銷數(shù)據(jù)的操作需要在同一時間觸發(fā)，且整體匯總時間越短越準(zhǔn)確。此外，各公司的營銷數(shù)據(jù)量并不相同，而且即使是相同的子公司每天產(chǎn)生的營銷數(shù)據(jù)量也不相同。

配置步驟

根據(jù)如上業(yè)務(wù)背景描述，同時基于現(xiàn)有資源情況，整體配置思路為：

創(chuàng)建一個summarydata部署組，其中新建4個實例，單個實例線程池數(shù)量為3；
應(yīng)用代碼中將34個子公司一一對應(yīng)到1~34的公司ID上；
根據(jù)大致地域和日均產(chǎn)生的數(shù)據(jù)量，將34家公司劃分到NORTH、SOUTH、EAST、WEST四個區(qū)域；
分片數(shù)量為4，每個分片對應(yīng)到1個實例，即1個實例至少計算1個區(qū)域的數(shù)據(jù)；
每個區(qū)域key對應(yīng)的子公司ID列表可通過代碼配置進行半自動調(diào)整，防止某個子公司數(shù)據(jù)量陡增情況；
為防止統(tǒng)計重復(fù)，不配置任務(wù)自動重試，采用手動補償。

步驟一：觸發(fā)類代碼編寫并打包

javapublic class SimpleShardExecutableTask implements ExecutableTask {

    private final static Logger LOG = LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());

    @Override    public ProcessResult execute(ExecutableTaskData executableTaskData) {        // 輸出任務(wù)執(zhí)行元數(shù)據(jù)        TaskExecuteMeta executeMeta = executableTaskData.getTaskMeta();        LOG.info("executeMetaJson:{}",executeMeta.toString());        // 輸出分配給本實例的分片參數(shù)        ShardingArgs shardingArgs = executableTaskData.getShardingArgs();        LOG.info("ShardCount: {}", shardingArgs.getShardCount());        Integer shardingKey = shardingArgs.getShardKey();        LOG.info("shardingKey: {}", shardingKey);        String shardingValue = shardingArgs.getShardValue();        LOG.info("shardingValue: {}", shardingValue);        // 模擬任務(wù)執(zhí)行        try {            this.doProcess(shardingValue);        } catch (Exception e) {            e.printStackTrace();        }        return ProcessResult.newSuccessResult();    }

    public void doProcess(String shardingValue) throws Exception {        if (shardingValue.equals(CompanyMap.NORTH.area)){            Arrays.stream(CompanyMap.NORTH.companyIds)                    .forEach(companyId->LOG.info("calling north subsidiary_{} api.....",companyId));        } else if(shardingValue.equals(CompanyMap.SOUTH.area)){            Arrays.stream(CompanyMap.SOUTH.companyIds)                    .forEach(companyId->LOG.info("calling south subsidiary_{} api.....",companyId));        } else if(shardingValue.equals(CompanyMap.EAST.area)){            Arrays.stream(CompanyMap.EAST.companyIds)                    .forEach(companyId->LOG.info("calling east subsidiary_{} api.....",companyId));        } else if(shardingValue.equals(CompanyMap.WEST.area)){            Arrays.stream(CompanyMap.WEST.companyIds)                    .forEach(companyId->LOG.info("calling west subsidiary_{} api.....",companyId));        }  else {            throw new Exception("input shardingValue error!");        }        ThreadUtils.waitMs(3000L);    }

    enum CompanyMap{        NORTH("NORTH", new int[]{1, 2, 3, 4, 5, 6, 7, 8, 9}),        SOUTH("SOUTH",new int[]{10,11,12,13,14,15,16,17,18,19}),        EAST("EAST",new int[]{20,21,22,23,24,25,26,27,28}),        WEST("WEST",new int[]{29,30,31,32,33,34});

        private String area;        private int[] companyIds;

        CompanyMap(String key,int[] values){            this.area = key;            this.companyIds = values;        }

        public String getArea() { return area; }        public void setArea(String area) { this.area = area; }        public int[] getCompanyIds() { return companyIds; }        public void setCompanyIds(int[] companyIds) { this.companyIds = companyIds; }    }}

步驟二：創(chuàng)建應(yīng)用及部署組，并完成部署

步驟三：創(chuàng)建TCT任務(wù)

步驟四：手動啟動任務(wù)測試

測試效果

通過控制臺查看實例執(zhí)行情況，同時可通過分片參數(shù)按鈕，查詢某個實例執(zhí)行批次內(nèi)的分片參數(shù)。

通過應(yīng)用日志查看結(jié)果，可發(fā)現(xiàn)有1個實例運行了2個分片任務(wù)，是由于TCT對實例負載情況進行了判斷，選擇了相對空閑的實例。

此外還進行了服務(wù)內(nèi)實例異常的測試，即當(dāng)summarydata服務(wù)中4個實例僅余1個實例正常時任務(wù)的執(zhí)行情況（由于日志較長，筆者節(jié)選了重要部分）?？梢钥吹角?個分片任務(wù)是同時且使用不同線程執(zhí)行的，第4個分片任務(wù)是在前3個任務(wù)執(zhí)行完成后再執(zhí)行的，符合預(yù)期。

未來方向

分布式任務(wù)調(diào)度平臺框架間的競爭過程漫長而膠著，各家廠商都在尋求產(chǎn)品價值上的突破口，TCT也仍有很多不足，需要從市場需求和技術(shù)趨勢的角度持續(xù)深度思考。針對分布式任務(wù)調(diào)度市場，筆者粗略總結(jié)了如下幾點未來產(chǎn)品可能的優(yōu)化方向：

1.去中心化

中心化的分布式任務(wù)調(diào)度平臺缺點明顯，難以支撐企業(yè)大規(guī)模落地場景。同時，市場中的產(chǎn)品及技術(shù)演進趨勢逐漸向去中心化發(fā)展，原因在于去中心化的分布式任務(wù)調(diào)度平臺才具有大規(guī)模商業(yè)化落地的可能，成功的商業(yè)化落地案例也是產(chǎn)品走向成熟的標(biāo)志。

2. 容器化

分布式任務(wù)調(diào)度平臺組件及組件間通訊目前多為傳統(tǒng)虛機方式，如果能同時實現(xiàn)支撐組件的容器化部署，就可以更好的發(fā)揮容器平臺快速啟停、資源調(diào)度、水平擴展等方面的優(yōu)勢，以提高支撐側(cè)整體可用性，減少擴縮容時的運維成本，有效提升平臺整體的吞吐量，而高可用、彈性擴縮、高性能是大型企業(yè)數(shù)字化轉(zhuǎn)型云原生的重要考量因素。

3. 可編程

越來越多的分布式任務(wù)場景需要針對多個任務(wù)做復(fù)雜的任務(wù)編排，目前主流的編排仍局限于任務(wù)間串行、并行、與或等簡單的邏輯處理。未來更多的需要一種通用的、可編程的模板語言，用于描述任務(wù)參數(shù)及內(nèi)容、DAGS（有向無環(huán)圖）、操作符、觸發(fā)動作等，標(biāo)準(zhǔn)化各家廠商對于任務(wù)編排的定義方式。

4. 容錯補償

在任務(wù)及工作流執(zhí)行異常時的處理策略也有很多方面需要完善，比如由于實例夯死導(dǎo)致的過時觸發(fā)問題、任務(wù)追趕和任務(wù)堆積問題、工作流場景下任務(wù)異常后是整體重試還是斷點續(xù)傳重試等。

5. 場景升級

目前各家產(chǎn)品在常見的定時任務(wù)場景中，功能同質(zhì)化程度比較高。但隨著云原生、大數(shù)據(jù)等相關(guān)領(lǐng)域的快速發(fā)展，分布式任務(wù)調(diào)度平臺也逐漸產(chǎn)生了新的應(yīng)用場景，如大數(shù)據(jù)場景下的分布式計算及計算匯總、調(diào)度平臺對接serverless應(yīng)用等，這都對產(chǎn)品的場景和功能提出更高的要求。

尾聲

通過對定時任務(wù)的場景、演進歷史、各平臺框架的介紹以及騰訊云自研分布式任務(wù)調(diào)度框架TCT的實踐案例描述，筆者繼前人的基礎(chǔ)上對分布式任務(wù)調(diào)度框架的應(yīng)用現(xiàn)狀和未來發(fā)展進行了簡要分析，之前知道的和不知道的現(xiàn)在讀者朋友應(yīng)該都知道了。謹(jǐn)希望本文能在技術(shù)選型及開源建設(shè)方面提供些許思路和視角，供企業(yè)和開源社區(qū)參考。

往期