任务调度平台是关键的软件基础设施，专门设计用于自动化、高效和可靠地安排及执行预定的后台任务。谷歌云首席决策工程师Kasim Khan曾提到：“在云计算环境中，自动化和效率是关键。”任务调度平台通过优化资源使用和集中管理功能，提供了一系列强大的调度策略、执行管理、监控报警和开发者工具，极大地简化了任务调度的复杂性，从而提升了系统的自动化水平和运维效率。此外，任务调度平台作为企业数字化转型的核心组件，以其出色的可扩展性和灵活性，成为企业适应快速变化的市场需求的关键支撑。

1 项目简介

任务调度平台（简称：PJob），作为数字化能力中心通用技术能力微服务治理的重要模块，目前已支持HTTP任务、Elastic Job任务及XXL-Job三种任务类型的接入。它凭借弹性调度、资源管控及作业治理的功能，配合其开放式的架构设计，致力于建成一个高可用、可监控与可追溯的分布式调度解决方案。

1.1 项目背景介绍

碧桂园服务（以下简称“碧服”）每年都有大量的任务调度需求。为此，我们对碧服的应用系统进行调研，发现任务调度的实现方式五花八门，导致任务的发布、扩容、监控、高可用和权限控制无法集中管理，这大大增加了定时任务执行问题的排查难度。

因此，引入一个集中的、标准化的任务调度平台对于解决以上问题至关重要。这样的平台可以提供统一的调度中心，支持高可用性和高容错性，同时简化任务管理和监控，并减少资源浪费。

1.2 项目实现目标及达成效果

任务调度平台的建设填补了技术数字化管理中关于任务调度流程化的空白，并提供了高效的任务调度开发工具。该平台实现了故障实时工单送达，确保告警事件100%触达系统管理员，有效提高系统的可用率，且问题排查时间也从数小时缩短至数分钟。具体体现如下：

高可用保障机制：通过集群和轮检机制，无论是轻量接入还是定制化开发，都能享受到高可用性的保障。集群的横向扩展能力，解决了潜在的性能瓶颈问题；

统一技术标准：减少了因分散的技术栈带来的维护负担，降低了各系统重复建设的成本，为任务调度功能提供了快速接入的建设方案，促进了技术的标准化和统一化；

完善技术管理：实施了对任务调度管理的流程化操作，提高了运维效率。运行数据作为一种数据资产，为技术决策提供了数据支持，增强了管理的科学性和精确性；

缩短业务故障时间：故障发生时，第一时间通过钉钉发送告警，使得管理员可以通过线上平台即时查看执行器、任务的状态以及任务的执行过程记录等，加快了故障响应和处理的速度。

当前任务调度平台已成功支持碧服内部11个系统的接入，且每年可处理上千万次的任务调度。以下的两个案例，充分展示了该平台的实际效果：

1、新传媒系统

新传媒系统作为首批接入任务调度平台的系统，已经稳定运行近两年时间，每年处理近百万次的调度任务。新传媒系统此前采用Elastic-Job技术栈，它在接入任务调度平台时几乎是0成本接入。接入后，新传媒系统节省下了注册中心与服务端资源的使用，并且提供了更丰富的追溯功能。在规范化的管理流程下，任务调度的成功率长期保持在100%。

2、大管家

大管家承载着碧服大量的运营管理工作，对任务调度的稳定性有较高的要求。在之前，大管家采用的是阿里云的商业产品SchedulerX来支持其任务调度需求，每月需花费数千元云服务费用。

经过深入调研和技术评估，任务调度平台已经具备了满足大管家的大部分应用场景的能力。基于这一发现，大管家将两个应用接入到任务调度平台上。这一转变不仅确保了任务调度的稳定性，还为其省下了云服务的费用，实现了运营成本的显著降低。

通过前文，我们已经对任务调度平台有了大概的认识。接下来，我们将重点探讨任务调度平台在分布式任务调度领域的应用，着重从“快速接入”和“稳定运行”两个方面进行阐述。

2 从0到1，快速搭建任务调度

任务调度平台支持三种任务类型：

2.1 轻量级HTTP任务

HTTP任务是任务调度最简单的任务类型，只需提供内网公开访问的URL，通过HTTP协议触发任务执行，无需便携任何额外的编码，就可通过简单的平台配置完成定时调度功能。

HTTP任务调度由平台发起，任务的加载与持久化由平台进行管理。因此，接入系统不需要开发，没有额外的资源占用，适合轻量级简单接入的需求。

2.2 原生Elastic Job任务

Elastic Job是一个广泛使用的分布式调度解决方案，它是Apache ShardingSphere的子项目。由于任务调度平台在底层采用了Elastic Job，因此它能够提供对Elastic Job的原生支持，非常适合那些在复杂业务场景下需要高度弹性伸缩和分片能力的系统。

Elastic Job本身是无中心化架构，无需独立的中心化调度节点。在分布式环境中，每个任务节点都能够自主地调度作业。为了协调分布式环境中的任务状态，只需要一个注册即可。任务调度平台提供了一个定制化的Elastic Job SDK，增加了注册中心的接入和任务初始化管理功能。平台将注册中心作为资源进行管理，并负责任务的初始化控制，从而使得接入方无需部署额外的注册中心服务，只需关注任务的开发。

2.3 中心调度，XXL-Job支持

XXL-Job是一个广受欢迎的轻量级分布式任务调度框架，在开源社区中非常流行。它以其简单的操作和丰富的功能特性被多个系统所采用。任务调度平台兼容XXL-Job任务接口，这意味着无需进行任何代码修改，就可以将现有的XXL-Job任务迁移到任务调度平台上进行托管。XXL-Job的运行态如下：

3 稳定运行，平台化管理与监控

3.1 快速运维实时监控

任务调度平台提供了一个用户友好的WEB管理界面，该界面不仅支持任务的创建、触发与禁用等功能，还实现了与钉钉预警系统的对接。这样，平台能够实时监控各调度器和执行器的运行状态，以及任务的执行历史。

尽管程序员在开发过程中已经在尽力避免引入错误，但问题有时仍然不可避免地出现。因此，快速的问题定位和解决是所有程序员都追求的目标。在这方面，任务调度平台在进行了以下几方面的尝试：

1、报警更直观

用户可以在创建Job时，可以配置告警接收人。当平台检测到对应Job问题时，它会通过机器人将相应的报警信息实时推送给指定的告警人，从而实现了快速响应和问题处理。

2、任务执行过程可追溯

通过WEB界面，可以查看任务实现状态与最新的执行记录，接入方可以通过任务调度平台提供的定制版日志收集工具，接入后可在平台上查看任务的执行过程记录。

3、执行器状态更清晰

平台除了支持实时查看任务执行，还能实时查看接入方各执行器状态，实时监控物理资源的运行。

3.2 削峰填谷，执行日志模块的平台化改造

执行日志模块在任务调度平台中扮演着重要的角色。它不仅负责记录任务的执行过程，为后续的任务追溯提供依据，还是任务告警机制和任务编排依赖的基础。任务之间的依赖关系和执行顺序都需要依靠稳定而高效的执行日志模块来支持。

在任务执行过程中，无论是扩散流量还是非扩散流量，最终都会流向DB。因此，流量控制的目标变得非常明确：关键在于对数据库的流量进行有效控制。

任务调度平台执行结果日志使用MySQL保存，执行的过程保存到非关系型的ElasticsSearch中。这种优化改造的目标主要是针对需要实时性更高的执行结果日志，分以下三部分进行优化改造：

1、SDK端改造支持

原生的Elastic Job SDK只支持RDB类型直接写数据库的数据持久化方案。由于Elastic Job考虑的是单个系统的分布式调度支持，对平台化不是很友好，限制了其在平台化场景下的使用。为了解决这个问题，我们对SDK进行改造，使其支持以REST API形式将结果日志向外报送。

2、平台端削峰填谷

在平台化场景下，关系型数据库作为存储很容易被打爆，因此引入消息中间件进行削峰填谷是一种有效的优化方案。我们通过将日志流量引入MQ，可以获得对执行日志的主动权，并为日志分析、任务依赖编写钩子函数提供了可能。

3、DB分区表优化

为了改善执行日志表的可伸缩性与可管理性，提高数据库的效率，我们对DB进行了分区表的改造。由于执行日志的记录表非常大，每月增长两三百万条，并且日志型数据具有时间属性，因此我们选择以时间维度进行区分。通过按月进行归档清理，我们可以保障当期数据在可操控的范围内。优化后的分区表在以下几个方面得到显著提升：

性能提升：在处理大量数据时，传统的单一表结构可能导致查询和维护操作的性能下降。通过使用分区策略，我们能够针对特定分区进行操作和查询，从而显著提高系统性能；

更容易维护：分区技术简化了维护任务，如备份和恢复。我们可以独立地对每个分区执行这些操作，无需影响整个操作表；

更好的并发性：利用分区，我们可以实现更高的并发性能。由于可以在不同的分区上并行执行某些操作，而无需锁定整个表，因此系统的并发处理能力得到增强；

数据管理：分区可以更轻松地管理数据，特别是对于具有时效性的数据。旧数据需要被归档或删除，而不是在整个表中操作，这使得数据管理更加高效和有序。

4 摸清脉络，简述实现原理

本文不对任务调度平台所支持的定时任务调度策略作过多赘述，以下是对任务调度平台实现原理以图文的方式做一个简述。

4.1 概要设计

4.2 调度流程

任务调度平台基于开源的分布式调度框架Elastic Job，其运行流程主要包括：

1、用户通过控制台（Console）创建应用（APP），并在应用中完成任务（Job）创建。通过控制台的API对任务进行持久化存储；

2、调度器集群（SC）启动，会加载应用和任务信息，并将自身以及这些任务注册到注册中心（ZK）；

3、调度器（Scheduler）在预定的时间准时准确找到待触发的任务，并找出与之关联的执行器，将任务分配给它们；

4、执行器（Executor）接收调度任务后，会创建任务实例（Job Instance）并执行，同时将结果和执行过程上报给调度器，也会更新自身的状态信息；

5、调度器接收到执行器的反馈后，通过控制台的API对结果进行持久化，并定期向控制台报告自身的状态；

6、控制台收集所有的信息，为用户提供各类监控数据。

总的来说，任务调度平台的核心工作就是在「指定时间」「通知执行器」以「指定方式」执行任务。

5 总结

本文简洁地概述了任务调度平台的基本原理和工作流程，尽管这些原理看似简单明了，但作为一个中间件平台，它必须确保任务调度过程的实时性和稳定性。此外，平台还需要开发各种复杂的任务执行策略，并具备处理大量任务调度请求的性能。而且，支持海量日志数据的存储与快速查询也是其关键职责之一。

统一任务调度平台的核心价值在于实现了任务调度流程的平台化管理。为了保持平台的高效运行，需要持续地进行运营和优化工作。在此过程中，感谢那些曾与我并肩作战的队友们，他们的努力和奉献是平台能够顺利运行的关键。未来也希望有更多人能投入到基础技术的赋能工作中，共同推动技术的进步和创新。

本文作者：戚思晓，碧桂园服务产品研发高/级工程师，拥有12年IT行业经验。