作者：千習

前言

在各類業務系統場景中，存在著大量定時觸發、週期觸發執行指定業務任務的需求場景，而分散式任務排程中介軟體平臺存在的意義就是為管理支撐上述場景而存在。在 Linux 中的 crontab、Java 中的 Timer 等等都涉及週期性定時排程執行任務來完成一系列自動化處理的業務場景。

週期定時執行是任務排程最為基礎的特性，但隨著業務擴張和發展對於任務排程中介軟體平臺的能力將會提出更高要求。在傳統業務系統中 Quartz 以及 Spring scheduling 包以框架整合方式給業務開發定時任務提供了很多便利，但伴隨各個業務應用分散式和微服務化部署後，大量分散的定時任務散部在各個業務應用系統之中很難對全域性所有任務的統一視覺化監控運維管理，分散式任務排程中介軟體平臺將對各個定時任務進行有效地統一視覺化管控。

分散式任務排程平臺以高可靠的定時任務排程為核心基礎，以視覺化管控為核心價值體現，結合業務發展趨勢圍繞這兩個基本要素進行平臺能力拓展。

SchedulerX 概覽

平臺資源管理

站在全局面向所有業務應用統一運維管控視角，對團隊和部署環境抽象了“空間”概念來進行資源管理隔離，對業務應用和機器叢集進行了一層抽象稱為“應用分組”。每一個業務應用可在排程平臺上建立對應應用分組與其實際對業務應用程式進行對接，從而實現各個業務團隊在統一的平臺上互不干涉的分別管控各自業務團隊的任務。並且在阿里雲上基於 RAM 許可權策略，可統一進行合理的資源許可權管控隔離。

通過上述資源模型業務平臺架構管理者可根據自身團隊的組織特點，進行空間和應用的合理規劃以及許可權策略配置，清晰地實現任務排程資源的訪問控制隔離和全域性性管控。

平臺視覺化管控

任務是任務排程平臺管控排程操作的基本單元，任務執行視覺化使原本藏在各個業務應用中默默奔跑的任務得以重見天日，讓每一個任務的執行狀況和執行結果得以展現和提醒。在沒有視覺化的情況下，任務執行狀態以及執行結果將無從知曉或者是很難被發覺，甚至於經過大量業務迭代發展之後，應用系統中存在多少定時任務都無法進行規範化管理。

分散式分片批處理

隨著業務體量推進發展，在一些定時排程任務場景下會伴隨著大資料量分散式批量處理需求。協調多個機器來定期完成大批量資料處理也成為了任務排程平臺重要功能特性，通過分散式批處理模型，使用者可簡單地實現大批量資料處理效率提升。

簡單運用場景

下面將基於任務排程平臺，針對性地列舉幾個簡單的業務使用場景，以初步瞭解在任務排程平臺上都能做些什麼事情。

基於廣播叢集運維場景

在廣播模式下，建立的排程任務會以給定的週期頻率將任務執行的指令下發給業務應用叢集或安裝了 Agent 的 ECS 叢集，當新擴容加入的資源也會後隨後動態廣播到。基於該功能特性，使用者可以架構出很多自定義的使用場景，例如：

• 日誌/臨時資料定期清理：對業務產生的日誌或臨時檔案進行定期清理。

• 伺服器檢測：使用者可通過廣播shell指令碼快速構建簡單的伺服器磁碟/記憶體/CPU 等健康檢測場景。

• 業務快取重新整理：對於存在本地快取的業務場景，可定期進行快取重新整理以及指定的業務應用服務預熱處理。

• 業務服務檢測：使用者可自定義各種業務型別指標採集判斷，基於排程平臺靈活構建輕量級的業務監控。

定時業務場景

各行業業務場景中，在任務排程平臺上進行定時任務處理，是最為廣泛的業務形式，例如：

• 定期傳送訊息提醒：繳款繳費提醒、積分到期提醒、客戶員工生日祝福提醒、交易訂單處理通知等等。

• 定期資料同步處理：員工組織結構資訊同步、業務基礎資訊同步、定時每天業務資料批量清算、交易訂單超時處理等等。

• 定期資料生成推送：月/季/年度報表生成推送、活動公告定期推送、消費賬單定期生成推送等等。

當上述業務需處理的資料體量逐漸擴大後，原本單機處理模式下處理效率瓶頸會慢慢出現，此時任務排程的分散式叢集批處理的能力將可以發揮叢集協同能力來進行大批量的資料並行處理。

分散式批處理場景

基於業務批量處理能力，當實時業務量較大時使用者可以配合服務降級策略構建業務定期批量補償任務，來實現峰值業務處理能力提升，以確保業務高峰時期核心業務的吞吐能力。作為業務系統平臺的架構設計者，如果能將定時分散式批處理能力與具體業務進行有效結合將充分發揮系統整體的業務處理能力和穩定性。下面對相關業務使用場景進行抽象總結闡述以供參考。

在常規場景下核心交易服務可能會通過 RPC/MQ 完成下游服務的呼叫處理。但這種模式下當業務量上漲時會產生一些問題，RPC 下游服務能力會影響核心服務吞吐能力，對 MQ 依賴時需要保證訊息投遞正常且消費端正確處理，這些都會成為核心服務處理能力提升的瓶頸。因此在業務接受範圍內，採取業務服務間徹底解耦的定期批處理補償的方式將大大提升處理效率，並且通過冪等性可重複執行將提升下游服務可靠性保障，同時結合分散式批處理模型可對資料進行批量載入、批量處理以降低 DB 互動壓力。同時在架構設計上該補償模式可與微服務服務降級配套整合使用。

快速接入 SchedulerX

建立應用分組

進入任務排程控制檯後選擇“公網”region，首先在“應用管理”->建立應用，該應用資訊將會成為後續步驟中業務應用程式、Agent 與任務排程平臺直接建立對接關係的核心元素。

SpringBoot 工程引入 SchedulerX

在本地構建的 SpringBoot 工程中新增如下依賴，並在 Properties 中新增對應控制檯建立的應用分組配置資訊，啟動應用即可完成業務應用與任務排程平臺關係建立。

<dependencies>
  <dependency>
    <groupId>com.aliyun.schedulerx</groupId>
    <artifactId>schedulerx2-spring-boot-starter</artifactId>
    <version>1.3.2</version>
  </dependency>
</dependencies>

# 公有云公網環境
spring.schedulerx2.namespace=aad167f6-8bee-41a7-ba41-*********
spring.schedulerx2.endpoint=acm.aliyun.com
spring.schedulerx2.groupId=qianxi.text
spring.schedulerx2.appKey=lYgR6qq**********

其他說明

完成上述步驟後，可進行後續應用下具體業務定時任務建立和開發，後續使用詳見官方手冊，點選此處即可前往！

總結

本文分別對任務排程平臺的資源定義、視覺化管控能力、分散式批處理能力進行了簡述，並基於 SchedulerX 的能力結合實際業務場景提供了一些基礎參考案例。希望通過上述內容能讓大家方便地熟悉任務排程平臺接入使用概況，對於現有使用者也可結合自身團隊特點進行平臺資源管控隔離，以及在產品業務量增長後通過分散式批處理能力來提升處理效率。

後續 SchedulerX 將繼續提升視覺化管控能力來服務企業級定時任務管理需要，並且平臺管控和定時排程服務能力將會逐步相容市面上常見開源元件客戶端。我們也會結合實際場景，繼續進行逐個剖析講解，敬請期待。

釋出雲原生技術最新資訊、彙集雲原生技術最全內容，定期舉辦雲原生活動、直播，阿里產品及使用者最佳實踐釋出。與你並肩探索雲原生技術點滴，分享你需要的雲原生內容。

關注【阿里巴巴雲原生】公眾號，獲取更多雲原生實時資訊！