A multi-strategy distributed task orchestration engine system and method

Abstract

This invention discloses a multi-strategy distributed task orchestration engine system and method, relating to the fields of cloud computing and distributed systems. The system includes an orchestration definition module for creating definition scenarios containing task nodes, dependencies, and strategy constraints; a dependency analyzer for parsing the definition scenarios and constructing a task DAG, identifying parallelizable tasks; a resource monitor for collecting load data from computing resource nodes to form snapshots; an intelligent scheduler including a conflict prediction unit and a planning optimization unit, which simulates future scheduling based on the DAG and resource snapshots, predicts resource conflicts, and generates executable orchestration plans; and a task type registry and a task execution engine that uses a unified plugin interface to load and execute plans and monitor strategy constraints. The method includes definition, parsing, monitoring, prediction, optimization, and execution steps, and supports strategies such as short-term conflict preemption / queuing and long-term conflict scaling to improve flexibility, resource utilization, and stability.

Description

Technical Field

[0001] This invention relates to the field of cloud computing and distributed systems, specifically to a multi-strategy distributed task orchestration engine system and method. Background Technology

[0002] With the deepening of enterprise digital transformation, microservice architecture has become the mainstream paradigm for building complex business systems. Under this architecture, a single business application is broken down into dozens or even hundreds of independent, loosely coupled services. A complete business process (such as "order placement - payment - inventory deduction - logistics notification" in e-commerce) typically requires orchestrating a series of tasks across multiple services in a specific order and logic. Currently, the mainstream methods for implementing such distributed task orchestration in the industry mainly include: hard-coded processes, simple triggering based on message queues, and using basic workflow engines. These methods generally suffer from the following shortcomings:

[0003] A. Decoupled from infrastructure: The engine itself is unaware of the dynamic load status of underlying computing resources (such as KubernetesPods and cloud servers) and cannot make optimal scheduling decisions.

[0004] B. Lack of intelligent conflict handling capabilities: When multiple resource-intensive tasks are simultaneously scheduled to the same resource node, or when the overall resource pool is insufficient, traditional engines can usually only perform simple failure retries or wait, and cannot proactively perform resource-level conflict prediction, elastic scaling, or task rescheduling, which can easily lead to system performance bottlenecks and large-scale task delays.

[0005] C. Limited task type support: It is difficult to seamlessly integrate diverse task execution engines (such as HTTP calls, message publishing, script execution, and big data jobs), requiring a lot of custom development. The orchestration strategy is singular and cannot flexibly adapt to the differentiated requirements of different business scenarios for timeouts, retries, priorities, etc.

[0006] In summary, existing technical solutions have significant shortcomings in terms of flexibility, resource utilization efficiency, and scheduling intelligence. They either rigidly define orchestration logic, making it unable to dynamically adapt to changes in business; or they focus only on the logical sequence of tasks, neglecting the collaborative optimization of underlying computing resources, resulting in slow system response, low resource utilization, and high operation and maintenance costs in complex microservice scenarios.

[0007] Therefore, there is an urgent need for a new type of distributed task orchestration engine system that can uniformly manage task logic and resource scheduling, support flexible orchestration with multiple strategies, and automatically resolve resource conflicts. Summary of the Invention

[0008] Based on the above analysis, the present invention provides the following specific implementation scheme: a multi-strategy distributed task orchestration engine system, comprising:

[0009] The orchestration definition module is used to receive user input, create and edit task definition scenarios, whereby a definition scenario refers to a structured template used to describe, configure and visualize the task execution process;

[0010] A dependency analyzer, which is connected to the orchestration definition module, is used to parse the execution dependencies between tasks in the defined scenario and identify tasks that can be executed in parallel.

[0011] An intelligent scheduler, connected to the dependency analyzer, for generating an executable orchestration plan, the intelligent scheduler comprising:

[0012] The conflict prediction unit simulates future task scheduling based on the execution dependencies between tasks and tasks that can be executed in parallel, and predicts resource conflict periods. The resource conflict period refers to the time interval on the time axis where the predicted total demand of multiple tasks scheduled to the same resource for that resource exceeds the total available resources of that resource.

[0013] The planning and optimization unit generates a final executable orchestration plan based on the resource conflict period and the tasks involved.

[0014] A task execution engine, which is used to load and execute the orchestration plan.

[0015] Preferably, the defined scenario is a structured template for describing task orchestration, which includes at least task nodes, dependencies between the task nodes, and policy constraints of the task nodes.

[0016] Preferably, the policy constraint refers to the structured attributes configured for the task node, which are used to control and constrain the execution behavior, resource allocation, or scheduling priority of the task node.

[0017] Preferably, it also includes a resource monitor, which is used to communicate with the computing resource nodes and collect the load indicators of each computing resource node in real time. The computing resource node refers to the smallest manageable computing unit that actually carries and executes computing tasks.

[0018] Preferably, it also includes a task type registry center, which is connected to the task execution engine. The task type registry center is used to register and manage executable task type plugins, whereby a task type plugin refers to software that contains a certain task type and an executor for that task type.

[0019] Preferably, the task type plugin adopts a unified execution interface.

[0020] A task orchestration method based on the multi-strategy distributed task orchestration engine system includes the following steps:

[0021] S1: Create a task definition scenario through the orchestration definition module, including task nodes, dependencies between task nodes, and policy constraints of the task nodes;

[0022] S2: The defined scenario is parsed by the dependency analyzer: a task DAG (Directed Acyclic Graph) is constructed, and topological sorting and task grouping are performed to obtain the topological sorting results and parallel task grouping, thereby determining the set of tasks that can be executed in parallel;

[0023] S3: The resource monitor collects the load indicators of each computing resource node in real time to form a resource load snapshot. The resource load snapshot includes the unique identifier of each computing resource node, the total amount of available resources, and the amount of resources currently consumed.

[0024] S4: The conflict prediction unit of the intelligent scheduler simulates future scheduling, predicts resource conflict periods, and provides the resource load snapshot to the intelligent scheduler based on the dependencies between the task nodes and the set of tasks that can be executed in parallel.

[0025] S5: The planning and optimization unit of the intelligent scheduler generates a final executable orchestration plan based on the resource conflict period and the tasks involved;

[0026] S6: The task execution engine loads and executes the orchestration plan. The task execution engine calls the task type plugin in the corresponding task type registry to execute the task and monitors the policy constraints.

[0027] Preferably, the task DAG in S2 is constructed by establishing directed edges based on the dependencies between the task nodes; and the policy constraint terms are used as graph node attributes or scheduling constraints to participate in subsequent scheduling.

[0028] Preferably, the planning and optimization unit in S5 receives the resource conflict period and the tasks involved, and applies different resolution strategies according to the characteristics of the tasks involved:

[0029] Short-term conflict: If the resource conflict occurs within the next 30 seconds, the priorities of the conflicting tasks are compared. If the new task has a higher priority than the old task, the new task is allowed to preempt the resource and the old task is paused, and the old task enters the waiting queue; otherwise, the new task waits in the queue. The new task is the task that enters the scheduling queue after the resource conflict determination time; the old task is the running task that has occupied the relevant resources.

[0030] Mid-term conflict: If the resource conflict occurs within five minutes after the next 30 seconds, the system will wait for the task to be executed according to priority;

[0031] Long-term conflict: If the resource conflict occurs more than five minutes later, the workload of the task node will be expanded by adding instances to share the load and resolve the conflict.

[0032] Preferably, the planning and optimization unit makes a final scheduling decision, which is defined by the planning and optimization unit as follows: the planning and optimization unit defines an optimization objective function:

[0033] Total cost = W1 * estimated completion time + W2 * resource load balancing index;

[0034] Among them, the total cost refers to the total consumption to complete the conflict resolution, W1 and W2 are configurable weight coefficients, the resource load balance index refers to the load difference of each computing resource node during the plan execution period, and the estimated completion time refers to the estimated time required to complete the conflict resolution.

[0035] The beneficial effects of this invention are:

[0036] (1) By defining scenarios (task nodes + dependencies + strategy constraints), the process configuration and visualization are realized, and the orchestration logic and business code are decoupled. At the same time, a plugin mechanism of task type registration center and unified execution interface is introduced, which can seamlessly access multiple types of tasks such as HTTP, message, script, and big data jobs, reduce the cost of customized development, and support different strategies for different tasks in terms of timeout, retry, priority, etc.

[0037] (2) The task DAG is constructed by the dependency analyzer and parallelizable tasks are identified. The resource monitor provides real-time resource load snapshots. The intelligent scheduler performs conflict prediction and planning optimization based on this. Through optimization decisions with the goal of estimated completion time and load balancing, more reasonable task allocation and concurrency control are achieved, hot nodes and resource idleness are reduced, and overall throughput and response speed are improved.

[0038] (3) The conflict prediction unit can detect resource conflict periods in advance. The planning and optimization unit adopts multiple strategies to resolve conflicts based on their characteristics (such as priority preemption / queuing for short-term conflicts and capacity sharing for long-term conflicts), avoiding cascading congestion and large-scale delays caused by passive retrying / waiting alone, thereby improving the stability of process execution and SLA assurance capabilities. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0040] Figure 1This is a structural diagram of the system modules in this invention;

[0041] Figure 2 This is a flowchart of resource scheduling and conflict resolution in this invention. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0043] This invention provides a multi-strategy distributed task orchestration engine system, aiming to solve the problems of poor flexibility, high resource conflict rate, and inability to dynamically schedule on demand in existing distributed task orchestration methods under complex business scenarios. This invention provides an engine system that supports multi-strategy, visual orchestration, and can automatically resolve resource and dependency conflicts, such as... Figure 1 As shown, it includes: an orchestration definition module, a task type registry center, a dependency analyzer, a resource monitor, an intelligent scheduler, and a task execution engine, wherein:

[0044] The orchestration definition module provides a visual orchestration interface for receiving user input, creating and editing business process scenario definitions. Scenario definitions include task nodes, dependencies between task nodes, and policy constraints for each task node. Policy constraints include automatic interruption of task process timeout and automatic retry when task process fails.

[0045] The dependency analyzer is connected to the orchestration definition module. The dependency analyzer creates a graph node for each task node in the defined scenario and establishes directed edges between the graph nodes according to the dependencies between the task nodes, thereby constructing a task DAG. The policy constraints are used as graph node attributes or scheduling constraints in subsequent scheduling.

[0046] The resource monitor is used to communicate with computing resource nodes (such as Kubernetes nodes and cloud host instances) and collect load metrics of each node in real time. Load metrics include: CPU utilization, memory utilization, network I / O, disk storage, and current task load.

[0047] The intelligent scheduler connects to both the dependency analyzer and the resource monitor to predict conflicts, plan optimizations, and generate executable orchestration plans. The intelligent scheduler includes:

[0048] Conflict prediction unit: Based on the task DAG and node load indicators, simulate future scheduling and predict resource conflict periods. Resource conflict periods refer to the time interval on the time axis when the predicted total demand of multiple tasks scheduled to the same resource for that resource exceeds the total available resources of that resource.

[0049] The planning and optimization unit generates a conflict resolution plan based on the resource conflict period, the tasks involved, preset priority rules, resource reservation strategies, and elastic scaling interfaces. Priority rules refer to the pre-defined execution weights of task nodes, used to determine the scheduling order during resource contention, such as priorities 1-10. Resource reservation strategies are a means of pre-locking computing resources; for example, when allocating tasks, the scheduler prioritizes scheduling high-priority tasks to nodes with a "high guarantee" label. Elastic scaling interfaces are standardized APIs for interaction between the system and computing resource nodes, used to dynamically adjust the scale of computing resources, such as through the cloud platform's resource reservation API. The planning and optimization unit optimizes the resolved task allocation plan based on time and stability weights, generating a final executable orchestration plan.

[0050] The task type registry is connected to the task execution engine. It registers and manages executable task type plugins (such as HTTP callers, message publishers, and script executors). A task type plugin is software that contains a specific task type and its executor. Each task type plugin implements a unified execution interface.

[0051] The system provides scalable, pluggable task execution capabilities through a task type registry center. Each task type is implemented as an independent pluggable, following a unified execution interface (e.g., TaskExecutor), which at least defines the executor object and the executor type. When a user selects a type for a task node in the orchestration definition module, they are essentially binding the specific pluggable that will be invoked at runtime.

[0052] Policy constraints are bound to task nodes as metadata and stored in the scenario definition as key-value pairs or structured objects for management during subsequent scheduling and execution phases. Table 1 lists some core task type plugins and their corresponding execution logic to illustrate the system's scalability:

[0053] Task type Corresponding executor plugin Plugin Core Functionality Summary HTTP synchronous call HttpTaskExecutor Encapsulate clients such as Feign / RestTemplate to initiate HTTP(S) requests to a specified URL and synchronously wait for and parse the response. Asynchronous message triggering MessageTaskExecutor As a RocketMQ / Kafka producer, you publish messages to a specified topic, triggering downstream asynchronous services. Database transactions TransactionTaskExecutor Execute a set of SQL statements on a defined database connection and manage the commit and rollback of local transactions. Script execution ScriptTaskExecutor It has an embedded Groovy / Python engine that executes user-defined business scripts in an isolated sandbox environment. Manual approval node HumanTaskExecutor Integrate with external workflow engines or notification systems to suspend tasks and wait for human approval before continuing. Data Query / Aggregation DataQueryTaskExecutor Execute predefined database queries or invoke aggregation jobs from big data platforms such as Spark.

[0054] Table 1

[0055] The task execution engine is used to load and execute orchestration plans, call task type plugins from the task type registry center according to the orchestration plan, and supervise the execution of policy constraints. Policy constraints are bound to task nodes as metadata and are used for management in subsequent scheduling and execution phases. The task execution engine calls plugins to execute tasks and monitors task status.

[0056] Example 2 This example provides a task orchestration method based on Example 1, such as Figure 2 As shown, it includes the following steps:

[0057] S1: Create task definition scenarios through the orchestration definition module, and define task nodes, dependencies between task nodes, and strategy constraints of task nodes;

[0058] S1.1: Define the logical sequence of tasks through the orchestration definition module to form a flowchart;

[0059] S1.2: Configure the task type and specific parameters (such as HTTPURL, message topic, database table or script content) for each task node from the task type registry center.

[0060] S1.3: Configure policy constraints for each task node. Policy constraints are stored as attributes of the node. Policy constraints include at least: execution timeout threshold, retry policy (maximum number of retries, retry interval), explicitly declared list of dependent tasks, priority value, and estimated resource requirements (number of CPU cores, memory size, disk size).

[0061] S1.4: Associate a resource pool with the entire process. The resource pool defines the range of computing resources that can be scheduled and used in this process.

[0062] S1.5: The orchestration definition module serializes all the above information into a structured scene object and stores it persistently;

[0063] S2: Parse the scene object, construct the task DAG, and perform topological sorting and task grouping;

[0064] S2.1: The scenario is defined by parsing the dependency analyzer, a graph node is created for each task node, and directed edges are established based on the "explicitly declared list of dependent tasks" attribute in the task node, thereby constructing a task DAG that describes the task execution order;

[0065] S2.2: The dependency analyzer performs topological sorting on the task DAG to obtain one or more valid linear execution sequences. Simultaneously, based on this sorting, all nodes with an in-degree of zero (no prior dependencies) in the graph are marked as "ready tasks" and added to the initial ready task queue. The system hierarchically divides tasks according to their depth in the task DAG; tasks at the same level can be executed in parallel.

[0066] S2.3: The intelligent scheduler performs feature analysis and grouping of tasks at the same level based on their estimated resource requirements (such as CPU and memory size) and priority attributes. Specifically, the system automatically identifies and groups tasks with both resource requirements and priorities exceeding a preset threshold into a "resource-intensive high-priority group." The purpose of this grouping is to enable centralized resource prediction and conflict prevention for such tasks in subsequent scheduling.

[0067] S3: Collect real-time load data of computing resource nodes through the resource monitor to form a resource load snapshot. The resource monitor continuously pulls load indicators from registered computing resource nodes (such as K8sNode, cloud server) to form a global resource load snapshot. This snapshot includes the unique identifier of each computing resource node, the total amount of available resources, and the amount of resources currently consumed.

[0068] S4: Based on task DAG and resource load snapshots, simulate future scheduling and predict resource conflict periods;

[0069] S4.1: The conflict prediction unit within the intelligent scheduler initiates simulated scheduling. Starting with the ready task queue in S2.2, the conflict prediction unit performs iterative simulations using the following data:

[0070] Task requirements: Estimated resource requirements (CPU, memory) for each task.

[0071] Task node status: Resource load snapshot.

[0072] Scheduling strategy: Basic scheduling strategies, such as "prioritizing scheduling tasks to the task nodes with the lowest current load and that meet the requirements".

[0073] Task duration estimation: Based on historical execution data of the task type or user preset values, an estimated execution duration (such as average or P90 percentile) can be assigned to the task.

[0074] S4.2: During the simulation, the conflict prediction unit maintains a resource usage plan table for each computing resource node, representing a future timeline. When a new task is scheduled to a computing resource node, the unit checks whether the node's planned cumulative resource usage will exceed its safety threshold (e.g., CPU utilization of 80%) during the task's estimated execution period. If so, it records this as a predicted conflict event, including the conflicting computing resource node, the conflict period, and a list of tasks involved.

[0075] S5: Based on preset priority rules and elastic scaling interface, resolve predicted conflicts and generate a final executable orchestration plan based on the resource conflict period and the tasks involved.

[0076] S5.1: The planning and optimization unit receives predicted conflict events and applies different resolution strategies based on the conflict characteristics.

[0077] Short-term conflict: If the resource conflict occurs within the next 30 seconds, the priorities of the conflicting tasks are compared. If the new task has a higher priority than the old task, the new task is allowed to preempt the resource and the old task is paused, and the old task enters the waiting queue; otherwise, the new task waits in the queue. Among them, the new task is the task that enters the scheduling queue after the time when the resource conflict is determined; the old task is the running task that has occupied the relevant resources.

[0078] Mid-term conflict: If a resource conflict occurs within the next 30 seconds to 5 minutes, the system will wait for the task to be executed according to its priority.

[0079] Long-term conflict: If a conflict is predicted to occur more than five minutes from now, the workload of the task node will be scaled up by adding instances to share the load and thus resolve the conflict.

[0080] S5.2: After initial conflict resolution, the planning and optimization unit makes the final scheduling decision from a global perspective. The planning and optimization unit defines an optimization objective function:

[0081] Total cost = W1 * estimated completion time + W2 * resource load balancing index;

[0082] Among them, the total cost refers to the total consumption to complete the conflict resolution, W1 and W2 are configurable weight coefficients, the resource load balance index refers to the load difference of each computing resource node during the plan execution period, and the estimated completion time refers to the completion time of the conflict resolution.

[0083] S5.3: The output of the optimization algorithm is serialized into a final executable orchestration plan; the orchestration plan is a timetable containing multiple scheduling entries, each of which includes at least the planned execution time, task identifier, target computing resource node identifier, task type plugin identifier, and control instructions such as timeout and retry; for example, at time T1, task A is scheduled to node Node-X, and the task execution engine calls the HttpTaskExecutor plugin corresponding to the task type of task A to execute it, carrying its timeout threshold, retry policy, and other control instructions.

[0084] S6: Load and execute the orchestration plan, with the task execution engine calling the corresponding task type plugins to execute the task and monitoring policy constraints;

[0085] S6.1: The task execution engine loads the orchestration plan. At the time specified in the plan, the task execution engine retrieves the corresponding plugin instance from the task type registry, injects parameters and context, and triggers task execution on the specified target computing resource node. The engine strictly monitors the execution status of each computing resource node and enforces the policy constraints of each computing resource node;

[0086] S6.2: The resource monitor continuously monitors the actual execution status. If an unplanned event occurs, such as a computing resource node's actual load far exceeding prediction, causing slow task execution, or a task failing and retries running out, the monitor will immediately issue a warning to the intelligent scheduler. Based on this warning, the intelligent scheduler can trigger a local process from conflict prediction to resolution to optimization, rescheduling subsequent tasks that have not yet been executed in real time, thereby ensuring the robustness of the entire process.

[0087] The prior description of the invention is provided to enable any person skilled in the art to make or use the invention. Various modifications to the invention will be apparent to those skilled in the art, and the general principles defined herein can be applied to other variations without departing from the spirit or scope of the invention. Thus, the invention is not intended to be limited to the examples and designs described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0088] The embodiments of the present invention have been described in detail above. The description of the embodiments above is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A multi-strategy distributed task orchestration engine system, characterized in that, include: The orchestration definition module is used to receive user input, create and edit task definition scenarios, whereby a definition scenario refers to a structured template used to describe, configure and visualize the task execution process; A dependency analyzer, which is connected to the orchestration definition module, is used to parse the execution dependencies between tasks in the defined scenario and identify tasks that can be executed in parallel. An intelligent scheduler, connected to the dependency analyzer, for generating an executable orchestration plan, the intelligent scheduler comprising: The conflict prediction unit simulates future task scheduling based on the execution dependencies between tasks and tasks that can be executed in parallel, and predicts resource conflict periods. The resource conflict period refers to the time interval on the time axis where the predicted total demand of multiple tasks scheduled to the same resource for that resource exceeds the total available resources of that resource. The planning and optimization unit generates a final executable orchestration plan based on the resource conflict period and the tasks involved. A task execution engine, which is used to load and execute the orchestration plan.

2. The multi-strategy distributed task orchestration engine system of claim 1, wherein, The defined scenario is a structured template used to describe task orchestration, which includes at least task nodes, dependencies between the task nodes, and policy constraints of the task nodes.

3. The multi-strategy distributed task orchestration engine system of claim 2, wherein, The policy constraint refers to the structured attributes configured for the task node, which are used to control and constrain the execution behavior, resource allocation, or scheduling priority of the task node.

4. The multi-strategy distributed task orchestration engine system of claim 1, wherein, It also includes a resource monitor, which is used to communicate with the computing resource nodes and collect the load indicators of each computing resource node in real time. The computing resource node refers to the smallest manageable computing unit that actually carries and executes computing tasks.

5. The multi-strategy distributed task orchestration engine system of claim 1, wherein, It also includes a task type registry center, which is connected to the task execution engine. The task type registry center is used to register and manage executable task type plugins. A task type plugin refers to software that contains a certain task type and an executor for that task type.

6. The multi-strategy distributed task orchestration engine system of claim 5, wherein, The task type plugins use a unified execution interface.

7. A task orchestration method based on the multi-strategy distributed task orchestration engine system according to any one of claims 1 to 6, characterized in that, Includes the following steps: S1: Create a task definition scenario through the orchestration definition module, including task nodes, dependencies between task nodes, and policy constraints of the task nodes; S2: The defined scenario is parsed by the dependency analyzer: a task DAG (Directed Acyclic Graph) is constructed, and topological sorting and task grouping are performed to obtain the topological sorting results and parallel task grouping, thereby determining the set of tasks that can be executed in parallel; S3: The resource monitor collects the load indicators of each computing resource node in real time to form a resource load snapshot. The resource load snapshot includes the unique identifier of each computing resource node, the total amount of available resources, and the amount of resources currently consumed. S4: The conflict prediction unit of the intelligent scheduler simulates future scheduling, predicts resource conflict periods, and provides the resource load snapshot to the intelligent scheduler based on the dependencies between the task nodes and the set of tasks that can be executed in parallel. S5: The planning and optimization unit of the intelligent scheduler generates a final executable orchestration plan based on the resource conflict period and the tasks involved; S6: The task execution engine loads and executes the orchestration plan. The task execution engine calls the task type plugin in the corresponding task type registry to execute the task and monitors the policy constraints.

8. The task orchestration method according to claim 7, characterized in that, The task DAG described in S2 is constructed by establishing directed edges based on the dependencies between the task nodes; and by using the policy constraint terms as graph node attributes or scheduling constraints in subsequent scheduling.

9. The task orchestration method according to claim 7, characterized in that, The planning and optimization unit in S5 receives the resource conflict period and the tasks involved, and applies different resolution strategies according to the characteristics of the tasks involved: Short-term conflict: If the resource conflict occurs within the next 30 seconds, the priorities of the conflicting tasks are compared. If the new task has a higher priority than the old task, the new task is allowed to preempt the resource and the old task is paused, and the old task enters the waiting queue; otherwise, the new task waits in the queue. The new task is the task that enters the scheduling queue after the resource conflict determination time; the old task is the running task that has occupied the relevant resources. Mid-term conflict: If the resource conflict occurs within five minutes after the next 30 seconds, the system will wait for the task to be executed according to priority; Long-term conflict: If the resource conflict occurs more than five minutes later, the workload of the task node will be expanded by adding instances to share the load and resolve the conflict.

10. The task orchestration method according to claim 7, characterized in that, The planning and optimization unit will make a final scheduling decision, which is defined by the planning and optimization unit as follows: Total cost = W1 * estimated completion time + W2 * resource load balancing index; Among them, the total cost refers to the total consumption to complete the conflict resolution, W1 and W2 are configurable weight coefficients, the resource load balance index refers to the load difference of each computing resource node during the plan execution period, and the estimated completion time refers to the estimated time required to complete the conflict resolution.

Images