Task processing method and related device

Abstract

A task processing method, applied to an operation and maintenance platform. The operation and maintenance platform comprises an event queue and a task executor. The method comprises: the event queue receives at least one operation and maintenance task of an application, and adds task events corresponding to the at least one operation and maintenance task to the event queue; the task executor fetches a first task event from the event queue, calls a first execution unit in an execution unit resource pool, executes a first subtask, delivers an operation of the first subtask on a resource to the resource, and releases the first execution unit; the event queue receives a first resource event sent by the resource; and on the basis of the state of the resource described by the first resource event, the task executor determines a next task or a next subtask to be processed, and executes the next task or the next subtask. The method is event-centric, and an operation and maintenance task, a subtask, and the state of a resource are processed as an event, so that a task is processed from a smaller granularity. Moreover, an execution unit is not blocked by a waiting state of an operation and maintenance task, so that the resource utilization is improved.

Description

A task processing method and related equipment

[0001] This application claims priority to Chinese Patent Application No. 202411586176.X, filed on November 7, 2024, entitled "A Task Processing Method and Related Equipment", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of operation and maintenance technology, and in particular to a task processing method, operation and maintenance platform, computing device cluster, computer-readable storage medium, and computer program product. Background Technology

[0003] To ensure the long-term stable operation of applications, maintenance tasks can be performed through an operations and maintenance platform. Operations and maintenance (O&M) essentially involves the operation and maintenance of applications at each stage of their lifecycle, achieving a mutually acceptable balance in terms of cost, stability, and efficiency. O&M tasks may include, but are not limited to, starting, stopping, restarting, or upgrading applications.

[0004] Some operational tasks are quite complex, such as long-running tasks which have relatively high complexity. The operations and maintenance platform can break down these complex tasks into multiple sub-tasks and then execute them. Taking an integrated business flow as an example, when an error occurs during the execution of an integrated business flow, the operations and maintenance platform can execute a flow retry task. This flow retry task can be broken down into the following sub-tasks: 1. Stop the integrated business flow; 2. Wait for the integrated business flow to stop successfully; 3. Start the integrated business flow; 4. Wait for the integrated business flow to start successfully; 5. If the application fails to start successfully, repeat the above steps three times, with a 30-second interval between each retry.

[0005] However, each operation and maintenance task usually requires a separate thread to run. Even though complex operation and maintenance tasks have been broken down, resource utilization is still low when executing complex operation and maintenance tasks. Summary of the Invention

[0006] This application provides a task processing method that uses events as the central focus, treating the states of maintenance tasks, subtasks, and resources as events for processing. This allows for the decomposition and processing of tasks at a finer granularity. When executing a task or subtask, operations on resources are distributed to those resources, and execution units such as threads can be released immediately without waiting for resource operations to complete. Execution units are not blocked by the waiting state of maintenance tasks, thus improving resource utilization. This application also provides a corresponding maintenance platform, computing device cluster, computer-readable storage medium, and computer program product.

[0007] Firstly, this application provides a task processing method. This method is applied to an operations and maintenance (O&M) platform. The O&M platform is used to execute O&M tasks for applications. The O&M platform can be software, and the software can be standalone O&M software. Depending on the application being operated on, the O&M software can be different. For example, the O&M software can be an integration platform as a service, a microservice hosting platform, a function hosting platform, or a virtual machine and container management O&M platform. It should be noted that this application can also be applied to management O&M platforms deployed in private clouds and hybrid clouds of data centers. The aforementioned O&M platform can manage and execute O&M tasks within the platform, especially optimizing the processing of complex O&M tasks, thereby improving resource utilization. In some examples, the O&M platform can also be hardware, which can be a cluster of computing devices with O&M capabilities. When the computing device cluster is running, it executes the task processing method of this application.

[0008] Specifically, the operation and maintenance platform includes an event queue and a task executor. The task executor includes an execution unit resource pool, which includes at least one execution unit. The event queue receives at least one operation and maintenance task from the application, adds the task events corresponding to the at least one operation and maintenance task to the event queue, and the task events corresponding to the at least one operation and maintenance task are represented by the task information of the at least one operation and maintenance task. The task executor retrieves a first task event from the event queue, calls the first execution unit in the execution unit resource pool, and executes a first subtask. The first subtask includes subtasks decomposed from the first operation and maintenance task corresponding to the first task event, distributes the operations of the first subtask on the resource to the resource, and releases the first execution unit. The resource includes the application or its modules and components. The event queue receives a first resource event sent by the resource, which describes the state of the resource. Based on the state of the resource, the task executor determines the next task or the next subtask to be processed and executes the next task or the next subtask.

[0009] This method is event-centric, decomposing complex operational tasks (such as long-running tasks) into subtasks. Operational tasks, subtasks, and resource states are treated as separate events, allowing for finer-grained task decomposition and processing. Specifically, the task executor, upon issuing the first subtask's operation to the resource, can release the corresponding execution unit (e.g., releasing threads) without waiting for the resource operation to complete. This prevents execution units from being blocked by the waiting state of operational tasks, improving resource utilization. A single execution unit can handle more subtasks, enhancing the scalability of task scheduling and processing, and maximizing the utilization of execution units. Furthermore, this method can dynamically determine the next task or subtask to be executed in real-time based on the resource's state, improving the flexibility and agility of task scheduling.

[0010] In some possible implementations, when the resource status is successful, the task executor can check whether the first maintenance task corresponding to the first task event includes a pending subtask. If so, the task executor generates a subtask event, adds it to the event queue, and uses the subtask event to indicate the second subtask to be executed from the first maintenance task. The task executor retrieves the subtask event from the event queue, calls the second execution unit in the execution unit resource pool, executes the second subtask, distributes the second subtask's resource operations to the resource, and releases the second execution unit.

[0011] On the one hand, this method can determine the next task or subtask to be executed in real time based on the status of resources, improving the flexibility of task scheduling. On the other hand, this method refines the granularity of task processing to the event level, avoiding the blocking of execution units by the waiting state of operation and maintenance tasks, and improving resource utilization.

[0012] In some possible implementations, the task executor can check for the arrival of conflicting tasks based on the task information of the first maintenance task. A conflicting task is a maintenance task that causes the current maintenance task (such as the first maintenance task) to stop. In some examples, the conflicting task has a higher priority than the current maintenance task. If the task executor does not detect a conflicting task, it generates a subtask event and adds it to the event queue.

[0013] This method checks for conflicting tasks. If no conflicting tasks arrive, it generates a new subtask event to continue executing the new subtask, thus avoiding the impact on user experience caused by untimely execution of conflicting tasks.

[0014] In some possible implementations, the task executor detects the arrival of a conflicting task and, based on the task information of the second subtask, determines the task operation for the first maintenance task to which the second subtask belongs. The task operation includes stopping or rolling back. The task information of the second subtask can be the task information of the first maintenance task to which the second subtask belongs.

[0015] This method takes into account that operation and maintenance tasks may be related to transactions. When a conflicting task is detected, it further determines whether to stop or roll back the task execution to ensure the stability of the system state.

[0016] In some possible implementations, when a resource is in a failed state, the task executor obtains the retry count for the first maintenance task. If the retry count is less than the maximum retry count, a retry subtask event is generated and added to the event queue. The retry subtask event is used to retry the first subtask.

[0017] This method improves the flexibility of task scheduling by deciding whether to generate a retry subtask when the resource status is failed, based on the relationship between the number of retries and the maximum number of retries.

[0018] In some possible implementations, the task executor updates the status of the first maintenance task based on its execution status or that of its subtasks. The status of the first maintenance task includes creation, abandonment, running, stopped, success, or failure. This method, by updating the status of the first maintenance task, can provide a reference for the scheduling and processing of subsequent maintenance tasks.

[0019] In some possible implementations, the task executor retrieves a first task event from the event queue, checks whether the event queue includes a second task event, and confirms that the second maintenance task corresponding to the second task event is in a running state, and that the task type of the second maintenance task is the same as that of the first maintenance task, and that the task object of the second maintenance task is the same as that of the first maintenance task. If not, the task executor calls the first execution unit in the execution unit resource pool to execute the first subtask.

[0020] This avoids the instability of the system state caused by repeatedly executing the same operation and maintenance tasks, and also avoids wasting resources.

[0021] In some possible implementations, if so, it means that there are identical operation and maintenance tasks being executed, and the task executor can discard the first operation and maintenance task, thereby improving resource utilization.

[0022] In some possible implementations, the operations and maintenance platform also includes a task storage module. The task storage module stores task information for at least one operations and maintenance task. The event queue can receive at least one operations and maintenance task sent by the task storage module. This method persists the task information of operations and maintenance tasks through the task storage module, facilitating subsequent retrieval of task information and flexible task scheduling.

[0023] In some possible implementations, operational tasks include user tasks or system tasks. User tasks are triggered by users through the console or through an application programming interface (API). This allows for the support of diverse operational needs.

[0024] Secondly, this application provides an operation and maintenance platform. The operation and maintenance platform is used to execute operation and maintenance tasks for applications. The operation and maintenance platform includes an event queue and a task executor. The task executor includes an execution unit resource pool, and the execution unit resource pool includes at least one execution unit.

[0025] The event queue is used to receive at least one operation and maintenance task of the application, add the task events corresponding to the at least one operation and maintenance task to the event queue, and the task events corresponding to the at least one operation and maintenance task are represented by the task information of the at least one operation and maintenance task.

[0026] The task executor is used to retrieve a first task event from the event queue, call a first execution unit in the execution unit resource pool, execute a first subtask, the first subtask including a subtask decomposed from the first operation and maintenance task corresponding to the first task event, distribute the operation of the first subtask on the resource to the resource, and release the first execution unit, the resource including the application or the application's modules and components;

[0027] The event queue is also used to receive a first resource event sent by the resource, wherein the first resource event describes the state of the resource;

[0028] The task executor is further configured to determine the next task or the next subtask to be processed based on the state of the resource, and execute the next task or the next subtask.

[0029] In some possible implementations, the task executor is specifically used for:

[0030] When the status of the resource is successful, check whether the first maintenance task corresponding to the first task event includes the next sub-task to be processed.

[0031] If so, generate a subtask event and add the subtask event to the event queue. The subtask event is used to indicate the execution of the second subtask of the first operation and maintenance task.

[0032] The subtask event is retrieved from the event queue, the second execution unit in the execution unit resource pool is invoked to execute the second subtask, the operation of the second subtask on the resource is sent to the resource, and the second execution unit is released.

[0033] In some possible implementations, the task executor is also used for:

[0034] Based on the task information of the first maintenance task, check if any conflicting tasks have arrived;

[0035] The task executor is specifically used for:

[0036] If no conflicting task is detected, a subtask event is generated and added to the event queue.

[0037] In some possible implementations, the task executor is also used for:

[0038] Upon detecting the arrival of the conflicting task, based on the task information of the second subtask, determine the task operation for the first maintenance task to which the second subtask belongs. The task operation includes stopping or rolling back.

[0039] In some possible implementations, the task executor is specifically used for:

[0040] When the resource status is failure, the number of retries for the first operation and maintenance task is obtained. When the number of retries is less than the maximum number of retries, a retry subtask event is generated and added to the event queue. The retry subtask event is used to retrieve the first subtask.

[0041] In some possible implementations, the task executor is also used for:

[0042] Update the status of the first operation and maintenance task based on the execution status of the first operation and maintenance task or its sub-tasks. The status of the first operation and maintenance task includes creation, abandonment, running, stopped, success, or failure.

[0043] In some possible implementations, the task executor is specifically used for:

[0044] Take the first task event from the event queue, check whether the event queue includes the second task event, the status of the second operation and maintenance task corresponding to the second task event is running, and the task type of the second operation and maintenance task is the same as the task type of the first operation and maintenance task, and the task object of the second operation and maintenance task is the same as the task object of the first operation and maintenance task.

[0045] If not, invoke the first execution unit in the execution unit resource pool to execute the first subtask.

[0046] In some possible implementations, the task executor is also used for:

[0047] If so, abandon the first maintenance task.

[0048] In some possible implementations, the operation and maintenance platform further includes a task storage module, which is used to store task information of the at least one operation and maintenance task;

[0049] The event queue is specifically used for:

[0050] Receive at least one maintenance task sent by the task storage module.

[0051] In some possible implementations, the operation and maintenance tasks include user tasks or system tasks, wherein the user tasks are triggered by the user through a console or through an application programming interface.

[0052] Thirdly, this application provides a computing device cluster. The computing device cluster includes at least one computing device, and the at least one computing device includes at least one processor and at least one memory. The at least one processor and the at least one memory communicate with each other. The at least one processor is used to execute instructions stored in the at least one memory to cause the computing device or the computing device cluster to perform the task processing method as described in the first aspect or any implementation thereof.

[0053] Fourthly, this application provides a computer-readable storage medium storing instructions that instruct a computing device or a cluster of computing devices to perform the task processing method described in the first aspect or any implementation thereof.

[0054] Fifthly, this application provides a computer program product containing instructions that, when run on a computing device or a cluster of computing devices, causes the computing device or cluster of computing devices to perform the task processing method described in the first aspect or any implementation thereof.

[0055] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0056] To more clearly illustrate the technical methods of this application, the accompanying drawings used will be briefly described below.

[0057] Figure 1 is a schematic diagram of a process for performing operation and maintenance tasks provided in this application;

[0058] Figure 2 is a schematic diagram of the architecture of an operation and maintenance platform provided in this application;

[0059] Figure 3 is a framework diagram of an operation and maintenance platform provided in this application;

[0060] Figure 4 is a flowchart of a task processing method provided in this application;

[0061] Figure 5 is a schematic diagram of an event queue provided in this application;

[0062] Figure 6 is a schematic diagram of the execution process of an operation and maintenance task provided in this application;

[0063] Figure 7 is a flowchart illustrating how this application determines the next task or subtask to be processed based on the state of resources.

[0064] Figure 8 is a schematic diagram of the structure of a computing device provided in this application;

[0065] Figure 9 is a schematic diagram of the structure of a computing device cluster provided in this application;

[0066] Figure 10 is a schematic diagram of another computing device cluster provided in this application;

[0067] Figure 11 is a schematic diagram of another computing device cluster provided in this application. Detailed Implementation

[0068] The terms "first" and "second" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first" and "second" may explicitly or implicitly include one or more of that feature.

[0069] First, some technical terms involved in the embodiments of this application will be introduced.

[0070] An application (or app) is a primary category of software, referring to a program written for a specific user application purpose. Examples include text processors, spreadsheets, accounting applications, browsers, media players, flight simulators, command-line games, and image editors. Applications can also be categorized based on development models; for instance, applications can include integrated applications and microservice applications. Integrated applications can be those that integrate business systems with process engines, including integrated business flows. Integrated business flows can be derived from Business Process Management (BPM) integration or from business-driven BPM.

[0071] Operations and Maintenance (O&M) refers to the operation and maintenance of an application throughout its lifecycle, aiming to achieve a consistent and acceptable state in terms of cost, stability, and efficiency. O&M is typically achieved by executing O&M tasks. These tasks may include, but are not limited to, starting, stopping, restarting, or upgrading the application.

[0072] For complex operational tasks, such as long-running tasks, they can be broken down into multiple sub-tasks for execution. Taking the operational example of an integrated business flow, if an error occurs during the execution of the integrated business flow, the operational platform can execute a flow retry task. The flow retry task can be broken down into the following sub-tasks: 1. Stop the business flow; 2. Wait for the business flow to stop successfully; 3. Start the business flow; 4. Wait for the business flow to start successfully; 5. If the application fails to start successfully, repeat the above steps 3 times, with a 30-second interval.

[0073] Complex operational tasks also arise in the operational platforms of other applications. For example, a microservice management platform can perform rolling upgrade tasks on microservice instances. A rolling upgrade task can be broken down into the following sub-tasks: 1. Stop the microservice instance; 2. Wait for the microservice instance to stop successfully; 3. Wait for the microservice instance to start; 4. Start the microservice instance; 5. Wait for the microservice instance to start successfully; 6. Repeat the above steps for the next microservice instance.

[0074] During the execution of operations and maintenance (O&M) tasks, if a newly arrived high-priority O&M task conflicts with the currently executing O&M task, the O&M platform can stop the currently executing O&M task and execute the newly arrived high-priority O&M task. For example, when an integrated business flow is being retried, if a user triggers a flow deletion task, the O&M platform can terminate the flow retry task and execute the flow deletion task to delete the integrated business flow. Taking microservice upgrades as an example, during a microservice instance upgrade, if a user decides to delete the application, the microservice management platform needs to terminate the current upgrade task. Furthermore, for O&M tasks related to transactions, after terminating the O&M task, a task rollback is usually required to ensure state consistency and stability.

[0075] Currently, related technologies input new tasks into a task queue sequentially. As shown in Figure 1, the Task Manager can retrieve new tasks from the Task Queue, such as task 1, and schedule them to worker threads for execution based on task priority. Task 1 can be broken down into multiple sub-tasks, such as sub-task 1-1, sub-task 1-2, sub-task 1-3, sub-task 1-4, and sub-task 1-5. The decomposition and execution of maintenance tasks occur in independent worker threads. Sub-tasks derived from the decomposition of complex maintenance tasks may also run in the same thread or in another thread. In the example in Figure 1, sub-task 1-1, sub-task 1-2, sub-task 1-4, and sub-task 1-5 run in the same thread, such as worker thread 1, while sub-task 1-3 runs in another thread, such as worker thread 2.

[0076] In the above scheme, each operation and maintenance task typically requires an independent thread (e.g., the worker thread in Figure 1) to run. For complex operation and maintenance tasks such as long-running tasks, there will be waiting time during execution, such as waiting for the application to start successfully. During this period, the thread is in a waiting state and cannot be released, resulting in low resource utilization. In addition, each operation and maintenance task needs to run on an independent thread, and the scalability of task scheduling is limited by the maximum number of threads in the application's business system, thus affecting operation and maintenance performance. For complex operation and maintenance tasks such as long-running tasks, the operation and maintenance task and its subtasks are executed independently in threads. It is difficult for the task manager to intervene in running operation and maintenance tasks. Blindly terminating operation and maintenance tasks can lead to system instability. Instability in system state manifests as inconsistent system state. The system state is updated after each operation and maintenance task is completed. When an operation and maintenance task is forcibly terminated during its execution, the system state may not be fully updated. For example, some system modules may stop while others are still running. Therefore, the task manager may not stop the currently running operation and maintenance task because of a newly added high-priority task.

[0077] In view of this, this application provides a task processing method. This method can be executed by an operations and maintenance (O&M) platform. An O&M platform can also be called an O&M system, management O&M platform, resource management O&M platform, resource management platform, or application management platform. The O&M platform can be software, and the software can be independent O&M software. Depending on the application being operated on, the O&M software can be different. For example, O&M software can be an Integration Platform as a Service (iPaaS), a microservice hosting platform, a function hosting platform, or a virtual machine and container management O&M platform. Among these, iPaaS can be an integrated business flow management O&M system, a microservice hosting platform can be a microservice management system, and a function hosting platform can be a function management system. It should be noted that this application can also be applied to management O&M platforms deployed in private clouds and hybrid clouds of data centers. The aforementioned O&M platform can manage and execute O&M tasks on the platform, especially optimizing the processing of complex O&M tasks, thereby improving resource utilization. In some examples, the O&M platform can also be hardware, which can be a cluster of computing devices with O&M capabilities. When the computing device cluster is running, the task processing method of this application is executed.

[0078] Specifically, the operations and maintenance (O&M) platform is used to execute O&M tasks for applications. The O&M platform includes an event queue and a task executor. The task executor includes an execution unit resource pool. An execution unit can be a unit that executes O&M tasks, such as a thread or a process. The execution unit resource pool can be a thread pool or a process pool. The execution unit resource pool can include at least one execution unit.

[0079] The event queue receives at least one operation and maintenance task from the application and adds the corresponding task events to the event queue. Each task event is represented by the task information of the at least one operation and maintenance task. The task executor retrieves the first task event from the event queue, calls the first execution unit in the execution unit resource pool, and executes the first subtask. The first subtask includes subtasks decomposed from the first operation and maintenance task corresponding to the first task event. The task executor distributes the first subtask's resource operations to the resource and releases the first execution unit. Resources include applications or application modules / components. Application components may include, but are not limited to, databases (DB), and application modules may include business flows (flows). The event queue receives the first resource event sent by the resource, which describes the resource's state. Based on the resource's state, the task executor determines the next task or subtask to be processed and executes it.

[0080] This method is event-centric, decomposing complex operational tasks (such as long-running tasks) into subtasks. Operational tasks, subtasks, and resource states are treated as separate events, allowing for finer-grained task decomposition and processing. Specifically, the task executor, upon issuing the first subtask's operation on a resource, can release the corresponding execution unit (e.g., releasing threads) without waiting for the resource operation to complete. This prevents execution units from being blocked by the waiting state of operational tasks, improving resource utilization. A single execution unit can handle task events, subtask events, or resource events, enabling the execution of more tasks / subtasks, improving the scalability of task scheduling and processing, and maximizing the utilization of execution units. Furthermore, this method can dynamically determine the next task or subtask to be executed in real-time based on resource status, enhancing the flexibility and agility of task scheduling. Moreover, when conflicting tasks are added, the currently executing operational task can be terminated or interrupted to handle the newly added conflicting task, ensuring system stability.

[0081] To make the technical solution of this application clearer and easier to understand, the system architecture of the operation and maintenance platform of this application is described below with reference to the accompanying drawings.

[0082] Referring to Figure 2, which shows a schematic diagram of an operation and maintenance platform architecture, the operation and maintenance platform 20 includes an event queue 202 and a task executor 204. Further, the operation and maintenance platform 20 may also include at least one of a task storage module 201 or a task descriptor 203. The operation and maintenance platform 20 interacts with resource 10 to implement resource management. The functions of each module or component in the operation and maintenance platform 20 and the functions of resource 10 are described below.

[0083] The task storage module 201, also known as the task store, is used to store at least one of the following: user-triggered or system-triggered operation and maintenance tasks. User-triggered tasks, often referred to as user tasks, are typically triggered by the user through the console or an application programming interface (API). For example, a user can trigger an operation and maintenance task to create or delete an application through the console. System-triggered tasks, often referred to as system tasks, are typically triggered by the operation and maintenance platform. For example, when an integrated business flow fails, the operation and maintenance platform triggers a flow retry task. It should be noted that the task storage module 201 can store operation and maintenance tasks in the form of a task list. Furthermore, the task storage module 201 also stores the status of operation and maintenance tasks for easy querying by the task executor 204.

[0084] Event queue 202, also known as the event queue, is a message queue used to store at least one of the following: task events or resource events. Event queue 202 is used to generate and consume task events or resource events. Task events have a set priority; for example, user tasks typically have a higher priority than system tasks. Task events can also have a set delay. For example, an application restart maintenance task typically needs to wait 30 seconds before execution.

[0085] Task descriptor 203, also known as the task descriptor, is used to describe operational tasks, including task information (such as task attributes). This task information can include subtasks (sub-tasks) that the operational task is broken down into. It can also include the relationships between operational tasks. For example, relationships between operational tasks can be indicated by a conflicting task field, which can be `Stop_For_Tasks`. `Stop_For_Tasks` describes how, if a new operational task joins while an existing task is running, the current operational task needs to be stopped.

[0086] The task executor 204, also known as the task executor, is used to consume events from the event queue 202 using execution resources in the execution resource pool. These execution resources can be threads or processes. Taking worker threads as an example, the task executor 204 can execute task events or resource events using worker threads from the thread pool. Furthermore, after a task event or a sub-task event of a task event has been completed, the task executor 204 can determine the next task or sub-task based on the task information described in the task descriptor 203 and the list of unprocessed tasks, and add the corresponding task event to the event queue 202 for processing. The task information can include the relationships between tasks, such as dependencies.

[0087] Resource 10, also known as resources, typically refers to resources used for operational tasks. Resource 10 can be an application (APP) or a module or component of an application. The application can be an integrated application or a microservice application. Application components can include, but are not limited to, databases, and application modules can include business flows, such as integrated business flows. Resource 10 receives operations on the resource from operational tasks or subtasks derived from operational tasks. Resource 10 can generate events based on the execution results of these operations. For example, if the application startup is complete, Resource 10 can emit an "Application Started" event. Similarly, if an integrated business flow encounters a database connection error, it can emit a "Database Connection Error" event.

[0088] It should be noted that the aforementioned task storage module 201, event queue 202, task descriptor 203, and task executor 204 can be encapsulated within a task runtime. A runtime can be a virtual machine system that provides software services to a currently executing program; it is typically provided by the operating system or by the parent program executing the program.

[0089] The following section, with reference to Figure 2, details the execution process of the task runtime, including the following steps:

[0090] Step 1: The user or system triggers the operation and maintenance task through the Console or API. The operation and maintenance task enters the task runtime, and the task runtime saves the operation and maintenance task in the task storage module 201 for persistence.

[0091] Operation and maintenance tasks are typically configured with task priorities. In some examples, user tasks (i.e., operation and maintenance tasks triggered by users) have higher task priorities than system tasks. The task runtime persists operation and maintenance tasks as a task list in the task storage module 201 for querying, updating, and deleting the status of operation and maintenance tasks.

[0092] Step 2: The task runtime adds the task events corresponding to the operation and maintenance task to the event queue 202.

[0093] Specifically, the task runtime adds the task information of the operation and maintenance tasks in the task list as task events to the event queue 202.

[0094] Step 3: Task executor 204 consumes task events from the event queue according to priority.

[0095] Step 4: Task executor 204 calls the worker thread to execute the maintenance task corresponding to the task event.

[0096] For ease of description, we will use the task event retrieved from the event queue by task executor 204 as an example of the first task event. The maintenance task corresponding to the first task event is called the first maintenance task (e.g., task 1 in Figure 2). Considering the possibility of duplicate triggering of maintenance tasks, such as user misoperation triggering duplicate maintenance tasks, or different users triggering the same maintenance task for the same application, the worker thread can check if a second maintenance task exists. This second maintenance task is in a running state, and its task type and task object are the same as those of the first maintenance task. The task object can be a resource operated on by the task. For example, the task object can be an application. If a running second maintenance task is detected, it indicates that the same maintenance task is being executed, and the worker thread can discard the first maintenance task. Furthermore, the worker thread can update the status of the first maintenance task to "discarded," for example, by updating the status of the first maintenance task in the task storage module 201. If no second maintenance task is found to be running, the worker thread can execute the first maintenance task based on the task information (metadata).

[0097] Specifically, the worker thread can query the task descriptor 203 to determine whether the first maintenance task supports decomposition. If decomposition is supported, the worker thread can execute the first subtask according to the description of the decomposition method in the task descriptor 203. This first subtask can be a first subtask (e.g., subtask 1-1 in Figure 2). In this method, the first subtask operates on resource 10. After the first subtask is completed, the worker thread updates the status of the first maintenance task to "running" in the task storage module 201. However, the worker thread does not wait for the operation on resource 10 to complete, but releases it after sending the operation to resource 10.

[0098] Step 5: After resource 10 completes the operation of issuing the first subtask, it issues the first resource event, which is then added to the event queue 202.

[0099] Resource events describe resource status updates. For example, a resource event can describe successful application execution, or it can describe application failure. The first resource event is the resource event corresponding to the first subtask.

[0100] Step 6: Task executor 204 consumes the first resource event, determines the next task or the next subtask to be processed based on the status of resource 10 described by the first resource event, and executes the next task or the next subtask.

[0101] Specifically, if the first resource event indicates successful resource execution, then the first subtask has also executed successfully. The task executor 204 can determine through the task descriptor 203 whether there is a next subtask to be executed, and it can also check the task storage module 201 for any conflicting tasks that have not yet been executed. If there is a next subtask to be executed, and there are no unexecuted conflicting tasks, a new subtask, such as a second subtask, can be created and added to the event queue. If no new subtask is created, it indicates that the first maintenance task has been successfully completed, and the Worker Thread can update the status of the first maintenance task to "success" in the task storage module 201.

[0102] If the first resource event indicates resource failure, it also indicates that the first subtask failed (or execution failed). The task executor 204 can check the task descriptor 203 to determine whether to retry. For example, the task executor 204 can obtain the retry count of the first maintenance task, which can be the retry count of the current subtask or the total retry count. When the retry count is less than the maximum retry count, the task executor 204 can generate a retry subtask event and add it to the event queue 202. This retry subtask event is used to retry the first subtask. If the maintenance task does not support retries, or the retry count is greater than or equal to the maximum retry count, it indicates that the first maintenance task has failed. The Worker Thread can update the status of the first maintenance task to "failed" in the task storage module 201.

[0103] The above describes the operational mechanism of tasks in the operations and maintenance platform 20. Task runtimes can be modules or components of the data plane of the operations and maintenance platform 20. As shown in Figure 3, task runtimes can receive operations and maintenance tasks issued by the management plane. These tasks can be user tasks triggered by users through the console user interface (console UI) or management plane API, or system tasks triggered by the system through the management plane API. These operations and maintenance tasks include resource management tasks triggered by users or the system. For example, operations and maintenance tasks may include starting, stopping, or deleting applications, or performing rolling upgrades on container clusters. System tasks can be application restart tasks triggered when the system detects application runtime errors. This maximizes the normal operation of applications and improves system reliability.

[0104] Based on the aforementioned operation and maintenance platform 20, this application provides a task processing method. The task processing method of this application will be described in detail below with reference to the accompanying drawings.

[0105] Referring to the flowchart of a task processing method shown in Figure 4, this method can be applied to the operation and maintenance platform 20 shown in Figure 2. The operation and maintenance platform 20 is used to execute operation and maintenance tasks for applications. The operation and maintenance platform 20 includes an event queue 202 and a task executor 204. The task executor 204 includes an execution unit resource pool, which includes at least one execution unit. In the example of Figure 2, the execution unit resource pool can be a thread pool, which can include at least one thread. The thread can be a worker thread. The method includes the following steps:

[0106] S402, Event queue 202 receives at least one operation and maintenance task from the application and adds the task events corresponding to at least one operation and maintenance task to event queue 202.

[0107] Operation and maintenance tasks are used to perform operations and maintenance on applications. Operation and maintenance tasks can be categorized into user tasks and system tasks, based on whether they are triggered by users or the system. User tasks are triggered by users through the console or via API, while system tasks can be triggered via API. Specifically, the operation and maintenance platform 20 can provide a console UI or a management API, through which users can trigger operation and maintenance tasks; these are user tasks. Alternatively, the operation and maintenance platform 20 can trigger operation and maintenance tasks via the management API; these are system tasks.

[0108] Task information can be metadata for operations and maintenance tasks, used to describe the attributes of the tasks. In some possible implementations, task information can be represented by a task model. A task model includes one or more of the following: task identifier (task_ID), task type (task_type), originator, resource identifier (resource_ID), task priority, delay, or task status (task_status).

[0109] Among them, `task_ID` is the unique identifier of the operation and maintenance task, and its attribute type is string. `task_type` describes the purpose and operation of the operation and maintenance task, and its attribute type is string. `Originator` describes the creator that triggered the operation and maintenance task, such as user or system. `resource_ID` describes the resource operated on by the operation and maintenance task, and its attribute type is string. `priority` describes the task priority of the operation and maintenance task; higher priority operation and maintenance tasks are executed first. User tasks usually have higher priority than system tasks. The attribute type of `priority` is integer (integer, int). `delay` describes the latency before the operation and maintenance task is executed, usually in seconds. The attribute type of `delay` is integer. `task_status` describes the status of the operation and maintenance task, and its attribute type is string. See below for details:

[0110] Table 1 Task Model

[0111] For ease of understanding, this application provides an example of a user task and an example of a system task, as shown below:

[0112] 1.User Task:Start Integration Flow

[0113] Among them, the user task can be to start the integrated business flow. The task_ID of this operation and maintenance task is t1233, the task_type is flow_start_task, the originator of the operation and maintenance task is user, the resource_ID is flow123, the priority is 1, the delay is 0, and the task_status is created (indicating creation).

[0114] 2.System Task:Retry Integration Flow when it is running failed.

[0115] Among them, the system task can be a business flow retry, denoted as the task_ID of this operation and maintenance task is t458, the task_type is flow_retry_task, the originator of the operation and maintenance task is system, the resource_ID is flow789, the priority is 2, the delay is 15, and the task_status is created.

[0116] At least one operation and maintenance (O&M) task corresponds to a task event, which is represented by the task information of at least one O&M task. Specifically, the O&M platform 20 also includes a task storage module 201, which stores the task information of at least one O&M task. At least one O&M task can be persisted in the task storage module 201. Specifically, at least one O&M task can be stored in the task storage module 201 as a task list. The event queue 202 can retrieve at least one O&M task from the task storage module 201. For example, the event queue 202 can receive at least one O&M task sent by the task storage module 201, generate task events corresponding to the O&M task based on the at least one O&M task, and add the task events corresponding to the O&M task to the event queue. The event queue is a linear data structure following a trapped first-out (FIFO) rule. Based on this, the event queue 202 can add the task events of the O&M task sequentially according to the task priority of the O&M task.

[0117] The task events in the event queue carry the task priority or delay of the operation and maintenance task. Task events with higher priority are consumed first, while events carrying a delay (or a delay greater than 0) can wait until the delay ends before being consumed. The event queue 202 can include multiple partitions, each with different priorities. For example, referring to Figure 5, which shows a schematic diagram of an event queue structure, event queue 202 can include partitions P1 and P2. Partition P1 includes task events for user tasks, and partition P2 includes task events for system tasks. In this example, partition P1 includes user task event 1, user sub-task events 1-2, and user task event 2; partition P2 includes system task event 1, system sub-task events 1-2, and system task event 2. The priority of task events (including operation and maintenance task or sub-task task events) in partition P1 is higher than the priority of task events in partition P2.

[0118] Furthermore, for task events carrying a delay or with a delay greater than 0, the corresponding partition can be added after the delay ends. In the example in Figure 5, the delay of user task event 3 is 15 seconds, and the P1 partition can be added after 15 seconds.

[0119] S404, Task executor 204 retrieves the first task event from event queue 202.

[0120] Task executor 204 can retrieve the first task event from event queue 202 according to priority based on a queue consumption mechanism. For example, task executor 204 can first retrieve the first task event from the user task event partition (partition P1 in Figure 5) of event queue 202. This first task event can be the task event at the head of the user task event partition. As illustrated in Figure 5, task executor 204 can retrieve user task event 1 from partition P1 of event queue 202 for consumption.

[0121] S406, Task executor 204 calls the first execution unit in the execution unit resource pool to execute the first subtask.

[0122] The first subtask includes the subtasks decomposed from the first maintenance task corresponding to the first task event. Specifically, the task descriptor 203 defines the decomposition information for maintenance tasks of different task types. This task decomposition information indicates whether to decompose the maintenance task or the decomposition method, where the decomposition method can be represented by the subtasks of the maintenance task. The task executor 204 can query the task descriptor 203 to obtain the task decomposition information of the first maintenance task. The task decomposition information may include multiple subtasks decomposed from the first maintenance task. The first subtask may be the highest-priority subtask among these subtasks, for example, the highest-priority subtask among the subtasks to be executed.

[0123] For example, the first maintenance task is a flow retry task, denoted as flow_retry_task. The task executor 204 queries the task descriptor of flow_retry_task and finds that the maintenance task includes the following subtasks: 1. Stop the business flow, denoted as flow_stop_task; 2. Start the business flow, denoted as flow_start_task.

[0124] The execution unit resource pool can be a resource pool formed by execution units. An execution unit can be a thread or a process. The first execution unit can be a thread in an idle state within the execution unit resource pool. For ease of description, using the execution unit resource pool as an example of a thread pool, the task executor 204 can call an idle worker thread from the thread pool to execute the first subtask.

[0125] Considering the possibility of duplicate triggering of maintenance tasks, task executor 204 can also check if there is a maintenance task that is identical to the first maintenance task and has a "running" status. The identical maintenance tasks can be of the same task type and have the same task object. The task object can be the resource that the task processes or operates on.

[0126] The task executor 204 can check whether a second maintenance task exists. The second maintenance task is in a running state, and its task type and object are the same as the first maintenance task. The task object can be a resource operated on by the task. For example, the task object can be an application, and the first and second maintenance tasks can be the same type of maintenance tasks for the same application.

[0127] If a second maintenance task is detected as "running," it indicates that the same maintenance task is being executed, and task executor 204 can discard the first maintenance task. Specifically, task executor 204 can discard the first maintenance task through a worker thread. Furthermore, task executor 204 can update the status of the first maintenance task to "discarded," for example, by updating the status of the first maintenance task in task storage module 201. If no second maintenance task is detected as "running," task executor 204 can invoke the first execution unit (e.g., a worker thread) in the execution unit resource pool to execute the first maintenance task. When executing the first maintenance task, the worker thread can determine the first subtask decomposed from the first maintenance task based on the task information (metadata) of the first maintenance task and execute that first subtask.

[0128] The execution of the first subtask by the work thread can be based on the task logic of the first subtask. The task logic of the first subtask includes generating the operation of the first subtask on resource 10. The operation on resource 10 may include, but is not limited to, starting, stopping, and deleting. It should be noted that the task logic of the first subtask may also include verification, authentication, etc., which are not limited in this application.

[0129] S408, Task executor 204 sends the operation of the first subtask on resource 10 to resource 10 and releases the first execution unit.

[0130] Resource 10 includes an application or its modules and components. Application components can be databases, and application modules can be business flows, such as integration business flows. Task executor 204 can use a first execution unit, such as a Worker Thread, to send the first subtask's operation on resource 10 to resource 10, and then release the first execution unit. In this method, the first execution unit (e.g.) does not need to wait for resource 10 to complete its operation; instead, it terminates directly after sending the operation to resource 10.

[0131] To facilitate understanding, the execution process of the maintenance task is explained in detail below with reference to the accompanying drawings. Referring to Figure 6, which illustrates the execution process of a maintenance task, the task executor 204 can retrieve the first task event corresponding to the first maintenance task from the event queue. Then, it calls the worker thread to check if a second maintenance task is running in the task storage module 201. The second maintenance task is in the "running" state, and its task type and object are the same as the first maintenance task. A "running" status indicates that the maintenance task is being processed; it may be waiting for information from resource 10 or has subtasks queued in the event queue 202. Therefore, if the check result is yes, it means that a maintenance task identical to the first maintenance task is being processed, and the worker thread can discard the first maintenance task. In other words, the worker thread can choose not to execute the first maintenance task. Furthermore, the worker thread can also update the status of the first maintenance task to "discarded" in the task storage module 201. If the check result is negative, the worker thread can execute the first maintenance task. If the first maintenance task is a long or complex task, the worker thread can execute the first subtask decomposed from the first maintenance task. Then, the worker thread can issue the operation of the first maintenance task or the first subtask to resource 10, and terminate immediately after issuing the operation.

[0132] S410, Event queue 202 receives the first resource event sent by resource 10.

[0133] Specifically, when resource 10 completes its first subtask, it can emit a resource event corresponding to the first subtask, i.e., the first resource event. The first resource event describes the state of resource 10. For example, the first resource event could be "application ran successfully" or "application ran failed." The first resource event can be added to event queue 202 so that task executor 204 can consume it.

[0134] The first resource event can be generated based on a resource event model. The resource event model can include one or more of the following: resource ID, task ID, priority, resource status, and resource message. The resource ID can be a unique identifier for resource 10, and the task ID can be the corresponding task operating on resource 10. The priority can be the priority of the resource event, which can be higher than the priority of the task event. As illustrated in Figure 5, the event queue 202 also includes resource event partitions, such as partition P0. Partition P0 contains resource events and has the highest priority. Resource events in partition P0 are first consumed and processed by task executor 204, followed by user task events in partition P1, and then system task events in partition P2. The resource status can be the status of resource 10. The resource message is the message information returned by resource 10. The attributes included in the resource event model are as follows:

[0135] Table 2 Model of Resource Events

[0136] The first resource event can be obtained by assigning a value to an attribute in the resource event model. This application also provides an example of a first resource event. In this example, resource 10 can be an application that emits the following first resource event upon successful startup:

[0137] S412, Task executor 204 determines the next task or the next subtask to be processed based on the status of the resources.

[0138] The status of a resource can be either success or failure. When a resource is in a success or failure state, the next task or subtask to be processed can differ. The task processing flow when a resource is in a success or failure state is described in detail below.

[0139] In some possible implementations, when the status of resource 10 is successful, task executor 204 checks whether the first maintenance task corresponding to the first task event includes a pending subtask. If so, task executor 204 generates a subtask event and adds it to event queue 202. The subtask event is used to indicate the second subtask for executing the first maintenance task. Task executor 204 can retrieve the subtask event from event queue 202, call the second execution unit in the execution unit resource pool, execute the second subtask, distribute the operation of the second subtask on resource 10 to resource 10, and release the second execution unit.

[0140] The second execution unit is an execution unit that is idle in the execution unit resource pool. Since the first execution unit has been released, the second execution unit can be the same execution unit as the first execution unit, or it can be a different execution unit.

[0141] It should be noted that, considering that higher-priority maintenance tasks may be running before the second subtask is executed, the task executor 204 can check for any conflicting tasks based on the task information of the first maintenance task. For example, the task executor 204 can check the task storage module 201 for any conflicting tasks of the first maintenance task through a worker thread. The conflicting task of the first maintenance task can be a maintenance task defined in the task information of the first maintenance task that causes the first maintenance task to stop.

[0142] When task executor 204 detects the arrival of a conflicting task, it can determine the task operation for the first maintenance task to which the second subtask belongs, based on the task information of the second subtask. The task operation includes stopping or rolling back. For example, if the first maintenance task is related to a transaction, the task operation can be rollback; if the first maintenance task is not related to a transaction, the task operation can be stopping. Furthermore, after stopping the first maintenance task, task executor 204 can update the status of the first maintenance task to stopped. If task executor 204 does not detect the arrival of a conflicting task, it can generate a subtask event and add the subtask event to the event queue.

[0143] In some possible implementations, when resource 10 is in a failed state, task executor 204 can determine whether to retry. Specifically, task executor 204 can check the task descriptor to determine whether to retry. Specifically, task executor 204 can obtain the maximum number of retries from the task descriptor for that task type. The task executor can obtain the number of retries for the first maintenance task and compare it with the maximum number of retries to determine whether to retry. When the number of retries is less than the maximum number of retries, task executor 204 can generate a retry subtask event and add it to the event queue. The retry subtask event is used to retry the first subtask. When the number of retries is greater than or equal to the maximum number of retries, or the maximum number of retries is 0, task executor 204 can update the status of the first maintenance task to "failed".

[0144] To facilitate understanding, examples are provided below with reference to the accompanying drawings.

[0145] Referring to Figure 7, which illustrates a flowchart for determining the next task or subtask to be processed based on the status of a resource, in this example, the task executor 204 retrieves the first resource event from the event queue 202 and then calls the worker thread to determine the next task or subtask to be processed. The worker thread can check whether the status of resource 10 described by the first resource event is successful.

[0146] If the check result for the status of resource 10 is yes, the worker thread can check the task descriptor to obtain the next subtask, such as the second subtask. Further, the worker thread can check the task storage module 201 to determine if any conflicting tasks have arrived. For example, the worker thread can check the maintenance tasks in the task storage module 201 with a status of "created." If a maintenance task with a status of "created" is found in `stop_for_tasks`, it indicates that a conflicting task has arrived. The worker thread can update the status of the first maintenance task to "stopped" in the task storage module 201. If no conflicting tasks are found, the worker thread can create a subtask event and add the subtask event to the event queue 202.

[0147] If the check of the status of resource 10 is negative, the worker thread can check the task descriptor to determine whether to retry. The task descriptor defines a maximum number of retries. If the number of retries for the first maintenance task is less than the maximum number of retries, a retry is determined, and the worker thread can create a retry subtask event and add it to event queue 202. If the number of retries for the first maintenance task is greater than or equal to the maximum number of retries, or the maximum number of retries is 0, a retry is determined, and the worker thread can update the status of the first maintenance task to failed.

[0148] The task descriptor model can include one or more attributes such as task type (task_type), subtasks (sub_tasks), conflicting tasks (stop_for_tasks), rollback tasks (rollback_for_tasks), rollback subtasks (rollback_sub_tasks), maximum repeat count (repeat_time), and repeat interval (repeat_interval). Specifically, task_type describes the purpose and operation of the maintenance task; sub_tasks describes the subtasks decomposed from the maintenance task; stop_for_tasks describes the maintenance tasks that cause the current maintenance task to stop; and rollback_for_tasks refers to the maintenance tasks that cause the current maintenance task to roll back. For example, if the first maintenance task is running and the maintenance tasks defined in rollback_for_tasks are in the event queue, it means that the first maintenance task needs to be stopped, and the subtasks defined in rollback_sub_tasks need to be executed to roll back the first maintenance task. rollback_sub_tasks refers to the subtasks that need to be executed to roll back the maintenance task. If `repeat_time` is greater than 0, it means that if the operation and maintenance task fails, it can be retried. `repeat_interval` describes the delay to wait before retrying, usually in seconds. The attributes included in the task descriptor model are as follows:

[0149] Table 3. Task Descriptor Model

[0150] To facilitate understanding, this application also provides an example of a task descriptor. The example of `flow_retry_task` is illustrated below:

[0151] S414, Task executor 204 executes the next task or the next subtask.

[0152] When executing the next task or the next subtask, the task executor 204 may refer to the aforementioned steps, and this application does not impose any restrictions on this.

[0153] Task executor 204 can update the status of the first maintenance task based on its execution status or that of its subtasks. The status of the first maintenance task includes creation, abandonment, running, stopped, success, or failure. By updating the status of the first maintenance task, task executor 204 can determine the next task or subtask to be processed when executing other maintenance tasks.

[0154] Based on the above, this application provides a task processing method. This method is event-centric, decomposing complex operation and maintenance tasks (such as long tasks) into subtasks. Operation and maintenance tasks, subtasks, and resource states are all treated as separate events, thus enabling task decomposition and processing at a finer granularity. Specifically, the task executor, upon issuing the first subtask's operation to the resource, can release the corresponding execution unit (e.g., releasing threads) without waiting for the resource operation to complete. This prevents the execution unit from being blocked by the waiting state of the operation and improves resource utilization. The same execution unit can handle more subtasks, improving the scalability of task scheduling and processing, and maximizing the utilization of the execution unit. Furthermore, this method can dynamically determine the next task or subtask to be executed in real time based on the resource state, improving the flexibility and agility of task scheduling. Moreover, when conflicting tasks are added, the currently executing operation and maintenance task can be terminated or interrupted to handle the newly added conflicting task, ensuring the stability of the system state.

[0155] Based on the aforementioned task processing method, this application also provides an operation and maintenance platform 20. The operation and maintenance platform 20 is used to execute operation and maintenance tasks for applications. The operation and maintenance platform 20 includes an event queue 202 and a task executor 204. The task executor 204 includes an execution unit resource pool, and the execution unit resource pool includes at least one execution unit.

[0156] The event queue 202 is used to receive at least one operation and maintenance task of the application, add the task events corresponding to the at least one operation and maintenance task to the event queue, and the task events corresponding to the at least one operation and maintenance task are represented by the task information of the at least one operation and maintenance task.

[0157] The task executor 204 is used to retrieve a first task event from the event queue, call a first execution unit in the execution unit resource pool, execute a first subtask, the first subtask including a subtask decomposed from the first operation and maintenance task corresponding to the first task event, distribute the operation of the first subtask on the resource to the resource, and release the first execution unit, the resource including the application or the application's modules and components;

[0158] The event queue 202 is also used to receive a first resource event sent by the resource, wherein the first resource event describes the state of the resource;

[0159] The task executor 204 is further configured to determine the next task or the next subtask to be processed based on the state of the resource, and execute the next task or the next subtask.

[0160] For example, the event queue 202 and task executor 204 described above can be implemented in hardware or in software.

[0161] When implemented in software, event queue 202 and task executor 204 can be applications running on computing devices, such as computing engines. These applications can also be virtualized and provided to users as virtualization services. Virtualization services can include virtual machine (VM) services, bare metal server (BMS) services, or container services. VM services can be services that use virtualization technology to create virtual machine (VM) resource pools on multiple physical hosts to provide VMs for users to use on demand. BMS services are services that use virtualization technology to create BMS resource pools on multiple physical hosts to provide BMS for users to use on demand. Container services are services that use virtualization technology to create container resource pools on multiple physical hosts to provide containers for users to use on demand. A VM is a simulated virtual computer, that is, a logical computer. A BMS is a scalable, high-performance computing service with computing performance indistinguishable from traditional physical machines and features secure physical isolation. A container is a kernel virtualization technology that can provide lightweight virtualization to isolate user space, processes, and resources. It should be understood that the VM service, BMS service, and container service mentioned above are merely specific examples. In practical applications, virtualization services can also include other lightweight or heavyweight virtualization services, which are not specifically limited here.

[0162] When implemented in hardware, the event queue 202 and task executor 204 may include at least one computing device, such as a server. Alternatively, the event queue 202 and task executor 204 may also be devices implemented using application-specific integrated circuits (ASICs) or programmable logic devices (PLDs). The PLD can be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0163] In some possible implementations, the task executor 204 is specifically used for:

[0164] When the status of the resource is successful, check whether the first maintenance task corresponding to the first task event includes the next sub-task to be processed.

[0165] If so, generate a subtask event and add the subtask event to the event queue. The subtask event is used to indicate the execution of the second subtask of the first operation and maintenance task.

[0166] The subtask event is retrieved from the event queue, the second execution unit in the execution unit resource pool is invoked to execute the second subtask, the operation of the second subtask on the resource is sent to the resource, and the second execution unit is released.

[0167] In some possible implementations, the task executor 204 is further configured to:

[0168] Based on the task information of the first maintenance task, check if any conflicting tasks have arrived;

[0169] The task executor 204 is specifically used for:

[0170] If no conflicting task is detected, a subtask event is generated and added to the event queue.

[0171] In some possible implementations, the operations and maintenance platform 20 also includes a task descriptor 203. The task descriptor 203 defines conflicting tasks for operations and maintenance tasks of at least one task type. Based on this, the task executor 204 queries the task descriptor 203 according to the task information of the first operations and maintenance task to check if any conflicting tasks have arrived.

[0172] Similar to event queue 202 and task executor 204, task descriptor 203 can be implemented in hardware or software. When implemented in software, task descriptor 203 can be an application running on a computing device. This application can also be virtualized and provided to users as virtualization services such as VM services, BMS services, or container services. When implemented in hardware, task descriptor 203 can include at least one computing device, such as a server. Alternatively, task descriptor 203 can also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD).

[0173] In some possible implementations, the task executor 204 is further configured to:

[0174] Upon detecting the arrival of the conflicting task, based on the task information of the second subtask, determine the task operation for the first maintenance task to which the second subtask belongs. The task operation includes stopping or rolling back.

[0175] In some possible implementations, the task executor 204 is specifically used for:

[0176] When the resource status is failure, the number of retries for the first operation and maintenance task is obtained. When the number of retries is less than the maximum number of retries, a retry subtask event is generated and added to the event queue. The retry subtask event is used to retrieve the first subtask.

[0177] In some possible implementations, the task executor 204 is further configured to:

[0178] Update the status of the first operation and maintenance task based on the execution status of the first operation and maintenance task or its sub-tasks. The status of the first operation and maintenance task includes creation, abandonment, running, stopped, success, or failure.

[0179] In some possible implementations, the task executor 204 is specifically used for:

[0180] Take the first task event from the event queue, check whether the event queue includes the second task event, the status of the second operation and maintenance task corresponding to the second task event is running, and the task type of the second operation and maintenance task is the same as the task type of the first operation and maintenance task, and the task object of the second operation and maintenance task is the same as the task object of the first operation and maintenance task.

[0181] If not, invoke the first execution unit in the execution unit resource pool to execute the first subtask.

[0182] In some possible implementations, the task executor 204 is further configured to:

[0183] If so, abandon the first maintenance task.

[0184] In some possible implementations, the operation and maintenance platform further includes a task storage module 201, which is used to store task information of the at least one operation and maintenance task;

[0185] The event queue 202 is specifically used for:

[0186] Receive at least one maintenance task sent by the task storage module.

[0187] Similar to event queue 202 and task executor 204, task storage module 201 can be implemented in hardware or software. When implemented in software, task storage module 201 can be an application running on a computing device. This application can also be virtualized and provided to users as virtualization services such as VM services, BMS services, or container services. When implemented in hardware, task storage module 201 can include at least one computing device, such as a server. This server can be a storage server. Alternatively, task storage module 201 can also be a device implemented using an Application-Specific Integrated Circuit (ASIC) or a Programmable Logic Device (PLD).

[0188] In some possible implementations, the operation and maintenance tasks include user tasks or system tasks, wherein the user tasks are triggered by the user through a console or through an application programming interface.

[0189] This application also provides a computing device 800. As shown in FIG8, the computing device 800 includes: a bus 802, a processor 804, a memory 806, and a communication interface 808. The processor 804, the memory 806, and the communication interface 808 communicate with each other via the bus 802. The computing device 800 may be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 800.

[0190] Bus 802 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 8, but this does not imply that there is only one bus or one type of bus. Bus 802 can include pathways for transmitting information between various components of computing device 800 (e.g., memory 806, processor 804, communication interface 808).

[0191] Processor 804 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0192] The memory 806 may include volatile memory, such as random access memory (RAM). The memory 806 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD). The memory 806 stores executable program code, which the processor 804 executes to implement the aforementioned task processing method. Specifically, the memory 806 stores instructions for the operation and maintenance platform 20 to execute the task processing method. For example, the memory 806 may store instructions for the event queue 202 and the task executor 204 to execute the task processing method. Furthermore, the memory 806 may also store instructions for the task storage module 201 and the task descriptor 203 to execute the task processing method.

[0193] The communication interface 808 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 800 and other devices or communication networks.

[0194] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0195] As shown in Figure 9, the computing device cluster includes at least one computing device 800. The memory 806 of one or more computing devices 800 in the computing device cluster may store instructions from the same operation and maintenance platform 20 for executing task processing methods.

[0196] In some possible implementations, one or more computing devices 800 in the computing device cluster can also be used to execute some of the instructions used by the operation and maintenance platform 20 to execute task processing methods. In other words, a combination of one or more computing devices 800 can jointly execute the instructions used by the operation and maintenance platform 20 to execute task processing methods.

[0197] It should be noted that the memory 806 in different computing devices 800 in the computing device cluster can store different instructions for executing some functions of the operation and maintenance platform 20.

[0198] Figure 10 illustrates one possible implementation. As shown in Figure 10, two computing devices 800A and 800B are connected via a communication interface 808. The memory in computing device 800A stores instructions for executing the functions of event queue 202. The memory in computing device 800B stores instructions for executing the functions of task executor 204. Furthermore, the memory in computing device 800A can also store instructions for executing the functions of task storage module 201, and the memory in computing device 800B can also store instructions for executing the functions of task descriptor 203. In other words, the memory 806 of computing devices 800A and 800B jointly stores the instructions used by the operation and maintenance platform 20 to execute task processing methods.

[0199] The connection method between the computing device clusters shown in Figure 10 can be considered because the task processing method provided in this application requires a lot of resources for task decomposition and execution. Therefore, it is considered to dedicate the functions implemented by the event queue 202 and the task executor 204 to different computing devices. For example, the functions implemented by the event queue 202 are dedicated to computing device 800A, and the functions implemented by the task executor 204 are dedicated to computing device 800B.

[0200] It should be understood that the functions of computing device 800A shown in Figure 10 can also be performed by multiple computing devices 800. Similarly, the functions of computing device 800B can also be performed by multiple computing devices 800.

[0201] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 11 illustrates one possible implementation. As shown in Figure 11, two computing devices 800C and 800D are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this type of possible implementation, the memory 806 in computing device 800C stores instructions for executing the function of event queue 202. Simultaneously, the memory 806 in computing device 800D stores instructions for executing the function of task executor 204. Further, the memory in computing device 800C can also store instructions for executing the function of task storage module 201, and the memory in computing device 800D can also store instructions for executing the function of task descriptor 203.

[0202] The connection method between the computing device clusters shown in Figure 11 can be based on the fact that the task processing method provided in this application requires a lot of resources for task decomposition and execution. Therefore, it is considered to delegate the functions implemented by the task executor to computing devices independent of the event queue 202. For example, the functions implemented by the event queue 202 are delegated to computing device 800C, and the functions implemented by the task executor 204 are delegated to computing device 800D.

[0203] It should be understood that the functions of the computing device 800C shown in Figure 11 can also be performed by multiple computing devices 800. Similarly, the functions of the computing device 800D can also be performed by multiple computing devices 800.

[0204] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the task processing method described above for use in the operation and maintenance platform 20.

[0205] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to perform the above-described task processing method.

[0206] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A task processing method, characterized in that, The method is applied to an operations and maintenance platform for executing operations and maintenance tasks for applications. The platform includes an event queue and a task executor. The task executor includes an execution unit resource pool, which includes at least one execution unit. The event queue receives at least one operation and maintenance task of the application, adds the task events corresponding to the at least one operation and maintenance task to the event queue, and the task events corresponding to the at least one operation and maintenance task are represented by the task information of the at least one operation and maintenance task. The task executor retrieves a first task event from the event queue, calls a first execution unit in the execution unit resource pool, executes a first subtask, the first subtask includes a subtask decomposed from the first operation and maintenance task corresponding to the first task event, distributes the operation of the first subtask on the resource to the resource, and releases the first execution unit, the resource includes the application or the application's modules and components; The event queue receives a first resource event sent by the resource, the first resource event describing the state of the resource; The task executor determines the next task or subtask to be processed based on the state of the resource, and executes the next task or subtask.

2. The method according to claim 1, characterized in that, The task executor determines the next task or subtask to be processed based on the state of the resources, and executes the next task or subtask, including: When the status of the resource is successful, the task executor checks whether the first maintenance task corresponding to the first task event includes a next subtask to be processed. If so, the task executor generates a subtask event and adds the subtask event to the event queue. The subtask event is used to indicate the execution of a second subtask of the first maintenance task. The task executor retrieves the subtask event from the event queue, calls the second execution unit in the execution unit resource pool to execute the second subtask, sends the operation of the second subtask on the resource to the resource, and releases the second execution unit.

3. The method according to claim 2, characterized in that, The method further includes: The task executor checks whether any conflicting tasks have arrived based on the task information of the first maintenance task; The task executor generates subtask events and adds the subtask events to the event queue, including: If the task executor does not detect the arrival of the conflicting task, it generates a sub-task event and adds the sub-task event to the event queue.

4. The method according to claim 3, characterized in that, The method further includes: The task executor detects the arrival of the conflicting task and, based on the task information of the second subtask, determines the task operation for the first maintenance task to which the second subtask belongs. The task operation includes stopping or rolling back.

5. The method according to claim 1, characterized in that, The task executor determines the next task or subtask to be processed based on the state of the resources, including: When the resource is in a failed state, the task executor obtains the number of retries for the first maintenance task. If the number of retries is less than the maximum number of retries, a retry subtask event is generated and added to the event queue. The retry subtask event is used to retry the first subtask.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: The task executor updates the status of the first maintenance task based on the execution status of the first maintenance task or its subtasks. The status of the first maintenance task includes creation, abandonment, running, stopped, success, or failure.

7. The method according to any one of claims 1 to 6, characterized in that, The task executor retrieves a first task event from the event queue, invokes a first execution unit from the execution unit resource pool, and executes a first subtask, including: The task executor retrieves the first task event from the event queue, checks whether the event queue includes the second task event, the status of the second operation and maintenance task corresponding to the second task event is running, and the task type of the second operation and maintenance task is the same as the task type of the first operation and maintenance task, and the task object of the second operation and maintenance task is the same as the task object of the first operation and maintenance task. If not, the task executor calls the first execution unit in the execution unit resource pool to execute the first subtask.

8. The method according to claim 7, characterized in that, The method further includes: If so, the task executor discards the first maintenance task.

9. The method according to any one of claims 1 to 8, characterized in that, The operation and maintenance platform also includes a task storage module, which is used to store the task information of the at least one operation and maintenance task. The event queue receives at least one operational task from the application, including: The event queue receives at least one maintenance task sent by the task storage module.

10. The method according to claim 9, characterized in that, The operation and maintenance tasks include user tasks or system tasks. The user tasks are triggered by the user through the console or through the application programming interface.

11. An operation and maintenance platform, characterized in that, The operation and maintenance platform is used to execute operation and maintenance tasks for applications. The operation and maintenance platform includes an event queue and a task executor. The task executor includes an execution unit resource pool, and the execution unit resource pool includes at least one execution unit. The event queue is used to receive at least one operation and maintenance task of the application, add the task events corresponding to the at least one operation and maintenance task to the event queue, and the task events corresponding to the at least one operation and maintenance task are represented by the task information of the at least one operation and maintenance task. The task executor is used to retrieve a first task event from the event queue, call a first execution unit in the execution unit resource pool, execute a first subtask, the first subtask including a subtask decomposed from the first operation and maintenance task corresponding to the first task event, distribute the operation of the first subtask on the resource to the resource, and release the first execution unit, the resource including the application or the application's modules and components; The event queue is also used to receive a first resource event sent by the resource, the first resource event describing the state of the resource; The task executor is further configured to determine the next task or the next subtask to be processed based on the state of the resource, and execute the next task or the next subtask.

12. The operation and maintenance platform according to claim 11, characterized in that, The task executor is specifically used for: When the status of the resource is successful, check whether the first maintenance task corresponding to the first task event includes the next sub-task to be processed. If so, generate a subtask event and add the subtask event to the event queue. The subtask event is used to indicate the execution of the second subtask of the first maintenance task. The subtask event is retrieved from the event queue, the second execution unit in the execution unit resource pool is invoked to execute the second subtask, the operation of the second subtask on the resource is sent to the resource, and the second execution unit is released.

13. The operation and maintenance platform according to claim 12, characterized in that, The task executor is also used for: Based on the task information of the first maintenance task, check if any conflicting tasks have arrived; The task executor is specifically used for: If no conflicting task is detected, a subtask event is generated and added to the event queue.

14. The operation and maintenance platform according to claim 13, characterized in that, The task executor is also used for: Upon detecting the arrival of the conflicting task, based on the task information of the second subtask, determine the task operation for the first maintenance task to which the second subtask belongs. The task operation includes stopping or rolling back.

15. The operation and maintenance platform according to claim 11, characterized in that, The task executor is specifically used for: When the resource status is failure, the number of retries for the first operation and maintenance task is obtained. When the number of retries is less than the maximum number of retries, a retry subtask event is generated and added to the event queue. The retry subtask event is used to retrieve the first subtask.

16. The operation and maintenance platform according to any one of claims 11 to 15, characterized in that, The task executor is also used for: Update the status of the first operation and maintenance task based on the execution status of the first operation and maintenance task or its sub-tasks. The status of the first operation and maintenance task includes creation, abandonment, running, stopped, success, or failure.

17. The operation and maintenance platform according to any one of claims 11 to 16, characterized in that, The task executor is specifically used for: Take the first task event from the event queue, check whether the event queue includes the second task event, the status of the second operation and maintenance task corresponding to the second task event is running, and the task type of the second operation and maintenance task is the same as the task type of the first operation and maintenance task, and the task object of the second operation and maintenance task is the same as the task object of the first operation and maintenance task. If not, invoke the first execution unit in the execution unit resource pool to execute the first subtask.

18. The operation and maintenance platform according to claim 17, characterized in that, The task executor is also used for: If so, abandon the first maintenance task.

19. The operation and maintenance platform according to any one of claims 11 to 18, characterized in that, The operation and maintenance platform also includes a task storage module, which is used to store the task information of the at least one operation and maintenance task. The event queue is specifically used for: Receive at least one maintenance task sent by the task storage module.

20. The operation and maintenance platform according to claim 19, characterized in that, The operation and maintenance tasks include user tasks or system tasks. The user tasks are triggered by the user through the console or through the application programming interface.

21. A computing device cluster, characterized in that, The computing device cluster includes at least one computing device, the at least one computing device including at least one processor and at least one memory, the at least one memory storing computer-readable instructions; the at least one processor executes the computer-readable instructions to cause the computing device cluster to perform the task processing method as described in any one of claims 1 to 10.

22. A computer-readable storage medium, characterized in that, Includes computer-readable instructions; the computer-readable instructions are used to implement the task processing method according to any one of claims 1 to 10.

23. A computer program product, characterized in that, Includes computer-readable instructions; the computer-readable instructions are used to implement the task processing method according to any one of claims 1 to 10.

Images