摘要：为了应对证券行业盘后批处理业务复杂度上升带来的批处理时间窗口逐步缩小和运维越来越困难的挑战，上交所技术积极拥抱开源技术，结合上交所批处理的生产经验教训，以零人工介入、自动化运维为目标，开发了一种跨平台、支持多种部署模式的任务调度系统。本文从上交所批处理系统面临的实际挑战出发，通过调研几类典型的批处理架构，选择以开源软件Spring cloud dataflow为基础，设计并研发了上交所批处理任务调度系统。目前，该系统已经在交易系统生产环境上平稳试运行半年有余，为该系统在上交所各技术系统的推广打下了坚实的基础。

关键字：（任务调度、批处理、Spring cloud dataflow、上交所技术）

背景和挑战

随着证券交易市场的快速发展，交易业务种类和待处理数据量也随之不断增加，核心应用系统的批处理业务越来越复杂。不同的批处理业务不但内部批处理单元相互依赖，而且与上下游对接系统的交互也越来越繁杂，导致留给批处理业务的处理时间窗口和应急时间窗口越来越小，这些都对新的批处理架构的高效性、高可用性和易维护性等方面提出了更高的要求。针对上交所批处理业务目前的实际情况，面临着如下问题和挑战。

首先是上交所各系统业务类型和数据量的增多对批处理架构的调度性能和功能提出了更多的要求。目前，上交所的核心交易盘后批处理业务类型越来越多，比如A/B股、综合业务、期权、沪港通等，对任务类调度的性能都有严格的要求。

其次是核心交易系统批处理业务的上下游交互越来越频繁，应急时间窗口越来越短，这对批处理架构的操控鲁棒性和预警系统的及时性都有了近乎严苛的要求。在证券系统中，不同的系统都有不同的分级，比如上交所核心系统为四级系统，对故障恢复时间要求极为严苛。如何能及时发现问题和解决问题，这不仅需要及时的预警系统，稳定的系统架构，更需要完善的应急操控功能。

第三、目前上交所技术公司业务系统、大数据系统和核心交易等系统都有各自的批处理框架，不同的批处理框架技术栈，各方面要求迥异，这都对新批处理架构选型造成了较大挑战。因此选择一个不同系统通用的任务调度系统，可以大大避免人力和资源的浪费，为软件的持续维护打下坚实的基础。

最后，软件技术、语言、系统等日新月异，软件的生命周期也是不可忽视的方面。比如，目前交易系统核心批处理是基于OPENVMS自主研发的批处理框架，虽然极其稳定高效，但是受限于操作系统生命周期将尽，升级或者重构都困难重重。

综上，已有的批处理架构在应对目前面临的各种挑战时就显得捉襟见肘，如何选择和研发一套满足证券业务处理高效性、鲁棒性和监控友好性的批处理架构越来越迫在眉睫。

批处理调度系统的探究和选型

目前批任务的处理根据调度控制的不同，分为资源调度和任务调度，资源调度是指为单个批步骤分配各种资源，比如CPU、内存、磁盘甚至主机，目的是为了提高批步骤利用资源的效率。典型的资源调度系统有Cloud Foundry、Yarn、Mesos等；任务调度是指一系列的批步骤按照批编排的顺序及时准确的执行。典型的任务调度系统有Elastic-job、Spring Batch、TaskCtl、Airflow等。具体如何选择技术方向，还需要根据实际的需求确定。

批处理调度系统的选型主要有三个方向：自研架构、基于开源软件二次开发和采用商用软件。自研批处理调度架构对人力成本、时间成本都耗费巨大，从零开始，是否经得起大数据量的考验都是不得不考虑的风险；商业软件，成熟稳定，但是一方面不能完全自主掌控，一旦出现问题，难以应急；另一方面，上交所业务复杂，批处理特殊需求较多，难以及时满足各种需求。基于开源软件二次开发，不但可以保证项目进度，而且开源软件经过多年验证，具有一定的可靠性，同时能满足不同业务的独特需求。所以选择开源项目并进行消化改造不失为一种便捷可靠的方向。

由于目的不同，资源调度和任务调度并不冲突，一个调度系统中既可以支持批步骤的资源配置，也可以支持不同批步骤间的流程编排。目前上交所核心批处理调度系统由于历史和稳定性要求等原因，暂时不会采用资源调度的方式，仅将资源调度能力作为系统扩展能力的一部分。目前已知的开源任务调度架构较多，比较有代表性的有Elastic-job、Airflow、Spring Cloud Data flow（以下简称Dataflow）等。

Elastic-job是当当网开源的定时分片类任务调度系统，目前很多公司基于该开源项目二次开发了自己的任务调度系统，比较有名的有唯品会的Saturn、数人云的Octopus等。但是Elastic-job对任务间的依赖关系支持较弱，支持的任务类型比较单一，监控的范围和粒度都不能满足证券交易业务的需要。

Airflow是Airbnb开源的DAG（有向无环图）类优秀的任务调度工具。Airflow主要由PYTHON实现，job的定义无法通过XML或者界面定义，只能依靠PYTHON定义，所以无法做到调度架构和应用业务的解耦合；另外，Airflow开源时间较短，调度性能较低，比较适用于简单的ETL类的编排。所以从易用性，稳定性和性能等方面都无法满足当前和未来证券业务的发展。

Dataflow是Pivotal公司开源的支持ETL、批量运算和持续运算的统一编程模型和托管服务。根据批任务的生命周期长短不同，Dataflow把应用处理分为流处理和任务处理，并且为基于微服务的分布式流处理和批处理提供了一系列的模型和最佳实践。

但是Dataflow也有一些不足：首先云调度性能不足，一个微服务的调度达到了分钟级；其次整体架构比较庞大，如何取其精华是必须面对的挑战。

但是结合上交所盘后批处理的实际情况，还有如下几方面优点：

Dataflow强大的编排能力可以支持关系复杂，数量庞大的交易业务。
Spring/Spring Cloud技术栈在上交所技术公司内部使用越来越广泛，这都为后期的Spring系列功能维护升级提供了保障。
Dataflow支持本地调度、云调度等部署方式，可以满足不同系统的等级要求，方便以后的系统升级和维护。核心交易系统为了安全性和稳定性的考虑，采用Dataflow本地版本可以规避Docker等新技术的稳定性风险，也方便了后续云调度功能的完善，核心系统的平滑升级。而大数据系统却可以采用云调度等部署方式，支持微服务，Docker等新技术满足自己弹性伸缩、灰度发布等方面的需求。
Dataflow天然支持流处理业务和批处理业务。证券交易业务既有实时交易数据流的同步处理需求，也有报表、对账等盘后处理需求。
Dataflow支持各种类型的批任务，比如EXE、SHELL、PERL、PYTHON、JAR等，可以实现调度架构和批应用开发完全解耦。

综上所述：选择以Dataflow开源框架为基石，开发出符合上交所数据处理实际需求的调度架构不失为一个可行、可控且符合安全运行需求的方案。

面向证券交易的任务调度系统的设计

虽然dataflow有诸多优点，但是其作为开源软件，也有开源软件的通病，比如：

1、开源软件只实现了基本功能，且侧重通用性，但是一个完整的企业级软件需要满足各种定制化需求。

2、开源软件一般性能不足，并且实战检验会有各种缺陷，需要不断优化。

3、开源软件需要消化学习成本较高，需要深入学习，才能融会贯通。

所以，结合核心系统的实际情况，我们开发了新一代任务调度服务架构（简称EzTS），它是基于Dataflow深度开发，支持跨操作系统（Linux和Windows）运行，满足不同的部署场景（本地、分布式、云调度），具有框架和批应用低耦合，强操控，自动化运维等特点的批处理调度系统。

3.1 总体架构

EzTS主要由三部分组成：监控网关、调度服务和执行器。核心交易系统批处理采用多活的部署方式保证系统的可靠性。监控网关负责监测数据的汇聚和操控指令的转发。调度服务主要负责批配置的管理，流程的触发、调用和监控等功能。调度服务可以根据服务提供接口（SPI）的不同，支持不同的部署方式，比如local版和cloud版。执行器可以根据逻辑的不同分为流程和批组，通过流程和批组的配置编排运行批步骤。所有执行器和批步骤的状态都会存储在状态数据库（核心系统以MYSQL作为状态数据库）中，其总体架构如图1所示。

虽然dataflow提供了非常强大的任务编排功能，但是还远远达不到企业级调度服务的要求，必须深入的改造才能适合上交所不同业务盘后批处理的需求。下面就从批应用配置、调服模式、操控方式、依赖处理和监控可视化五个方面介绍新一代任务调度服务的优化设计。

3.2 极简的应用配置导入

目前任务调度领域应用配置导入方式主要有三大类：XML/JSON配置式、程序配置式和拖拽配置式。XML/JSON格式的应用配置方式比较复杂，比较适合业务数量较少，关系简单的系统；应用通过程序配置的方式，对框架侵入性太大，变更难度大，不够灵活，同样难以适合大规模的批处理应用系统；拖拽式的应用配置方式是最近比较流行的配置方式，虽然上手简单，但是实用性不足，难以满足大规模的应用配置。

为了将应用批步骤配置简单化、应用和架构完全解耦合，EzTS采用了EXCEL文件作为应用的配置文件，应用的配置流程如图2所示。

应用的配置升级，只需要如下三步骤：

应用开发者从任务调度服务web操控端下载配置模板。
应用开发者填写应用配置。
应用配置升级。目前应用配置升级支持两种升级方式：方式一是通过任务调度服务的web操控端一键导入，提前检测配置的正确性；另一种升级方式需要把excel配置文件放置于公共目录，调度服务启动时会自动加载应用配置。

这种应用配置的方式一方面大大的简化了应用配置的复杂度，应用开发者更容易上手。另一方面，调度架构和批应用测试升级完全解耦，增加了批应用开发的灵活性。

3.3 灵活的三层调度模式

随着交易业务的多样性，同一业务类型内部处理单元错综复杂，这些都对调度层级提出了更高的要求。为了更好的支持不同业务类型，不同的批处理逻辑单元的关系，EzTS采用了三层调度架构的设计，根据层级的不同，分为流程、批组和批步骤，如图3所示。

目前，业界大多调度系统都支持基于UNIX的CRONTAB的定时任务，一方面CRONTAB为周期性的任务提供了极大的便利，但是却存在着明显的局限性。往往批步骤之间都有极大的耦合性，如果仅仅依靠定时的方式，所有的批步骤均和时间相关，一旦批步骤出现问题，未必能保证批步骤的执行顺序。

另外，目前部分较完善的批处理框架虽然也支持批步骤的串并行配置，但是却无法满足交易业务中天然具有分组概念的内部逻辑。所以为了区分不同业务批处理，不同处理组和不同批的处理先后关系

3.4 多样的操控方式

随着交易业务越来越多，批处理业务的复杂度也越来越高，批步骤关联的上下游系统也越来越多，造成了批处理的应急窗口不断缩小，如何快速的解决批处理中遇到的问题，就显得愈加重要。

在实际的盘后批处理运行过程中，批步骤需要人为干涉的原因各种各样，比如上游数据迟到、错误或者数据处理出错等，这些不同的问题对任务调度服务的操控提出了更高的要求。根据批步骤操控方式的不同，可以简单归为两类：重跑操控和置状态操控。

下表列出了目前支持的操控方式如表1所示。

在批应用的生命周期中，往往不是一个人在开发和运维，随着时间的推移，一个批步骤的前后依赖关系逐渐变得模糊。一旦一个批步骤出错，哪些相关联的批步骤需要重跑，除非对该应用十分熟悉，否则很难抉择，这大大增加了应急的难度、时间和风险。所以针对这一类情况，特别加入了相关批重跑的操控类型。当批应用开发的过程中，配置相关批步骤的信息，这样再碰到这样的应急场景时，可以通过相关批重跑功能快速解决问题，这样可以大大减少应急的时间和风险。

多样的操控方式不仅增加了问题处理的灵活性，而且大大缩短了批处理系统恢复处理的时间。

3.5 完善的依赖方式

所有的批步骤都必须依赖满足才能被调起运行，否则，一方面会造成有限资源的浪费，另一方面造成程序进度的不可预知。根据上交所批处理业务的实际，将批步骤的依赖分为三大类：时间依赖、文件依赖和状态依赖。

在交易系统的批处理应用中，时间依赖的应用场景主要有两类，一类是某一批步骤不能早于某一时间点运行，比如期权结算价计算不能早于实时收盘时间。另外一类是某一类批步骤只能一周或者一个月运行一次。

目前，不同的证券系统之间盘后处理主要依靠文件来交互数据，这就造成了批处理的文件等待处理越来越重要。一方面，文件就绪后，调度服务立即调起批步骤应用程序可以大大缩小批步骤运行的时间，另一方面，批应用运行结束后，文件是否正确生成也可以通过批配置文件依赖反馈到批的运行状态。

另外，随着证券业务类型越来越多，批步骤之间的逻辑划分在实际开发的过程中越来越不清晰，导致不同批步骤之间的关系越来越错综复杂。出于配置和展示的需要，流程图的节点依赖逻辑不能太过复杂，这样完善的批状态依赖设计就显得特别重要。在流程图上能够表示出来不同批步骤间依赖关系称为显式状态依赖，否则称为隐式状态依赖。显式状态依赖可以快速的定位批步骤在流程中的位置。隐式批状态依赖可以灵活的配置任意批/批组和流程的等待关系，最大程度的节省批程序的整体处理时间。