Computing power network task scheduling method and system

Abstract

The application provides a computing power network task scheduling method and system, which comprises the following steps: obtaining a to-be-deployed micro service, a deployment algorithm, to-be-deployed micro service requirements and cluster information, screening a first cluster set matched with the to-be-deployed micro service based on the to-be-deployed micro service requirements and the cluster information; determining a deployment strategy based on the first cluster set and the deployment algorithm, wherein the deployment strategy comprises the number of replicas and the name of a deployment cluster, the deployment cluster belongs to the first cluster set, and the to-be-deployed micro service is deployed based on the deployment strategy; obtaining a to-be-scheduled task, a scheduling algorithm and to-be-scheduled task requirements, screening a second cluster set from the deployment cluster set based on the to-be-scheduled task requirements; determining a scheduling strategy based on the second cluster set and the scheduling algorithm, wherein the scheduling strategy comprises the name of a scheduling cluster and the number of task requests corresponding to each scheduling cluster, the scheduling cluster belongs to the second cluster set, and the to-be-scheduled task request is scheduled based on the scheduling strategy.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet, and particularly relates to a computing power network task scheduling method and system. BACKGROUND

[0002] With the Internet entering the second half of the game and gradually changing from consumer applications to production applications, the digital development of various industries has given rise to new businesses such as autonomous driving, AR / VR, and ultra-high-definition video. These businesses are different from traditional Internet era businesses such as email distribution, web browsing, and file transfer. They have the most core feature of being computationally intensive and require networks to provide ultra-low latency, ultra-large-scale connectivity, and ultra-strong computing power, as well as high-quality and differentiated services.

[0003] As traditional task processing methods and capabilities gradually fail to meet the above business needs, the industry has explored cloud computing, edge computing, SD-WAN, cloud network integration, and other solutions to integrate networks and computing to meet the computing power needs of computationally intensive businesses. In recent years, with the deep integration of IT and CT, the evolution of cloud network integration to algorithm network integration represented by computing power networks has become an important development direction. The algorithm network platform based on cloud computing clusters is a system that enables various computationally intensive tasks to be processed by computing power networks. It not only can perceive computing power and network resources, business and user status, but also can implement task scheduling and processing, and scaling capabilities. Among them, algorithm network task deployment and scheduling are key steps to achieve efficient task processing. Currently, algorithm network platforms have centralized and distributed design schemes. Although the distributed scheme has advantages such as flexibility and scalability, it has problems such as difficulty in management, weak security, and inability for unified operation and maintenance and billing by the operation and maintenance organization, so the distributed scheme does not meet the technical and commercial needs of actual deployment. The centralized deployment scheme has better compatibility with the existing hierarchical network architecture of each operator, and is easier to manage and operate and deliver services, so the existing algorithm network platforms that have been implemented are deployed and scheduled in a centralized manner.

[0004] However, the above centralized computing network platform still has the following problems, which restrict the ability and efficiency of task scheduling: (1) Most existing computing network platforms adopt a design scheme of integrating each function, which, although it realizes centralized task scheduling, the relationship between modules is not clear, and different functions are coupled together, and the same function is also divided into multiple places. The scheduling engine under this architecture cannot achieve modular independent operation of scheduling work, nor can it reduce the redundant interaction of the scheduling engine with other modules. (2) The specific function design of the task scheduling engine of the existing computing network platform is not detailed enough. For cloud cluster-based computing network platforms, task scheduling should include different processes such as initial deployment of applications and scheduling of user requests, and for computing network platforms with scaling functions, it should also include the scaling and scaling processes of applications. However, existing computing network platforms often do not distinguish task scheduling in detail, and only design a simple common scheduling process. (3) The scheduling strategy used by the task scheduling engine of the existing computing network platform in the process of executing the scheduling work is often fixed and embedded. However, different user application services have different QoS requirements, which means that the scheduling strategies and algorithms used by different businesses should be diverse. At present, the industry and related scholars have proposed some solutions for the design and optimization of the task scheduling engine in the computing network platform, but it is still in the initial exploratory stage of research, and cannot completely solve the above problems, there is still a large gap in theory and technology from actual deployment application, and a large number of innovative and detailed research is still needed to form a perfect technical system.

[0005] Specifically, there is a cluster resource scheduling method in the prior art, which comprises the following steps: obtaining resource scheduling tasks of each tenant in a preset time period; determining the scheduling priority corresponding to each resource scheduling task according to each resource scheduling task and a matching preset resource scheduling threshold range; determining the cluster scheduling resource corresponding to each resource scheduling task in each scheduling priority according to each scheduling priority and a preset scheduling priority order; and scheduling the cluster scheduling resource corresponding to each resource scheduling task. However, this method has the following disadvantages: the scheme of setting the scheduling priority according to the pre-set threshold is not feasible, this method is not suitable for the micro-service deployment scenario based on the cloud cluster, and the classification of the scheduling task is not clear. Because in the actual computing power network platform, the computing devices accessed are heterogeneous, and the user business demands are different, the pre-set threshold method cannot accurately guarantee the business demand, in addition, in a large-scale computing network platform, setting the priority for all businesses and users will greatly increase the calculation and storage capacity; and this method classifies the application business first and then directly deploys it, however, in the micro-service scenario, the platform needs to split an overall application into multiple micro-services and deploy them to different clusters, if different micro-services are set to different priorities, it may cause the problem that the application cannot run in time in each cluster; this method does not distinguish between the application deployment process and the request scheduling process, and does not consider the scheduling problem involved in the scaling.

[0006] In addition to the above, there is a micro-service scheduling and automatic scaling system and method under multiple workflows in the prior art, which models the micro-service workflow, proposes a micro-service scheduling and automatic scaling optimization method to optimize the server resource usage cost under the workflow deadline constraint, and gives the micro-service execution mapping relationship and the adaptive configuration resource of the container. However, although the idea of jointly optimizing scheduling and scaling can solve the mutual influence problem to some extent, it greatly increases the calculation amount. In addition, the scheduling and scaling decision modules are completely coupled together, so that the related functions no longer have the advantages of easy expansion and flexible combination. Moreover, this method is mainly used in a relatively stable virtual machine environment, but it is difficult to implement for a computing network platform based on multiple cloud clusters with the characteristics of large range, dynamicity and heterogeneity. In addition to the above, there is no check and screening mechanism before the deployment / scheduling of clusters and micro-services in this method, and there is no error handling mechanism, so the system robustness is poor in actual application.

[0007] In summary, for the computing power network task scheduling method and system, the prior art generally has poor processing capacity for computing power task requests, therefore, how to improve the processing capacity of computing power task requests is a technical problem to be solved. SUMMARY

[0008] Therefore, the application provides a computing power network task scheduling method and system to solve one or more problems in the prior art.

[0009] According to one aspect of the application, a computing power network task scheduling method is disclosed, which comprises:

[0010] Obtaining a to-be-deployed microservice, a deployment algorithm, a to-be-deployed microservice requirement, and cluster information, screening a first cluster set matched with the to-be-deployed microservice based on the to-be-deployed microservice requirement and the cluster information;

[0011] Determining a deployment strategy based on the first cluster set and the deployment algorithm, the deployment strategy comprising the number of microservice replicas and the name of a deployment cluster, the deployment cluster belonging to the first cluster set, and deploying the to-be-deployed microservice based on the deployment strategy;

[0012] Obtaining a to-be-scheduled task, a scheduling algorithm, and a to-be-scheduled task requirement, and screening a second cluster set from the deployment cluster set based on the to-be-scheduled task requirement;

[0013] Determining a scheduling strategy based on the second cluster set and the scheduling algorithm, the scheduling strategy comprising the name of a scheduling cluster and the number of task requests corresponding to each scheduling cluster, the scheduling cluster belonging to the second cluster set, and scheduling the requests in the to-be-scheduled task based on the scheduling strategy.

[0014] In some embodiments of the application, screening a first cluster set matched with the to-be-deployed microservice based on the to-be-deployed microservice requirement and the cluster information comprises:

[0015] Pre-screening all clusters based on the to-be-deployed microservice requirement to obtain candidate clusters;

[0016] Screening a first cluster matched with the to-be-deployed microservice based on the computing power, storage resources, and network resources of each candidate cluster to form a first cluster set.

[0017] In some embodiments of the application, deploying the to-be-deployed microservice based on the deployment strategy comprises:

[0018] Setting a reservation state for each deployment cluster corresponding to the to-be-deployed microservice; the reservation state comprising reservation success, reservation failure, or pending approval;

[0019] When the reservation state is reservation success, binding the to-be-deployed microservice and the corresponding deployment cluster, and sending the microservice image of the to-be-deployed microservice to the corresponding deployment cluster to complete deployment.

[0020] In some embodiments of the present application, a reservation state is set for each deployment cluster corresponding to the to-be-deployed microservice, including:

[0021] The first permission plug-in is used to check whether the deployment cluster permits the corresponding to-be-deployed microservice to be bound;

[0022] When the binding is permitted, the reservation state is reservation success;

[0023] When the binding is refused, the reservation state is reservation failure;

[0024] When the binding is pending, the reservation state is pending approval.

[0025] In some embodiments of the present application, the deployment algorithm and / or the scheduling algorithm is a self-defined algorithm.

[0026] In some embodiments of the present application, the method further includes:

[0027] Receiving an expansion and contraction strategy sent by a dynamic expansion and contraction module, the expansion and contraction strategy including an expansion and contraction cluster name and a number of microservice instance replicas that need to be expanded or contracted;

[0028] Performing a corresponding expansion operation or contraction operation based on the received expansion and contraction strategy.

[0029] In some embodiments of the present application, the request in the to-be-scheduled task is scheduled based on the scheduling strategy, including:

[0030] The second permission plug-in is used to check whether the scheduling cluster permits to be invoked;

[0031] When the invocation is permitted, the task request of the to-be-scheduled task is matched with the corresponding scheduling cluster;

[0032] When the invocation is refused, the task request of the to-be-scheduled task is saved to a scheduling cache queue;

[0033] When the invocation is pending, the task request of the to-be-scheduled task is saved to a waiting request list, and when the waiting time exceeds a preset time, the task request of the to-be-scheduled task is saved to the scheduling cache queue.

[0034] In some embodiments of the present application, the method further includes:

[0035] Receiving to-be-deployed microservice demand information and to-be-scheduled task demand information sent by a business demand awareness module, receiving network link information sent by a network resource awareness module, receiving computing power resource states of each computing node sent by a computing power resource awareness module, and receiving cluster registration information sent by a registration information module;

[0036] The to-be-deployed microservice requirement information, to-be-scheduled task requirement information, network link information, computing resource state of each computing node, cluster registration information, deployment strategy and scheduling strategy are stored to an information table.

[0037] According to another aspect of the present application, a computing power network task scheduling engine system is also disclosed, which comprises a processor and a memory, the memory storing computer instructions, the processor being configured to execute the computer instructions stored in the memory, and the system implementing the steps of the method of any one of the above embodiments when the computer instructions are executed by the processor.

[0038] According to still another aspect of the present application, a computer readable storage medium is also disclosed, which stores a computer program, the program being executed by a processor to implement the steps of the method of any one of the above embodiments.

[0039] The computing power network task scheduling method and system disclosed in the present application first determine a deployment strategy based on a first cluster set and a deployment algorithm, and further deploy the to-be-deployed microservice after determining the deployment strategy; then determine a scheduling strategy based on a second cluster set and a scheduling algorithm, and complete the scheduling of the to-be-scheduled task based on the scheduling strategy. In the method, the deployment and the scheduling belong to different processings, so that the deployment and the scheduling can be completed by one scheduling engine, and the whole scheduling work can be completed through the efficient mutual cooperation of each process; in the method, the deployment steps independently executed with the scheduling can be reused multiple times, so that the microservice can be deployed conveniently; thus, the method and the system improve the processing capacity of the computing power task request and reduce the system calculation amount.

[0040] Additional advantages, objects, and features of the application will be set forth in part by the description that follows, and will become apparent to those skilled in the art upon examination of the following or can be learned by practice of the application. The objects and other advantages of the application can be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

[0041] It will be understood by those skilled in the art that the objects and advantages of the present application can be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings. BRIEF DESCRIPTION OF DRAWINGS

[0042] The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the principles of the application. The components in the drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the application. To facilitate an understanding of some portions of this application, corresponding portions of the drawings have been exaggerated in some aspects and minimized in others.

[0043] Figure 1 Flowchart of a computing power network task scheduling method according to an embodiment of the present application.

[0044] Figure 2 Structure diagram of a computing power network task scheduling system according to an embodiment of the present application.

[0045] Figure 3 Data interaction diagram of a computing power network task scheduling engine and each module according to an embodiment of the present application.

[0046] Figure 4a Flowchart of a deployment process according to an embodiment of the present application.

[0047] Figure 4b Flowchart of a scheduling process according to an embodiment of the present application.

[0048] Figure 4c Flowchart of a scaling process according to an embodiment of the present application.

[0049] Figure 5a Running mechanism diagram of a scheduling engine in a micro-service deployment stage according to an embodiment of the present application.

[0050] Figure 5b Running mechanism diagram of a scheduling engine in a request scheduling stage according to an embodiment of the present application.

[0051] Figure 5c Running mechanism diagram of a scheduling engine in a scaling stage according to an embodiment of the present application. DETAILED DESCRIPTION

[0052] In order to make the purpose, technical scheme and advantages of the embodiments of the present application clearer, further detailed description of the embodiments of the present application will be given below with reference to the drawings. Here, the illustrative embodiments of the present application and the description thereof are used to explain the present application, but do not limit the present application.

[0053] Here, it should be noted that, in order to avoid obscuring the present application due to unnecessary details, only structures and / or processing steps closely related to the scheme according to the present application are shown in the drawings, and other details not closely related to the present application are omitted.

[0054] It should be emphasized that the terms "comprises / comprising" when used in this specification are taken to specify the presence of stated features, elements, steps or components but do not preclude the presence or addition of one or more other features, elements, steps, components, or groups thereof.

[0055] In view of a series of problems existing in the task scheduling engine in the current computing network platform, the application provides a computing power network task scheduling method and system. In the following, the application will be described in terms of the composition structure of the scheduling engine in the computing power network task scheduling method and system, the overall operation mechanism of the scheduling engine in the computing network platform, the data interaction mechanism of the scheduling engine and other modules in the computing network platform, and the specific operation steps and operations of the computing power network task scheduling engine in the micro-service deployment stage, the request scheduling stage and the expansion and contraction stage. The computing power network task scheduling method and system provide a key idea and technical basis for the further optimization and development of the computing network task scheduling engine.

[0056] In the following, embodiments of the application will be described with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar components or the same or similar steps.

[0057] Figure 1 As shown in the flowchart of the computing power network task scheduling method of an embodiment of the application, Figure 1 the method at least includes steps S10 to S40.

[0058] Step S10: obtaining a to-be-deployed micro-service, a deployment algorithm, to-be-deployed micro-service requirements and cluster information, and filtering a first cluster set matched with the to-be-deployed micro-service based on the to-be-deployed micro-service requirements and the cluster information.

[0059] Step S20: determining a deployment strategy based on the first cluster set and the deployment algorithm, the deployment strategy including the number of micro-service replicas and the name of a deployment cluster, the deployment cluster belonging to the first cluster set, and deploying the to-be-deployed micro-service based on the deployment strategy;

[0060] Step S30: obtaining a to-be-scheduled task, a scheduling algorithm and to-be-scheduled task requirements, and filtering a second cluster set from the deployment cluster set based on the to-be-scheduled task requirements;

[0061] Step S40: determining a scheduling strategy based on the second cluster set and the scheduling algorithm, the scheduling strategy including the name of a scheduling cluster and the number of task requests corresponding to each scheduling cluster, the scheduling cluster belonging to the second cluster set, and scheduling the requests in the to-be-scheduled task based on the scheduling strategy.

[0062] The steps S10 to S20 above are based on the received to-be-deployed microservice requirement to deploy the to-be-deployed microservice, and the steps S30 to S40 are based on the received to-be-scheduled task requirement and the to-be-scheduled task to schedule the request in the to-be-scheduled task. In this embodiment, the to-be-deployed microservice requirement and the to-be-scheduled task requirement can both be user input.

[0063] In step S10, a first cluster set matching the to-be-deployed microservice of the user is mainly selected from a series of clusters, that is, a cluster that can perform microservice deployment is selected from the series of clusters. In an example, each cluster in the first cluster set matching the to-be-deployed microservice matches the to-be-deployed microservice requirement input by the user. The specific conditions contained in the to-be-deployed microservice requirement are not limited, and can be changed according to the actual requirement of the user.

[0064] In an embodiment, the first cluster set matching the to-be-deployed microservice is selected based on the to-be-deployed microservice requirement and the cluster information, including: pre-selecting all clusters based on the to-be-deployed microservice requirement to obtain candidate clusters; selecting the first cluster set matching the to-be-deployed microservice based on the computing power, storage resource and network resource of each candidate cluster. In this embodiment, the step of determining the first cluster set matching the to-be-deployed microservice includes pre-selection and selection, and the clusters in the first cluster set are highly matched to the to-be-deployed microservice requirement corresponding to the to-be-deployed microservice through two selections. Wherein, the computing power, storage resource and network resource of each cluster are obtained based on the cluster information of each cluster.

[0065] In step S20, a deployment strategy is first determined, and then the to-be-deployed microservice is specifically deployed based on the determined deployment strategy; wherein the specific deployment algorithm can be customized according to the requirement of the platform / user / application. Specifically, deploying the to-be-deployed microservice based on the deployment strategy includes: setting a reserved state for each deployment cluster corresponding to the to-be-deployed microservice; the reserved state includes reserved success, reserved failure or to be approved; when the reserved state is reserved success, the to-be-deployed microservice is bound to the corresponding deployment cluster, and the microservice image of the to-be-deployed microservice is sent to the corresponding deployment cluster to complete the deployment. In this embodiment, the deployment cluster is the cluster finally determined to complete the deployment of the to-be-deployed microservice according to the first cluster set and the deployment algorithm, and the reserved state is set for the deployment cluster to prevent resource competition when the scheduling engine waits for binding, so as to ensure that the to-be-deployed microservice and the corresponding deployment cluster can be effectively bound.

[0066] And setting a reservation state for each deployment cluster corresponding to the to-be-deployed microservice, which may exemplarily include: based on the first permission plug-in, checking whether the deployment cluster permits the corresponding to-be-deployed microservice to be bound; when the binding is allowed, the reservation state is reservation success; when the binding is refused, the reservation state is reservation failure; and when the binding is waiting, the reservation state is waiting for approval. When the reservation is successful, the to-be-deployed microservice can be further bound to the corresponding deployment cluster; when the reservation fails, the to-be-deployed microservice can be stored in the deployment cache queue; and when the binding is waiting, the to-be-deployed microservice can be further stored in the waiting queue for a certain period of time, and if the binding is still not allowed after the waiting time reaches the preset time, the to-be-deployed microservice is further stored in the deployment cache queue similar to the reservation failure state.

[0067] In step S30, the to-be-scheduled task and the to-be-scheduled task demand can be input by the user, and at this time, the deployment cluster is first checked to check whether the deployment cluster has the ability to process the to-be-scheduled task, so as to select the cluster that meets certain conditions for processing the scheduling task request from the deployment cluster set to generate a second cluster set. If no second cluster that meets the conditions is found in the deployment cluster set, the platform can be directly fed back information that the task request cannot be scheduled / scheduling fails.

[0068] In step S40, the scheduling strategy is first determined, and then the to-be-scheduled task is scheduled based on the scheduling strategy; wherein the specific scheduling algorithm can be customized according to the needs of the platform / user / application. Exemplarily, based on the scheduling strategy, the request in the to-be-scheduled task is scheduled, including: based on the second permission plug-in, checking whether the scheduling cluster is allowed to be called; when the calling is allowed, the task request of the to-be-scheduled task is matched with the corresponding scheduling cluster; when the calling is refused, the task request of the to-be-scheduled task is saved to the scheduling cache queue; and when the calling is waiting, the task request of the to-be-scheduled task is saved to the waiting request list, and when the waiting time exceeds the preset time, the task request of the to-be-scheduled task is saved to the scheduling cache queue.

[0069] In another embodiment, the computing power network task scheduling method further includes the following steps: receiving the expansion and contraction strategy sent by the dynamic expansion and contraction module, the expansion and contraction strategy including the expansion and contraction cluster name and the number of microservice instance replicas that need to be expanded or contracted; based on the received expansion and contraction strategy, performing the corresponding expansion operation or contraction operation.

[0070] The task scheduling engine is the core module of the computing power network task processing, and plays a crucial role in the operation of the computing network platform and the processing of user services. Figure 2 The structure diagram of the computing power network task scheduling engine system of an embodiment of the present application is as follows:Figure 2 As shown, in an embodiment, the computing power network task scheduling engine system can specifically include a scheduler, an executor, and an information table. The scheduling engine participates in three processes of microservice deployment (initial deployment of application instances), service request scheduling (user request scheduling after deployment of instances), and dynamic scaling (increasing / decreasing of microservice instances) through asynchronous working with the aid of these components. Among them, the scheduler is mainly responsible for decision-making for microservice deployment, service request scheduling, and the like, and recording of information related to scaling, the executor is responsible for executing the decisions made by the scheduler, and the information table is used to maintain information exchanged between the scheduling engine and other modules and data information generated inside the scheduling engine.

[0071] In the computing power network platform, in order to realize the operation and maintenance of the platform and the processing of user business, the computing power network platform includes, in addition to the scheduling engine, a business demand perception module, a network resource perception module, a computing power resource perception module, a registration information module, and a dynamic scaling module, etc. The business demand perception module is used to obtain demand information of users, the network resource perception module is used to perceive network link information in real time, the computing power resource perception module is used to perceive the state of computing power resources of each computing node in real time, the registration information module is used to record registration information of cloud clusters and users, and the dynamic scaling module is used to decide further deployment of microservices to increase service processing capacity for scaling or to release part of the microservices to reduce redundant processing capacity for scaling down, according to real-time resource quantity and business quantity.

[0072] Reference Figure 3 The information table is used to realize storage and interaction of data information of each module. That is, data obtained in real time by the business demand perception module, the network resource perception module, the computing power resource perception module, and the registration information module is transported to the information table of the scheduling engine for storage, and the running results of the deployment algorithm and the scheduling algorithm and the scaling strategy of the dynamic scaling module are also stored in the information table of the scheduling engine. In addition, the information table also stores information output by the scheduling engine, such as providing required parameters to the deployment algorithm and the scheduling algorithm, and periodically inputting necessary data to the dynamic scaling module. Since the deployment algorithm and the scheduling algorithm can be self-defined algorithms, the types of parameters provided to the deployment algorithm and the scheduling algorithm change based on changes in the self-defined algorithms. Exemplary parameters provided to the deployment algorithm and the scheduling algorithm include delay, jitter, bandwidth, and the like in network perception indicators. Necessary data periodically input to the dynamic scaling module includes memory load rate, disk bandwidth load rate, and the like. In addition to the above, the information table of the scheduling engine can also store or record interaction data generated in the interaction process of the scheduler, the executor, and the like.

[0073] Specifically, in one embodiment, the computing power network task scheduling method further includes the following steps: receiving microservice demand information to be deployed and task demand information to be scheduled sent by the business demand perception module; receiving network link information sent by the network resource perception module; receiving the computing power resource status of each computing node sent by the computing power resource perception module; and receiving cluster registration information sent by the registration information module; and storing the microservice demand information to be deployed, task demand information to be scheduled, network link information, computing power resource status of each computing node, cluster registration information, deployment strategy, and scheduling strategy into an information table.

[0074] Figure 4a , 4b Figures 4 and 4c are flowcharts illustrating the deployment, scheduling, and scaling processes according to an embodiment of the present invention. The scheduling engine implements capabilities such as microservice deployment, service request scheduling, and execution of dynamic scaling strategies through asynchronous operation. Figure 4a As shown, during the initial deployment of the application, the scheduling engine deploys this microservice application. Specifically, the scheduler invokes a deployment algorithm (the specific deployment algorithm can be customized) to obtain a deployment decision. The deployment decision includes, for example, the name of the cluster to be deployed to, and the number of instance replicas to be deployed in each cluster. Then, the executor executes this deployment decision. The executor sends the deployment decision and the corresponding microservice image to the target clusters. The Master nodes (i.e., primary nodes) on each target cluster can then execute the deployment, ultimately generating and running microservice instances on their respective clusters.

[0075] After the microservices are deployed, instances of the corresponding applications will be running on each cluster. For example... Figure 4b As shown, during service request scheduling, each client initiates a service request, which is stored in a request message cache queue. The scheduling engine then processes these requests. Specifically, the scheduler invokes a scheduling algorithm (the specific algorithm can be customized) to obtain a scheduling policy. This policy includes, for example, the name of the cluster to be scheduled and the number of requests each cluster will receive. The executor then executes this scheduling policy. Based on the scheduling policy, the executor asynchronously distributes the corresponding requests to the target cluster, and the microservice instances running on each cluster can then process these requests.

[0076] refer to Figure 4cIn the dynamic scaling process, the dynamic scaling module first transmits the scaling strategy formulated by the dynamic scaling module to the scheduling engine, and the scaling strategy includes, for example, the cluster name for performing scaling and the number of instance replicas required for scaling of the corresponding cluster, and then the executor processes the scaling strategy. Specifically, for the scaling decision, the executor transmits the scaling deployment decision and the corresponding microservice image to the target cluster, and then the Master node of each target cluster can perform the scaling deployment; for the scaling decision, the executor directly transmits the decision to the target cluster, and then the Master node of each target cluster can directly perform the replica scaling. In this embodiment, the scheduling engine needs to periodically input the data required for running of the dynamic scaling module to the dynamic scaling module, and the transmission period is not affected by the deployment / request period of the scheduling engine, but should be determined according to the needs of the dynamic scaling module, and the needs of the dynamic scaling module can be manually input by the user or automatically formulated by the system.

[0077] In the dynamic scaling process, the dynamic scaling module first transmits the scaling strategy formulated by the dynamic scaling module to the scheduling engine, and the scaling strategy includes, for example, the cluster name for performing scaling and the number of instance replicas required for scaling of the corresponding cluster, and then the executor processes the scaling strategy. Specifically, for the scaling decision, the executor transmits the scaling deployment decision and the corresponding microservice image to the target cluster, and then the Master node of each target cluster can perform the scaling deployment; for the scaling decision, the executor directly transmits the decision to the target cluster, and then the Master node of each target cluster can directly perform the replica scaling. In this embodiment, the scheduling engine needs to periodically input the data required for running of the dynamic scaling module to the dynamic scaling module, and the transmission period is not affected by the deployment / request period of the scheduling engine, but should be determined according to the needs of the dynamic scaling module, and the needs of the dynamic scaling module can be manually input by the user or automatically formulated by the system.

[0078] In order to better embody the present application, the operation process of the scheduler and the executor is abstracted as a modular plug-in, and the functions and effects of the plug-in corresponding to each step are specifically introduced in the order of execution.

[0079] Figure 5a The running mechanism diagram of the scheduling engine of an embodiment of the present application in the microservice deployment stage is shown in FIG. 1. Figure 5a In the deployment stage, the following plug-ins are applied: the microservice queue plug-in, the pre-screening plug-in, the screening plug-in, the no available plug-in, the deployment strategy plug-in, the reservation plug-in, the permission plug-in, the pre-binding plug-in, the binding plug-in, the binding extension port plug-in, the reservation unresponsive plug-in, and the cluster plug-in.

[0080] Specifically, first, the micro-service instances in the to-be-deployed queue are sorted by the "micro-service queue" plug-in, and only one "micro-service queue" plug-in can be started each time. Then, the "pre-filtering" plug-in is used to preprocess the relevant information of the micro-service, or to check certain conditions that the cluster or the Pod (i.e., the micro-service replica to be deployed) must satisfy. If the "pre-filtering" plug-in returns an error message, the deployment process will jump to the "no available" plug-in described below. The "filtering" plug-in is used to filter out the clusters that cannot perform micro-service deployment; for each cluster, the scheduler will call the "filtering" plug-in in the order of its configuration; if a "filtering" plug-in marks a cluster as unavailable, the scheduler will not call the remaining "filtering" plug-ins (if there are multiple filtering steps) for the cluster; if the "filtering" plug-in returns an error message, the deployment process will jump to the "no available" plug-in described below; in this filtering step, the scheduler needs to filter out the clusters that meet the conditions according to the principle that the demand of the to-be-scheduled micro-service matches the computing resources, storage resources, and network resources of the cluster.

[0081] The "no available" plug-in is called after the "filtering" stage, but only when there is no available cluster for the Pod; the "no available" plug-in will mark the cluster as "unschedulable", and then the remaining subsequent plug-ins will not be called; among them, there are two ways to handle the "unschedulable" state: 1) feedback to the platform that deployment is impossible / failure; 2) implement preemption to try to deploy the micro-service by preoccupying the resources of other micro-services. The "deployment strategy" plug-in calls the pre-configured deployment strategy and runs its core code, returning information such as the name of the cloud cluster deployed and the number of micro-service replicas deployed; the specific deployment algorithm can be customized according to the needs of the platform / user / application, and no special specification is made in the scheduling engine of the present application; in addition, the input parameters required for running the deployment algorithm are provided by the information table in the scheduling engine.

[0082] The "reservation" plug-in performs a reservation step, which is an informational extension step to inform the plug-in when the node reserves resources for the specified Pod; this step is performed before the executor actually binds the Pod to the cluster, and its existence is to prevent resource competition during the binding process in the scheduling engine; when the Pod is in the "reservation" state, it will trigger different plug-ins at the end of the executor's binding period according to the execution; specifically, the "reservation not responded" plug-in is triggered when the execution fails, and the "binding extension point" plug-in is triggered when the execution succeeds.

[0083] The "permission" plugin is invoked at the end of each Pod's scheduler execution cycle to prevent or delay the binding of the Pod. The "permission" plugin can do one of the following: 1) approve: once all "permission" plugins approve the Pod, the Pod will be sent to the executor for binding; 2) reject: if any "permission" plugin rejects the Pod, the Pod will be returned to the pending queue, which will trigger the "reservation not responded" plugin; 3) wait (with timeout): if a "permission" plugin returns a "wait" result, the Pod will be sent to an internal "waiting Pod" list, and the binding cycle of the Pod will be blocked directly until it is approved to continue; if a timeout occurs, the waiting state will become a rejection state, and the Pod will be returned to the pending queue and trigger the "reservation not responded" plugin.

[0084] The "pre-bind" plugin is used to perform all the work required before Pod binding; if any "pre-bind" plugin returns an error, the Pod will be rejected and returned to the pending queue. The "bind" plugin is used to bind the Pod to the cluster; the "bind" plugin will only be invoked after all "pre-bind" plugins have completed. The "bind extension point" plugin is an informational extension step; the "bind extension point" plugin is invoked after the Pod is successfully bound; this is the end of the binding cycle of the executor and can be used to clean up related resources.

[0085] The "reservation not responded" plugin is an informational extension step; if a Pod is "reserved" and then rejected in a subsequent step, the "reservation not responded" plugin will be notified; the "reservation not responded" plugin should be clear about the relevant state of the reserved Pod, and in addition, the "reservation not responded" can introduce further necessary processing mechanisms (such as related error handling mechanisms). The "cluster plugin" is an optional plugin; the "cluster plugin" is used to implement any operations within the cluster, such as Pod deployment and binding.

[0086] Figure 5b The running mechanism diagram of the scheduling engine of an embodiment of the present application in the request scheduling stage is shown in FIG. 5. In the request scheduling stage, the applied plugins specifically include the "request queue" plugin, the "check" plugin, the "no available" plugin, the "scheduling strategy" plugin, the "permission" plugin, the "match" plugin, the "match extension point" plugin, the "response failure" plugin, and the "cluster" plugin.

[0087] Specifically, first, the user service request (to-be-scheduled task) in the to-be-scheduled queue is sorted through the "request queue" plug-in, and only one "request queue" plug-in can be started each time. Further, the related information of the request is preprocessed through the "check" plug-in, and some conditions that must be met by the cluster for processing the request are checked; if the "check" plug-in returns an error information, or it is found that there is no cluster that can support the request, the scheduling process will jump to the "no available" plug-in.

[0088] The "no available" plug-in is called after the "check" process, but only when there is no feasible processing cluster for the request; the "no available" plug-in will mark the request as "unschedulable", and the remaining subsequent plug-ins will not be called; the processing mode triggered by the request process "no available" can be: directly feeding back the information that the request cannot be scheduled / scheduling fails to the platform.

[0089] The "scheduling strategy" plug-in calls the pre-configured scheduling strategy and runs its core code, and returns the information such as the name of the scheduled cloud cluster and the number of requests received by the cluster; specifically, the scheduling algorithm can be customized according to the needs of the platform / user / application, and no special designation is made in the present scheduling engine; in addition, the input parameters required for running the scheduling algorithm are provided by the information table in the scheduling engine.

[0090] The "permission" plug-in is called at the end of each request through the scheduler, which is used to prevent or delay the matching of the request. The "permission" plug-in can do one of the following operations: 1) approval: once all "permission" plug-ins approve the request, the request will be sent to the executor for matching (and then sent to the cluster specified by the scheduling strategy by the executor); 2) rejection: if any "permission" plug-in rejects the request, the request will be returned to the scheduling cache queue, and the "response failure" plug-in will be triggered; 3) wait (with timeout): if a "permission" plug-in returns a "wait" result, the request will be sent to an internal "waiting request" list, and the matching period of the request will be directly blocked (i.e. delayed sending) until it is approved to continue; if timeout occurs, the waiting state will become a rejection state, the request will be returned to the scheduling cache queue, and the "response failure" plug-in will be triggered.

[0091] The "match" plug-in is used to match the request and send it to the specified cluster. The "match extension point" plug-in is an informative extension step; the "match extension point" plug-in is called after the request is successfully matched and sent, which is the end of the execution process of the executor, and can be used to clean up related resources. The "response failure" plug-in is an informative extension step; the "response failure" plug-in should introduce further necessary error handling mechanisms to address requests that fail to be normally scheduled in the scheduling engine cycle. The "cluster" plug-in is an optional plug-in, and the "cluster plug-in" is used to implement Pod deployment and binding and any other operations performed within the cluster.

[0092] Figure 5c The running mechanism diagram of the scheduling engine of an embodiment of the present application in the scaling phase is shown in FIG. 5. In the dynamic scaling phase, the "record" plug-in, the "reservation" plug-in, the "permission" plug-in, the "pre-binding" plug-in, the "binding" plug-in, the "binding extension point" plug-in, the "reservation unresponsive" plug-in, and the "cluster" plug-in are applied. The "record" plug-in is used to record the scaling strategy and configuration information output by the dynamic scaling module to the scheduling engine. The "reservation" plug-in, the "permission" plug-in, the "pre-binding" plug-in, the "binding" plug-in, the "binding extension point" plug-in, the "reservation unresponsive" plug-in, and the "cluster" plug-in have the same functions as the corresponding plug-ins in the micro-service deployment phase, and thus the corresponding plug-ins in the micro-service deployment phase can be directly reused in the dynamic scaling phase.

[0093] In addition, three points need to be noted in the work of the scheduling engine in the scaling phase: 1) The scheduling engine periodically provides input parameters to the dynamic scaling module through the information table maintained internally, and the length of the cycle is generally based on the operation cycle of the dynamic scaling module or specified by the system or user; 2) In the scaling phase, the scheduling engine can perform deployment operations according to the deployment scheme provided by the dynamic scaling module (such as the cluster name for performing scaling, the number of instance replicas for scaling, etc.); 3) In the scaling phase, the scheduling engine only needs to directly send the specific scaling number to the cluster to be scaled, and the Master node directly performs the scaling operation.

[0094] The following content takes the AI intelligent transportation business as an example to further describe the processes of each phase of the scheduling engine. For example, first, deploy the business (i.e., the micro-service deployment phase) on the cluster: deploy all micro-services of the AI intelligent transportation business on the algorithm network platform, that is, the scheduling engine in the algorithm network platform selects multiple cloud clusters for deployment according to business requirements, algorithm network resources, etc. and calls the deployment algorithm. After the micro-service deployment is completed, these cloud clusters all run micro-service instances that can process the AI intelligent transportation business.

[0095] Afterwards, when users (e.g. connected vehicles, traffic management departments, etc.) participating in the traffic activities need to access the service, these users send service requests to the computing network platform, and then enter the request scheduling stage. In this stage, the scheduling engine schedules the service requests of the users to the clusters where the microservice instances are deployed, so that the user requests can be processed by the microservice instances. The scheduling engine will call the scheduling algorithm according to the specific requirements of these requests, the running state of each microservice, node computing network resource, etc. data information, select the corresponding cloud cluster, and then schedule these requests to make the user requests be processed by the microservice instances running on the cloud cluster.

[0096] During the running of the AI intelligent management application, the dynamic scaling module of the computing network platform periodically collects various types of business data and computing network resource data to determine whether the application is full or idle. When some microservice instances are idle, a scaling-down decision is made, and when the microservice instances are busy or even overloaded, a scaling-up decision is made. The scaling decision is sent to the scheduling engine, and the scheduling engine directly executes the corresponding decision, such as directly notifying the corresponding cluster to release and release the microservice instances of the AI intelligent traffic business when the scaling-down decision is executed, and directly redeploying a specified number of microservice instances of the AI intelligent traffic business to the corresponding cluster when the scaling-up decision is executed.

[0097] It can be found from the above embodiments that the computing network task scheduling method and system of the present application mainly includes the following four aspects:

[0098] (1) The overall architecture, workflow scheme and data interaction mechanism with other modules of the computing network task scheduling engine in the computing network platform. The centralized and modular task scheduling engine of the present application, as the core component of the computing network platform, undertakes the whole-process computing network task scheduling including microservice deployment, service request scheduling, dynamic scaling strategy execution, etc.

[0099] (2) The specific running steps of the computing network task scheduling engine in the microservice deployment stage. The present application realizes the ability of the cluster to process user service requests through microservice instances by deploying microservice instances on demand in the cloud cluster. It can be understood that the cloud cluster mentioned in the present application can be a private cloud cluster, a public cloud cluster (and can be a single cloud vendor or cross multiple cloud vendors) and a hybrid cloud cluster.

[0100] (3) The specific operation steps of the computing power network task scheduling engine in the request scheduling stage. After the micro-service deployment stage is completed, the cluster has micro-service instances running and can process corresponding service requests. The specific operation steps of the scheduling stage for user-initiated service requests are designed to realize that the scheduler and the executor use the scheduling algorithm / strategy to schedule the user-initiated service requests to the cluster running the corresponding micro-service instances according to the business requirements and resource status information for processing.

[0101] (4) The specific operation steps of the computing power network task scheduling engine in the expansion and contraction stage. The application provides necessary periodic data support for the dynamic expansion and contraction module, and undertakes the expansion and contraction strategy made by the dynamic expansion and contraction module, and accordingly performs expansion and contraction operations on the corresponding cluster to realize the on-demand increase or decrease of the number of micro-service instances.

[0102] The computing power network task scheduling method of the application adopts a centralized and modular computing power network task scheduling engine. The modular computing power network task scheduling engine not only connects the modules in the existing computing power network platform to realize plug-in flexible combination of the modules, and efficiently cooperates with each other to complete the entire scheduling work, but also includes various processes in the scheduling work such as micro-service deployment, service request scheduling, and dynamic expansion and contraction strategy execution, so that the entire type of scheduling tasks can be completed by one engine. In addition, the deployment steps are abstracted into a plug-in, which facilitates flexible combination and calling of the deployment steps, and facilitates multiple reuse of the same deployment step. Some steps also support the operation steps in the expansion and contraction stage. In addition to the above, the computing power network task scheduling method of the application faces the situation that the dynamic expansion and contraction module is used to increase / decrease the number of micro-service instances in the existing computing power network platform. The scheduling engine undertakes the expansion and contraction strategy output by the dynamic expansion and contraction module, and uses the executor and other components to complete the expansion and contraction operation specified by the strategy. Most of the steps of the scheduling engine in executing the expansion and contraction decision reuse some steps in the micro-service deployment stage, which improves the convenience in specific execution.

[0103] Correspondingly, the application also provides a computing power network task scheduling engine system, which includes a processor and a memory. The memory stores computer instructions. The processor is used to execute the computer instructions stored in the memory. When the computer instructions are executed by the processor, the system realizes the steps of the method of any one of the above embodiments.

[0104] In addition, the application also discloses a computer readable storage medium, which stores a computer program. When the program is executed by the processor, the steps of the method of any one of the above embodiments are realized.

[0105] The computing power network task scheduling method and system disclosed by the application first determine a deployment strategy based on a first cluster set and a deployment algorithm, and further deploy the to-be-deployed micro service after determining the deployment strategy; then determine a scheduling strategy based on a second cluster set and a scheduling algorithm, and complete scheduling of the to-be-scheduled task based on the scheduling strategy. In the method, deployment and scheduling belong to different process treatments, so that deployment and scheduling work can be completed through a scheduling engine, and the entire scheduling work can be completed through efficient mutual cooperation of each process; in the method, the deployment step independently executed with the scheduling can be reused multiple times, so that the to-be-deployed micro service is conveniently deployed; thus, the method and system improve the processing capacity of computing power task requests and reduce system calculation amount.

[0106] Those of ordinary skill in the art should understand that the example components, systems and methods described in connection with the embodiments disclosed herein can be implemented in hardware, software, or a combination thereof. The decision to implement in hardware or software depends on the specific application and design constraints imposed on the technological solution. Skilled professionals can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), appropriate firmware, a plug-in, a functional card, etc. When implemented in software, the elements of the present application are program or code segments used to perform the required tasks. The program or code segments can be stored in a machine-readable medium or transmitted through a data signal carried in a carrier wave on a transmission medium or communication link. The "machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, etc. The code segments can be downloaded via a computer network such as the Internet, an intranet, etc.

[0107] It should also be noted that the exemplary embodiments mentioned in the present application describe some methods or systems based on a series of steps or systems. However, the present application is not limited to the order of the above steps, that is, the steps can be performed in the order mentioned in the embodiments, or in an order different from the embodiments, or several steps can be performed simultaneously.

[0108] In the present application, the features described and / or exemplified for one embodiment can be used in the same way or in a similar way in one or more other embodiments, and / or in combination with or instead of the features of other embodiments.

[0109] The above merely provides the preferred embodiments of the present application, and is not used to limit the present application. For those skilled in the art, the present application can have various modifications and changes. Any modifications, equivalent replacements, improvements, etc. made within the principles and technical scope of the present application shall fall into the scope of the present application.

Claims

1. A method for scheduling tasks in a computing power network, characterized in that, The method is executed by a task scheduling engine, and the method comprises: obtaining a to-be-deployed microservice, a deployment algorithm, a to-be-deployed microservice requirement and cluster information, filtering a first cluster set matched with the to-be-deployed microservice based on the to-be-deployed microservice requirement and the cluster information; determining a deployment strategy based on the first cluster set and the deployment algorithm, the deployment strategy comprising a number of microservice replicas and a name of a deployment cluster, the deployment cluster belonging to the first cluster set, and deploying the to-be-deployed microservice based on the deployment strategy; obtaining a to-be-scheduled task, a scheduling algorithm and a to-be-scheduled task requirement, filtering a second cluster set from the deployment cluster set based on the to-be-scheduled task requirement; determining a scheduling strategy based on the second cluster set and the scheduling algorithm, the scheduling strategy comprising a name of a scheduling cluster and a number of task requests corresponding to each scheduling cluster, the scheduling cluster belonging to the second cluster set, and scheduling a request in the to-be-scheduled task based on the scheduling strategy.

2. The computing power network task scheduling method according to claim 1, characterized in that, The method further comprises: pre-filtering all clusters based on the to-be-deployed microservice requirement to obtain candidate clusters; filtering a first cluster matched with the to-be-deployed microservice based on computing power, storage resources and network resources of each candidate cluster to form a first cluster set.

3. The computing power network task scheduling method according to claim 1, characterized in that, The method further comprises: setting a reservation state for each deployment cluster corresponding to the to-be-deployed microservice; the reservation state comprising reservation success, reservation failure or pending approval; when the reservation state is reservation success, binding the to-be-deployed microservice and the corresponding deployment cluster, and sending a microservice image of the to-be-deployed microservice to the corresponding deployment cluster to complete deployment.

4. The computing power network task scheduling method according to claim 3, characterized in that, The method further comprises: checking whether the deployment cluster permits the corresponding to-be-deployed microservice to be bound based on a first permission plug-in; when permitting to be bound, the reservation state is reservation success; when refusing to be bound, the reservation state is reservation failure; when waiting to be bound, the reservation state is pending approval.

5. The computing power network task scheduling method according to any one of claims 1 to 4, characterized in that, The deployment algorithm and / or the scheduling algorithm is a custom algorithm.

6. The computing power network task scheduling method according to claim 5, characterized in that, The method further comprises: receiving an expansion and contraction strategy sent by a dynamic expansion and contraction module, the expansion and contraction strategy comprising an expansion and contraction cluster name and a number of microservice instance replicas that need to be expanded or contracted; performing a corresponding expansion operation or contraction operation based on the received expansion and contraction strategy.

7. The computing power network task scheduling method according to claim 1, characterized in that, The method further comprises: checking whether the scheduling cluster permits to be invoked based on a second permission plug-in; when permitting to be invoked, matching a task request of the to-be-scheduled task with the corresponding scheduling cluster; when refusing to be invoked, saving the task request of the to-be-scheduled task to a scheduling cache queue; when waiting to be invoked, saving the task request of the to-be-scheduled task to a waiting request list, and when a waiting time exceeds a preset time, saving the task request of the to-be-scheduled task to the scheduling cache queue.

8. The computing power network task scheduling method according to claim 1, characterized in that, The method further comprises: receiving the to-be-deployed microservice requirement information and the to-be-scheduled task requirement information sent by the service requirement perception module, receiving the network link information sent by the network resource perception module, receiving the computing power resource state of each computing node sent by the computing power resource perception module, and receiving the cluster registration information sent by the registration information module; storing the to-be-deployed microservice requirement information, the to-be-scheduled task requirement information, the network link information, the computing power resource state of each computing node, the cluster registration information, the deployment strategy and the scheduling strategy into an information table.

9. A computing power network task scheduling system, the system comprising a processor and a memory, characterized in that, The memory stores computer instructions, and the processor is configured to execute the computer instructions stored in the memory, so that the system implements the steps of the method according to any one of claims 1 to 8.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the steps of the method according to any one of claims 1 to 8.

Images