Dynamic feature-oriented micro-service application optimization resource management system and method

Abstract

A dynamic feature-oriented micro-service application optimization resource management system and method, comprising: a network-based load monitor, a load updater for sensing congestion and a resource efficient request emptier, when a micro-service application has load and call graph dynamics, the load monitor, according to the network monitoring data of each micro-service, updating the load updater for updating the load of the micro-service application according to the network monitoring data of each micro-service; analyzing to obtain a network flow and a network packet, and predicting to obtain a monitoring load through a linear regression technology in machine learning; the load updater calculates a real to-be-processed load of each micro-service according to a monitoring load and a blocking graph constructed through a calling relation and a calling sequence among the micro-services, and allocates a corresponding resource quantity to the real to-be-processed load; and the request emptier calculates the excessive load of each micro-service in the remaining QoS recovery time according to the real load of each micro-service output by the load updater and the current resource allocation information, and allocates excessive resources to each micro-service, thereby achieving the purpose of quickly recovering the QoS of the application. According to the method, under the condition that code modification does not need to be carried out on the micro-service application, the QoS target of the application can be quickly recovered under the dynamic nature of the micro-service application, and the resource allocation amount can be minimized to maintain the resource efficiency; and support can be provided for optimization resource management technology landing when load occurs in the micro-service application in the cloud data center and graph dynamics are called.

Description

Technical Field

[0001] The present invention relates to a technology in the field of computing resource configuration, specifically a microservice application optimization resource management system and method oriented to dynamic characteristics. Background Art

[0002] The decoupling of microservice applications brings about a complex microservice application dependency structure. Figure 1 In the typical DAG structure of a microservice application shown in the figure, each node is a microservice, and each edge is a call dependency between microservices. Most microservice applications have a tree structure, where each downstream microservice has only one upstream microservice calling it. A few microservice applications may have a small number of microservices with an in-degree greater than 1. In addition, industrial microservice applications usually have multiple different call graphs, such as Figure 1 (b) and (c). Different call graphs originate from different user request patterns, for example, users have different choices for comprehensive or lowest price recommendations in e-commerce applications. Each call graph only contains a part of the entire microservice application dependency graph, and different call graphs may have the same microservices. Existing resource management and fast QoS guarantee for dynamic microservice applications have the following challenges: 1) How to determine the actual pending load of each microservice in advance by monitoring the load based on the call relationship and sequence between microservices, and make corresponding advance resource adjustments; 2) Select appropriate resource adjustment input indicators to quickly perceive the microservice load changes caused by dynamicity, and use them to decide the amount of microservice resource allocation; 3) For queued requests during resource adjustment, how to use appropriate excess resources to quickly clear them and reduce total resource usage while meeting QoS recovery time goals. Summary of the invention

[0003] In view of the shortcomings of the prior art that the dynamic occurrence of microservice applications cannot be quickly discovered, the actual load to be processed of each microservice cannot be accurately determined to quickly make corresponding resource adjustment decisions, and the request queuing caused by the dynamic nature of microservices cannot be quickly processed, thereby failing to quickly restore the QoS goals of microservice applications, the present invention proposes a microservice application optimization resource management system and method oriented to dynamic characteristics. Without the need to modify the code of the microservice application, the QoS goals of the application can be quickly restored under the dynamic nature of the microservice application, and the resource allocation amount can be minimized to maintain resource efficiency. Support can be provided for the implementation of optimized resource management technology when load and call graph dynamics occur in microservice applications in cloud data centers.

[0004] The present invention is achieved through the following technical solutions:

[0005] The present invention relates to a microservice application optimization resource management system oriented to dynamic characteristics, comprising: a network-based load monitor, a blocking-aware load updater and a resource-efficient request emptier. When the microservice application has load and call graph dynamics, the load monitor parses network traffic and network packets according to network monitoring data for each microservice, and predicts the monitored load through the linear regression technology in machine learning; the load updater calculates the real to-be-processed load of each microservice according to the monitored load and the blocking graph constructed through the call relationship and call sequence between microservices, and allocates corresponding resources to it; the request emptier calculates the excess load of each microservice within the remaining QoS recovery time according to the real load of each microservice output by the load updater and the current resource allocation information, and allocates excess resources to each microservice, so as to achieve the QoS goal of quickly recovering the application.

[0006] The present invention relates to a method for optimizing resource management of microservice applications oriented to dynamic characteristics based on the above system, comprising:

[0007] 1) The load monitor periodically collects network metrics of all microservices every second, uses the collected metrics to predict the monitoring load size of each microservice through a linear regression model, and outputs the predicted monitoring load to the load updater.

[0008] The network indicators include: network traffic and the number of network packets received.

[0009] 2) The load updater updates the weights of the nodes and edges of the load blocking graph in the order of breadth-first search according to the monitored load and current resource allocation of each microservice, obtains the real pending load of each microservice in advance, and allocates the corresponding amount of resources to it, reducing the QoS violation time, including:

[0010] 2.1) The load updater builds a load blocking graph of the microservice application based on the calling relationships and calling sequences between microservices from the microservice application dependency graph, and initializes the node weights and edge weights of the graph.

[0011] 2.2) The load updater combines the current resource allocation and monitoring load of each microservice and updates the real pending load in advance based on the constructed load blocking graph.

[0012] 2.3) The load updater uses linear regression technology to predict the amount of CPU resources required by each microservice based on the actual load updated in step 2.2 and allocates them accordingly.

[0013] 3) The request handler calculates the total request queue of each microservice based on the actual load of each microservice obtained by the load updater in step 2, combined with the request queuing time and resource shortage of each microservice through queuing theory, and reallocates excess resources to each microservice to restore application QoS within the recovery time objective and ensure resource efficiency. Technical Effects

[0014] The present invention quickly obtains the monitored load size of microservices through network monitoring, updates the real load size of microservices in advance based on the monitored load, resource allocation and blocking relationship between microservices, and determines the excess resource size that needs to be allocated to the microservice based on the real load, queuing time and resource shortage to quickly restore the QoS target of the microservice application. Compared with the existing technology, the present invention can restore the QoS target of the application more quickly and ensure the efficiency of computing resource allocation. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 It is a microservice application dependency graph and call diagram;

[0016] In the figure: (a) microservice application call dependency graph; (b) and (c) are call graphs;

[0017] Figure 2 It is a schematic diagram of the system of the present invention;

[0018] Figure 3 Schematic diagram of the construction of the blocking graph;

[0019] Figure 4 Schematic diagram of resource volume decision for queuing requests;

[0020] Figure 5 It is a method logic diagram. DETAILED DESCRIPTION

[0021] like Figure 2 As shown, this embodiment involves a microservice application optimization resource management system for dynamic characteristics, including: a network-based load monitor, a blocking-aware load updater, and a resource-efficient request clearer. When the microservice application has load and call graph dynamics, the load monitor parses the network traffic and network packets based on the network monitoring of each microservice, and predicts the monitored load through the linear regression technology in machine learning; the load updater calculates the actual to-be-processed load of each microservice based on the monitored load and the blocking graph constructed through the call relationship and call sequence between microservices, and allocates the corresponding amount of resources to it; the request clearer calculates the excess load that each microservice needs to handle within the remaining QoS recovery time based on the actual load of each microservice output by the load updater and the current resource allocation information, and allocates excess resources to each microservice to achieve the QoS goal of quickly recovering the application.

[0022] The QoS recovery time includes monitoring, resource adjustment and queue clearing time.

[0023] The load monitor includes: a network monitoring unit and a monitoring load prediction unit, wherein: the network monitoring unit regularly monitors and counts the network packets and network traffic size between each pair of microservices according to the network IP and port information of each microservice, and obtains the upstream inflow network bandwidth and the number of network packets per second of each microservice; the monitoring load prediction unit uses a linear regression model to predict according to the network monitoring information to obtain the monitoring load of each microservice.

[0024] The load updater includes: a load blocking graph construction unit, a real load updating unit, and a resource quantity prediction and allocation unit, wherein: the load blocking graph construction unit constructs and aggregates the substructure of the blocking graph according to the calling relationship and calling sequence information between microservices to obtain the load blocking graph of the microservice application; the real load updating unit calculates the microservice blocking rate and updates the real load according to the breadth-first search of the graph based on the monitoring load, load blocking graph, and existing resource allocation information of the microservice obtained by the load monitor to obtain the real load of all microservices; the resource quantity prediction and allocation unit uses a linear regression model to predict the required resource quantity of each microservice according to the real load, and makes corresponding allocation after obtaining the resource quantity.

[0025] The request clearer includes: an excess load calculation unit and an excess resource prediction and allocation unit, wherein: the excess load calculation unit performs excess load calculation processing based on the remaining QoS recovery time, microservice resource shortage, and request queuing time information to obtain the excess load calculation result of each microservice; the excess resource prediction and allocation unit uses a linear regression model to perform excess resource quantity prediction processing based on the excess load information, obtains the excess resource quantity result and allocates resources accordingly.

[0026] This embodiment relates to a method for optimizing resource management of microservice applications oriented to dynamic characteristics of the above system, including:

[0027] 1) The load monitor periodically collects network metrics of microservice applications, uses the collected metrics to predict the monitoring load size of each microservice based on linear regression technology, and outputs the predicted monitoring load to the load updater.

[0028] The network indicators include: network traffic and the number of network packets received.

[0029] The periodic collection means that the load monitor collects the microservice entrance network traffic\network packet monitoring every second to obtain the load size of each microservice. The specific process is: use the Libpcap C++ library to assist in obtaining the network packets\network traffic between each pair of microservice applications. This method uses 3 threads to complete the network situation statistics of each microservice. Thread 1 iteratively collects and parses the network packets passing through the network cards of all microservices; thread 2 performs clock synchronization every 20ms or a specified time to ensure the consistency of statistical data; thread 3 performs data statistics and formatted output for the latest collected network packets, and calculates the length of each network packet to obtain the network bandwidth usage size (Mbps) between each pair of microservices in this second. Since the data size requested by different users may be different, it will cause instability in network traffic monitoring. Thread 3 can also identify different requests through the IP sequence number of each network packet, thereby obtaining the call rate size of each microservice within 1 second.

[0030] 2) The load updater obtains the real load to be processed of each microservice in advance according to the monitored load of each microservice from the load monitor and the processable load corresponding to the resource allocation, and allocates the corresponding amount of resources to it, thereby reducing the QoS violation time, including:

[0031] 2.1) When the microservice application load and call graph dynamics appear, the resource allocation of some microservices will be insufficient. At this time, the calling relationship between microservices and the calling order between microservices will lead to the previous level blocking effect. Specifically, the insufficient resources of the previous microservice of a certain microservice (becoming a bottleneck) will block the load size that it can perceive. The previous level microservice includes the superior in the call relationship and the predecessor in the call order. Therefore, the present invention first constructs a blocking graph of the microservice application based on the dependency relationship and the call order between microservices, and on the basis of this blocking graph, the real load size of each microservice is quickly updated according to the monitored load of the microservice, the processable load corresponding to the resource allocation, and the blocking rate, and then allocates just enough resources. The load updater constructs a microservice application load blocking graph based on the calling relationship and dependency relationship between microservices, and the specific construction process is as follows:

[0032] ① For microservices with multiple in-degrees, convert the subtree with it into multiple identical copies to maintain the tree structure of the initial dependency graph, such as Figure 3 (a) shown.

[0033] ② Construct blocking relationships for each substructure: Figure 3 As shown in (b), microservices X and Y do not have a fixed call order from their common parent microservice. In this case, the blocking relationship is equivalent to the call dependency relationship between microservices. Figure 3As shown in (c), X is called by their common superior microservice before Y. In this case, Y's superior blocking microservice is the microservice at the end of the superior blocking subtree with X as its root.

[0034] The number of the microservices is not limited to one or more.

[0035] ③ Decompose the microservice dependency graph into multiple substructures, and then iteratively construct the upper-level blocking relationship from the root node microservice to obtain the final blocking graph of the overall microservice application.

[0036] In the initial construction state, the node weight in the blocking graph is the load size that each microservice can support, which is obtained by predicting the resource allocation in its current state through a linear model; the edge weight in the blocking graph is the load size transmitted between microservices, which can be constructed by simply calculating the load size supported by each microservice and the monitored load size based on the blocking relationship.

[0037] Preferably, this embodiment constructs a blocking graph based on a real load update mechanism, that is, starting from the root node, the real load size of each microservice is calculated step by step from top to bottom according to the blocking relationship and the blocking rate.

[0038] 2.2) The load updater performs advance updates of the real load to be processed. The specific process is as follows:

[0039] i) Initialize the record triples of each microservice, build the blocking graph weight information, and initialize a queue for breadth-first search.

[0040] ii) After putting the root microservice into the queue, update the actual load: Calculate the blocking rate of the first microservice j in the queue; Since the real load of the microservice at the head of the queue has been correctly updated, start processing j's downstream microservices, that is, for each downstream microservice k, first use j's blocking rate to update the real load from j to k, that is, the edge weight EW of the blocking graph jk =EW jk ×rate j ,When all the incoming edges of k have been updated, they are put into the queue to follow the breadth-first search until the queue is empty, the update process ends, that is, the real load of all microservices has been updated.

[0041] The blocking rate of the microservice j is: Among them: MonitorLoad i It is obtained from the web-based load monitor, ActualLoad i Will be obtained by the update mechanism for each microservice update and will be equal to MonitorLoad at the beginning i , HandleLoad iThe load that each microservice can handle is predicted from the resource allocation of its corresponding microservice using a linear regression model. Since the handleable load may be higher than the monitored load, the blocking rate is the actual load divided by the minimum of the handleable load and the monitored load.

[0042] When microservice applications become dynamic, the load of some microservices may decrease instead, resulting in a blocking rate of less than 1. In this case, the blocking rate is preferably regarded as 1.

[0043] iii) According to the actual load, the prediction model is used to predict the amount of CPU resources required by each microservice, and resources are allocated. The original microservice monitoring load, processable load, updated actual load and other indicators are input into the request clearer.

[0044] 2.3) The load updater uses the real load updated in step 2.2 and uses linear regression technology to predict the amount of CPU resources required by each microservice and allocates them.

[0045] 3) The request processor calculates the total request queue of each microservice based on the actual load of each microservice obtained in step 2.2, the request queue time of each microservice, the resource shortage and the remaining QoS recovery time, and allocates excess resources to each microservice to restore the application QoS and ensure resource efficiency within the recovery time target, including:

[0046] 3.1) The request processor calculates the total number of requests queued for each microservice. The specific process is as follows:

[0047] i) Use monitoring load, processable load, and real load to calculate the excess load OverLoad of each microservice during resource adjustment i =ActualLoad i -min(MonitorLoad i , HandleLoad i );

[0048] ii) When a dynamic situation occurs in a microservice application, for microservices whose real load is less than or equal to their monitored load and processable load, the corresponding excess load is set to 0. After calculating the excess load, the total number of requests to be processed by each microservice in the remaining QoS recovery time is further calculated. i =OverLoad i ×T i +ActualLoad i ×(QT-T i ), where: T iIt is the resource adjustment time that causes request queuing, QT is the QoS recovery time target, and in the total number of requests, the first item is the total number of queued requests, and the second item is the number of normal requests to be processed in the remaining time.

[0049] iii) Calculate the total load to be processed during the remaining QoS recovery time Where: TotQuery i is the total number of requests to be processed, QT is the QoS recovery time target, T i Adjust the time for resources that cause request queuing.

[0050] 3.2) If Figure 4 As shown in the figure, the request emptier allocates excess resources to each microservice so that the queued requests of each microservice are cleared just within the recovery time target, that is, the excess resource allocation is minimized while ensuring the recovery time target. The specific process is: use the linear regression model to predict the excess resources that need to be allocated to each microservice, and adjust the excess resource allocation of each microservice accordingly.

[0051] Preferably, when the QoS violation is eliminated, over-allocated resources are reclaimed in a timely manner to ensure high resource efficiency.

[0052] The QoS violation means that the 99th percentile delay of the microservice application exceeds a set fixed value, such as 100ms.

[0053] When new microservice dynamics are detected, the above process is repeated until the QoS of the microservice application is restored.

[0054] The dynamics of microservice applications refers to the total load of user requests and / or the changes in the proportion of different types of call graphs.

[0055] After specific practical experiments, in a specific environment setting with an 8-CPU cluster, configured with Intel(R) Xeon(R) CPU E5-2630 v4@2.20GHz and 256GB memory, 18 different dynamic load and dynamic call graph scenarios were evaluated, as follows: Figure 5As shown, when a user requests to enter a microservice application, first keep the existing resource allocation unchanged, and collect network indicators within the monitoring interval; network monitoring obtains the inlet network traffic / network packets of each microservice, and predicts the use of the monitored load when the network situation changes; the load updater calculates the blocking rate of the microservice application from top to bottom based on the blocking graph according to the monitoring load and other related indicators, and updates the real load, and adjusts the resources for the microservice application according to the real load; the request emptyer calculates the excess resource allocation required for each microservice according to the real load, the remaining QoS recovery time and other indicators, quickly restores the application QoS while ensuring resource efficiency, and adds excess resources for each microservice, and the above process is repeated according to a fixed cycle. The results obtained are: compared with the most advanced microservice resource management system, the present invention can reduce the QoS recovery time by more than 10 times; the use of network-based load monitoring can reduce the monitoring time by about 3 times; the use of a load updater that perceives blocking can reduce the resource adjustment time by about 2.6 times; the use of a resource-efficient request emptyer can reduce the queue clearing time by about 1.6 times.

[0056] In summary, compared with the current advanced microservice resource management system, this method can effectively reduce the QoS recovery time by more than 10 times.

[0057] The above-mentioned specific implementation can be partially adjusted in different ways by those skilled in the art without departing from the principle and purpose of the present invention. The protection scope of the present invention shall be based on the claims and shall not be limited by the above-mentioned specific implementation. Each implementation scheme within its scope shall be subject to the constraints of the present invention.

Claims

1. A microservice application optimization resource management system for dynamic characteristics, characterized in that: include: Network-based load monitor, blocking-aware load updater, and resource-efficient request cleaner. When microservice applications have dynamic load and call graph, the load monitor parses the network traffic and network packets based on the network monitoring data for each microservice, and predicts the monitored load through linear regression technology in machine learning. The load updater calculates the actual load to be processed for each microservice based on the monitored load and the blocking graph built through the call relationship and call sequence between microservices, and allocates the corresponding amount of resources to it; The request cleaner calculates the excess load of each microservice within the remaining QoS recovery time based on the real load of each microservice and the current resource allocation information output by the load updater, and allocates excess resources to each microservice to achieve the QoS goal of quickly restoring the application.

2. The microservice application optimization resource management system for dynamic characteristics according to claim 1 is characterized in that: The load monitor includes: a network monitoring unit and a monitoring load prediction unit, wherein: the network monitoring unit regularly monitors and counts the network packets and network traffic size between each pair of microservices according to the network IP and port information of each microservice, and obtains the upstream inflow network bandwidth and the number of network packets per second of each microservice; the monitoring load prediction unit uses a linear regression model to predict according to the network monitoring information to obtain the monitoring load of each microservice.

3. The microservice application optimization resource management system for dynamic characteristics according to claim 1 is characterized in that: The load updater includes: a load blocking graph construction unit, a real load updating unit, and a resource quantity prediction and allocation unit, wherein: the load blocking graph construction unit constructs and aggregates the substructure of the blocking graph according to the calling relationship and calling sequence information between microservices to obtain the load blocking graph of the microservice application; the real load updating unit calculates the microservice blocking rate and updates the real load according to the breadth-first search of the graph based on the monitoring load, load blocking graph, and existing resource allocation information of the microservice obtained by the load monitor to obtain the real load of all microservices; the resource quantity prediction and allocation unit uses a linear regression model to predict the required resource quantity of each microservice according to the real load, and makes corresponding allocation after obtaining the resource quantity.

4. The microservice application optimization resource management system for dynamic characteristics according to claim 1 is characterized in that: The request clearer includes: an excess load calculation unit and an excess resource prediction and allocation unit, wherein: the excess load calculation unit performs excess load calculation processing based on the remaining QoS recovery time, microservice resource shortage, and request queuing time information to obtain the excess load calculation result of each microservice; the excess resource prediction and allocation unit uses a linear regression model to perform excess resource quantity prediction processing based on the excess load information, obtains the excess resource quantity result and allocates resources accordingly.

5. A method for optimizing resource management of microservice applications based on the system according to any one of claims 1 to 4, characterized in that: include: 1) The load monitor periodically collects network metrics of microservice applications, uses the collected metrics to predict the monitoring load size of each microservice based on linear regression technology, and outputs the predicted monitoring load to the load updater; 2) The load updater obtains the real load to be processed of each microservice in advance according to the monitored load of each microservice from the load monitor and the processable load corresponding to the resource allocation, and allocates the corresponding amount of resources to it, thereby reducing the QoS violation time, including: 2.1) A blocking graph of the microservice application is constructed based on the dependencies and call order between microservices. Based on this blocking graph, the real load size of each microservice is quickly updated according to the monitored load of the microservice, the processable load corresponding to the resource allocation, and the blocking rate, and then just enough resources are allocated; the load updater constructs a microservice application load blocking graph based on the call relationship and dependency relationship between microservices; 2.2) Based on the above blocking graph construction algorithm / strategy, the load updater performs advance update of the real load to be processed. The specific process is as follows: i) Initialize the record triples of each microservice, build the blocking graph weight information, and initialize a queue for breadth-first search; ii) After putting the root microservice into the queue, update the actual load: Calculate the blocking rate of the first microservice j in the queue; Since the real load of the microservice at the head of the queue has been correctly updated, start processing j's downstream microservices, that is, for each downstream microservice k, first use j's blocking rate to update the real load from j to k, that is, the edge weight EW of the blocking graph jk =EW jk ×rate j , when all incoming edges of k have been updated, they are put into a queue to follow the breadth-first search until the queue is empty, and the update process ends, that is, the real load of all microservices has been updated; iii) predict the amount of CPU resources required by each microservice through the prediction model according to the actual load, allocate resources, and input the original microservice monitoring load, processable load, updated actual load and other indicators into the request clearer; 2.3) The load updater uses the real load updated in step 2.2 and uses the linear regression technology to predict the amount of CPU resources required by each microservice and allocates them. 3) The request processor calculates the total request queue of each microservice based on the request queue time, resource shortage and remaining QoS recovery time of each microservice in the real load of each microservice obtained in step 2.2, and allocates excess resources to each microservice to restore application QoS and ensure resource efficiency within the recovery time target, including: 3.1) The request server calculates the total number of requests queued for each microservice; 3.2) The request emptyer allocates excess resources to each microservice, which means: clearing the queued requests of each microservice just within the recovery time target, that is, minimizing the allocation of excess resources while ensuring the recovery time target; in order to allocate just enough excess resources to each microservice, the specific process is: using a linear regression model to predict the excess resources that need to be allocated to each microservice, and adjusting the excess resource allocation of each microservice accordingly.

6. According to the method for optimizing resource management of microservice applications oriented to dynamic characteristics of claim 5, in the initial construction state, the node weight in the blocking graph is the load size that each microservice can support, which is obtained by predicting the resource allocation in its current state through a linear model, and the edge weight in the blocking graph is the load size transmitted between microservices, which is constructed by simply calculating the load size supported by each microservice and the monitored load size according to the blocking relationship; The construction of the blocking graph based on the real load update mechanism is to start from the root node and gradually calculate the real load size of each microservice from top to bottom according to the blocking relationship and the blocking rate.

7. According to the method for optimizing resource management of microservice applications oriented to dynamic characteristics of claim 5, the construction of the microservice application load blocking graph is specifically carried out as follows: ① For microservices with multiple in-degrees, convert the subtree with it into multiple identical copies to maintain the tree structure of the initial dependency graph; ②Build a blocking relationship for each substructure: Microservices X and Y do not have a fixed call order from their common superior microservice. In this case, the blocking relationship is equivalent to the call dependency relationship between microservices. X is called by their common superior microservice before Y. In this case, Y's superior blocking microservice is the microservice at the end of the superior blocking subtree with X as the root; ③ Decompose the microservice dependency graph into multiple substructures, and then iteratively construct the upper-level blocking relationship from the root node microservice to obtain the final blocking graph of the overall microservice application.

8. According to the method for optimizing resource management of microservice applications oriented to dynamic characteristics in claim 5, the blocking rate of the microservice j is: in: MonitorLoad i It is obtained from the web-based load monitor, ActualLoad i Will be obtained by the update mechanism for each microservice update and will be equal to MonitorLoad at the beginning i , HandleLoad i The load that each microservice can handle is predicted from the resource allocation of its corresponding microservice using a linear regression model. Since the handleable load may be higher than the monitored load, the blocking rate is the actual load divided by the minimum value of the handleable load and the monitored load. In addition, when the microservice application is dynamic, the load of some microservices may decrease, resulting in a blocking rate that may be smaller than 1. At this time, this method regards the blocking rate as 1. The dynamics of microservice applications refer to: changes in the total load of user requests, changes in the proportion of different types of call graphs, and changes in the former two together.

9. According to the method for optimizing resource management of microservice applications oriented to dynamic characteristics in claim 5, the total request queue volume of each microservice is specifically as follows: i) Use monitoring load, processable load, and real load to calculate the excess load OverLoad of each microservice application during resource adjustment i =ActualLoad i -min(MonitorLoad i , HandleLoad i ); ii) When dynamic situations occur in microservice applications, for some microservices, their actual load may be less than or equal to their monitored load and processable load. Accordingly, the excess load is assigned to 0. After calculating the excess load, the total number of requests to be processed by each microservice in the remaining QoS recovery time is further calculated. i =OverLoad i ×T i +ActualLoad i ×(QT-T i )in: T i is the resource adjustment time that causes request queuing, QT is the QoS recovery time target, and in the total number of requests, the first item is the total number of queued requests, and the second item is the number of normal requests to be processed in the remaining time; iii) Calculate the total load to be processed during the remaining QoS recovery time Where: TotQuery i is the total number of requests to be processed, QT is the QoS recovery time target, T i Adjust the time for resources that cause request queuing.

10. According to the method for optimizing resource management of microservice applications oriented to dynamic characteristics of claim 5, when the QoS violation is eliminated, the over-allocated resources will be recovered in time to ensure high resource efficiency; The QoS violation means that the 99th percentile delay of the application exceeds a set fixed value.

Images