CN107450975A

CN107450975A - 一种基于分层的任务执行方法及装置

Info

Publication number: CN107450975A
Application number: CN201710703160.6A
Authority: CN
Inventors: 朱莹
Original assignee: Bank of China Ltd
Current assignee: Bank of China Ltd
Priority date: 2017-08-16
Filing date: 2017-08-16
Publication date: 2017-12-08

Abstract

本申请提高了一种基于分层的任务执行方法及装置，将各项客户服务分解为预设类型的数据模型，预设类型的数据模型包括客户服务层、功能层、交易层和接口层，数据模型中的上层的各项由下层的至少一项组合形成。以交易层中的各个步骤为任务，统计批量任务信息，并查询所述批量任务信息，生成预设时间段内需要执行的任务汇总，执行所述任务汇总中的各项任务，因此，将客户服务的执行分解为任务的颗粒度进行调度执行，所以，可以统一调度各个任务的执行，因此，能够避免对于热点资源的争夺，所以，可以提高系统的运行效率。

Description

一种基于分层的任务执行方法及装置

技术领域

本申请涉及电子信息领域，尤其涉及一种基于分层的任务执行方法及装置。

背景技术

电子商务网站上可以提供各种服务。例如，银行的网站可以向用户提供转账服务，转账服务对于银行内部而言，通过资金归集功能实现。资金归集是银行的一项基本功能。

随着电子商务的发展，可向用户提供的服务越来越多。目前，各种服务均由各项基本功能组合而成。例如，资金归集功能和购买理财功能这两项基本功能，组合形成一项新的服务。

通常，各种服务的运行是独立的，例如，对于上述新的服务，需要依次调度资金归集功能和购买理财功能，而对于另一项由资金归集和信用卡还款两项基本功能组合而成的服务，需要依次调度资金归集功能和信用卡还款功能。

可见，不同的服务可能要调度相同的基本功能，而大量不同的服务分别运行，可能会发生系统资源的争夺，从而导致系统的运行效率降低。

发明内容

本申请提供了一种基于分层的任务执行方法及装置，目的在于解决现有的调度方法导致的系统运行效率低的问题。

为了实现上述目的，本申请提供了以下技术方案：

一种基于分层的任务执行方法，包括：

将各项客户服务分解为预设类型的数据模型，所述预设类型的数据模型包括客户服务层、功能层、交易层和接口层，所述功能层包括构成所述客户服务层的所述各项客户服务的功能，所述交易层包括构成所述各项功能的步骤，所述接口层包括实现所述交易层的各项步骤需要调用的接口；

依据所述数据模型，统计批量任务信息，所述批量任务信息包括各个任务的参数，所述任务为所述交易层中包括所述步骤；

查询所述批量任务信息，生成预设时间段内需要执行的任务汇总；

执行所述任务汇总中的各项任务。

可选的，所述任务中的任意一项任务的参数包括：

该任务的标识、该任务组合形成的功能的标识以及客户服务的标识、该任务的触发条件、该任务的执行周期、执行时间和并发数。

可选的，所述任意一项任务的参数还包括：

该任务的前置任务的标识、所述前置任务的触发条件。

可选的，所述查询所述批量任务信息，生成预设时间段内需要执行的任务汇总包括：

通过查询所述批量任务信息中各项任务的执行时间，将执行时间在预设时间范围内的任务加入任务汇总。

可选的，所述任务汇总信息中任意一项任务的汇总信息包括：

该任务的批号、该任务的标识、该任务组合形成的功能的标识和客户服务的标识、任务状态以及允许重跑次数，所述任务状态表示该任务已执行或者未执行。

可选的，所述执行所述任务汇总中的各项任务包括：

遍历所述任务汇总中的各项任务的任务状态，如果所述任务状态为未执行，则通过所述任务汇总中所述任务的标识，从所述批量任务信息中查询具有相同任务标识的任务的参数，如果所述参数满足执行条件，则触发任务执行，所述执行条件包括当前到达执行时间和/或执行周期，如果有前置任务，则所述执行条件还包括：所述前置任务执行完毕。

可选的，在所述执行所述任务汇总中的各项任务之后，还包括：

更新所述数据模型中的各层的状态。

一种基于分层的任务执行装置，包括：

分解模块，用于将各项客户服务分解为预设类型的数据模型，所述预设类型的数据模型包括客户服务层、功能层、交易层和接口层，所述功能层包括构成所述客户服务层的所述各项客户服务的功能，所述交易层包括构成所述各项功能的步骤，所述接口层包括实现所述交易层的各项步骤需要调用的接口；

统计模块，用于依据所述数据模型，统计批量任务信息，所述批量任务信息包括各个任务的参数，所述任务为所述交易层中包括所述步骤；

汇总模块，用于查询所述批量任务信息，生成预设时间段内需要执行的任务汇总；

执行模块，用于执行所述任务汇总中的各项任务。

可选的，所述任务中的任意一项任务的参数包括：

可选的，所述任意一项任务的参数还包括：

该任务的前置任务的标识、所述前置任务的触发条件。

可选的，所述汇总模块具体用于：

可选的，所述执行模块具体用于：

可选的，还包括：

更新模块，用于在所述执行模块执行所述任务汇总中的各项任务之后，更新所述数据模型中的各层的状态。

本申请所述的基于分层的任务执行方法及装置，将各项客户服务分解为预设类型的数据模型，预设类型的数据模型包括客户服务层、功能层、交易层和接口层，所述功能层包括构成所述客户服务层的所述各项客户服务的功能，所述交易层包括构成所述各项功能的步骤，所述接口层包括实现所述交易层的各项步骤需要调用的接口，可见，数据模型中的上层的各项由下层的至少一项组合形成。以交易层中的各个步骤为任务，统计批量任务信息，并查询所述批量任务信息，生成预设时间段内需要执行的任务汇总，执行所述任务汇总中的各项任务，因此，将客户服务的执行分解为任务的颗粒度进行调度执行，所以，可以统一调度各个任务的执行，因此，能够避免对于热点资源的争夺，所以，可以提高系统的运行效率。

附图说明

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

图1为本申请实施例公开的基于分层的任务执行方法的流程图；

图2为本申请实施例公开的数据模型的示意图；

图3为本申请实施例公开的数据模型中各层的组合示意图；

图4为本申请实施例公开的基于分层的任务执行装置的结构示意图。

具体实施方式

本申请实施例公开的基于分层的调度方法及装置，可以应用在电子商务网站的业务运行系统中，例如，银行的业务运行系统。目的在于，通过对于客户服务的分层，实现对组合成客户服务的功能、组合成功能的步骤的解耦，从而实现以各项基本功能的基本步骤为维度的调度过程。

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

S101：将各项客户服务分解为预设类型的数据模型。

预设类型的数据模型如图2所示，包括：客户服务层、功能层、交易层和接口层。

其中，客户服务层包括向客户提供的服务。客户服务层包括的各项功能需要向用户展示。

功能层包括构成客户服务层的各项客户服务的功能。这些功能不带有具体业务场景的性质。功能层包括的功能可以是已有的功能，也可以是新开发的功能。功能层包括的功能可以向用户展示，也可以不向用户展示。

交易层包括构成各项功能的步骤，即系统实现各项功能需要执行的基本步骤。交易层包括的步骤，不向客户展示。

接口层包括实现交易层的各项步骤需要调用的其它系统的接口。接口层包括的接口不向客户展示。

也就是说，图2所示的数据模型中，上一层的任意一项，由下一层的一项或者几项组合实现。举例说明，客户服务层的客户服务1，由功能层的资金归集和信用卡还款两个功能组成，其中，资金归集功能由交易层的步骤A和步骤B实现，其中，步骤A通过调用接口C实现。

各层的异常机制和存储可以参见图2所示。

按照图2所示的数据模型，将每个客户服务分解为四层，其中，每一层中的不同的项，均对应一个唯一对应的标识。

所有的客户服务被分解后，形成如图3所示的数据模型：各项客户服务被分解为至少一项功能，各项功能被分解成至少一个步骤，各个步骤被分解成至少一个接口。每层中的不同项均对应一个唯一的标识。

从图3可以看出，不同的客户服务可能具有相同的某些功能，不同的功能的实现可能具有相同的某些步骤，不同的步骤可能需要调用相同的某些接口。

S102：依据预设类型的数据模型，统计批量任务信息。

具体的，可以使用批量任务定义表的形式，记录批量任务信息。批量任务定义表中包括各个任务的参数。其中，任务为数据模型的交易层中包括的各个步骤(也可称为交易)。

具体的，参数包括但不限于：任务的标识、任务组合形成的功能的标识以及客户服务的标识、该任务的前置任务(可选)的标识、前置任务以及该任务的触发条件(可选)、任务的执行周期、执行时间、并发数。

其中，并发数是指，该任务在执行过程中，允许并行执行的其它任务的最大数量。

为了统一并发机制，可选的，采用与系统中的数据不同类型的数据项，表示并发数。

表1为批量任务定义表的一个示例(本实施例中，均以ID表示标识)：

表1

编号	字段名	类型	描述
				1	TASK_ID	char(6)	任务ID
2	FUNC_ID	char(6)	功能ID
				3	BUSI_ID	char(6)	客户服务ID
4	FRONT_TASK_ID	char(6)	前置任务ID
				5	START_CONDITION	char(1)	(前置)任务触发条件
6	RUN_DATE	VARchar2(4)	执行周期
				7	RUN_TIME	char(5)	执行时间
8	PALL_NO	NUMBER(4)	并发数

可选的，还可以统计客户服务的分层数据。

具体的，可以使用客户服务定义表的形式，统计客户服务的分层数据。客户服务定义表中包括任意一项客户服务的标识、组合成该客户服务的功能的数量以及功能的标识。

表2为客户服务定义表的一个示例：

表2

编号	字段名	类型	描述
				1	BUSI_ID	char(6)	客户服务ID
2	FUNC_NUMBBER	NUMBER(2)	组合的功能数
				3	FUNC_ID_1	char(6)	功能一ID
4	FUNC_ID_2	char(6)	功能二ID
				5	FUNC_ID_3	char(6)	功能三ID

需要说明的是，S101-S103可以在系统对用户提供服务之前，预先执行，也就是说，预先将系统按照S101-S103进行改造，以为后续的服务提供过程中，高效运行奠定基础。

下面将说明基于上述的数据模型，向客户提供服务的调度过程。

S103：查询批量任务信息，生成预设时间段内需要执行的任务汇总。

生成预设时间段内需要执行的任务汇总的具体实现方式为：通过查询批量任务信息中各项任务的执行时间，将执行时间在预设时间范围内的任务加入任务汇总。

具体的，可以以预设的周期执行S104。

例如，在每日8点，查询批量任务定义表，选择执行日期为当日的任务，形成当日的批量任务运行汇总表，如表3所示。

表3

编号	字段名	类型	描述
				1	RUN_NO	VARchar2(16)	任务批号
2	TASK_ID	char(6)	任务ID
				3	FUNC_ID	char(6)	功能ID
4	BUSI_ID	char(6)	客户服务ID
				5	TASK_STS	char(1)	任务状态
6	REP_RUN_TIMES	NUMBER(3)	允许重跑次数

从表3可以看出，任务汇总信息中包括任务的批号、任务的标识、任务组合形成的功能的标识和客户服务的标识、任务状态(表示已执行或者未执行)以及允许重跑次数。

S104：执行任务汇总中的各项任务。

具体的执行过程为：遍历批量任务运行汇总表中的各项任务的任务状态，如果任务状态为未执行，则通过表3中的任务ID，从表1中查询相同任务ID的任务的参数，如果参数满足执行条件，则触发任务执行。

其中，执行条件包括：当前到达执行时间和/或执行周期，如果有前置任务，则执行条件还包括：前置任务执行完毕。

任务执行被触发后，调用与实现任务的各个子进程，以执行任务。

在具体实现中，任务包括脱机任务和联机任务。其中，脱机任务主要体现为数据整理。联机任务主要体现在通过调用接口调用其它系统。

S105：更新数据模型中的各层的状态。

具体的，更新各层的状态包括以下几个方面：

1、更新任务的执行状态，具体的，更新各项任务的执行明细，以表4所示的批量任务运行明细表为例：

表4

编号	字段名	类型	描述
				1	RUN_NO	VARchar2(16)	任务批号
2	RUN_SEQ	NUMBER(3)	任务(本批次)执行序号
				3	PALL_SEQ	NUMBER(4)	并发编号
4	PROC_STS	char(1)	进程状态

任务的执行明细包括：任务批号、本批次中任务的执行序号、并发编号以及进程状态。其中，并发编号用于表示任务重复执行的次数。

2、更新客户服务层的状态，以表5所示的客户服务流程状态表为例：

表5

编号	字段名	类型	描述
				1	BUSI_SEQ	VARchar2(16)	客户服务流水号
2	BUSI_ID	char(6)	客户服务ID
				3	BUSI_STS	char(1)	客户服务状态

客户服务层的状态包括客户服务流水号、客户服务的标识以及客户服务状态，其中，客户服务状态用于表示客户服务是否完成。确定客户服务完成的依据为，组合成客户服务的各项功能被完成。

3、更新功能层的状态，以表6所示的功能流水状态表为例：

表6

编号	字段名	类型	描述
				1	FUNC_SEQ	VARchar2(16)	功能流水号
2	FUNC_ID	char(6)	功能ID
				3	BUSI_SEQ	VARchar2(16)	客户服务流水号
4	FUNC_STS	char(1)	功能状态

功能层的状态包括功能流水号、功能的标识、客户服务流水号以及功能状态。其中，功能状态用于表示功能是否完成。确定功能完成的依据为，组合成功能的各个步骤(交易层)被完成。

需要说明的是，表6中的客户服务流水号表示该功能组合形成的客户服务的流水号。

4、更新交易层的状态，以表7所示的交易流水状态表为例：

表7

编号	字段名	类型	描述
				1	TRA_SEQ	VARchar2(16)	任务流水号
2	TRA_ID	char(6)	任务ID
				3	FUNC_SEQ	VARchar2(16)	功能流水号
4	TRA_STS	char(1)	任务状态

交易层的状态包括任务流水号、任务的标识、功能流水号，以及任务状态。其中，功能流水号表示该任务组成的功能的流水号。

其中，任务状态用于表示任务是否完成。确定功能完成的依据为，任务是否被完成。

5、更新接口层的状态，以表8所示的接口流水状态表为例：

表8

编号	字段名	类型	描述
				1	UUID_SEQ	VARchar2(16)	接口流水号
2	UUID_ID	VARchar2(10)	接口ID
				3	TRA_SEQ	VARchar2(16)	任务流水号
4	UUID_STS	char(1)	接口返回状态

接口层的状态包括接口流水号、接口的标识、任务流水号以及接口返回状态。其中，任务流水号表示调用接口的任务的流水号。接口返回状态表示接口调用是否成功。

可选的，除了以每一层为维度记录状态外，还可以以某项功能或者某个任务为维度，记录状态。

表9为以各项功能为维度记录状态的一个示例：

表9

编号	字段名	类型	描述
				1	FUNC_SEQ	VARchar2(16)	功能流水号
2	FUNC_ID	char(6)	功能ID
				3	XXX		功能属性

其中，功能属性用于表示该功能的业务属性，接口层或交易层可以从这里获得业务属性信息。

在实际应用过程中，可以通过调用公共组件(以下所示各个函数)的方式，实现对于上述各个表格中的信息的更新。具体的：

1、客户服务状态更新函数：联机处理根据传入的参数“是否更新客户服务状态”的取值，调用客户服务状态更新函数，修改客户服务流水状态表中的客户服务状态的取值。

2、功能状态更新函数：联机处理根据传入的参数“是否更新功能状态”的取值，调用功能状态更新函数，修改功能流水状态表中的功能状态的取值。

3、交易状态和接口状态更新函数：联机处理调用交易状态和接口状态更新函数，UPDATE交易流水状态表和接口流水状态表中的记录状态信息和其它信息。

4、调用接口后处理函数：该函数对上述三个函数进行封装，所有联机处理调用接口后，根据接口返回结果，更新相应的流水状态表。

5、调用接口前状态表准备函数：所有要调用接口的联机程序，在调用前都需要将交易流水状态表中的交易状态UPDATE为3-处理中，同时INSERT接口流水状态表信息，并下commit，然后再执行UPDATE或SELECT FOR UPDATE语句，为记录加锁，避免不同进程并发同时修改同一记录。所有联机程序在调用服务接口前统一条用该函数进行状态表的准备。

6、交易流水预检函数：所有联机交易执行时，需要根据输入的交易流水键值检查该流水是否需要处理，该函数根据流水键值查询交易流水状态表，获取交易流水的状态，根据联机批量任务定义表中的参数检查，当前流水状态是否需要处理，如果不需要处理，则直接返回到程序返回段。

7、接口返回码处理函数：对于同一个系统的接口，不同接口返回码的处理一般而言是相同的，返回码分为三类：成功，失败，未明。该函数用于返回码的判断，接口返回可以用相同的函数进行接口状态的判断，返回给接口程序。

8、进程统计数据更新函数：由各个联机批量子进程调用，更新联机批量任务运行明细表中的各个进程的状态数据和交易统计数据，例如交易处理总数，成功数，失败数等。

以上函数的功能的具体实现过程可以参见现有技术，这里不再赘述。

从图1所示的过程可以看出：通过对业务实现过程分层抽象，构建接口、交易、功能组合机制，同时提供统一的批量转联机交易调度机制，可以实现以任务为维度的调用。因此，对于不同的客户服务，可以并行执行相应的任务，并在组合运行时由整个方法提供统一的交易一致性管理、运行触发、并发控制、状态监控机制。因此，能够提高系统的运行效率。

除此之外，新增客户服务时，可以逐层组合而成，有利于加快新产品的开发。

图4为本申请实施例公开的基于分层的任务执行装置，包括：分解模块、统计模块、汇总模块和执行模块，可选的，还可以包括更新模块。

其中，分解模块用于将各项客户服务分解为图2以及图3所示的预设类型的数据模型。统计模块用于依据所述数据模型，统计批量任务信息。汇总模块用于查询所述批量任务信息，生成预设时间段内需要执行的任务汇总。执行模块用于执行所述任务汇总中的各项任务。更新模块用于在所述执行模块执行所述任务汇总中的各项任务之后，更新所述数据模型中的各层的状态。

各个模型实现各自功能的具体实现方式可以参见上述方法实施例，这里不再赘述。

图4所述的装置具有以下优点：不同的联机批量支持并发执行，且并发数的设置参数化，可根据生产情况调整；具备完备的联机批量任务状态、日志管理机制；支持定时、实时触发的批量转联机调度；支持多个批量转联机处理的组合调度，以满足产品组合需求的设计需要，例如归集加申购理财组合产品；支持批量转联机处理的优先级调度，包括进程的执行、阻塞等，从而使得系统具有更高的执行效率。

本申请实施例方法所述的功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算设备可读取存储介质中。基于这样的理解，本申请实施例对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一台计算设备(可以是个人计算机，服务器，移动计算设备或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims

1.一种基于分层的任务执行方法，其特征在于，包括：

执行所述任务汇总中的各项任务。

2.根据权利要求1所述的方法，其特征在于，所述任务中的任意一项任务的参数包括：

3.根据权利要求2所述的方法，其特征在于，所述任意一项任务的参数还包括：

该任务的前置任务的标识、所述前置任务的触发条件。

4.根据权利要求2所述的方法，其特征在于，所述查询所述批量任务信息，生成预设时间段内需要执行的任务汇总包括：

5.根据权利要求1或4所述的方法，其特征在于，所述任务汇总信息中任意一项任务的汇总信息包括：

6.根据权利要求5所述的方法，其特征在于，所述执行所述任务汇总中的各项任务包括：

7.根据权利要求1所述的方法，其特征在于，在所述执行所述任务汇总中的各项任务之后，还包括：

更新所述数据模型中的各层的状态。

8.一种基于分层的任务执行装置，其特征在于，包括：

执行模块，用于执行所述任务汇总中的各项任务。

9.根据权利要求8所述的装置，其特征在于，所述任务中的任意一项任务的参数包括：

10.根据权利要求9所述的装置，其特征在于，所述任意一项任务的参数还包括：

该任务的前置任务的标识、所述前置任务的触发条件。

11.根据权利要求10所述的装置，其特征在于，所述汇总模块具体用于：

12.根据权利要求8或11所述的装置，其特征在于，所述任务汇总信息中任意一项任务的汇总信息包括：

13.根据权利要求12所述的装置，其特征在于，所述执行模块具体用于：

14.根据权利要求8所述的装置，其特征在于，还包括：