Micro-service deployment method and system in edge cloud environment

Abstract

The invention discloses a micro-service deployment method and system in an edge cloud environment, relates to the field of micro-service deployment, and is used for reducing the total cost of micro-service deployment in a cloud native environment. Under the limitation of node resources, various deployment models for deploying micro-services required by an application program to a plurality of given nodes respectively are constructed, and for each deployment model, at least two micro-services with a sharing layer are deployed to the same node; and solving a deployment scheme through a genetic algorithm based on the constructed deployment model by taking minimization of the total cost of deployment as a target. According to the invention, the deployment cost, deployment time and communication cost of the micro-service can be effectively reduced, and the calculation efficiency of the deployment scheme is high.

Description

Technical Field

[0001] The present invention relates to the field of microservice deployment, and in particular to a microservice deployment method and system in an edge cloud environment. Background Art

[0002] The emergence and development of microservice technology has reduced the difficulty of application development and maintenance and improved the reusability of functional modules. The emergence of cloud-native computing has changed the development model of applications. It decouples traditional single-chip microcomputers into many dependent microservices. Cloud-native has the characteristics of continuous integration, lightweight, and easy deployment. With the development and popularization of cloud computing technology, more and more organizations choose to deploy microservices on cloud platforms. Cloud platforms provide elastic computing resources and automated management tools to meet the needs of microservice architecture for dynamic resource adjustment and rapid deployment. As a lightweight virtualization technology, containers have the advantages of continuous integration and easy deployment, and are widely used to support various microservices.

[0003] Microservice technology ensures continuous delivery and deployment by decoupling applications into multiple independently developed and maintained microservices and deploying them in containers. Container-based microservice cloud deployment brings about the concepts of cloud-native edge computing and edge cloud-native. Compared with the central cloud, the edge cloud is widely distributed and has relatively limited resources.

[0004] Although containers are lightweight, pulling and starting large container images still consumes a lot of resources, especially in edge clouds with relatively limited resources. Pulling microservice containers consumes a lot of traffic and brings high deployment costs. At the same time, the longer microservice container pull time increases the microservice startup time, and the pull delay seriously affects the service quality and user experience. The complex call relationship of microservices will generate communication costs when the application is running. When a large number of microservices work together, the call chains between microservices constitute the microservice call graph. These call relationships will increase runtime traffic consumption and affect the performance of microservice deployment. Summary of the invention

[0005] The purpose of the present invention is to provide a microservice deployment method and system in an edge cloud environment to address all or part of the above-mentioned problems, so as to reduce the total cost of microservice deployment in a cloud-native environment.

[0006] The technical solution adopted by the present invention is as follows:

[0007] A microservice deployment method in an edge cloud environment, comprising:

[0008] Under the node resource constraints, build multiple deployment models to deploy each microservice required by the application to multiple given nodes. For each deployment model, deploy at least two microservices with a shared layer to the same node.

[0009] Based on the constructed deployment model, a deployment plan is solved with the goal of minimizing the total deployment cost; the total deployment cost includes the cost of deploying all microservices to each node, the communication cost between microservices after deployment is completed, and the time cost of deploying all microservices.

[0010] Further, the deploying of at least two microservices shared by the existence layer to the same node includes:

[0011] Traverse all microservices and deploy as many microservices with shared layers as possible to the same node.

[0012] Furthermore, deploying as many microservices with a shared layer as possible to the same node includes:

[0013] For the microservice to be deployed, traverse all nodes and deploy the microservice to be deployed on the node where the shared layer has been deployed.

[0014] Furthermore, the step of deploying at least two microservices having a shared layer to the same node includes:

[0015] According to the calling relationship between each microservice, the microservice call graph is divided into microservice call subgraphs, and the microservice call graph reflects all the calling relationships between all microservices;

[0016] At least two microservices in the same call chain in at least one microservice call subgraph are deployed to the same node.

[0017] Furthermore, the microservice call graph is divided into microservice call subgraphs according to the call relationship between the microservices, including:

[0018] According to the calling relationship between each microservice, a depth-first search method is adopted to divide the microservice calling subgraphs one by one from the microservice calling graph.

[0019] Furthermore, the method for constructing the deployment model includes:

[0020] Randomly deploy the microservices required by the application to a given plurality of nodes, wherein at least two microservices with a shared layer are deployed to the same node;

[0021] Based on the resource limits of each node, microservices that exceed the node resource limits are randomly deployed to other nodes that can accommodate the microservices.

[0022] Furthermore, a genetic algorithm is used to solve the deployment plan.

[0023] Furthermore, the use of a genetic algorithm to solve a deployment solution includes:

[0024] Initialize the population with multiple deployment models, and use the total deployment cost as the fitness to obtain the population individuals with the best fitness;

[0025] Perform iterative evolution operations on the population and obtain the individuals with the best fitness in each round of iteration;

[0026] The best fitness individual among all the best fitness individuals in the population is taken as the deployment solution.

[0027] Furthermore, in the iterative evolution operation on the population, if there are population individuals that do not meet the node resource limit, the microservices in the population individuals that exceed the node resource limit are randomly deployed to other nodes that can accommodate the microservices.

[0028] The present invention also provides a microservice deployment system in an edge cloud environment, including a processor and a storage medium, wherein the storage medium stores computer instructions; when the processor runs the computer instructions, it can execute the above-mentioned microservice deployment method in the edge cloud environment.

[0029] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are:

[0030] The microservice deployment solution designed in the edge cloud environment of this application is based on the resource-constrained characteristics of deploying microservices on the edge cloud. Taking into account the layered architecture of container design, the microservices with shared layers are deployed on the same node, thereby effectively reducing the traffic consumption when pulling container images, reducing the deployment cost and communication cost of microservices, and speeding up the startup of microservices and reducing deployment time. In addition, according to the microservice call graph, this application uniformly deploys microservices belonging to the same microservice call subgraph, while improving the sharing rate of the microservice container base layer, and minimizing the call chain between nodes, thereby reducing the complexity of the optimized deployment solution as much as possible and improving the efficiency of the algorithm. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The present invention will now be described by way of example with reference to the accompanying drawings, in which:

[0032] Figure 1 This is a comparison chart of container image pull traffic when the microservice is deployed in layer sharing or not in the embodiment of the present application.

[0033] Figure 2 It is a schematic diagram of communication cost generation after microservice deployment in an embodiment of the present application.

[0034] Figure 3 It is a structural diagram of the chromosome encoding in the examples of this application.

[0035] Figure 4 This is a result diagram of chromosome decoding in the examples of this application.

[0036] Figure 5 This is a comparison chart of the solution time under different microservice scales with or without solution space reduction in the embodiment of the present application.

[0037] Figure 6 It is a diagram of the sensitive experimental results of the crossover rate and mutation rate during the evolution process in the embodiments of the present application. DETAILED DESCRIPTION

[0038] All features disclosed in this specification, or steps in all methods or processes disclosed, except mutually exclusive features and / or steps, can be combined in any manner.

[0039] Any feature disclosed in this specification (including any additional claims and abstract), unless otherwise stated, may be replaced by other equivalent or alternative features having similar purposes. That is, unless otherwise stated, each feature is only an example of a series of equivalent or similar features.

[0040] In the current research on microservice deployment, most of them only model microservices as lightweight virtual machines, using the characteristics of simple development and easy maintenance of microservices to reduce the difficulty of application development. Few people consider the deployment performance of microservices, especially the deployment cost.

[0041] In the cloud deployment of microservices, microservice startup is mainly limited by container pull, which consumes 76.6% of the microservice startup time. For example, when deploying a MySQL container, 500-600M of pull traffic will be generated. However, the life cycle of a microservice is only a few minutes. The long microservice container pull delay seriously affects the service quality and user experience. At the same time, the traffic consumed by container pull also brings high deployment costs. This problem is more prominent in the case of highly distributed and relatively limited resource edge clouds. At the same time, there are complex call relationships between microservices. Frequent interactions between microservices will generate communication costs between nodes. When a large number of microservices work together, a large number of microservice call chains constitute the microservice call graph, and too many call chains between nodes will invisibly increase the communication cost. The above deployment costs and communication costs are the main components of the total cost of microservice deployment.

[0042] The Chinese patent document with publication number CN118337640A provides a method for deploying microservices in collaboration with cloud and multi-edge network nodes, which includes the following steps: the first step is to model the network topology structure of cloud and multi-edge network nodes and the application composed of microservice nodes, distributed databases, and multiple complex communication methods, and obtain the microservice deployment model of cloud and multi-edge network nodes. The second step is to build a reinforcement learning training environment and deployment scheme evaluation index of the microservice deployment model based on the network topology structure and microservice deployment model of cloud and multi-edge network nodes to optimize the end-to-end delay, resource consumption, and deployment success rate of the microservice application deployment structure as the optimization goal. The third step is to train the microservice deployment model based on the Thompson sampling exploration mechanism of the clipped Gaussian approximation and the reinforcement learning algorithm of the qualification tracking strategy of multi-step training to obtain a converged microservice deployment model of cloud and multi-edge network nodes. The method solves the problem of microservice deployment in the scenario of cloud and multi-edge network node collaboration by designing a reinforcement learning algorithm based on the Thompson sampling exploration strategy of the clipped Gaussian approximation and the qualification tracking mechanism to minimize resource consumption on the basis of meeting the end-to-end delay. However, this method lacks consideration of the communication costs after deployment. The frequent calls of subsequent microservices will lead to increased communication costs between nodes, increased communication latency, high operating costs, and reduced service quality to a certain extent.

[0043] The Chinese patent document with publication number CN117573379A provides a microservice deployment method based on symmetric scaling and merging, which includes: the first step: according to the predicted user request traffic and the processing capacity of a single core of the server for each microservice, the number of cores initially allocated to each microservice is calculated, and the microservice group is initialized and generated, and the symmetric merge algorithm is used to obtain the symmetric merged microservice group; the second step: according to the microservice group obtained by the symmetric merge, the total number of server cores used in the current deployment scheme is counted; the third step: using the instance expansion algorithm, the microservice instance in each microservice group is expanded to obtain the microservice group after the instance is expanded and shrunk; the fourth step: according to the relevant theories of queuing theory, the request arrival rate at each microservice is calculated, and the deployment status of each microservice in the microservice group obtained after the instance is expanded and shrunk is counted, and the request traffic at each microservice is equally divided into each microservice group to complete the equal-division routing; the fifth step: according to the microservice group after the instance is expanded and shrunk, the total number of servers used in the current deployment scheme is counted. If the total number of servers currently used exceeds the number of available servers, the migration and merging algorithm is used to migrate the microservice group that needs to be migrated to other microservice groups. This method no longer considers routing problems separately, and is efficient in solving them. It also solves microservice deployment and request routing problems together, and directly solves them globally to obtain the best solution, reduce user request latency, maximize request success rate, and improve user experience. However, this method does not take into account the hierarchical structure of containers when calculating the deployment of microservices. The calculated deployment solution pulls high traffic and takes a long time to pull, which increases the deployment time of microservices.

[0044] In general, existing microservice deployment methods do not fully consider the traffic pulled by microservices in containers, the deployment time of microservices, or the communication costs caused by calls after microservice deployment, resulting in poor deployment performance.

[0045] In the currently popular container technologies such as Docker, a layered structure is adopted, and some basic layers can be shared between different microservices, such as Figure 1 As shown, the shared layer does not need to be pulled repeatedly. Based on this phenomenon, the embodiment of the present application provides a microservice deployment method and system in an edge cloud environment, aiming to improve the performance of microservice deployment in terms of total deployment cost.

[0046] The following are the parameter definitions involved in the embodiments of this application:

[0047] 1) Define the node set {N, E}, where N is the node set and E is the edge set. The relevant attribute definitions of the microservice deployment node are shown in Table 1.

[0048] Table 1 Definition of properties related to microservice deployment nodes

[0049]

[0050] 2) Define the set of microservice layers as L, and the definitions of the related attributes of the microservice layer structure are shown in Table 2.

[0051] Table 2 Definition of properties related to microservice layer structure

[0052] <![CDATA[l k ]]> <![CDATA[The size of layer k, l k ∈L]]>

[0053] 3) Define the microservice set {M, H}, where M is the set of microservice containers and H is the set of call relationships. The definitions of microservice related attributes are shown in Figure 3.

[0054] Table 3 Definition of microservice related attributes

[0055]

[0056]

[0057] Before introducing the microservice deployment method, the optimization index of this application, namely the total deployment cost, is explained. The total deployment cost involves the resource and time consumption when deploying microservices and the resource consumption after deploying microservices. The consumption of each part is respectively called: deployment cost, deployment time and communication cost.

[0058] 1) Deployment cost.

[0059] The deployment cost is the traffic cost of all microservices when they are deployed. It can be obtained by calculating the deployment traffic of each node and summing them up. For the deployment traffic consumed by a single node, calculate whether each microservice needs to be deployed on the node. If deployed on the node, the traffic consumed is the traffic pulled by the microservice container minus the sharable layer traffic. It is calculated using formula 1.1.

[0060]

[0061] 2) Communication costs.

[0062] The communication cost is the expected value of the communication time per unit time after the microservice deployment is completed, such as Figure 2 The figure shows the schematic diagram of the communication cost between microservices. In the specific calculation, a microservice has one or more containers. When there are multiple containers, the probability of each container being called is equal. Calculate whether each node is deployed with the corresponding microservice container, and divide it by the total number of corresponding microservice containers to get the probability of being called. Then multiply it by the microservice communication delay to get the expected value of the communication delay between a pair of microservices. The sum can be used to get the communication cost. It is calculated by formula 1.2.

[0063]

[0064] In addition, the communication cost may also be the total amount of data expected to be transmitted per unit time.

[0065] 3) Deployment time.

[0066] The deployment time is the total time from the start of deploying the microservice to the completion of the deployment. The total time depends on the node that takes the longest time to deploy. Therefore, according to the traffic consumption of each node, divided by the communication bandwidth between the node and the Docker hub, the maximum value is the deployment time. It is calculated by formula 1.3.

[0067]

[0068] In addition, the deployment time can also be the total time for all nodes to deploy microservice containers and start them.

[0069] During the calculation, the deployment cost, communication cost and deployment time also need to be normalized and added together. Then, the three-objective optimization problem is converted into a single-objective optimization problem with the goal of minimizing the total deployment cost.

[0070] The target problem is expressed as:

[0071] minα deployment cost + β communication cost + λ deployment time (1.4)

[0072] Where α, β, and λ are the normalized weights of the corresponding costs.

[0073] At the same time, the resources of a single node are limited. When deploying microservices, the resources are limited by the computing resources and memory resources of the node. It is necessary to make the resources required by all microservices deployed on the node less than the total resources of the node. At the same time, all microservices need to be deployed, and the constraint conditions such as formula 1.5 can be obtained.

[0074]

[0075] The microservice deployment method in the edge cloud environment provided by this application includes:

[0076] S1. Under the constraint of node resources, build multiple deployment models to deploy each microservice required by the application to multiple given nodes. For each deployment model, deploy at least two microservices with a shared layer to the same node. This can effectively reduce the amount of container image pull traffic for each deployment model, and the final deployment solution also has this feature.

[0077] As an optional implementation, in the above-mentioned multiple deployment models for building each microservice required by the application to be deployed to a given plurality of nodes respectively, the method for building each deployment model includes:

[0078] S1.1. Randomly deploy each microservice required by the application to a given plurality of nodes. At least two microservices with a shared layer are deployed to the same node to save deployment costs.

[0079] S1.2. According to the resource limit of each node, randomly deploy the microservices that exceed the node resource limit to other nodes that can accommodate the microservices. Edge cloud deployment has the characteristics of resource limit. The resources (CPU resources and memory resources) of each node are limited, and only a limited number of microservices can be deployed. Since the available resources of each node are different, the resources occupied by each microservice are different, and the number of microservices that can be deployed on each node cannot be clearly defined. Therefore, after randomly deploying microservices, the microservices deployed on a certain node may exceed the resource tolerance of the node. This deployment model is an infeasible deployment model. For infeasible deployment models, the microservices that exceed the node resources are removed and randomly deployed to other idle nodes (referring to those with idle resources) to ensure that each deployment model is feasible, so that there is optimization value.

[0080] The above-mentioned deployment of at least two microservices with shared layers to the same node is for the purpose of saving container image pull traffic. The shared layer between microservices only needs to be pulled once, so deploying microservices with shared layers on the same node can effectively save container image pull traffic. In some optional implementations, the deployment process includes:

[0081] S1.3. Traverse all microservices and deploy as many microservices with shared layers as possible to the same node.

[0082] The microservices required by the application may have multiple microservices sharing the same basic layer. If these microservices are deployed on different nodes, the container images need to be pulled separately when deploying the microservice containers. When these microservices are deployed to as few nodes as possible, that is, when as many microservices with shared layers as possible are deployed on the same node, repeated pulling traffic can be saved to the greatest extent.

[0083] The deployment of microservices does not have to be performed simultaneously. In some embodiments, for the microservice to be deployed, all nodes are traversed and the microservice to be deployed is deployed to the node where the shared layer is already deployed. If there is more than one such node, the microservice to be deployed is deployed to any of the nodes to save the pull traffic. As a preferred method, the microservice to be deployed is deployed to the node where the most shared layers are already deployed to maximize the saving of pull traffic.

[0084] In addition, the present application also takes into account the communication cost between nodes after the microservices are deployed, which is mainly determined by the number of microservice call chains between nodes and network latency.

[0085] As an optional implementation, when building a deployment model, the microservice call graph is divided into microservice call subgraphs according to the call relationship between the microservices, and at least two microservices in the same call chain in at least one microservice call subgraph are deployed to the same node.

[0086] The communication cost of a microservice is only related to the microservice with which data transmission exists, and there is a call chain between the microservices with which data transmission exists. As described above, the call relationship between all microservices forms a microservice call graph. Only microservices in the same call chain have communication costs, and the microservices with call chains have different network delays for data transmission due to different nodes to which they belong, and the resulting communication costs are also different. As many microservices with call chains as possible can be deployed to the same node, the call chains between nodes can be reduced, thereby reducing the complexity of the optimized deployment scheme, reducing the size of the solution space, and improving the efficiency of solving the deployment scheme. In addition, the network delay of microservice calls can be reduced as much as possible to reduce communication costs. In some specific embodiments, for each microservice call subgraph, as many microservices as possible are deployed to as few nodes as possible under the resource constraints of each node. For example, all microservices in a microservice call subgraph are deployed according to the connection order of the call chain. First, a node is selected for deployment. After the resources of the node are consumed, the next node is selected for deployment, and so on.

[0087] For each microservice call subgraph, in an optional implementation, according to the call relationship between each microservice, a depth-first search method is used to divide them one by one from the microservice call graph. Depth-first search means starting from a certain microservice, searching for microservices on the same chain in sequence until reaching the endpoint, and then searching the next chain, and so on, until all microservices are searched.

[0088] S2. Based on the constructed deployment model, the deployment solution is solved with the goal of minimizing the total deployment cost. The total deployment cost includes the cost of deploying all microservices to each node, that is, the deployment cost mentioned above, the communication cost between microservices after deployment, and the time cost of deploying all microservices, that is, the deployment time mentioned above. The expression for solving the deployment solution is shown in Formula 1.4.

[0089] As an optional implementation, the present application uses a genetic algorithm to solve the deployment solution.

[0090] S2.1, the genetic algorithm initializes the population with the multiple deployment models constructed in step S1, that is, the chromosomes of various deployment models are encoded respectively, and the corresponding population individuals (i.e., chromosomes) are initialized. Each group of chromosomes is regarded as a deployment model.

[0091] like Figure 3 As shown, in an embodiment of a coding deployment model, each gene position of the chromosome represents a microservice at a corresponding position, for example, the first position represents microservice m1, and num positions represent num microservices. The value of each gene represents the node where the corresponding microservice is deployed, for example Figure 3 The value of the first gene position in is 3, which means that microservice m1 is deployed on node 3, and the same applies to the remaining gene positions. This encoding method can ensure that all microservices can be deployed on the corresponding nodes. Figure 3 Decode the chromosomes in Figure 4 From the deployment scheme shown, you can see that each microservice is deployed on the corresponding node.

[0092] According to the description of some of the embodiments in the previous text, it can be known that in the initialized population, the deployment models corresponding to each chromosome are all feasible deployment models. In addition, as described above, the three costs that constitute the total deployment cost simplify the multi-objective optimization problem into a single-objective optimization problem through the normalized weight as a balancing factor. But in fact, since the scales of the three costs are different, if the three costs are directly scaled to the same range, the corresponding extreme values, that is, the maximum and minimum values, need to be calculated during the normalization process, but the actual situation is that there is no direct and effective way to calculate the extreme values. In this regard, in some feasible implementations, the relative values ​​to the random deployment scheme are used to scale the three costs to the same scale.

[0093] In the embodiment of the present application, several feasible deployment models are first randomly generated; the deployment cost, communication cost and deployment time of each deployment model are calculated using the above formulas 1.1, 1.2 and 1.3, and the average value of each cost is calculated as the benchmark value. For subsequent deployment models, the relative values ​​between the three costs and the corresponding benchmark values ​​are calculated respectively, so as to unify the orders of magnitude. For subsequent deployment models, the relative values ​​of the three costs are used as the total deployment cost of the deployment model, and as the fitness of the corresponding population individuals in the genetic algorithm.

[0094] S2.2. Perform iterative evolution operations on the population and obtain the individuals in the population with the best fitness in each round of iteration.

[0095] In the process of using genetic algorithms to solve deployment plans, the most common sire selection strategy is the roulette wheel selection algorithm. Usually, the probability of selection by the roulette wheel selection algorithm is based on the ratio of fitness to total fitness. Since in the scenario of this application, fitness is the weighted sum of three costs, contrary to traditional evolutionary methods, in this application, the lower the fitness, the better the performance of the deployment model. Therefore, when using genetic algorithms to solve deployment plans, the inverse fitness roulette wheel selection algorithm is used to select the sire. First, calculate the inverse fitness of all population individuals as the inverse fitness. Then calculate the sum of the inverse fitness of all population individuals to determine the proportion of evolutionary selection probability. In this way, sires with lower total deployment costs will be selected with a greater probability. Let x represent a population individual, f(x) is the total deployment cost of population individual x, then population individual x a The probability of being selected as the father is:

[0096]

[0097] Where PipSize represents the population size, that is, the number of individuals in the population.

[0098] After the father selection is completed, the evolution operation is completed on the selected father based on probability. Common evolution operations include crossover and mutation operations.

[0099] For the crossover operation, a random number is generated and compared with the set crossover probability to determine whether to perform the crossover operation. If the crossover condition is met, a crossover point is randomly selected for each set of parent chromosomes, and the gene fragments are exchanged at this point, that is, the nodes deployed by the two microservices are exchanged. If the crossover condition is met, two new sets of chromosomes will be generated as offspring individuals.

[0100] After the sub-band individuals are generated, mutation operations need to be performed to introduce new genetic information, increase the diversity of the population and prevent falling into the local optimum. For each group of sub-band individuals, the generated random number is compared with the mutation probability. The chromosome that needs to be mutated randomly selects several gene positions for mutation, that is, some microservices are randomly deployed to other nodes. The mutation operation is completed by randomly generating new chromosomes, thereby preventing falling into the local optimum.

[0101] Similarly, due to the limited resources of edge nodes, the new deployment model generated during the evolution process may not meet the node resource constraints. In this regard, in the iterative evolution operation of the population, if there are population individuals that do not meet the node resource constraints, the microservices in the population individuals that exceed the node resource constraints are randomly deployed to other nodes that can accommodate the microservices. Specifically, in the new individuals, the memory and CPU resources required for all microservices deployed to a node may exceed the total resources of the node. In this case, the generated deployment model is an infeasible deployment model and needs to be adjusted. In order to solve the infeasibility of the deployment model, the entire deployment model can be traversed to determine which specific nodes violate the resource constraints. The microservices deployed on the node that exceed the node resource constraints are randomly redeployed to other nodes with sufficient resources.

[0102] The pseudo code for solving the deployment plan using a genetic algorithm is as follows:

[0103]

[0104]

[0105] In the above solution algorithm, lines 2 to 7 are for initializing the population of the genetic algorithm to obtain the initial deployment model that meets the resource constraints, lines 9 to 13 are for the crossover and mutation operations of the genetic algorithm, lines 15 to 18 are for adjusting the deployment model of microservices that do not meet the resource constraints, that is, randomly deploying some microservices that exceed the node resources to the remaining idle nodes, and lines 21 to 22 are for selecting the optimal deployment plan.

[0106] Through the above method, the best deployment plan can be efficiently solved while taking into account the deployment cost, communication cost and deployment time of microservice deployment. Among them, by deploying microservices with shared layers on the same node as much as possible, the container image pull traffic is saved, thereby saving deployment cost and deployment time; by centrally deploying microservices in the same microservice call subgraph, these microservices are deployed in as few nodes as possible, which can reduce the call chain between nodes, thereby reducing the complexity of solving the microservice deployment plan, reducing the size of the solution space, accelerating the convergence speed of the solution, and improving the deployment efficiency. In addition, the network delay of microservice calls can be minimized, reducing communication costs and improving service quality.

[0107] The present application also performs performance verification on the method proposed in the present application. The present application embodiment uses the open source microservice operation data of Alibaba Cloud as a data set to verify the effectiveness of the algorithm. The data set is divided into four parts: node resource part, container resource part, call graph part and container information part. In the present application embodiment, the first three parts of the data set are mainly used. Node resources include the CPU available resources and memory available resources of all nodes at a certain moment, container resources are the CPU resources and memory resources occupied by a single container of a microservice at a certain moment, and the call graph is the call chain number and the call initiation container and the call acceptance container. Due to the large scale of the data set, this embodiment selects 7 call chains from it. There is a direct or indirect mutual call relationship between all microservices in the same call chain. It includes 50 nodes and 120 microservice containers, and three groups of experiments with different experimental scales are constructed to verify the effectiveness of the algorithm. Since there is no layer structure of the microservice container in the data set, this embodiment manually sets the shared layer for simulation, and the size of each microservice container is 50-120MB. The size of the shared layer is 10%-15% of the size of the microservice container. In the communication call process, the bandwidth between nodes and the size of the data transmitted during the communication process are not given, so this embodiment manually sets the bandwidth between nodes and the size of the data transmitted. It is assumed that any two nodes are communicable and have different bandwidths. By default, the normalized weights are set to 1. That is, the deployment cost, deployment time and communication cost are considered equally.

[0108] The design verifies that the partitioning of the understanding space improves the solution time. A total of three groups of comparative experiments were designed, in which the microservice call graph of the first group of experiments only had one microservice call subgraph, that is, the partitioning of the microservice call graph was not considered. Figure 5 From the experimental results, we can see that dividing the microservice call subgraph to reduce the solution space can effectively reduce the experimental running time. And the improvement effect increases with the increase in the number of microservices.

[0109] Table 4 shows the relative values ​​of different cost increases at different scales. It can be seen that when the normalized weights are the same, all three costs are reduced. For deployment costs, the memory cost can be saved by about 5%-15%. For deployment time, the startup time was reduced by about half for both the first and third groups of experiments. Even the second group of experiments, which was relatively worse, reduced the deployment time by 10%. For communication costs, as the number of microservices increases, the cost reduction rate decreases, but there is still a reduction of at least 25%. It can be concluded that when the deployment plan is solved by dividing the microservice call subgraph using the improved genetic algorithm, the deployment time of the microservice and the communication cost generated during subsequent operation can be effectively reduced.

[0110] Table 4 Improvements of the present invention on deployment cost, deployment time, and communication cost performance

[0111] Problem size Deployment Cost communication cost Deployment time 1 call chain, 14 containers 0.86 0.22 0.56 3 call chains, 47 containers 0.88 0.55 0.88 7 call chains, 119 containers 0.91 0.75 0.55

[0112] Figure 6 These are the results of sensitivity experiments on the crossover rate and mutation rate. It can be seen that different crossover rates and mutation rates have little effect on the improvement effect, that is, the method of this application is not sensitive to the crossover rate and mutation rate. When using the algorithm proposed in this application, it is not necessary to repeatedly experiment to set appropriate hyperparameters.

[0113] In the foregoing embodiments, the three costs are normalized into a single-objective optimization problem for solution. In fact, according to the design idea of ​​the present application, the optimization problem can be replaced by a three-cost minimization problem (i.e., a multi-objective optimization problem) and solved by a genetic algorithm.

[0114] Based on the design concept of the present application, an embodiment of the present application also provides a microservice deployment system in an edge cloud environment, the system includes a processor and a storage medium, and the storage medium stores computer instructions; when the processor runs the computer instructions, the microservice deployment method in the edge cloud environment of the above embodiment can be executed.

[0115] The present invention is not limited to the above-mentioned specific embodiments, but extends to any new features or any new combination disclosed in this specification, as well as any new method or process steps or any new combination disclosed.

Claims

1. A microservice deployment method in an edge cloud environment, characterized in that: include: Under the node resource constraints, build multiple deployment models to deploy each microservice required by the application to multiple given nodes. For each deployment model, deploy at least two microservices with a shared layer to the same node. Based on the constructed deployment model, the deployment solution is solved with the goal of minimizing the total deployment cost; The total deployment cost includes the cost of deploying all microservices to each node, the communication cost between microservices after deployment, and the time cost of deploying all microservices.

2. The microservice deployment method in the edge cloud environment as described in claim 1, characterized in that: The step of deploying at least two microservices shared by the existence layer to the same node includes: Traverse all microservices and deploy as many microservices with shared layers as possible to the same node.

3. The microservice deployment method in the edge cloud environment as described in claim 2, characterized in that: Deploy as many microservices with a shared layer as possible to the same node, including: For the microservice to be deployed, traverse all nodes and deploy the microservice to be deployed on the node where the shared layer has been deployed.

4. The microservice deployment method in an edge cloud environment as described in any one of claims 1 to 3, characterized in that: The step of deploying at least two microservices with a shared layer to the same node includes: According to the calling relationship between each microservice, the microservice call graph is divided into microservice call subgraphs, and the microservice call graph reflects all the calling relationships between all microservices; At least two microservices in the same call chain in at least one microservice call subgraph are deployed to the same node.

5. The microservice deployment method in the edge cloud environment as described in claim 4, characterized in that: According to the calling relationship between each microservice, the microservice call graph is divided into microservice call subgraphs, including: According to the calling relationship between each microservice, a depth-first search method is adopted to divide the microservice calling subgraphs one by one from the microservice calling graph.

6. The microservice deployment method in the edge cloud environment as claimed in claim 1, characterized in that: The method for constructing the deployment model includes: Randomly deploy the microservices required by the application to a given plurality of nodes, wherein at least two microservices with a shared layer are deployed to the same node; Based on the resource limits of each node, microservices that exceed the node resource limits are randomly deployed to other nodes that can accommodate the microservices.

7. The microservice deployment method in an edge cloud environment as described in claim 1 or 6, characterized in that: Genetic algorithm is used to solve the deployment plan.

8. The microservice deployment method in the edge cloud environment as claimed in claim 7, characterized in that: The method of using a genetic algorithm to solve a deployment solution includes: Initialize the population with multiple deployment models, and use the total deployment cost as the fitness to obtain the population individuals with the best fitness; Perform iterative evolution operations on the population and obtain the individuals with the best fitness in each round of iteration; The best fitness individual among all the best fitness individuals in the population is taken as the deployment solution.

9. The microservice deployment method in the edge cloud environment as claimed in claim 8, characterized in that: During the iterative evolution operation on the population, if there are population individuals that do not meet the node resource limit, the microservices in the population individuals that exceed the node resource limit are randomly deployed to other nodes that can accommodate the microservices.

10. A microservice deployment system in an edge cloud environment, comprising a processor and a storage medium, wherein the storage medium stores computer instructions; characterized in that: When the processor runs the computer instructions, it can execute the microservice deployment method in the edge cloud environment as described in any one of claims 1-9.

Images