A micro-service deployment method and system in an edge cloud environment

Abstract

The application discloses a micro-service deployment method and system in an edge cloud environment, relates to the field of micro-service deployment, and aims to reduce the total cost of micro-service deployment in a cloud native environment.Under the limitation of node resources, a plurality of deployment models for respectively deploying each micro-service required by an application program to a plurality of given nodes are constructed, at least two micro-services with a shared layer are deployed to the same node for each deployment model, and a deployment scheme is solved by a genetic algorithm based on the constructed deployment model and with the minimum total deployment cost as the target.The application can effectively reduce the deployment cost, deployment time and communication cost of the micro-service, and the solving efficiency of the deployment scheme is high.

Description

TECHNICAL FIELD

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

[0002] The emergence and development of microservice technology have 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 mode of application programs, which decouples the traditional single-chip 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, which can meet the needs of resource dynamic adjustment and rapid deployment of microservice architecture. Containers, as a lightweight virtualization technology, 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 application programs into multiple independently developed and maintained microservices and deploying them in containers. Container-based microservice cloud deployment brings the concepts of cloud native edge computing and edge cloud native. Compared with central cloud, edge cloud has the characteristics of wide distribution and relatively limited resources.

[0004] Although containers have the characteristics of lightweight, pulling and starting large container images still consumes a lot of resources, especially in the relatively limited resources of edge cloud. Pulling microservice containers consumes a lot of traffic and brings high deployment cost. At the same time, the long microservice container pulling time increases the microservice startup time, and the pulling delay seriously affects the service quality and user experience. The complex calling relationship of microservices will generate communication cost at runtime, and when a large number of microservices work together, the calling chain between microservices constitutes a microservice calling graph, which will increase the runtime traffic consumption and affect the microservice deployment performance. SUMMARY

[0005] The purpose of the present application is to provide a microservice deployment method and system in an edge cloud environment to reduce the total cost of microservice deployment in a cloud native environment.

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

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

[0008] Under 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 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.

[0010] Furthermore, deploying at least two microservices shared by the presence 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 the node where the shared layer has been deployed.

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

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

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

[0017] Furthermore, the microservice call graph is divided into microservice call subgraphs according to the call relationship between each microservice, 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 multiple given nodes, where 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] Further, the genetic algorithm is used to solve the deployment scheme.

[0023] Further, the genetic algorithm is used to solve the deployment scheme, including:

[0024] The population is initialized by using the constructed multiple deployment models, and the population individual with the best fitness is obtained by taking the total deployment cost as the fitness.

[0025] The population is iteratively evolved, and the population individual with the best fitness is obtained in each iteration.

[0026] The population individual with the best fitness among all the obtained population individuals with the best fitness is taken as the solved deployment scheme.

[0027] Further, in the iterative evolution operation of the population, if there is a population individual that does not satisfy the node resource limit, the microservice that exceeds the node resource limit in the population individual is randomly deployed to other nodes that can accommodate the microservice.

[0028] The application also provides a microservice deployment system in an edge cloud environment, including a processor and a storage medium, the storage medium storing computer instructions; the processor executes the computer instructions, and can execute the microservice deployment method in the edge cloud environment.

[0029] As described above, due to the adoption of the above technical solutions, the application has the following beneficial effects:

[0030] The microservice deployment scheme in the edge cloud environment designed by the application is suitable for the characteristics of limited resources in deploying microservices on the edge cloud, considers the layered architecture of container design, deploys microservices with a shared layer to the same node, thereby effectively reducing the traffic consumption when pulling the container image, reducing the deployment cost and communication cost of the microservice, and accelerating the startup speed of the microservice and reducing the deployment time. Moreover, according to the microservice call graph, the microservices belonging to the same microservice call subgraph are uniformly deployed, which improves the sharing rate of the microservice container base layer and reduces the call chain between nodes as much as possible, thereby reducing the complexity of the optimized deployment scheme as much as possible and improving the algorithm efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0031] The application will be described by examples and with reference to the accompanying drawings, in which:

[0032] Figure 1 is a container image pulling traffic comparison diagram of whether the microservice in the embodiment of the application is deployed with layer sharing or not.

[0033] Figure 2 is a communication cost generation schematic diagram of the microservice after deployment in the embodiment of the 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 diagram showing the results 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 when the solution space is reduced or not in the embodiment of the present application.

[0037] Figure 6 This is a diagram showing the results of a sensitive experiment on the crossover rate and mutation rate during the evolution process in the examples of this application. DETAILED DESCRIPTION

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

[0039] Any feature disclosed in this specification (including any appended claims and abstract), unless otherwise stated, may be replaced by other equivalent or similar features. 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 the research only models microservices as lightweight virtual machines, using the characteristics of microservice development simplicity and easy maintenance to reduce the difficulty of application development. Few consider the deployment performance of microservices, especially the deployment cost.

[0041] In cloud deployments of microservices, microservice startup is primarily limited by container pulls, which consume 76.6% of microservice startup time. For example, deploying a MySQL container generates 500-600MB of pull traffic. However, the lifecycle of a microservice is only a few minutes. Long microservice container pull latency severely impacts service quality and user experience. Furthermore, the traffic consumed by container pulls leads to high deployment costs, a problem exacerbated by highly distributed edge clouds with relatively limited resources. Furthermore, microservices have complex call relationships. Frequent interactions between microservices incur communication costs between nodes. When a large number of microservices work together, numerous microservice call chains form the microservice call graph. Excessive call chains between nodes invisibly increase communication costs. Both deployment and communication costs contribute significantly to the total cost of microservice deployment.

[0042] Chinese patent publication CN118337640A provides a method for deploying microservices in collaboration with cloud and multiple edge network nodes. The method includes the following steps: First, modeling the network topology of the cloud and multiple edge network nodes and the application consisting of microservice nodes, a distributed database, and multiple complex communication methods to obtain a microservice deployment model for the cloud and multiple edge network nodes. Second, based on the network topology and microservice deployment model, a reinforcement learning training environment and deployment scheme evaluation metrics are constructed for the microservice deployment model, with the goal of optimizing the end-to-end latency, resource consumption, and deployment success rate of the microservice application deployment structure. Third, a reinforcement learning algorithm is used to train the microservice deployment model using a Thompson sampling exploration mechanism with a clipped Gaussian approximation and a multi-step training qualification tracking strategy to obtain a converged microservice deployment model for the cloud and multiple edge network nodes. This method solves the microservice deployment problem in the cloud and multiple edge network node collaboration scenario by designing a reinforcement learning algorithm based on the Thompson sampling exploration strategy with a clipped Gaussian approximation and a qualification tracking mechanism to minimize resource consumption while meeting end-to-end latency. However, this method lacks consideration of the communication costs after deployment is completed. Subsequent frequent calls to microservices will lead to increased communication costs between nodes, increased communication latency, high operating costs, and a certain degree of reduction in service quality.

[0043] The Chinese patent document with publication number CN117573379A provides a microservice deployment method based on symmetric scaling and merging, which includes: a first step: calculating the number of cores initially allocated to each microservice based on the predicted user request traffic and the processing capacity of a single core of the server for each microservice, and initializing a microservice group, and using a symmetric merging algorithm to obtain a symmetric merged microservice group; a second step: counting the total number of server cores used in the current deployment scheme based on the microservice group obtained by the symmetric merging; a third step: using an instance expansion algorithm, amplifying the microservice instances in each microservice group to obtain a microservice group after instance expansion and contraction; a fourth step: calculating the request arrival rate at each microservice based on relevant theories of queuing theory, and counting the deployment status of each microservice in the microservice group obtained after instance expansion and contraction, dividing the request traffic at each microservice equally into each microservice group, and completing equal-division routing; a fifth step: counting the total number of servers used in the current deployment scheme based on the microservice group after instance expansion and contraction, and if the total number of servers currently used exceeds the number of available servers, using a migration and merging algorithm, migrating the microservice group to be migrated to another microservice group. This method eliminates the need to consider routing issues separately, resulting in efficient solutions. It simultaneously solves microservice deployment and request routing problems, directly solving them globally to obtain the optimal solution. This reduces user request latency, maximizes request success rates, and improves user experience. However, this method fails to consider the hierarchical structure of containers when calculating microservice deployment. The resulting deployment solution draws high traffic and takes a long time, increasing microservice deployment time.

[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 incurred 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 microservice layer set as L, and the microservice layer structure related attribute definition is shown in Table 2.

[0051] Table 2 Microservice layer structure related attribute definition

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

[0053] 3) Define the microservice set {M, H}, M is the microservice container set, and H is the call relationship set, and the microservice related attribute definition is shown in Table 3.

[0054] Table 3 Microservice related attribute definition

[0055]

[0056]

[0057] Before introducing the microservice deployment method, the optimization index of the application, i.e. the total deployment cost, is described. The total deployment cost involves the resource and time consumption when deploying the microservice and the resource consumption after deploying the microservice, which are respectively referred to as deployment cost, deployment time and communication cost.

[0058] 1) Deployment cost.

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

[0060]

[0061] 2) Communication cost.

[0062] The communication cost is the expected value of the communication time and in unit time after the microservice deployment is completed, as shown in formula 1.2. Figure 2 The schematic diagram of the communication cost formed by the microservices is shown in FIG. 1.2. In the specific calculation, there is one or more containers for a microservice. In the case of multiple containers, the probability of each container being called is equal. It is calculated whether each node deploys the corresponding microservice container, and the total number of the corresponding microservice containers is divided by the calling probability, and then multiplied by the microservice communication delay, which is the expected value of the communication delay between a pair of microservices. The sum can obtain the communication cost. It is calculated by formula 1.2.

[0063]

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

[0065] 3) Deployment time.

[0066] Deployment time is the total time from the start of microservice deployment to its completion. This total time depends on the node that takes the longest to deploy. Therefore, the deployment time is calculated by dividing the traffic consumption of each node by the communication bandwidth between that node and the Docker hub. The maximum value is the deployment time. This is calculated using Equation 1.3.

[0067]

[0068] Alternatively, the deployment time can also be the total time it takes to deploy microservice containers on all nodes and start them.

[0069] During the calculation, the deployment cost, communication cost, and deployment time 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, resources are constrained by the node's computing and memory resources. Therefore, the resources required by all microservices deployed on a node must be less than the total resources of the node. Given that all microservices must be deployed, we can obtain the constraint condition shown in Equation 1.5.

[0074]

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

[0076] S1. Under node resource constraints, build multiple deployment models that deploy each microservice required by the application to a given number of 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 traffic pulled by 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 deploying each microservice required by the application to a given plurality of nodes, the method for constructing 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 shared layers are deployed to the same node to save deployment costs.

[0079] S1.2, according to the resource limit of each node, randomly deploy the microservice exceeding the resource limit of the node to other nodes that can accommodate the microservice. The edge cloud deployment has resource limits, and each node has limited resources (CPU resources and memory resources) and can only deploy a limited number of microservices. Since the available resources of each node are different and each microservice occupies different resources, it is not possible to clearly define the number of microservices that each node can deploy. Therefore, after randomly deploying microservices, it may occur that the microservices deployed on a node exceed the resource bearing range of the node. This deployment model is not feasible. For the unfeasible deployment model, the microservice exceeding the node resource is removed and randomly deployed to other idle nodes (i.e., with free resources) to ensure that each deployment model obtained is feasible, thus having optimization value.

[0080] The above-mentioned deployment of at least two microservices with shared layers to the same node is to save the container image pulling 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 the container image pulling traffic. In some optional embodiments, 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 base layer. If these microservices are deployed on different nodes, the container image needs to be pulled separately when deploying the microservice container. However, when these microservices are deployed in as few nodes as possible, i.e., as many microservices with shared layers as possible are deployed in the same node, the repeated pulling traffic can be saved to the maximum extent.

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

[0084] In addition, the present application also considers the communication cost between nodes after the deployment of microservices, which is mainly determined by the number of microservice call chains between nodes and network delay.

[0085] As an optional implementation, when building a deployment model, the microservice call graph is divided into microservice call subgraphs based on the call relationships between the microservices. 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 microservices with which it transmits data. Microservices with data transmission have call chains between them. As previously explained, the call relationships between all microservices form a microservice call graph. Communication costs only apply to microservices within the same call chain. However, due to the different nodes to which microservices within a call chain belong, the network latency for data transmission varies, resulting in different communication costs. By deploying as many microservices with call chains as possible to the same node, the call chains between nodes can be reduced, thereby reducing the complexity of the optimized deployment solution, narrowing the solution space, and improving the efficiency of solving the deployment solution. Furthermore, the network latency of microservice calls can be minimized, thereby reducing communication costs. In some specific embodiments, for each microservice call subgraph, as many microservices as possible are deployed to as few nodes as possible, subject to the resource constraints of each node. For example, for all microservices in a microservice call subgraph, a node is selected for deployment first based on the connection order of the call chain. Once the resources of that node are exhausted, the next node is selected for deployment, and so on.

[0087] In one optional implementation, each microservice call subgraph is partitioned one by one from the microservice call graph using a depth-first search method based on the call relationships between the microservices. A depth-first search starts with a microservice and sequentially searches for microservices on the same chain until the endpoint is reached. The search then continues with the next chain, and so on, until all microservices have been searched.

[0088] S2. Based on the constructed deployment model, determine a deployment solution with the goal of minimizing the total deployment cost. The total deployment cost includes the cost of deploying all microservices to each node (the deployment cost mentioned above), the communication cost between microservices after deployment, and the time cost of deploying all microservices (the deployment time mentioned above). The expression for the deployment solution is shown in Equation 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 using the multiple deployment models constructed in step S1. That is, each deployment model is encoded with chromosomes and initialized to obtain the corresponding population individuals (i.e., chromosomes). Each set of chromosomes is considered 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 As shown in the deployment scheme, you can see that each microservice is deployed on the corresponding node.

[0092] According to the description of some of the embodiments above, it can be seen 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 are simplified into a single-objective optimization problem through the normalization weight as a balancing factor. However, 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, i.e., the maximum and minimum values, need to be calculated during the normalization process. However, 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, thereby completing the unification of the orders of magnitude. For subsequent deployment models, the relative values ​​of the three costs are summed 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 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, the sire with a lower total deployment cost will be selected with a greater probability. Let x represent the 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 is selected, the evolution operation is performed on the selected father based on probability. Common evolution operations include crossover and mutation operations.

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

[0100] After generating sub-band individuals, mutation is required to introduce new genetic information, increase population diversity, and prevent regression into local optima. For each sub-band individual, a generated random number is compared with the mutation probability. Several genetic positions are randomly selected for mutation on the chromosome to be mutated, randomly deploying some microservices to other nodes. Mutation is performed by randomly generating new chromosomes, thus preventing regression into local optima.

[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. To address this, during the iterative evolution of the population, if there are population individuals that do not meet the node resource constraints, the microservices in that population individual that exceed the node resource constraints are randomly deployed to other nodes that can accommodate the microservices. Specifically, in the new individual, the memory and CPU resources required for all microservices deployed to a certain node may exceed the total resources of the node. In this case, the resulting deployment model is an infeasible deployment model and needs to be adjusted. To resolve 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 the genetic algorithm is as follows:

[0103]

[0104]

[0105] In the above solution algorithm, lines 2 to 7 are the initialization of the genetic algorithm population to obtain the initial deployment model that meets the resource constraints. Lines 9 to 13 are the crossover and mutation operations of the genetic algorithm. Lines 15 to 18 are the adjustment of the microservice deployment model that does not meet the resource constraints, that is, the microservices that exceed the node resources are randomly deployed to the remaining idle nodes. Lines 21 to 22 are used to screen the optimal deployment plan.

[0106] The above method efficiently calculates the optimal deployment solution while comprehensively considering the deployment cost, communication cost, and deployment time of microservice deployment. By deploying microservices with shared layers on the same node as much as possible, the amount of traffic required to pull container images is reduced, thereby saving deployment cost and time. By centrally deploying microservices in the same microservice call subgraph and deploying them on as few nodes as possible, the call chain between nodes can be reduced, thereby reducing the complexity of solving the microservice deployment solution, shrinking the solution space, accelerating the convergence of the solution, and improving deployment efficiency. Furthermore, the network latency of microservice calls can be minimized, reducing communication costs and improving service quality.

[0107] This application also performs performance verification on the proposed method. This embodiment uses Alibaba Cloud's open-source microservices runtime data as a dataset to verify the effectiveness of the algorithm. This dataset is divided into four parts: node resources, container resources, call graph, and container information. In this embodiment, the first three parts of the dataset are primarily used. Node resources include the available CPU and memory resources of all nodes at a given moment. Container resources include the CPU and memory resources occupied by a single microservice container at a given moment. The call graph includes the call chain number, the call-initiating container, and the call-receiving container. Due to the large size of the dataset, this embodiment selects seven call chains. All microservices in the same call chain have direct or indirect mutual call relationships. This dataset includes 50 nodes and 120 microservice containers. Three sets of experiments with different experimental scales were constructed to verify the effectiveness of the algorithm. Since the dataset does not contain a layered structure for microservice containers, this embodiment manually sets a shared layer for simulation. Each microservice container is 50-120MB in size. The shared layer size is 10%-15% of the microservice container size. The bandwidth between nodes and the size of the data transmitted during the communication call are not specified. Therefore, this embodiment manually sets the bandwidth and data size between nodes. It is assumed that any two nodes are able to communicate with each other and have different bandwidths. By default, the normalized weights are all set to 1. This means that deployment cost, deployment time, and communication cost are equally considered.

[0108] The design verifies that partitioning the understanding space improves solution time. A total of three sets of comparative experiments were designed. In the first set of experiments, the microservice call graph only had one microservice call subgraph, which means that the microservice call graph was not partitioned. Figure 5 The experimental results show that dividing the microservice call subgraph to reduce the solution space can effectively reduce the experimental run time. Moreover, the improvement effect increases with the number of microservices.

[0109] Table 4 shows the relative improvements in various costs at different scales. It can be seen that, with the same normalized weights, all three costs were reduced. Regarding deployment costs, memory costs were reduced by approximately 5%-15%. Regarding deployment time, the startup time was reduced by approximately half for both the first and third experiments. Even the second experiment, which performed relatively poorly, reduced deployment time by 10%. Regarding communication costs, the reduction decreased with the increase in the number of microservices, but still achieved a reduction of at least 25%. This indicates that partitioning the microservice call subgraph and using an improved genetic algorithm to solve the deployment solution effectively reduces microservice deployment time and the communication costs incurred during subsequent runtime.

[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 crossover rate and mutation rate. As can be seen, different crossover rates and mutation rates have little impact on the improvement effect, which means that the method proposed in this application is not sensitive to crossover rate and mutation rate. When using the algorithm proposed in this application, there is no need to repeatedly experiment to set appropriate hyperparameters.

[0113] In the previous embodiment, the three costs are normalized into a single-objective optimization problem for solution. In fact, according to the design idea of ​​this 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 this application, an embodiment of this application also provides a microservice deployment system in an edge cloud environment, which includes a processor and a storage medium, in which computer instructions are stored; when the processor runs the computer instructions, it can execute the microservice deployment method in the edge cloud environment of the above embodiment.

[0115] The present invention is not limited to the aforementioned 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 node resource constraints, multiple deployment models are constructed to deploy each microservice required by an application to a given plurality of nodes. For each deployment model, at least two microservices with a shared layer are deployed to the same node, including: traversing all microservices and deploying as many microservices with a shared layer as possible to the same node; using a depth-first search method to partition a microservice call graph into microservice call subgraphs based on the call relationships between the microservices, wherein the microservice call graph reflects all call relationships between all microservices; and deploying at least two microservices in the same call chain in at least one microservice call subgraph to the same node; Based on the constructed deployment model, with the goal of minimizing the total deployment cost, a genetic algorithm is used to solve the deployment plan, including: initializing the population with multiple constructed deployment models, and using the total deployment cost as the fitness to obtain the population individual with the best fitness; performing iterative evolution operations on the population, and obtaining the population individual with the best fitness in each round of iteration; and using the population individual with the best fitness among all the obtained population individuals with the best fitness as the deployment plan to be solved; 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.

2. The microservice deployment method in an edge cloud environment according to claim 1, wherein: Deploy as many microservices with shared layers as possible to the same node, including: For the microservice to be deployed, traverse all nodes and deploy the microservice to the node where the shared layer has been deployed.

3. The microservice deployment method in an edge cloud environment according to claim 1, wherein: The method for constructing the deployment model includes: Randomly deploy the microservices required by the application to multiple given nodes, where 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.

4. The microservice deployment method in an edge cloud environment according to claim 1, wherein: During the iterative evolution of 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.

5. 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-4.

Images