SchedulerX 如何帮助用户解决分布式任务调度难题？

作者：千习

前言

在各类业务系统场景中，存在着大量定时触发、周期触发运行指定业务任务的需求场景，而分布式任务调度中间件平台存在的意义就是为管理支撑上述场景而存在。在 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.comspring.schedulerx2.groupId=qianxi.textspring.schedulerx2.appKey=lYgR6qq**********

其他说明

完成上述步骤后，可进行后续应用下具体业务定时任务创建和开发，后续使用详见官方手册，点击此处即可前往！

总结

本文分别对任务调度平台的资源定义、可视化管控能力、分布式批处理能力进行了简述，并基于 SchedulerX 的能力结合实际业务场景提供了一些基础参考案例。希望通过上述内容能让大家方便地熟悉任务调度平台接入使用概况，对于现有用户也可结合自身团队特点进行平台资源管控隔离，以及在产品业务量增长后通过分布式批处理能力来提升处理效率。

后续 SchedulerX 将继续提升可视化管控能力来服务企业级定时任务管理需要，并且平台管控和定时调度服务能力将会逐步兼容市面上常见开源组件客户端。我们也会结合实际场景，继续进行逐个剖析讲解，敬请期待。