任務(wù)調(diào)度平臺是關(guān)鍵的軟件基礎(chǔ)設(shè)施，專門設(shè)計用于自動化、高效和可靠地安排及執(zhí)行預(yù)定的后臺任務(wù)。谷歌云首席決策工程師Kasim Khan曾提到：“在云計算環(huán)境中，自動化和效率是關(guān)鍵?！比蝿?wù)調(diào)度平臺通過優(yōu)化資源使用和集中管理功能，提供了一系列強(qiáng)大的調(diào)度策略、執(zhí)行管理、監(jiān)控報警和開發(fā)者工具，極大地簡化了任務(wù)調(diào)度的復(fù)雜性，從而提升了系統(tǒng)的自動化水平和運(yùn)維效率。此外，任務(wù)調(diào)度平臺作為企業(yè)數(shù)字化轉(zhuǎn)型的核心組件，以其出色的可擴(kuò)展性和靈活性，成為企業(yè)適應(yīng)快速變化的市場需求的關(guān)鍵支撐。

1 項目簡介

任務(wù)調(diào)度平臺（簡稱：PJob），作為數(shù)字化能力中心通用技術(shù)能力微服務(wù)治理的重要模塊，目前已支持HTTP任務(wù)、Elastic Job任務(wù)及XXL-Job三種任務(wù)類型的接入。它憑借彈性調(diào)度、資源管控及作業(yè)治理的功能，配合其開放式的架構(gòu)設(shè)計，致力于建成一個高可用、可監(jiān)控與可追溯的分布式調(diào)度解決方案。

1.1 項目背景介紹

碧桂園服務(wù)（以下簡稱“碧服”）每年都有大量的任務(wù)調(diào)度需求。為此，我們對碧服的應(yīng)用系統(tǒng)進(jìn)行調(diào)研，發(fā)現(xiàn)任務(wù)調(diào)度的實現(xiàn)方式五花八門，導(dǎo)致任務(wù)的發(fā)布、擴(kuò)容、監(jiān)控、高可用和權(quán)限控制無法集中管理，這大大增加了定時任務(wù)執(zhí)行問題的排查難度。

因此，引入一個集中的、標(biāo)準(zhǔn)化的任務(wù)調(diào)度平臺對于解決以上問題至關(guān)重要。這樣的平臺可以提供統(tǒng)一的調(diào)度中心，支持高可用性和高容錯性，同時簡化任務(wù)管理和監(jiān)控，并減少資源浪費(fèi)。

1.2?項目實現(xiàn)目標(biāo)及達(dá)成效果

任務(wù)調(diào)度平臺的建設(shè)填補(bǔ)了技術(shù)數(shù)字化管理中關(guān)于任務(wù)調(diào)度流程化的空白，并提供了高效的任務(wù)調(diào)度開發(fā)工具。該平臺實現(xiàn)了故障實時工單送達(dá)，確保告警事件100%觸達(dá)系統(tǒng)管理員，有效提高系統(tǒng)的可用率，且問題排查時間也從數(shù)小時縮短至數(shù)分鐘。具體體現(xiàn)如下：

高可用保障機(jī)制：通過集群和輪檢機(jī)制，無論是輕量接入還是定制化開發(fā)，都能享受到高可用性的保障。集群的橫向擴(kuò)展能力，解決了潛在的性能瓶頸問題；

統(tǒng)一技術(shù)標(biāo)準(zhǔn)：減少了因分散的技術(shù)棧帶來的維護(hù)負(fù)擔(dān)，降低了各系統(tǒng)重復(fù)建設(shè)的成本，為任務(wù)調(diào)度功能提供了快速接入的建設(shè)方案，促進(jìn)了技術(shù)的標(biāo)準(zhǔn)化和統(tǒng)一化；

完善技術(shù)管理：實施了對任務(wù)調(diào)度管理的流程化操作，提高了運(yùn)維效率。運(yùn)行數(shù)據(jù)作為一種數(shù)據(jù)資產(chǎn)，為技術(shù)決策提供了數(shù)據(jù)支持，增強(qiáng)了管理的科學(xué)性和精確性；

縮短業(yè)務(wù)故障時間：故障發(fā)生時，第一時間通過釘釘發(fā)送告警，使得管理員可以通過線上平臺即時查看執(zhí)行器、任務(wù)的狀態(tài)以及任務(wù)的執(zhí)行過程記錄等，加快了故障響應(yīng)和處理的速度。

當(dāng)前任務(wù)調(diào)度平臺已成功支持碧服內(nèi)部11個系統(tǒng)的接入，且每年可處理上千萬次的任務(wù)調(diào)度。以下的兩個案例，充分展示了該平臺的實際效果：

1、新傳媒系統(tǒng)

新傳媒系統(tǒng)作為首批接入任務(wù)調(diào)度平臺的系統(tǒng)，已經(jīng)穩(wěn)定運(yùn)行近兩年時間，每年處理近百萬次的調(diào)度任務(wù)。新傳媒系統(tǒng)此前采用Elastic-Job技術(shù)棧，它在接入任務(wù)調(diào)度平臺時幾乎是0成本接入。接入后，新傳媒系統(tǒng)節(jié)省下了注冊中心與服務(wù)端資源的使用，并且提供了更豐富的追溯功能。在規(guī)范化的管理流程下，任務(wù)調(diào)度的成功率長期保持在100%。

2、大管家

大管家承載著碧服大量的運(yùn)營管理工作，對任務(wù)調(diào)度的穩(wěn)定性有較高的要求。在之前，大管家采用的是阿里云的商業(yè)產(chǎn)品SchedulerX來支持其任務(wù)調(diào)度需求，每月需花費(fèi)數(shù)千元云服務(wù)費(fèi)用。

經(jīng)過深入調(diào)研和技術(shù)評估，任務(wù)調(diào)度平臺已經(jīng)具備了滿足大管家的大部分應(yīng)用場景的能力。基于這一發(fā)現(xiàn)，大管家將兩個應(yīng)用接入到任務(wù)調(diào)度平臺上。這一轉(zhuǎn)變不僅確保了任務(wù)調(diào)度的穩(wěn)定性，還為其省下了云服務(wù)的費(fèi)用，實現(xiàn)了運(yùn)營成本的顯著降低。

通過前文，我們已經(jīng)對任務(wù)調(diào)度平臺有了大概的認(rèn)識。接下來，我們將重點探討任務(wù)調(diào)度平臺在分布式任務(wù)調(diào)度領(lǐng)域的應(yīng)用，著重從“快速接入”和“穩(wěn)定運(yùn)行”兩個方面進(jìn)行闡述。

2?從0到1，快速搭建任務(wù)調(diào)度

任務(wù)調(diào)度平臺支持三種任務(wù)類型：

2.1?輕量級HTTP任務(wù)

HTTP任務(wù)是任務(wù)調(diào)度最簡單的任務(wù)類型，只需提供內(nèi)網(wǎng)公開訪問的URL，通過HTTP協(xié)議觸發(fā)任務(wù)執(zhí)行，無需便攜任何額外的編碼，就可通過簡單的平臺配置完成定時調(diào)度功能。

HTTP任務(wù)調(diào)度由平臺發(fā)起，任務(wù)的加載與持久化由平臺進(jìn)行管理。因此，接入系統(tǒng)不需要開發(fā)，沒有額外的資源占用，適合輕量級簡單接入的需求。

2.2 原生Elastic Job任務(wù)

Elastic Job是一個廣泛使用的分布式調(diào)度解決方案，它是Apache ShardingSphere的子項目。由于任務(wù)調(diào)度平臺在底層采用了Elastic Job，因此它能夠提供對Elastic Job的原生支持，非常適合那些在復(fù)雜業(yè)務(wù)場景下需要高度彈性伸縮和分片能力的系統(tǒng)。

Elastic Job本身是無中心化架構(gòu)，無需獨(dú)立的中心化調(diào)度節(jié)點。在分布式環(huán)境中，每個任務(wù)節(jié)點都能夠自主地調(diào)度作業(yè)。為了協(xié)調(diào)分布式環(huán)境中的任務(wù)狀態(tài)，只需要一個注冊即可。任務(wù)調(diào)度平臺提供了一個定制化的Elastic Job SDK，增加了注冊中心的接入和任務(wù)初始化管理功能。平臺將注冊中心作為資源進(jìn)行管理，并負(fù)責(zé)任務(wù)的初始化控制，從而使得接入方無需部署額外的注冊中心服務(wù)，只需關(guān)注任務(wù)的開發(fā)。

2.3 中心調(diào)度，XXL-Job支持

XXL-Job是一個廣受歡迎的輕量級分布式任務(wù)調(diào)度框架，在開源社區(qū)中非常流行。它以其簡單的操作和豐富的功能特性被多個系統(tǒng)所采用。任務(wù)調(diào)度平臺兼容XXL-Job任務(wù)接口，這意味著無需進(jìn)行任何代碼修改，就可以將現(xiàn)有的XXL-Job任務(wù)遷移到任務(wù)調(diào)度平臺上進(jìn)行托管。XXL-Job的運(yùn)行態(tài)如下：

3?穩(wěn)定運(yùn)行，平臺化管理與監(jiān)控

3.1 快速運(yùn)維實時監(jiān)控

任務(wù)調(diào)度平臺提供了一個用戶友好的WEB管理界面，該界面不僅支持任務(wù)的創(chuàng)建、觸發(fā)與禁用等功能，還實現(xiàn)了與釘釘預(yù)警系統(tǒng)的對接。這樣，平臺能夠?qū)崟r監(jiān)控各調(diào)度器和執(zhí)行器的運(yùn)行狀態(tài)，以及任務(wù)的執(zhí)行歷史。

盡管程序員在開發(fā)過程中已經(jīng)在盡力避免引入錯誤，但問題有時仍然不可避免地出現(xiàn)。因此，快速的問題定位和解決是所有程序員都追求的目標(biāo)。在這方面，任務(wù)調(diào)度平臺在進(jìn)行了以下幾方面的嘗試：

1、報警更直觀

用戶可以在創(chuàng)建Job時，可以配置告警接收人。當(dāng)平臺檢測到對應(yīng)Job問題時，它會通過機(jī)器人將相應(yīng)的報警信息實時推送給指定的告警人，從而實現(xiàn)了快速響應(yīng)和問題處理。

2、任務(wù)執(zhí)行過程可追溯

通過WEB界面，可以查看任務(wù)實現(xiàn)狀態(tài)與最新的執(zhí)行記錄，接入方可以通過任務(wù)調(diào)度平臺提供的定制版日志收集工具，接入后可在平臺上查看任務(wù)的執(zhí)行過程記錄。

3、執(zhí)行器狀態(tài)更清晰

平臺除了支持實時查看任務(wù)執(zhí)行，還能實時查看接入方各執(zhí)行器狀態(tài)，實時監(jiān)控物理資源的運(yùn)行。

3.2 削峰填谷，執(zhí)行日志模塊的平臺化改造

執(zhí)行日志模塊在任務(wù)調(diào)度平臺中扮演著重要的角色。它不僅負(fù)責(zé)記錄任務(wù)的執(zhí)行過程，為后續(xù)的任務(wù)追溯提供依據(jù)，還是任務(wù)告警機(jī)制和任務(wù)編排依賴的基礎(chǔ)。任務(wù)之間的依賴關(guān)系和執(zhí)行順序都需要依靠穩(wěn)定而高效的執(zhí)行日志模塊來支持。

在任務(wù)執(zhí)行過程中，無論是擴(kuò)散流量還是非擴(kuò)散流量，最終都會流向DB。因此，流量控制的目標(biāo)變得非常明確：關(guān)鍵在于對數(shù)據(jù)庫的流量進(jìn)行有效控制。

任務(wù)調(diào)度平臺執(zhí)行結(jié)果日志使用MySQL保存，執(zhí)行的過程保存到非關(guān)系型的ElasticsSearch中。這種優(yōu)化改造的目標(biāo)主要是針對需要實時性更高的執(zhí)行結(jié)果日志，分以下三部分進(jìn)行優(yōu)化改造：

1、SDK端改造支持

原生的Elastic Job SDK只支持RDB類型直接寫數(shù)據(jù)庫的數(shù)據(jù)持久化方案。由于Elastic Job考慮的是單個系統(tǒng)的分布式調(diào)度支持，對平臺化不是很友好，限制了其在平臺化場景下的使用。為了解決這個問題，我們對SDK進(jìn)行改造，使其支持以REST API形式將結(jié)果日志向外報送。

2、平臺端削峰填谷

在平臺化場景下，關(guān)系型數(shù)據(jù)庫作為存儲很容易被打爆，因此引入消息中間件進(jìn)行削峰填谷是一種有效的優(yōu)化方案。我們通過將日志流量引入MQ，可以獲得對執(zhí)行日志的主動權(quán)，并為日志分析、任務(wù)依賴編寫鉤子函數(shù)提供了可能。

3、DB分區(qū)表優(yōu)化

為了改善執(zhí)行日志表的可伸縮性與可管理性，提高數(shù)據(jù)庫的效率，我們對DB進(jìn)行了分區(qū)表的改造。由于執(zhí)行日志的記錄表非常大，每月增長兩三百萬條，并且日志型數(shù)據(jù)具有時間屬性，因此我們選擇以時間維度進(jìn)行區(qū)分。通過按月進(jìn)行歸檔清理，我們可以保障當(dāng)期數(shù)據(jù)在可操控的范圍內(nèi)。優(yōu)化后的分區(qū)表在以下幾個方面得到顯著提升：

性能提升：在處理大量數(shù)據(jù)時，傳統(tǒng)的單一表結(jié)構(gòu)可能導(dǎo)致查詢和維護(hù)操作的性能下降。通過使用分區(qū)策略，我們能夠針對特定分區(qū)進(jìn)行操作和查詢，從而顯著提高系統(tǒng)性能；

更容易維護(hù)：分區(qū)技術(shù)簡化了維護(hù)任務(wù)，如備份和恢復(fù)。我們可以獨(dú)立地對每個分區(qū)執(zhí)行這些操作，無需影響整個操作表；

更好的并發(fā)性：利用分區(qū)，我們可以實現(xiàn)更高的并發(fā)性能。由于可以在不同的分區(qū)上并行執(zhí)行某些操作，而無需鎖定整個表，因此系統(tǒng)的并發(fā)處理能力得到增強(qiáng)；

數(shù)據(jù)管理：分區(qū)可以更輕松地管理數(shù)據(jù)，特別是對于具有時效性的數(shù)據(jù)。舊數(shù)據(jù)需要被歸檔或刪除，而不是在整個表中操作，這使得數(shù)據(jù)管理更加高效和有序。

4?摸清脈絡(luò)，簡述實現(xiàn)原理

本文不對任務(wù)調(diào)度平臺所支持的定時任務(wù)調(diào)度策略作過多贅述，以下是對任務(wù)調(diào)度平臺實現(xiàn)原理以圖文的方式做一個簡述。

4.1 概要設(shè)計

4.2 調(diào)度流程

任務(wù)調(diào)度平臺基于開源的分布式調(diào)度框架Elastic Job，其運(yùn)行流程主要包括：

1、用戶通過控制臺（Console）創(chuàng)建應(yīng)用（APP），并在應(yīng)用中完成任務(wù)（Job）創(chuàng)建。通過控制臺的API對任務(wù)進(jìn)行持久化存儲；

2、調(diào)度器集群（SC）啟動，會加載應(yīng)用和任務(wù)信息，并將自身以及這些任務(wù)注冊到注冊中心（ZK）；

3、調(diào)度器（Scheduler）在預(yù)定的時間準(zhǔn)時準(zhǔn)確找到待觸發(fā)的任務(wù)，并找出與之關(guān)聯(lián)的執(zhí)行器，將任務(wù)分配給它們；

4、執(zhí)行器（Executor）接收調(diào)度任務(wù)后，會創(chuàng)建任務(wù)實例（Job Instance）并執(zhí)行，同時將結(jié)果和執(zhí)行過程上報給調(diào)度器，也會更新自身的狀態(tài)信息；

5、調(diào)度器接收到執(zhí)行器的反饋后，通過控制臺的API對結(jié)果進(jìn)行持久化，并定期向控制臺報告自身的狀態(tài)；

6、控制臺收集所有的信息，為用戶提供各類監(jiān)控數(shù)據(jù)。

總的來說，任務(wù)調(diào)度平臺的核心工作就是在「指定時間」「通知執(zhí)行器」以「指定方式」執(zhí)行任務(wù)。

5 總結(jié)

本文簡潔地概述了任務(wù)調(diào)度平臺的基本原理和工作流程，盡管這些原理看似簡單明了，但作為一個中間件平臺，它必須確保任務(wù)調(diào)度過程的實時性和穩(wěn)定性。此外，平臺還需要開發(fā)各種復(fù)雜的任務(wù)執(zhí)行策略，并具備處理大量任務(wù)調(diào)度請求的性能。而且，支持海量日志數(shù)據(jù)的存儲與快速查詢也是其關(guān)鍵職責(zé)之一。

統(tǒng)一任務(wù)調(diào)度平臺的核心價值在于實現(xiàn)了任務(wù)調(diào)度流程的平臺化管理。為了保持平臺的高效運(yùn)行，需要持續(xù)地進(jìn)行運(yùn)營和優(yōu)化工作。在此過程中，感謝那些曾與我并肩作戰(zhàn)的隊友們，他們的努力和奉獻(xiàn)是平臺能夠順利運(yùn)行的關(guān)鍵。未來也希望有更多人能投入到基礎(chǔ)技術(shù)的賦能工作中，共同推動技術(shù)的進(jìn)步和創(chuàng)新。

本文作者：戚思曉，碧桂園服務(wù)產(chǎn)品研發(fā)高/級工程師，擁有12年IT行業(yè)經(jīng)驗。