A multi-task perception-oriented micro-service deployment method

Abstract

This invention discloses a multi-task-aware microservice deployment method. Using microservices as vertices and the basic rules governing their call relationships, timing relationships, and constraints as directed edges, a graph model is established. The resource indicators of each microservice represented by a vertex are mapped to the weights of its outgoing edges, forming an Area of ​​Effect (AOE) network. Microservices undertaking critical tasks are identified according to their importance, and these, combined with the resource indicators of the remaining microservices, constitute a multi-task-aware deployment model based on the AOE network. A multi-task-aware deployment algorithm calculates priority paths composed of microservices from this model. Using a greedy approach, paths are preferentially allocated to cluster physical nodes with more remaining resources according to their priority. Finally, an optimized scheme for splitting and deploying the original microservice groups is provided based on the allocation results. This invention helps users complete deployment work flexibly and efficiently, thus solving the problem of difficult deployment.

Description

Technical Field

[0001] This invention relates to a microservice deployment method oriented towards multi-task awareness, belonging to the field of computer software technology. Background Technology

[0002] In traditional microservice-based distributed application deployment scenarios, if the remaining resources of the cluster's physical machine nodes are limited, the typical deployment method simply splits and deploys the microservices that make up the application based on their resource consumption and the remaining cluster resources, thereby ensuring load balancing and system availability as much as possible. This approach largely ignores the inherent characteristics of distributed applications, failing to consider the relationships between microservices during splitting, and neglecting to specifically handle microservices that perform critical tasks within the application. This can easily lead to redundancy in communication links between microservices and reduce application efficiency. Since traditional technologies cannot provide a very good solution to this problem, how to model distributed applications composed of microservices during deployment and split and deploy microservices according to certain principles has become an urgent problem to be solved in this field. Summary of the Invention

[0003] Purpose of the Invention: To address the problems and shortcomings of existing technologies, this invention provides a multi-task-aware microservice deployment method. When a group of interconnected microservices needs to be deployed but the remaining resources on all physical nodes in the cluster are exhausted, the method generates a deployment plan for the user. This plan satisfies the following: 1. Prioritize microservices within the microservice group that play critical roles in the upper-layer application for the user; 2. Allow the user to split the group of microservices and deploy them across multiple nodes according to the plan; 3. Ensure that the relationships between microservices are preserved as completely as possible, that microservices with close data exchanges are not excessively split, and that the cluster's operational efficiency is maximized.

[0004] Technical Solution: To help users flexibly and efficiently deploy a group of interconnected microservices to cluster nodes when facing a shortage of remaining resources on physical machine nodes, and to ensure the most efficient operation of the deployed system, a multi-task-aware microservice deployment method is proposed. This method organizes microservices using an AOE-based multi-task-aware deployment model, calculates priority paths composed of microservices using a multi-task-aware deployment algorithm, and then uses a greedy approach to prioritize and allocate resources to cluster physical machine nodes with more remaining resources. Finally, based on the allocation results, an optimized scheme for splitting and deploying the original microservice groups is provided. This method includes the following steps:

[0005] Step 1: Organize the microservices to be deployed into an AOE network model, and identify the microservices that meet the user's preset conditions according to their importance, forming a multi-task-aware deployment model based on the AOE network. The microservices that meet the user's preset conditions are called critical microservices. Meeting the user's preset conditions means that the user can define the microservices that undertake critical tasks. Generally, these critical microservices have a high priority for the stable operation of the entire cluster application, such as being in a critical position in the data flow between microservices, having a large amount of data throughput, requiring significant computing power, generating a large amount of temporary data, and being unable to tolerate frequent scheduling and redeployment. The definition can be extended by the user implementing the deployment, who can then specify the priority of each critical task undertaken during the subsequent deployment process.

[0006] Step 2: Combining the resource metrics of all microservices except the critical microservices, calculate a series of priority paths composed of microservices for the deployment model using a multi-task-aware algorithm.

[0007] Step 3: Using a greedy approach, prioritize each path and attempt to allocate resources to cluster physical machine nodes with more remaining resources. If a path cannot be fully deployed to a single node, try other nodes in sequence. If it still fails, continue splitting the path in half, keeping only the first half, until deployment is possible. If, during the trial allocation process, even splitting a path into only one microservice cannot result in deployment on any node, declare that the cluster has reached its limit and deployment is not feasible. If the entire trial allocation process is successful, provide an optimized solution for splitting and deploying the original microservice group based on the allocation results.

[0008] Step 1 includes the following steps:

[0009] Step 1.1: Using microservices as vertices and the basic rules such as call relationships, timing relationships, and constraint relationships between microservices as directed edges, establish a directed acyclic graph model.

[0010] Step 1.2: Map the resource metrics of the microservices represented by each vertex to the weights of their outgoing edges to form an AOE network (Activity On Edge Network).

[0011] Step 1.3: Identify all critical microservices with consecutive positive integers, starting from 1 and increasing in order of importance. These microservices with identification numbers are the key parts that will be given priority in the following algorithm.

[0012] Step 1.4: Add a vertex to the AOE network, pointing to all vertices with an in-degree of 0, and set all outgoing edge weights to 0. This vertex is the starting point. Then add another vertex to the AOE network, with all vertices with an out-degree of 0 pointing to this vertex, and set all incoming edge weights to 0. This vertex is the ending point. Finally, the AOE network with the starting and ending points is the multi-task-aware deployment model based on the AOE network.

[0013] Step 2 includes the following steps:

[0014] Step 2.1: Begin the multi-task awareness algorithm process. First, calculate the sum of resource metrics t of all microservices at this point. a Then, set the weight of all outgoing edges corresponding to the vertex of the key microservice to t. a Multiply by the number of identifiers for that key microservice.

[0015] Step 2.2: Find the critical path for the multi-task awareness deployment model based on AOE network, and remove the starting point, ending point and outgoing edge weights of 0 vertices in the critical path. Put the microservices represented by the vertices in the final path into queue M with microservices as elements in sequence. Then set the outgoing edge weights of all vertices in the path in the multi-task awareness deployment model based on AOE network to 0.

[0016] Step 2.3: Repeat the operation in 2.2 until the weights of all edges in the multi-task-aware deployment model based on AOE network are set to 0.

[0017] Step 2.4: Create a new linear list with microservices as elements. Continuously pop elements from queue M into the linear list until the out-degree of the vertex represented by the last popped microservice in the AOE-based multi-task-aware deployment model is greater than 1, or the in-degree of the vertex represented by the head of queue M in the AOE-based multi-task-aware deployment model is greater than 1, or queue M is empty. Then add the linear list to the tail of the double-ended queue T with the linear list as elements.

[0018] Step 2.5: Repeat the operation in 2.4 until queue M is empty. The resulting double-ended queue T contains a linear list of microservices as elements, which are paths composed of microservices with priority levels.

[0019] Step 3 includes the following steps:

[0020] Step 3.1: Create a maximum priority queue N with physical machine nodes as its elements. The key of the maximum priority queue N is the resource index of the node, and put all nodes into it.

[0021] Step 3.2: Pop the head n of the maximum priority queue N, pop the head t of the double-ended queue T, and check if n can accommodate t. If it can, subtract the CPU and memory consumed by t from the remaining CPU and memory of n. Then, insert n back into the maximum priority queue N and generate a deployment rule that deploys all microservices in t to n. Add this deployment rule to the rule set S, which is the deployment strategy. If not, continuously pop nodes from N and check if they can accommodate t until they can or the maximum priority queue N is empty. If the maximum priority queue N is empty, further divide t into two parts and check if the nodes popped out one after the other can accommodate the first half of t. If neither can, continue to divide the first half of t into two parts until it can. Insert the remaining second half back into the head of the double-ended queue T. Finally, insert all the popped nodes back into the maximum priority queue N. If even if only one microservice remains in the first half and it still cannot be deployed to any node, then the cluster state has reached its limit and deployment is not feasible.

[0022] Step 3.3: Repeat the operation in 3.2 until the double-ended queue T is empty or deployment is not feasible. If deployment is feasible, the set S consisting of deployment rules is the final deployment strategy.

[0023] Step 1.2 includes the following steps:

[0024] Step 1.2.1: In the process of handling multi-task-aware microservice deployment, it is necessary to simultaneously compare the CPU and memory resource consumption of the microservice and the remaining CPU and memory resources of the physical machine nodes. This can cause many inconveniences in the calculation process. Therefore, we define a resource metric, Score, which has linear additivity, to uniformly describe the resource consumption and remaining resource resources of a microservice or cluster physical machine node:

[0025] Score = Score C +Score M Formula 1

[0026]

[0027]

[0028] Assume a deployment consists of m microservices to be deployed and n available physical machine nodes, where Score C Score represents the score for CPU resources in resource metrics. M If the score for memory resources is represented in the resource metrics, then:

[0029] It represents the ratio of the CPU resources consumed by a microservice (or the remaining CPU resources of a node) to the total available CPU resources of the physical machine nodes in the cluster; This represents the ratio of the total CPU resources consumed by all microservices in this deployment to the total available CPU resources of the cluster's physical machine nodes. This ratio reflects the importance of CPU resources. C represents the remaining CPU resources of the k-th physical machine node. When Score calculates the resource metrics of a microservice i, C... i This represents the amount of CPU resources consumed by the microservice, where l = m; when the Score calculates the resource metrics of a physical machine node i, C i This represents the amount of CPU resources remaining on the physical machine node, where l = n.

[0030] This represents the ratio of the memory resources consumed by a microservice (or the remaining memory resources of a node) to the total available memory of the physical nodes in the cluster. This represents the ratio of the total memory resources consumed by all microservices in this deployment to the total available memory of the physical machine nodes in the cluster. This ratio reflects the importance of memory resources. M represents the remaining memory resources of the k-th physical machine node. When the Score calculates the resource metrics of a microservice i, M... i This represents the amount of memory resources consumed by the microservice, where l = m; when the Score calculates the resource metrics of a physical machine node i, M... i This represents the amount of memory resources remaining on the physical machine node, where l = n.

[0031] This invention offers the following advantages: It helps microservice system operators prioritize the deployment of critical microservices when cluster resources are running low, and rationally distributes the remaining microservices according to their structural principles. This ensures that the relationships between microservices are preserved as much as possible, that microservices with close data exchanges are not over-split, and that cluster efficiency is maximized. Compared to the naive method of deploying based solely on microservice resource consumption and cluster resource availability, this reduces communication redundancy and improves the operational efficiency of distributed applications. Attached Figure Description

[0032] Figure 1 This is a schematic diagram of the method in an embodiment of the present invention;

[0033] Figure 2 This is a multi-task perception deployment model based on AOE network in this embodiment of the invention (without edge weights assigned);

[0034] Figure 3 This is a multi-task perception deployment model based on AOE network in this embodiment of the invention (without starting and ending points);

[0035] Figure 4 This is a multi-task awareness deployment model based on AOE network in this embodiment of the invention;

[0036] Figure 5 This is a preliminary transformation of the model by the multi-task-aware deployment algorithm in this embodiment of the invention;

[0037] Figure 6 This is the transformation result of the multi-task-aware deployment algorithm on the model in this embodiment of the invention;

[0038] Figure 7 This is a flowchart illustrating the detailed steps in step 3 of the present invention. Detailed Implementation

[0039] The present invention will be further illustrated below with reference to specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. After reading the present invention, any modifications of the present invention in various equivalent forms by those skilled in the art will fall within the scope defined by the appended claims.

[0040] A multi-task-aware microservice deployment method addresses the core problem of how to generate a deployment scheme when a group of interconnected microservices needs to be deployed but the remaining resources on all physical nodes in the cluster are exhausted. This scheme should satisfy the following requirements: 1. Prioritize microservices within the microservice group that play critical roles in the upper-layer application for the user; 2. Allow the user to split and deploy the group of microservices across multiple nodes based on this scheme; 3. Ensure that the relationships between microservices are preserved as closely as possible, that microservices with close data exchanges are not excessively split, and that the cluster's operational efficiency is maximized. The solution proposed in this invention is as follows: A graph model is established using microservices as vertices and the basic rules governing their call relationships, timing relationships, and constraints as directed edges. The resource metrics of each microservice represented by a vertex are mapped to the weights of its outgoing edges, forming an AOE (Activity On Edge Network). Microservices undertaking critical tasks are identified according to their importance, and these, combined with the resource metrics of the remaining microservices, constitute a multi-task-aware deployment model based on the AOE network. A multi-task-aware deployment algorithm calculates priority paths composed of microservices for this model. Using a greedy approach, paths are prioritized and allocated to cluster physical nodes with more remaining resources. Finally, an optimized scheme for splitting and deploying the original microservice groups is provided based on the allocation results. Simultaneously, the feasibility and rationality of the deployment scheme are verified, helping users complete deployment work flexibly and efficiently, thus solving the problem of difficult deployment for users.

[0041] In a cluster with limited remaining CPU and memory resources, when a microservice-based distributed application needs to be deployed immediately to provide services, but other applications already deployed in the cluster are performing critical tasks and cannot be unloaded to provide resources, forcing the distributed application to be deployed only to the remaining three nodes, a comprehensive deployment plan is needed, taking into account the characteristics of the application architecture and the remaining resources on the three nodes, to achieve maximum resource utilization and ensure the application runs as efficiently as possible. This requires a complete and effective deployment methodology to generate a deployment plan for this specific situation.

[0042] Step 1: Organize the microservices to be deployed into an AOE network model, and identify the microservices that meet the user's preset conditions according to their importance, forming a multi-task-aware deployment model based on the AOE network. These microservices that meet the user's preset conditions are called critical microservices. Meeting the user's preset conditions means that the user can define the microservices that undertake critical tasks. Generally, these critical microservices have a high priority for the stable operation of the entire cluster application, such as being in a critical position in the data flow between microservices, having a large amount of data throughput, requiring significant computing power, generating a large amount of temporary data, and being unable to tolerate frequent scheduling and redeployment. The definition can be extended by the user implementing the deployment, who can then specify the priority of each critical task undertaken during the subsequent deployment process.

[0043] Table 1

[0044] Microservice Name Subsequent calls (information flow) Requires CPU resources (microprocessor / CPU) Required memory resources (MB) Microservice a1 Microservice A2 250 128 Microservice A2 microservice d1 250 128 Microservices b1 Microservices b2 250 128 Microservices b2 microservice d1 250 128 User Entry Microservices C1 300 128 Microservices C1 microservices d2 250 128 microservice d1 microservices d2 250 128 microservices d2 Microservice d3, Microservice e1 250 128 Microservices d3 Comprehensive analysis, microservices g1 250 128 Microservices e1 Data processing 250 128 Data processing microservices e2 350 256 microservices e2 microservices f2 250 128 Comprehensive analysis Microservices F1 400 256 Microservices F1 microservices f2 250 128 microservices f2 none 250 128 microservices g1 microservices g2 250 128 microservices g2 microservices f2 250 128

[0045] Table 2

[0046] Node Name Available CPU resources (milicpu) Available memory resources (MB) Node 1 1750 1024 Node 2 1750 1024 Node 3 1750 1024

[0047] As shown in Table 1, which describes the distributed application of this microservice architecture, and in Table 2, which describes the remaining resource status of available nodes in the physical machine cluster, a directed acyclic graph model is first established, with microservices as vertices and the basic rules governing the call relationships, timing relationships, and constraints between microservices as directed edges. Figure 2 As shown.

[0048] Next, the resource metrics of the microservices represented by each vertex are mapped to the weights of their outgoing edges, forming an AOE network, such as... Figure 3 As shown.

[0049] All critical microservices are identified using consecutive positive integers, starting from 1 and increasing in order of importance. These microservices with assigned numbers are the key components that will be prioritized in the subsequent algorithm. Here, we assume that the three microservices "User Entry," "Data Processing," and "Comprehensive Analysis" perform critical tasks in the entire system and should be prioritized for deployment, with their importance increasing sequentially. Therefore, their assigned numbers are 1, 2, and 3, respectively.

[0050] Add a vertex to the AOE network, pointing to all vertices with an in-degree of 0, and set all outgoing edge weights to 0. This vertex is the starting point. Then add another vertex to the AOE network, with all vertices with an out-degree of 0 pointing to this vertex, and set all incoming edge weights to 0. This vertex is the ending point. The final model, with the starting and ending points added, is the multi-task-aware deployment model based on the AOE network, as shown below. Figure 4 As shown.

[0051] Step 2: Combining the resource metrics of all microservices except the critical microservices, a multi-task-aware algorithm is used to calculate a series of priority paths composed of microservices for the deployment model.

[0052] The multi-task awareness algorithm begins by calculating the sum of resource metrics t for all microservices at this point. a , to obtain t a The value is 12.400625. Then, the weights of all outgoing edges from the vertex corresponding to the key microservice are set to t. a Multiplying by the identifier number of the key microservice, the outbound weights of the three microservices, "User Entry", "Data Processing", and "Comprehensive Analysis", become 12.400625, 24.801250, and 37.201875, respectively.

[0053] The critical path is calculated for the AOE-based multi-task-aware deployment model. Vertices with a start, end, and outgoing edge weight of 0 are removed from the critical path. The microservices represented by the vertices in the final path are sequentially placed into a queue M containing microservices. Then, the outgoing edge weights of all vertices in this path are set to 0. This process is repeated until all edge weights in the AOE-based multi-task-aware deployment model are set to 0. At this point, the elements in queue M should be arranged as follows: User Entry, Microservice c1, Microservice d2, Microservice d3, Comprehensive Analysis, Microservice f1, Microservice f2, Microservice a1, Microservice a2, Microservice d1, Microservice e1, Data Processing, Microservice e2, Microservice b1, Microservice b2, Microservice g1, Microservice g2, etc. Figure 5 As shown.

[0054] Create a new linear list with microservices as elements. Continuously pop elements from queue M into the linear list until the out-degree of the vertex represented by the last popped microservice in the AOE-based multi-task-aware deployment model is greater than 1, or the in-degree of the vertex represented by the head of queue M in the AOE-based multi-task-aware deployment model is greater than 1, or queue M is empty. Then, add this linear list to the tail of a double-ended queue T with linear list elements. Repeat the above operation until queue M is empty. The final double-ended queue T contains linear lists with microservices as elements, which are paths composed of microservices with priority levels. At this point, the elements in the double-ended queue T are as follows: Figure 6 As shown.

[0055] Step 3: Using a greedy approach, prioritize the cluster physical machine nodes with more remaining resources according to the priority level of each path, and establish a maximum priority queue N with physical machine nodes as the elements. The key of the maximum priority queue N is the resource index of the node, and all nodes are placed into it.

[0056] Pop the head of the maximum priority queue N, n, and the head of the double-ended queue T, t. Check if n can accommodate t. If it can, subtract the CPU and memory consumed by t from the remaining CPU and memory of n. Then, insert n back into the maximum priority queue N and generate a deployment rule that deploys all microservices in t to n. Add this deployment rule to the rule set S, which is the deployment strategy. If not, continuously pop nodes from N and check if they can accommodate t until they can or the maximum priority queue N is empty. If the maximum priority queue N is empty, further divide t in half and check if the nodes popped first and second can accommodate the first half of t. If neither can, continue to divide the first half of t in half until it can. Insert the remaining second half back into the head of the double-ended queue T. Finally, insert all the popped nodes back into the maximum priority queue N. If even if only one microservice remains in the first half and it still cannot be deployed to any node, the cluster state is declared to have reached its limit and deployment is not feasible.

[0057] Repeat the above operations until the double-ended queue T is empty or deployment is not feasible. If deployment is feasible at this point, the set S consisting of deployment rules is the final deployment strategy. The above process is as follows: Figure 7 As shown.

Claims

1. A method for multi-task-aware micro-service deployment, characterized in that, The method comprises the following steps: Step 1: organizing the microservice group to be deployed in the form of an AOE network model, and identifying the microservices meeting the preset conditions of the user according to their respective importance to form a multi-task-aware deployment model based on the AOE network, and the microservices meeting the preset conditions of the user are referred to as key microservices; Step 2: combining the resource indicators of the remaining microservices except the key microservices, and calculating a path composed of microservices with priority levels through a multi-task-aware algorithm for the deployment model; Step 3: performing trial allocation on the cluster physical machine nodes with more remaining resources in priority according to the priority levels of the paths in a greedy principle, if a path cannot be completely deployed on a node, then sequentially trying other nodes, if it still cannot be deployed, then continuously splitting the path by half to reserve the first half until it can be deployed, if the path is split into only one microservice and it still cannot be deployed on any node, then it is declared that the cluster state has reached the limit and the deployment is not feasible, if the trial allocation process is successful, then an optimization scheme for splitting and deploying the original microservice group is finally given according to the allocation result.

2. The microservice deployment method for multi-task awareness according to claim 1, wherein, The step 1 comprises the following steps: Step 1.1: establishing a directed acyclic graph model with microservices as vertices and the calling relationship, timing relationship and constraint relationship between the microservices as directed edges; Step 1.2: mapping the resource indicators of the microservices represented by the vertices to the weights of the outgoing edges to form an AOE network (Activity On Edge Network); Step 1.3: identifying all the key microservices with consecutive positive integers, starting from 1 and sequentially increasing according to the importance, and these microservices with identification numbers are the key parts to be considered preferentially in the subsequent algorithm; Step 1.4: adding a vertex to the AOE network, the vertex points to all vertices with an in-degree of 0, and the weight of all outgoing edges is set to 0, and the vertex is the starting point; and adding another vertex to the AOE network, all vertices with an out-degree of 0 point to the vertex, and the weight of all incoming edges of the vertex is set to 0, and the vertex is the end point; and finally adding the starting point and the end point to the AOE network to form a multi-task-aware deployment model based on the AOE network.

3. The microservice deployment method for multi-task awareness according to claim 1, wherein, The step 2 comprises the following steps: Step 2.1: Start entering the multi-task-aware algorithm flow, first calculate the sum of resource indicators of all microservices at this time t a Then set the weight of all outgoing edges of the vertex corresponding to the microservice as the key task to t a Multiply the identification number of the microservice; Step 2.2: finding the critical path of the multi-task-aware deployment model based on the AOE network, removing the starting point, the end point and the vertices with an outgoing edge weight of 0 in the critical path, and sequentially putting the microservices represented by the vertices in the final path into a queue M with microservices as elements, and setting the outgoing edge weights of all vertices in the path in the multi-task-aware deployment model based on the AOE network to 0; Step 2.3: repeating the operation in 2.2 until the weights of all edges in the multi-task-aware deployment model based on the AOE network are set to 0; Step 2.4: A linear list with microservices as elements is created, and elements in the queue M are continuously popped into the linear list until the last popped microservice has an out-degree greater than 1 in the AOE-based multi-task-aware deployment model or the head of the queue M has an in-degree greater than 1 in the AOE-based multi-task-aware deployment model or the queue M is empty, and then the linear list is added to the tail of the double-ended queue T with linear lists as elements; Step 2.5: The operation in 2.4 is repeated until the queue M is empty, and the linear lists with microservices as elements stored in the double-ended queue T in sequence are finally obtained, which are paths with priority levels and composed of microservices.

4. The microservice deployment method for multi-task awareness according to claim 1, wherein, The step 3 includes the following steps: Step 3.1: A maximum priority queue N with physical machine nodes as elements is established, and the key is the resource index of the node, and all nodes are put into the queue; Step 3.2: The head n of the maximum priority queue N is popped, and the head t of the double-ended queue T is popped, and it is checked whether n can accommodate t, if yes, the remaining CPU and memory of n are reduced by the CPU and memory consumed by t, then n is inserted back into the priority queue N, and a deployment rule of deploying all microservices in t on n is generated, and the deployment rule is added to the rule set S, and the set S is the deployment strategy; if not, nodes are continuously popped from N, and it is checked whether t can be accommodated, until it can be accommodated or the queue is empty, if the queue is empty, t is further divided into two parts, and it is checked whether the nodes popped in sequence can accommodate the first half of t, if not, t is further divided into two parts based on the first half, until it can be accommodated, the remaining second half is inserted into the head of the double-ended queue T, and finally all the popped nodes are inserted into the priority queue N, if the first half still cannot be deployed on any node even if there is only one microservice in the first half, it is declared that the cluster state has reached the limit, and the deployment is not feasible; Step 3.3: The operation in 3.2 is repeated until the double-ended queue T is empty or the deployment is not feasible, and at this time, if the deployment is feasible, the set S composed of the deployment rules is the final deployment strategy.

5. The microservice deployment method for multi-task awareness according to claim 2, wherein, The step 1.2 includes the following steps: Step 1.2.1: In the process of processing the microservice deployment oriented to multi-task awareness, it is necessary to compare the consumption of microservice CPU resources and memory resources and the remaining amount of physical machine node CPU resources and memory resources at the same time, and define a resource index with linear additivity to uniformly describe the resource consumption and resource remaining amount of a certain microservice or cluster physical machine node: Formula 1 Formula 2 Formula 3 Let’s denote that in a once deployment there are microservices to be deployed, physical machine nodes available, where represents the score of CPU resource in the resource indicator, represents the score of memory resource in the resource indicator, then: This represents the ratio of the CPU resources consumed by a microservice or the remaining CPU resources of a node to the total available CPU resources of all physical nodes in the cluster. This represents the ratio of the total CPU resources consumed by all microservices in this deployment to the total available CPU resources of the physical machine nodes in the cluster. This ratio reflects the importance of CPU resources; It indicates the first The remaining CPU resources of the physical machine nodes, when The calculation is for a certain microservice When considering resource indicators, This indicates the amount of CPU resources consumed by the microservice. ;when The calculation is performed on a certain physical machine node. When considering resource indicators, This represents the amount of CPU resources remaining on that physical machine node. ; represents the ratio of the memory resource consumed by the microservice or the remaining memory resource of a node to the total available memory of the cluster physical machine node; represents the ratio of the total memory resource consumed by all microservices in this deployment to the total available memory of the cluster physical machine node, which reflects the importance of memory resources; wherein represents the remaining memory resource amount of the first physical machine node, when the resource index of a certain microservice is calculated, represents the memory resource amount consumed by the microservice, at this time ; when the resource index of a certain physical machine node is calculated, represents the remaining memory resource amount of the physical machine node, at this time .

Images