Micro-service deployment method and apparatus, electronic device, and storage medium

Abstract

This application discloses a microservice deployment method, apparatus, electronic device, and storage medium, relating to the field of big data technology. The method includes: constructing a physical network model and a service model for a microservice group; the service model characterizes the dependencies and access flows between different microservices in the microservice group; determining multiple optimization objectives, wherein the multiple optimization objectives include at least: average response latency for user access to the microservice group, deployment cost of the microservice group, transmission cost of the microservice group, and deployment efficiency of the microservice group; determining a target model for achieving each optimization objective based on the physical network model and the service model; and deploying the microservices in the microservice group according to the target models of the multiple optimization objectives. This application solves the technical problems of poor flexibility and accuracy in dynamic deployment of microservices in cross-cloud deployment scenarios in the prior art.

Description

Technical Field

[0001] This application relates to the field of big data technology, and more specifically, to a microservice deployment method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the development of new network technologies, computing power networks will interconnect dynamically distributed computing and storage resources based on ubiquitous network connections. Through the unified and coordinated scheduling of multi-dimensional resources such as network, storage, and computing power, massive applications can call ubiquitous computing resources on demand and in real time. The aim is to build a new network infrastructure that can sensitively perceive computing power, ensuring that the network can allocate computing resources in different geographical locations in real time according to actual needs, thereby improving the overall utilization efficiency of network and computing resources. Multi-cloud interconnection constitutes one of the basic scenarios of computing power networks.

[0003] Existing microservice deployment research techniques typically only consider single-cloud scenarios. While some have achieved cross-cloud deployment, when researching the problem, they often only consider one of deployment cost or user response latency as the optimization objective, neglecting deployment efficiency and inter-microservice transmission costs. Furthermore, in computing networks, because cloud environments are often dynamically changing and resources are volatile and uncertain, existing technologies suffer from poor flexibility and accuracy in dynamically deploying microservices across clouds.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a microservice deployment method, apparatus, electronic device, and storage medium to at least solve the technical problems of poor flexibility and accuracy in dynamic deployment of microservices in cross-cloud deployment scenarios in the prior art.

[0006] According to one aspect of the embodiments of this application, a microservice deployment method is provided, comprising: constructing a physical network model and a service model of a microservice group, wherein the physical network model is used to characterize the internal attributes of each data center and the link attributes between nodes in a scenario where multiple data centers are interconnected; the service model is used to characterize the dependencies and access processes between different microservices in the microservice group; determining multiple optimization objectives, wherein the multiple optimization objectives include at least: the average response latency of user access to the microservice group, the deployment cost of the microservice group, the transmission cost of the microservice group, and the deployment efficiency of the microservice group; determining a target model for achieving each optimization objective based on the physical network model and the service model; and deploying the microservices in the microservice group according to the target models of the multiple optimization objectives.

[0007] Optionally, constructing a physical network model includes: determining a first set and a second set, wherein the first set includes the node locations of each data center and the second set includes link information between the data centers; determining the transmission cost and transmission latency between any two data centers; determining the set of container types for each data center, wherein the set of container types for each data center includes all container types that make up that data center; and constructing a physical network model based on the first set, the second set, the transmission cost and transmission latency between any two data centers, and the set of container types for each data center.

[0008] Optionally, a service model for the microservice group is constructed, including: generating a directed acyclic graph (DAG) based on the microservice group, wherein the DAG is used to describe the dependency and invocation relationships between multiple microservices in the microservice group; and constructing a service model for the microservices based on the DAG, a user center set, and a replica deployment strategy, wherein the user center set includes various user groups that invoke the microservices, and the replica deployment strategy is used to limit the one-to-one deployment relationship between each microservice replica and a container, and each microservice and its replica are deployed on a container type in the same cloud data center.

[0009] Optionally, the target model for each optimization objective is determined based on the physical network model and the service model, including: determining the network latency between the user center and the first microservice accessed based on the physical network model to obtain first data; determining the network latency between the user center and the last microservice accessed based on the physical network model to obtain second data; determining the workload of the microservice group and the gateway request frequency from the user center to the microservice group based on the service model; determining the network latency between the user center and the microservice group based on the first data, the second data, the workload of the microservice group, and the gateway request frequency; and determining the target model for the average response latency of the user accessing the microservice group as the summation function of the response time and network latency within the microservice group.

[0010] Optionally, the target model for each optimization objective is determined based on the physical network model and the service model, including: determining the data center and container type deployed for each microservice in the microservice group based on the physical network model and the service model; determining the target model corresponding to the deployment cost of the microservice group based on the data center and container type deployed for each microservice; determining the transmission cost between any two microservices in the microservice group based on the physical network model and the service model; and determining the target model corresponding to the transmission cost of the microservice group when processing user requests based on the transmission cost between any two microservices.

[0011] Optionally, the target model for each optimization objective is determined based on the physical network model and the service model, including: determining the data center and container type corresponding to each microservice in the microservice group, and the expected value corresponding to the remaining quantity of each type of container in each data center, based on the physical network model and the service model; determining the probability information of each microservice when deployed to each container in each data center based on the expected value; determining the deployment success rate of each microservice based on the data center and container type corresponding to each microservice and the probability information; and determining the target model corresponding to the deployment efficiency of the microservice group based on the deployment success rate of each microservice in the microservice group.

[0012] Optionally, the microservices in the microservice group are deployed according to a target model with multiple optimization objectives, including: deploying the microservices in the microservice group according to at least one of the following constraints and the target model with multiple optimization objectives:

[0013] The first constraint is used to ensure that the amount of idle resources in the microservice group is greater than or equal to the minimum amount of resources required to process user requests.

[0014] The second constraint is used to restrict microservices of the same type from being deployed to the same container in the same data center;

[0015] The third constraint is used to ensure that the actual workload of the microservice group does not exceed the maximum load threshold of the microservice group when processing user requests.

[0016] Optionally, the microservices in the microservice group are deployed according to at least one of the following constraints and a target model with multiple optimization objectives, including: Step 1, generating a parent population that meets the constraints for the target model with multiple optimization objectives, wherein the parent population represents the initial solution of the first generation; Step 2, after performing a non-dominated sort on the generated parent population, obtaining the offspring population through selection crossover mutation; Step 3, merging the parent population and the offspring population, and after performing a non-dominated sort, determining the individual levels of the population, and determining all individuals in the population except for the lowest-level individuals as individuals of the next generation population; Step 4, for the lowest-level individuals... Individuals are normalized and their vertical distance to the reference point is calculated. Based on the vertical distance, at least one individual from the lowest-ranking population is selected as the next generation population. Step 5: Selective crossover mutation is performed on the next generation population, and it is determined whether the maximum number of evolutionary iterations has been reached. If the maximum number of evolutionary iterations has not been reached, the evolutionary count is incremented by one, and the process returns to Step 3 to continue iterating. If the maximum number of evolutionary iterations has been reached, the process proceeds to Step 6. Step 6: From all the obtained solutions, the target solution that satisfies the constraints is selected. Step 7: The microservices in the microservice group are deployed based on the target solution.

[0017] According to another aspect of the embodiments of this application, a microservice deployment apparatus is also provided, comprising: a model building unit for building a physical network model and a service model of a microservice group, wherein the physical network model is used to characterize the internal attributes of each data center and the link attributes between nodes in a scenario where multiple data centers are interconnected; the service model is used to characterize the dependencies and access processes between different microservices in the microservice group; a first determining unit for determining multiple optimization objectives, wherein the multiple optimization objectives include at least: the average response latency of user access to the microservice group, the deployment cost of the microservice group, the transmission cost of the microservice group, and the deployment efficiency of the microservice group; a second determining unit for determining a target model for achieving each optimization objective based on the physical network model and the service model; and a deployment unit for deploying the microservices in the microservice group according to the target models of the multiple optimization objectives.

[0018] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer-readable storage medium, and wherein, when the computer program is executed, the device where the computer-readable storage medium is located executes the microservice deployment method described above.

[0019] According to another aspect of the embodiments of this application, an electronic device is also provided, wherein the electronic device includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by one or more processors, the one or more processors cause the one or more processors to perform the microservice deployment method described above.

[0020] This application first constructs a physical network model and a service model for a microservice group. The physical network model characterizes the internal attributes of each data center and the link attributes between nodes in a scenario where multiple data centers are interconnected. The service model characterizes the dependencies and access processes between different microservices within the microservice group. Then, multiple optimization objectives are determined, including at least: average response latency for user access to the microservice group, deployment cost of the microservice group, transmission cost of the microservice group, and deployment efficiency of the microservice group. Based on the physical network model and the service model, a target model is determined to achieve each optimization objective. Finally, based on the target models for multiple optimization objectives, the microservices within the microservice group are deployed.

[0021] As can be seen from the above, this application, by designing multi-dimensional optimization objectives and combining the constructed physical network model and the service model of the microservice group, can dynamically adjust the deployment method of each microservice when deploying it, thereby improving the deployment flexibility of microservices. Moreover, the deployment of microservices is constrained by multiple optimization objectives, which can also improve the deployment accuracy of microservices and ensure that microservices can be deployed to better data centers and containers. This solves the technical problems of poor dynamic deployment flexibility and accuracy of microservices in cross-cloud deployment scenarios in the prior art. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0023] Figure 1 This is a flowchart of an optional microservice deployment method according to an embodiment of this application;

[0024] Figure 2 This is a schematic diagram of an optional physical network model according to an embodiment of this application;

[0025] Figure 3 This is a schematic diagram of an optional microservice group service model according to an embodiment of this application;

[0026] Figure 4 This is a flowchart illustrating an optional microservice deployment method according to an embodiment of this application.

[0027] Figure 5 This is a flowchart of an optional NSGA-III algorithm solution according to an embodiment of this application;

[0028] Figure 6 This is a schematic diagram of an optional microservice deployment apparatus according to an embodiment of this application. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] It should also be noted that the information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) collected in this application are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with the relevant laws, regulations, and standards of the relevant regions, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse. For example, this system has interfaces with relevant users or organizations. Before obtaining relevant information, a request to obtain the information needs to be sent to the aforementioned user or organization through the interface, and the relevant information is obtained only after receiving consent from the aforementioned user or organization.

[0032] According to an embodiment of this application, a microservice deployment method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0033] In one optional embodiment, a microservice deployment system can serve as the execution subject of the microservice deployment method in this application embodiment. The microservice deployment system can be a software system or an embedded system combining software and hardware. Furthermore, besides a microservice deployment system, the execution subject can also be other forms of subject, such as devices, equipment, etc. Those skilled in the art should understand that this application does not particularly limit the specific form of the execution subject.

[0034] For ease of explanation, the following descriptions will use a microservice deployment system as the execution subject.

[0035] Figure 1This is a flowchart of an optional microservice deployment method according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0036] Step S101: Construct the physical network model and the service model of the microservice group.

[0037] In step S101, the physical network model is used to characterize the internal attributes of each data center and the link attributes between nodes in a scenario where multiple data centers are interconnected; the service model is used to characterize the dependencies and access processes between different microservices in a microservice group.

[0038] Optionally, the physical network model primarily describes the characteristics of each data center constituting the computing power network and the connectivity between them. Specifically, the physical network model includes the following key attribute information:

[0039] Data center node location and internal attributes: Each data center is considered a node, and its internal attributes, such as geographical location, computing power, storage capacity, and network bandwidth, are taken into account. These attributes directly determine the cost-effectiveness and suitability of the data center, and are crucial for the deployment selection of microservices.

[0040] Link attributes between nodes: The physical network model also records the connection link status between each data center in detail, including transmission latency, transmission cost, bandwidth limitations, etc. This information is crucial for evaluating the communication efficiency and cost between microservices across data centers.

[0041] By constructing a physical network model, we can intuitively understand the topology and resource distribution of the entire computing network. This model helps to more accurately calculate the total cost (including deployment and transmission costs) and response latency of microservices deployed on different data centers during subsequent multi-objective optimization processes, thereby making more reasonable decisions.

[0042] Optionally, the service model of a microservice group focuses on the microservice structure and operational mechanisms within the application, especially the interactions and dependencies between microservices. The microservice group service model is implemented in the following ways:

[0043] Representation of a Directed Acyclic Graph (DAG): The service model of a microservice group uses a DAG to depict the dependencies between microservices. In a DAG, each microservice is a node, and the directed edges between nodes represent dependencies. That is, an edge from node A to node B means that microservice B depends on the output of microservice A to run.

[0044] Microservice access flow: The service model for microservice groups also considers how users access microservice groups through the API gateway. The flow, processing order, and return path of user requests are all reflected in the service model.

[0045] The goal of building a microservice service model is to ensure that when deploying microservices, the locations of microservices can be reasonably arranged to meet the logical order and dependencies of the application, while optimizing response latency and deployment efficiency.

[0046] Step S102: Determine multiple optimization objectives.

[0047] In step S102, the multiple optimization objectives include at least: the average response latency of user access to the microservice group, the deployment cost of the microservice group, the transmission cost of the microservice group, and the deployment efficiency of the microservice group.

[0048] Optionally, the average response latency for a user accessing a microservice group refers to the average time from when a user sends a request to when they receive the processing result from the microservice group. The magnitude of the average response latency directly affects user experience and satisfaction, especially for applications with high real-time requirements.

[0049] Optionally, response latency includes microservice processing time, network transmission latency, and inter-microservice collaboration latency. In a microservice architecture, an application may consist of multiple independent but collaborative microservices. Therefore, the calculation of response latency must comprehensively consider the processing time of each microservice and the network latency of communication between them. Reducing average response latency can improve user access speed and experience. This can be achieved through various strategies such as reasonable service layout, optimizing communication paths between microservices, and improving local processing performance.

[0050] Secondly, the deployment cost of a microservice group refers to the fixed and operational costs required to deploy microservices, including the cost of renting or purchasing cloud resources, network connection fees, and potential additional maintenance expenses. Factors influencing deployment costs include: the price of cloud resources, the resource requirements of the microservices, the deployment model (e.g., containerization, virtual machines) and strategy (centralized deployment, distributed deployment), and the long-term economics. Minimizing the total deployment cost can reduce the operational burden on enterprises. Optimization strategies may include finding the most cost-effective cloud resources, utilizing idle computing resources, and designing efficient resource allocation algorithms.

[0051] The transmission cost of a microservice group refers to the cost incurred due to network transmission when microservices need to exchange data across data centers. This involves the cost of data transmission volume, transmission distance, and network bandwidth. Factors affecting transmission costs include: the network architecture between different cloud providers, the frequency and magnitude of data transmission between microservices, and the geographical distribution and network performance of cloud data centers. Reducing transmission costs can be achieved by optimizing service deployment locations, minimizing unnecessary data transmission, and utilizing lower-cost transmission lines.

[0052] The deployment efficiency of microservice groups is primarily reflected in the reliability and speed of service deployment, i.e., the probability or ratio of successfully deploying microservices to suitable resources within a specified time. In the dynamic resource environment of a computing network, deployment efficiency directly impacts service availability and user wait time. Factors affecting deployment efficiency include: cloud resource availability, failure rate during deployment, and the complexity and automation level of microservice deployment. Improving deployment efficiency can shorten service launch time and enhance system stability and reliability. Optimization strategies for deployment efficiency include: increasing cloud resource redundancy, improving deployment algorithms, and pre-configuring commonly used services.

[0053] It should be noted that in computing networks, the interconnection of multiple cloud data centers constitutes a highly dynamic and widely distributed resource environment. In such an environment, focusing solely on a single objective often neglects other important aspects, leading to poor overall system performance or excessive costs. Therefore, this application proposes a microservice deployment strategy based on multi-objective optimization, taking the aforementioned four aspects as comprehensive optimization objectives. The aim is to find a series of Pareto optimal solutions through algorithms, achieving a balance between cost, efficiency, and user experience. This ensures the optimal deployment state of microservice groups even under constantly changing resource prices, network conditions, or user needs, thereby providing stable and efficient services.

[0054] Step S103: Determine the target model for achieving each optimization objective based on the physical network model and the service model.

[0055] Optionally, firstly, for scenarios involving the interconnection of multiple cloud data centers in a computing power network, a system model is constructed, including a physical network model (used to characterize the attributes of each cloud data center and its internal attributes and the link attributes between nodes in the scenario of interconnection of multiple cloud data centers in a distributed computing power network) and a microservice service model (used to represent the dependencies between microservices that make up the application, and the process of users accessing the application); then, the availability of the application to users is taken as a constraint, and the average response latency of users accessing the application (microservice group), the deployment cost and transmission cost of the microservice group, and the deployment efficiency of the microservice group are taken as optimization objectives, and mathematical models for average request response latency, total cost (deployment cost and transmission cost), deployment efficiency, and resource availability are designed respectively; then, based on the constructed mathematical models, a multi-objective optimization problem is modeled; finally, a multi-objective optimization algorithm is used as the solution algorithm for the problem, and the algorithm solution process is designed.

[0056] Step S104: Deploy the microservices in the microservice group according to the target model of multiple optimization objectives.

[0057] Optionally, in a computing network, the deployment of microservices needs to comprehensively consider user access response time, deployment and transmission costs, deployment efficiency, and resource availability. The construction of the target model transforms these abstract objectives into concrete mathematical expressions, providing a solvable mathematical framework for the algorithm. By treating each microservice in the microservice group as a decision variable, the algorithm can explore different deployment schemes, evaluate their performance under each optimization objective, and ultimately select a deployment strategy that balances all optimization objectives.

[0058] Based on the above steps S101 to S104, this application first constructs a physical network model and a service model for the microservice group. The physical network model characterizes the internal attributes of each data center and the link attributes between nodes in a scenario where multiple data centers are interconnected. The service model characterizes the dependencies and access processes between different microservices within the microservice group. Then, multiple optimization objectives are determined, including at least: the average response latency for user access to the microservice group, the deployment cost of the microservice group, the transmission cost of the microservice group, and the deployment efficiency of the microservice group. Based on the physical network model and the service model, a target model is determined to achieve each optimization objective. Then, based on the target models for the multiple optimization objectives, the microservices in the microservice group are deployed.

[0059] As can be seen from the above, this application, by designing multi-dimensional optimization objectives and combining the constructed physical network model and the service model of the microservice group, can dynamically adjust the deployment method of each microservice when deploying it, thereby improving the deployment flexibility of microservices. Moreover, the deployment of microservices is constrained by multiple optimization objectives, which can also improve the deployment accuracy of microservices and ensure that microservices can be deployed to better data centers and containers. This solves the technical problems of poor dynamic deployment flexibility and accuracy of microservices in cross-cloud deployment scenarios in the prior art.

[0060] In one optional embodiment, constructing a physical network model includes: determining a first set and a second set, wherein the first set includes the node locations of each data center and the second set includes link information between the data centers; determining the transmission cost and transmission latency between any two data centers; determining a set of container types for each data center, wherein the set of container types for each data center includes all container types that make up the data center; and constructing a physical network model based on the first set, the second set, the transmission cost and transmission latency between any two data centers, and the set of container types for each data center.

[0061] Optionally, a physical network model can be constructed to characterize the attributes of each cloud data center and its internal attributes and the link attributes between nodes in the multi-cloud data center interconnection scenario in the distributed computing power network.

[0062] Optionally, for scenarios involving the interconnection of multiple cloud data centers in a computing power network, this application constructs the distributed interconnected cloud data center network as a completely undirected graph. in, This represents the set of distributed interconnected cloud data center node locations (corresponding to the first set mentioned above). This represents the set of links connecting cloud data centers (corresponding to the second set mentioned above). The transmission cost between cloud data centers m and n is denoted as tc. mn The transmission delay is represented as tt mn In the subsequent problem-solving process, this application temporarily ignores the transmission cost (i.e., transmission latency) between microservices deployed in the same cloud data center, and only considers the transmission cost and transmission latency between microservices deployed in different data centers.

[0063] Optionally, each cloud data center offers multiple types of containers for users. This application represents the total set of container types as follows: The container types available in each data center are: A subset (i.e., the set of container types for each data center). Simultaneously, the container types located within the data center... Represented as: At the same time, users purchase The cost is expressed as: c ij .

[0064] Figure 2 This is a schematic diagram of an optional physical network model according to an embodiment of this application, such as... Figure 2 As shown, the cloud data centers include: Cloud Data Center A0 (the container types in this data center include V4, V2, and V6), Cloud Data Center A1 (the container types in this data center include V0, V2, V3, and V6), Cloud Data Center A2 (the container types in this data center include V0, V2, and V10), Cloud Data Center A3 (the container types in this data center include V5, V9, V3, and V4), and Cloud Data Center A4 (the container types in this data center include V0, V7, V3, and V6).

[0065] In one optional embodiment, constructing a service model for a microservice group includes: generating a directed acyclic graph (DAG) based on the microservice group, wherein the DAG is used to describe the dependency and invocation relationships between multiple microservices in the microservice group; and constructing a service model for the microservices based on the DAG, a user center set, and a replica deployment strategy, wherein the user center set includes various user groups that invoke the microservices, and the replica deployment strategy is used to limit the one-to-one deployment relationship between each microservice replica and a container, and each microservice and its replica are deployed on a container type in the same cloud data center.

[0066] Optionally, to address the deployment problem of applications composed of microservices, this application can represent the set of dependent microservices to be deployed as follows: To clearly illustrate the application's business processes, namely the dependencies and calls between microservices, this set of microservices that need to be deployed (also known as a microservice group) is modeled as a directed acyclic graph. in, This represents a group of nodes that constitute a microservice. This represents a set of directed links connecting microservices. This indicates that microservices s m and s n A directed link that connects the links. Based on e mn s m Known as s n The parent service, s n It is s m Sub-services. A microservice may have more than one parent service and one child service. This application will define the microservices as follows: l The set of sub-services is represented as: Sub(s) l The parent service set is represented as: Par(s) l).

[0067] In addition, this application also sets a replica deployment strategy: each microservice replica is deployed on only one container, and one container can only deploy one microservice replica. Each microservice and its multiple replicas are deployed on one type of container in the same cloud data center. (Using variables) Indicates: microservices l Deployed in cloud data centers Use container type The number of microservices, i.e. l Deployed in cloud data centers Number of copies n l The operation model for each microservice instance is an M / M / 1 queuing model.

[0068] Furthermore, consider a set of user centers. This serves as a central point representing a user group in a specific region. Users typically access microservices through an API gateway as the unified entry point. Requests to this group of microservices from the user center are generated according to a Poisson distribution. The request rate varies periodically, measured in seconds. Within one second, the gateway request rate λ... k Indicates from user center U k The request frequency to the API gateway of the microservice group.

[0069] Optionally, Figure 3 This is a schematic diagram of an optional microservice group service model according to an embodiment of this application, such as... Figure 3 As shown, the user center set includes four user centers: U0, U1, U2, and U3. Through the API gateway, it first connects to microservice S0, then to microservice S1 via link e01, then to microservice S2 via link e12, and finally to microservice S3 via link e13. Microservice S2 connects to microservice S4 via link e24, and microservice S4 connects to microservice S5 via link e45. Microservice S3 connects to microservice S5 via link e35. Microservice S5 returns service information to the user center through the API gateway.

[0070] In one optional embodiment, determining the target model for each optimization objective based on the physical network model and the service model includes: determining the network latency between the user center and the first microservice accessed based on the physical network model to obtain first data; determining the network latency between the user center and the last microservice accessed based on the physical network model to obtain second data; determining the workload of the microservice group and the gateway request frequency from the user center to the microservice group based on the service model; determining the network latency between the user center and the microservice group based on the first data, the second data, the workload of the microservice group, and the gateway request frequency; and determining the target model for the average response latency of user access to the microservice group by summing the response time and network latency within the microservice group.

[0071] Optionally, to determine the target model for the average response latency of user access to the microservice group (i.e., the mathematical model for the average response latency of user requests), the microservice s can be defined. l The workload is given by formula (1):

[0072]

[0073] Since this application models the operations of each microservice instance as an M / M / 1 queuing model, then the microservice s l The average request processing time can be defined by formula (2):

[0074]

[0075] Where, α l microservices l After deployment to a container, the number of user requests that can be processed per unit of time, n l microservices l The total number of copies.

[0076] Optionally, User Center U k The network latency between the microservice group and the microservice group can be expressed as formula (3):

[0077]

[0078] Among them, It k User Center U k Network latency between the first microservice accessed (corresponding to the first data mentioned above, i.e., including the user center U) k Network latency to the API gateway of the microservice group and network latency between the API gateway and the first microservice to which the request is received. k User Center U kThe network latency between the last microservice accessed (corresponding to the second data mentioned above, which includes the network latency from the last microservice to the API gateway and the latency from the API gateway to the user center U) k (Network latency between).

[0079] Therefore, the average response time of a microservice group (application) (i.e., the average response time for user requests) can be expressed as formula (4):

[0080] ART = ut + MS (4)

[0081] The function MS is used to calculate the response time (also known as uptime) within the microservice group. This application defines two functions, EST (earliest start time) and FT (end time), for each microservice to calculate the validity period of the microservice group. The calculation process begins with the start of access to the microservice, and MS is the end time of the last accessed microservice. See equations (5) to (8) below:

[0082] EST(s0)=0(5)

[0083] FT(s l ) = EST(s l )+pt l (6)

[0084]

[0085] MS = FT(s) |S|-1 (8)

[0086] Among them, st ml microservices m With microservices l Transmission delay between them, in seconds.

[0087] In one optional embodiment, determining the target model for each optimization objective based on the physical network model and the service model includes: determining the data center and container type deployed for each microservice in the microservice group based on the physical network model and the service model; determining the target model corresponding to the deployment cost of the microservice group based on the data center and container type deployed for each microservice; determining the transmission cost between any two microservices in the microservice group based on the physical network model and the service model; and determining the target model corresponding to the transmission cost of the microservice group when processing user requests based on the transmission cost between any two microservices.

[0088] Optionally, when deploying a group of microservices with certain dependencies, in addition to considering the deployment cost of the microservices (i.e., the cost of renting containers in each data center), it is also necessary to consider the data transfer cost between microservices during runtime. The sum of these two costs is considered as the total cost of deploying the microservice group.

[0089] Among them, microservices l The deployment cost can be defined by formula (9):

[0090]

[0091] in, microservices l Is it deployed in data center A? i Container type V j If so, then otherwise, In other words, Used to characterize the data center and container type deployed for each microservice in a microservice group.

[0092] Therefore, the deployment cost of a microservice group can be defined by formula (10):

[0093]

[0094] Alternatively, the average transmission cost for processing user requests can be defined by formula (11):

[0095] TTC = TC(s) |S|-1 (11)

[0096] The function TC is used to calculate the transmission cost between microservices. Refer to formulas (11) and (12) below.

[0097] TC(s0)=0 (11)

[0098]

[0099] Where, p ml microservices m With microservices l The transmission cost between them.

[0100] Therefore, the total deployment cost (deployment cost + transmission cost) can be expressed as formula (13):

[0101] TDTC=TDC+TTC (13)

[0102] In one optional embodiment, the target model for each optimization objective is determined based on the physical network model and the service model, including: determining the data center and container type corresponding to each microservice in the microservice group, and determining the expected value corresponding to the remaining quantity of each type of container in each data center, based on the physical network model and the service model; determining the probability information when each microservice is deployed to each container in each data center based on the expected value; determining the deployment success rate of each microservice based on the data center and container type corresponding to each microservice and the probability information; and determining the target model corresponding to the deployment efficiency of the microservice group based on the deployment success rate of each microservice in the microservice group.

[0103] Optionally, in computing power networks, since multi-cloud environment resources are often dynamically changing and exhibit volatility and uncertainty, the deployment efficiency of microservices needs to be considered when studying the deployment problem of microservices in multi-cloud data center interconnection scenarios within computing power networks. Deployment efficiency characterizes the probability of successfully executing a deployment request (i.e., requesting the cloud data center to provide the required number of container instances) according to the resource requirements and deployment location requirements of the microservice.

[0104] Microservice architecture encourages service autonomy and decoupling. Each microservice is typically designed to run as independently as possible, allowing them to be developed, deployed, scaled, and maintained independently. This design philosophy is also adopted in this application; each microservice is considered independent during deployment, meaning the success or failure of one microservice's deployment will not directly affect the deployment success rate of another microservice.

[0105] Therefore, assuming that data center A provided by the cloud provider... i The remaining container type V j The quantity of resources is a random variable R. ij It follows a Poisson distribution: R ij ~π(λ) ij ), that is, random variable R ij The possible values ​​of are 0, 1, 2, 3..., and the probability of each value can be expressed as shown in formula (14):

[0106]

[0107] Therefore, the probability distribution function can be defined as shown in formula (15):

[0108]

[0109] Where, λ ij This represents the expected value of the Poisson distribution, which is also the value of data center A. i Remaining quantity V of container type j The expected value.

[0110] Therefore, microservices l The overall deployment success rate can be defined by formula (16):

[0111]

[0112] in, microservices l Is it deployed in data center A? i Container type V j If so, then otherwise,

[0113] The deployment efficiency of microservice group S (application) is defined as the product of the successful deployments of all microservices, as shown in formula (17):

[0114]

[0115] In one optional embodiment, deploying microservices in a microservice group according to a target model with multiple optimization objectives includes: deploying microservices in a microservice group according to at least one of the following constraints and the target model with multiple optimization objectives:

[0116] The first constraint is used to ensure that the amount of idle resources in the microservice group is greater than or equal to the minimum amount of resources required to process user requests.

[0117] The second constraint is used to restrict microservices of the same type from being deployed to the same container in the same data center;

[0118] The third constraint is used to ensure that the actual workload of the microservice group does not exceed the maximum load threshold of the microservice group when processing user requests.

[0119] Optionally, Figure 4 This is a framework flowchart of an optional microservice deployment method according to an embodiment of this application, such as... Figure 4As shown, firstly, for the scenario of interconnecting multiple cloud data centers in a computing power network, a system model is constructed through a system model construction module. This includes a physical network model (used to represent the attributes of each cloud data center and its internal attributes and the link attributes between nodes in the scenario of interconnecting multiple cloud data centers in a distributed computing power network) and a microservice service model (used to represent the dependencies between microservices that make up the application, as well as the user's access to the application process). Then, the availability of the application to the user is taken as a constraint, and the average response latency of the user accessing the application (microservice group), the deployment cost and transmission cost of the microservice group, and the deployment efficiency of the microservice group are taken as optimization objectives. Through a mathematical model and objective function establishment module, mathematical models for average request response latency, total cost (deployment cost and transmission cost), deployment efficiency, and resource availability are designed respectively.

[0120] Among them, data center A i Container type V j Availability per unit time can be expressed as: a ij Resource availability refers to the percentage of time a resource is in normal service within a given unit of time, relative to the total available time. The availability of resources varies significantly across different data centers and container types, and this is one of the factors used to measure the service level of a cloud service provider. In this application, application resource availability is considered a constraint, meaning that the application's resource availability must meet the user's minimum standards.

[0121] Based on the above, the availability of microservices can be defined by formula (18):

[0122]

[0123] The overall service availability of the microservice group S (application) can be further defined by formula (19):

[0124]

[0125] Then, based on the constructed mathematical model, a multi-objective optimization problem is modeled; finally, a multi-objective optimization algorithm is used as the solution algorithm, and the algorithm solution process is designed. For example, in this application, the average response latency of user requests, total deployment cost, and deployment efficiency are used as optimization objectives, while being constrained by user requirements for the resource availability of the deployed application, the deployment location of microservices, and the load of microservices.

[0126] like Figure 4 As shown, based on the mathematical model established above, the objective function can be obtained as shown in formula (20):

[0127]

[0128] Among them, through three-dimensional tensors To represent the microservice deployment plan, use a one-dimensional variable. This indicates the number of replicas deployed in a microservice.

[0129] Optionally, the constraints for solving the mathematical model in this application are determined as follows:

[0130] (1) User availability requirement constraint (corresponding to the first constraint above): The resource availability of the application providing the service needs to meet the user's required level, referring to formula (21):

[0131] AVA S ≥b (21)

[0132] Where b is the minimum requirement for the availability of application resources.

[0133] (2) Deployment location constraint (corresponding to the second constraint above): A microservice can only be deployed to the same container type in one cloud data center, referring to formula (22):

[0134]

[0135] (3) Load constraint (corresponding to the third constraint above): The workload of a microservice will not exceed its request processing capacity, as shown in formula (23):

[0136]

[0137] like Figure 4 As shown, a data collection module can also be used to collect data on microservice transmission latency and cost, container distribution and availability, and user distribution and request patterns. Then, using this collected information and the mathematical model constructed above, the microservice deployment module uses the NSGA-III algorithm (Nondominated Sorting Genetic Algorithm III) to solve for the optimal deployment strategy, and then deploys the microservices according to the optimal deployment strategy.

[0138] It should be noted that this application includes a parameter setting module for configuring the data involved in the solution process. For multi-cloud data center interconnection scenarios in computing power networks, solving the microservice deployment strategy of this application requires configuring the transmission latency and cost between each cloud data center, container distribution and availability, user distribution and request conditions, including the transmission cost tc between cloud data centers m and n. mn Transmission delay tt mn microservices m and s n Transmission delay between st mland cost p ml Container type V in each cloud data center ij and its remaining quantity R ij and its purchase cost c ij User access frequency λ k and User Center U k Communication latency between applications It k and Ot k Data Center A i Container type V j Availability per unit time a ij wait.

[0139] In one alternative embodiment, the microservices in the microservice group are deployed according to a target model based on at least one of the following constraints and multiple optimization objectives, including:

[0140] Step 1: For the target model with multiple optimization objectives, generate a parent population that meets the constraints, where the parent population represents the initial solution of the first generation.

[0141] Step 2: After performing non-dominated sorting on the generated parent population, the offspring population is obtained through selection crossover mutation.

[0142] Step 3: Merge the parent population with the offspring population, and after performing non-dominant sorting, determine the population individual rank, and identify all population individuals except the lowest-ranked individuals as individuals of the next generation population.

[0143] Step 4: Normalize the individuals of the lowest-ranking population and calculate the vertical distance from the individual to the reference point. Based on the vertical distance, select at least one individual from all the individuals of the lowest-ranking population as the individual for the next generation population.

[0144] Step 5: Selective crossover and mutation are performed on the individuals of the next generation population. At the same time, it is determined whether the maximum number of evolutionary iterations has been reached. If the maximum number of evolutionary iterations has not been reached, the evolutionary count is incremented by one, and the process returns to Step 3 to continue iterating. If the maximum number of evolutionary iterations has been reached, proceed to Step 6.

[0145] Step 6: Select the objective solution that satisfies the constraints from all the obtained solutions;

[0146] Step 7: Deploy the microservices in the microservice group according to the target solution.

[0147] Optionally, based on the preceding problem modeling, the problem of solving the objective model in this application is actually a multi-objective optimization problem. In a multi-cloud environment, there are many available container types in different data center locations, resulting in a large search space. Therefore, this application adopts the heuristic algorithm NSGA-III for multi-objective optimization to solve the problem. Based on the data set in the data parameter setting module, the NSGA-III algorithm is used to solve for the optimal microservice deployment strategy. The NSGA-III algorithm solution process is designed as follows: Figure 5 As shown.

[0148] It should be noted that, during the initial population generation, since the initial population is randomly generated and the solution space is very large, ensuring that every individual satisfies the user availability constraints could lead to an infinite loop in the initial population generation process. Therefore, a maximum number of loops is set during the initial population generation process. This may result in some individuals not satisfying the availability constraints. Similarly, after performing crossover and mutation operations on the population, some individuals may also fail to satisfy the availability constraints. However, this does not hinder the solution of the problem. This application adopts a boundary condition relaxation approach, initially disregarding the requirement that all individuals satisfy the constraints. After the solution process is completed, all Pareto optimal solutions that satisfy the constraints are selected from the feasible solutions.

[0149] like Figure 5 As shown, the solution process of the NSGA-III algorithm used in this application is as follows:

[0150] Step 1: Generate an initial solution that meets the constraints (first generation parent population).

[0151] Step 2: After performing non-dominated sorting on the generated initial population, the first generation offspring population is obtained through selection crossover mutation. The number of evolutions is counted as 2.

[0152] Step 3: Merge the parent and offspring populations, perform rapid non-dominated sorting, determine the individual rank of the population, and directly assign individuals with higher ranks to the next generation of the population.

[0153] Step 4: In the last level, individuals are normalized and their vertical distance to the reference point is calculated. The remaining outstanding individuals are selected to enter the next generation of the new parent population.

[0154] Step 5: Selective crossover mutation is performed on the parent population generated in the new generation. At the same time, it is determined whether the maximum number of evolutionary iterations has been reached. If not, the number of evolutionary iterations is incremented by one, and the process returns to step 3 to continue iterating.

[0155] Step 6: After reaching the maximum number of evolutions, select all Pareto optimal solutions that satisfy the constraints from the obtained feasible solutions. Solution complete.

[0156] According to another aspect of this application, a microservice deployment apparatus is also provided, wherein, Figure 6 This is a schematic diagram of an optional microservice deployment apparatus according to an embodiment of this application, such as... Figure 6 As shown, the device includes: a model building unit 601, used to build a physical network model and a service model for a microservice group, wherein the physical network model is used to characterize the internal attributes of each data center and the link attributes between nodes in a scenario where multiple data centers are interconnected; the service model is used to characterize the dependencies and access processes between different microservices in the microservice group; a first determining unit 602, used to determine multiple optimization objectives, wherein the multiple optimization objectives include at least: the average response latency of user access to the microservice group, the deployment cost of the microservice group, the transmission cost of the microservice group, and the deployment efficiency of the microservice group; a second determining unit 603, used to determine a target model for achieving each optimization objective based on the physical network model and the service model; and a deployment unit 604, used to deploy the microservices in the microservice group according to the target models of the multiple optimization objectives.

[0157] Optionally, the model building unit 601 includes: a first determining subunit for determining a first set and a second set, wherein the first set includes the node locations of each data center and the second set includes link information between the data centers; a second determining subunit for determining the transmission cost and transmission latency between any two data centers; a third determining subunit for determining the container type set of each data center, wherein the container type set of each data center includes all container types that make up the data center; and a building subunit for building a physical network model based on the first set, the second set, the transmission cost and transmission latency between any two data centers, and the container type set of each data center.

[0158] Optionally, the model building unit 601 includes: a generation subunit, used to generate a directed acyclic graph based on the microservice group, wherein the directed acyclic graph is used to describe the dependency and calling relationships between multiple microservices in the microservice group; and a building subunit, used to build a service model of the microservices based on the directed acyclic graph, the user center set, and the replica deployment strategy, wherein the user center set includes various user groups that call the microservices, and the replica deployment strategy is used to limit the one-to-one deployment relationship between each microservice replica and a container, and each microservice and its replica are deployed on a container type in the same cloud data center.

[0159] Optionally, the second determining unit 603 includes: a fourth determining subunit, used to determine the network latency between the user center and the first accessed microservice based on the physical network model, and obtain first data; a fifth determining subunit, used to determine the network latency between the user center and the last accessed microservice based on the physical network model, and obtain second data; a sixth determining subunit, used to determine the workload of the microservice group and the gateway request frequency from the user center to the microservice group based on the service model; a seventh determining subunit, used to determine the network latency between the user center and the microservice group based on the first data, the second data, the workload of the microservice group, and the gateway request frequency; and an eighth determining subunit, used to determine the target model of the average response latency of the user accessing the microservice group by summing the response time and network latency within the microservice group.

[0160] Optionally, the second determining unit 603 includes: a ninth determining subunit, used to determine the data center and container type deployed for each microservice in the microservice group based on the physical network model and service model; a tenth determining subunit, used to determine the target model corresponding to the deployment cost of the microservice group based on the data center and container type deployed for each microservice; an eleventh determining subunit, used to determine the transmission cost between any two microservices in the microservice group based on the physical network model and service model; and a twelfth determining subunit, used to determine the target model corresponding to the transmission cost of the microservice group when processing user requests based on the transmission cost between any two microservices.

[0161] Optionally, the second determining unit 603 includes: a thirteenth determining subunit, used to determine the data center and container type corresponding to each microservice in the microservice group based on the physical network model and service model, and to determine the expected value corresponding to the remaining quantity of each type of container in each data center; a fourteenth determining subunit, used to determine the probability information of each microservice when deployed to each container in each data center based on the expected value; a fifteenth determining subunit, used to determine the deployment success rate of each microservice based on the data center and container type corresponding to each microservice and the probability information; and a sixteenth determining subunit, used to determine the target model corresponding to the deployment efficiency of the microservice group based on the deployment success rate of each microservice in the microservice group.

[0162] Optionally, deployment unit 604 includes: a deployment subunit for deploying microservices in a microservice group according to a target model based on at least one of the following constraints and multiple optimization objectives:

[0163] The first constraint is used to ensure that the amount of idle resources in the microservice group is greater than or equal to the minimum amount of resources required to process user requests.

[0164] The second constraint is used to restrict microservices of the same type from being deployed to the same container in the same data center;

[0165] The third constraint is used to ensure that the actual workload of the microservice group does not exceed the maximum load threshold of the microservice group when processing user requests.

[0166] Optionally, the deployment subunit includes: a first execution module for executing step one, generating a parent population that meets the constraints for a target model with multiple optimization objectives, wherein the parent population represents the initial solution of the first generation; a second execution module for executing step two, obtaining a offspring population by performing non-dominated sorting on the generated parent population and then selecting crossover mutation; a third execution module for executing step three, merging the parent and offspring populations, and determining the individual rank of the population after performing non-dominated sorting, and determining all individuals in the population except the lowest-ranked individuals as individuals of the next generation population; and a fourth execution module for executing step four, normalizing the individuals in the lowest-ranked population and calculating... Calculate the vertical distance from the individual in the population to the reference point. Based on the vertical distance, select at least one individual from all the individuals with the lowest rank as the next generation population. The fifth execution module is used to execute step five: perform selection, crossover, and mutation on the individuals in the next generation population, and determine whether the maximum number of evolutionary iterations has been reached. If the maximum number of evolutionary iterations has not been reached, increment the number of evolutionary iterations by one and return to step three to continue iterating. If the maximum number of evolutionary iterations has been reached, proceed to step six. The sixth execution module is used to execute step six, and select the target solution that satisfies the constraints from all the obtained solutions. The seventh execution module is used to execute step seven, and deploy the microservices in the microservice group according to the target solution.

[0167] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein the computer-readable storage medium stores a computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located performs the microservice deployment method described above.

[0168] According to another aspect of the embodiments of this application, an electronic device is also provided, wherein the electronic device includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors perform the microservice deployment method described above.

[0169] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0170] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0171] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0172] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0173] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0174] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0175] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A microservice deployment method, characterized in that, include: Construct a physical network model and a service model for microservice groups. The physical network model is used to characterize the internal attributes of each data center and the link attributes between nodes in a scenario where multiple data centers are interconnected. The service model is used to characterize the dependencies and access processes between different microservices in the microservice group. Multiple optimization objectives are identified, including at least: the average response latency of user access to the microservice group, the deployment cost of the microservice group, the transmission cost of the microservice group, and the deployment efficiency of the microservice group; Based on the physical network model and the service model, a target model is determined to achieve each optimization objective; Based on the target model of the multiple optimization objectives, the microservices in the microservice group are deployed; The deployment of microservices in the microservice group, based on the target model of the multiple optimization objectives, includes: Step 1: For the target model of the multiple optimization objectives, generate a parent population that meets the constraints, wherein the parent population represents the initial solution of the first generation; Step 2: After performing non-dominated sorting on the generated parent population, the offspring population is obtained through selection crossover mutation; Step 3: Merge the parent population with the offspring population, and after performing non-dominant sorting, determine the population individual rank, and determine all population individuals except the lowest-ranked individuals as individuals of the next generation population. Step 4: Normalize the individuals of the lowest-ranking population and calculate the vertical distance from the individual to the reference point. Based on the vertical distance, select at least one individual from all the individuals of the lowest-ranking population as the individual of the next generation population. Step 5: Selective crossover mutation is performed on the individuals of the next generation population, and it is determined whether the maximum number of evolutionary iterations has been reached. If the maximum number of evolutionary iterations has not been reached, the number of evolutionary iterations is incremented by one, and the process returns to Step 3 to continue iterating; if the maximum number of evolutionary iterations has been reached, the process proceeds to Step 6. Step 6: Select the target solution that satisfies the constraints from all the obtained solutions; Step 7: Deploy the microservices in the microservice group according to the target solution.

2. The method according to claim 1, characterized in that, Constructing a physical network model includes: Determine a first set and a second set, wherein the first set includes the node location of each data center, and the second set includes link information between the data centers; Determine the transmission cost and latency between any two data centers; Determine the set of container types for each data center, wherein the set of container types for each data center includes all container types that make up that data center; The physical network model is constructed based on the first set, the second set, the transmission cost and latency between any two data centers, and the set of container types for each data center.

3. The method according to claim 1, characterized in that, Building a service model for microservice groups includes: A directed acyclic graph is generated based on the microservice group, wherein the directed acyclic graph is used to describe the dependency and calling relationships between multiple microservices in the microservice group; Based on the directed acyclic graph, user center set, and replica deployment strategy, the service model of the microservice is constructed. The user center set includes various user groups that call the microservice. The replica deployment strategy is used to limit the one-to-one deployment relationship between each microservice replica and a container, and each microservice and its replica are deployed on a container type in the same cloud data center.

4. The method according to claim 1, characterized in that, Based on the physical network model and the service model, the target model for each optimization objective is determined, including: Based on the physical network model, the network latency between the user center and the first microservice accessed is determined to obtain the first data. The network latency between the user center and the last microservice accessed is determined based on the physical network model to obtain the second data; The workload of the microservice group and the frequency of gateway requests from the user center to the microservice group are determined based on the service model. Based on the first data, the second data, the workload of the microservice group, and the gateway request frequency, determine the network latency between the user center and the microservice group; The summation function of the response time within the microservice group and the network latency is determined as the target model for the average response latency of the user accessing the microservice group.

5. The method according to claim 1, characterized in that, Based on the physical network model and the service model, the target model for each optimization objective is determined, including: Based on the physical network model and the service model, determine the data center and container type deployed for each microservice in the microservice group; Based on the data center and container type deployed for each microservice, determine the target model corresponding to the deployment cost of the microservice group; Based on the physical network model and the service model, determine the transmission cost between any two microservices in the microservice group; Based on the transmission cost between any two microservices, determine the target model corresponding to the transmission cost of the microservice group when processing user requests.

6. The method according to claim 1, characterized in that, Based on the physical network model and the service model, the target model for each optimization objective is determined, including: Based on the physical network model and the service model, determine the data center and container type deployed for each microservice in the microservice group, and determine the expected value corresponding to the remaining quantity of each type of container in each data center; Based on the expected value, determine the probability information when each microservice is deployed to each container in each data center; The deployment success rate of each microservice is determined based on the data center and container type deployed for each microservice and the probability information. Based on the deployment success rate of each microservice in the microservice group, determine the target model corresponding to the deployment efficiency of the microservice group.

7. The method according to claim 1, characterized in that, Based on the target model of the multiple optimization objectives, the microservices in the microservice group are deployed, including: Deploy the microservices in the microservice group according to at least one of the following constraints and the target model of the multiple optimization objectives: The first constraint condition is used to ensure that the amount of idle resources in the microservice group is greater than or equal to the minimum amount of resources required to process user requests. The second constraint is used to restrict microservices of the same type from being deployed to the same container in the same data center; The third constraint is used to ensure that the actual workload of the microservice group does not exceed the maximum load threshold of the microservice group when processing user requests.

8. A microservice deployment device, characterized in that, include: The model building unit is used to build a physical network model and a service model for a microservice group. The physical network model is used to characterize the internal attributes of each data center and the link attributes between nodes in a scenario where multiple data centers are interconnected. The service model is used to characterize the dependency relationships and access processes between different microservices in the microservice group. The first determining unit is used to determine multiple optimization objectives, wherein the multiple optimization objectives include at least: the average response latency of user access to the microservice group, the deployment cost of the microservice group, the transmission cost of the microservice group, and the deployment efficiency of the microservice group; The second determining unit is used to determine the target model for achieving each optimization objective based on the physical network model and the service model; The deployment unit is used to deploy the microservices in the microservice group according to the target model of the multiple optimization objectives; The deployment unit includes a deployment subunit, which includes: The first execution module is used to execute step one, which generates a parent population that meets the constraints for the target model of the multiple optimization objectives, wherein the parent population represents the initial solution of the first generation. The second execution module is used to execute step two, which involves performing non-dominated sorting on the generated parent population and then obtaining the offspring population through crossover mutation. The third execution module is used to execute step three, which merges the parent population with the offspring population, and after performing non-dominant sorting, determines the population individual level, and determines all population individuals except the lowest level individual as individuals of the next generation population. The fourth execution module is used to execute step four, which involves normalizing the lowest-ranked individuals in the population and calculating the vertical distance from the individual to the reference point. Based on the vertical distance, at least one individual is selected from all the lowest-ranked individuals in the population as the next generation of individuals. The fifth execution module is used to execute step five, which involves selecting and crossovering individuals in the next generation population, and simultaneously determining whether the maximum number of evolutionary iterations has been reached. If the maximum number of evolutionary iterations has not been reached, the evolutionary count is incremented by one, and the process returns to step three to continue iterating. If the maximum number of evolutionary iterations has been reached, the process proceeds to step six. The sixth execution module is used to execute step six, selecting the target solution that satisfies the constraints from all the obtained solution results; The seventh execution module is used to execute step seven, which involves deploying the microservices in the microservice group according to the target solution.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed, the device in which the computer-readable storage medium resides performs the microservice deployment method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the microservice deployment method according to any one of claims 1 to 7.

Images