A method, device and storage medium for processing a timing task

Abstract

Embodiments of the present application provide a processing method, device and storage medium for a timing task. An agent service can be started before a timing task framework is started, so that the timing task framework can be disabled in a user-unaware manner by using the agent service; on this basis, a job controller in kubernetes can be called to create a container group for each timing task, and the container group can be used to carry the timing task and the agent service. In this way, the timing task can be managed by the job controller instead of the timing task framework; the agent service can be used to replace the timing task framework to perform related processing on the timing task and perceive the execution state of the timing task, and the container group occupied by the timing task can be released after the agent service perceives that the timing task is executed, so that the timing task is stopped after being completed. Accordingly, the serverless of the timing task framework can be implemented without modifying the timing task framework, and the resource occupation problem of the timing task can be improved.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a method, device and storage medium for processing timed tasks. Background Technology

[0002] The processing of scheduled tasks usually relies on a scheduled task framework. However, the scheduled task framework is a persistent class model, which means that it will always occupy computing resources regardless of whether the scheduled task is executed or not.

[0003] Currently, the industry has proposed a serverless transformation of scheduled task frameworks to optimize resource consumption. However, this requires decomposing the task logic within the framework and rewriting it. Often, a single scheduled task framework contains dozens or even hundreds of task entities, making the decomposition process extremely complex. This intrusive approach to modifying the scheduled task framework has a high learning curve and complexity, resulting in low user willingness to address the resource consumption issue. Summary of the Invention

[0004] This application provides a method, apparatus, and storage medium for processing scheduled tasks, thereby improving the resource consumption problem of scheduled tasks.

[0005] This application provides a method for processing timed tasks, including:

[0006] When the target scheduled task meets the startup conditions, the task job controller in Kubernetes is invoked to create a container group (pod) for the target scheduled task.

[0007] Before the scheduled task framework that the target scheduled task originally depends on starts, start the agent service on the container group pod to disable the scheduled task framework.

[0008] Execute the target scheduled task in the container group (pod);

[0009] Once the proxy service detects that the target scheduled task has been completed, it releases the container group (pod) occupied by the target scheduled task.

[0010] This application also provides a computing device, including a memory and a processor;

[0011] The memory is used to store one or more computer instructions;

[0012] The processor is coupled to the memory and is used to execute the one or more computer instructions for:

[0013] When the target scheduled task meets the startup conditions, the task job controller in Kubernetes is invoked to create a container group (pod) for the target scheduled task.

[0014] Before the scheduled task framework that the target scheduled task originally depends on starts, start the agent service on the container group pod to disable the scheduled task framework.

[0015] Execute the target scheduled task in the container group (pod);

[0016] Once the proxy service detects that the target scheduled task has been completed, it releases the container group (pod) occupied by the target scheduled task.

[0017] This application also provides a computer-readable storage medium for storing computer instructions, which, when executed by one or more processors, cause the one or more processors to perform the aforementioned timed task processing method.

[0018] In this embodiment, a proxy service can be started before the scheduled task framework begins, allowing the scheduled task framework to be disabled without the user's awareness. Furthermore, the job controller in Kubernetes can be invoked to create container groups (pods) for each scheduled task, and these pods can be used to host both the scheduled tasks and the proxy service. This allows the job controller to manage scheduled tasks instead of the scheduled task framework; the proxy service can handle the scheduled tasks and monitor their execution status, and release the container group pods used by the scheduled task once it detects completion, thus achieving immediate shutdown upon completion. Therefore, a serverless scheduled task framework can be achieved without any modification to the original framework, improving resource consumption issues associated with scheduled tasks. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0020] Figure 1 A flowchart illustrating a method for processing a timed task, provided as an exemplary embodiment of this application;

[0021] Figure 2 A logical schematic diagram of a timed task processing method provided for an exemplary embodiment of this application;

[0022] Figure 3A functional logic diagram of a proxy service provided for an exemplary embodiment of this application;

[0023] Figure 4 This is a schematic diagram of the structure of a computing device provided for another exemplary embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] Currently, scheduled tasks continuously consume computing resources regardless of whether they are executed, leading to resource waste. To address this, some embodiments of this application propose: A proxy service can be started before the scheduled task framework begins, allowing the scheduled task framework to be disabled without the user's awareness; furthermore, the job controller in Kubernetes can be invoked to create container groups (pods) for each scheduled task, and these pods can be used to host both the scheduled tasks and the proxy service. This allows the job controller to manage scheduled tasks instead of the scheduled task framework; the proxy service can handle the scheduled tasks and monitor their execution status, and release the container groups (pods) occupied by the scheduled tasks once the proxy service detects their completion, thus achieving immediate shutdown upon completion of the scheduled tasks. Accordingly, a serverless scheduled task framework can be achieved without any modifications to the original framework, improving the resource consumption problem of scheduled tasks.

[0026] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0027] Figure 1 This is a flowchart illustrating a method for processing a timed task, provided as an exemplary embodiment of this application. Figure 2 This is a logical schematic diagram of a method for processing a timed task, provided as an exemplary embodiment of this application. (Reference) Figure 1 The method may include:

[0028] Step 100: When the target scheduled task meets the startup conditions, call the job controller in Kubernetes to create a container group (pod) for the target scheduled task.

[0029] Step 101: Before the scheduled task framework that the target scheduled task originally depends on starts, start the agent service on the container group pod to disable the scheduled task framework.

[0030] Step 102: Execute the target scheduled task in the container group pod;

[0031] Step 103: After the proxy service detects that the target scheduled task has been completed, release the container group pod occupied by the target scheduled task.

[0032] The scheduled task processing solution provided in this embodiment can be applied to various scenarios that require a scheduled task framework for scheduled task processing. This embodiment does not limit the application scenario. A scheduled task, as the name suggests, is a task that needs to be executed at regular intervals. A scheduled task framework is a framework used to manage scheduled tasks. This embodiment does not limit the type of scheduled task framework; the type of scheduled task framework may include, but is not limited to, Quartz, XXLJob, ElasticJob, Spring Task, etc.

[0033] The scheduled task processing solution provided in this embodiment can realize serverless operation of the scheduled task framework. The serverless operation in this embodiment mainly includes two aspects: the operation of scheduled tasks no longer depends on the user's local server but is fully managed in the cloud; the scheduled task stops immediately after completion and automatically releases resources.

[0034] Therefore, this embodiment proposes to call the job controller in Kubernetes to schedule scheduled tasks. Thus, the scheduled task processing solution provided in this embodiment uses Kubernetes as its underlying foundation. Kubernetes, or k8s for short, is a container orchestration engine that supports automated deployment, large-scale scalability, and containerized application management. In Kubernetes, multiple container groups (pods) can be created, and each pod can contain multiple containers, each running an application instance. In this embodiment, scheduled tasks can be hosted through container groups (pods).

[0035] Based on the underlying Kubernetes, see reference Figure 1 and Figure 2 In step 100, if the target scheduled task meets the startup conditions, the job controller in Kubernetes can be invoked to create a container group (pod) for the target scheduled task.

[0036] Traditional scheduled task frameworks require additional reliance on scheduling centers (e.g., ZooKeeper, databases) as schedulers to manage scheduled tasks. In this embodiment, scheduled tasks can be scheduled by calling the job controller within Kubernetes, eliminating the need for the scheduler required by traditional scheduled task frameworks.

[0037] In Kubernetes, the job controller can be used to manage tasks (jobs) and the container groups (pods) they create. In this embodiment, the job controller supports task features such as timeouts, retries, and blocking policies, and is compatible with the configuration of existing scheduled task frameworks. In one exemplary implementation: a configuration page for the job controller is provided to the user; in response to configuration operations on the configuration page, a configuration file corresponding to the job controller is generated; the job controller runs according to the configuration file. This implementation grants users configuration permissions to the job controller, allowing them to configure necessary task scheduling parameters, including but not limited to the number of retries, retry intervals, and blocking policies. Essentially, users also need to configure these task scheduling parameters for existing scheduled task frameworks; however, in this embodiment, users can configure these parameters in the job controller's configuration file. Thus, the job controller can schedule scheduled tasks according to the user-configured task scheduling parameters by executing its corresponding configuration file. The configuration file corresponding to the job controller can be a YAML file, etc. Users can directly configure the YAML file. Alternatively, these task scheduling parameters can be input into the cloud product through a white-screen interface, and the cloud product will generate the YAML file. This embodiment does not limit the user's configuration operation method.

[0038] In this embodiment, users no longer publish scheduled tasks according to the task format required by traditional scheduled task frameworks. Instead, they publish scheduled tasks according to the task format requirements of the job controller. That is, the format of the scheduled tasks published by the user must be compatible with the task format required by the job controller. For example, the task formats supported by the job controller may include, but are not limited to, CronJob, etc., although this embodiment is not limited to these. CronJob, similar to crontab in Linux systems, is used to manage time-based tasks and can run specified tasks at specified time periods. This provides the implementation basis for scheduling scheduled tasks by calling the job controller in Kubernetes in this embodiment.

[0039] When publishing a scheduled task, users can also configure the corresponding timing strategy. Therefore, in this embodiment, a scheduled task creation interface can be provided to the user. In response to the scheduled task creation operation and timing strategy configuration operation in the creation interface, a scheduled task conforming to the task format requirements of the job controller and its associated timing strategy can be generated. Here, the timing strategy may include, but is not limited to, one or more of the following: startup conditions, time zone, number of shards, restart conditions, timeout conditions, and blocking conditions. The startup condition can be used to specify the startup time of the scheduled task, the restart condition can be used to specify the restart requirements of the scheduled task, and the timeout condition can be used to specify the conditions for determining whether the scheduled task has timed out. Based on this, in step 100, the job controller can be used to obtain the timing strategy associated with the target scheduled task, which is pre-configured by the user for the target scheduled task; and the job controller can be used to detect whether the target scheduled task has met the startup conditions based on the timing strategy. During this process, the job controller can read the startup conditions from the timing strategy associated with the target scheduled task and combine this with the current actual time information to determine whether the target scheduled task has met the startup conditions. For example, if the startup condition for scheduled task A is to run once a day at 10:00, the job controller can determine that scheduled task A has met the startup condition when the actual time information is 10:00, and can create a container group pod for scheduled task A.

[0040] At this point, the container group pod can host the application corresponding to the target scheduled task.

[0041] Continue to refer to Figure 1 and Figure 2 In step 101, the proxy service can be started on the container group pod before the scheduled task framework that the target scheduled task originally depends on is started, so as to disable the scheduled task framework.

[0042] In step 101, the container group pod will host the application corresponding to the target scheduled task and the proxy service provided in this embodiment.

[0043] In one alternative implementation, bytecode-enhanced Java agent technology can be used to start a proxy service on the container pod before the original scheduled task framework, which the target scheduled task originally depends on, starts. In practice, the basic idea is to add a proxy service (Java Agent) when the container pod starts. This proxy service is associated with a pre-configured JAR file, and the MANIFEST.MF file within the container pod specifies the proxy class, which contains a premain method. Thus, when the container pod loads its classes, it executes the premain method of the proxy class first, and then executes the main method of the application corresponding to the scheduled task framework. Through this mechanism, the proxy service can be started automatically without modifying the original scheduled task framework, and the original scheduled task framework is no longer required to start. Therefore, the scheduled task framework can be disabled by starting the proxy service.

[0044] In this embodiment, a proxy service can replace the original scheduled task framework to perform related processing on scheduled tasks.

[0045] Figure 3 A functional logic diagram of a proxy service provided for an exemplary embodiment of this application. (Reference) Figure 3 In this embodiment, a proxy service can be used to specify the target type corresponding to the timed task framework that the target timed task depends on from multiple types, and the service logic resource package associated with the target type can be obtained as the target service logic resource package adapted to the timed task framework. Based on this, a custom class loading operation can be performed in the container group pod through the proxy service to load the target service logic resource package adapted to the timed task framework; the target timed task can then be processed according to the service logic in the target service logic resource package using the proxy service. As mentioned earlier, a proxy class is specified for the proxy service in this embodiment, which breaks the traditional parent delegation model in Java. Therefore, in this embodiment, a custom class loader can be obtained during the class loading process, and the target service logic resource package can be found and loaded according to a pre-defined path using the custom class loader. The service logic resource package here can be a JAR file or other formats.

[0046] To support the proxy service in executing the service logic within the target service logic resource package, this embodiment also utilizes the proxy service to discover the target scheduled task, its corresponding pre-callback task, and / or post-callback task on the container group pod. During the research process, the inventors discovered that traditional scheduled task frameworks typically use interfaces or annotations to identify specified classes or methods as "scheduled tasks to be executed," and as "callback tasks before and after the scheduled task execution." Therefore, in this embodiment, the proxy service can use reflection to discover the target scheduled task, its corresponding pre-callback task, and / or post-callback task. Specifically, the proxy service can use reflection to find methods in the target class or classes or methods identified by target annotations / interfaces, thereby discovering the target scheduled task and its corresponding pre-callback task and / or post-callback task.

[0047] The target service logic resource package can be generated by pre-encapsulating the task processing logic within the timed task framework upon which the target timed task depends. In this embodiment, different timed task frameworks can be encapsulated separately to obtain various service logic resource packages adapted to different timed task frameworks. Thus, the service logic in the target service logic resource package may include, but is not limited to, executing the pre-callback task corresponding to the target timed task, executing the target timed task, and executing the post-callback task corresponding to the target timed task. Based on this, the proxy service can execute these service logics to process the target timed task.

[0048] In this embodiment, when the service logic "execute the target scheduled task" in the target service logic resource package is executed, the target scheduled task can be triggered to execute in the container group pod. To ensure the smooth execution of the target scheduled task in the container group pod, the service logic in the target service logic resource package in this embodiment may further include injecting task description information into the task context of the target scheduled task. To achieve task context injection, in one optional implementation: the job controller can inject environment variables into the container group pod; these environment variables are used to identify the task description information of the target scheduled task; a proxy service can identify the environment variables to obtain the task description information of the target scheduled task; and the proxy service can inject the task description information into the task context of the target scheduled task so that the target scheduled task can execute its own task logic based on the task description information. In practical applications, users can configure the relevant logic for the job controller to inject environment variables into the container group pod in the aforementioned job controller configuration file. In this way, the job controller can inject environment variables into the container group pod when creating it. The proxy service can identify these environment variables and thus obtain the task description information of the scheduled task. Here, the task description information may include, but is not limited to, task ID, task name, task execution parameters, total number of task shards, current number of task shards, and current shard parameters. By injecting the task description information into the task context of the target scheduled task, the target scheduled task can execute its own task logic on the container group pod.

[0049] refer to Figure 1 and Figure 2 In step 103, the proxy service can be used to detect when the target scheduled task has finished executing and release the container group pod occupied by the target scheduled task.

[0050] In one exemplary implementation, the service logic in the aforementioned target service logic resource package may further include an exit code. Based on this, in this embodiment, a proxy service can also be used to generate an exit code representing the completion status of the target scheduled task based on the execution result of the target scheduled task. For example, if the target scheduled task has completed execution, the exit code value can be 0; conversely, if the target scheduled task has failed, the exit code value can be 1. Thus, in step 103, if the exit code indicates that the target scheduled task has completed execution, the container group (pod) occupied by the target scheduled task can be released. This enables the target scheduled task to stop immediately upon completion, promptly releasing the container group (pod) occupied by the target scheduled task.

[0051] The following example illustrates the timed task processing solution provided in this embodiment.

[0052] In this exemplary application scenario, scheduled task A originally relied on scheduled task framework a to run. Scheduled task framework a is of type Quartz and originally included a task (JobDetail), a trigger (Trigger), and an external scheduler (Scheduler). Scheduled task framework a may have originally run on the user's local server or a cloud server rented by the user, and the user originally published scheduled task A according to the deployment format.

[0053] Based on the scheduled task processing scheme provided in this embodiment, users can publish scheduled task A according to the cronjob format and associate a scheduling policy with scheduled task A, specifying the start conditions, time zone, etc., of scheduled task A in the scheduling policy. Task scheduling parameters can also be configured in the YAML file corresponding to the job controller; alternatively, the processing scheme provider can build the configuration file and configure the task scheduling parameters. On this basis, the job controller in Kubernetes can be called to schedule and manage the lifecycle of each cronjob published by the user.

[0054] The Job controller can execute YAML files to operate according to the predefined logic and task scheduling parameters within those files. In this way, the Job controller can detect when a scheduled task A needs to be started based on the scheduling policy associated with that task and create a pod for it.

[0055] After creating the pod, you can add the agent service provided in this embodiment to the pod and inject environment variables into the pod. The pod then hosts the application and agent corresponding to scheduled task A.

[0056] By adding an agent to the pod, the scheduled task framework 'a' no longer starts on the pod. Instead, the agent service loads the specified JAR file and runs the pre-defined service logic within the JAR file. During this process:

[0057] The agent can select a framework, choosing the type corresponding to the current scheduled task framework 'a';

[0058] The agent performs a custom class loading operation, obtains the custom class loader `lanchedurlclassloader`, generates the JAR URL corresponding to the JAR package associated with the selected framework type, and thus obtains the required JAR package. This JAR package is generated by encapsulating the original task processing logic in Quartz and is pre-stored in a specified path for later use.

[0059] The agent can discover scheduled task A and its callback tasks before and after execution on the pod through reflection. It can also obtain the task description information corresponding to scheduled task A by identifying environment variables and inject it into the task context of scheduled task A.

[0060] In this way, the agent can trigger the execution of the callback task corresponding to scheduled task A before execution, trigger the execution of scheduled task A, and trigger the execution of the callback task corresponding to scheduled task A after execution.

[0061] The target scheduled task A on the Pod can execute its own task logic based on the task context after injecting task description information.

[0062] The Agent can also sense the execution status of scheduled task A and output exit code 1 after successful execution;

[0063] When the exit code is 1, the computing resources occupied by scheduled task A can be released in a timely manner, so as to realize pay-as-you-go billing for scheduled task A.

[0064] Accordingly, the scheduled task processing solution provided in this embodiment can leverage Java agent technology to enable zero-modification support for Java scheduled task framework applications to construct task contexts, run specified tasks, and stop tasks immediately upon completion. It utilizes the Kubernetes job controller to replace the task scheduling and core feature-related functions of the original Java scheduled task framework and manages the task lifecycle. Combining these two points achieves zero-modification support for the serverless implementation of the Java scheduled task framework, maintaining compatibility with scheduled task-related features (timeout, retries, blocking, etc.) while enabling tasks to stop immediately upon completion. This allows users to pay only for the execution of scheduled tasks, significantly saving user resources and manpower costs. Furthermore, users only need to focus on the specific task logic of the scheduled tasks without needing to manage and maintain functions related to task scheduling.

[0065] It should be noted that some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 101, 102, etc., are merely used to distinguish different operations and do not represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0066] Figure 4 This is a schematic diagram of the structure of a computing device provided for another exemplary embodiment of this application. For example... Figure 4 As shown, the computing device includes a memory 40 and a processor 41.

[0067] Processor 41, coupled to memory 40, is used to execute computer programs in memory 110 for:

[0068] When the target scheduled task meets the startup conditions, the task job controller in Kubernetes is invoked to create a container group (pod) for the target scheduled task.

[0069] Before the scheduled task framework that the target scheduled task originally depends on starts, start the agent service on the container group pod to disable the scheduled task framework.

[0070] Execute the target scheduled task in a container group (pod);

[0071] Once the proxy service detects that the target scheduled task has finished executing, it releases the container group (pod) occupied by the target scheduled task.

[0072] The computing device provided in this embodiment can be a cloud server or a virtual machine running on a cloud server; this embodiment does not limit this.

[0073] In an alternative embodiment, processor 41 may also be used for:

[0074] The job controller injects environment variables into the container group pod. These environment variables are used to identify the task description information of the target scheduled task.

[0075] Use proxy services to identify environment variables in order to obtain task description information for the target scheduled task;

[0076] The task description information is injected into the task context of the target scheduled task using a proxy service, so that the target scheduled task can execute its own task logic based on the task description information.

[0077] In an alternative embodiment, processor 41 may also be used for:

[0078] A custom class loading operation is performed in the container group pod through a proxy service to load the target service logic resource package that is adapted to the scheduled task framework;

[0079] The proxy service is used to process the target scheduled task according to the service logic in the target service logic resource package.

[0080] In one alternative embodiment, the target service logic resource package is generated by pre-encapsulating the task processing logic in the scheduled task framework.

[0081] In an optional embodiment, during the process of processing the target scheduled task using the proxy service according to the service logic in the service logic resource package, the processor 41 can be used to:

[0082] Use the proxy service to discover the target scheduled task, the corresponding pre-callback task and / or post-callback task on the container group pod;

[0083] Trigger the execution of the pre-callback tasks and / or post-callback tasks corresponding to the target customized task and the target timed task;

[0084] The proxy service generates an exit code that represents the completion status of the target scheduled task based on the execution result of the target scheduled task.

[0085] In an optional embodiment, after the processor 41 detects that the target scheduled task has finished executing using the proxy service, during the process of releasing the container group pod occupied by the target scheduled task, it can be used to:

[0086] If the exit code indicates that the target scheduled task has completed execution, then the container group (pod) occupied by the target scheduled task is released.

[0087] In an alternative embodiment, processor 41 may also be used for:

[0088] Provide users with a configuration page for the job controller;

[0089] In response to configuration operations that occur on the configuration page, generate the configuration file corresponding to the job controller;

[0090] The job controller runs according to the configuration file.

[0091] In an alternative embodiment, processor 41 may also be used for:

[0092] The job controller is used to obtain the timing policy associated with the target scheduled task. The timing policy is pre-configured by the user for the target scheduled task.

[0093] The job controller uses a timing strategy to determine whether the target timed task has met the start conditions.

[0094] In one optional embodiment, the timing strategy includes one or more of the following: start condition, time zone, number of slices, restart condition, timeout condition, and blocking condition.

[0095] In an optional embodiment, the target scheduled task is published in a format that conforms to the task format requirements of the job controller.

[0096] Furthermore, such as Figure 4 As shown, the computing device also includes other components such as a communication component 42 and a power supply component 43. Figure 4 The diagram only shows some components and does not mean that the computing device includes only these components. Figure 4 The components shown.

[0097] It is worth noting that the technical details of the above-mentioned embodiments of the computing device can be referred to the relevant descriptions in the foregoing method embodiments. To save space, they will not be repeated here, but this should not cause any loss to the scope of protection of this application.

[0098] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed, can perform the steps that can be executed by a computing device in the above method embodiments.

[0099] The above Figure 4 The memory in a computer is used to store computer programs and can be configured to store various other data to support operation on a computing platform. Examples of this data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, pictures, videos, etc. The memory can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disks, or optical disks.

[0100] The above Figure 4 The communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component further includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA) technology, Ultra-Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0101] The above Figure 4 The power supply component provides power to the various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which it resides.

[0102] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0103] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0104] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0105] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0106] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0107] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0108] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0109] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0110] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for processing scheduled tasks, comprising: When it is detected that the target scheduled task that requires the scheduled task framework has met the startup conditions, the task job controller in Kubernetes is invoked to create a container group (pod) for the target scheduled task. Before the scheduled task framework that the target scheduled task originally depends on starts, start a proxy service on the container group pod to disable the scheduled task framework using the proxy service. Execute the target scheduled task within the container group (pod); Once the proxy service detects that the target scheduled task has been completed, it releases the container group (pod) occupied by the target scheduled task.

2. The method according to claim 1, further comprising: The job controller injects environment variables into the container group pod, and the environment variables are used to identify the task description information of the target scheduled task. The proxy service is used to identify the environment variables in order to obtain the task description information of the target timed task. The proxy service is used to inject the task description information into the task context of the target timed task, so that the target timed task can execute its own task logic based on the task description information.

3. The method according to claim 1, further comprising: The proxy service performs a custom class loading operation in the container group pod to load the target service logic resource package adapted to the scheduled task framework. The proxy service is used to process the target scheduled task according to the service logic in the target service logic resource package.

4. The method according to claim 3, wherein the target service logic resource package is generated by pre-encapsulating the task processing logic in the timed task framework.

5. The method according to claim 3, wherein processing the target scheduled task using the proxy service according to the service logic in the service logic resource package includes: The proxy service is used to discover the target scheduled task, the pre-callback task and / or post-callback task corresponding to the target scheduled task on the container group pod; Trigger the execution of the target timed task, the pre-callback task corresponding to the target timed task, and / or the post-callback task; The proxy service generates an exit code that characterizes the completion status of the target scheduled task based on the execution result of the target scheduled task.

6. The method according to claim 5, wherein releasing the container group pod occupied by the target scheduled task after the proxy service detects that the target scheduled task has been completed includes: If the exit code indicates that the target scheduled task has been completed, then the container group (pod) occupied by the target scheduled task is released.

7. The method according to claim 1, further comprising: Provide the user with a configuration page for the job controller; In response to the configuration operation that occurs on the configuration page, a configuration file corresponding to the job controller is generated; The job controller runs according to the configuration file.

8. The method according to claim 1, further comprising: The job controller is used to obtain the timing policy associated with the target scheduled task, which is pre-configured by the user for the target scheduled task. The job controller uses the timing strategy to detect whether the target timed task has met the start conditions.

9. The method according to claim 8, wherein the timing strategy includes one or more of the following: startup condition, time zone, number of slices, restart condition, timeout condition, and blocking condition.

10. The method according to claim 1, wherein the publishing format of the target timed task conforms to the task format requirements of the job controller.

11. A computing device, comprising a memory and a processor; The memory is used to store one or more computer instructions; The processor is coupled to the memory and is used to execute the one or more computer instructions for: When it is detected that the target scheduled task that requires the scheduled task framework has met the startup conditions, the task job controller in Kubernetes is invoked to create a container group (pod) for the target scheduled task. Before the scheduled task framework that the target scheduled task originally depends on starts, start a proxy service on the container group pod to disable the scheduled task framework using the proxy service. Execute the target scheduled task in the container group (pod); Once the proxy service detects that the target scheduled task has been completed, it releases the container group (pod) occupied by the target scheduled task.

12. A computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause the one or more processors to perform a processing method for a timed task as described in any one of claims 1-10.

Images