作者：千習
前言
在各類業務系統場景中，存在著大量定時觸發、周期觸發運行指定業務任務的需求場景，而分布式任務調度中間件平臺存在的意義就是為管理支撐上述場景而存在，在 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 將繼續提升可視化管控能力來服務企業級定時任務管理需要，并且平臺管控和定時調度服務能力將會逐步兼容市面上常見開源組件客戶端，我們也會結合實際場景，繼續進行逐個剖析講解，敬請期待，
發布云原生技術最新資訊、匯集云原生技術最全內容，定期舉辦云原生活動、直播，阿里產品及用戶最佳實踐發布，與你并肩探索云原生技術點滴，分享你需要的云原生內容，
關注【阿里巴巴云原生】公眾號，獲取更多云原生實時資訊！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/423941.html
標籤：其他
上一篇：平安保隙訓于 SPI 機制的 RocketMQ 定制化應用
下一篇：如何做“健康碼”的性能壓測