Micro-service scaling and request route updating method, system and equipment based on data awareness

Abstract

The invention discloses a micro-service scaling and request routing updating method, system and device based on data awareness, and the method comprises the steps: determining the total number of micro-service instances required by each time slot and the increment of the corresponding change in real time according to the change of the average request arrival rate based on a dynamic instance determination algorithm of the maximum marginal gain; according to the increment of micro-service instance deployment between time slots and the service capability of a service center, the specific deployment of each time slot is dynamically and telescopically adjusted in combination with the topology dependence of the existing deployment based on a redundancy recovery-based segmented active telescopic algorithm, and the life cycle management of the micro-service application is completed; and according to a marginal benefit calculation principle of instance perception calculation, removing occupation of instance resources by the shared call chain, and based on a request stream corresponding to a micro-service application, determining a micro-service request routing forwarding strategy according to a resource proportion and an instance perception principle. According to the method, the dynamic change micro-service request between time slots can be handled, the request time delay can be further reduced, the resource overhead is saved, and the request success rate can be guaranteed.

Description

Technical Field

[0001] The present invention relates to the field of cloud data routing, and in particular to a method, system and device for updating microservice scaling and request routing based on data perception. Background Art

[0002] In recent years, with the widespread application of microservice architecture, dynamic deployment technology has gradually become an important means to solve performance optimization problems in complex cloud computing environments. Microservice architecture breaks down a single application into multiple independent services, which has the advantages of loose coupling, easy scalability and easy maintenance. Especially in cloud computing applications that deal with high concurrency and real-time processing requirements, the independent deployability of microservices makes it particularly outstanding in performance tuning and system elasticity.

[0003] In cloud data centers, real-time applications usually receive a large number of user requests, which are distributed on different service nodes and need to be processed through microservice call chains. Due to the complex dependencies and frequent communication interactions between microservices, how to achieve efficient service deployment in a dynamic environment has become a key issue. The deployment of microservices not only affects the response speed of the system, but is also directly related to the overall service latency, load balancing, and resource utilization.

[0004] Existing microservice deployment solutions usually separate service deployment and request routing. Although they optimize their respective tasks locally, they ignore the complex dependencies and data interactions between services, making it difficult to achieve global performance optimization. This approach often fails to quickly adjust service deployment strategies when faced with dynamically changing request volumes, resulting in reduced system performance and increased latency.

[0005] Therefore, how to design a dynamic deployment method that can take into account the global optimization of service deployment and request routing in combination with the dynamic change characteristics of services has become a core challenge to improve the quality of cloud computing services. This requires not only accurate modeling and analysis of microservice call graphs, but also the ability to dynamically adjust deployment strategies to respond to service requests under different load scenarios, thereby achieving global optimization of system performance. Summary of the invention

[0006] The purpose of the present invention is to overcome the problem in the prior art that the service deployment strategy cannot be quickly adjusted, and to provide a method, system and device for updating microservice scaling and request routing based on data perception when the service deployment strategy cannot be quickly adjusted.

[0007] To achieve the above objectives, the technical solution of the present invention is:

[0008] In a first aspect, the present invention provides a data-aware microservice scaling and request routing update method, comprising the following steps:

[0009] S1 determines the network configuration of the cloud data service center and the set of microservice-based user requests for accessing the cloud data service center in each time slot; obtains the number and type of instances required to be deployed for each time slot service instance through a dynamic instance calculation model based on maximum marginal gain; uses polling placement to quickly determine the total number of microservice instances required during the time slot change process and the corresponding change increment, and realizes user needs with the minimum ideal deployment cost;

[0010] S2 completes the orchestration of multi-instance microservices under the service grid architecture in a fine-grained manner, based on the total number of microservice instances required during the current time slot change and the corresponding change increment, combined with a segmented active scaling algorithm based on redundancy recovery, releases redundant instance resources, and actively retains some redundancy to prevent sudden traffic loads;

[0011] S3 eliminates the occupation of instance resources by the shared call chain according to the calculation results of the multi-instance microservice orchestration and the dynamic instance calculation model based on the maximum marginal gain, determines the routing probability of the corresponding request flows of the remaining microservice-based applications according to the principle of proportional allocation of microservice resources, routes the requests to the corresponding microservice instances and server nodes, and finally determines the decision variables.

[0012] S11 Determine the network configuration and service support of the cloud data service center, including:

[0013] The network configuration of the cloud data service center includes a large number of servers that can provide computing services. Deploying a service instance on a node consumes a certain amount of computing resources of the node, that is, the number of cores in each server. At the same time, there is also communication delay and transmission bandwidth between servers.

[0014] G=(N, E) represents the cloud data service center, where N={n1, n2, ..., n |N|} is a collection of physical server nodes, E represents the connection between two physical servers n i , n j A collection of links;

[0015] Indicates physical server n i ∈N, the maximum computing resource capacity, the number of cores of the server represents the computing resources. Each core can only instantiate one container, and each container can only hold one microservice instance;

[0016] Each physical link Corresponding to a pair of connected server nodes {(n i , n j )|n i , n j ∈N}; Indicates the connected physical server n i , n j The maximum bandwidth capacity between the two, which is shared by all service requests. Indicates physical server n i , n j Inherent communication delay between

[0017] Represents a collection of microservice types. For each microservice Due to the heterogeneity of microservices, the core of the same server has different processing capabilities for task requests of different types of microservices. The unit processing capacity is expressed as

[0018] The step of determining a microservice-based user request set for accessing the cloud data service center in each time slot includes:

[0019] During the processing of the cloud data service center, user requests from different time slots are dynamically received. The service types and request arrival rates in different time slots change in real time. In the formula, MA(t)={ma1(t),ma2(t),...,ma |MA(t)| (t)} represents the set of all microservice-based applications;

[0020] use Represents a request flow consisting of a specific user request, where represents the time when the request flow of the microservice-based application arrives at the cloud data service center, λ ma(t) represents the real-time average request arrival rate, Represents the topology of a tree-like microservice graph, Indicates the predefined maximum service / request response delay threshold. is a collection of call paths;

[0021] Includes a collection of microservice types A collection of directed dependencies between microservices According to the microservice topology Get all specific microservice call path collections in: represents the arrival rate of the i-th call path split according to the ratio, represents the i-th call path, Indicates the kth accessed microservice in the i-th call path; the request needs to traverse the specified microservice call sequence to be successfully processed; all execution paths are obtained through DFS, and combined with Properties and microservice dependencies Determine the equivalent request arrival rate corresponding to each microservice call chain Based on the DAG graph structure of probability forwarding, the sum of the average request arrival rates of the child microservice nodes is equal to the average input arrival rate of the parent microservice. The attribute of each microservice call link in the data parallel DAG graph structure contains the forwarding probability, and the sum of the probabilities is 1; based on the data parallel DAG graph structure, the equivalent average arrival rate of each microservice call chain is equal to the average request arrival rate of the request flow

[0022] S12 obtains the number and type of instances required to be deployed for each time slot service instance through a dynamic instance calculation model based on maximum marginal gain, including:

[0023] Defining variables Indicates that at time slot t, microservice The number of cores occupied on the physical server n∈N, that is, the number of microservice instances; in addition, each deployment plan is executed at the end of the previous time slot t-1, so these instances are available to complete the corresponding function and complete user requests during time slot t; considering that the total number of deployed microservice instances cannot exceed the total number of cores of the physical server, the computing resource constraint is obtained:

[0024]

[0025] When determining the number of instances required for each microservice, the polling placement strategy is used to calculate the number of microservice instances with the highest tolerance combined with the tightened latency constraints of each call chain. Since the needs of each user are different and there are multiple call paths in the microservice call graph, Distributed physical servers will collaboratively provide corresponding functions; specifically, for each real-time request flow corresponding to a microservice-based application, there are multi-instance and multi-queue request routing.

[0026] S13 calculates the tightened tolerance delay based on the dynamic request traffic-instance awareness algorithm, and uses the polling placement strategy to calculate the maximum number of microservice instances to be deployed under the current number of polling queues;

[0027] Calculate the tighter delay tolerance In each time slot t, historical information related to the microservice system is counted to calculate the statistical average propagation, data transmission and query delays. And call the depth-first search algorithm DFS, all real-time changing microservice-based applications ma(t)∈MA(t), calculate all specific call paths for each application And sort all call chains in descending order according to their equivalent average arrival rate; then calculate the tightened tolerance delay for each call chain The average communication delay, communication bandwidth, and average arrival rate of request flows between service network servers are used to replace the average data transmission delay of specific request flows. The arrival rate of request flows and the query cost of interacting with the database are used to obtain the database interaction delay. The calculation is based on Subtract the average propagation delay, data transmission delay, and database interaction delay to obtain the tighter tolerance delay

[0028] For each required microservice, the microservice instances are distributed and placed in On each server node, following the dependency relationship of the call chain, a request queues and calculate the probability of each request service path Then, add an instance for each microservice and update the probability synchronously and calculate the expected delay gain To ensure fairness, calculate the average instance gain of each microservice and select the microservice with the largest marginal gain value. According to the properties of the microservice application, update the i-th call chain cp of the microservice-based application ma(t) i The number of microservices required by After each round of instance number update, recalculate the response delay and delay constraints Compare until user needs are met; finally, perform statistical classification to obtain the set of instances required for each microservice required by dynamic requests within time slot t Service instance requirements on different call paths than the current time

[0029] Dynamic request traffic-instance-aware algorithm:

[0030] S131 calculates the average communication delay based on the network topology and average communication bandwidth Initialize the average access latency of stateful microservices based on historical log records

[0031] S132 Specific service request ma(t) in the cyclic request set MA(t) is based on the topological characteristics Calculate the call path set based on the characteristics of the service graph through the depth-first traversal method And sort in descending order according to the equivalent average arrival rate of the call chain to get a new set

[0032] S133 loop microservice request Specific microservice call chain Recalculate the tightened tolerance delay, consider the database interaction delay, and calculate the microservice call chain First response delay under ideal network conditions

[0033] S134 If Loop specific microservice call chain Specific microservices in Based on the proportional probability routing, the application places the number of microservice instances required to be deployed in the current round according to the polling placement strategy. At most instance queues and calculate the probability of each request queue When the total number of instances of the corresponding microservice increases by one, the instance queue and According to the queuing theory formula, the expected delay gain is calculated:

[0034]

[0035] Indicates the latency of calculating the number of instances allocated to the queue based on the proportional allocation result after the polling placement instances are increased. Indicates the delay before the current round of polling placement. represents the expected delay gain;

[0036] S135 finds the placement result with the largest latency gain and corresponds it to the number of microservice instances to be deployed To increase;

[0037] S136 Topology based on service graph Increase the number of instances to ensure a certain level of redundancy

[0038] S137 pair All the same microservices in Number of instances updated simultaneously

[0039] S138 Recalculate response delay

[0040] S139 classifies and counts each microservice based on the attribute characteristics of each microservice-based application r(t) Calculate the sum of the number of instances required for each microservice at the current time t

[0041] In S2, the active microservice automatic scaling in the multi-instance microservice orchestration under the service grid architecture includes: segmented active automatic scaling accompanied by redundancy recovery:

[0042] S21 initializes an existing set of microservice-based applications And perform life cycle management: traverse the application collection Each specific application Microservice-based applications that exceed the time slot constraint no longer provide services to users: If Then end the service of these requests and Remove But keep the corresponding service instance and update the corresponding network status variables; is the response delay of the critical call path, For microservices-based applications The maximum request latency threshold defined by It represents the time when the request flow of the microservice-based application arrives at the data center, represented by t; after the traversal is completed, it enters S22;

[0043] S22 Initialization instance retention redundancy factor Mean() calculates the average, [] + Indicates that negative values ​​are taken as 0, and max(,) means taking the maximum value of the two;

[0044] S23 extracts the microservice-based application set MA(t) and There are service graphs with the same topology in , and we get an overlapping set of orchestration attributes for microservice-based applications: in, A collection of microservice-based applications that existed in the previous time slot is the current microservice-based application set MA(t) and the previous time slot A microservices-based application with a service graph of the same topology, The deployment decision of whether the microservice m of the application is deployed on node n; Backing up a collection of microservices All microservices in the above are sorted in ascending order, and then enter S24;

[0045] S24 is not an empty set, go to S241; when It is an empty set, and enters S3;

[0046] S241 is the number of microservice instances required for time slot t Reclaim all instance resources of microservice m and enter S245;

[0047] S242 in The sum of the number of resources instantiated in the previous time slot t-1, and the corresponding calculation of the number of instances that actually need to be reduced To cope with potential burst request loads:

[0048] S2421 Initialize the instantiated node list: the instantiated node list collection If it is an empty set, traverse the application set Each specific application if Then The server node n with the value of 1 joins the set After the traversal is completed, when the collection is not an empty set, go to S2422; when the set If it is an empty set, go to S2423;

[0049] S2422 It is not an empty set, and the microservices have a common topology structure middle;

[0050] S24221 Traversing a collection All server nodes n in:

[0051] if or So

[0052] if and So

[0053] After the traversal is completed, when Enter S24222; when Enter S2423;

[0054] S24222 According to the number of instances of microservice m Sort in descending order and traverse the collection All server nodes n in;

[0055] if or So μ m for;

[0056] After the traversal is completed, when Re-enter S24222; when Enter S2423;

[0057] S2423 It is an empty set, and the microservices do not have a common topology structure. In the example, according to the number of instances of microservice m on each server node For all activated server nodes N in the current time slot active Sort in ascending order Get Collection Traversal All server nodes in n:

[0058] if or So

[0059] if or So

[0060] After the traversal is completed, enter S2424;

[0061] S2424 Maintain The corresponding request flow transition probability of applications with the same topology and path variables constant, is the microservice m deployed on n nodes under the ma(t) application p Forward the next service request to n deployed j Node microservices s Probability; enter S245:

[0062] S243 If Then for all server nodes n, keep the existing deployment plan of microservice m

[0063] S244 If Then calculate the average resource utilization of the currently activated node Calculating average resource utilization According to MA(t) and The topological dependency relationship of microservice m is used to find the predecessor microservice set of microservice m. and subsequent microservices collection Calculate all the nodes that exist on the currently activated node and The total number of instances of the microservice According to the utilization rate and topology-dependent instance ratio The weighted sum of , sort the server node set in descending order Weighting coefficient: α1+α2=1, calculation instance increment

[0064] S2441 Enter S24411;

[0065] S24411 loops through the set N of active states in the current time slot active The nodes n where all microservices are deployed,

[0066] if or Just allocate instance resources directly.

[0067] is the lower limit of the fairness index, indicating the maximum load capacity (between 0 and 1, 0.9 means the maximum capacity is 90%), C n represents the maximum number of nodes n that can be deployed when not deployed, C(t) n represents the maximum number of nodes n that can be deployed at time slot t;

[0068] if Then allocate existing computing resources,

[0069]

[0070] if Indicates that the redundancy limit has been exceeded and no further instances will be added to the node;

[0071] if This means that all instances have been placed, ending the current loop and entering S24412;

[0072] S24412 Indicates that the existing enabled servers are insufficient, except N active A server node n′ is added to the remaining available nodes to meet the optimal result in terms of comprehensive evaluation of bandwidth and communication delay, and then instance resources are allocated to it. Add n′ to the list of activated server nodes N active ;

[0073] S24413 Re-enter S24411; otherwise enter S245;

[0074] S245 has completed all deployments at this time. Remove microservice m; when If it is an empty set, go to S3; otherwise, re-enter S241;

[0075] The routing strategy determined in S3 based on the transfer probability and routing path of the request flow includes:

[0076] Since each microservice can be instantiated on a different server, the request flow requires The microservice m contained in can be processed on multiple nodes; define variables Indicates the microservice called by application ma(t) at time slot t Whether the corresponding functional requirements are processed / responded on server node n; secondly, based on the dependencies between microservices When the request from the predecessor microservice is processed, the successor microservice can start working. In addition, the number of cores of the same type of microservice containerized on different server nodes is usually different. Considering the limited bandwidth resources and communication overhead between servers, user requests need a suitable request routing strategy to determine the forwarding path between the predecessor node and the successor node.

[0077] Defining variables Represents the request flow of the microservice-based application ma(t) from the deployment of the predecessor microservice m p Server n i Routing to the deployment successor microservice m s Server n j The probability of is the call topology between microservices; from a micro perspective, each user selects a request routing path and traverses the specified microservices in order to meet the requirements; from a macro perspective, the request flow implements multi-queue request routing and diversion in a probabilistic way to avoid network congestion and achieve load balancing; for variables and There are the following expressions:

[0078]

[0079] in is an indicator function. In a microservice-based application ma(t), when microservice m p and m s When there is a dependency between them, the value of this function is 1; otherwise, it is 0;

[0080] Routing requests to the corresponding microservice instances and server nodes, and finally determining the decision variables: Based on the routing strategy of the application resource ratio of the microservice, the corresponding request flow of the microservice application is routed to the corresponding microservice instance and server node according to the principle of resource ratio, and finally determining the ternary decision variables and

[0081] In a second aspect, the present invention provides a microservice scaling and request routing update system based on data perception, the system is used to execute the aforementioned microservice scaling and request routing update method based on data perception, specifically comprising:

[0082] The dynamic instance quantity determination module is used to determine the network configuration of the cloud data service center and the set of microservice-based user requests for accessing the cloud data service center in each time slot; the number and type of instances required to be deployed for each time slot service instance are obtained through a dynamic instance calculation model based on maximum marginal gain; polling placement is used to quickly determine the total number of microservice instances required during the time slot change process and the corresponding change increment, and to achieve user needs with the minimum ideal deployment cost;

[0083] The instance dynamic scaling deployment module is used to complete the multi-instance microservice orchestration under the service grid architecture in a fine-grained manner according to the total number of microservice instances required during the current time slot change and the corresponding change increment, combined with the segmented active scaling algorithm based on redundancy recovery, to release redundant instance resources, actively retain some redundancy, and prevent sudden traffic loads;

[0084] The proportional routing dynamic partitioning module is used to eliminate the occupation of instance resources by the shared call chain according to the calculation results of the multi-instance microservice orchestration and the dynamic instance calculation model based on the maximum marginal gain, determine the routing probability of the corresponding request flows of the remaining microservice-based applications according to the principle of proportional allocation of microservice resources, route the requests to the corresponding microservice instances and server nodes, and finally determine the decision variables.

[0085] In a third aspect, the present invention provides a microservice scaling and request routing update device based on data perception, characterized in that: it includes a memory and a processor, the memory is used to store computer program code and transmit the computer program code to the processor;

[0086] The processor is used to execute the aforementioned data-aware based microservice scaling and request routing update method according to the instructions in the computer program code.

[0087] In a fourth aspect, the present invention provides a computer program product, including a computer program, characterized in that when the computer program is executed by a processor, the steps of the aforementioned data-aware based microservice scaling and request routing update method are implemented.

[0088] Compared with the prior art, the present invention has the following beneficial effects:

[0089] 1. In a data-aware microservice scaling and request routing update method of the present invention, the network configuration and service support of the cloud data service center and the user request of the microservice-based application that sends the request to the cloud data service center are first determined. Then, according to the cloud computing center data network and the set of pending user requests, a dynamic instance calculation model based on maximum marginal gain is used to calculate the tightened tolerance delay with the help of average propagation, data transmission and query delays. The number and type of instances required to be deployed for each time slot service instance are calculated using a polling placement strategy. Then, according to a segmented active scaling algorithm based on redundancy recovery, multi-instance microservice orchestration under a service grid architecture is completed. Finally, a routing strategy is determined based on a method for dividing the application resources of microservices. Through the above steps, while ensuring the efficiency and success rate of network data processing and request response, the overall resource consumption of the system is reduced, and resource utilization and network fairness are improved.

[0090] 2. The present invention provides a deployment scheme for dynamic scaling at any time slot in a data-aware microservice scaling and request routing update method. First, the required number of instances is calculated based on the marginal benefit of the user request arrival situation in each time slot. Then, according to the changes in the deployment situation between time slots, the instance retention redundancy factor is calculated, the instance is scaled, the resource overhead is reduced, and the service capacity of the entire cloud data service center is adjusted in time. Finally, the routing of the request is arranged to reduce network congestion.

[0091] 3. The present invention provides a data-aware microservice scaling and request routing update system for implementing the steps of the data-aware microservice scaling and request routing update method provided in any of the above technical solutions. Therefore, the system also includes all the beneficial effects of the data-aware microservice scaling and request routing update method provided in any of the above technical solutions, which will not be repeated here.

[0092] 4. A data-aware microservice scaling and request routing update device of the present invention includes a processor and a memory, the memory is used to store computer program code and transmit the computer program code to the processor, and the processor is used to execute the data-aware microservice scaling and request routing update method provided in any of the above technical solutions according to the instructions in the computer program code. Therefore, the device also includes all the beneficial effects of the data-aware microservice scaling and request routing update method provided in any of the above technical solutions, which will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0093] Figure 1 It is a flow chart of the method of the present invention.

[0094] Figure 2 It is a system structure diagram of the present invention.

[0095] Figure 3 It is a diagram of the equipment of the present invention.

[0096] Figure 4 It is a schematic diagram of the network structure of the cloud data service center of Example 1 of the present invention.

[0097] Figure 5 It is a structural diagram of multi-instance microservice orchestration under the Chinese service grid architecture in Example 1 of the present invention.

[0098] Figure 6 It is a curve showing the average response delay between the embodiment of the present invention and the comparative example as the function of the request flow.

[0099] Figure 7 It is the memory usage between the embodiment of the present invention and the comparative example as the algorithm changes. DETAILED DESCRIPTION

[0100] The present invention is further described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0101] The optimization performance of this patent algorithm under different scale dynamics is tested by building a server cluster platform through K8S, and two commonly used algorithms in the industry are used for comparison. The control variable method is used to compare with the implementation scheme of this patent:

[0102] Comparative Example 1

[0103] It mainly uses the FFD algorithm based on the firstfit idea and the greedy idea to consider centralized deployment and reduce the latency consumption of services on a single node, but ignores the congestion of the link and the balance of deployment.

[0104] Comparative Example 2

[0105] It mainly uses the RRA,algorithm with iterative ideas and uses random deployment exploration to,perform multiple rounds of algorithm updates to obtain better results,,but all of them ignore the overhead and occupancy in the,server and microservice start and stop process during the time slot change,process.

[0106] Embodiment 1:

[0107] See also Figure 1 , 4 5. A data-aware microservice scaling and request routing update method comprises the following steps:

[0108] S1 determines the network configuration of the cloud data service center and the set of microservice-based user requests for accessing the cloud data service center in each time slot; obtains the number and type of instances required to be deployed for each time slot service instance through a dynamic instance calculation model based on maximum marginal gain; uses polling placement to quickly determine the total number of microservice instances required during the time slot change process and the corresponding change increment, and realizes user needs with the minimum ideal deployment cost;

[0109] Ideal deployment cost: The minimum total number of deployment instances required to meet the constraints, reducing the storage and computing resources for server container startup;

[0110] S11 Determine the network configuration and service support of the cloud data service center, including:

[0111] The network configuration of the cloud data service center includes a large number of servers that can provide computing services. Deploying a service instance on a node consumes a certain amount of computing resources of the node, that is, the number of cores in each server. At the same time, there is also communication delay and transmission bandwidth between servers.

[0112] G=(N,E) represents the cloud data service center, where N={n1,n2,...,n |N|} is a collection of physical server nodes, E represents the connection between two physical servers n i ,n j A collection of links;

[0113] Indicates physical server n i ∈N, the maximum computing resource capacity, the number of cores of the server represents the computing resources. Each core can only instantiate one container, and each container can only hold one microservice instance;

[0114] Each physical link Corresponding to a pair of connected server nodes {(n i , n j )|n i , n j ∈N}; Indicates the connected physical server n i , n j The maximum bandwidth capacity between the two, which is shared by all service requests. Indicates physical server n i , n j Inherent communication delay between

[0115] Represents a collection of microservice types. For each microservice Due to the heterogeneity of microservices, the core of the same server has different processing capabilities for task requests of different types of microservices. The unit processing capacity is expressed as

[0116] The step of determining a microservice-based user request set for accessing the cloud data service center in each time slot includes:

[0117] During the processing of the cloud data service center, user requests from different time slots are dynamically received. The service types and request arrival rates in different time slots change in real time. In the formula, MA(t)={ma1(t),ma2(t),...,ma |MA(t)| (t)} represents the set of all microservice-based applications;

[0118] use Represents a request flow consisting of a specific user request, where represents the time when the request flow of the microservice-based application arrives at the cloud data service center, λ ma(t) represents the real-time average request arrival rate, Represents the topology of a tree-like microservice graph, Indicates the predefined maximum service / request response delay threshold. is a collection of call paths;

[0119] Includes a collection of microservice types A collection of directed dependencies between microservices According to the microservice topology Get all specific microservice call path collections in: represents the arrival rate of the i-th call path split according to the ratio, represents the i-th call path, Indicates the kth accessed microservice in the i-th call path; the request needs to traverse the specified microservice call sequence to be successfully processed; whether it is the probabilistic forwarding call or the data parallel call DAG graph structure, all execution paths can be obtained through DFS, and combined with Properties and microservice dependencies Determine the equivalent request arrival rate corresponding to each microservice call chain Based on the DAG graph structure of probability forwarding, the sum of the average request arrival rates of the child microservice nodes is equal to the average input arrival rate of the parent microservice. The attribute of each microservice call link in the data parallel DAG graph structure contains the forwarding probability, and the sum of the probabilities is 1; based on the data parallel DAG graph structure, the equivalent average arrival rate of each microservice call chain is equal to the average request arrival rate of the request flow

[0120] S12 obtains the number and type of instances required to be deployed for each time slot service instance through a dynamic instance calculation model based on maximum marginal gain, including:

[0121] Defining variables Indicates that at time slot t, microservice The number of cores occupied on the physical server n∈N, that is, the number of microservice instances; in addition, each deployment plan is executed at the end of the previous time slot t-1, so these instances are available to complete the corresponding function and complete user requests during time slot t; considering that the total number of deployed microservice instances cannot exceed the total number of cores of the physical server, the computing resource constraint is obtained:

[0122]

[0123] When determining the number of instances required for each microservice, the polling placement strategy is used to calculate the number of microservice instances with the highest tolerance combined with the tightened latency constraints of each call chain. Since the needs of each user are different and there are multiple call paths in the microservice call graph, Distributed physical servers will collaboratively provide corresponding functions; specifically, for each real-time request flow corresponding to a microservice-based application, there are multi-instance and multi-queue request routing.

[0124] S13 calculates the tightened tolerance delay based on the dynamic request traffic-instance awareness algorithm, and uses the polling placement strategy to calculate the maximum number of microservice instances to be deployed under the current number of polling queues;

[0125] Calculate the tighter delay tolerance In each time slot t, historical information related to the microservice system is counted to calculate the statistical average propagation, data transmission and query delays. And call the depth-first search algorithm DFS, all real-time changing microservice-based applications ma(t)∈MA(t), calculate all specific call paths for each application And sort all call chains in descending order according to their equivalent average arrival rate; then calculate the tightened tolerance delay for each call chain The average communication delay, communication bandwidth, and average arrival rate of request flows between service network servers are used to replace the average data transmission delay of specific request flows. The arrival rate of request flows and the query cost of interacting with the database are used to obtain the database interaction delay. The calculation is based on Subtract the average propagation delay, data transmission delay, and database interaction delay to obtain the tighter tolerance delay

[0126] For each required microservice, the microservice instances are distributed and placed in On each server node, following the dependency relationship of the call chain, a request queues and calculate the probability of each request service path It is an improvement based on the idea of ​​queuing theory, using multiple queues (because multiple queues will reduce the delay processing rate) to improve the tolerance of the algorithm;

[0127] Then, add an instance for each microservice and update the probability synchronously and calculate the expected delay gain To ensure fairness, calculate the average instance gain of each microservice and select the microservice with the largest marginal gain value. According to the properties of the microservice application, update the i-th call chain cp of the microservice-based application ma(t) i The number of microservices required by After each round of instance number update, recalculate the response delay and delay constraints Compare until user needs are met; finally, perform statistical classification to obtain the set of instances required for each microservice required by dynamic requests within time slot t Service instance requirements on different call paths than the current time

[0128] Dynamic request traffic-instance-aware algorithm:

[0129] S131 calculates the average communication delay based on the network topology and average communication bandwidth Initialize the average access latency of stateful microservices based on historical log records

[0130] S132 Specific service request ma(t) in the cyclic request set MA(t) is based on the topological characteristics Calculate the call path set based on the characteristics of the service graph through the depth-first traversal method And sort in descending order according to the equivalent average arrival rate of the call chain to get a new set

[0131] S133 loop microservice request Specific microservice call chain Recalculate the tightened tolerance delay, consider the database interaction delay, and calculate the microservice call chain First response delay under ideal network conditions

[0132] S134 If Loop specific microservice call chain Specific microservices in Based on the proportional probability routing, the application places the number of microservice instances required to be deployed in the current round according to the polling placement strategy. At most instance queues and calculate the probability of each request queue When the total number of instances of the corresponding microservice increases by one, the instance queue and According to the queuing theory formula, the expected delay gain is calculated:

[0133]

[0134] Indicates the latency of calculating the number of instances allocated to the queue based on the proportional allocation result after the polling placement instances are increased. Indicates the delay before the current round of polling placement. represents the expected delay gain;

[0135] S135 finds the placement result with the largest latency gain and corresponds it to the number of microservice instances to be deployed To increase;

[0136] S136 Topology based on service graph Increase the number of instances to ensure a certain level of redundancy

[0137] S137 pair All the same microservices in Number of instances updated simultaneously

[0138] S138 Recalculate response delay

[0139] S139 classifies and counts each microservice based on the attribute characteristics of each microservice-based application r(t) Calculate the sum of the number of instances required for each microservice at the current time t

[0140] S2 completes the orchestration of multi-instance microservices under the service grid architecture in a fine-grained manner, based on the total number of microservice instances required during the current time slot change and the corresponding change increment, combined with a segmented active scaling algorithm based on redundancy recovery, releases redundant instance resources, and actively retains some redundancy to prevent sudden traffic loads;

[0141] The fine-grained approach means breaking down services into modular microservices and deploying and scaling microservices in the form of instances.

[0142] The segmented active scaling algorithm based on redundancy recovery completes the multi-instance microservice orchestration under the service grid architecture, including:

[0143] Through the segmented active scaling algorithm based on redundancy recovery, the multi-instance microservice orchestration under the service grid architecture is completed online and efficiently in a fine-grained manner. Compare the orchestration schemes after the service period changes. When the required microservice instances need to be reduced, the redundant instance resources are released according to the scaling strategy, and some redundancy is actively retained to prevent sudden traffic loads;

[0144] When the number of microservice instances that need to be deployed increases, the location of microservice instances of the same type, the amount of data communication that depends on the microservice nodes, and the communication latency are considered in three dimensions. Appropriate server nodes are selected to deploy microservice instances, and the forwarding probability at the instance level is determined in combination with the resource proportion-aware routing principle. Ultimately, active microservice automatic scaling is achieved, reducing latency and dynamic deployment costs.

[0145] In S2, the active microservice automatic scaling in the multi-instance microservice orchestration under the service grid architecture includes: segmented active automatic scaling accompanied by redundancy recovery:

[0146] S21 initializes an existing set of microservice-based applications And perform life cycle management: traverse the application collection Each specific application Microservice-based applications that exceed the time slot constraint no longer provide services to users: If Then end the service of these requests and Remove But keep the corresponding service instance and update the corresponding network status variables; is the response delay of the critical call path, For microservices-based applications The maximum request latency threshold defined by It represents the time when the request flow of the microservice-based application arrives at the data center, represented by t; after the traversal is completed, it enters S22;

[0147] S22 Initialization instance retention redundancy factor Mean() calculates the average, [] + Indicates that negative values ​​are taken as 0, and max(,) means taking the maximum value of the two;

[0148] S23 extracts the microservice-based application set MA(t) and There are service graphs with the same topology in , and we get an overlapping set of orchestration attributes for microservice-based applications: in, A collection of microservice-based applications that existed in the previous time slot is the current microservice-based application set MA(t) and the previous time slot A microservices-based application with a service graph of the same topology, The deployment decision of whether the microservice m of the application is deployed on node n; Backing up a collection of microservices All microservices in the array are sorted in ascending order, and the process goes to S24;

[0149] S24 is not an empty set, go to S241; when It is an empty set, and enters S3;

[0150] S241 is the number of microservice instances required for time slot t Reclaim all instance resources of microservice m and enter S245;

[0151] S242 in The number of resources instantiated in the previous time slot t-1 and the number of microservice instances that actually need to be retained are calculated based on the instance redundancy factor. Calculate the number of instances that need to be reduced accordingly To cope with potential burst request loads:

[0152] If microservices m are in a common topology or overlapping microservice-based applications , the corresponding service instance on the server node occupied by the above application will not be released temporarily, and the same type of microservice instances on other server nodes will be reduced first; if there are still remaining microservice instances that have not been reduced, the nodes containing the microservice m instances are sorted in descending order, according to the principle of polling, the judgment principle is The number of instances decreases by 1;

[0153] If the microservice does not exist in the public topology, sort all nodes containing the number of microservice instances in descending order, starting with the smallest node and clearing the number of instances until only the remaining number of instances is indivual;

[0154] S2421 Initialize the instantiated node list: the instantiated node list collection If it is an empty set, traverse the application set Each specific application if Then The server node n with the value of 1 joins the set After the traversal is completed, when the collection is not an empty set, go to S2422; when the set If it is an empty set, go to S2423;

[0155] S2422 It is not an empty set, and the microservices have a common topology structure middle;

[0156] S24221 Traversing a collection All server nodes n in:

[0157] if or So

[0158] if and So

[0159] After the traversal is completed, when Enter S24222; when Enter S2423;

[0160] S24222 According to the number of instances of microservice m Sort in descending order and traverse the collection All server nodes n in;

[0161] if or So μm;

[0162] After the traversal is completed, when Re-enter S24222; when Enter S2423;

[0163] S2423 It is an empty set, and the microservices do not have a common topology structure. In the example, according to the number of instances of microservice m on each server node For all activated server nodes N in the current time slot active Sort in ascending order Get Collection Traversal All server nodes in n:

[0164] if or So

[0165] if or So

[0166] After the traversal is completed, enter S2424;

[0167] S2424 Maintain The corresponding request flow transition probability of applications with the same topology and path variables constant, is the microservice m deployed on n nodes under the ma(t) application p Forward the next service request to n deployed j Node microservices s Probability; enter S245:

[0168] S243 If Then for all server nodes n, keep the existing deployment plan of microservice m

[0169] S244 If Then calculate the average resource utilization of the currently activated node Calculating average resource utilization According to MA(t) and The topological dependency relationship of microservice m is used to find the predecessor microservice set of microservice m. and subsequent microservices collection Calculate all the nodes that exist on the currently activated node and The total number of instances of the microservice According to the utilization rate and topology-dependent instance ratio The weighted sum of , sort the server node set in descending order Weighting coefficient: α1+α2=1, calculation instance increment

[0170] S2441 Enter S24411;

[0171] S24411 loops through the set N of active states in the current time slot active The nodes n where all microservices are deployed,

[0172] if or Just allocate instance resources directly.

[0173] is the lower limit of the fairness index, indicating the maximum load capacity (between 0 and 1, 0.9 means the maximum capacity is 90%), C n represents the maximum number of nodes n that can be deployed when not deployed, C(t) n represents the maximum number of nodes n that can be deployed at time slot t;

[0174] if Then allocate existing computing resources,

[0175]

[0176] if Indicates that the redundancy limit has been exceeded and no further instances will be added to the node;

[0177] if This means that all instances have been placed, ending the current loop and entering S24412;

[0178] S24412 Indicates that the existing activated servers are insufficient, and new activated servers need to be added to meet the computing resource requirements, except N active A server node is added from the remaining available nodes The node that meets the best comprehensive evaluation results in terms of bandwidth and communication delay is then allocated instance resources. Add n′ to the list of activated server nodes N active ;

[0179] Refers to finding the standby server (that is, except N active The remaining available nodes in α T and α B Under two equalization coefficients, calculate The node with the smallest result is taken as n';

[0180] S24413 Re-enter S24411; otherwise enter S245;

[0181] S245 has completed all deployments at this time. Remove microservice m; when If it is an empty set, go to S3; otherwise, re-enter S241;

[0182] S3 eliminates the occupation of instance resources by the shared call chain according to the calculation results of the multi-instance microservice orchestration and the dynamic instance calculation model based on the maximum marginal gain, determines the routing probability of the corresponding request flows of the remaining microservice-based applications according to the principle of proportional allocation of microservice resources, routes the requests to the corresponding microservice instances and server nodes, and finally determines the decision variables.

[0183] The routing strategy is determined based on the transfer probability and routing path of the request flow, including:

[0184] Since each microservice can be instantiated on a different server, the request flow requires The microservice m contained in can be processed on multiple nodes; define variables Indicates the microservice called by application ma(t) at time slot t Whether the corresponding functional requirements are processed / responded on server node n; secondly, based on the dependencies between microservices When the request from the predecessor microservice is processed, the successor microservice can start working. In addition, the number of cores of the same type of microservice containerized on different server nodes is usually different. Considering the limited bandwidth resources and communication overhead between servers, user requests need a suitable request routing strategy to determine the forwarding path between the predecessor node and the successor node.

[0185] Defining variables Represents the request flow of the microservice-based application ma(t) from the deployment of the predecessor microservice m p Server n i Routing to the deployment successor microservice m s Server n j The probability of is the call topology between microservices; from a micro perspective, each user selects a request routing path and traverses the specified microservices in order to meet the requirements; from a macro perspective, the request flow implements multi-queue request routing and diversion in a probabilistic way to avoid network congestion and achieve load balancing; for variables and There are the following expressions:

[0186]

[0187] in is an indicator function. In a microservice-based application ma(t), when microservice m p and m s When there is a dependency between them, the value of this function is 1; otherwise, it is 0;

[0188] Routing requests to the corresponding microservice instances and server nodes, and finally determining the decision variables: Based on the routing strategy of the application resource ratio of the microservice, the corresponding request flow of the microservice application is routed to the corresponding microservice instance and server node according to the principle of resource ratio, and finally determining the ternary decision variables and

[0189] Figure 6 It is the average request processing delay of the cloud computing center data network under different request sizes.

[0190] Figure 7 It is the memory usage of the data network of the cloud computing center under the same scale of user requests.

[0191] Embodiment 2:

[0192] See also Figure 2 , a data-aware microservice scaling and request routing update system, the system is used to execute the aforementioned data-aware microservice scaling and request routing update method, specifically comprising:

[0193] The dynamic instance quantity determination module is used to determine the network configuration of the cloud data service center and the set of microservice-based user requests for accessing the cloud data service center in each time slot; the number and type of instances required to be deployed for each time slot service instance are obtained through a dynamic instance calculation model based on maximum marginal gain; polling placement is used to quickly determine the total number of microservice instances required during the time slot change process and the corresponding change increment, and to achieve user needs with the minimum ideal deployment cost;

[0194] The instance dynamic scaling deployment module is used to complete the multi-instance microservice orchestration under the service grid architecture in a fine-grained manner according to the total number of microservice instances required during the current time slot change and the corresponding change increment, combined with the segmented active scaling algorithm based on redundancy recovery, to release redundant instance resources, actively retain some redundancy, and prevent sudden traffic loads;

[0195] The proportional routing dynamic partitioning module is used to eliminate the occupation of instance resources by the shared call chain according to the calculation results of the multi-instance microservice orchestration and the dynamic instance calculation model based on the maximum marginal gain, determine the routing probability of the corresponding request flows of the remaining microservice-based applications according to the principle of proportional allocation of microservice resources, route the requests to the corresponding microservice instances and server nodes, and finally determine the decision variables.

[0196] Embodiment 3:

[0197] See also Figure 3 , a data-aware microservice scaling and request routing update device, comprising a memory and a processor, wherein the memory is used to store a computer program code and transmit the computer program code to the processor;

[0198] The processor is used to execute the data-aware microservice scaling and request routing update method described in Example 1 according to the instructions in the computer program code.

[0199] Embodiment 4:

[0200] A computer program product includes a computer program, characterized in that when the computer program is executed by a processor, the steps of the aforementioned data-aware based microservice scaling and request routing update method are implemented.

Claims

1. A data-aware microservice scaling and request routing update method, characterized in that: The following steps are involved: S1 determines the network configuration of the cloud data service center and the set of microservice-based user requests for accessing the cloud data service center in each time slot; obtains the number and type of instances required to be deployed for each time slot service instance through a dynamic instance calculation model based on maximum marginal gain; uses polling placement to quickly determine the total number of microservice instances required during the time slot change process and the corresponding change increment, and realizes user needs with the minimum ideal deployment cost; S2 completes the orchestration of multi-instance microservices under the service grid architecture in a fine-grained manner, based on the total number of microservice instances required during the current time slot change and the corresponding change increment, combined with a segmented active scaling algorithm based on redundancy recovery, releases redundant instance resources, and actively retains some redundancy to prevent sudden traffic loads; S3 eliminates the occupation of instance resources by the shared call chain according to the calculation results of the multi-instance microservice orchestration and the dynamic instance calculation model based on the maximum marginal gain, determines the routing probability of the corresponding request flows of the remaining microservice-based applications according to the principle of proportional allocation of microservice resources, routes the requests to the corresponding microservice instances and server nodes, and finally determines the decision variables.

2. According to a data-aware microservice scaling and request routing update method according to claim 1, it is characterized in that: S11 Determine the network configuration and service support of the cloud data service center, including: The network configuration of the cloud data service center includes a large number of servers that can provide computing services. Deploying a service instance on a node consumes a certain amount of computing resources of the node, that is, the number of cores in each server. At the same time, there is also communication delay and transmission bandwidth between servers. G=(N,E) represents the cloud data service center, where N={n1,n2,...,n |N| } is a collection of physical server nodes, E represents the connection between two physical servers n i ,n j A collection of links; Indicates physical server n i ∈N, the maximum computing resource capacity, the number of cores of the server represents the computing resources. Each core can only instantiate one container, and each container can only hold one microservice instance; Each physical link Corresponding to a pair of connected server nodes {(n i , n j )|n i , n j ∈N}; Indicates the connected physical server n i , n j The maximum bandwidth capacity between the two, which is shared by all service requests. Indicates physical server n i , n j Inherent communication delay between Represents a collection of microservice types. For each microservice Due to the heterogeneity of microservices, the core of the same server has different processing capabilities for task requests of different types of microservices. The unit processing capacity is expressed as The step of determining a microservice-based user request set for accessing the cloud data service center in each time slot includes: During the processing of the cloud data service center, user requests from different time slots are dynamically received. The service types and request arrival rates in different time slots change in real time. In the formula, MA(t)={ma1(t),ma2(t),...,ma |MA(t)| (t)} represents the set of all microservice-based applications; use Represents a request flow consisting of a specific user request, where represents the time when the request flow of the microservice-based application arrives at the cloud data service center, λ ma(t) represents the real-time average request arrival rate, Represents the topology of a tree-like microservice graph, Indicates the predefined maximum service / request response delay threshold. is a collection of call paths; Includes a collection of microservice types A collection of directed dependencies between microservices According to the microservice topology Get all specific microservice call path collections in: represents the arrival rate of the i-th call path split according to the ratio, represents the i-th call path, Indicates the kth accessed microservice in the i-th call path; the request needs to traverse the specified microservice call sequence to be successfully processed; all execution paths are obtained through DFS, and combined with Properties and microservice dependencies Determine the equivalent request arrival rate corresponding to each microservice call chain Based on the DAG graph structure of probability forwarding, the sum of the average request arrival rates of the child microservice nodes is equal to the average input arrival rate of the parent microservice. The attribute of each microservice call link in the data parallel DAG graph structure contains the forwarding probability, and the sum of the probabilities is 1; based on the data parallel DAG graph structure, the equivalent average arrival rate of each microservice call chain is equal to the average request arrival rate of the request flow 3. According to a data-aware microservice scaling and request routing update method according to claim 2, it is characterized in that: S12 obtains the number and type of instances required to be deployed for each time slot service instance through a dynamic instance calculation model based on maximum marginal gain, including: Defining variables Indicates that at time slot t, microservice The number of cores occupied on the physical server n∈N, that is, the number of microservice instances; in addition, each deployment plan is executed at the end of the previous time slot t-1, so these instances are available to complete the corresponding function and complete user requests during time slot t; considering that the total number of deployed microservice instances cannot exceed the total number of cores of the physical server, the computing resource constraint is obtained: When determining the number of instances required for each microservice, the polling placement strategy is used to calculate the number of microservice instances with the highest tolerance combined with the tightened latency constraints of each call chain. Since the needs of each user are different and there are multiple call paths in the microservice call graph, Distributed physical servers will collaboratively provide corresponding functions; specifically, for each real-time request flow corresponding to a microservice-based application, there are multi-instance and multi-queue request routing.

4. According to the data-aware microservice scaling and request routing update method of claim 3, it is characterized in that: S13 calculates the tightened tolerance delay based on the dynamic request traffic-instance awareness algorithm, and uses the polling placement strategy to calculate the maximum number of microservice instances to be deployed under the current number of polling queues; Calculate the tighter delay tolerance In each time slot t, historical information related to the microservice system is counted to calculate the statistical average propagation, data transmission and query delays. And call the depth-first search algorithm DFS, all real-time changing microservice-based applications ma(t)∈MA(t), calculate all specific call paths for each application And sort all call chains in descending order according to their equivalent average arrival rate; then calculate the tightened tolerance delay for each call chain The average communication delay, communication bandwidth, and average arrival rate of request flows between service network servers are used to replace the average data transmission delay of specific request flows. The arrival rate of request flows and the query cost of interacting with the database are used to obtain the database interaction delay. The calculation is based on Subtract the average propagation delay, data transmission delay, and database interaction delay to obtain the tighter tolerance delay For each required microservice, the microservice instances are distributed and placed in On each server node, following the dependency relationship of the call chain, a request queues and calculate the probability of each request service path Then, add an instance for each microservice and update the probability synchronously and calculate the expected delay gain To ensure fairness, calculate the average instance gain of each microservice and select the microservice with the largest marginal gain value. According to the properties of the microservice application, update the i-th call chain cp of the microservice-based application ma(t) i The number of microservices required by After each round of instance number update, recalculate the response delay and delay constraints Compare until user needs are met; finally, perform statistical classification to obtain the number of instances required for each microservice required by dynamic requests in time slot t Service instance requirements on different call paths than the current time 5. According to the data-aware microservice scaling and request routing update method of claim 4, it is characterized in that: Dynamic request traffic-instance-aware algorithm: S131 calculates the average communication delay based on the network topology and average communication bandwidth Initialize the average access latency of stateful microservices based on historical log records S132 Specific service request ma(t) in the cyclic request set MA(t) is based on the topological characteristics Calculate the call path set based on the characteristics of the service graph through the depth-first traversal method And sort in descending order according to the equivalent average arrival rate of the call chain to get a new set S133 loop microservice request Specific microservice call chain Recalculate the tightened tolerance delay, consider the database interaction delay, and calculate the microservice call chain First response delay under ideal network conditions S134 If Loop specific microservice call chain Specific microservices in Based on the proportional probability routing, the application places the number of microservice instances required to be deployed in the current round according to the polling placement strategy. At most instance queues and calculate the probability of each request queue When the total number of instances of the corresponding microservice increases by one, the instance queue and According to the queuing theory formula, the expected delay gain is calculated: Indicates the latency of calculating the number of instances allocated to the queue based on the proportional allocation result after the polling placement instances are increased. Indicates the delay before the current round of polling placement. represents the expected delay gain; S135 finds the placement result with the largest latency gain and corresponds it to the number of microservice instances to be deployed To increase; S136 Topology based on service graph Increase the number of instances to ensure a certain level of redundancy S137 pair All the same microservices in Number of instances updated simultaneously S138 Recalculate response delay S139 classifies and counts each microservice based on the attribute characteristics of each microservice-based application r(t) Calculate the sum of the number of instances required for each microservice at the current time t 6. According to a data-aware microservice scaling and request routing update method according to claim 1, it is characterized in that: In S2, the active microservice automatic scaling in the multi-instance microservice orchestration under the service grid architecture includes: segmented active automatic scaling accompanied by redundant recovery: S21 initializes an existing set of microservice-based applications And perform life cycle management: traverse the application collection Each specific application Microservice-based applications that exceed the time slot constraint no longer provide services to users: If Then end the service of these requests and Remove But keep the corresponding service instance and update the corresponding network status variables; is the response delay of the critical call path, For microservices-based applications The maximum request latency threshold defined by It represents the time when the request flow of the microservice-based application arrives at the data center, represented by t; after the traversal is completed, it enters S22; S22 Initialization instance retention redundancy factor Mean() calculates the average, [] + Indicates that negative values ​​are taken as 0, and max(,) means taking the maximum value of the two; S23 extracts the microservice-based application set MA(t) and There are service graphs with the same topology in , and we get an overlapping set of orchestration attributes for microservice-based applications: in, A collection of microservice-based applications that existed in the previous time slot is the current microservice-based application set MA(t) and the previous time slot A microservices-based application with a service graph of the same topology, The deployment decision of whether the microservice m of the application is deployed on node n; Backing up a collection of microservices All microservices in the array are sorted in ascending order, and the process goes to S24; S24 is not an empty set, go to S241; when It is an empty set, and enters S3; S241 is the number of microservice instances required for time slot t Reclaim all instance resources of microservice m and enter S245; S242 in The sum of the number of resources instantiated in the previous time slot t-1, and the corresponding calculation of the number of instances that actually need to be reduced To cope with potential burst request loads: S2421 Initialize the instantiated node list: the instantiated node list collection If it is an empty set, traverse the application set Each specific application if Then The server node n with the value of 1 joins the set After the traversal is completed, when the collection is not an empty set, go to S2422; when the set If it is an empty set, go to S2423; S2422 It is not an empty set, and the microservices have a common topology structure middle; S24221 Traversing a collection All server nodes n in: if or So if and So After the traversal is completed, when Enter S24222; when Enter S2423; S24222 According to the number of instances of microservice m Sort in descending order and traverse the collection All server nodes n in; if or So μ m for; After the traversal is completed, when Re-enter S24222; when Enter S2423; S2423 It is an empty set, and the microservices do not have a common topology structure. In the example, according to the number of instances of microservice m on each server node For all activated server nodes N in the current time slot active Sort in ascending order Get Collection Traversal All server nodes in n: if or So if or So After the traversal is completed, enter S2424; S2424 Maintain The corresponding request flow transition probability of applications with the same topology and path variables constant, The microservice m is deployed on n nodes under the ma(t) application p Forward the next service request to n deployed j Node microservices s Probability; enter S245: S243 If Then for all server nodes n, keep the existing deployment plan of microservice m S244 If Then calculate the average resource utilization of the currently activated node Calculating average resource utilization According to MA(t) and The topological dependency relationship of microservice m is used to find the predecessor microservice set of microservice m. and subsequent microservices collection Calculate all the nodes that exist on the currently activated node and The total number of instances of the microservice According to the utilization rate and topology-dependent instance ratio The weighted sum of , sort the server node set in descending order Weighting coefficient: α1+α2=1, calculation instance increment S2441 Enter S24411; S24411 loops through the set N of active states in the current time slot active The nodes n where all microservices are deployed, if or Just allocate instance resources directly. is the lower limit of the fairness index, indicating the maximum load capacity (between 0 and 1, 0.9 means the maximum capacity is 90%), C n represents the maximum number of nodes n that can be deployed when not deployed, C(t) n represents the maximum number of nodes n that can be deployed at time slot t; if Then allocate existing computing resources, if Indicates that the redundancy limit has been exceeded and no further instances will be added to the node; if This means that all instances have been placed, ending the current loop and entering S24412; S24412 Indicates that the existing enabled servers are insufficient, except N active A server node n′ is added to the remaining available nodes to meet the optimal result in terms of comprehensive evaluation of bandwidth and communication delay, and then instance resources are allocated to it. Add n′ to the list of activated server nodes N active ; S24413 Re-enter S24411; otherwise enter S245; S245 has completed all deployments at this time. Remove microservice m; when If it is an empty set, go to S3; otherwise, re-enter S241.

7. According to the data-aware microservice scaling and request routing update method of claim 1, it is characterized in that ,The routing strategy determined in S3 based on the transfer probability and ,routing path of the request flow includes: Since each microservice can be instantiated on a different server, the request flow requires The microservice m contained in can be processed on multiple nodes; define variables Indicates the microservice called by application ma(t) at time slot t Whether the corresponding functional requirements are processed / responded on server node n; secondly, based on the dependencies between microservices When the request from the predecessor microservice is processed, the successor microservice can start working. In addition, the number of cores of the same type of microservice containerized on different server nodes is usually different. Considering the limited bandwidth resources and communication overhead between servers, user requests need a suitable request routing strategy to determine the forwarding path between the predecessor node and the successor node. Defining variables Represents the request flow of the microservice-based application ma(t) from the deployment of the predecessor microservice m p Server n i Routing to the deployment successor microservice m s Server n j The probability of is the call topology between microservices; from a micro perspective, each user selects a request routing path and traverses the specified microservices in order to meet the requirements; from a macro perspective, the request flow implements multi-queue request routing and diversion in a probabilistic way to avoid network congestion and achieve load balancing; for variables and There are the following expressions: in is an indicator function. In a microservice-based application ma(t), when microservice m p and m s When there is a dependency between them, the value of this function is 1; otherwise, it is 0; Routing requests to the corresponding microservice instances and server nodes, and finally determining the decision variables: Based on the routing strategy of the application resource ratio of the microservice, the corresponding request flow of the microservice application is routed to the corresponding microservice instance and server node according to the principle of resource ratio, and finally determining the ternary decision variables and 8. A data-aware microservice scaling and request routing update system, characterized by: The system is used to execute the data-aware microservice scaling and request routing update method according to any one of claims 1 to 7, specifically comprising: The dynamic instance quantity determination module is used to determine the network configuration of the cloud data service center and the set of microservice-based user requests for accessing the cloud data service center in each time slot; the number and type of instances required to be deployed for each time slot service instance are obtained through a dynamic instance calculation model based on maximum marginal gain; polling placement is used to quickly determine the total number of microservice instances required during the time slot change process and the corresponding change increment, and to achieve user needs with the minimum ideal deployment cost; The instance dynamic scaling deployment module is used to complete the multi-instance microservice orchestration under the service grid architecture in a fine-grained manner according to the total number of microservice instances required during the current time slot change and the corresponding change increment, combined with the segmented active scaling algorithm based on redundancy recovery, to release redundant instance resources, actively retain some redundancy, and prevent sudden traffic loads; The proportional routing dynamic partitioning module is used to eliminate the occupation of instance resources by the shared call chain according to the calculation results of the multi-instance microservice orchestration and the dynamic instance calculation model based on the maximum marginal gain, determine the routing probability of the corresponding request flows of the remaining microservice-based applications according to the principle of proportional allocation of microservice resources, route the requests to the corresponding microservice instances and server nodes, and finally determine the decision variables.

9. A data-aware microservice scaling and request routing update device, characterized in that: The method comprises a memory and a processor, wherein the memory is used to store computer program code and transmit the computer program code to the processor; The processor is used to execute the data-aware microservice scaling and request routing update method according to any one of claims 1 to 7 according to the instructions in the computer program code.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the data-aware microservice scaling and request routing update method described in any one of claims 1 to 7 are implemented.

Images