Data-aware microservice scaling and request routing update method, system and device

Abstract

The application discloses a data-aware micro-service scaling and request routing update method, system and device, which comprises a maximum marginal gain-based dynamic instance determination algorithm, which determines the total instance number of micro-service required by each time slot and the corresponding increment according to the average request arrival rate variation in real time; according to the increment of micro-service instance deployment between time slots and the service capacity of the service center, the segment active scaling algorithm based on redundancy recovery is combined with the existing deployed topology to dynamically scale and adjust the specific deployment of each time slot, thereby completing the life cycle management of the micro-service application; according to the marginal benefit calculation principle of the instance-aware algorithm, the occupancy of instance resources by the common call chain is removed, and the micro-service request routing forwarding strategy is determined according to the resource proportion and the instance-aware principle based on the corresponding request flow of the micro-service application. The application can not only cope with the dynamic change of micro-service requests between time slots, but also further reduce the request time delay, save resource overhead, and guarantee the request success rate.

Description

Technical Field

[0001] This invention relates to the field of cloud data routing, and more particularly to a data-aware microservice scaling and request routing update method, system, and device. Background Technology

[0002] In recent years, with the widespread adoption of microservice architecture, dynamic deployment technology has gradually become an important means of solving performance optimization problems in complex cloud computing environments. Microservice architecture, by decomposing a single application into multiple independent services, offers advantages such as loose coupling, easy scalability, and ease of maintenance. Especially in cloud computing applications that handle high concurrency and real-time processing demands, the independent deployability of microservices makes them particularly outstanding in terms of performance tuning and system resilience.

[0003] In cloud data centers, real-time applications typically receive a large number of user requests distributed across different service nodes, requiring processing through a microservice call chain. Due to the complex dependencies and frequent communication between microservices, achieving efficient service deployment in a dynamic environment becomes a critical issue. Microservice deployment not only affects system response speed but also directly impacts overall service latency, load balancing, and resource utilization.

[0004] Existing microservice deployment solutions typically separate service deployment from request routing. While this optimizes individual tasks locally, it neglects 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, leading to degraded system performance and increased latency.

[0005] Therefore, designing a dynamic deployment method that balances service deployment with global request routing optimization, taking into account the dynamic nature of services, has become a core challenge in improving the quality of cloud computing services. This requires not only accurate modeling and analysis of the microservice call graph but also dynamic adjustment of deployment strategies to cope with service requests under different load scenarios, thereby achieving global optimization of system performance. Summary of the Invention

[0006] The purpose of this invention is to overcome the problem of the inability to quickly adjust service deployment strategies in the prior art, and to provide a data-aware microservice scaling and request routing update method, system and device for addressing the inability to quickly adjust service deployment strategies.

[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; it obtains the required number and type of service instances for each time slot through a dynamic instance calculation model based on maximum marginal gain; and it quickly determines the total number of microservice instances required during time slot changes and the corresponding increment of changes by using round-robin placement, and achieves user needs with the minimum ideal deployment cost.

[0010] S2, based on the total number of microservice instances required during the current time slot change process and the corresponding increment of change, combined with a segmented proactive scaling algorithm based on redundancy recovery, completes the orchestration of multi-instance microservices under the service mesh architecture in a fine-grained manner, releases excess instance resources, proactively retains some redundancy, and prevents sudden traffic load.

[0011] Based on the multi-instance microservice orchestration and the calculation results of the dynamic instance calculation model based on maximum marginal gain, S3 excludes the shared call chain from occupying instance resources. The remaining request flows of the microservice-based application determine the routing probability according to the principle of microservice resource allocation ratio, and route the requests to the corresponding microservice instances and server nodes, thus finally determining the decision variables.

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

[0013] In the network configuration of the cloud data service center, there are a large number of servers that can provide computing services distributed in the cloud data service center. Deploying a service instance on a node will consume a certain amount of computing resources of the node, namely the number of cores inside each server. At the same time, there is also communication latency and transmission bandwidth between services.

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

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

[0016] Each physical link A corresponding pair of connected server nodes {(n i n j )|n i n j ∈N}; Indicates the connected physical servers n i n j The maximum bandwidth capacity between all service requests, which is shared by all service requests. Represents physical server n i n j The inherent communication delay between them;

[0017] This represents the set 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 from different types of microservices. Unit processing capability is expressed as...

[0018] The determination of the set of microservice-based user requests for accessing the cloud data service center in each time slot includes:

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

[0020] use This represents a request stream consisting of specific user requests, where λ represents the moment when a request stream from a microservice-based application arrives at the cloud data service center. ma(t) This represents the real-time average request delivery rate. This represents the topological structure of a tree-like microservice graph. This represents the predefined maximum service / request response latency threshold. It is a collection of call paths;

[0021] Includes a collection of microservice types A set of directed dependencies between microservices Based on microservice topology Get the set of all specific microservice call paths in: This represents the arrival rate of the i-th call path, which is split according to the ratio. This represents the i-th call path. This represents the k-th microservice accessed in the i-th call path; a request needs to traverse the specified microservice call order to be successfully processed; all execution paths are obtained through Depth-First Search (DFS), and combined with... Attributes and microservice dependencies Determine the equivalent request reach rate for each microservice call chain. In a DAG graph structure based on probabilistic forwarding, the sum of the average request arrival rates of the child microservice nodes equals the average input arrival rate of the parent microservice. If each microservice call chain in the graph contains a forwarding probability, then the sum of the probabilities is 1; however, 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 that request flow.

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

[0023] Define variables This indicates that in time slot t, the microservice The number of cores occupied on physical servers n∈N, i.e., the number of microservice instances; furthermore, 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 fulfill user requests during time slot t; considering that the total number of deployed microservice instances cannot exceed the total number of physical server cores, the following computational resource constraints are obtained:

[0024]

[0025] When determining the specific number of instances required for each microservice, the maximum tolerable number of microservice instances is calculated based on a round-robin placement strategy combined with latency constraints for tightening each call chain. This is because each user's needs differ and the microservice call graph contains multiple call paths. Distributed physical servers work together to provide the corresponding functions; specifically, for each microservice-based application's real-time request stream, there are multiple instances and multiple queues for request routing.

[0026] S13 is based on the dynamic request traffic-instance awareness algorithm to calculate and obtain the tightened tolerance latency. It uses the polling placement strategy to calculate the maximum number of microservice instances that need to be deployed under the current polling queue size.

[0027] Calculate and obtain the tightening tolerance delay Within each time slot t, historical relevant information of the microservice system is statistically analyzed to calculate statistical average propagation, data transmission, and query latency, using unique graph topology attributes. It then invokes the Depth-First Search (DFS) algorithm to compute all specific call paths for each of the real-time changing microservice-based applications, ma(t)∈MA(t). Then, all call chains are sorted in descending order based on their equivalent average arrival rate; finally, the tightening tolerance latency is calculated for each call chain. The average communication latency, bandwidth, and arrival rate of request streams between service network servers are used to replace the average data transmission latency of specific request streams. Database interaction latency is obtained using the arrival rate of request streams and the query cost of database interaction. The calculation is then performed using... The tightened tolerance latency is obtained by subtracting the average propagation, data transmission latency, and database interaction latency.

[0028] For each required microservice, microservice instances are distributed across different locations according to a round-robin placement strategy. On each server node, following the dependency relationship of the call chain, a sequence is formed. Each request queue is processed, and the probability of serving each request path is calculated. Then, add an instance for each microservice and update the probabilities synchronously. And calculate the expected delay gain To ensure fairness, the average gain of each microservice instance is calculated, and the microservice with the largest marginal gain is selected. Based on the attributes of the microservice application, update the i-th call chain cp of the microservice-based application ma(t). i The number required for the j-th microservice After each instance count update, the response latency is recalculated. and time delay limit The comparison continues until the user's needs are met; finally, statistical classification is performed to obtain the set of instances required for each microservice for dynamic requests within time slot t. Service instance requirements on different call paths at different times

[0029] Dynamic Request Traffic - Instance Aware Algorithm:

[0030] S131 calculates the average communication delay based on the network topology. and average communication bandwidth Based on historical log records, the average access latency for initializing stateful microservices was determined.

[0031] The specific service request ma(t) in the S132 cyclic request set MA(t) is determined based on topological characteristics. The call path set is calculated based on the characteristics of the service graph using a depth-first traversal method. Then, based on the equivalent average arrival rate of the call chain, sort them in descending order to obtain a new set.

[0032] S133 Looping Microservice Requests Specific microservice call chains Recalculate the tightened tolerance latency, and after considering database interaction latency, calculate the microservice call chain. First response delay under ideal network conditions

[0033] S134 If Loop through the specific microservice call chain Specific microservices in Based on proportional probability routing, the application determines the number of microservice instances to be deployed in the current round based on a round-robin placement strategy. At most divided into Count the number of instance queues and calculate the probability of each request queue. When the total number of instances of the corresponding microservice increases by one, update the instance queue and Calculate the expected delay gain using queuing theory formulas:

[0034]

[0035] This indicates the latency for calculating the number of instances allocated to the queue based on the proportional allocation result after the number of instances added in the polling placement process. This indicates the delay before the current polling session is placed. Indicates the desired delay gain;

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

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

[0038] S137 All the same microservices Synchronously update the number of instances

[0039] S138 recalculates response delay

[0040] S139 provides statistical classifications for each type of microservice, based on the attribute characteristics Ψ of each microservice-based application. r(t) Calculate the sum of the number of instances required for each type of microservice at the current time t.

[0041] In S2, the proactive microservice autoscaling in the multi-instance microservice orchestration under the service mesh architecture includes: segmented proactive autoscaling accompanied by redundancy recovery.

[0042] S21 Initializes the existing collection of microservice-based applications. And perform lifecycle management: traverse the application collection Each specific application in Microservice-based applications that exceed time slot constraints will no longer provide services to users: if Then terminate the service for these requests and remove them from the set. Remove from However, the corresponding service instance is retained, and the corresponding network status variables are updated. For the response latency of the critical call path, For microservice-based applications The maximum request latency threshold is defined as follows. The time when the request flow of a microservice-based application arrives at the data center is represented by t; after traversal is complete, proceed to S22;

[0043] S22 initialization instance retains redundancy factor Mean() calculates the average, [] + The negative value is 0, and max(,) means taking the maximum of the two values;

[0044] S23 Extracts the microservice-based application set MA(t) and Service graphs with the same topology structure yield overlapping sets of orchestration attributes for microservice-based applications: in, This refers to the collection of microservice-based applications that existed in the previous time slot. Let MA(t) be the current set of microservice-based applications and the previous time slot. Microservice-based applications with service graphs that share the same topology The deployment decision for whether the microservice m of this application is deployed on node n; based on For backup microservice collections All microservices are sorted in ascending order and then entered into S24;

[0045] S24 when If it is not an empty set, proceed to S241; when Since it is an empty set, proceed to S3;

[0046] S241 Number of microservice instances required for time slot t Reclaim all instance resources of microservice m and proceed to S245;

[0047] S242 when in Given the sum of the number of resources already instantiated in the previous time slot t-1, calculate the actual number of instances that need to be reduced. To handle potential sudden surges in request load:

[0048] S2421 Initialize the instantiated node list: the collection of instantiated node lists If the set is empty, iterate through the application set. Each specific application in if Then Server node n with a value of 1 is added to the set. After the traversal is complete, when the collection If the set is not empty, proceed to S2422; when the set is empty... If the set is empty, proceed to S2423;

[0049] S2422 Not an empty set, microservices have a shared topology. middle;

[0050] S24221 Traversing the set All server nodes n:

[0051] if or So

[0052] if and So

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

[0054] S24222 is based on the number of instances of microservice m. Sort the collection in descending order and traverse it. All server nodes n in ;

[0055] if or So μ m for;

[0056] After the traversal is complete, when Re-entering S24222; when Enter S2423;

[0057] S2423 As an empty set, microservices do not have a public topology. In the middle, based on the number of microservice m instances on each server node For all active server nodes N in the current time slot active Sort in ascending order Get the set Traversal All server nodes n:

[0058] if or So

[0059] if or So

[0060] After completing the traversal, proceed to S2424;

[0061] S2424 remains The probability of request flow transition for applications with the same topology. and path variables constant, For the microservice m deployed on n nodes under the application ma(t) p Forward the next service request to the n deployed on j microservices of a node m s The probability of entering S245:

[0062] S243 If Therefore, for all server nodes n, maintain the existing deployment scheme of microservice m.

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

[0064] S2441 when Enter S24411;

[0065] S24411 iterates through the set N of currently active time slots. active The number of nodes n where all microservices are deployed.

[0066] if or Just allocate instance resources directly.

[0067] The lower limit of the fairness index represents the maximum load capacity (a value between 0 and 1, where 0.9 indicates a maximum utilization of 90% of the capacity). C n Let C(t) represent the maximum number of nodes that can be deployed when node n is not yet deployed. n This represents the maximum number of nodes n that can be deployed in time slot t.

[0068] if Then allocate existing computing resources.

[0069]

[0070] if This indicates that the redundancy limit has been exceeded, and no more instances will be added to this node.

[0071] if This means all instances have been placed, the current loop ends, and we proceed to S24412;

[0072] S24412 when This indicates that there are not enough currently active servers, except for N. active One additional server node n′ is added from the remaining available nodes, ensuring that the node achieves the optimal result in terms of both bandwidth and communication latency. Then, instance resources are allocated to it accordingly. Add n′ to the list of active server nodes N. active ;

[0073] S24413 when Re-enter S24411; otherwise, enter S245.

[0074] S245 has now completed all deployments and is ready to proceed. Remove microservice m from the middle; when If the set is empty, proceed to S3; otherwise, re-enter S241.

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

[0076] Since each microservice can be instantiated on a different server, the request flow requires... The included microservice m can be processed on multiple nodes; define variables. This represents the microservice called by application ma(t) in time slot t. First, are the corresponding functional requirements processed / responded to on server node n? Second, based on the dependencies between microservices... A subsequent microservice can only start working when a request from the predecessor microservice has been processed. In addition, the number of containerized cores for the same type of microservice on different server nodes is usually different. Considering the limited bandwidth resources and communication overhead between servers, user requests need an appropriate request routing strategy to determine the forwarding path between the predecessor node and the successor node.

[0077] Define variables This represents the request flow of a microservice-based application ma(t) from the pre-deployment microservice m. p server n i Routing to subsequent microservices m after deployment s server n j The probability of , where This refers to the call topology between microservices. From a micro perspective, each user selects a request routing path, traversing the specified microservices in sequence to fulfill their requirements. From a macro perspective, the request flow uses probability to achieve multi-queue request routing and distribution, avoiding network congestion and achieving load balancing. Regarding variables... and The following expression exists:

[0078]

[0079] in It is an indicator function; in a microservice-based application ma(t), when microservice m... p and m s The function evaluates to 1 if a dependency exists; otherwise, it evaluates to 0.

[0080] The requests are routed to the corresponding microservice instances and server nodes, ultimately determining the decision variables: a routing strategy based on the application resource ratio of microservices. This strategy routes the request flow corresponding to the microservice application to the corresponding microservice instances and server nodes according to the resource ratio principle, ultimately determining the three decision variables. and

[0081] Secondly, the present invention provides a data-aware microservice scaling and request routing update system, the system being used to execute the aforementioned data-aware microservice scaling and request routing update method, specifically including:

[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; it obtains the required number and type of service instances to be deployed for each time slot through a dynamic instance calculation model based on maximum marginal gain; and it quickly determines the total number of microservice instances required during time slot changes and the corresponding increment of changes by using round-robin placement, and achieves user needs with the minimum ideal deployment cost.

[0083] The instance dynamic scaling deployment module is used to perform multi-instance microservice orchestration in a fine-grained manner based on the total number of microservice instances required during the current time slot change process and the corresponding change increment, combined with a segmented proactive scaling algorithm based on redundancy recovery. This releases excess instance resources, proactively retains some redundancy, and prevents sudden traffic load.

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

[0085] Thirdly, the present invention provides a data-aware microservice scaling and request routing update device, characterized in that: it includes a memory and a processor, wherein the memory is used to store computer program code and transmit the computer program code to the processor;

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

[0087] Fourthly, the present invention provides a computer program product, including a computer program, characterized in that, when the computer program is executed by a processor, it implements the steps of the aforementioned data-aware microservice scaling and request routing update method.

[0088] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0089] 1. This invention discloses a data-aware microservice scaling and request routing update method. First, it determines the cloud data service center's network configuration, service support, and user requests from microservice-based applications sending requests to the cloud data service center. Then, based on the cloud computing center's data network and the set of user requests to be processed, it calculates the tightening tolerance latency using a dynamic instance calculation model based on maximum marginal gain, leveraging average propagation, data transmission, and query latency. A round-robin placement strategy is used to calculate the required number and type of service instances for each time slot. Next, a segmented proactive scaling algorithm based on redundancy recovery is used to complete the orchestration of multi-instance microservices under the service mesh architecture. Finally, a routing strategy is determined based on a method for allocating application resources proportionally within the microservices. Through these steps, while ensuring the efficiency and success rate of network data processing and request response, the overall system resource consumption is reduced, and resource utilization and network fairness are improved.

[0090] 2. The present invention provides a deployment scheme for dynamic scaling of microservices based on data awareness and request routing update method, which first calculates the required number of instances based on the arrival status of user requests in each time slot according to marginal benefits. Then, based on the changes in deployment status between time slots, the redundancy factor of instances is calculated, instances are scaled up and down to reduce resource overhead, and the service capacity of the entire cloud data service center is adjusted in a timely manner. Finally, the routing of requests is arranged to reduce network congestion.

[0091] 3. The data-aware microservice scaling and request routing update system of the present invention is used to implement the steps of the data-aware microservice scaling and request routing update method provided in any of the above technical solutions. Therefore, this system simultaneously 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. The present invention provides a data-aware microservice scaling and request routing update device, comprising a processor and a memory. The memory stores computer program code and transmits the computer program code to the processor. The processor executes the data-aware microservice scaling and request routing update method provided in any of the above-described technical solutions according to the instructions in the computer program code. Therefore, this device simultaneously includes all the beneficial effects of the data-aware microservice scaling and request routing update method provided in any of the above-described technical solutions, which will not be elaborated further here. Attached Figure Description

[0093] Figure 1 This is a flowchart of the method of the present invention.

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

[0095] Figure 3 This is a diagram of the device of the present invention.

[0096] Figure 4 This is a schematic diagram of the cloud data service center network structure according to Embodiment 1 of the present invention.

[0097] Figure 5 This is a schematic diagram of the structure of multi-instance microservice orchestration under the Chinese service mesh architecture in Embodiment 1 of the present invention.

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

[0099] Figure 7 This shows the memory usage of the embodiments and comparative examples of the present invention as the algorithm changes. Detailed Implementation

[0100] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0101] The performance optimization of this patented algorithm under different scales and dynamic conditions was tested by building a server cluster platform using Kubernetes. Two commonly used industry algorithms were compared, and the implementation scheme of this patent was compared using a controlled variable method.

[0102] Comparative Example 1

[0103] The main approach is to use the FFD algorithm based on the firstfit concept. It uses a greedy approach to consider centralized deployment and reduce the latency of services on a single node, but it ignores link congestion and deployment balance.

[0104] Comparative Example 2

[0105] The main approach is to use the iterative RRA algorithm, which uses random deployment to explore and update the algorithm in multiple rounds to achieve better results. However, it ignores the overhead and resource consumption of the server and microservice startup and shutdown processes during time slot changes.

[0106] Example 1:

[0107] See Figure 1 , 4 5. A data-aware microservice scaling and request routing update method, comprising 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; it obtains the required number and type of service instances for each time slot through a dynamic instance calculation model based on maximum marginal gain; and it quickly determines the total number of microservice instances required during time slot changes and the corresponding increment of changes by using round-robin placement, and achieves user needs with the minimum ideal deployment cost.

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

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

[0111] In the network configuration of the cloud data service center, there are a large number of servers that can provide computing services distributed in the cloud data service center. Deploying a service instance on a node will consume a certain amount of computing resources of the node, namely the number of cores inside each server. At the same time, there is also communication latency and transmission bandwidth between services.

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

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

[0114] Each physical link A corresponding pair of connected server nodes {(n i n j )|n i n j ∈N}; Indicates the connected physical servers n i n j The maximum bandwidth capacity between all service requests, which is shared by all service requests. Represents physical server n i n j The inherent communication delay between them;

[0115] This represents the set 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 from different types of microservices. Unit processing capability is expressed as...

[0116] The determination of the set of microservice-based user requests for accessing the cloud data service center in each time slot includes:

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

[0118] use This represents a request stream consisting of specific user requests, where λ represents the moment when a request stream from a microservice-based application arrives at the cloud data service center. ma(t) This represents the real-time average request delivery rate. This represents the topological structure of a tree-like microservice graph. This represents the predefined maximum service / request response latency threshold. It is a collection of call paths;

[0119] Includes a collection of microservice types A set of directed dependencies between microservices Based on microservice topology Get the set of all specific microservice call paths in: This represents the arrival rate of the i-th call path, which is split according to the ratio. This represents the i-th call path. This represents the k-th microservice accessed in the i-th call path; a request needs to traverse the specified microservice call order to be successfully processed; regardless of whether it's a probabilistic forwarding call or a data parallel call mode, the DAG graph structure can be used to find all execution paths using DFS, and combined with... Attributes and microservice dependencies Determine the equivalent request reach rate for each microservice call chain. In a DAG graph structure based on probabilistic forwarding, the sum of the average request arrival rates of the child microservice nodes equals the average input arrival rate of the parent microservice. If each microservice call chain in the graph contains a forwarding probability, then the sum of the probabilities is 1; however, 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 that request flow.

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

[0121] Define variables This indicates that in time slot t, the microservice The number of cores occupied on physical servers n∈N, i.e., the number of microservice instances; furthermore, 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 fulfill user requests during time slot t; considering that the total number of deployed microservice instances cannot exceed the total number of physical server cores, the following computational resource constraints are obtained:

[0122]

[0123] When determining the specific number of instances required for each microservice, the maximum tolerable number of microservice instances is calculated based on a round-robin placement strategy combined with latency constraints for tightening each call chain. This is because each user's needs differ and the microservice call graph contains multiple call paths. Distributed physical servers work together to provide the corresponding functions; specifically, for each microservice-based application's real-time request stream, there are multiple instances and multiple queues for request routing.

[0124] S13 is based on the dynamic request traffic-instance awareness algorithm to calculate and obtain the tightened tolerance latency. It uses the polling placement strategy to calculate the maximum number of microservice instances that need to be deployed under the current polling queue size.

[0125] Calculate and obtain the tightening tolerance delay Within each time slot t, historical relevant information of the microservice system is statistically analyzed to calculate statistical average propagation, data transmission, and query latency, using unique graph topology attributes. It then invokes the Depth-First Search (DFS) algorithm to compute all specific call paths for each of the real-time changing microservice-based applications, ma(t)∈MA(t). Then, all call chains are sorted in descending order based on their equivalent average arrival rate; finally, the tightening tolerance latency is calculated for each call chain. The average communication latency, bandwidth, and arrival rate of request streams between service network servers are used to replace the average data transmission latency of specific request streams. Database interaction latency is obtained using the arrival rate of request streams and the query cost of database interaction. The calculation is then performed using... The tightened tolerance latency is obtained by subtracting the average propagation, data transmission latency, and database interaction latency.

[0126] For each required microservice, microservice instances are distributed across different locations according to a round-robin placement strategy. On each server node, following the dependency relationship of the call chain, a sequence is formed. Each request queue is processed, and the probability of serving each request path is calculated. It is an improvement based on the idea of ​​queuing theory, which uses multiple queues (because multiple queues will reduce the processing speed due to latency) to improve the tolerance of the algorithm;

[0127] Then, add an instance for each microservice and update the probabilities synchronously. And calculate the expected delay gain To ensure fairness, the average gain of each microservice instance is calculated, and the microservice with the largest marginal gain is selected. Based on the attributes of the microservice application, update the i-th call chain cp of the microservice-based application ma(t). i The number required for the j-th microservice After each instance count update, the response latency is recalculated. and time delay limit The comparison continues until the user's needs are met; finally, statistical classification is performed to obtain the set of instances required for each microservice for dynamic requests within time slot t. Service instance requirements on different call paths at different times

[0128] Dynamic Request Traffic - Instance Aware Algorithm:

[0129] S131 calculates the average communication delay based on the network topology. and average communication bandwidth Based on historical log records, the average access latency for initializing stateful microservices was determined.

[0130] The specific service request ma(t) in the S132 cyclic request set MA(t) is determined based on topological characteristics. The call path set is calculated based on the characteristics of the service graph using a depth-first traversal method. Then, based on the equivalent average arrival rate of the call chain, sort them in descending order to obtain a new set.

[0131] S133 Looping Microservice Requests Specific microservice call chains Recalculate the tightened tolerance latency, and after considering database interaction latency, calculate the microservice call chain. First response delay under ideal network conditions

[0132] S134 If Loop through the specific microservice call chain Specific microservices in Based on proportional probability routing, the application determines the number of microservice instances to be deployed in the current round based on a round-robin placement strategy. At most divided into Count the number of instance queues and calculate the probability of each request queue. When the total number of instances of the corresponding microservice increases by one, update the instance queue and Calculate the expected delay gain using queuing theory formulas:

[0133]

[0134] This indicates the latency for calculating the number of instances allocated to the queue based on the proportional allocation result after the number of instances added in the polling placement process. This indicates the delay before the current polling session is placed. Indicates the desired delay gain;

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

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

[0137] S137 All the same microservices Synchronously update the number of instances

[0138] S138 recalculates response delay

[0139] S139 provides statistical classifications for each type of microservice, based on the attribute characteristics Ψ of each microservice-based application. r(t) Calculate the sum of the number of instances required for each type of microservice at the current time t.

[0140] S2, based on the total number of microservice instances required during the current time slot change process and the corresponding increment of change, combined with a segmented proactive scaling algorithm based on redundancy recovery, completes the orchestration of multi-instance microservices under the service mesh architecture in a fine-grained manner, releases excess instance resources, proactively retains some redundancy, and prevents sudden traffic load.

[0141] Fine-grained approach refers to breaking down services into modular microservices and deploying and scaling microservices as instances.

[0142] The segmented proactive scaling algorithm based on redundancy recovery completes the orchestration of multi-instance microservices under a service mesh architecture, including:

[0143] By employing a segmented proactive scaling algorithm based on redundancy recovery, multi-instance microservice orchestration in a service mesh architecture is completed online and efficiently in a fine-grained manner. By comparing orchestration schemes after service time changes, when the required number of microservice instances needs to be reduced, excess instance resources are released according to the scaling strategy, while proactively retaining some redundancy to prevent sudden traffic loads.

[0144] When the number of microservice instances to be deployed increases, the appropriate server nodes are selected to deploy microservice instances, taking into account the location of similar microservice instances, the amount of data communication with dependent microservice nodes, and the communication latency. The forwarding probability at the instance level is determined by combining the resource ratio-aware routing principle, which ultimately achieves proactive microservice auto-scaling, reducing latency and dynamic deployment costs.

[0145] In S2, the proactive microservice autoscaling in the multi-instance microservice orchestration under the service mesh architecture includes: segmented proactive autoscaling accompanied by redundancy recovery.

[0146] S21 Initializes the existing collection of microservice-based applications. And perform lifecycle management: traverse the application collection Each specific application in Microservice-based applications that exceed time slot constraints will no longer provide services to users: if Then terminate the service for these requests and remove them from the set. Remove from However, the corresponding service instance is retained, and the corresponding network status variables are updated. For the response latency of the critical call path, For microservice-based applications The maximum request latency threshold is defined as follows. The time when the request flow of a microservice-based application arrives at the data center is represented by t; after traversal is complete, proceed to S22;

[0147] S22 initialization instance retains redundancy factor Mean() calculates the average, [] + The negative value is 0, and max(,) means taking the maximum of the two values;

[0148] S23 Extracts the microservice-based application set MA(t) and Service graphs with the same topology structure yield overlapping sets of orchestration attributes for microservice-based applications: in, This refers to the collection of microservice-based applications that existed in the previous time slot. Let MA(t) be the current set of microservice-based applications and the previous time slot. Microservice-based applications with service graphs that share the same topology The deployment decision for whether the microservice m of this application is deployed on node n; based on For backup microservice collections All microservices are sorted in ascending order and then entered into S24;

[0149] S24 when If it is not an empty set, proceed to S241; when Since it is an empty set, proceed to S3;

[0150] S241 Number of microservice instances required for time slot t Reclaim all instance resources of microservice m and proceed to S245;

[0151] S242 when in Given the sum of resources already instantiated in the previous time slot t-1, calculate the actual number of microservice instances that need to be retained based on the instance redundancy factor. The corresponding calculation should determine the actual number of instances that need to be reduced. To handle potential sudden surges in request load:

[0152] If microservice m is in a public topology or an overlapping microservice-based application If microservice instances exist, resources will not be released temporarily on the corresponding service instances on the server nodes occupied by the aforementioned applications. Priority will be given to reducing the number of similar microservice instances on other server nodes. If microservice instances still remain unreduced, the nodes containing microservice m instances will be sorted in descending order, and the selection will be based on a round-robin approach. The number of instances decreases by 1 each time;

[0153] If the microservice does not exist in a public topology, sort all nodes containing the number of instances of that microservice in descending order, starting with the node with the smallest number of instances, and clear the instance count until only a small number of instances remain. indivual;

[0154] S2421 Initialize the instantiated node list: the collection of instantiated node lists If the set is empty, iterate through the application set. Each specific application in if Then Server node n with a value of 1 is added to the set. After the traversal is complete, when the collection If the set is not empty, proceed to S2422; when the set is empty... If the set is empty, proceed to S2423;

[0155] S2422 Not an empty set, microservices have a shared topology. middle;

[0156] S24221 Traversing the set All server nodes n:

[0157] if or So

[0158] if and So

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

[0160] S24222 is based on the number of instances of microservice m. Sort the collection in descending order and traverse it. All server nodes n in ;

[0161] if or So μm is;

[0162] After the traversal is complete, when Re-entering S24222; when Enter S2423;

[0163] S2423 As an empty set, microservices do not have a public topology. In the middle, based on the number of microservice m instances on each server node For all active server nodes N in the current time slot active Sort in ascending order Get the set Traversal All server nodes n:

[0164] if or So

[0165] if or So

[0166] After completing the traversal, proceed to S2424;

[0167] S2424 remains The probability of request flow transition for applications with the same topology. and path variables constant, For the microservice m deployed on n nodes under the application ma(t) p Forward the next service request to the n deployed on j microservices of a node m s The probability of entering S245:

[0168] S243 If Therefore, for all server nodes n, maintain the existing deployment scheme of microservice m.

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

[0170] S2441 when Enter S24411;

[0171] S24411 iterates through the set N of currently active time slots. active The number of nodes n where all microservices are deployed.

[0172] if or Just allocate instance resources directly.

[0173] The lower limit of the fairness index represents the maximum load capacity (a value between 0 and 1, where 0.9 indicates a maximum utilization of 90% of the capacity). C n Let C(t) represent the maximum number of nodes that can be deployed when node n is not yet deployed. n This represents the maximum number of nodes n that can be deployed in time slot t.

[0174] if Then allocate existing computing resources.

[0175]

[0176] if This indicates that the redundancy limit has been exceeded, and no more instances will be added to this node.

[0177] if This means all instances have been placed, the current loop ends, and we proceed to S24412;

[0178] S24412 when This indicates that the existing active servers are insufficient, and new active servers are needed to meet the computing resource requirements, excluding N. active Add a server node from the remaining available nodes. The node that achieves the best overall performance in terms of bandwidth and communication latency will then be allocated instance resources accordingly. Add n′ to the list of active server nodes N. active ;

[0179] This refers to finding the standby servers (i.e., excluding N). active (remaining available nodes outside) in α T and α B Calculation under two equilibrium coefficients The node with the smallest result is taken as n';

[0180] S24413 when Re-enter S24411; otherwise, enter S245.

[0181] S245 has now completed all deployments and is ready to proceed. Remove microservice m from the middle; when If the set is empty, proceed to S3; otherwise, re-enter S241.

[0182] Based on the multi-instance microservice orchestration and the calculation results of the dynamic instance calculation model based on maximum marginal gain, S3 excludes the shared call chain from occupying instance resources. The remaining request flows of the microservice-based application determine the routing probability according to the principle of microservice resource allocation ratio, and route the requests to the corresponding microservice instances and server nodes, thus finally determining the decision variables.

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

[0184] Since each microservice can be instantiated on a different server, the request flow requires... The included microservice m can be processed on multiple nodes; define variables. This represents the microservice called by application ma(t) in time slot t. First, are the corresponding functional requirements processed / responded to on server node n? Second, based on the dependencies between microservices... A subsequent microservice can only start working when a request from the predecessor microservice has been processed. In addition, the number of containerized cores for the same type of microservice on different server nodes is usually different. Considering the limited bandwidth resources and communication overhead between servers, user requests need an appropriate request routing strategy to determine the forwarding path between the predecessor node and the successor node.

[0185] Define variables This represents the request flow of a microservice-based application ma(t) from the pre-deployment microservice m. p server n i Routing to subsequent microservices m after deployment s server n j The probability of , where This refers to the call topology between microservices. From a micro perspective, each user selects a request routing path, traversing the specified microservices in sequence to fulfill their requirements. From a macro perspective, the request flow uses probability to achieve multi-queue request routing and distribution, avoiding network congestion and achieving load balancing. Regarding variables... and The following expression exists:

[0186]

[0187] in It is an indicator function; in a microservice-based application ma(t), when microservice m... p and m s The function evaluates to 1 if a dependency exists; otherwise, it evaluates to 0.

[0188] The requests are routed to the corresponding microservice instances and server nodes, ultimately determining the decision variables: a routing strategy based on the application resource ratio of microservices. This strategy routes the request flow corresponding to the microservice application to the corresponding microservice instances and server nodes according to the resource ratio principle, ultimately determining the three decision variables. and

[0189] Figure 6 This refers to the average request processing latency of the cloud computing center's data network under different request volumes.

[0190] Figure 7 This refers to the memory usage of the cloud computing center's data network under the same number of user requests.

[0191] Example 2:

[0192] See Figure 2 A data-aware microservice scaling and request routing update system, the system being used to execute the aforementioned data-aware microservice scaling and request routing update method, specifically including:

[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; it obtains the required number and type of service instances to be deployed for each time slot through a dynamic instance calculation model based on maximum marginal gain; and it quickly determines the total number of microservice instances required during time slot changes and the corresponding increment of changes by using round-robin placement, and achieves user needs with the minimum ideal deployment cost.

[0194] The instance dynamic scaling deployment module is used to perform multi-instance microservice orchestration in a fine-grained manner based on the total number of microservice instances required during the current time slot change process and the corresponding change increment, combined with a segmented proactive scaling algorithm based on redundancy recovery. This releases excess instance resources, proactively retains some redundancy, and prevents sudden traffic load.

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

[0196] Example 3:

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

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

[0199] Example 4:

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

Claims

1. A data-aware based microservice scaling and request routing update method, characterized in that, The method comprises the following steps: S1, determining a cloud data service center network configuration and a set of micro-service-based user requests accessing the cloud data service center in each time slot; obtaining the required number and type of deployed instances of each time slot service instance through a dynamic instance calculation model based on maximum marginal gain; and using round-robin placement to quickly determine the total number of required micro-service instances and the corresponding increment in the time slot change process, and to achieve user demand at the minimum ideal deployment cost; S2, according to the total number of required micro-service instances and the corresponding increment in the current time slot change process, combining a segmented active scaling algorithm based on redundancy recovery, in a fine-grained manner, completing multi-instance micro-service orchestration under a service mesh architecture, releasing redundant instance resources, and actively retaining part of the redundancy to prevent sudden traffic load; S3, according to the multi-instance micro-service orchestration and the calculation result of the dynamic instance calculation model based on maximum marginal gain, excluding the occupation of instance resources by common call chains, determining routing probability according to the principle of micro-service resource proportion allocation for the corresponding request flow of the remaining micro-service-based application, and routing the request to the corresponding micro-service instance and server node to finally determine the decision variable.

2. The method of claim 1, wherein, S11, determining a cloud data service center network configuration and service support, comprising: In the cloud data service center network configuration, a large number of servers providing computing services are distributed in the cloud data service center, and deploying a service instance on a node will consume a certain amount of computing resources of the node, that is, the number of cores inside each server, and there is also a communication delay and transmission bandwidth between servers; represents a cloud data service center, wherein is a set of physical server nodes, represents a set of links connecting two physical server nodes. represents the maximum computing resource capacity of the physical server The number of cores of the server represents the computing resource; each core can only instantiate one container, and each container can only accommodate one microservice instance; Each physical link A pair of corresponding connected server nodes ; Indicates the connected physical server The maximum bandwidth capacity between all service requests, which is shared by all service requests. Indicates physical server The inherent communication delay between them; a set of microservice types, for each microservice Due to the heterogeneity of microservices, the same server's core has different processing capabilities for task requests of different types of microservices, and the unit processing capability is represented as ; The determination of the set of micro-service-based user requests accessing the cloud data service center in each time slot comprises: In the process of cloud data service center, user requests from different time slots are dynamically received. The service types and request arrival rates in different time slots are real-time changes. In each time slot , a set of all micro-service-based applications is represented by . with denotes a request flow consisting of specific user requests, wherein denotes the time of arrival of the request flow of the microservice-based application at the cloud data service center, denotes the average request arrival rate in real time, denotes the topology of the tree-shaped microservice graph, denotes a predefined maximum service / request response latency threshold, is a set of call paths; a set of microservice types and a set of directed dependencies between microservices ; according to the microservice topology , get all specific microservice invocation path sets , where: represents the arrival rate of the ith invocation path according to the proportional split, represents the ith invocation path, , represents the kth accessed microservice in the ith invocation path; the request needs to traverse the specified microservice invocation order to be successfully processed; all execution paths are obtained by DFS, and the properties of and microservice dependencies determine the equivalent request arrival rate corresponding to each microservice invocation chain ; based on the probability forwarding DAG graph structure, 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, and if each microservice invocation link attribute contains a forwarding probability, the sum of the probabilities is 1; and based on the data parallel DAG graph structure, the equivalent average arrival rate of each microservice invocation chain is equal to the average request arrival rate of the request flow .

3. The method of claim 2, wherein, S12, obtaining the required number and type of deployed instances of each time slot service instance through a dynamic instance calculation model based on maximum marginal gain, comprising: Definition of variables representing in time slot , microservice the number of cores occupied on the physical server , i.e. the number of microservice instances; in addition, each deployment scheme is executed at the end of the previous time slot , so these instances are available during the time slot to complete the corresponding function functions and user requests; considering that the total deployed microservice instances cannot exceed the total core number of the physical server, the computing resource constraint is obtained: ； In the specific determination of the required instance number of each microservice, according to the strategy of round-robin placement, the maximum tolerance instance number of microservice is calculated combined with the time delay constraint of each call chain tightening; since the demand of each user is different and the microservice call graph has multiple call paths , the distributed physical servers cooperatively provide corresponding functions; specifically, for each real-time request flow corresponding to a microservice-based application, there are multiple instances and multiple queue request routing.

4. The method of claim 3, wherein, S13, based on a dynamic request traffic-instance awareness algorithm, calculating the tolerated delay of tightening, and using the strategy of round-robin placement to calculate the maximum value of the number of micro-service instances to be deployed under the current round-robin queue number; Calculate and obtain the tightening tolerance delay In each time slot Internally, it uses historical information from the statistical microservice system to calculate statistical averages for propagation, data transmission latency, and average query latency, through unique graph topology attributes. It also invokes the Depth-First Search (DFS) algorithm to process all real-time changes in microservice-based applications. Calculate all specific call paths for each application Then, all call chains are sorted in descending order based on their equivalent average arrival rate; finally, the tightening tolerance latency is calculated for each call chain. The average communication latency, average communication bandwidth, and average arrival rate of request streams across the service network are used to replace the average data transmission latency of specific request streams. Database interaction latency is obtained using the arrival rate of request streams and the query cost of interacting with the database. The latency is then calculated using... The tightened tolerance latency is obtained by subtracting the average propagation, data transmission latency, and database interaction latency. ; For each required microservice, microservice instances are distributed across different locations according to a round-robin placement strategy. On each server node, following the dependency relationship of the call chain, a sequence is formed. Each request queue is processed, and the probability of serving each request path is calculated. Then, add an instance for each microservice and synchronously update the probabilities. And calculate the expected delay gain To ensure fairness, the average gain of each microservice instance is calculated, and the microservice with the largest marginal gain is selected. Update the microservice-based application according to its attributes. The i-th call chain The number required for the j-th microservice After each instance count update, the response latency is recalculated. and time delay limit The comparison continues until user needs are met; finally, statistical classification is performed to obtain time slots. The set of instances required for each microservice in internal dynamic requests Service instance requirements on different call paths at different times .

5. The method of claim 4, wherein, The dynamic request traffic-instance awareness algorithm comprises: S131 calculate average communication latency according to network topology and average communication bandwidth , initialize average access latency of stateful microservice according to historical log records ; S132 loop request specific service request ma(t) in the set MA(t), according to the characteristics of the topology , the method of depth-first traversal according to the characteristics of the service graph to calculate the call path set , and according to the equivalent average arrival rate of the call chain, the new set is sorted in descending order ; S133 loop microservice request Microservice call chain in detail , Recalculate the tolerance delay of the tightened, calculate the microservice call chain after considering the database interaction delay First response delay under ideal network state ; S134 if , loop specific microservice call chain , specific microservice , according to proportional probability routing, the strategy according to the round robin placement will divide the number of microservice instances required for the current round into 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, update the instance queue and ; according to the queuing theory formula, calculate the expected delay gain: ； a time delay calculated according to the number of instances allocated to the queue calculated according to the proportional allocation result after the polling placement instance is increased, a time delay before the current round of polling placement, a desired time delay gain; S135 finds the placement result with the largest latency gain, and it corresponds to the required number of microservice instances to be deployed increase; S136 according to the topology of the service graph An increase is made to the number of instances ; S137 pair All identical microservices in the middle Synchronize the number of instances ; S138 recalculate response latency ; S139 classifies statistics for each microservice, according to the attribute characteristics of each microservice-based application computes at the current time the sum of the number of instances required for each microservice .

6. The method of claim 1, wherein, In S2, the active micro-service automatic scaling in the multi-instance micro-service orchestration under the service mesh architecture comprises segmented active automatic scaling accompanied by redundancy recovery: S21 Initializes the existing collection of microservice-based applications. And perform lifecycle management: traverse the application collection Each specific application in For microservice-based applications that exceed time slot constraints, services will no longer be provided to users: if Then the service for these requests will be terminated, and the collection will be removed. Remove from However, the corresponding service instance is retained, and the corresponding network status variables are updated. , Microservice-based applications The maximum request latency threshold is defined as follows. This indicates the moment when the request flow from a microservice-based application arrives at the data center; after traversal, proceed to S22; S22 initialize instance representation redundancy factor ; wherein denotes averaging, denotes taking the maximum of both, denotes taking the maximum of both. S23 extracts the microservice-based application set with the same topology structure as the service graph in the previous time slot, obtaining the overlapping microservice-based application orchestration attribute set: wherein, is the microservice-based application set in the previous time slot , is the current microservice-based application set with the same topology structure as the service graph in the previous time slot , is the deployment decision of whether the microservice m of the application is deployed on the node n; according to all microservices in the backup microservice set are sorted in ascending order, and S24 is entered; S24 when is not empty, go to S241; when is empty, go to S3; S241 when the slot the number of microservice instances required , recycle the microservice all instance resources, enter S245; S242 when wherein is the number of resources that have been instantiated for the previous time slot t-1 and is the corresponding calculation of the number of instances that actually need to be reduced to cope with potential burst request load: S2421 initialize the instantiated node list: the instantiated node list set is empty, traverse the application set in each specific application , if , the value of server node with value 1 join the set ; after the traversal is completed, when the set is not empty, enter S2422; when the set is empty, enter S2423; S2422 Non-empty set, microservices exist public topology Medium; S24221 traverses the set all server nodes in the set : If or , then , ; If and then , ; After the traversal is completed, when , S24222 is entered; when , S2423 is entered; S24222 according to the microservice instance number of the microservice is sorted in descending order, and all server nodes in the set are traversed ; If or , then , , is; After the traversal is completed, when , re-enter S24222; when , enter S2423; S2423 For the empty set, there is no common topology of microservices In the middle, according to the number of instances of microservices On each server node All active server nodes under the current time slot Sorted in ascending order ), get the set , traverse All server nodes in : If or then , ; If or then , ; After the traversal is completed, S2424 is entered; S2424 holds the transfer probability of the corresponding request stream of the application with the same topology and path variable is invariant, for the application deployed in the microservice of the node forward the next service request to the microservice deployed in the node the probability; enter S245: S243 If , then for all server nodes , keep microservice existing deployment scheme ; S244 If , then calculate the average resource utilization of the currently activated node , calculate the average resource utilization ; according to and topological dependence relationship, find the predecessor microservice set and the successor microservice set of the microservice , calculate the total number of instances of all microservices existing in and on the currently activated node , according to the weighted sum of the utilization rate and the topological dependence instance proportion , sort the server node set in descending order , the weighting coefficient: , calculate the increment of the instance ; S2441 when enter S24411; S24411 loops through the set of active sets at the current time slot all microservice deployments on node n, If or , the instance resource is directly allocated, , , ; is the lower bound of the fairness index, indicating the highest capacity of the load, is the maximum deployable quantity of the node n when not deployed, is the remaining maximum deployable quantity of the node n at time slot t; If , then allocate existing computing resources, , , ; If , indicates that the redundancy limit is exceeded and no further instances are added at this node; If , it represents that the placement of all instances is completed, the current loop is ended, and S24412 is entered. S24412 when , indicates that there are not enough servers already enabled, from the remaining available nodes , to add one server node , that meets the node result optimal in the comprehensive evaluation of bandwidth and communication latency, then assign instance resources to it , , , add to the active server node list ; S24413 when re-enter S24411; else enter S245; S245 All deployments are now complete, from microservice m is removed; when is empty, go to S3; otherwise, go back to S241.

7. The method of claim 1, wherein In S3, the routing strategy determined according to the transfer probability of the request flow and the routing path comprises: Since each microservice can be instantiated on different servers, the request flow requires microservices contained in the middle can be processed on multiple nodes; define variables representing time slots , applications invoked microservices corresponding functional requirements are processed / responses on server nodes ; secondly, according to the dependence between microservices , when the request from the predecessor microservice is processed, the successor microservice can start working; in addition, the core number of the same type of microservice containerized on different server nodes is usually not the same, and considering the limited bandwidth resources and communication overhead between servers, the user request needs a suitable request routing strategy to determine the forwarding path between the predecessor node and the successor node; Define variables Indicates microservice-based applications The request flow originates from the pre-deployment microservice. server Routing to subsequent microservices after deployment server The probability of , where This refers to the call topology between microservices. From a micro perspective, each user selects a request routing path, traversing the specified microservices in sequence to fulfill their requirements. From a macro perspective, the request flow uses probability to achieve multi-queue request routing and distribution, avoiding network congestion and achieving load balancing. Regarding variables... and The expression is as follows: ； ； wherein is an indicator function, in a microservice-based application when there is a dependency between microservices and the value of this function is 1; otherwise, 0; The request is routed to the corresponding microservice instance and server node, and finally determines the decision variable: the routing strategy of the application resource proportion division of the microservice, and the corresponding request flow of the application of the microservice is routed to the corresponding microservice instance and server node according to the principle of resource proportion, and finally determines the ternary decision variable and .

8. A data-aware based microservice scaling and request routing update system, characterized in that: The system is used to execute the micro-service scaling and request routing update method based on data awareness according to any one of claims 1 to 7, and specifically comprises: A dynamic instance number determination module is configured to determine a cloud data service center network configuration and a set of micro-service-based user requests accessing the cloud data service center in each time slot; obtain the required number and type of deployed instances of each time slot service instance through a dynamic instance calculation model based on maximum marginal gain; and use round-robin placement to quickly determine the total number of required micro-service instances and the corresponding increment in the time slot change process, and to achieve user demand at the minimum ideal deployment cost. An example dynamic scaling deployment module is used to combine a segmented active scaling algorithm based on redundancy recovery according to the total number of instances of microservices required in the current time slot change process and the increment corresponding to the change, in a fine-grained manner, to complete the multi-instance microservice orchestration under the service mesh architecture, release redundant instance resources, actively retain part of the redundancy, and prevent sudden traffic load; A proportional routing dynamic division module is used to exclude the occupation of instance resources by common call chains according to the multi-instance microservice orchestration and the calculation results of a dynamic instance calculation model based on maximum marginal gain, determine routing probabilities for corresponding request flows of remaining microservice-based applications according to a microservice resource proportional allocation principle, route requests to corresponding microservice instances and server nodes, and finally determine the decision variable. 9.A data-aware based microservice scaling and request routing update device, characterized in that: The memory is configured to store computer program code and transmit the computer program code to the processor. The processor is configured to execute instructions in the computer program code to perform the data-aware microservice scaling and request routing update method according to any one of claims 1 to 7.

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

Images