为应对证券行业盘后批量结算业务日益复杂，批量结算时间窗口不断缩小、运维难度日益加大等挑战，上证所积极拥抱开源技术，结合上证所批量结算的生产经验和教训，以零人工干预、自动化运维为目标，开发了支持多种部署模式的跨平台任务调度系统。 从上海证券交易所批量解决方案系统面临的实际挑战出发，通过对几种典型批量解决方案架构的研究，设计并开发了基于开源软件Spring cloud dataflow的上海证券交易所批量解决方案任务调度系统。 目前，该系统已在交易系统生产环境中平稳运行半年多，为系统在上交所各技术系统的推广奠定了坚实的基础。 关键词:(任务调度、批量解决、春云数据流、SSE技术)背景与挑战随着证券交易市场的快速发展，交易业务的种类和需要解决的数据量也越来越多，核心应用系统的批量解决业务也越来越复杂。 不同的批量解决方案不仅相互依赖，而且与上下游对接系统的交互越来越复杂，导致批量解决方案的解决时间窗口和应急时间窗口越来越小，这对新的批量解决方案架构的高效性、高可用性和易维护性提出了更高的要求。 从上海证券交易所审批结算业务的实际情况来看，面临以下问题和挑战。 首先，上交所各系统业务种类和数据量的增加，对批量解决方案架构的调度性能和功能提出了更多的要求。 目前上交所的核心盘后结算服务种类越来越多，如A/B股、综合服务、期权、沪港通等。，对任务调度的性能有严格的要求。 其次，核心交易系统批量结算业务上下游的交互越来越频繁，应急时间窗口越来越短，对批量结算架构的健壮性和预警系统的及时性有着近乎苛刻的要求。 在证券系统中，不同的系统有不同的等级。比如上交所的核心系统是四级系统，对恢复时间要求极其严格。 如何及时发现和处理问题，不仅需要及时的预警系统、稳定的系统架构，还需要完善的紧急控制功能。 再次，目前上交所科技公司的业务系统、大数据系统、核心交易系统都有自己的批量解决方案框架，不同的批量解决方案框架在各方面的要求也不一样，这些都给新的批量解决方案框架的选择带来了很大的挑战。 因此，为不同的系统选择一个通用的任务调度系统，可以大大避免人力物力的浪费，为软件的持续维护打下坚实的基础。 最后，软件技术、语言、系统等日新月异，软件的生命周期也是不可忽视的一个方面。 比如目前交易系统的核心批量解决方案就是基于OPENVMS自主研发的批量解决方案框架。虽然它非常稳定和高效，但由于操作系统生命周期的结束，很难更新或重建它。 综上所述，现有的批量解决方案架构，在目前面临各种挑战时，似乎是供不应求的。如何选择和开发满足证券业务的高效性、健壮性和监控友好性的批量解决方案架构变得越来越迫切。 批量调度系统的探索与选择目前，批量任务按照调度控制的不同分为资源调度和任务调度。资源调度是指为单个批处理步骤分配各种资源，如CPU、内存、磁盘甚至主机，以提高批处理步骤的资源利用效率。 典型的资源调度系统包括Cloud Foundry、Yarn、Mesos等。任务调度是指按照批量安排的顺序，及时准确地执行一系列批量步骤。 典型的任务调度系统包括弹性作业、Spring Batch、TaskCtl、Airflow等。 具体技术方向如何选择，也需要根据实际需求来确定。 解决批量调度系统的选型主要有三个方向:自主开发架构、基于开源软件的二次开发和采用商业软件。 自研和审批调度架构会耗费大量的人力和时间，所以能否从零开始经得起大数据量的考验，是不得不考虑的风险。商业软件是成熟稳定的，但是一方面不能完全由自己掌控。一旦出现问题，就很难应对。另一方面，上交所业务复杂，有很多特殊需求需要解决，很难及时满足各种需求。 基于开源软件的二次开发，不仅可以保证项目进度，而且开源软件经过多年验证具有一定的可靠性，可以满足不同业务的独特需求。 所以选择开源项目，进行消化转化，是一个方便可靠的方向。 因为目的不同，资源调度和任务调度并不冲突。调度系统可以支持批处理步骤的资源分配和不同批处理步骤之间的过程安排。 目前上交所核心批量解决方案调度系统由于历史和稳定性要求，暂不采用资源调度，仅将资源调度能力作为系统扩展能力的一部分。 目前已知的开源任务调度架构有很多，如Elastic-job、Airflow、Spring Cloud数据流(以下简称数据流)等。 Elastic-job是当当网开源的预定任务调度系统。目前已经有很多公司基于这个开源项目开发了自己的任务调度系统，比如唯品会的Saturn，数字云的Octopus。 但Elastic-job对任务间依赖关系的支持较弱，支持的任务类型较为单一，监控的范围和粒度不能满足证券交易业务的需求。 Airflow是Airbnb开源DAG(有向无环图)类的优秀任务调度工具。 气流主要是用PYTHON实现的，作业的定义不能用XML或者用户界面来定义，只能用PYTHON来定义，无法实现调度架构和应用业务的解耦。另外，Airflow开源时间短，调度性能低，更适合简单的ETL类安排。 因此，易用性、稳定性和性能都不能满足当前和未来证券业务的发展。 Dataflow是Pivotal的开源统一编程模型和托管服务，支持ETL、批量操作和连续操作。 根据批量任务的不同生命周期，Dataflow将应用解决方案分为流程解决方案和任务解决方案，并为基于微服务的分布式流程解决方案和批量解决方案提供了一系列模型和最佳实践。 但是，Dataflow也有几个缺点:首先，云调度的性能不足，一个微服务的调度达到分钟级别；其次，整体结构比较大，如何提取其精华是必须面对的挑战。 但结合上交所盘后结算的实际情况，还是有以下优势:数据流强大的布局能力，可以支撑复杂的关系和庞大的交易。 Spring/Spring云技术栈在上交所技术公司的应用越来越广泛，为Spring系列功能的后期维护和更新提供了保障。 数据流支持本地调度、云调度等多种部署方式，可以满足不同系统的级别要求，方便日后系统更新和维护。 出于核心交易系统的安全性和稳定性考虑，采用Dataflow的本地版本可以规避Docker等新技术的稳定性风险，也有利于后续云调度功能的完善和核心系统的平滑更新。 而大数据系统可以采用云调度等部署方式来支持微服务，Docker等新技术可以在弹性伸缩、灰度发布等方面满足自身需求。 数据流天然支持流程解决方案业务和批量解决方案业务。 证券业务不仅需要实时交易数据流的同步解决方案，还需要报表和对账的盘后解决方案。 数据流支持各种类型的批处理任务，如EXE、SHELL、PERL、PYTHON、JAR等。，可以将调度架构和批量应用开发完全解耦。 综上所述，选择数据流开源框架作为基石，开发符合上交所数据解决方案实际需求的调度框架，是一个可行、可控、安全的方案。 虽然dataflow有很多优点，但是它也有一些开源软件的通病，比如:1。开源软件只实现基本功能，注重通用性，但一个完整的企业级软件需要满足各种定制需求。 2.一般开源软件性能不足，实际测试会有各种缺陷，需要不断优化。 3.开源软件需要消化和学习，成本很大，需要深入学习。 因此，结合核心系统的实际情况，我们开发了新一代任务调度服务架构(简称EzTS)，这是一个基于数据流深度开发的批量解决方案调度系统，支持跨操作系统(Linux和Windows)，满足不同部署场景(本地、分布式和云调度)，具有框架与批量应用耦合度低、操控能力强、自动化运维等特点。 3.1整体架构EzTS主要由三部分组成:监控网关、调度服务和执行器。 核心交易系统的批量解决方案采用主动部署模式，保证系统的可靠性。 监控网关负责监控数据的汇聚和控制指令的转发。 调度服务主要负责流程的批量配置管理、触发、调用和监控。 服务调度可以根据不同的服务提供者接口(SPI)支持不同的部署模式，比如本地版本和云版本。 执行器可以根据不同的逻辑划分为流程和批次组，批次步骤可以通过流程和批次组的配置来运行。 所有执行器和批处理步骤的状态都会存储在状态数据库中(核心系统中使用MYSQL作为状态数据库)，其整体架构如图1所示。 图片来自网络虽然数据流提供了非常强大的任务调度功能，但距离企业级调度服务的要求还很远，需要进行深度改造，以满足上交所不同业务的需求。 下面从批量应用配置、服务调整模式、控制模式、依赖解析、监控可视化五个方面详细介绍新一代任务调度服务的优化设计。 3.2极简应用配置导入目前，任务调度领域的应用配置导入方式主要有三种:XML/JSON配置、程序配置和拖拽配置。 XML/JSON格式的应用配置方式比较复杂，比较适合业务较少、关系简单的系统。通过应用配置的方式，框架侵入性太强，难以更改且不灵活，也难以适用于应用系统的大规模批量解决方案；拖放式应用程序配置是最近流行的一种配置模式。虽然好用，但是实用性不够，无法满足大规模应用配置的要求。 为了简化应用批处理步骤的配置，实现应用与架构的完全解耦，EzTS使用EXCEL文件作为应用的配置文件，应用的配置流程如图2所示。 来自网络应用的映像的配置更新只需要以下三个步骤:应用开发者从任务调度服务web控制终端下载配置模板 应用程序开发人员填写应用程序配置。 应用配置更新 目前应用配置更新支持两种更新方式:第一种方式是通过任务调度服务的web控制端一键导入，提前检查配置的正确性；另一种更新方法是将excel配置文件放在public目录中，当调度服务启动时，将无限期加载应用程序配置。 一方面，这种应用配置的方法大大简化了应用配置的复杂度，更便于应用开发者使用。 另一方面，调度架构与批量应用测试更新完全解耦，增加了批量应用开发的灵活性。 3.3灵活的三层调度模式随着交易业务的多样性，同一业务类型的内部解决方案单元复杂，对调度层次提出了更高的要求。 为了更好地支持不同业务类型和不同批次逻辑单元之间的关系，EzTS采用了三层调度架构的设计，按照不同的级别分为流程、批次组和批次步骤，如图3所示。 图片来自网络目前业内大多数调度系统都支持基于UNIX的CRONTAB的调度任务。一方面，CRONTAB为周期性任务提供了极大的便利，但也有明显的局限性。 批处理步骤之间通常有很大的耦合。如果只靠计时，所有的批量步骤都和时间有关。一旦批量步骤出现问题，批量步骤的执行顺序可能无法保证。 此外，目前一些完善的批量解析框架也支持批量步骤的串并行配置，但无法满足交易业务中天然具有分组概念的内在逻辑。 因此，为了区分不同业务的批量解决方案，不同解决方案组和不同批量解决方案的顺序3.4各种控制方式随着交易业务越来越多，批量解决方案的复杂程度越来越高，与批量步骤相关联的上下游系统越来越多，导致批量解决方案的应急窗口不断缩小。如何快速处理批量解决中遇到的问题变得越来越重要。 在实际的盘后批量解决方案操作过程中，批量步骤存在各种人为干预的原因，如上游数据较晚、数据解决方案出错或错误等。这些不同的问题对任务调度服务的运行提出了更高的要求。 根据批量步骤控制方式的不同，可以简单地分为两类:重新运行控制和复位状态控制。 下表列出了当前支持的操作方法，如表1所示。 来自网络的图片，在批量应用的生命周期中，往往不是一个人开发和操作的。随着时间的推移，一个批处理步骤的前后依赖关系逐渐变得模糊。 一旦一个批处理步骤出现问题，哪些相关的批处理步骤需要重新运行，除非你对应用非常熟悉，否则很难选择，大大增加了应急响应的难度、时间和风险。 因此，针对这种情况，特别增加了相关批次重新运行的控制类型。 在批量应用开发过程中，配置相关批量步骤的信息，这样当再次遇到这样的紧急场景时，可以通过相关的批量重新运行功能快速处理问题，可以大大降低紧急时间和风险。 多种操作方法不仅增加了问题求解的灵活性，而且大大缩短了批量求解系统恢复和求解的时间。 3.5完美的依靠方式所有的批量步骤都必须依靠满意度才能开始，否则一方面会浪费有限的资源，另一方面程序进度也无法预测。 根据上交所批量结算业务的实践，批量步骤的依赖性可以分为三类:时间依赖性、文件依赖性和状态依赖性。 在交易系统的批量结算应用中，主要有两种依赖于时间的应用场景。一个是某批步骤不能早于某个时间点运行，比如期权结算价计算不能早于实时收盘时间。 另一个是某些批处理步骤只能每周或每月运行一次。 目前，不同证券系统之间的盘后结算主要依靠文件交换数据，这使得批量结算文件等待结算变得越来越重要。 一方面，当文件准备好时，调度服务立即调用批处理步骤应用程序，这可以大大减少批处理步骤运行时间。另一方面，批处理应用程序运行后，能否正确生成文件也可以通过批处理配置文件反馈到批处理运行状态。 此外，随着证券业务种类越来越多，批量步骤之间的逻辑划分在实际开发过程中越来越不清晰，导致不同批量步骤之间的关系越来越复杂。 出于配置和展现的需要，流程图的节点依赖逻辑不能太复杂，所以一个完善的批量状态依赖设计尤为重要。 可以在流程图上表达的不同批处理步骤之间的依赖关系称为显式状态依赖，否则称为隐式状态依赖。 显式状态依赖可以快速定位过程中批处理步骤的位置。 隐式批处理状态依赖可以灵活配置任意批处理/批处理组和进程的等待关系，最大程度地节省批处理程序的整体求解时间。 3.6监控的可视化随着证券业务的发展，批量步骤越来越多，批量结算的运行时间越来越长，批量结算的运维难度加大，对批量结算的监控提出了更高的要求。 批次分辨率监控包括两个部分:批次分辨率的显示和操作。 批量显示的难点是批量步骤和预警的关系；批量控制的难点在于安全性和可靠性。 目前批量解决方案呈现方式主要有两种:流程图呈现和列表呈现。 两种呈现方式各有利弊。例如，在流程图中可以直观地看到批次步骤之间的关系，但是很难找到某个批次步骤，并且呈现信息有限，而列表则相反。 流程图页面可以快速定位有问题的过程、批次组和批次步骤。 不同节点不仅可以显示批次名称、批次描述等信息，还可以点击批次步骤，直接控制和快速修复批次解决中遇到的问题。 在列表页面上，您可以快速搜索过程、批次组和批次步骤，并直接定位和操作它们。 同时还支持根据不同维度对批量步骤进行快速分组。例如，您可以快速搜索出跳过了哪些批处理步骤。 在绘制流程图的过程中，如何恰当地显示批量步骤的节点成为一个必须解决的问题。 流程图呈现方面，目前只有商业软件TASKCTL支持无流程图穿越。例如，所有批处理步骤必须属于一个串行或并行组，但是实际批处理步骤之间的关系非常复杂。针对上交所批量步骤的实际耦合关系，专门设计了流程图的坐标算法，计算过程如图6所示。 图片来自网络第一步:批量解决方案调度服务通过读取数据库的流程图配置，如& & amp& amp& ampe第二步:根据流程图中的串并配置信息(注意:配置为DSL语言，比如A串口B用& & ampb，平行b)成有向无环图。 第三步:为了使流程图从头到尾只有一个运行方向(比如从上到下，或者从左到右)，对有向无环图进行拓扑排序，使得不同批次步骤的层次更加明显。 第四步:通过第三步中的拓扑排序，节点分布在不同的层次上，但不能保证批量步骤依赖连线和批量步骤节点不重合，所以添加虚拟节点，实现流程图无点、线交叉。 这种流程图显示坐标的算法一方面实现了简单的串并行配置规则对流程图的描述，另一方面实现了任意有向无环图的层次虚线交叉显示。 总结与展望虽然在新一代任务调度系统的实际开发中遇到了各种各样的问题，比如开源软件底层架构的缺陷、高并发的数据库死锁、线程和内存资源的过度占用等。，通过我们的不懈努力，这些问题已经得到优化和处理，完全满足核心系统上线的要求。 运维、微服务、云调度一直是互联网技术研究的热点。上证所科技将充分利用积累的运维经验，以开放的心态拥抱、研究、实施新技术，不断打磨解决证券数据的能力，进一步提升证券业务的研发、保障、运营能力。