Batch task operation system for scheduling between servers

Abstract

The invention relates to the technical field of scheduling between servers, in particular to a batch task running system for scheduling between servers. The system comprises a task configuration module, a task deployment module and a task operation kernel module. According to the invention, a batch task processing strategy is formulated through the task configuration module, and the execution process of the batch tasks is managed and monitored through the task deployment module, so that the batch tasks are processed in batches in a process manner, the processing work of each batch task is systematically managed, the processing logic of the batch tasks is improved, and the processing efficiency is improved. Meanwhile, the task operation kernel module responds to the task instruction of the task configuration module, the corresponding task models are controlled to execute and process the batch tasks, the task instructions are automatically adapted through processing of the corresponding batch tasks in an adaptive mode through the multiple different types of task models, the task operation processing in different scenes is met, and the task operation efficiency is improved. The flexibility of the whole system is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of server - to - server scheduling, and more particularly, to a batch task running system for server - to - server scheduling. Background Art

[0002] The batch task operation services in the financial industry are usually carried out at night to complete a series of services such as risk control and early warning, full - process management of credit services, batch repayment processing, account settlement, interest calculation, data processing, preparation of regulatory reporting data, and report generation. The batch operations in financial institutions at night have the characteristics of large data volume and complex and sensitive services. These tasks usually involve a large amount of data and need to be completed within a specified window time, which brings huge challenges to aspects such as data processing capacity, efficiency, and logic. The existing technologies have the following defects and deficiencies: First, the batch processing in the banking system is concentrated at night. A large number of batch tasks need to be completed within a short time window at night, which consumes a large amount of system resources. The traditional underlying modules for batch task operation are difficult to adapt, affecting the performance of online transactions.

[0003] Second, with the construction of distributed new cores and big data platforms in the financial industry, the scale of batch processing jobs is getting larger, the scheduling scenarios are more diverse, and the system scheduling logic is more complex, which puts higher requirements on scheduling performance, stability, and scalability. Some existing systems have gradually been unable to meet the requirements.

[0004] Third, due to the lack of unified professional technical support and allowing each system to be built freely and disorderly, from the perspective of the whole bank, the stability of scheduling is difficult to be technically guaranteed, resulting in low efficiency of batch task processing.

[0005] In order to address the above problems, there is an urgent need for a batch task running system for server - to - server scheduling. Summary of the Invention

[0006] The purpose of the present invention is to provide a batch task running system for server - to - server scheduling to solve the problems raised in the above - mentioned background art.

[0007] To achieve the above - mentioned purpose, a batch task running system for server - to - server scheduling is provided, which includes a task configuration module, a task deployment module, and a task running kernel module; Among them, the task deployment module is used to receive task instructions in batch tasks and manage and monitor the execution process of batch tasks through a configuration management project; The task running kernel module is used to store different types of task models and respond to the task instructions of the task configuration module, and match the corresponding task models according to the content of the task instructions; The task configuration module is used to formulate a batch task processing strategy, including three parts: task definition, task loading, and task running; Among them, task definition is to define the task metadata in the transmission instruction and identify the task metadata type; task loading is to load the carrier of the batch task as task metadata recognizable by the system and provide the management of task metadata; task running instantiates the task metadata into a task entity and transmits it to the task running kernel module to control the corresponding task model to execute and process the batch task.

[0008] As a further improvement of this technical solution, the task models stored in the task running kernel module include a serial task model, a parallel unit task model, a subtask model, a task pool model, a timing scheduling model, and a streaming record processing model; Serial task model: The serial task is used to execute the batch task according to the configured serial routing order; Parallel unit task model: The parallel unit task is used to execute multiple task metadata; Subtask model: It is split into several independent subtasks to execute the corresponding number of task units; Task pool model: It is used to generate multiple pieces of data according to the data producer; Timing scheduling model: The scheduling model consists of three parts: a scheduling configuration file, scheduling loading, and scheduling execution, and performs timing execution work on the complete business meaning; Streaming record processing model: It is used for the operation of processing a large number of files of the same type one by one in a pipeline.

[0009] As a further improvement of this technical solution, the management items in the task deployment module include service configuration, task configuration, plan configuration, current task, task interference, and historical tasks; Among them, service configuration: It is used to manage the batch microservices in the system, and the batch execution command will be sent to the batch microservices for execution; Task configuration: Displays the task information in the system in the form of a list; Plan configuration: It is used to maintain the timing or polling plan information; Current task: It is used to view the tasks that are currently running; Task interference: It is a view specified by manual intervention when pausing or waiting for tasks; Historical tasks: It is used to view the previous batch running results.

[0010] As a further improvement of this technical solution, the method for formulating a batch task processing strategy in the task configuration module includes the following steps: S101. Define the task metadata through a task (Task) definition file and transmit the task metadata to the task (Task) loading module; S102. Load the task metadata as system-recognizable task metadata through the task loader in the Task loading module; S103. Transmit the recognized task metadata to the Task running module. Instantiate the task metadata into a task entity through the Task running engine in the Task running module, obtain the task (Task) entry, match the corresponding task model through the task (Task) entry, and execute the task entity.

[0011] As a further improvement of this technical solution, the method for executing the task entity in S103 includes the following steps: S1031. Detect all task definition files in the system and update the new version of the files to the database; S1032. Query tasks according to the task name and task description, and perform operations such as modifying, enabling / disabling, deleting, and rerunning the task configuration file.

[0012] As a further improvement of this technical solution, the method for the task deployment module to manage and monitor includes the following steps: S201. Obtain the deployment method by getting the content of the entry (Task); S202. Run and process batch tasks according to the deployment method and the matching task model; The deployment methods include single service replica, multiple services with single replica, multiple services with multiple replicas, using a database (DB) to implement asynchronous instructions, and using a message queue (MQ) to implement asynchronous instructions.

[0013] Compared with the prior art, the beneficial effects of the present invention are: In this batch task running system for server - to - server scheduling, a batch task processing strategy is formulated through the task configuration module, and the execution process of batch tasks is managed and monitored through the task deployment module, so as to process batch tasks in a process - based and batch - by - batch manner, systematically manage the processing work of various batch tasks, improve the processing logic of batch tasks, thereby improving the processing efficiency. At the same time, the task running kernel module responds to the task instructions of the task configuration module, controls the corresponding task model to execute and process batch tasks, adapts to the processing of corresponding batch tasks through multiple different types of task models, automatically adapts task instructions, meets the running and processing of batch tasks in different scenarios, and improves the flexibility of the overall system. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 It is the overall structure block diagram of the present invention; Figure 2 It is the specific task execution flow chart of the serial task model of the present invention; Figure 3This is the specific task execution flowchart of the parallel unit task model of the present invention; Figure 4 This is the specific task execution flowchart of the task pool model of the present invention; Figure 5 This is the specific step diagram of the main control thread of the present invention; Figure 6 This is the specific step diagram of the worker thread of the present invention; Figure 7 This is the specific implementation step diagram of the scheduling model of the present invention; Figure 8 This is the main thread execution process diagram of the present invention.

[0015] The meanings of the various labels in the figure are as follows: 10. Task configuration module; 20. Task deployment module; 30. Task running kernel module. Specific implementation manner

[0016] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by those of ordinary skill in the art without making creative efforts shall fall within the protection scope of the present invention.

[0017] Please refer to Figure 1 As shown, a batch task running system for inter-server scheduling is provided, including a task configuration module 10, a task deployment module 20, and a task running kernel module 30; Among them, the task deployment module 20 is used to receive task instructions in the batch task and configure and manage the project to manage and monitor the execution process of the batch task; The task running kernel module 30 is used to store different types of task models and respond to the task instructions of the task configuration module 10 to match the corresponding task models according to the content of the task instructions; The task configuration module 10 is used to formulate a batch task processing strategy, including three parts: task definition, task loading, and task running; Among them, task definition is to define the task metadata in the transmission instruction and identify the task metadata type; task loading is to load the carrier of the batch task as task metadata recognizable by the system and provide the management of the task metadata; task running instantiates the task metadata into a task entity and transmits it to the task running kernel module 30 to control the corresponding task model to execute and process the batch task.

[0018] In specific use, since the business scenarios of financial institutions are diverse, and the processing methods of batch tasks corresponding to different business scenarios will also vary. Therefore, in the process of scheduling and processing batch tasks in different servers, first, the task deployment module 20 receives the task instructions in the batch task, and the configuration management project manages and monitors the execution process of the batch task. In order to further match the corresponding task instructions and match different task processing models for adaptation processing, the task configuration module 10 formulates a batch task processing strategy. Among them, the task metadata in the transmission instruction is defined through task definition, that is, the task metadata type is identified, and the task metadata type is matched one by one with the task model. The task instruction is used to specify the processing method of the current batch task and is expressed through the task metadata; After completing the task metadata type identification work, the carrier of the batch task is loaded as task metadata recognizable by the system through task loading, and the management of the task metadata is provided. Finally, the task metadata is instantiated into a task entity through task running and transmitted to the task running kernel module 30. The task running kernel module 30 responds to the task instructions of the task configuration module 10, matches the corresponding task model according to the content of the task instructions, and controls the corresponding task model to execute and process the batch task.

[0019] The present invention formulates a batch task processing strategy through the task configuration module 10, manages and monitors the execution process of the batch task through the task deployment module 20, thereby performing process-based batch processing on the batch task, systematically managing the processing work of each batch task, improving the processing logic of the batch task, and thus improving the processing efficiency. At the same time, the task running kernel module 30 responds to the task instructions of the task configuration module 10, controls the corresponding task model to execute and process the batch task, adapts the corresponding batch task processing through multiple different types of task models, automatically adapts the task instructions, meets the operation and processing of batch tasks in different scenarios, and improves the flexibility of the overall system.

[0020] In addition, the task models stored in the task running kernel module 30 include a serial task model, a parallel unit task model, a subtask model, a task pool model, a timed scheduling model, and a streaming record processing model; Among them, the serial task model: uses serial tasks to execute batch tasks according to the configured serial routing order; The specific task execution process is as follows Figure 2As shown below: First, execute the task start (taskStart) event, and judge the setup. When there is a setup, execute the setup unit. When there is no setup, set the current execution unit (Unit) to start, and trigger the unit start (unitStart). After passing through the steps of the start unit execution (unit.execute) until the unit ends (unitEnd), then calculate whether there is a next execution unit (nestUnit) according to the routing table. When it is judged that there is one, set the next execution unit (nestUnit) to start. When it is judged that there is none, execute the disassembly judgment. When there is a teardown, execute the teardown. When there is no teardown, execute the task end (teardown) event.

[0021] Parallel unit task model: Multiple task metadata are executed using parallel unit tasks; specifically, a parallel unit task is a task that contains "parallel units". If 2 units need to be executed in parallel, then these 2 units (unit) are called parallel units, and parallel units must be wrapped by a "parallel unit container" to be executed. A parallel unit container is a special unit (unit) that can run the parallel units in the container simultaneously. When all parallel units are executed, the container is considered to be executed.

[0022] The specific implementation steps are as Figure 3 shown. If there are parallel units in the task (Task), that is, unit start task 1 (unit1.execute) and unit start task 1 (unit1.execute) in the figure, the start task (unitStart) in the task event (TaskEventListener) will be triggered by the "parallel unit container", and the parallel unit start (paralleUnitStart) will be triggered before the parallel units in the container are executed, and the parallel unit end (paralleUnitEnd) will be triggered after the execution. Sub-task model: It is split into several independent sub-tasks to execute the corresponding number of task units. Among them, there are 2 definition methods for sub-tasks according to business characteristics. One is defined in the parent task. This kind of sub-task is only visible to the parent task and is suitable for the situation where the sub-task has a strong business coupling with the parent task. The other is to define the sub-task as an independent root task, and this root task can be referenced as a sub-task by any other task. In this case, the sub-task is generally relatively independent and can be referenced by multiple other tasks.

[0023] Task pool model: It is used to generate multiple pieces of data according to data producers, instantiate a task (Task) for each piece of data, and finally execute these tasks (Task) in parallel; The specific working structure is as follows Figure 4 shown in the figure. It includes a task pool composed of a data producer (TaskPoolProducer), a work queue (Queue), and a working thread (ThreadHandler). The data producer (TaskPoolProducer) is responsible for providing data (files, databases, and message queues) and delivering it to the work queue (Queue) until the work queue (Queue) is full. According to the corresponding working thread (ThreaHandler), it executes in the order of the dates (dates) of different tasks (tasks) until the data in the work queue (Queue) becomes available; When the task pool runs, there is a "master thread" and multiple "working threads". The master thread is responsible for fetching data from the producer and putting it into the work queue (Queue), and the working threads are responsible for fetching data from the work queue (Queue) and then processing it. Before the master thread finishes fetching data from the producer and is about to put it into the work queue (Queue) each time, it needs to determine whether the working threads report errors. If there are errors, it will no longer put data into the work queue (Queue), but instead prepare to end all working threads and exit; The specific steps of the master thread are as follows Figure 5 shown in the figure. Among them, after the master thread puts an end marker into the work queue (Queue), it will try to end the thread pool of the working threads. If there are still working threads working at this time, it needs to wait for a period of time. If the working threads still have not ended after waiting, then the main thread will throw an exception and the batch job will fail.

[0024] The specific steps of the working threads are as follows Figure 6 shown in the figure. Among them, it is the start of the task pool thread handler, the start of the task pool data, and the end of the task pool data.

[0025] Timing scheduling model: The scheduling model consists of three parts: a scheduling configuration file, scheduling loading, and scheduling execution. Its core is the scheduling model, which is composed of a scheduling server (TaskServer), scheduling jobs (Jobs), a scheduler (Scheduler), and tasks (Tasks). The scheduling server (Scheduler) represents a complete scheduling, which contains multiple scheduling jobs (Jobs). Each scheduling job (Job) represents a timed execution job with a complete business meaning, and these scheduling jobs (Jobs) are independent; The specific implementation steps of the scheduling model are as follows Figure 7As shown, each scheduled job maps to a task, that is, an executable task entry; at the same time, each scheduled job maps to a scheduler, and the scheduler decides how the task is executed. The default timings supported by the system are "fixed cycle", "fixed delay" and "fixed time".

[0026] Streaming record processing model: a model for processing large data structures. In this model, records are the core, data providers fill data into records, and data controllers process current records. Components drive data providers to continuously fill records until no more data can be provided. This processing unit is suitable for pipeline processing of large amounts of data of the same type.

[0027] The PRH data processing model is used to stream access and process large amounts of data. The model includes basic concepts and basic implementations. This model can unify structured and unstructured data processing and establish a flexible and efficient data processing mechanism.

[0028] The PRH data processing model consists of three parts: R (RecordSet): defines the record structure and drives the model operation. It consists of record sets (RecordSet) and auxiliary classes, records (Record) and fields (Field); P (Provider): Data provider, the interface (DataProvider) defines the behavior of the data provider module; H (Handler): Data processing, defines the behavior of the data processing module.

[0029] The RecordSet process is similar to the mechanism of a task pool. Inside the RecordSet, a work queue is maintained. The Provider continuously puts data into the work queue, and the ThreadHandler continuously takes data from the work queue for processing. Each working thread in the RecordSet maintains a group of handlers. Each handler uses the same group of handler instances to process multiple pieces of data. The RecordSet has an additional error handling mechanism. That is, when the ThreadHandler reports an error, the main thread will judge the cumulative number of reported errors. If the cumulative number of reported errors is within the tolerable range, the main thread continues to distribute data; otherwise, the main thread throws an error. If the ThreadHandler is configured with an exceptionHandler, the exceptionHandler is used to handle the error when an error occurs. However, if no exceptionHandler is configured, the ThreadHandler reports an error, which causes the main control thread to report an error and the execution ends; The execution process of the main thread is as Figure 8 shown. maxExceptionNumber is the maximum number of tolerated errors. When this number is exceeded, the system stops taking data from the producer, but the tasks being executed by the system are not stopped. That is, when the cumulative errors exceed the maximum number of tolerated errors (maxExceptionNumber), there may still be up to: (handlersThreadNumber) - 1 pieces of data being executed, where is the operator thread number. In an extreme case, these handlersThreadNumber - 1 may all report errors again. Although the system is configured with the maximum number of errors as the maximum number of tolerated errors (maxExceptionNumber), the maximum number of reported errors that may occur is maxExceptionNumber + handlersThreadNumber.

[0030] Furthermore, the management items in the task deployment module 20 include service configuration, task configuration, schedule configuration, current tasks, task interference, and historical tasks; Among them, service configuration: used to manage the batch microservices in the system. The batch execution commands will be sent to the batch microservices for execution; Task Configuration: Display task information in the system in the form of a list. The functions provided by the list include: query, enable or disable, add, delete, and edit, etc.; When a task in the task list is selected, the task can be enabled or disabled. Before enabling the task, the configuration of the task cannot be empty. The prerequisite for disabling a task is that there is no task currently running. If there is no running task, disabling the task will also disable the plan associated with the task.

[0031] Schedule Configuration: Used to maintain scheduled or polled schedule information. In the query interface, schedules (schedule numbers or schedule names) or associated tasks can be queried simultaneously. Additionally, new schedules can be added, modified, enabled or disabled, and manually triggered.

[0032] Current Tasks: Used to view currently running tasks. Operations such as query, edit, and delete can be performed on the current tasks. Additionally, when the current task is completed (execution fails or succeeds), the entire task, error unit nodes, and any nodes can be selected to rerun.

[0033] Task Intervention: When tasks are paused or waiting, view the views specified by these manual interventions. When the pause is resumed or the suspended wait is cancelled, the intervention information is automatically deleted.

[0034] Historical Tasks: Used to view past batch processing results. The functions include: querying the list based on task name or description, schedule name or description, start time, end time, and task status.

[0035] By providing a page graphical interface to configure tasks and task routing, the execution interactivity is improved.

[0036] Furthermore, the method for formulating a batch task processing strategy in the task configuration module 10 includes the following steps: S101. Define task metadata through a task (Task) definition file and transmit the task metadata to the task (Task) loading module; S102. Load the task metadata as system-recognizable task metadata through the task (Task) loader in the task (Task) loading module; S103. Transmit the recognized task metadata to the Task running module. Through the Task running engine in the Task running module, instantiate the task metadata into a task entity, obtain the task (Task) entry, match the corresponding task model through the task (Task) entry, and execute the task entity.

[0037] During specific use, the task configuration module 10 is divided into three parts: task definition, task loading, and task running. Task definition is to define task metadata (TaskMeta), and by default, the system uses files to define it; task loading is to load the task carrier (by default, a file) as task metadata recognizable by the system and provide metadata management; the task running module instantiates the task metadata into a task entity and executes the task entity.

[0038] It should be noted that both task definition and loading are organized around the runtime task model. Each runtime task has a task (Task) entry, which represents the entire process of this task. That is, different task models correspond to a task (Task) entry. By matching the task (Task) entry, the corresponding task model can be found. At the same time, a Task can have multiple component units (Unit) and a routing table (RouteMap). Unit represents the task logic unit, and the routing table (RouteMap) defines the flow between logic units.

[0039] Specifically, the method for executing the task entity in S103 includes the following steps: S1031. Detect all task definition files in the system and update the new version files to the database; S1032. Query tasks according to the task name and task description, and perform operations such as modifying, enabling / disabling, deleting, and rerunning on the task configuration files; When disabling a task, it is necessary to ensure that the task is not being executed. After disabling the task, the associated plan is also automatically disabled in the background; When editing a task, it is necessary to ensure that the task is in the disabled state, otherwise it cannot be edited. Editing tasks supports text box editing and graphical interface display; When deleting a task, it is necessary to ensure that the task is in the disabled state and has no associated plan, otherwise it cannot be deleted; When rerunning a task, it is necessary to ensure that the task is in the enabled state, otherwise it cannot be rerun.

[0040] In addition, the method for the task deployment module 20 to perform management and monitoring includes the following steps: S201. Obtain the deployment method by getting the content of the task (Task) entry; S202. Run and process batch tasks according to the deployment method and the matching task model; Deployment methods include single service replica, multiple services with single replica, multiple services with multiple replicas, using a database (DB) to implement asynchronous instructions, and using a message queue (MQ) to implement asynchronous instructions.

[0041] The actual operation steps of the single service replica are as follows: All batch tasks are in the same service. There is no need for a task_manager project. When configuring, you can directly access the task_app project. That is, you can process batch tasks online through a browser and a gateway. First, instantiate the task metadata of the task engine in the task configuration into a task entity, obtain the Task entry, match the corresponding task model through the Task entry, perform sequential scheduling on the batch tasks through the scheduling engine in the scheduling configuration, send them sequentially to the corresponding task model for processing, and perform metadata storage work in real time; The actual operation steps for the multi-service single-replica mode are as follows: In this mode, you can configure and manage multiple batch microservices by accessing the unified view of the task_manager; The actual operation steps for the multi-service multi-replica mode are as follows: In this mode, the task_manager and the task_app do not communicate directly. Instead, the request messages for the required network resource records (RRS) are stored in a database or a message queue (MQ), and are executed by the task_app. The global user interface (i.e., the browser) data is divided into different data centers for processing through a load balancer, and network communication is carried out through a gateway. Each task plan configuration corresponds to a task_manager for monitoring and management, and sequential scheduling is performed in turn. Finally, the tasks are executed in sequence.

[0042] When using a database (DB) to implement the asynchronous instruction mode, the requests sent by the task_manager to the task_app will be recorded in the database, and the task_app will poll the database and execute the instructions.

[0043] When using a message queue (MQ) to implement the asynchronous instruction mode, the requests sent by the task_manager to the task_app will be recorded in the message queue (MQ). The task_app will poll the message queue (MQ) and execute the instructions. At the same time, the parameters of the message queue (MQ) need to be configured. Finally, start the message queue (MQ), and create a new instruction request and response queue for online configuration.

[0044] The basic principles, main features and advantages of the present invention have been shown and described above. Those skilled in the art should understand that the present invention is not limited by the above embodiments. The above embodiments and the descriptions in the specification are only preferred examples of the present invention and are not used to limit the present invention. Without departing from the spirit and scope of the present invention, the present invention will have various changes and improvements, and these changes and improvements all fall within the scope of the present invention claimed. The scope of protection claimed by the present invention is defined by the appended claims and their equivalents.

Claims

1. A batch task running system for scheduling between servers, characterized by: It includes a task configuration module (10), a task deployment module (20) and a task running kernel module (30); The task deployment module (20) is used to receive task instructions in batch tasks and configure management items to manage and monitor the execution process of batch tasks; The task execution kernel module (30) is used to store different types of task models, and respond to the task instructions of the task configuration module (10), and match the corresponding task model according to the content of the task instructions; The task configuration module (10) is used to formulate a batch task processing strategy, including three parts: task definition, task loading, and task running; Among them, task definition is to define the task metadata in the transmission instruction and identify the task metadata type; task loading is to load the carrier of the batch task as task metadata that can be recognized by the system and provide task metadata management; task running instantiates the task metadata into a task entity and transmits it to the task running kernel module (30) to control the corresponding task model to execute and process the batch task.

2. The batch task running system for scheduling between servers according to claim 1 is characterized in that: The task models stored in the task execution kernel module (30) include a serial task model, a parallel unit task model, a subtask model, a task pool model, a timing scheduling model and a streaming record processing model; Serial task model: Use serial tasks to execute batch tasks according to the configured serial routing order; Parallel unit task model: Use parallel unit tasks to execute multiple task metadata; Subtask model: split into several independent subtasks to execute the corresponding number of task units; Task pool model: used to generate multiple data according to data producers; Scheduled scheduling model: The scheduling model consists of three parts: scheduling configuration file, scheduling loading and scheduling execution, and performs scheduled execution work for the complete business meaning; Streaming record processing model: used for pipeline processing of a large number of files of the same type one by one.

3. The batch task running system for scheduling between servers according to claim 1 is characterized in that: The management items in the task deployment module (20) include service configuration, task configuration, plan configuration, current task, task interference and historical task; Among them, service configuration: is used to manage batch microservices in the system, and batch execution commands will be sent to batch microservices for execution; Task configuration: Displays the task information in the system in a list format; Plan configuration: used to maintain timing or polling plan information; Current tasks: used to view the running tasks; Task intervention: when pausing or waiting for a task, view the view specified by manual intervention; Historical tasks: used to view previous batch run results.

4. The batch task running system for scheduling between servers according to claim 1, characterized in that: The method for formulating a batch task processing strategy in the task configuration module (10) comprises the following steps: S101, defining task metadata through a task definition file, and transmitting the task metadata to a task loading module; S102, loading the task metadata into task metadata recognizable by the system through a task loader in a task loading module; S103, transmitting the identified task metadata to the Task running module, instantiating the task metadata into a task entity through the Task running engine in the Task running module, obtaining a task entry, matching the corresponding task model through the task entry, and executing the task entity.

5. The batch task running system for scheduling between servers according to claim 4 is characterized in that: The method for executing the task entity in S103 comprises the following steps: S1031, detecting all task definition XML files in the system, and updating the new version of the XML files to the database; S1032. Query the task according to the task name and task description, and modify, enable or disable, delete or re-run the task configuration file.

6. The batch task running system for scheduling between servers according to claim 1, characterized in that: The method for performing management and monitoring by the task deployment module (20) comprises the following steps: S201, obtain entry (Task) content acquisition deployment method; S202, running and processing batch tasks according to the deployment mode and the matching task model; The deployment methods include single service copy, multiple service single copy, multiple service multiple copies, using database (DB) to implement asynchronous instructions, and using message queue (MQ) to implement asynchronous instructions.

Images