Node scheduling method and device based on network element microservice, equipment, medium and product

Abstract

The application discloses a node scheduling method and device based on network element microservices, equipment, medium and product. The method comprises: obtaining a service creation request, the service creation request carrying a first identifier indicating a network element microservice and a performance requirement parameter indicating a service performance requirement; selecting a target node from the nodes of the cluster based on the first identifier, the performance requirement parameter and the matching relationship data; wherein the matching relationship data represents the priority order of the CPU types corresponding to the set performance capacity level of the nodes of the cluster under different network element microservices. In this way, the container instance can be deployed based on the highest priority target node in the nodes of the cluster selected by the microservice, so that the most effective and suitable computing resource can be allocated for different businesses, the overall resource utilization of the cluster is improved, the power consumption is reduced, and the effect of reducing cost and increasing efficiency is realized.

Description

Technical Field

[0001] This application relates to microservice technology, and more particularly to a node scheduling method, apparatus, device, medium, and product based on network element microservices. Background Technology

[0002] In a microservices architecture, a service application consists of a large number of relatively simple, independent, lightweight, and interconnected microservices. Some microservices are designed to be elastically scalable, and a single microservice may contain multiple identical instances, achieving higher performance, elasticity, security, and robustness, making it very suitable for cloud computing paradigms. Microservices architecture reduces the complexity of developing and maintaining large-scale applications and accelerates application iteration, and has been widely adopted by numerous enterprise applications.

[0003] In related technologies, for cloud-native evolution, telecommunications network elements are being restructured from monolithic service architectures in the form of virtual machines into microservice architectures (low coupling, high cohesion). Different microservices are decoupled from each other and can be independently developed, deployed, and maintained. Compared to IT applications, telecommunications network elements are more complex. A single network element logically consists of multiple microservices handling different services, deployed through containerization. Different types of services have varying CPU computing power requirements. Although Docker and Kubernetes technologies support the construction and scheduling of container images for multiple architectures such as ARM and x86, the scheduling mechanism assumes that all nodes have equivalent CPU computing power. This results in the inability to accurately schedule containers to the optimal CPU architecture node when deploying applications in heterogeneous CPU clusters, leading to suboptimal container instance performance or low node CPU resource utilization. Summary of the Invention

[0004] In view of this, embodiments of this application provide a node scheduling method, apparatus, device, medium and product based on network element microservices, aiming to achieve optimized scheduling of network element microservice nodes, so as to improve the resource utilization of nodes in the cluster while ensuring business performance.

[0005] The technical solution of this application embodiment is implemented as follows:

[0006] In a first aspect, embodiments of this application provide a node scheduling method based on network element microservices, including:

[0007] Obtain a service creation request, the service creation request carrying a first identifier indicating the network element microservice and performance requirement parameters indicating the service performance requirements;

[0008] Based on the first identifier, the performance requirement parameters, and the matching relationship data, a target node is selected from the nodes of the cluster; wherein, the matching relationship data represents the priority ranking of the nodes of the cluster according to the CPU type with different performance capacity levels set under different network element microservices.

[0009] In the above scheme, the service creation request also carries a second identifier indicating the microservice type to which the network element microservice belongs, the matching relationship data includes a matching relationship table corresponding to each microservice type, and the step of selecting a target node from the nodes of the cluster based on the first identifier, the performance requirement parameters, and the matching relationship data includes:

[0010] Based on the second identifier, determine the target matching relationship table corresponding to the microservice type to which the network element microservice belongs;

[0011] Based on the first identifier and the target matching relationship table, query whether there is a matching network element microservice in the target matching relationship table. If so, select the node containing the CPU type with the highest priority from the CPU types under the matching network element microservice based on priority sorting according to the performance requirement parameters, and select it as the target node. If not, select the target node from the nodes of the cluster based on the preset scheduling algorithm.

[0012] The microservice types include one or more of the following: interface microservices, business microservices, management microservices, database microservices, and middleware microservices.

[0013] The method in the above scheme further includes:

[0014] The matching relationship data is generated using a static configuration method.

[0015] The method in the above scheme further includes:

[0016] The matching relationship data is generated or updated in a dynamically configured manner.

[0017] In the above scheme, generating or updating the matching relationship data in a dynamically configured manner includes:

[0018] Collect performance statistics, platform resource information, and CPU power consumption data of network element microservices;

[0019] Based on the collected performance statistics, platform resource information, and CPU power consumption data of the network element microservices, the priority ranking result of the CPU type under the set performance capacity level of the network element microservices is calculated.

[0020] Based on the priority ranking results of CPU types with set performance capacity levels under the network element microservices, generate or update the matching relationship data of the network element microservices.

[0021] In the above scheme, the calculation of the priority ranking result of CPU types under the set performance capacity level of the network element microservice based on the collected performance statistics, platform resource information, and CPU power consumption data of the network element microservice includes:

[0022] For the performance statistics of the network element microservices that fall into the same set performance capacity level, the service power consumption of nodes of each CPU type is calculated respectively. The service power consumption is generated based on the platform resource information and the CPU power consumption data.

[0023] Based on the service power consumption, the priority ranking result of the CPU type under the set performance capacity level of the network element microservice is obtained; wherein, the lower the service power consumption, the higher the corresponding priority level.

[0024] The method in the above scheme further includes:

[0025] In response to an alarm message indicating a fault in the current target node, a new target node is selected from the cluster nodes, excluding the current target node, based on the first identifier, the performance requirement parameters, and the matching relationship data.

[0026] The method in the above scheme further includes:

[0027] Based on the CPU architecture of the target node, select a container image from the image repository that matches the CPU architecture;

[0028] Based on the selected container image, deploy a container instance that provides the network element microservice on the target node.

[0029] Secondly, embodiments of this application provide a node scheduling device based on network element microservices, comprising:

[0030] The acquisition module is used to acquire a service creation request, wherein the service creation request carries a first identifier indicating the network element microservice and performance requirement parameters indicating the service performance requirements;

[0031] The selection module is used to select a target node from the nodes of the cluster based on the first identifier, the performance requirement parameters, and the matching relationship data; wherein, the matching relationship data represents the priority order of the nodes of the cluster corresponding to the CPU type with different performance capacity levels set under different network element microservices.

[0032] Thirdly, embodiments of this application provide an electronic device, including: a processor and a memory for storing a computer program capable of running on the processor, wherein, when the processor is used to run the computer program, it executes the steps of the method described in the first aspect of embodiments of this application.

[0033] Fourthly, embodiments of this application provide a computer storage medium storing a computer program, which, when executed by a processor, implements the steps of the method described in the first aspect of embodiments of this application.

[0034] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in the first aspect of embodiments of this application.

[0035] The technical solution provided in this application involves obtaining a service creation request, which carries a first identifier indicating the network element microservice and performance requirement parameters indicating the service performance requirements. Based on the first identifier, performance requirement parameters, and matching relationship data, a target node is selected from the nodes of the cluster. The matching relationship data represents the priority ranking of the cluster nodes according to the CPU type for different network element microservices with set performance capacity levels. In this way, the highest priority target node in the cluster can be selected based on the microservice to deploy container instances. This allows for the allocation of the most effective and suitable computing resources to different services, ensuring service performance while improving the overall resource utilization of the cluster, reducing power consumption, and ultimately achieving cost reduction and efficiency improvement. Attached Figure Description

[0036] Figure 1 This is a schematic diagram of the K8s scheduling process in related technologies;

[0037] Figure 2 This is a flowchart illustrating the node scheduling method based on network element microservices in an embodiment of this application.

[0038] Figure 3 This is a schematic diagram illustrating the process of dynamically generating the matching relationship table in one application embodiment of this application;

[0039] Figure 4 This is a schematic diagram of the end-to-end network element scheduling process in one application embodiment of this application;

[0040] Figure 5 This is a schematic diagram of the node scheduling device based on network element microservices in an embodiment of this application;

[0041] Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0042] The present application will now be described in further detail with reference to the accompanying drawings and embodiments.

[0043] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0044] Among related technologies, Kubernetes (K8s), as the de facto standard in the industry's container orchestration field, is the cornerstone of cloud-native applications. The smallest unit in a K8s cluster is a Pod (container repository), and the complete lifecycle of a Pod is controlled by a series of scheduling policies. These K8s scheduling policies are calculated by the Scheduler component using corresponding algorithms. For example... Figure 1 As shown, the scheduling process is divided into three stages: node pre-selection, node optimization, and node selection. Node pre-selection checks each node based on a series of pre-selection rules, excluding nodes that do not meet the conditions; node optimization prioritizes the pre-selected nodes; and node selection chooses the node with the highest priority from the priority ranking results to run the Pod.

[0045] While Kubernetes supports scheduling and deployment of containers across multiple architectures for heterogeneous CPU clusters—for example, storing various container images corresponding to different CPU architectures in the image repository of the scheduling management platform, and the Kubernetes scheduler performing load balancing according to the above scheduling process, automatically pulling and deploying container images that match the CPU architecture type of the current node after node selection—the scheduling mechanism assumes that all nodes have equivalent CPU computing power. This results in the inability to accurately schedule containers to the optimal CPU architecture node when deploying applications on heterogeneous CPU clusters, leading to suboptimal container instance performance or low node CPU resource utilization.

[0046] Based on this, this application provides a node scheduling method for sensing network element microservice services and optimizing the scheduling of nodes in a heterogeneous cluster, aiming to improve the overall resource utilization of the cluster and reduce power consumption while ensuring service performance.

[0047] like Figure 2 As shown, this application provides a node scheduling method based on network element microservices, applied to a scheduling platform device. The method includes:

[0048] Step 201: Obtain a service creation request, wherein the service creation request carries a first identifier indicating the network element microservice and performance requirement parameters indicating the service performance requirements.

[0049] For example, the scheduling platform device can be an electronic device that deploys a Kubernetes scheduler, which can discover service creation requests through the Kubernetes watch-list mechanism. For example, this service creation request can be initiated by a user through the MANO (NFV management and orchestration) platform to the Kubernetes API server, and discovered by the Kubernetes scheduler based on the Kubernetes watch-list mechanism, where NFV (Network Function Virtualization) is the virtualization of network functions.

[0050] Here, network element microservices can be understood as communication microservices, which means refactoring core network elements from a monolithic business architecture in the form of virtual machines into a microservice architecture (low coupling, high cohesion). Different microservices are decoupled from each other and can be independently developed, deployed, operated and maintained, thereby better meeting the cloud service paradigm.

[0051] Step 202: Based on the first identifier, the performance requirement parameters, and the matching relationship data, select a target node from the nodes of the cluster; wherein, the matching relationship data represents the priority order of the nodes of the cluster corresponding to the CPU type with different performance capacity levels set under different network element microservices.

[0052] Understandably, since the matching relationship data can characterize the priority ranking of the CPU types of the cluster nodes corresponding to different network element microservices with different performance capacity levels, the highest priority node can be selected from the cluster nodes based on the first identifier and performance requirement parameters as the target node. This allows the network element microservices to be scheduled to the nodes corresponding to the most suitable CPU types, allocating the most effective and suitable computing resources to different services. This ensures service performance while improving the overall resource utilization of the cluster, reducing power consumption, and ultimately achieving the effect of cost reduction and efficiency improvement.

[0053] Here, the first identifier can be the identity identifier of the network element microservice, for example, the name of the network element microservice; the performance requirement parameter can characterize the performance capacity of the network element microservice, for example, the number of users the network element microservice can support. Thus, based on the first identifier and the performance requirement parameter, the target node providing the network element microservice can be selected from the matching relationship data.

[0054] For example, to improve the scheduling efficiency of the scheduling platform device in scenarios with a large number of microservices, the service creation request also carries a second identifier indicating the microservice type to which the network element microservice belongs. The matching relationship data includes a matching relationship table corresponding to each microservice type. The step of selecting a target node from the nodes of the cluster based on the first identifier, the performance requirement parameters, and the matching relationship data includes:

[0055] Based on the second identifier, determine the target matching relationship table corresponding to the microservice type to which the network element microservice belongs;

[0056] Based on the first identifier and the target matching relationship table, query whether there is a matching network element microservice in the target matching relationship table. If so, select the node containing the CPU type with the highest priority from the CPU types under the matching network element microservice based on priority sorting according to the performance requirement parameters, and select it as the target node. If not, select the target node from the nodes of the cluster based on the preset scheduling algorithm.

[0057] The microservice types include one or more of the following: interface microservices, business microservices, management microservices, database microservices, and middleware microservices.

[0058] In this embodiment, network element microservices can be categorized into interface microservices, business microservices, management microservices, database microservices, and middleware microservices based on their different functionalities. Interface microservices handle north-south communication within the network element, such as AMF (Access and Mobility Management Function), NGAP (Next Generation Application Protocol), and HTTP / 2. Business microservices handle core business logic, such as AMF access management and mobility management. Management microservices handle network element management, monitoring, and maintenance, such as Prometheus. Database microservices manage network element status and business context databases, such as Redis. Middleware microservices provide internal support for the network element, such as Kafka. Each type of microservice contains multiple microservices, and each microservice can be implemented by one or more Pods.

[0059] For example, the cluster in this application embodiment can be a heterogeneous CPU cluster. For instance, it can be a heterogeneous cluster composed of servers with different architectures, models, and generations, such as x86 (Intel, Hygon) and ARM (Kunpeng, Everest). The CPU type of the nodes in the cluster can be determined based on the CPU architecture, model, etc. For example, the matching relationship table corresponding to the microservice type can be shown in Table 1 below:

[0060] Table 1

[0061]

[0062] Understandably, the matching table can be set at the microservice level, prioritizing all available CPU types based on the same performance capacity. This allows the scheduling management platform to determine the target matching table for the microservice type of the network element microservice from the matching data based on the second identifier. When a matching network element microservice exists in the target matching table, the platform can select the node containing the highest-priority CPU type under the corresponding performance capacity based on performance requirement parameters. This ensures that nodes with higher-priority CPU types are scheduled more frequently, resulting in more precise deployment of network element microservices. Thus, the default scheduling mechanism of the Kubernetes cluster is enhanced by introducing a microservice type-based scheduling method. This prioritizes different container applications to the most suitable CPU type, making application deployment more accurate, ensuring network element service performance while improving CPU resource efficiency and reducing power consumption.

[0063] It should be noted that if, based on the first identifier and the target matching relationship table, no matching network element microservice is found in the target matching relationship table, the target node can be selected from the nodes of the cluster based on a preset scheduling algorithm. For example, the default scheduling mechanism of the K8s cluster can be used to select the target node, thereby ensuring compatibility with the original scheduling algorithm. When the enhancement mechanism in this application embodiment is closed or not in effect, the native scheduling result of K8s can be used.

[0064] Exemplarily, the method further includes:

[0065] The matching relationship data is generated using a static configuration method.

[0066] It should be noted that the matching relationship data in this application embodiment can be generated using a static configuration method. For example, in the initial stage of cluster establishment, a matching relationship table between microservices and CPU types can be statically configured.

[0067] In one application example, taking the access management microservice in the AMF network element service class as an example, the matching relationship between microservices and CPU types is shown in Table 2 below:

[0068] Table 2

[0069]

[0070] Referring to Table 2, taking the access management microservice in the AMF network element service category as an example, based on the same microservice carrying the same number of users, such as 1 million users, to ensure consistent performance (capacity, latency, etc.) of the microservice, priority sorting under different CPU types is statically configured. It should be noted that this method is suitable for the initial stage of cluster establishment when the network element has not yet undertaken any services.

[0071] Exemplarily, the method further includes:

[0072] The matching relationship data is generated or updated in a dynamically configured manner.

[0073] It should be noted that the matching relationship data in this application embodiment can be generated or updated dynamically. For example, after the network element service is launched, the most suitable CPU type for different microservices can be dynamically analyzed by combining platform-level CPU resource information and service performance statistics and other monitoring data, thereby generating or updating the matching relationship data.

[0074] For example, generating or updating the matching relationship data in a dynamically configured manner includes:

[0075] Collect performance statistics, platform resource information, and CPU power consumption data of network element microservices;

[0076] Based on the collected performance statistics, platform resource information, and CPU power consumption data of the network element microservices, the priority ranking result of the CPU type under the set performance capacity level of the network element microservices is calculated.

[0077] Based on the priority ranking results of CPU types with set performance capacity levels under the network element microservices, generate or update the matching relationship data of the network element microservices.

[0078] For example, the calculation of the priority ranking result of CPU types under the set performance capacity level of the network element microservice based on the collected performance statistics, platform resource information, and CPU power consumption data of the network element microservice includes:

[0079] For the performance statistics of the network element microservices that fall into the same set performance capacity level, the service power consumption of nodes of each CPU type is calculated respectively. The service power consumption is generated based on the platform resource information and the CPU power consumption data.

[0080] Based on the service power consumption, the priority ranking result of the CPU type under the set performance capacity level of the network element microservice is obtained; wherein, the lower the service power consumption, the higher the corresponding priority level.

[0081] Figure 3 A schematic diagram illustrating the process of dynamically generating a matching relationship table in an application embodiment is shown. For example... Figure 3 As shown, the dynamic generation of the matching relationship table includes: data collection, data analysis, and matching relationship table generation, which are described in detail below:

[0082] I. Data Collection:

[0083] For example, data collection includes the following three parts:

[0084] 1) Obtain performance statistics of network element microservices from the network management OMC (Operations and Maintenance Center);

[0085] 2) Obtain platform resource information corresponding to the network element microservice from NFVO, such as obtaining Kubernetes platform resource information such as Pod CPU corresponding to the network element microservice;

[0086] 3) Obtain the server's CPU power consumption data from PIM (Physical Infrastructure Manager).

[0087] II. Data Analysis:

[0088] Here, based on the CPU resource, power consumption, and performance statistics obtained from data collection, we can analyze the operation of different microservices and their associated Pods under different CPU architectures. For example, based on a set performance capacity level, we can calculate the service power consumption of nodes with different CPU types.

[0089] For example, taking the AMF access management microservice that supports 1 million users as an example for analysis, the total power consumption of the microservice is calculated based on the number of CPU cores required by the Pod under different CPU architecture types and the power consumption of a single core at base frequency: power consumption of access management microservice = x(N)*y(N), where x(N) and y(N) are the number of CPU cores occupied by the Pod under different architectures and the power consumption value of a single core at base frequency, respectively.

[0090] In one application example, the calculation of service power consumption will be illustrated using the following four CPU types as examples:

[0091] 1) x86 Intel 6625: Service power consumption = x1 * y1, where x1 is the number of CPU cores required by Intel 6625, and y1 is the power consumption of Intel 6625 at single-core base frequency;

[0092] 2) x86 Hygon 7380: Service power consumption = x2*y2, where x2 is the number of CPU cores required by Hygon 7380, and y2 is the power consumption of Hygon 7380 at single-core base frequency;

[0093] 3) ARM Kunpeng 920: Power consumption = x3*y3, where x3 is the number of CPU cores required by Kunpeng 920, and y3 is the power consumption of Kunpeng 920 at single-core base frequency;

[0094] 4) ARM Everest 8155: Power consumption = x4*y4, where x4 is the number of CPU cores required for Everest 8155, and y4 is the power consumption of Everest 8155 at a single core base frequency;

[0095] It should be noted that the values ​​of x(N) and y(N) can change dynamically. Under the same capacity, they can gradually stabilize through iterative calculations. For example, by collecting data within a set time period and performing iterative calculations, a stable service power consumption can be obtained.

[0096] III. Generation of Matching Relationship Table:

[0097] Based on the above data analysis, priority ranking is performed. Under the premise of ensuring equal performance of microservices, the lower the power consumption of a service, the higher its priority level, thereby generating or updating the matching relationship table.

[0098] It should be noted that the dynamic matching table can generate multiple tables based on different performance levels, and supports dynamically adjusting node priorities according to business load and platform resource usage, ensuring network element performance and improving resource utilization efficiency; among them, the dynamic matching table has higher priority than the static table. For example, as the server node resources in the Kubernetes cluster change, such as adding a new type of server, the statistics will change, and the matching table will also be dynamically adjusted accordingly.

[0099] Exemplarily, the method further includes:

[0100] In response to an alarm message indicating a fault in the current target node, a new target node is selected from the cluster nodes, excluding the current target node, based on the first identifier, the performance requirement parameters, and the matching relationship data.

[0101] It should be noted that, in response to an alarm message indicating that the current target node is faulty, the scheduling platform device can reselect a node from the cluster nodes other than the current target node as a new target node based on the first identifier, the performance requirement parameters, and the matching relationship data. This automatically switches to the secondary node and updates the priority ranking result, thereby ensuring the availability of the application and the continuity and reliability of the business.

[0102] Exemplarily, the method further includes:

[0103] Based on the CPU architecture of the target node, select a container image from the image repository that matches the CPU architecture;

[0104] Based on the selected container image, deploy a container instance that provides the network element microservice on the target node.

[0105] It is understandable that the scheduling platform device can select a container image that matches the CPU architecture of the target node from the image repository, and deploy container instances on the target node based on the selected container image, thereby providing the corresponding network element microservices.

[0106] The present application will now be described in further detail with reference to an application embodiment.

[0107] This application example optimizes the default scheduling function of Kubernetes by adding a scheduling algorithm based on microservice type matching in the node selection stage. The optimized end-to-end network element scheduling process is as follows: Figure 4 As shown.

[0108] Users initiate service creation requests from the MANO system to the Kubernetes API server. The Kubernetes scheduler discovers resource scheduling requests through the Kubernetes watchlist mechanism and performs node selection, node optimization, and node selection processes based on the scheduling parameters provided by the user. In the node optimization step, a microservice-based optimization algorithm is used to prioritize nodes, ultimately selecting the node with the highest priority in the node selection step. During node optimization, matching queries are performed sequentially according to microservice type and microservice order. If the query is successful, the matching table takes effect; otherwise, the native Kubernetes scheduling result is used. Different microservices can be assigned to nodes with different CPU architectures, and the corresponding container images are pulled based on the CPU architecture of the node. Automatic switching to other heterogeneous nodes is also supported.

[0109] In this application example, the scheduling optimization algorithm based on microservice type is an enhancement on the original K8s scheduling mechanism, so it does not affect the original scheduling algorithm; if this mechanism is closed or not in effect, the original K8s scheduling result will be used by default.

[0110] To implement the method of the embodiments of this application, the embodiments of this application also provide a node scheduling device based on network element microservices. This node scheduling device based on network element microservices corresponds to the above-mentioned node scheduling method based on network element microservices. The steps in the above-mentioned node scheduling method embodiment based on network element microservices are also fully applicable to this node scheduling device embodiment based on network element microservices.

[0111] like Figure 5 As shown, the node scheduling device based on network element microservices includes an acquisition module 501 and a selection module 502. The acquisition module 501 is used to acquire a service creation request, which carries a first identifier indicating the network element microservice and performance requirement parameters indicating service performance requirements. The selection module 502 is used to select a target node from the nodes of the cluster based on the first identifier, the performance requirement parameters, and matching relationship data. The matching relationship data represents the priority ranking of the nodes in the cluster according to the CPU type corresponding to different performance capacity levels set under different network element microservices.

[0112] For example, the selection module 502 is specifically used for:

[0113] Based on the second identifier, determine the target matching relationship table corresponding to the microservice type to which the network element microservice belongs;

[0114] Based on the first identifier and the target matching relationship table, query whether there is a matching network element microservice in the target matching relationship table. If so, select the node containing the CPU type with the highest priority from the CPU types under the matching network element microservice based on priority sorting according to the performance requirement parameters, and select it as the target node. If not, select the target node from the nodes of the cluster based on the preset scheduling algorithm.

[0115] The microservice types include one or more of the following: interface microservices, business microservices, management microservices, database microservices, and middleware microservices.

[0116] For example, the node scheduling device based on network element microservices further includes: a first configuration module 503, used to generate the matching relationship data in a static configuration manner.

[0117] For example, the node scheduling device based on network element microservices further includes: a second configuration module 504, used to generate or update the matching relationship data in a dynamically configured manner.

[0118] For example, the second configuration module 504 is specifically used for:

[0119] Collect performance statistics, platform resource information, and CPU power consumption data of network element microservices;

[0120] Based on the collected performance statistics, platform resource information, and CPU power consumption data of the network element microservices, the priority ranking result of the CPU type under the set performance capacity level of the network element microservices is calculated.

[0121] Based on the priority ranking results of CPU types with set performance capacity levels under the network element microservices, generate or update the matching relationship data of the network element microservices.

[0122] For example, the calculation of the priority ranking result of CPU types under the set performance capacity level of the network element microservice based on the collected performance statistics, platform resource information, and CPU power consumption data of the network element microservice includes:

[0123] For the performance statistics of the network element microservices that fall into the same set performance capacity level, the service power consumption of nodes of each CPU type is calculated respectively. The service power consumption is generated based on the platform resource information and the CPU power consumption data.

[0124] Based on the service power consumption, the priority ranking result of the CPU type under the set performance capacity level of the network element microservice is obtained; wherein, the lower the service power consumption, the higher the corresponding priority level.

[0125] For example, the selection module 502 is also used for:

[0126] In response to an alarm message indicating a fault in the current target node, a new target node is selected from the cluster nodes, excluding the current target node, based on the first identifier, the performance requirement parameters, and the matching relationship data.

[0127] For example, the node scheduling device based on the network element microservice further includes: an image determination module 505 and a container deployment module 506. The image determination module 505 is used to select a container image that matches the CPU architecture of the target node from the image repository; the container deployment module 506 is used to deploy a container instance that provides the network element microservice on the target node based on the selected container image.

[0128] In practical applications, the acquisition module 501, selection module 502, first configuration module 503, second configuration module 504, image determination module 505, and container deployment module 506 can be implemented by the processor in the node scheduling device based on network element microservices. Of course, the processor needs to run the computer program in memory to implement its functions.

[0129] It should be noted that the node scheduling device based on network element microservices provided in the above embodiments is only illustrated by the division of the above-described program modules when performing node scheduling based on network element microservices. In practical applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the device can be divided into different program modules to complete all or part of the processing described above. In addition, the node scheduling device based on network element microservices provided in the above embodiments and the node scheduling method embodiments based on network element microservices belong to the same concept, and the specific implementation process is detailed in the method embodiments, which will not be repeated here.

[0130] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiments of this application, the embodiments of this application also provide an electronic device. Figure 6 The diagram shows only an exemplary structure of the electronic device, not the entire structure; implementation is possible as needed. Figure 6 The structure shown may be part or all of the structure.

[0131] like Figure 6As shown, the electronic device 600 provided in this application embodiment includes: at least one processor 601, a memory 602, a user interface 603, and at least one network interface 604. The various components in the electronic device 600 are coupled together via a bus system 605. It can be understood that the bus system 605 is used to implement communication between these components. In addition to a data bus, the bus system 605 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 6 The general designated all buses as Bus System 605.

[0132] The user interface 603 may include a monitor, keyboard, mouse, trackball, click wheel, buttons, touchpad, or touch screen.

[0133] The memory 602 in this embodiment is used to store various types of data to support the operation of the electronic device. Examples of such data include any computer program used to operate on the electronic device.

[0134] The node scheduling method based on network element microservices disclosed in this application can be applied to or implemented by processor 601. Processor 601 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the node scheduling method based on network element microservices can be completed by integrated logic circuits in the hardware of processor 601 or by instructions in software form. The processor 601 can be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 601 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules can be located in a storage medium, specifically memory 602. Processor 601 reads information from memory 602 and, in conjunction with its hardware, completes the steps of the node scheduling method based on network element microservices provided in the embodiments of this application.

[0135] In an exemplary embodiment, the electronic device may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned method.

[0136] It is understood that memory 602 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), Sync Link Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memories described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable types of memories.

[0137] In an exemplary embodiment, this application also provides a computer storage medium, specifically a computer-readable storage medium, such as a memory 602 storing a computer program. This computer program can be executed by the processor 601 of the electronic device 600 to complete the steps described in the method of this application embodiment. The computer-readable storage medium can be a ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM, etc.

[0138] In an exemplary embodiment, this application also provides a computer program product, including a computer program that can be executed by a processor 601 of an electronic device 600 to perform the steps described in the method of this application embodiment.

[0139] It should be noted that terms such as "first" and "second" are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0140] Furthermore, the technical solutions described in the embodiments of this application can be combined arbitrarily without conflict.

[0141] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for node scheduling based on network element microservices, characterized in that, The method comprises: obtaining a service creation request, the service creation request carrying a first identifier indicating a network element microservice, a second identifier indicating a microservice type to which the network element microservice belongs, and a performance requirement parameter indicating a service performance requirement; based on the first identifier, the performance requirement parameter, and matching relationship data, selecting a target node from nodes of a cluster; wherein the matching relationship data represents a priority order of CPU types corresponding to a set performance capacity level of different network element microservices of the nodes of the cluster, and includes a matching relationship table corresponding to each microservice type; the selecting a target node from nodes of a cluster based on the first identifier, the performance requirement parameter, and matching relationship data comprises: determining a target matching relationship table corresponding to the microservice type to which the network element microservice belongs based on the second identifier; based on the first identifier and the target matching relationship table, querying whether there is a matching network element microservice in the target matching relationship table, if yes, selecting, based on the performance requirement parameter, a node in which a CPU type with the highest priority in the CPU types under the matching network element microservice as the target node based on the priority order; if not, selecting the target node from the nodes of the cluster based on a preset scheduling algorithm.

2. The method of claim 1, wherein, The microservice type comprises one or more of the following: an interface microservice, a business microservice, a management microservice, a database microservice, and an intermediate microservice.

3. The method of claim 1, wherein, The method further comprises: generating the matching relationship data in a static configuration manner.

4. The method of claim 1, wherein, The method further comprises: generating or updating the matching relationship data in a dynamic configuration manner.

5. The method of claim 4, wherein, The generating or updating the matching relationship data in a dynamic configuration manner comprises: collecting performance statistical data of a network element microservice, platform resource information, and CPU power consumption data; based on the collected performance statistical data of the network element microservice, the platform resource information, and the CPU power consumption data, calculating a priority order result of CPU types corresponding to a set performance capacity level of the network element microservice; based on the priority order result of the CPU types corresponding to the set performance capacity level of the network element microservice, generating or updating the matching relationship data of the network element microservice.

6. The method of claim 5, wherein, The calculating a priority order result of CPU types corresponding to a set performance capacity level of the network element microservice based on the collected performance statistical data of the network element microservice, the platform resource information, and the CPU power consumption data comprises: for the performance statistical data of the network element microservice falling into the same set performance capacity level, calculating service power consumptions of nodes of each CPU type respectively, the service power consumptions being generated based on the platform resource information and the CPU power consumption data; based on the service power consumptions, obtaining the priority order result of the CPU types corresponding to the set performance capacity level of the network element microservice; wherein the lower the service power consumption, the higher the corresponding priority level.

7. The method of claim 1, wherein, The method further comprises: in response to alarm information indicating that a current target node is faulty, reselecting, based on the first identifier, the performance requirement parameter, and the matching relationship data, a node other than the current target node as a new target node from nodes of a cluster.

8. The method according to claim 1 or 7, characterized in that The method further comprises: selecting a container image matching the CPU architecture of the target node in a mirror repository based on the CPU architecture; deploying a container instance providing the network element microservice on the target node based on the selected container image. 9.A node scheduling apparatus based on network element microservice, characterized in that, The method comprises the steps of: obtaining a service creation request, the service creation request carrying a first identifier indicating a network element microservice, a second identifier indicating a microservice type to which the network element microservice belongs, and a performance requirement parameter indicating a service performance requirement; selecting a target node from nodes of a cluster based on the first identifier, the performance requirement parameter, and matching relationship data, wherein the matching relationship data represents a priority order of CPU types corresponding to different network element microservice performance capacity levels of the nodes of the cluster, and comprises a matching relationship table corresponding to each microservice type; the selection module is specifically configured to: determine a target matching relationship table corresponding to the microservice type to which the network element microservice belongs based on the second identifier; query whether there is a matching network element microservice in the target matching relationship table based on the first identifier and the target matching relationship table, if yes, select a node in which a CPU type with the highest priority in the CPU types under the matching network element microservice as the target node based on the priority order; and if not, select the target node from the nodes of the cluster based on a preset scheduling algorithm.

10. An electronic device, comprising: The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 8. The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 8. The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 8.

11. A computer storage medium having stored thereon a computer program, characterized in that ​ 12. A computer program product comprising a computer program, characterized in that, ​

Images