A congestion game-based adaptive management method for microservice resources in a cloud-native architecture

Abstract

The present invention relates to a microservice resource adaptive management method based on congestion game under a cloud native architecture, and belongs to the technical field of dynamic optimization configuration of microservice resources. The method can dynamically adjust various types of fine-grained resources. First, the DeathStarBench benchmark test program is run on the Docker platform to simulate real application scenarios; secondly, the "resource-performance" data of all microservice nodes on the critical path of the application are collected; then, based on the semi-supervised meta-learning mechanism, tasks are self-generated on the unlabeled data machine, and the correlation and difference between tasks are quickly learned, and the learned knowledge is generalized to the constructed classifier, and parameters are fine-tuned through labeled data sets to accurately predict the performance of microservice nodes; finally, the Nash equilibrium theory in game theory is used to optimize the resource allocation strategy, so as to achieve the purpose of improving the resource utilization of microservice nodes while meeting the end-to-end service quality of tasks.

Description

Technical Field

[0001] The present invention relates to a microservice resource adaptive management method based on congestion game under a cloud native architecture, belonging to the technical field of dynamic optimization configuration of microservice resources. Background Art

[0002] As an elastic, reliable and dynamic service provider, cloud computing provides computing resources based on CPU, GPU, RAM, disk I / O and network bandwidth. However, with the explosive growth of application types, cloud native, a new generation of cloud technology architecture that focuses on agile iteration, on-demand allocation and elastic scaling, has gradually replaced the original monolithic cloud and is being accepted by more industries. Different from traditional cloud computing, cloud native has two major characteristics, namely containerization and microservices, which decouple complex monolithic applications into multiple independent, modular and lightweight microservice nodes to reduce the interdependence between modules, and use lightweight containers as the main operating environment to achieve environmental isolation and cluster resource management. It also improves the concurrency and robustness of its development and deployment, thereby effectively shortening the software development cycle.

[0003] Current data centers face inherent limitations in hardware resources, operating costs, and energy supply. Therefore, the strategy of ensuring quality of service (QoS) by simply increasing resource investment is not sustainable. In addition, microservice applications have significant differences in their demands for various resources. In a resource-sharing environment, multiple microservice nodes face competition for limited resources such as CPU, memory, and I / O bandwidth. Current resource scheduling algorithms often ignore the negative impact of resource competition on system performance, resulting in system performance degradation when multiple microservice nodes request resources at the same time. To ensure the QoS of microservice applications, it is necessary to accurately capture and fully meet their specific demands for various resources. Therefore, if the resources of each microservice node can be adaptively allocated and managed efficiently, it can not only significantly improve the overall performance and resource utilization of the system, but also be crucial to ensuring the end-to-end QoS of the application.

[0004] However, it is challenging to effectively guarantee the end-to-end QoS of tasks and improve the resource utilization of microservice nodes under the cloud-native architecture. This is reflected in the following two aspects: First, different microservices have different requirements for computing resources, loads, and QoS, and there are many types of resources with significant functional differences. Microservice architectures usually contain multiple different types of services, each of which may have different resource requirements and characteristics. Some of these microservices are CPU-sensitive, while others are memory-sensitive, resulting in an unbalanced use of resources. To manage and balance these diverse service characteristics, ensure that microservice nodes can share system resources, and that the abundant resources are fully and effectively utilized, it is necessary to clarify the resource requests of each microservice, which poses great difficulties for resource allocation. Second, the performance tracking and resource allocation mode of a single node lacks consideration for the overall QoS of the task. Currently, resource management in most cloud-native architectures is distributed, that is, each microservice node independently requests resources that can adapt to its own latency from the resource pool without considering the performance of other nodes. However, due to the loose coupling and fine-grained nature of microservices, the execution of a task (such as e-commerce transactions, streaming media services, etc.) may require the participation of hundreds or even thousands of microservice units. The serial, parallel, remote call and other cooperative and competitive relationships between these massive nodes will inevitably affect the overall QoS of the task. Therefore, when allocating resources, if only single-node performance optimization is involved and the dependency properties between nodes are ignored, the overall QoS of the task and the resource allocation strategy may not reach the global optimum.

[0005] In the prior art, there are two main methods for microservice resource management: one is a microservice adaptive resource allocation method based on neural networks, and the other is elastic scaling management of microservice resources based on resource request characteristics.

[0006] "Microservice resource allocation method based on combined neural network", Chinese invention patent (CN114968563A), 2022, based on combined neural network to identify the dependencies of microservices and the dynamic characteristics of cloud environment, predict and locate microservices that cause performance defaults, and lock their restricted bottleneck resources, and allocate resources for bottleneck resources to maximize the resource utilization of data centers while reducing performance defaults. However, in complex dynamic environments, due to the high computational overhead and lack of real-time performance of combined neural networks, it is difficult to quickly respond to sudden loads or nonlinear changes in resource demand.

[0007] "An elastic scaling method and system for cloud server resource management", Chinese invention patent (CN117076106A), 2023, generates a load pressure line by random gradient descent and offset, judges the load state of the load data based on the load pressure line, and selects an applicable elastic scaling method according to the judgment result. However, they lack the ability to adapt to dynamically changing environments, which affects the accuracy and real-time performance of elastic scaling.

[0008] "Topology-aware microservice application scheduling method and application in cloud environment", Chinese invention patent (CN114625500A), 2022, based on the summary information of the cluster, a multi-dimensional resource management model is constructed for the working nodes in the cluster. Subsequently, the working nodes are pre-deployed using the summary information of the microservice application and the multi-dimensional resource management model. In this process, suitable scheduling nodes are selected based on the resource balancing principle. Then, by referring to the topological structure diagram of the microservice application and the scheduling node, the scheduling scheme of the microservice application is obtained, and the corresponding scheduling tasks are performed according to this scheme. However, they rely too much on the summary information of the cluster and microservices, resulting in a decrease in resource utilization and scheduling efficiency.

[0009] Game theory has been widely used in the field of resource management in recent years. However, there is no report on the performance prediction of microservice nodes based on semi-supervised meta-learning, and the scheme of maximizing the resource utilization of microservice nodes under the premise of meeting the end-to-end service quality by combining congestion game. Therefore, the present invention takes the response time of service requests as QoS, and proposes a microservice resource adaptive management method based on congestion game under cloud native architecture, so as to improve the resource utilization of microservice nodes while meeting the end-to-end service quality of tasks. Summary of the invention

[0010] The main purpose of the present invention is to provide a microservice resource adaptive management method based on congestion game under a cloud native architecture, aiming to solve the technical problem that it is difficult to ensure the end-to-end service quality of tasks and the resource utilization of microservice nodes under a cloud native architecture.

[0011] To achieve the above objectives, the present invention proposes a congestion game-based adaptive management method for microservice resources under a cloud native architecture. When the semi-supervised meta-learning (SMPM) model predicts that the performance corresponding to the node exceeds the QoS specified range, the CPU, memory, I / O, LLC and other resources of the microservice node are dynamically adjusted in combination with the congestion game algorithm. The specific steps are:

[0012] Step 1: Deploy benchmark tools in the container engine to simulate real application scenarios;

[0013] Step 2: Use performance monitoring tools to collect microservice "resource-performance" data in the application scenario;

[0014] Step 3: Standardize the microservice "resource-performance" data; add conditional vectors to the table generation adversarial (TGAN) model to obtain a revised conditional table generation adversarial (CTGAN) model, and use the CTGAN model to generate labeled auxiliary data based on the labeled data set in the standardized microservice "resource-performance" data;

[0015] Step 4: Based on the standardized microservice “resource-performance” data and the labeled auxiliary data, an SMPM model is constructed to achieve performance prediction of microservice nodes;

[0016] Step 5: When the performance of the predicted microservice does not meet the preset service quality requirements, a resource adaptive allocation decision is generated in combination with congestion game;

[0017] Step 6: Based on the resource adaptive allocation decision, use resource management tools to allocate CPU, memory and I / O resources.

[0018] The Step 3 is specifically as follows:

[0019] Step 3.1: Process the continuous features and discrete features in the microservice “resource-performance” data to obtain standardized microservice “resource-performance” data;

[0020] Step 3.2: Construct conditional vector;

[0021] Step 3.3: Based on the constructed conditional vector, the generator is trained using cross entropy loss;

[0022] Step 3.4: Evaluate the generator performance through the discriminator;

[0023] Step 3.5: Repeat Step 3.2-Step 3.4. When the generated data distribution is the same as the actual data distribution, output the labeled auxiliary data with a consistent data distribution with the standardized microservice "resource-performance" data.

[0024] The Step 4 is specifically as follows:

[0025] Step 4.1: Use the unlabeled data in the standardized microservice "resource-performance" data to self-generate tasks;

[0026] Specifically, due to the heterogeneous characteristics of the microservice "resource-performance" dataset, it is difficult to effectively obtain the microservice nodes in the performance data. Therefore, multiple resource feature columns are randomly selected and the clustering algorithm is run. The clustering results are used as the performance values ​​of the corresponding resource features, that is, pseudo-labels are given to the microservice nodes to self-generate tasks.

[0027] Step 4.2: Train the prototype network (ProtoNet) based on the generated tasks to obtain the optimal embedding space parameters and build the SMPM model;

[0028] Step 4.3: Based on the SMPM model, the labeled data set and the labeled auxiliary data are input into the classifier to adjust parameters and predict the performance of the microservice.

[0029] Specifically, the predicted results of the present invention divide the response time into three levels: low, medium, and high, represented by 0, 1, and 2, respectively: when the response time is between 0 and 0.5 milliseconds, it is at a low level, indicating that the node resources are abundant and there is a certain degree of waste. At this time, it is recommended to appropriately reduce resource allocation to optimize resource utilization efficiency; if the response time is in the range of 0.5 to 10 milliseconds, it is at an intermediate level, indicating that the current resource configuration is appropriate and can meet the normal operation requirements of the node, and no adjustment is required; once the response time exceeds 10 milliseconds, it will be at a high level, which means that the node resources are insufficient and it is difficult to support its normal operation. At this time, resources should be quickly increased to ensure service quality and user experience. The classification method based on response time can more accurately monitor and predict the performance status of microservice nodes, especially key nodes that are located on the application execution path but perform poorly.

[0030] The optimal embedding space parameters obtained in Step 4.2 are specifically:

[0031] For a given task, we first sample two disjoint datasets from the task: the support set , which are used to construct the classifier and train the constructed classifier respectively. The prototype vector of each pseudo class is obtained by the following formula :

[0032]

[0033] in, express All pseudo-classes A sample set of represents the eigenvector after perturbation, yes The corresponding category label, is a parameterized embedding function that maps the input sample to a On this basis, we build a classifier , the calculation formula is:

[0034]

[0035] Representation sample Predicted to be a pseudo-class , Represents the pseudo-class Other pseudo-classes besides For pseudo-class The prototype vector of

[0036] Then, by computing the query set In the classifier The cross entropy loss in , and get the meta-learning loss , the calculation formula is:

[0037]

[0038]

[0039] By different task sets Meta-learning loss on Optimize and iterate the training model to minimize the loss and finally obtain the best embedding space parameters .

[0040] The Step 5 is specifically as follows:

[0041] Step 5.1: Define the microservice node set and resource set;

[0042] Step 5.2: Design a congestion function to quantify the effect of resource contention on performance;

[0043] Step 5.3: Design the revenue function based on the congestion function;

[0044] Step 5.4: Based on the profit function, an iterative algorithm is used to find the Nash equilibrium and generate adaptive resource allocation decisions.

[0045] Specifically, when the strategies of other nodes remain unchanged, when each node cannot obtain higher benefits by unilaterally changing its strategy, it means that the current iteration has reached equilibrium. After many iterations, the Nash equilibrium point of the entire game can be found. Nash equilibrium not only ensures that the model can find a stable strategy combination, but also can adapt to the dynamically changing game environment. Each time a new participant joins, a new round of strategy adjustment will be triggered. The final Nash equilibrium point is the optimal resource allocation plan for the node.

[0046] The Step 5.2 is specifically as follows:

[0047] Congestion number Representation Resources Total usage, in strategy Calculate the resources of all microservice nodes Total usage:

[0048]

[0049] in, Representing microservices About Resources Amount of usage;

[0050] Congestion function Representation Resources The performance impact of using is as follows:

[0051]

[0052] in, It is a resource The total capacity of is the congestion coefficient, which indicates the negative impact of resource competition on performance. Indicates system resources relative utilization rate.

[0053] The Step 5.3 is specifically as follows:

[0054] The benefit function represents the benefit that each microservice obtains from the resources allocated by the system and the negative impact of congestion caused by other nodes on the benefit. Based on the congestion function, the benefit function of each microservice node is obtained. It is expressed as:

[0055]

[0056] in, is a function that represents the performance improvement of the microservice on the allocated resources. is the weight, indicating the resource For microservices The importance of different resources is adjusted by the contribution of different resources to system performance.

[0057] The Step 5.4 is specifically as follows:

[0058] Step5.4.1: Set the initial strategy vector;

[0059] Step 5.4.2: For each microservice node, under the condition of fixing the strategies of other nodes, select the best resource allocation by maximizing the benefit function and update the strategy vector;

[0060] Step5.4.3: Determine whether the strategy vector converges. If so, output the final strategy combination. If not, return to Step5.4.2 to continue iterating.

[0061] The beneficial effects of the present invention are as follows: the present invention uses the response time of service requests as QoS. First, the DeathStarBench benchmark program is run on the Docker platform to simulate real application scenarios. Second, the "resource-performance" data of all microservice nodes on the critical path in the application are collected. Subsequently, based on a semi-supervised meta-learning mechanism, tasks are self-generated on an unlabeled data machine to quickly learn the correlation and difference between tasks, generalize the learned knowledge to the constructed classifier, and fine-tune parameters through labeled data sets to accurately predict the performance of microservice nodes. Finally, the Nash equilibrium theory in game theory is used to optimize the resource allocation strategy, so as to achieve the purpose of improving the resource utilization of microservice nodes while meeting the end-to-end service quality of the task. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] Figure 1 is a flow chart of the steps of the present invention;

[0063] Figure 2 It is a structural diagram of the SMPM model of the present invention. DETAILED DESCRIPTION

[0064] The present invention will be further described below in conjunction with the accompanying drawings and specific implementation methods.

[0065] Example 1: Figure 1 As shown in the figure, a congestion game-based adaptive management method for microservice resources in a cloud native architecture is shown in the figure. The specific steps are as follows:

[0066] Step 1: Deploy benchmark tools in the container engine to simulate real application scenarios.

[0067] Specifically, since microservices under the cloud-native architecture usually run in containers, the present invention relies on deploying the open source benchmark suite DeathStarBench in the container engine Docker to simulate the operation scenario of real microservice applications. Docker uses operating system-level virtualization technology to package applications and their dependencies into a single portable package of the Docker container, thereby achieving application isolation, portability and repeatability. DeathStarBench is a cloud-native, high-performance open source benchmark program that includes 6 end-to-end services, covering the current popular cloud and edge services such as social networks, media services and secure banking systems. Each application contains multiple microservice nodes, based on which the impact of application design on microservices is analyzed.

[0068] Step 2: Use performance monitoring tools to collect microservice "resource-performance" data in the application scenario.

[0069] Specifically, in order to control the access of processes in the container to resources, Docker can use control groups technology, namely Cgroups, based on which the resource allocation of processes in the container can be controlled. At the same time, the Linux performance monitoring tool vmstat is used to obtain the "resource-performance" data of microservices in social network and media service applications. At the same time, with the help of the distributed tracking system Jaeger, the performance time of microservice nodes can be collected, specifically, the response time t of the corresponding node is collected. Table 1 lists the "resource-performance" data of microservices.

[0070] Table 1 Microservice “resource-performance” data

[0071]

[0072] Furthermore, Docker uses the Cgroups mechanism to control the resource allocation of processes in the container and the Linux performance monitoring tool vmstat to obtain the resource usage data of the microservices. At the same time, the performance data of the microservice nodes is collected through the distributed tracking system Jaeger, and finally 10 data instances are obtained as shown in Table 2.

[0073] Table 2 Microservice “resource-performance” data example

[0074]

[0075] Among them, ID is the microservice node number, shares is the priority of the microservice node using the CPU, cpus is the CPU core used by the microservice node, swap is the virtual size memory, free is the available memory size, the memory size of the swap area read and write is represented by si and so respectively, the amount of data read and written per second by the block device is represented by bi and bo respectively, us is the user process execution time, sy is the system process execution time, id is the CPU idle time, and t is the corresponding response time of the microservice node.

[0076] Step 3: Standardize the microservice "resource-performance" data; add conditional vectors on the basis of the TGAN model to obtain the revised CTGAN model, and use the CTGAN model to generate labeled auxiliary data based on the labeled data set in the standardized microservice "resource-performance" data. The specific steps are:

[0077] Step 3.1: Process the continuous features and discrete features in the microservice “resource-performance” data to obtain standardized microservice “resource-performance” data;

[0078] The microservice "resource-performance" label data includes continuous features and discrete features. For continuous features, each continuous column are all considered as a continuous variable containing multiple Gaussian distributions, each with a unique weight and standard deviation; then, the variable is estimated using the Variational Gaussian Mixture Model (VGN) to estimate the number of modes and fit the Gaussian distribution. The Continuous variables , assuming that there is The modal components are , For the modes, and the learned Gaussian mixture distribution for:

[0079] (1)

[0080] in and are the weight and standard deviation of the mode, respectively. For the modal, is a normal distribution. The probability from each mode is denoted as , For the The probability of a pattern. Calculated as:

[0081]

[0082] By evaluating the samples in each Gaussian distribution, and Indicates which distribution the sample belongs to and the specific value of the sample in its distribution, thereby completing the transformation of continuous feature data. For discrete features, all discrete columns All are composed of one-hot vectors express, Indicates discrete columns, Indicates One-hot vector, The one-hot vector is ,in , Indicates Discrete feature columns Finally, The resource usage and performance data conversion results of each microservice node are recorded as , expressed as: .in, and is a continuous feature representation, It is the representation of discrete features after one-hot encoding. is the number of continuous features, is the number of discrete features, through the concatenation operation ( ), so that different types of feature data are combined into a comprehensive feature vector .

[0083] Step 3.2: Construct conditional vector .

[0084] With equal probability from all Select one discrete column from the , As the index of the selected column, in the selected The PMF (Probability Mass Function) is constructed over the range of values ​​in the column, is a randomly selected value in PMF, so the condition is: . It is with One-hot vector The related mask vector, represented as ,in Therefore, the condition can be expressed as a mask vector, as follows: . Therefore, the conditional vector is: , For the mask vector.

[0085] Step 3.3: Based on the constructed conditional vector, the generator is trained using cross entropy loss.

[0086] During training, the generator is free to produce any set of one-hot discrete vectors , For the One-hot discrete vectors, each of which corresponds to a discrete feature column. However, due to the freedom of the generator, it may generate conditional vectors that are different from the constructed Therefore, the present invention proposes a constraint mechanism based on cross entropy loss, by adding the generator output to the loss function. With the correct conditional mask The cross entropy term is According to the conditional vector By averaging the loss over all samples in the training batch, the generator gradually learns to generate the same Completely consistent output. As training progresses, the output of the generator will become more accurate, that is, it can When , the corresponding one-hot encoded discrete vector is accurately generated .

[0087] Step 3.4: Evaluate the generator performance through the discriminator.

[0088] The generated data generated by the generator will be evaluated by the discriminator and the generated data distribution will be calculated under given conditions. The actual data distribution The distance between is a single sample. The original distribution It is expressed as:

[0089] (2)

[0090] In the formula, for One of the possible values, is specific The sampling of the true training data and the construction of the conditional vector must be consistent to help the discriminator estimate the distance.

[0091] Step 3.5: Repeat Step 3.2-Step 3.4. When the generated data distribution is the same as the actual data distribution, output the labeled auxiliary data with a consistent data distribution with the standardized microservice "resource-performance" data.

[0092] Furthermore, first, according to Step 3.1, the transformation of the microservice "resource-performance" data in Table 2 is completed. Taking the continuous feature "us" as an example, the variational Gaussian mixture model is used to fit the best three Gaussian distributions, which are , whose mean and standard deviation are , , , and , For a value in the "us" column , calculated by the probability density formula , calculate the probability of belonging to each mode respectively, where , , respectively calculated: ,because Maximum, judgment Belong to modal Then, for the value Perform normalization and calculate its normalized value in the mode: . At the same time The modal information of , used to identify it as belonging to the third mode. Next, the discrete feature "shares" is processed using one-hot encoding. Let "shares=512" be 1, "shares=1024" be 2, and "shares=2048" be 3. Taking ID1 as an example, the result of encoding its "shares" feature is a three-dimensional vector [1,0,0].

[0093] According to Step 3.2, randomly select a feature column index from the three discrete feature columns "shares", "cpus", and "swaps" , that is, select the feature column (“shares”). The range of contains three values, and the first value is randomly selected, then . Index Corresponding The column mask The components are set to 1, that is, =1. Next, according to the mask , , , calculate the conditional vector After calculating the conditional vector After that, the generated data and the real data are sampled. After Step 3.3-Step 3.4, a set of combined generated data with Gaussian distribution of the original features and the same number as Table 2 can be obtained as shown in Table 3. Among them, the ID of the generated data is represented by S1-S10.

[0094] Table 3. Generated data based on CTGAN

[0095]

[0096] Step 4: Based on the standardized microservice "resource-performance" data and the labeled auxiliary data, an SMPM model is constructed to achieve performance prediction of microservice nodes. The method for constructing the SMPM model is as follows: Figure 2 As shown. Step 4 The specific steps are:

[0097] Step 4.1: Use the unlabeled data in the standardized microservice "resource-performance" data to self-generate tasks.

[0098] Specifically, multiple resource feature columns are randomly selected and a clustering algorithm is run. The clustering algorithm may be a K-means clustering algorithm, so that the clustering result is used as the performance value of the corresponding resource feature, that is, a pseudo label is given to the microservice node to self-generate tasks.

[0099] To generate a single task , from a uniform distribution Randomly generate binary masks in ,in and They are the upper and lower bounds of the uniform distribution, respectively, to control the range of the generated values. Then, feature columns with a mask index value of 1 are selected from the unlabeled microservice resource data. Based on the selected columns, K-means clustering is run to generate task labels, and tasks are generated by the following formula:

[0100] (3)

[0101] Make , indicating the sample Category label is a one-hot encoded vector, and the sum of the elements of each category label is unique, which means that the sample is assigned to a unique category. is the number of centroids, is a vector of 1, Indicates a dimensional real vector space. Each centroid is a dimensional vector, is the matrix of the centroids, is the total number of rows of microservice resource data generated for tasks, is a randomly generated binary mask, is the feature transformation function. To avoid the problem of model performance degradation caused by unbalanced data distribution, for the selected column features, the formula The disturbance is processed, represents the eigenvector after perturbation, is a value randomly sampled from the empirical marginal distribution of each column feature, a binary mask The column feature position that needs to be disturbed is specified. The column with a mask value of 1 will be replaced, and the values ​​of other columns remain the original feature values. By optimizing the objective function, the optimal centroid matrix can be determined and category labels , thus completing the generation of the task.

[0102] Step 4.2: Train the prototype network based on the generated tasks, obtain the optimal embedding space parameters, and build the SMPM model.

[0103] For a given task , first from the task Two disjoint data sets are sampled from: the support set , which are used to construct the classifier and train the constructed classifier respectively. The prototype vector of each pseudo class is obtained by the following formula :

[0104] (4)

[0105] in, express All pseudo-classes A sample set of represents the eigenvector after perturbation, yes The corresponding category label, is a parameterized embedding function that maps the input sample to a On this basis, the ProtoNet classifier is constructed , the calculation formula is:

[0106] (5)

[0107] Then, by computing the query set In the classifier The cross entropy loss in : , and get the meta-learning loss , the calculation formula is:

[0108] (6)

[0109] By different task sets Meta-learning loss on Optimize and iterate the training model to minimize the loss and finally obtain the best embedding space parameters .

[0110] Step 4.3: Based on the SMPM model, the labeled data set and the labeled auxiliary data are input into the classifier to adjust parameters and predict the performance of the microservice.

[0111] Specifically, the optimal embedding space parameters obtained by the prototype network in the meta-learning mechanism are After that, the labeled data set and the labeled auxiliary data are input into the classifier to adjust the parameters. The predicted results divide the response time into three levels: low, medium, and high, represented by 0, 1, and 2, respectively: when the response time is between 0 and 0.5 milliseconds, it is at a low level, indicating that the node resources are sufficient and there is a certain degree of waste. At this time, it is recommended to appropriately reduce resource allocation to optimize resource utilization efficiency; if the response time is in the range of 0.5 to 10 milliseconds, it is at a medium level, indicating that the current resource configuration is appropriate and can meet the normal operation requirements of the node, and no adjustment is required; once the response time exceeds 10 milliseconds, it will be at a high level, which means that the node resources are insufficient and it is difficult to support its normal operation. At this time, resources should be quickly increased to ensure service quality and user experience. The classification method based on response time can more accurately monitor and predict the performance status of microservice nodes, especially key nodes that are located on the application execution path but perform poorly.

[0112] Furthermore, the SMPM model is initialized Based on this model, the time of the 10 data instances in Table 2 is predicted and classified into three levels: high, medium, and low, represented by 0, 1, and 2 respectively. When SMPM uses unlabeled data to learn the correlation and difference between tasks and learns the embedding space through the meta-learning mechanism, it takes the labeled auxiliary data as input, fine-tunes the parameters in the classifier according to formula (4), and calculates the output of the model according to formula (5), that is, the prediction result, and records the prediction classification structure result in Table 4. middle.

[0113] Table 4 Data for constructing the SMPM model

[0114]

[0115] When the prediction result is set to 2, that is, the predicted performance is high, it exceeds the specified range of QoS. The predicted performance of instances 1, 4, and 9 exceeds the specified range of QoS, so Step 5 needs to be executed to adaptively allocate resources.

[0116] Step 5: When the performance of the predicted microservice does not meet the preset service quality requirements, a resource adaptive allocation decision is generated in combination with congestion game. The specific steps are:

[0117] Step 5.1: Define the microservice node set and resource set;

[0118] , represents the set of microservice nodes, is the total number of microservice nodes.

[0119] , represents a resource collection, where is the type of resource in the system. Each resource Corresponds to a specific hardware resource type, such as CPU, memory, I / O bandwidth, etc.

[0120] , representing microservices The selected set of strategies, that is, each microservice The selected resource configuration strategy. Each strategy Representing microservices The amount of CPU, memory, and I / O bandwidth allocated. Representing microservices The number of CPUs allocated; Representing microservices The amount of memory allocated; Representing microservices The amount of I / O bandwidth allocated.

[0121] Strategy Indicates the resource allocation status of all microservice nodes. Representative The resource allocation strategy for each microservice node.

[0122] Step 5.2: Design a congestion function to quantify the effect of resource contention on performance;

[0123] Specifically, when multiple microservices request the same resource, the system resources are allocated to more microservices, and the resource share that each microservice can obtain will be reduced, resulting in performance degradation. The present invention quantifies the effect of resource competition on performance by designing a congestion function.

[0124] Congestion number Representation Resources Total usage, in strategy Calculate the resources of all microservice nodes Total usage:

[0125] (7)

[0126] in, Representing microservices About Resources usage.

[0127] Congestion function Representation Resources The performance impact of using is as follows:

[0128] (8)

[0129] in, It is a resource The total capacity of The congestion coefficient indicates the negative impact of resource competition on performance. When multiple microservices compete for the same resource, the performance of the system may be greatly reduced. To reflect the speed or cost of performance degradation when resources are overused, Indicates system resources The current system's relative utilization of resources Demand and total capacity The larger the value, the more intense the resource competition and the higher the congestion risk.

[0130] Step 5.3: Design the revenue function based on the congestion function;

[0131] Specifically, the benefit function represents the benefit that each microservice obtains from the resources allocated by the system and the negative impact of congestion on the benefit caused by other nodes. Therefore, the design of the benefit function is divided into two parts: the direct benefit part and the congestion penalty part. The former is the performance improvement brought by the microservice obtaining resources, which is related to the actual amount of resources allocated to the microservice; the latter is the performance degradation caused by resource congestion due to other microservices competing for the same resources, which is expressed by the congestion function. Based on the congestion function, the benefit function of each microservice node is obtained It is expressed as:

[0132] (9)

[0133] in, is a function that represents the performance improvement of the microservice on the allocated resources. is the weight, indicating the resource For microservices The importance of different resources is adjusted by the contribution of different resources to system performance.

[0134] Step 5.4: Based on the profit function, an iterative algorithm is used to find the Nash equilibrium and generate adaptive resource allocation decisions;

[0135] Specifically, in the congestion game model of the present invention, Nash equilibrium refers to the strategy vector Below, among them Representative The optimal resource allocation scheme selected by each microservice node under Nash equilibrium. They cannot unilaterally change their own strategies. To increase their own benefits. That is, for each and The following conditions are met:

[0136] (10)

[0137] in, In addition to microservices In addition, the strategy combination of all other microservice nodes. Indicates A microservice node selects a Nash equilibrium strategy among all nodes The income at that time, Indicates Microservice nodes in other node strategies In the fixed case, by choosing the strategy The income obtained.

[0138] The Nash equilibrium is found through iterative optimization algorithm. First, in the initialization phase, the initial strategy vector is set , that is, the initial resource allocation of each microservice node, Representative Then, in the iterative optimization phase, each microservice node , in fixing other node strategies Under the condition of , that is, by maximizing the profit function To select the best resource allocation and update the policy vector ,in Indicates The microservice node fixes the strategy of all other nodes In the case of Finally, we determine the strategy vector Whether it converges. If it converges, the final strategy combination is output; if it does not converge, it returns to the iterative optimization stage to continue iterating.

[0139] When the strategies of other nodes remain unchanged, and each node cannot obtain higher benefits by unilaterally changing its strategy, it means that the current iteration has reached equilibrium. After many iterations, the Nash equilibrium point of the entire game can be found. Nash equilibrium not only ensures that the model can find a stable strategy combination, but also can adapt to the dynamically changing game environment. Each time a new participant joins, a new round of strategy adjustment will be triggered. The final Nash equilibrium point is the optimal resource allocation plan for the node.

[0140] Furthermore, according to the prediction results of Step 4, the nodes of data instances 1, 4, and 9 are adjusted for resources, and the following three types of microservice node resources are competed according to the physical resources of the local server: CPU, memory, and I / O. The problem of microservice node resource allocation is modeled as a congestion game problem. There are three microservice nodes , resource collection , respectively represented by CPU, memory, and I / O, and the total capacity is: Cores, , The initial policy settings are as follows:

[0141] Microservice node 1:

[0142] Microservice Node 2:

[0143] Microservice node 3:

[0144] Total resource usage (i.e. congestion ) is calculated as follows:

[0145]

[0146]

[0147]

[0148] Based on the congestion number, according to formula (6) and , , , calculate the congestion function of each resource separately:

[0149] CPU congestion function : ;

[0150] Memory congestion function : ;

[0151] I / O congestion function : ;

[0152] Based on the congestion number and congestion function of each resource calculated above, the benefit of each node is calculated according to formula (9), where , =0.8, , :

[0153] In microservice node 1, The value of each element in is , , . Therefore, the payoff is: ;

[0154] In microservice node 2, The value of each element in is , , . Therefore, the payoff is: ;

[0155] In microservice node 3, The value of each element in is , , . Therefore, the payoff is: .

[0156] In the first iteration, node 3 is selected as the node with the smallest benefit. The CPU allocation of node 3 is increased from 5 to 6. The new total resource usage and new congestion function and benefit are recalculated and adjusted. The policy adjustment optimizes the benefit through iteration and eventually tends to the Nash equilibrium point. Through policy iteration, the system realizes the reasonable allocation of resources among microservice nodes. Each node adjusts its policy according to the degree of congestion to maximize the benefit. Finally, Nash equilibrium is reached, resource utilization is optimized, and performance degradation caused by excessive competition is avoided. The final policy obtained by each node for:

[0157]

[0158]

[0159]

[0160] Step 6: Based on the resource adaptive allocation decision, use resource management tools to allocate CPU, memory and I / O resources.

[0161] Specifically, resource adaptive allocation decisions need to be implemented using various resource management tools. When adjusting CPU performance, the present invention uses the CPU subsystem commands cpu.cfs_period_us and cpu.cfs_quota_us in the Linux kernel management tool Cgroups to implement it; for memory and LLC (last level cache) adjustments, Intel's CAT (Cache Allocation Technology) tool is used to complete it; for I / O performance adjustment, the blkio subsystem in Cgroups is used to control the hard disk throughput.

[0162] Furthermore, using Cgroups and Intel CAT instructions, according to the resource adjustment plan obtained in Step 5, the relevant resources in each microservice node are adjusted.

[0163] In microservice node 1, adjust the number of CPU cores to 5, the memory to 1.5 GB, and the I / O to 2 GB; in microservice node 2, adjust the number of CPU cores to 6, the memory to 2 GB, and the I / O to 3 GB; in microservice node 3, adjust the number of CPU cores to 5, the memory to 2.5 GB, and the I / O to 2 GB.

[0164] The specific implementation modes of the present invention are described in detail above in conjunction with the accompanying drawings, but the present invention is not limited to the above implementation modes, and various changes can be made within the knowledge scope of ordinary technicians in this field without departing from the purpose of the present invention.

Claims

1. A congestion game-based adaptive management method for microservice resources in a cloud-native architecture, characterized in that: The method includes: Step 1: Deploy benchmark tools in the container engine to simulate real application scenarios; Step 2: Use performance monitoring tools to collect microservice "resource-performance" data in the application scenario; Step 3: Standardize the microservice "resource-performance" data; add conditional vectors on the basis of the TGAN model to obtain a revised CTGAN model, and use the CTGAN model to generate labeled auxiliary data based on the labeled data set in the standardized microservice "resource-performance" data; Step 4: Based on the standardized microservice "resource-performance" data and the labeled auxiliary data, an SMPM model is constructed to achieve performance prediction of microservice nodes; Step 5: When the performance of the predicted microservice does not meet the preset service quality requirements, a resource adaptive allocation decision is generated in combination with congestion game; Step 6: Based on the resource adaptive allocation decision, use the resource management tool to allocate CPU, memory and I / O resources; The Step 4 is specifically as follows: Step 4.1: Use the unlabeled data in the standardized microservice "resource-performance" data to self-generate tasks; Step 4.2: Train the prototype network based on the generated tasks to obtain the optimal embedding space parameters and build the SMPM model; Step 4.3: Based on the SMPM model, the labeled data set and the labeled auxiliary data are input into the classifier to adjust parameters and predict the performance of the microservice; The optimal embedding space parameters obtained in Step 4.2 are specifically: For a given task, we first sample two disjoint datasets from the task: the support set , which are used to construct the classifier and train the constructed classifier respectively. The prototype vector of each pseudo class is obtained by the following formula : ； in, express All pseudo-classes A sample set of represents the eigenvector after perturbation, yes The corresponding category label, is a parameterized embedding function that maps the input sample to a On this basis, we build a classifier , the calculation formula is: ； Representation sample Predicted to be a pseudo-class , Represents the pseudo-class Other pseudo-classes besides For other pseudo-classes The prototype vector of Then, by computing the query set In the classifier The cross entropy loss in , and get the meta-learning loss , the calculation formula is: ； ； By different task sets Meta-learning loss on Optimize and iterate the training model to minimize the loss and finally obtain the best embedding space parameters .

2. According to the method for adaptive management of microservice resources based on congestion game in a cloud native architecture according to claim 1, it is characterized in that: The Step 3 is specifically as follows: Step 3.1: Process the continuous features and discrete features in the microservice "resource-performance" data to obtain standardized microservice "resource-performance" data; Step 3.2: Construct conditional vector; Step 3.3: Based on the constructed conditional vector, the generator is trained using cross entropy loss; Step 3.4: Evaluate the generator performance through the discriminator; Step 3.5: Repeat Step 3.2-Step 3.

4. When the generated data distribution is the same as the actual data distribution, output the labeled auxiliary data with consistent data distribution with the standardized microservice "resource-performance" data.

3. According to the method for adaptive management of microservice resources based on congestion game in a cloud native architecture according to claim 1, it is characterized in that: The Step 5 is specifically as follows: Step 5.1: Define the microservice node set and resource set; Step 5.2: Design a congestion function to quantify the effect of resource contention on performance; Step 5.3: Design the revenue function based on the congestion function; Step 5.4: Based on the profit function, an iterative algorithm is used to find the Nash equilibrium and generate adaptive resource allocation decisions.

4. According to the method for adaptive management of microservice resources based on congestion game in a cloud native architecture according to claim 3, it is characterized in that: The Step 5.2 is specifically as follows: Congestion number Representation Resources Total usage, in strategy Calculate the resources of all microservice nodes Total usage: ； in, Representing microservices About Resources Amount of usage; Congestion function Representation Resources The performance impact of using is as follows: ； in, It is a resource The total capacity of is the congestion coefficient, which indicates the negative impact of resource competition on performance. Indicates system resources relative utilization rate.

5. According to the method for adaptive management of microservice resources based on congestion game in a cloud native architecture according to claim 3, it is characterized in that: The Step 5.3 is specifically as follows: The benefit function represents the benefit that each microservice obtains from the resources allocated by the system and the negative impact of congestion caused by other nodes on the benefit. Based on the congestion function, the benefit function of each microservice node is obtained. It is expressed as: ； in, is a function that represents the performance improvement of the microservice on the allocated resources. is the weight, indicating the resource For microservices The importance of different resources is adjusted by the contribution of different resources to system performance.

6. According to the method for adaptive management of microservice resources based on congestion game in a cloud native architecture according to claim 3, it is characterized in that: The Step 5.4 is specifically as follows: Step5.4.1: Set the initial strategy vector; Step 5.4.2: For each microservice node, under the condition of fixing the strategies of other nodes, select the best resource allocation by maximizing the benefit function and update the strategy vector; Step5.4.3: Determine whether the strategy vector converges. If so, output the final strategy combination. If not, return to Step5.4.2 to continue iterating.

Images