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

Abstract

The invention discloses a micro-service deployment method and device, electronic equipment and a storage medium, and relates to the technical field of big data. The method comprises the following steps: constructing a physical network model and a service model of a micro-service group; the service model is used for representing a dependency relationship and an access flow between different micro-services in the micro-service group; a plurality of optimization objectives are determined, and the optimization objectives at least comprise the average response time delay when the user accesses the micro-service group, the deployment cost of the micro-service group, the transmission cost of the micro-service group and the deployment efficiency of the micro-service group; determining a target model for realizing each optimization target according to the physical network model and the service model; and deploying the micro-services in the micro-service group according to the target models of the plurality of optimization targets. According to the method and the device, the technical problems of poor flexibility and accuracy of micro-service dynamic deployment in a micro-service cross-cloud deployment scene in the prior art are solved.

Description

Technical Field

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

[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 unified and coordinated scheduling of multi-dimensional resources such as network, storage, and computing power, massive applications will be able to call ubiquitously distributed computing resources on demand and in real time. The goal is to build a new network infrastructure that can keenly perceive computing power, ensure that the network can allocate computing resources in different geographical locations in real time according to actual needs, and thereby improve 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. Some have achieved cross-cloud deployment, but when conducting research, they often only consider either deployment cost or user response latency as the optimization objective, while ignoring deployment efficiency and inter-microservice transmission costs. In computing networks, cloud environments are often dynamic, and resources are volatile and uncertain. Therefore, existing technologies for cross-cloud deployment of microservices suffer from poor flexibility and accuracy in dynamic deployment.

[0004] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0005] The embodiments of the present application provide a microservice deployment method, device, electronic device and storage medium to at least solve the technical problems in the prior art of poor flexibility and accuracy in dynamic deployment of microservices in scenarios where microservices are deployed across clouds.

[0006] According to one aspect of an embodiment of the present application, a microservice deployment method is provided, including: constructing a physical network model and a service model of a microservice group, wherein the physical network model is used to characterize the internal properties of each data center and the link properties 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 targets, wherein the multiple optimization targets include at least: the average response delay of users accessing 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 target based on the physical network model and the service model; and deploying the microservices in the microservice group based on the target models of the multiple optimization targets.

[0007] Optionally, constructing a physical network model includes: determining 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 each data center; determining the transmission cost and transmission delay between any two data centers; determining a container type set for each data center, wherein the container type set for each data center includes all container types that constitute the data center; and constructing a physical network model based on the first set, the second set, the transmission cost and transmission delay between any two data centers, and the container type set of each data center.

[0008] Optionally, constructing a service model for a microservice group includes: generating 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; constructing a service model for the microservice based on the directed acyclic graph, a user center set, and a replica deployment strategy, wherein the user center set includes various user groups that call the microservice, and the replica deployment strategy is used to limit the existence of a one-to-one deployment relationship between a replica of each microservice and a container, and each microservice and the replica of the microservice are deployed on a container type in the same cloud data center.

[0009] Optionally, the target model of each optimization target is determined according to the physical network model and the service model, including: determining the network delay between the user center and the first microservice visited according to the physical network model to obtain first data; determining the network delay between the user center and the last microservice visited according to 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 according to the service model; determining the network delay between the user center and the microservice group according to the first data, the second data, the workload of the microservice group, and the gateway request frequency; and determining the sum function of the response time and the network delay within the microservice group as the target model of the average response delay of the user accessing the microservice group.

[0010] Optionally, the target model of each optimization target is determined based on the physical network model and the service model, including: determining the data center and container type corresponding to the deployment of 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 corresponding to the deployment of each microservice; determining the transmission cost between any two microservices in the microservice group based on the physical network model and the service model; 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 of each optimization target is determined based on the physical network model and the service model, including: determining the data center and container type corresponding to the deployment of each microservice in the microservice group, and determining the expected value corresponding to the remaining number of each 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 the deployment of each microservice and the probability information; 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, deploying the microservices in the microservice group according to the target model of the multiple optimization targets includes: deploying the microservices in the microservice group according to at least one of the following constraints and the target model of the multiple optimization targets:

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

[0014] The second constraint is used to constrain microservices of the same type to be deployed in the same container in the same data center.

[0015] The third constraint is used to constrain the actual workload of the microservice group to 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 the following at least one constraint and a target model of multiple optimization objectives, including: step 1, generating a parent population that meets the constraint conditions for the target model of multiple optimization objectives, wherein the parent population represents the initial solution of the first generation; step 2, performing non-dominated sorting on the generated parent population, and obtaining a child population by selecting crossover mutation; step 3, merging the parent population and the child population, and after performing non-dominated sorting, determining the level of the population individuals, and determining all the population individuals except the lowest-level population individual as individuals of the next generation population; step 4, performing crossover mutation on the lowest-level population The individuals are normalized and the vertical distance from the population individual to the reference point is calculated. Based on the vertical distance, at least one population individual is selected from all the population individuals with the lowest level as the individual of the next generation population; Step 5: Select crossover mutation for the individuals of 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, the number of evolutions is increased by one, and the process returns to Step 3 to continue iteration; if the maximum number of evolutionary iterations has been reached, the process proceeds to Step 6; Step 6: Select the target solution that meets the constraints from all the solution results obtained; Step 7: Deploy the microservices in the microservice group according to the target solution.

[0017] According to another aspect of an embodiment of the present application, a microservice deployment device is also provided, wherein the device includes: a model building unit, used to build a physical network model and a service model of a microservice group, wherein the physical network model is used to characterize the internal properties of each data center and the link properties 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 determination unit, used to determine multiple optimization targets, wherein the multiple optimization targets include at least: the average response delay of users accessing 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 determination unit, used to determine a target model for achieving each optimization target based on the physical network model and the service model; a deployment unit, used to deploy the microservices in the microservice group according to the target models of the multiple optimization targets.

[0018] According to another aspect of an embodiment of the present application, a computer-readable storage medium is further provided, wherein a computer program is stored in the computer-readable storage medium. When the computer program runs, the device where the computer-readable storage medium is located executes the above-mentioned microservice deployment method.

[0019] According to another aspect of an embodiment of the present application, an electronic device is further 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 execute the above-mentioned microservice deployment method.

[0020] In this application, a physical network model and a service model of a microservice group are first constructed, wherein the physical network model is used to characterize the internal properties of each data center and the link properties 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. Then, multiple optimization goals are determined, wherein the multiple optimization goals include at least: the average response delay of users accessing 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 target model for achieving each optimization goal is determined based on the physical network model and the service model, and the microservices in the microservice group are deployed based on the target models of the multiple optimization goals.

[0021] From the above content, it can be seen that this application, by designing multi-dimensional optimization goals and combining the constructed physical network model and the service model of the microservice group, can dynamically adjust the deployment method of microservices when deploying each microservice, thereby improving the deployment flexibility of microservices. Moreover, the premise of deploying microservices is constrained by multiple optimization goals, which can also improve the deployment accuracy of microservices and ensure that microservices can be deployed to better data centers and containers, thereby solving the technical problems of poor flexibility and accuracy in the dynamic deployment of microservices in the scenario of cross-cloud deployment of microservices in the existing technology. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

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

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

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

[0026] Figure 4 This is a framework flow chart of an optional microservice deployment method according to an embodiment of the present application;

[0027] Figure 5 is an optional NSGA-III algorithm solution flow chart according to an embodiment of the present application;

[0028] Figure 6 This is a schematic diagram of an optional microservice deployment device according to an embodiment of the present application. DETAILED DESCRIPTION

[0029] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0030] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[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, displayed data, etc.) collected by this application are information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of relevant data comply with the relevant laws, regulations and standards of the relevant regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entrances for users to choose to authorize or refuse. For example, an interface is set up between this system and relevant users or institutions. Before obtaining relevant information, it is necessary to send an acquisition request to the aforementioned user or institution through the interface, and obtain relevant information after receiving the consent information fed back by the aforementioned user or institution.

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

[0033] In an optional embodiment, a microservice deployment system can serve as the execution entity of the microservice deployment method in the embodiments of this application. The microservice deployment system can be a software system or an embedded system that combines software and hardware. In addition, in addition to being a microservice deployment system, the execution entity can also be other forms of entities, such as devices, equipment, etc. Those skilled in the art should be aware that this application does not specifically limit the specific form of the execution entity.

[0034] For the sake of convenience, the following description uses the microservice deployment system as the execution entity to explain the solution.

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

[0036] Step S101: construct a physical network model and a service model of a microservice group.

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

[0038] Optionally, the physical network model mainly describes the characteristics of each data center in the computing network and the connection status between each data center. 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 internal attributes such as its location, computing power, storage capacity, and network bandwidth are taken into consideration. These attributes directly determine the cost-effectiveness and applicability of the data center and are crucial for microservice deployment decisions.

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

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

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

[0043] Directed Acyclic Graph (DAG) representation: 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 directed edges between nodes represent dependencies. For example, 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 of a microservice group also considers how users access the microservice group through the API gateway. The flow of user requests, the processing order, and the return path are all reflected in the service model.

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

[0046] Step S102: determining multiple optimization objectives.

[0047] In step S102 , the multiple optimization objectives include at least: average response delay of 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.

[0048] Optionally, the average response latency for a user accessing a microservice group is the average time between a user sending a request and receiving the result processed by the microservice group. The average response latency directly impacts 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 microservices architecture, an application may consist of multiple independent yet collaborative microservices. Therefore, response latency calculation 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 rational 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 connectivity fees, and possible additional O&M expenses. Factors influencing deployment cost include the price of cloud resources, the resource requirements of microservices, the deployment model (such as containerization or virtual machines) and strategy (centralized or decentralized deployment), and the economic viability of long-term operations. Minimizing total deployment costs can reduce the operational burden on the enterprise. Optimization strategies may include identifying 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 network transmission costs incurred when microservices exchange data across data centers. This involves the amount of data transmitted, the transmission distance, and the cost of network bandwidth. Factors influencing transmission costs include the network structure between different cloud providers, the frequency and volume 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, reducing unnecessary data transmission, and utilizing lower-cost transmission lines.

[0052] The deployment efficiency of a microservice group is primarily reflected in the reliability and speed of service deployment, specifically the probability or rate of successfully deploying a microservice to appropriate resources within a specified timeframe. In the dynamic resource environment of a computing network, deployment efficiency directly impacts service availability and user wait times. Factors influencing deployment efficiency include the availability of cloud resources, the failure rate during deployment, the complexity of microservice deployment, and the degree of automation. Improving deployment efficiency can shorten service launch time and enhance system stability and reliability. Strategies for optimizing deployment efficiency include increasing cloud resource redundancy, improving deployment algorithms, and pre-setting common service configurations.

[0053] It should be noted that in the computing power network, the interconnection of multiple cloud data centers constitutes a highly dynamic environment with widely distributed resources. Faced with such an environment, focusing only on a single goal often ignores other important aspects, resulting in poor overall system performance or excessively high costs. Therefore, this application proposes a microservice deployment strategy based on multi-objective optimization, taking the above four aspects as comprehensive optimization goals, aiming to find a series of Pareto optimal solutions through algorithms to achieve a balance between cost, efficiency and user experience. In this way, even when resource prices, network conditions or user needs are constantly changing, the optimal deployment state of the microservice group can be ensured, thereby providing stable and efficient services.

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

[0055] Optionally, first, for the scenario of multi-cloud data center interconnection in the computing power network, a system model is constructed, including a physical network model (used to characterize the cloud data centers and their internal properties and link properties between nodes in the scenario of multi-cloud data center interconnection in the distributed computing power network) and a microservice service model (used to represent the dependencies between the microservices that make up the application, as well as the process of user access to the application); then, the availability of the user to the application is taken as a constraint condition, and the average response delay 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 regarded as optimization goals, and mathematical models of the average response delay of the request, the total cost (deployment cost and transmission cost) mathematical model, the deployment efficiency mathematical model, and the resource availability mathematical model are designed respectively; then, based on the constructed mathematical model, multi-objective optimization problems are modeled; finally, the multi-objective optimization algorithm is used as the problem-solving algorithm, and the algorithm solution process is designed.

[0056] Step S104: deploy the microservices in the microservice group according to the target models of the multiple optimization targets.

[0057] Alternatively, in a computing network, microservice deployment requires comprehensive consideration of user access response time, deployment and transmission costs, deployment efficiency, and resource availability. The construction of a goal model transforms these abstract goals into concrete mathematical expressions, providing a mathematical framework for the algorithm to solve. By treating each microservice in a microservice group as a decision variable, the algorithm can explore different deployment options, evaluate their performance under each optimization objective, and ultimately select a deployment strategy that balances all optimization objectives.

[0058] Based on the contents of steps S101 to S104 above, it can be seen that in this application, a physical network model and a service model of a microservice group are first constructed, wherein the physical network model is used to characterize the internal properties of each data center and the link properties 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. Then, multiple optimization targets are determined, wherein the multiple optimization targets include at least: the average response delay of users accessing 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 target model for achieving each optimization target is determined based on the physical network model and the service model, and the microservices in the microservice group are deployed based on the target models of the multiple optimization targets.

[0059] From the above content, it can be seen that this application, by designing multi-dimensional optimization goals and combining the constructed physical network model and the service model of the microservice group, can dynamically adjust the deployment method of microservices when deploying each microservice, thereby improving the deployment flexibility of microservices. Moreover, the premise of deploying microservices is constrained by multiple optimization goals, which can also improve the deployment accuracy of microservices and ensure that microservices can be deployed to better data centers and containers, thereby solving the technical problems of poor flexibility and accuracy in the dynamic deployment of microservices in the scenario of cross-cloud deployment of microservices in the existing technology.

[0060] In an optional embodiment, constructing a physical network model includes: determining 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 each data center; determining the transmission cost and transmission delay between any two data centers; determining a container type set for each data center, wherein the container type set for each data center includes all container types that constitute the data center; and constructing a physical network model based on the first set, the second set, the transmission cost and transmission delay between any two data centers, and the container type set for each data center.

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

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

[0063] Optionally, each cloud data center has multiple types of containers for users to use. This application represents the total container type set as: The container types that each data center has are A subset of (i.e., the set of container types in each data center). At the same time, the container types located in the data center Expressed as: At the same time, users purchase The cost is expressed as: c ij .

[0064] Figure 2 is a schematic diagram of an optional physical network model according to an embodiment of the present 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 an optional embodiment, a service model of a microservice group is constructed, including: generating 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; constructing a service model of the microservice based on the directed acyclic graph, a user center set, and a replica deployment strategy, wherein the user center set includes various user groups that call the microservice, and the replica deployment strategy is used to limit the existence of a one-to-one deployment relationship between a replica of each microservice and a container, and each microservice and the replica of the microservice are deployed on a container type in the same cloud data center.

[0066] Optionally, in order to solve the problem of deploying an application consisting of microservices, this application can express a set of microservices with dependencies to be deployed as follows: In order to clearly show the business process of the application, that is, the dependencies and call relationships between microservices, this set of microservices that need to be deployed (also called microservice group) is modeled as a directed acyclic graph. in, A set of nodes representing a microservice. Represents a set of directed links connecting microservices. Indicates that microservices m and s n A directed link connected. Based on e mn , s m Known as s n Parent service, s n It is m A microservice may have more than one subservice and parent service. This application will l The sub-service set 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 a container can only deploy one microservice replica, and each microservice and its multiple replicas are deployed on a container type in the same cloud data center. Represents: Microservices l Deployed in cloud data centers Using container types The number of microservices l Deployed in cloud data centers The number of copies n l The operation of each microservice instance is modeled as an M / M / 1 queuing model.

[0068] Furthermore, consider a set of user center sets A center that represents a user group in a region. Users access microservices through an API gateway as a unified access point. Requests from the user center to this group of microservices are generated according to a Poisson distribution. The request rate changes periodically, in seconds. Within each second, the gateway request rate λ k Indicates that from the user center U k The frequency of requests to the API gateway of the microservice group.

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

[0070] In an optional embodiment, a target model for each optimization target is determined based on a physical network model and a service model, including: determining a network delay between a user center and a first microservice accessed based on a physical network model to obtain first data; determining a network delay between a user center and a last microservice accessed based on a physical network model to obtain second data; determining a workload of a microservice group and a frequency of gateway requests from the user center to the microservice group based on a service model; determining a network delay between the user center and the microservice group based on the first data, the second data, the workload of the microservice group, and the frequency of gateway requests; and determining a sum function of a response time within the microservice group and the network delay as a target model for an average response delay of a user accessing the microservice group.

[0071] Optionally, in order to determine the target model of the average response delay of users accessing the microservice group (i.e., the mathematical model of the average response delay of user requests), the microservice s l The workload is formula (1):

[0072]

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

[0074]

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

[0076] Optionally, the user center U k The network delay between the microservice group and the server can be expressed as formula (3):

[0077]

[0078] Among them, k Represents the user center U k The network delay between the first microservice accessed (corresponding to the first data above, including the user center U k The network latency from the API gateway to the microservice group to the network latency from the API gateway to the first microservice requested to access), Ot k Represents the user center U kThe network delay between the last microservice accessed (corresponding to the second data above, that is, the network delay from the last microservice to the API gateway and the network delay from the API gateway to the user center U k network delay between 1 and 2).

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

[0080] ART=ut+MS (4)

[0081] Among them, the function MS is used to calculate the response time (also known as uptime) within the microservice group. In this application, two functions EST (earliest start time) and FT (end time) are defined for each microservice to calculate the validity period of the microservice group. The calculation process starts from the beginning of accessing the microservice, and MS is the end time of the last microservice accessed. See the following formulas (5) to (8):

[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 Represents microservices m With microservices l The transmission delay between them is in seconds.

[0087] In an optional embodiment, a target model for each optimization target is determined based on a physical network model and a service model, including: determining a data center and a container type corresponding to the deployment of each microservice in the microservice group based on the physical network model and the service model; determining a target model corresponding to the deployment cost of the microservice group based on the data center and the container type corresponding to the deployment of each microservice; determining a transmission cost between any two microservices in the microservice group based on the physical network model and the service model; and determining a 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 microservice group with dependencies, consider not only the deployment cost of the microservices (i.e., the cost of renting containers in each data center), but also the transmission cost of data between microservices during runtime. The sum of these two costs is considered the total cost of deploying the microservice group.

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

[0090]

[0091] in, Represents microservices l Whether deployed in data center A i Container type V in j If yes, then otherwise, That is to say, Used to characterize the data center and container type in which each microservice in a microservice group is deployed.

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

[0093]

[0094] Alternatively, the average transmission cost of processing a user request can be defined as formula (11):

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

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

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

[0098]

[0099] Among them, p ml Represents 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 an optional embodiment, a target model for each optimization target is determined based on a physical network model and a service model, including: determining the data center and container type corresponding to the deployment of each microservice in the microservice group, and determining the expected value corresponding to the remaining number of each 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 the deployment of 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] Alternatively, in computing networks, since multi-cloud environment resources are often dynamic, volatile, and uncertain, the deployment efficiency of microservices needs to be considered when studying the deployment of microservices in multi-cloud data center interconnected scenarios. Deployment efficiency represents the probability of successfully executing a deployment request (i.e., requesting a cloud data center to provide the required number of container instances) based on the resource requirements and deployment location requirements of the microservice.

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

[0105] Therefore, assume that the cloud provider provides data center A i The remaining container types V j The number of resources is a random variable R ij , obeys Poisson distribution: R ij ~π(λ ij ), that is, the random variable R ij The possible values of are 0, 1, 2, 3, etc., then the probability of each value can be expressed as shown in formula (14):

[0106]

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

[0108]

[0109] Among them, λ ij is the expected value of the Poisson distribution, which means that data center A i Remaining quantity V of container type j expected value.

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

[0111]

[0112] in, Represents microservices l Whether deployed in data center A i Container type V in j If yes, then otherwise,

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

[0114]

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

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

[0117] The second constraint is used to constrain microservices of the same type to be deployed in the same container in the same data center.

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

[0119] Optionally, Figure 4 This is a framework flow chart of an optional microservice deployment method according to an embodiment of the present application, such as Figure 4As shown in the figure, first, for the scenario of multi-cloud data center interconnection in the computing power network, a system model is constructed through the system model construction module, including a physical network model (used to characterize the cloud data centers and their internal properties and link properties between nodes in the scenario of multi-cloud data center interconnection in the distributed computing power network) and a microservice service model (used to represent the dependencies between the microservices that make up the application, as well as the process of user access to the application); then, the availability of the user to the application is taken as a constraint condition, and the average response delay 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 regarded as optimization goals. Through the mathematical model and objective function establishment module, the mathematical models of the average response delay of the request, the total cost (deployment cost and transmission cost), the deployment efficiency and the resource availability are designed respectively.

[0120] Among them, Data Center A i Container type V in j The availability per unit time can be expressed as: ij , which is the ratio of the time the resource is in normal service per unit time to the total time. The availability of resources of different container types in different data centers varies greatly, which is also one of the factors that measure the service level of cloud service providers. In this application solution, the resource availability of the application is considered as a constraint condition, that is, the resource availability of the application must meet the user's minimum standard.

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

[0122]

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

[0124]

[0125] Then, based on the constructed mathematical model, a multi-objective optimization problem is modeled. Finally, the multi-objective optimization algorithm is used as the problem-solving algorithm to design the algorithm solution process. For example, in this application, the average response delay of user requests, the total deployment cost, and the deployment efficiency are used as optimization objectives, while being subject to the constraints of the user's resource availability for the deployed application, the microservice deployment location, and the microservice load.

[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 the three-dimensional tensor To represent the microservice deployment plan, use a one-dimensional variable Indicates the number of replicas deployed for the 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 mentioned above): The resource availability of the application providing the service needs to meet the user's requirement level, refer to formula (21):

[0131] AVA S ≥b (21)

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

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

[0134]

[0135] (3) Load constraint (corresponding to the third constraint mentioned above): The workload of the microservice will not exceed its ability to process requests, refer to formula (23):

[0136]

[0137] like Figure 4 As shown, the data collection module can also be used to collect information about the transmission delay and cost of microservices, container distribution and availability, and user distribution and request status. 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 the optimal deployment strategy, and then deploy the microservices based on the optimal deployment strategy.

[0138] It should be noted that this application designs a parameter setting module to set the data involved in the solution process. For the multi-cloud data center interconnection scenario in the computing network, solving the microservice deployment strategy of this application requires setting the transmission delay 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 The transmission delay between mland cost p ml Container type V of 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 delay with the application k and Ot k Data Center A i Container type V in j Availability per unit time a ij wait.

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

[0140] Step 1: For the target model of 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 by selecting crossover mutation;

[0142] Step 3: Merge the parent population and the child population, and after performing non-dominated sorting, determine the rank of the population individuals, and determine all population individuals except the lowest-ranked individual as individuals of the next generation population;

[0143] Step 4: normalize the lowest-ranked individuals and calculate the vertical distance between the individuals and the reference point. Based on the vertical distance, select at least one individual from all the lowest-ranked individuals as the next generation population individual.

[0144] Step 5: Select crossover mutation for individuals in the next generation population and determine whether the maximum number of evolutionary iterations has been reached. If not, the number of evolutionary iterations is increased by one and the process returns to step 3 to continue iteration. If the maximum number of evolutionary iterations has been reached, the process proceeds to step 6.

[0145] Step 6: Select the target solution that meets the constraints from all the solution results obtained;

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

[0147] Optionally, based on the modeling of the previous problem, it can be concluded that the problem of solving the target model in this application is actually a multi-objective optimization problem. In a multi-cloud environment, there are many types of containers available 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 it. Based on the data set by the data parameter setting module, the NSGA-III algorithm is used to solve the optimal deployment strategy for microservices. The NSGA-III algorithm solution process design is as follows Figure 5 shown.

[0148] It should be noted that when generating the initial population, since the initial population is randomly generated and the solution space is very large, ensuring that every individual meets the user availability constraint may cause the initial population generation process to fall into an infinite loop. Therefore, a maximum number of loops is set during the initial population generation process. This may cause some individuals to fail to meet the availability constraint. Similarly, after performing crossover and mutation operations on the population, some individuals also fail to meet the availability constraint. However, this does not hinder the solution to the problem. This application adopts the idea of relaxing boundary conditions, not considering that all individuals meet the constraints. After the solution process is completed, all Pareto optimal solutions that meet the constraints are selected from the feasible solutions.

[0149] like Figure 5 As shown, the NSGA-III algorithm used in this application solves the problem as follows:

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

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

[0152] Step 3: Merge the parent and offspring populations, perform fast non-dominated sorting, determine the individual ranks of the population, and directly use the individuals with high ranks as individuals of the next generation population.

[0153] Step 4: In the last level, the remaining excellent individuals are selected to enter the next generation of new parent population by normalizing the individuals and calculating their vertical distance to the reference point.

[0154] Step 5: Select crossover mutation for the parent population generated by the new generation, and determine whether the maximum number of evolutionary iterations has been reached. If not, increase the number of evolutionary iterations by one, return to step 3, and continue iterating.

[0155] Step 6: After reaching the maximum number of evolutions, select all Pareto optimal solutions that meet the constraints from the feasible solutions obtained. The solution is completed.

[0156] According to another aspect of the present application, a microservice deployment device is also provided, wherein: Figure 6 is a schematic diagram of an optional microservice deployment device according to an embodiment of the present application, such as Figure 6 As shown, the device includes: a model building unit 601, which is used to build a physical network model and a service model of a microservice group, wherein the physical network model is used to characterize the internal properties of each data center and the link properties between nodes in a scenario where multiple data centers are interconnected; the service model is used to characterize the dependency relationship and access process between different microservices in the microservice group; a first determination unit 602, which is used to determine multiple optimization targets, wherein the multiple optimization targets include at least: the average response delay 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 determination unit 603, which is used to determine a target model for achieving each optimization target based on the physical network model and the service model; a deployment unit 604, which is used to deploy the microservices in the microservice group according to the target models of the multiple optimization targets.

[0157] Optionally, the model building unit 601 includes: a first determination subunit, used to 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 each data center; a second determination subunit, used to determine the transmission cost and transmission delay between any two data centers; a third determination subunit, used to determine the container type set of each data center, wherein the container type set of each data center includes all container types that constitute the data center; a construction subunit, used to construct a physical network model based on the first set, the second set, the transmission cost and transmission delay 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 for generating 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; a construction subunit for constructing a service model of the microservice based on the directed acyclic graph, a user center set and a replica deployment strategy, wherein the user center set includes various user groups that call the microservice, and the replica deployment strategy is used to limit the existence of a one-to-one deployment relationship between a replica of each microservice and a container, and each microservice and the replica of the microservice are deployed on a container type in the same cloud data center.

[0159] Optionally, the second determination unit 603 includes: a fourth determination subunit, used to determine the network delay between the user center and the first microservice accessed according to the physical network model to obtain first data; a fifth determination subunit, used to determine the network delay between the user center and the last microservice accessed according to the physical network model to obtain second data; a sixth determination subunit, used to determine the workload of the microservice group and the gateway request frequency from the user center to the microservice group according to the service model; a seventh determination subunit, used to determine the network delay 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; an eighth determination subunit, used to determine the sum function of the response time and the network delay within the microservice group as the target model of the average response delay of the user accessing the microservice group.

[0160] Optionally, the second determination unit 603 includes: a ninth determination subunit, for determining the data center and container type corresponding to the deployment of each microservice in the microservice group based on the physical network model and the service model; a tenth determination subunit, for determining the target model corresponding to the deployment cost of the microservice group based on the data center and container type corresponding to the deployment of each microservice; an eleventh determination subunit, for determining the transmission cost between any two microservices in the microservice group based on the physical network model and the service model; and a twelfth determination subunit, for 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.

[0161] Optionally, the second determination unit 603 includes: a thirteenth determination subunit, used to determine the data center and container type corresponding to the deployment of each microservice in the microservice group based on the physical network model and the service model, and determine the expected value corresponding to the remaining number of each container in each data center; a fourteenth determination subunit, used to determine the probability information when each microservice is deployed to each container in each data center based on the expected value; a fifteenth determination subunit, used to determine the deployment success rate of each microservice based on the data center and container type corresponding to the deployment of each microservice and the probability information; a sixteenth determination 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, the deployment unit 604 includes a deployment subunit configured to deploy microservices in the microservice group according to the target model of at least one of the following constraints and multiple optimization objectives:

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

[0164] The second constraint is used to constrain microservices of the same type to be deployed in the same container in the same data center.

[0165] The third constraint is used to constrain the actual workload of the microservice group to 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 of multiple optimization objectives, wherein the parent population represents the initial solution of the first generation; a second execution module for executing step two, performing non-dominated sorting on the generated parent population, and obtaining a child population by selecting crossover mutation; a third execution module for executing step three, merging the parent population with the child population, and determining the level of the population individuals after performing non-dominated sorting, and determining all the population individuals except the lowest-level population individual as individuals of the next generation population; a fourth execution module for executing step four, normalizing the lowest-level population individual and calculating Calculate the vertical distance between the individual of the population and the reference point, and select at least one individual of the population from all the individuals of the lowest level as the individual of the next generation population based on the vertical distance; the fifth execution module is used to execute step five: select crossover mutation for the individuals of the next generation population, and at the same time determine whether the maximum number of evolutionary iterations has been reached. If the maximum number of evolutionary iterations has not been reached, the number of evolutions is increased by one, and the process returns to step three to continue iteration; 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, and select the target solution that meets the constraint conditions from all the solution results obtained; 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 an embodiment of the present application, a computer-readable storage medium is further provided, wherein a computer program is stored in the computer-readable storage medium, wherein when the computer program is run, the device where the computer-readable storage medium is located executes the above-mentioned microservice deployment method.

[0168] According to another aspect of an embodiment of the present application, an electronic device is further 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 execute the above-mentioned microservice deployment method.

[0169] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0170] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description 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. Among them, the device embodiments described above are only exemplary. For example, the division of the units can be a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0172] The units described as separate components may or may not be physically separate, and 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 may be selected according to actual needs to achieve the purpose of the present embodiment.

[0173] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0174] If the integrated unit is implemented in the form of 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 the present application is essentially 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, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0175] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A microservice deployment method, characterized in that: include: Construct a physical network model and a service model for the microservice group. The physical network model is used to represent the internal properties of each data center and the link properties between nodes in a scenario where multiple data centers are interconnected. The service model is used to represent the dependencies and access processes between different microservices in the microservice group. Determining multiple optimization objectives, wherein the multiple optimization objectives include at least: an average response delay of a user accessing the microservice group, a deployment cost of the microservice group, a transmission cost of the microservice group, and a deployment efficiency of the microservice group; determining a target model for achieving each optimization goal based on the physical network model and the service model; The microservices in the microservice group are deployed according to the target models of the multiple optimization targets.

2. The method according to claim 1, characterized in that Build a physical network model, including: 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 a container type set for each data center, wherein the container type set for each data center includes all container types constituting the data center; The physical network model is constructed according to the first set, the second set, the transmission cost and the transmission delay between any two data centers, and the container type set of each data center.

3. The method according to claim 1, characterized in that Build a service model for the microservice group, including: Generate a directed acyclic graph based on the microservice group, wherein the directed acyclic graph is used to describe the dependency and call relationships between multiple microservices in the microservice group; A service model of the microservice is constructed 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 microservice, and the replica deployment strategy is used to limit the existence of a one-to-one deployment relationship between a replica of each microservice 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, wherein Determining a target model for each optimization target based on the physical network model and the service model includes: Determine the network delay between the user center and the first microservice accessed according to the physical network model to obtain first data; Determine, according to the physical network model, a network delay between the user center and the last microservice accessed to obtain second data; Determine the workload of the microservice group and the frequency of gateway requests from the user center to the microservice group according to the service model; Determining a network delay between the user center and the microservice group according to the first data, the second data, the workload of the microservice group, and the gateway request frequency; A sum function of the response time within the microservice group and the network delay is determined as a target model of the average response delay of the user accessing the microservice group.

5. The method according to claim 1, wherein Determining a target model for each optimization target based on the physical network model and the service model includes: Determine, based on the physical network model and the service model, a data center and a container type corresponding to the deployment of each microservice in the microservice group; Determine a target model corresponding to the deployment cost of the microservice group based on the data center and container type where each microservice is deployed; Determine, based on the physical network model and the service model, a transmission cost between any two microservices in the microservice group; According to the transmission cost between the any two microservices, a target model corresponding to the transmission cost of the microservice group when processing the user request is determined.

6. The method according to claim 1, characterized in that Determining a target model for each optimization target based on the physical network model and the service model includes: Determine, based on the physical network model and the service model, a data center and container type for deployment of each microservice in the microservice group, and an expected value corresponding to the remaining number of each container type in each data center; Determine, based on the expected value, probability information of each microservice being deployed to each container in each data center; Determine a deployment success rate for each microservice based on the data center and container type in which each microservice is deployed and the probability information; According to the deployment success rate of each microservice in the microservice group, a target model corresponding to the deployment efficiency of the microservice group is determined.

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

8. The method according to claim 1, characterized in that Deploying the microservices in the microservice group according to at least one of the following constraints and the target model of the multiple optimization targets includes: Step 1: generating a parent population that meets the constraint conditions for the target model of the multiple optimization objectives, 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 by selecting crossover mutation; Step 3: Merge the parent population and the child population, and after performing non-dominated sorting, determine the ranks of the population individuals, and determine all population individuals except the lowest-ranked population individual as individuals of the next generation population; Step 4: normalize the lowest-ranked individuals and calculate the vertical distance between the individuals and the reference point. Based on the vertical distance, select at least one individual from all the lowest-ranked individuals as an individual of the next generation population. Step 5: Select crossover mutation for individuals of the next generation population, and determine whether the maximum number of evolutionary iterations has been reached. If not, the number of evolutionary iterations is increased by one, and the process returns to Step 3 to continue iteration. 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 constraint conditions from all the solution results obtained; Step seven: deploy the microservices in the microservice group according to the target solution.

9. A microservice deployment device, characterized in that: include: A model building unit is configured to build a physical network model and a service model of a microservice group, wherein the physical network model is used to characterize the internal properties of each data center and the link properties between nodes in a scenario where multiple data centers are interconnected; and the service model is used to characterize the dependencies and access processes between different microservices in the microservice group. A first determining unit is configured to determine a plurality of optimization objectives, wherein the plurality of optimization objectives include at least: an average response delay of a user accessing the microservice group, a deployment cost of the microservice group, a transmission cost of the microservice group, and a deployment efficiency of the microservice group; a second determining unit, configured to determine a target model for achieving each optimization target based on the physical network model and the service model; A deployment unit is configured to deploy the microservices in the microservice group according to the target models of the multiple optimization targets.

10. 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 where the computer-readable storage medium is located executes the microservice deployment method according to any one of claims 1 to 8.

11. An electronic device, characterized in that: The microservice deployment method comprises one or more processors and a memory, wherein the memory is 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 execute the microservice deployment method according to any one of claims 1 to 8.

Images