CN104702426A - 一种定时调度服务系统的配置方法及装置 - Google Patents

Abstract

本发明提出了一种定时调度服务系统的配置方法，包括如下步骤：用户将业务执行逻辑程序编绎成设定格式的逻辑文件；将其通过定时调度客户端上传到定时调度后台服务端，并配置定时方案；定时调度后台服务端将定时方案存储到数据库中，并将其存放到相应的文件目录下，同时在数据库中记录基本程序集信息；定时调度支撑服务端读取定时方案，并动态创建定时器；判断定时调度是否被触发，如是，加载逻辑文件并根据程序集信息反射执行用户的逻辑程序；否则，返回。本发明还涉及一种实现上述方法的装置。实施本发明的定时调度服务系统的配置方法及装置，具有以下有益效果：简化开发人员的工作量、设计实现方式统一、服务管理较容易、能统一升级。

Description

一种定时调度服务系统的配置方法及装置

技术领域

本发明涉及定时调度领域，特别涉及一种定时调度服务系统的配置方法及装置。

背景技术

日常的IT工作中，常常会遇到需要做数据同步、定时邮件、短信提醒、任务扫描等这类需求。遇到这种情况，通常需要开发一个定时调度服务来处理此类需求。这类定时调度服务的一般开发步骤是：搭建windows服务或普通可执行的程序，将其作为定时调度服务运行的宿主；开发定时器或调度框架；开发轮询中要执行的业务逻辑；实现日志跟踪。

通常情况下，一个定时调度服务的设计方案包含有：服务运行宿主、定时调度器、执行逻辑、日志跟踪四大要素。按照这种常规的定时调度设计方案，每一个需要定时调度的项目都需要开发出服务运行宿主、定时调度器、执行逻辑和日志跟踪。而实际上，其中只有执行逻辑不具备复用性，其它几点从功能用途的角度来看都是一样的，但并没有被抽象出来。

这种常规的定时调度设计方案，普遍存在如下问题：（1）重复设计开发：由于服务运行宿主、定时调度器和日志跟踪被一次次的重复设计、开发、测试，增加开发人员的工作量，造成时间及资源的浪费。（2）设计实现方式不统一：具体就是实现定时调度或日志跟踪时，又可以有多种设计实现方式，如定时调度可直接用Timer（定时器）或调度框架，而日志跟踪可用自创日志程序或第三方日志组件等多种方式实现记录日志功能等；对于不同的设计及开发人员，水平也有高低之分，可能有一些设计出来的定时调度程序很稳定，而有一些则不稳定、易出问题。（3）必须独立部署：由于这种常规的设计方案缺乏抽象的设计思想，每一个定时调度服务必须要独立进行部署；如果是针对不同的项目，这种做法并无不妥；但如果是针对同一项目中的多个定时调度需求，则没有必要开发部署这么多服务，还会造成服务管理上的困难。（4）无法统一升级：由于不同的定时调度服务都按自己的设计及实现方案，且都是独立部署，基本上无法应对服务统一升级管理的需求。

发明内容

本发明要解决的技术问题在于，针对现有技术的上述增加开发人员的工作量、设计实现方式不统一、服务管理较困难、无法统一升级的缺陷，提供一种简化开发人员的工作量、设计实现方式统一、服务管理较容易、能统一升级的定时调度服务系统的配置方法及装置。

本发明解决其技术问题所采用的技术方案是：构造一种定时调度服务系统的配置方法，所述定时调度服务系统包括定时调度支撑服务端、定时调度后台服务端、定时调度客户端和存储层；所述方法包括如下步骤：

A）用户将业务执行逻辑程序编绎成设定格式的逻辑文件；

B）将所述逻辑文件通过所述定时调度客户端上传到所述定时调度后台服务端，并配置定时方案；

C）所述定时调度后台服务端将所述定时方案存储到所述存储层中的数据库中，并将所述逻辑文件存放到相应的文件目录下，同时在所述数据库中记录所述逻辑文件的基本程序集信息；

D）所述定时调度支撑服务端从数据库中读取所述定时方案，并动态创建定时器；

E）判断定时调度是否被触发，如是，加载所述逻辑文件并根据所述程序集信息反射执行用户的逻辑程序；否则，返回所述步骤D）。

在本发明所述的定时调度服务系统的配置方法中，所述设定格式为DLL格式。

在本发明所述的定时调度服务系统的配置方法中，所述步骤B）中的定时方案是在可视化的定时配置界面中进行配置的。

在本发明所述的定时调度服务系统的配置方法中，所述步骤D）进一步包括：

D1）接收任务通知；

D2）读取所述数据库中的任务的定时配置；

D3）动态创建定时作业并将其加入到作业库中；

D4）根据用户通知启动所述定时作业。

在本发明所述的定时调度服务系统的配置方法中，所述步骤E）进一步包括：

 E1）判断定时调度是否被触发，如是，读取所述数据库中任务中对应的逻辑文件信息并执行步骤E2）；否则，返回所述步骤D）；

E2）在相应目录下加载所述逻辑文件；

E3）通过反射机制读取入口函数； 

E4）执行所述入口函数中的业务逻辑；

E5）等待下一次调度；

E6）判断是否有关停任务通知，如是，停止任务并返回步骤D）；否则，返回步骤E1）。 

本发明还涉及一种实现上述定时调度服务系统的配置方法的装置，所述定时调度服务系统包括定时调度支撑服务端、定时调度后台服务端、定时调度客户端和存储层；所述装置包括：

编译单元：用于使用户将业务执行逻辑程序编绎成设定格式的逻辑文件；

上传配置单元：用于将所述逻辑文件通过所述定时调度客户端上传到所述定时调度后台服务端，并配置定时方案；

存储记录单元：用于使所述定时调度后台服务端将所述定时方案存储到所述存储层中的数据库中，并将所述逻辑文件存放到相应的文件目录下，同时在所述数据库中记录所述逻辑文件的基本程序集信息；

读取创建单元：用于使所述定时调度支撑服务端从数据库中读取所述定时方案，并动态创建定时器；

定时调度判断单元：用于判断定时调度是否被触发，如是，加载所述逻辑文件并根据所述程序集信息反射执行用户的逻辑程序。

在本发明所述的实现上述定时调度服务系统的配置方法的装置中，所述设定格式为DLL格式。

在本发明所述的实现上述定时调度服务系统的配置方法的装置中，所述上传配置单元中的定时方案是在可视化的定时配置界面中进行配置的。

在本发明所述的实现上述定时调度服务系统的配置方法的装置中，所述读取创建单元进一步包括：

任务接收模块：用于接收任务通知；

定时读取模块：用于读取所述数据库中的任务的定时配置；

定时作业创建模块：用于动态创建定时作业并将其加入到作业库中；

作业启动模块：用于根据用户通知启动所述定时作业。

在本发明所述的实现上述定时调度服务系统的配置方法的装置中，所述定时调度判断单元进一步包括：

触发判断模块：用于判断定时调度是否被触发，如是，读取所述数据库中任务中对应的逻辑文件信息；

加载模块：用于在相应目录下加载所述逻辑文件；

函数读取模块：用于通过反射机制读取入口函数； 

业务逻辑执行模块：用于执行所述入口函数中的业务逻辑；

调度等待模块：用于等待下一次调度；

任务关停判断模块：用于判断是否有关停任务通知，如是，停止任务并返回。

实施本发明的定时调度服务系统的配置方法及装置，具有以下有益效果:由于使用定时调度支撑服务端、定时调度后台服务端、定时调度客户端和存储层；用户将业务执行逻辑程序编绎成设定格式的逻辑文件，通过定时调度客户端上传到定时调度后台服务端，并配置定时方案；定时调度后台服务端将定时方案存储到存储层中的数据库中，并将逻辑文件存放到相应的文件目录下，同时在数据库中记录逻辑文件的基本程序集信息；定时调度支撑服务端端从数据库中读取定时方案，并动态创建定时器；当定时调度被触发时，加载逻辑文件并根据程序集信息反射执行用户的逻辑程序。将任务逻辑和定时调度彻底分离，任务逻辑不用直接封装在定时调度服务中。针对每个需求，开发人员只需专注开发执行的任务逻辑即可，无需再重复实现定时调度细节，所以简化开发人员的工作量，使定时调度服务通用化，设计实现方式统一；可以把同一项目的不同的调度封装成业务执行逻辑文件，并加入调度的作业库中，完全不需要所有的调度服务都必须独立部署，所以服务管理较容易；由于调度服务是通用的，没有具体开发实现水平上的差异，所以易于维护，同时能统一升级，且升级较容易。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明定时调度服务系统的配置方法及装置一个实施例中方法的流程图；

图2为所述实施例中定时调度支撑服务端从数据库中读取定时方案，并动态创建定时器的具体流程图；

图3是所述实施例中定时调度触发判断的具体流程图；

图4是所述实施例中方法的时序图；

图5是所述实施例中定时调度服务系统的整体架构图；

图6是所述实施例中装置的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明定时调度服务系统的配置方法及装置实施例中，其定时调度服务系统的配置方法的流程图如图1所示。在介绍定时调度服务系统的配置方法之前，先介绍一下定时调度服务系统。本实施例中，定时调度服务系统包括定时调度支撑服务端、定时调度后台服务端、定时调度客户端和存储层。其中，定时调度支撑服务端是一个独立运行的服务，封装了定时器、调度管理、日志等功能，执行用户的调度逻辑程序就靠这个服务，但它与用户要执行的具体的业务逻辑完全松耦合；定时调度后台服务端是专门给定时调度客户端提供比如数据存储、数据查询等服务的，以及提供逻辑文件上传等功能，并不具备调度的功能，只是用来读写数据库及文件管理；定时调度客户端是面向调度开发人员的客户端，提供可视化任务调度配置（包括定时方案配置、选择逻辑文件上传）、任务查看、开启和关停、日志查看等功能；存储层用来存储用户配置的数据以及上传的逻辑文件。

图1中，该定时调度服务系统的配置方法包括：

步骤S01用户将业务执行逻辑程序编绎成设定格式的逻辑文件：本步骤中，用户将业务执行逻辑程序编绎成设定格式的逻辑文件，本实施例中，上述设定格式为DLL格式。换句话说，就是用户实现自己的业务执行逻辑程序后，将程序编绎成DLL格式的逻辑文件。

步骤S02 将逻辑文件通过定时调度客户端上传到定时调度后台服务端，并配置定时方案：本步骤中，将逻辑文件通过定时调度客户端上传到定时调度后台服务端，并在可视化的定时配置界面中配置好定时方案。

步骤S03 定时调度后台服务端将定时方案存储到所述存储层中的数据库中，并将逻辑文件存放到相应的文件目录下，同时在数据库中记录逻辑文件的基本程序集信息：本步骤中，定时调度后台服务端将用户配置好的定时方案存储到存储层中的数据库中，并将用户上传的逻辑文件存放到相应的文件目录下，同时在数据库中记录逻辑文件（程序文件）的基本程序集信息。

步骤S04定时调度支撑服务端从数据库中读取定时方案，并动态创建定时器：本步骤中，定时调度支撑服务端从数据库中读取用户配置的定时方案，并在定时调度支撑服务端内存中动态创建定时器。

步骤S05判断定时调度是否被触发：本步骤中，判断定时调度是否被触发，如果判断的结果为是，则执行步骤S06；否则，返回步骤S04。

步骤S06加载逻辑文件并根据程序集信息反射执行用户的逻辑程序：如果上述步骤S05的判断结果为是，则执行本步骤。本步骤中，加载用户上传的逻辑文件，并根据程序集信息反射执行用户的逻辑程序。通过抽象出除业务执行逻辑之外的其余部分，开发人员只需专注在业务逻辑的开发上，简化了开发人员的工作量，同时可以帮助实现服务通用化、统一化；此外，用简单易理解的定时调度配置客户端，让操作者可以轻松的配置出复杂的定时方案。 

对于本实施例而言，上述步骤S04还可进一步细化，其细化后的流程图如图2所示。图2中，步骤S04进一步包括：

步骤S41接收任务通知：本步骤中，接收新任务通知。

步骤S42读取数据库中的任务的定时配置：本步骤中，读取数据库中的任务的定时配置。

步骤S43动态创建定时作业并将其加入到作业库中：本步骤中，动态创建定时作业并将其加入到作业库中。

步骤S44 根据用户通知启动定时作业：本步骤中，根据用户通知启动定时作业。

对于本实施例而言，上述步骤S05- S06还可进一步细化，其细化后的流程图如图3所示。图3中，步骤S05- S06进一步包括：

步骤S51判断定时调度是否被触发：本步骤中，判断定时调度是否被触发，如果判断的结果为是，则执行步骤S52；否则，返回步骤S04。

步骤S52 读取数据库中任务中对应的逻辑文件信息：如果上述步骤S51的判断结果为是，则执行本步骤。本步骤中，读取数据库中任务中对应的逻辑文件信息。值得一提的是，执行完本步骤，执行步骤S53。

步骤S53在相应目录下加载逻辑文件：本步骤中，在相应目录下加载逻辑文件，具体就是以反射形式加载用户上传的DLL格式的逻辑文件。

步骤S54通过反射机制读取入口函数：本步骤中，加载DLL格式的逻辑文件成功后，通过数据库中针对该逻辑文件的描述信息，找到DLL程序的入口函数。

步骤S55 执行入口函数中的业务逻辑：本步骤中，调用并执行入口函数中的业务逻辑。

步骤S56等待下一次调度：本步骤中，等待下一次调度。

步骤S57判断是否有关停任务通知：本步骤中，判断是否有关停任务通知，如果判断的结果为是，则执行步骤S58；否则，返回步骤S51。

步骤S58停止任务：如果上述步骤S57的判断结果为是，则执行本步骤。本步骤中，停止任务，并返回步骤S04。

本实施例中定时调度服务系统的配置方法的时序图如图4所示。

值得一提的是，本发明对实现其技术方案的程序语言、开发方式并没有具体的要求，只要能够实现其技术方案的原理，用任何方式的语言都可以。本实施例中将以.net语言为例，来讲述其技术方案的实现原理。

对于定时调度支撑服务端，首先搭建一个Windows服务，做为定时调度支撑服务的宿主。在定时调度支撑服务端中封装调度框架Quartz（.net 下则使用Quartz.net版本）。对于Quartz而言，其基本原理是：在一开始就创建定时作业并把该定时作业加入作业仓库，当定时调度被触发时，将执行每个作业的Execute方法。所以一般业务逻辑会写在Execute方法中，让Quartz去执行。

本实施例中，为了使调度支撑服务端和业务执行逻辑完全分离，但又能在调度时执行用户的业务逻辑，可将用户的业务逻辑形成DLL格式的逻辑文件，并在作业的Execute方法中，以反射形式加载用户上传的DLL格式的逻辑文件。加载DLL格式的逻辑文件成功后，通过数据库中针对该逻辑文件的描述信息，找到DLL程序的入口函数，调用并执行其中的业务逻辑。由于将调度支撑服务端和业务执行逻辑完全分离，这样可以简化开发人员的工作量，节省时间和资源。实现日志可用Log4net组件，并在Execute方法中加入日志信息。由于集成日志，这样可减少重复开发日志功能的工作量。

对于定时调度后台服务端，创建WebServices服务。服务中至少提供如下接口：定时配置存储接口；文件上传接口；任务启动、关停接口；任务查询接口；日志查看接口。其中定时配置存储接口、任务查询接口和日志查看接口是直接读写操作数据库。文件上传接口用来将用户把要执行的逻辑文件，通过此接口上传到调度支撑服务端，上传时先给逻辑文件创建好目录（按用户指定的目录名来建目录），或使用默认目录来存放逻辑文件。上传方式一般以二进制流的方式进行文件内容上传。任务启动、关停接口只是一个通知接口，可把通知写在数据库中，定时调度支撑服务端轮询读取数据库中的这个信息，并控制相关任务的执行；也可以在Windows服务中实现remoting（远程）接口，这样任务的启动、关停通知可以立即通知到定时调度支撑服务端，而不用轮询扫描的方式来读取通知。

对于定时调度客户端，提供用户四个配置界面：定时配置页面、任务逻辑文件上传及配置页面、任务逻辑文件上传及配置页面、调度控制页面和日志查看页面；其中，定时配置页面提供友好的调度配置界面，把用户配置的定时方案转换成Cron（克龙）表达式，并传输给定时调度后台服务端。在任务逻辑文件上传及配置页面，用户把要执行调度的逻辑文件（DLL格式的逻辑文件）传到指定的位置，并填写关于该逻辑文件的一些信息，如：任务的关键字；逻辑文件存放的目录名；逻辑文件的文件全名；调用类名、入口函数名即可。调度控制页面用于启动或关停该任务的调度。日志查看页面用于显示该任务的执行时的日志情况。当然，在本实施例的另外一些情况下，也可以增加一些功能，以进行通用功能上的增强。

对于存储层，用户的配置数据可用Sql Server数据库来存储，定时调度支撑服务端和定时调度后台服务端都可以访问这一数据库；用户上传的逻辑文件放在存储层的存储服务器的目录下。其定时调度服务系统的整体架构图如图5所示。

本实施例还涉及一种实现上述定时调度服务系统的配置方法的装置，其结构示意图如图6所示。本实施例中，定时调度服务系统包括定时调度支撑服务端、定时调度后台服务端、定时调度客户端和存储层。图6中，该装置包括编译单元1、上传配置单元2、存储记录单元3、读取创建单元4和定时调度判断单元5；其中，编译单元1用于使用户将业务执行逻辑程序编绎成设定格式的逻辑文件；上传配置单元2用于将逻辑文件通过定时调度客户端上传到所述定时调度后台服务端，并配置定时方案；存储记录单元3用于使定时调度后台服务端将定时方案存储到存储层中的数据库中，并将逻辑文件存放到相应的文件目录下，同时在数据库中记录逻辑文件的基本程序集信息；读取创建单元4用于使定时调度支撑服务端从数据库中读取定时方案，并动态创建定时器；定时调度判断单元5用于判断定时调度是否被触发，如是，加载逻辑文件并根据程序集信息反射执行用户的逻辑程序。值得一提的是，本实施例中，上述设定格式为DLL格式。上述上传配置单元2中的定时方案是在可视化的定时配置界面中进行配置的。

本实施例中，读取创建单元4进一步包括任务接收模块41、定时读取模块42、定时作业创建模块43和作业启动模块44；其中，任务接收模块41用于接收任务通知；定时读取模块42用于读取数据库中的任务的定时配置；定时作业创建模块43用于动态创建定时作业并将其加入到作业库中；作业启动模块44用于根据用户通知启动定时作业。

本实施例中，定时调度判断单元5进一步包括触发判断模块51、加载模块52、函数读取模块53、业务逻辑执行模块54、调度等待模块55和任务关停判断模块56；其中，触发判断模块51用于判断定时调度是否被触发，如是，读取数据库中任务中对应的逻辑文件信息；加载模块52用于在相应目录下加载逻辑文件；函数读取模块53用于通过反射机制读取入口函数； 业务逻辑执行模块54用于执行入口函数中的业务逻辑；调度等待模块55用于等待下一次调度；任务关停判断模块56用于判断是否有关停任务通知，如是，停止任务并返回。

总之，在本实施例中，本发明实现了通用且高效稳定的定时调度服务设计。用户只需要上传任务逻辑组件，并进行简单的定时配置，即可实现复杂的定时调度任务，减少很多开发定时调度的工作量，更好地达到了定时调度服务的通用化、封装化及稳定性。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种定时调度服务系统的配置方法，其特征在于，所述定时调度服务系统包括定时调度支撑服务端、定时调度后台服务端、定时调度客户端和存储层；所述方法包括如下步骤：

A）用户将业务执行逻辑程序编绎成设定格式的逻辑文件；

B）将所述逻辑文件通过所述定时调度客户端上传到所述定时调度后台服务端，并配置定时方案；

C）所述定时调度后台服务端将所述定时方案存储到所述存储层中的数据库中，并将所述逻辑文件存放到相应的文件目录下，同时在所述数据库中记录所述逻辑文件的基本程序集信息；

D）所述定时调度支撑服务端从数据库中读取所述定时方案，并动态创建定时器；

E）判断定时调度是否被触发，如是，加载所述逻辑文件并根据所述程序集信息反射执行用户的逻辑程序；否则，返回所述步骤D）。

2.根据权利要求1所述的定时调度服务系统的配置方法，其特征在于，所述设定格式为DLL格式。

3.根据权利要求1或2所述的定时调度服务系统的配置方法，其特征在于， 所述步骤B）中的定时方案是在可视化的定时配置界面中进行配置的。

4.根据权利要求3所述的定时调度服务系统的配置方法，其特征在于，所述步骤D）进一步包括：

D1）接收任务通知；

D2）读取所述数据库中的任务的定时配置；

D3）动态创建定时作业并将其加入到作业库中；

D4）根据用户通知启动所述定时作业。

5.根据权利要求4所述的定时调度服务系统的配置方法，其特征在于，所述步骤E）进一步包括：

 E1）判断定时调度是否被触发，如是，读取所述数据库中任务中对应的逻辑文件信息并执行步骤E2）；否则，返回所述步骤D）；

E2）在相应目录下加载所述逻辑文件；

E3）通过反射机制读取入口函数； 

E4）执行所述入口函数中的业务逻辑；

E5）等待下一次调度；

E6）判断是否有关停任务通知，如是，停止任务并返回步骤D）；否则，返回步骤E1）。

6.一种实现如权利要求1所述的定时调度服务系统的配置方法的装置，其特征在于，所述定时调度服务系统包括定时调度支撑服务端、定时调度后台服务端、定时调度客户端和存储层；所述装置包括：

编译单元：用于使用户将业务执行逻辑程序编绎成设定格式的逻辑文件；

上传配置单元：用于将所述逻辑文件通过所述定时调度客户端上传到所述定时调度后台服务端，并配置定时方案；

存储记录单元：用于使所述定时调度后台服务端将所述定时方案存储到所述存储层中的数据库中，并将所述逻辑文件存放到相应的文件目录下，同时在所述数据库中记录所述逻辑文件的基本程序集信息；

读取创建单元：用于使所述定时调度支撑服务端从数据库中读取所述定时方案，并动态创建定时器；

定时调度判断单元：用于判断定时调度是否被触发，如是，加载所述逻辑文件并根据所述程序集信息反射执行用户的逻辑程序。

7.根据权利要求6所述的实现上述定时调度服务系统的配置方法的装置，其特征在于，所述设定格式为DLL格式。

8.根据权利要求6或7所述的实现上述定时调度服务系统的配置方法的装置，其特征在于，所述上传配置单元中的定时方案是在可视化的定时配置界面中进行配置的。

9.根据权利要求8所述的实现上述定时调度服务系统的配置方法的装置，其特征在于，所述读取创建单元进一步包括：

任务接收模块：用于接收任务通知；

定时读取模块：用于读取所述数据库中的任务的定时配置；

定时作业创建模块：用于动态创建定时作业并将其加入到作业库中；

作业启动模块：用于根据用户通知启动所述定时作业。

10.根据权利要求9所述的实现上述定时调度服务系统的配置方法的装置，其特征在于，所述定时调度判断单元进一步包括：

触发判断模块：用于判断定时调度是否被触发，如是，读取所述数据库中任务中对应的逻辑文件信息；

加载模块：用于在相应目录下加载所述逻辑文件；

函数读取模块：用于通过反射机制读取入口函数； 

业务逻辑执行模块：用于执行所述入口函数中的业务逻辑；

调度等待模块：用于等待下一次调度；

任务关停判断模块：用于判断是否有关停任务通知，如是，停止任务并返回。