Micro-service capacity expansion and shrinkage method and container arrangement management system

Abstract

The embodiment of the invention provides a micro-service capacity expansion and shrinkage method and a container arrangement management system, and relates to the technical field of micro-service architecture.The container arrangement management system obtains a plurality of application layer index values of a first micro-service associated with a target business process; performing weighted summation processing on the plurality of application layer index values by using the weight coefficients of the plurality of application layer index values of the first micro-service corresponding to the target business process to obtain a current load score of the first micro-service corresponding to the target business process; determining a first expected copy number of the first micro-service according to the current load score; and carrying out capacity expansion and shrinkage processing according to the first expected copy number. According to the scheme, the resource allocation accuracy can be improved.

Description

Technical Field

[0001] This application relates to the field of microservice architecture technology, and in particular to a microservice scaling method and a container orchestration management system. Background Technology

[0002] The load on container orchestration management systems (such as Kubernetes) changes in real time. To maintain the stable performance of the container orchestration management system, it uses a Horizontal Pod Autoscaler (HPA) mechanism to scale up and down microservices. Specifically, a resource metric collector or a custom metric adapter collects the values ​​of metrics such as CPU utilization and memory utilization of microservices, and uses a linear algorithm formula to determine the expected number of replicas of the microservices. The system control manager modifies the number of replicas of the target resource to the expected number of replicas of the microservices, thereby realizing the scaling up and down of microservices.

[0003] In this microservice scaling method, all microservices associated with business processes are scaled up or down using a single metric threshold (such as CPU utilization), which cannot adapt to the business characteristics of different business processes, resulting in low accuracy of resource allocation. Summary of the Invention

[0004] The purpose of this application is to provide a microservice scaling method and a container orchestration management system to improve the accuracy of resource allocation. The specific technical solution is as follows:

[0005] In a first aspect, embodiments of this application provide a microservice scaling method, applied to a container orchestration management system, the method comprising:

[0006] Obtain multiple application-layer metric values ​​of the first microservice associated with the target business process;

[0007] Using the weight coefficients of multiple application layer indicator values ​​of the first microservice corresponding to the target business process, the multiple application layer indicator values ​​are weighted and summed to obtain the current load score of the first microservice corresponding to the target business process.

[0008] Based on the current load score, determine the first expected number of replicas for the first microservice;

[0009] The capacity is adjusted based on the first desired number of replicas.

[0010] In some embodiments, the step of using the weight coefficients of multiple application layer metric values ​​of the first microservice corresponding to the target business process to perform weighted summation on the multiple application layer metric values ​​to obtain the current load score of the first microservice corresponding to the target business process includes:

[0011] By using the weight coefficients of multiple application layer indicator values ​​of the first microservice corresponding to the target business process, the multiple application layer indicator values ​​are weighted and summed to obtain the initial load score of the first microservice corresponding to the target business process.

[0012] The initial load score is corrected by using the correction factor of the first microservice corresponding to the target business process to obtain the current load score of the first microservice corresponding to the target business process.

[0013] In some embodiments, the number of target business processes is multiple;

[0014] The step of determining the first expected number of replicas of the first microservice based on the current load score includes:

[0015] By using the weight coefficient of each target business process, the current load scores corresponding to multiple target business processes are weighted and summed to obtain the total load score;

[0016] If the total load score is greater than the first preset load threshold, or if the total load score is less than the second preset load threshold, then the first expected number of replicas of the first microservice is calculated using a linear algorithm based on the total load score and the target load score, wherein the first preset load threshold is greater than the second preset load threshold.

[0017] In some embodiments, each target business process is also associated with other microservices besides the first microservice;

[0018] The step of scaling up or down the first microservice according to the first expected number of replicas includes:

[0019] Based on the proportional relationship between the microservices associated with each target business process and the first expected number of replicas, determine the second expected number of replicas of other microservices associated with each target business process;

[0020] Scaling is performed based on the first expected number of replicas and the second expected number of replicas of other microservices associated with each target business process.

[0021] In some embodiments, if the total load score is greater than a first preset load threshold, the step of scaling up or down based on the first expected number of replicas and the second expected number of replicas of other microservices associated with each target business process includes:

[0022] If the available resources of the container orchestration management system are greater than or equal to the first demand resources corresponding to the first total expected number of replicas, then the number of replicas of the first microservice is scaled up or down to the first expected number of replicas, and the number of replicas of other microservices associated with each target business process is scaled up or down to the corresponding second expected number of replicas. The first total expected number of replicas is the sum of the first expected number of replicas and all the second expected number of replicas.

[0023] If the available resources are less than the first required resources, then the microservices associated with the multiple target business processes are scaled up according to their priorities.

[0024] In some embodiments, the step of scaling up the microservices associated with the multiple target business processes according to their priorities includes:

[0025] If the available resources are greater than or equal to the second required resources corresponding to the second total expected number of replicas, then the number of replicas of the first microservice is expanded to the first expected number of replicas, and the number of replicas of other microservices associated with the first target business process is expanded to the corresponding second expected number of replicas. The second total expected number of replicas is the sum of the first expected number of replicas and the second expected number of replicas of other microservices associated with the first target business process. The first target business process is the target business process with the highest priority among the plurality of target business processes.

[0026] According to the priority from high to low, traverse other target business processes except the first target business process to obtain the current business process, and update the available resources according to the determined expected number of replicas of each microservice;

[0027] If the updated available resources are greater than or equal to the third required resources corresponding to the third total expected replica count, then the replica count of other microservices associated with the current business process will be expanded to the corresponding second expected replica count, and the third total expected replica count is the sum of the second expected replica counts of other microservices associated with the current business process.

[0028] If the updated available resources are less than the third required resources, then based on the available resources, the number of replicas of other microservices associated with the current business process is determined as the third expected number of replicas, and the required resources corresponding to the third expected number of replicas are less than or equal to the updated available resources; the number of replicas of other microservices associated with the current business process is expanded to the third expected number of replicas.

[0029] In some embodiments, the step of scaling up the microservices associated with the multiple target business processes according to their priorities includes:

[0030] If the available resources are less than the second required resources corresponding to the second total expected replica count, where the second total expected replica count is the sum of the first expected replica count and the second expected replica counts of other microservices associated with the first target business process, and the first target business process is the highest priority target business process among the plurality of target business processes, then scaling up or down is performed using any of the following methods:

[0031] Method 1: Based on the available resources, determine the fourth expected number of replicas of the first microservice and the fifth expected number of replicas of other microservices associated with the first target business process. The ratio of the fourth expected number of replicas to the fifth expected number of replicas satisfies the ratio between the first microservice and other microservices associated with the first target business process. Expand the number of replicas of the first microservice to the fourth expected number of replicas, and expand the number of replicas of other microservices associated with the first target business process to the fifth expected number of replicas.

[0032] Method 2: If the available resources are greater than or equal to the fourth required resources corresponding to the first expected number of replicas, then calculate the difference between the available resources and the fourth required resources to obtain the first remaining resources; based on the first remaining resources, determine the sixth expected number of replicas for other microservices associated with the first target business process, wherein the required resources corresponding to the sixth expected number of replicas are less than or equal to the first remaining resources; expand the number of replicas for the first microservice to the first expected number of replicas, and expand the number of replicas for other microservices associated with the first target business process to the sixth expected number of replicas;

[0033] If the available resources are less than the fourth required resources, then the seventh expected number of replicas of the first microservice is determined based on the available resources, wherein the required resources corresponding to the seventh expected number of replicas are less than or equal to the available resources; and the number of replicas of the first microservice is increased to the seventh expected number of replicas.

[0034] In some embodiments, the method further includes:

[0035] If the available resources are less than the first required resources, then a resource reduction processing method is adopted to process multiple target business processes. Among the multiple target business processes, the reduction in resource usage of the first business process is greater than the reduction in resource usage of the second business process, and the priority of the first business process is lower than that of the second business process.

[0036] In some embodiments, the target business process is also associated with other microservices besides the first microservice;

[0037] The step of scaling up or down the first microservice according to the first expected number of replicas includes:

[0038] Based on the proportional relationship between the microservices associated with the target business process and the first expected number of replicas, determine the second expected number of replicas for the other microservices;

[0039] The number of replicas of the first microservice is scaled up or down to the first desired number of replicas, and the number of replicas of the other microservices is scaled up or down to the second desired number of replicas.

[0040] In some embodiments, the method further includes:

[0041] Collect host-level index values ​​for each node in the container orchestration and management system;

[0042] The available resources of the container orchestration and management system are determined by using the host-level index values ​​of each node.

[0043] In some embodiments, the method further includes:

[0044] The scaling strategies for each business process are obtained through the human-computer interaction interface, and the scaling strategies include the scaling configuration parameters for each microservice role in each business process.

[0045] Record the scaling strategies for each business process.

[0046] In some embodiments, the method further includes:

[0047] Obtain inter-service call data in the container orchestration and management system;

[0048] The call data and microservice code are analyzed to determine the basic process information of the container orchestration management system. The basic process information includes the candidate microservices associated with each business process and the dependencies between each candidate microservice.

[0049] The basic information of the process is displayed through the human-computer interaction interface, so that users can input the scaling strategies of each business process based on the basic information of the process.

[0050] Secondly, embodiments of this application provide a container orchestration management system, which includes an indicator collection layer, a decision engine, and an interface server;

[0051] The indicator collection layer is used to collect multiple application layer indicator values ​​of the first microservice associated with the target business process.

[0052] The decision engine is used to perform a weighted summation of the multiple application layer indicator values ​​of the first microservice corresponding to the target business process by using the weight coefficients of the multiple application layer indicator values ​​of the first microservice corresponding to the target business process; determine the first expected number of replicas of the first microservice based on the current load score; generate a scaling instruction based on the first expected number of replicas; and send the scaling instruction to the interface server.

[0053] The interface server is used to perform scaling up or down processing based on the number of microservice replicas in the scaling up / down instruction.

[0054] In some embodiments, the decision engine is specifically used for:

[0055] By using the weight coefficients of multiple application layer indicator values ​​of the first microservice corresponding to the target business process, the multiple application layer indicator values ​​are weighted and summed to obtain the initial load score of the first microservice corresponding to the target business process.

[0056] The initial load score is corrected by using the correction factor of the first microservice corresponding to the target business process to obtain the current load score of the first microservice corresponding to the target business process.

[0057] In some embodiments, the number of target business processes is multiple;

[0058] The decision engine is specifically used to: use the weight coefficient of each target business process to perform weighted summation of the current load scores corresponding to multiple target business processes to obtain a total load score; if the total load score is greater than a first preset load threshold, or if the total load score is less than a second preset load threshold, then calculate the first expected number of replicas of the first microservice using a linear algorithm based on the total load score and the target load score, wherein the first preset load threshold is greater than the second preset load threshold.

[0059] In some embodiments, each target business process is also associated with other microservices besides the first microservice;

[0060] The decision engine is specifically used to: determine the second expected number of other microservices associated with each target business process based on the proportional relationship between the microservices associated with each target business process and the first expected number of replicas; and generate scaling instructions based on the first expected number of replicas and the second expected number of other microservices associated with each target business process.

[0061] In some embodiments, if the total load score is greater than a first preset load threshold, then the decision engine is specifically used for:

[0062] If the available resources of the container orchestration management system are greater than or equal to the first demand resources corresponding to the first total expected number of replicas, then a scaling instruction is generated carrying the first expected number of replicas and the second expected number of replicas of other microservices associated with each target business process. The first total expected number of replicas is the sum of the first expected number of replicas and all the second expected number of replicas.

[0063] If the available resources are less than the first required resources, then scaling instructions are generated based on the priorities of multiple target business processes.

[0064] In some embodiments, the decision engine is specifically used for:

[0065] If the available resources are less than the first required resources, and the available resources are greater than or equal to the second required resources corresponding to the second total expected replica count, then the first expected replica count and the second expected replica count of other microservices associated with the first target business process are added to the scaling instruction. The second total expected replica count is the sum of the first expected replica count and the second expected replica count of other microservices associated with the first target business process. The first target business process is the highest priority target business process among the multiple target business processes.

[0066] According to the priority from high to low, traverse the other target business processes except the first target business process to obtain the current business process, and update the available resources according to the expected number of replicas of each microservice included in the scaling instruction;

[0067] If the updated available resources are greater than or equal to the third required resources corresponding to the third total expected replica count, then the second expected replica count of other microservices associated with the current business process is added to the scaling instruction, and the third total expected replica count is the sum of the second expected replica counts of other microservices associated with the current business process.

[0068] If the updated available resources are less than the third required resources, then the number of replicas of other microservices associated with the current business process is determined as the third expected replica number. The required resources corresponding to the third expected replica number are less than or equal to the updated available resources, and the third expected replica number is added to the scaling instruction.

[0069] In some embodiments, the decision engine is specifically used for:

[0070] If the available resources are less than the second required resources corresponding to the second total expected replica count, where the second total expected replica count is the sum of the first expected replica count and the second expected replica counts of other microservices associated with the first target business process, and the first target business process is the highest priority target business process among the plurality of target business processes, then scaling instructions are generated using any of the following methods:

[0071] Method 1: Based on the available resources, determine the fourth expected number of replicas of the first microservice and the fifth expected number of replicas of other microservices associated with the first target business process. The ratio of the fourth expected number of replicas to the fifth expected number of replicas satisfies the ratio between the first microservice and other microservices associated with the first target business process. Generate scaling instructions carrying the fourth expected number of replicas and the fifth expected number of replicas.

[0072] Method 2: If the available resources are greater than or equal to the fourth required resources corresponding to the first expected number of replicas, then calculate the difference between the available resources and the fourth required resources to obtain the first remaining resources; based on the first remaining resources, determine the sixth expected number of replicas of other microservices associated with the first target business process, wherein the required resources corresponding to the sixth expected number of replicas are less than or equal to the first remaining resources; generate scaling instructions carrying the first expected number of replicas and the sixth expected number of replicas.

[0073] If the available resources are less than the fourth required resources, then the seventh expected number of replicas of the first microservice is determined based on the available resources, wherein the required resources corresponding to the seventh expected number of replicas are less than or equal to the available resources; and a scaling instruction carrying the seventh expected number of replicas is generated.

[0074] In some embodiments, the decision engine is further configured to: if the available resources are less than the first required resources, then process multiple target business processes by adopting a resource reduction processing method, wherein, among the multiple target business processes, the reduction in resource usage of the first business process is greater than the reduction in resource usage of the second business process, and the priority of the first business process is lower than that of the second business process.

[0075] In some embodiments, the target business process is also associated with other microservices besides the first microservice;

[0076] The decision engine is specifically used to: determine the second expected number of replicas of the other microservices based on the proportional relationship between the microservices associated with the target business process and the first expected number of replicas; and generate scaling instructions carrying the first expected number of replicas and the second expected number of replicas.

[0077] In some embodiments, the indicator acquisition layer is also used to acquire host layer indicator values ​​for each node.

[0078] The decision engine is also used to determine the available resources of the container orchestration management system by utilizing the host layer metric values ​​of each node.

[0079] In some embodiments, the container orchestration management system further includes a policy configuration center;

[0080] The strategy configuration center is used to obtain the scaling strategies of each business process input by the user through a human-computer interaction interface. The scaling strategies include the scaling configuration parameters of each microservice role in each business process; and record the scaling strategies of each business process.

[0081] In some embodiments, the container orchestration management system further includes a process analysis module;

[0082] The process analysis module is used to collect call data between microservices in the container orchestration management system; analyze the call data and the code of the microservices to determine the basic process information of the container orchestration management system, which includes candidate microservices associated with each business process and the dependencies between each candidate microservice; and display the basic process information through the human-computer interaction interface so that users can input the scaling strategies of each business process into the policy configuration center based on the basic process information.

[0083] Beneficial effects of the embodiments in this application:

[0084] In the technical solution provided in this application embodiment, the container orchestration management system configures corresponding weight coefficients for multiple application-layer metrics of different microservices associated with different business processes. Using the values ​​of these multiple application-layer metrics and their weight coefficients, the current load score of different microservices corresponding to different business processes is determined. Then, based on the current load score, the expected number of replicas of the microservices is determined for scaling up and down. In this solution, the application-layer metrics and weight coefficients can be configured according to the business characteristics of different business processes. Utilizing multiple application-layer metrics and weight coefficients adapted to the business characteristics of the business processes for scaling up and down overcomes the drawbacks of using a single metric threshold for scaling up and down, adapting to the business characteristics of different business processes, and thus improving the accuracy of resource allocation.

[0085] Of course, implementing any product or method of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

[0086] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other embodiments can be obtained based on these drawings.

[0087] Figure 1 This is a schematic diagram of a first structure of the container orchestration management system provided in an embodiment of this application;

[0088] Figure 2 This is a schematic diagram of a second structure of the container orchestration management system provided in an embodiment of this application;

[0089] Figure 3 This is a schematic diagram of a third structure of the container orchestration management system provided in the embodiments of this application;

[0090] Figure 4 A schematic diagram of a process dependency graph provided in an embodiment of this application;

[0091] Figure 5 This is a flowchart illustrating a microservice scaling method provided in an embodiment of this application. Detailed Implementation

[0092] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0093] For ease of understanding, the terms appearing in the embodiments of this application are explained below.

[0094] Microservice overlap: Multiple business processes share the same microservice.

[0095] Application layer metrics: Metrics directly related to business processes, reflecting the operational status and performance of the business processes. In this embodiment, application layer metrics may include, but are not limited to, CPU utilization, memory utilization, Queries Per Second (QPS), Input / Output Operations Per Second (IOPS), concurrent connections, single request processing time, request latency, error rate, etc.

[0096] Host-level metrics: Metrics related to the usage of underlying infrastructure resources, reflecting the physical / virtual resource status of nodes or containers. In this embodiment, host-level metrics may include, but are not limited to, CPU utilization, memory utilization, bandwidth utilization, packet loss rate, etc.

[0097] A container orchestration and management system can include multiple nodes, on which multiple microservices can be deployed. Multiple microservices associated with a single business process can be deployed on one or more nodes. Microservices are hosted in container groups (pods). One microservice is hosted within a pod.

[0098] Kubernetes is a container orchestration and management system. Kubernetes uses the HPA mechanism to scale microservices up and down. Specifically, a resource metric collector (such as a Metrics Server) or a custom metric adapter (such as a Prometheus Adapter) collects values ​​for microservice metrics such as CPU utilization and memory utilization, and uses the following linear algorithm formula to determine the desired number of replicas:

[0099] Expected number of replicas = ceil[current number of replicas * (current metric value / target metric value)];

[0100] Here, ceil[] represents rounding up.

[0101] The system control manager (such as Kube Controller Manager) modifies the number of replicas of the target resource (such as Deployment) to the expected number of replicas of the microservice, thereby enabling the scaling up and down of the microservice.

[0102] This microservice scaling method has the following problems:

[0103] 1) Low accuracy in resource allocation;

[0104] Container orchestration management systems comprise multiple business processes, each of which calls multiple microservices during its implementation. These microservices are the microservices associated with the business process. The performance requirements of a single business process on its associated microservices may differ, and different business processes may also have different performance requirements on the same or different microservices. However, in existing HPA mechanisms, all microservices associated with business processes are scaled up or down using a single metric threshold (such as CPU utilization), which cannot adapt to the different business characteristics of different business processes, resulting in low accuracy in resource allocation.

[0105] 2) Overlapping microservices lead to resource contention;

[0106] When multiple business processes share the same microservice, the existing HPA mechanism lacks a cross-business process coordination mechanism, which causes high-priority business processes to preempt resources from low-priority business processes. This is especially true when the container orchestration management system is under resource pressure, which will prevent high-priority business processes from executing normally.

[0107] 3) Imbalance in microservice collaboration related to business processes;

[0108] A business process may involve multiple microservices with dynamic ratios between them. For example, an order processing process may involve an order creation microservice, an inventory query microservice, and a payment processing microservice, with the ratio of order creation microservice: inventory query microservice: payment processing microservice being 3:1:2.

[0109] The existing HPA mechanism only supports independent scaling of single microservices, meaning it only scales up or down individual microservices exceeding a certain threshold, lacking a multi-microservice coordination mechanism. This independent scaling approach disrupts the dynamic proportional relationships between microservices, leading to bottleneck microservices, dragging down overall performance, and wasting resources. For example, scaling down the inventory query microservice resulted in insufficient replicas, causing a 40% drop in order completion rate; conversely, scaling up the payment processing microservice resulted in excessive replicas, with overall resource utilization at only 30%.

[0110] 4) The resource allocation strategy is static, has poor adaptability, and cannot dynamically adapt to business fluctuations.

[0111] The existing HPA mechanism relies on statically configured fixed indicator thresholds (such as the target indicator values ​​mentioned above) for scaling up and down operations. It cannot dynamically adjust resource allocation strategies according to business changes (such as seasonal traffic fluctuations), resulting in low resource utilization during off-peak hours, resource waste, and insufficient resources and response delays when facing sudden traffic surges.

[0112] To address the aforementioned problems, embodiments of this application provide a container orchestration and management system, such as... Figure 1 As shown, the container orchestration and management system includes an indicator acquisition layer 101, a decision engine 102, and an interface server 103.

[0113] Metrics collection layer 101 is used to collect multiple application layer metric values ​​of the first microservice associated with the target business process.

[0114] The decision engine 102 is used to perform weighted summation of multiple application layer indicator values ​​using the weight coefficients of multiple application layer indicator values ​​of the first microservice corresponding to the target business process, to obtain the current load score of the first microservice corresponding to the target business process; to determine the first expected number of replicas of the first microservice based on the current load score; and to generate scaling instructions based on the first expected number of replicas and send the scaling instructions to the interface server 103.

[0115] Interface server 103 is used to perform scaling up and down processing based on the number of microservice replicas in the scaling up and down instructions.

[0116] In the technical solution provided in this application embodiment, the container orchestration management system configures corresponding weight coefficients for multiple application-layer metrics of different microservices associated with different business processes. Using the values ​​of these multiple application-layer metrics and their weight coefficients, the current load score of different microservices corresponding to different business processes is determined. Then, based on the current load score, the expected number of replicas of the microservices is determined for scaling up and down. In this solution, the application-layer metrics and weight coefficients can be configured according to the business characteristics of different business processes. Utilizing multiple application-layer metrics and weight coefficients adapted to the business characteristics of the business processes for scaling up and down overcomes the drawbacks of using a single metric threshold for scaling up and down, adapting to the business characteristics of different business processes, and thus improving the accuracy of resource allocation.

[0117] In this embodiment, the container orchestration management system can run multiple business processes. A business process is a process that implements a specific business logic, such as a process that implements order processing logic or a process that implements product management logic. The target business process can be any one of these multiple business processes. The target business process can be associated with one or more microservices, which together implement the business logic of the target business process. The first microservice can be any one of these one or more microservices.

[0118] Application layer metrics for microservices associated with different business processes can be the same or different; application layer metrics for different microservices associated with a single business process can be the same or different.

[0119] In some embodiments, such as Figure 2 As shown, the container orchestration and management system may also include a policy configuration center 104;

[0120] The strategy configuration center 104 is used to obtain the scaling policies of each business process input by the user through the human-computer interaction interface. The scaling policies include the scaling configuration parameters of each microservice role associated with each business process; and record the scaling policies of each business process.

[0121] In some embodiments, such as Figure 3 As shown, the container orchestration management system may also include a process analysis module 105;

[0122] The process analysis module 105 is used to collect call data between microservices in the container orchestration management system; analyze the call data and the code of microservices to determine the basic process information of the container orchestration management system. The basic process information includes the candidate microservices associated with each business process and the dependencies between each candidate microservice; and display the basic process information through a human-computer interaction interface so that users can input the scaling strategies of each business process into the policy configuration center 104 based on the basic process information.

[0123] The following is combined with Figure 3 The container orchestration management system shown herein will be described in detail in the embodiments of this application.

[0124] (1) Process Analysis Module 105. Process Analysis Module 105 is used to analyze business processes, microservices and their interrelationships within the container orchestration management system.

[0125] In this embodiment of the application, the process analysis module 105 may include an automatic processing part and a manual analysis part, as follows:

[0126] 1) Automatic processing section.

[0127] The process analysis module 105 utilizes distributed tracing tools (such as Jaeger) to embed specific tracing mechanisms into microservices, automatically and continuously collecting and recording call data (i.e., interaction information) between microservices. Call data may include, but is not limited to, request initiation, transmission paths, and response status. The process analysis module 105 also utilizes code analysis tools to automatically scan and analyze the code of each microservice, obtaining key information such as function calls and data interactions within the microservice code.

[0128] Based on the collected call data and key information, the process analysis module 105 can determine the candidate microservices (i.e., the microservices that may be involved) associated with each business process and the dependencies between each candidate microservice, thereby obtaining the basic process information of the container orchestration management system.

[0129] To facilitate user viewing and determination of scaling configuration parameters, the process analysis module 105 can construct a process dependency graph and microservice overlap relationships based on basic process information. This graph and microservice overlap relationships are displayed through a human-computer interaction interface, providing an objective and accurate data foundation for subsequent analysis of process dependencies and microservice overlaps. The information included in the process dependency graph can be set according to actual needs; for example, it can include scheduling-related information such as call frequency and data volume.

[0130] For example, in an e-commerce system (i.e., a container orchestration management system), there are business processes such as order processing and promotional activities. The process analysis module 105 constructs a process dependency graph and microservice overlap relationships based on basic process information and displays them on the human-computer interaction interface. Figure 4 As shown, the order processing flow is associated with microservices 1, 2, and 3, while the promotional activity flow is associated with microservices 4, 5, and 3. This approach clearly presents the dependencies between the various microservices associated with the order processing and promotional activity flows. The order processing and promotional activity flows share the inventory query microservice 3, and the information related to calls between microservices is clearly displayed. Figure 4 In the context of a connection between two microservices with an arrow, the microservice without an arrow calls the microservice with an arrow.

[0131] Although the process analysis module 105 cannot directly and accurately determine each microservice and its role in the business process implementation using the aforementioned distributed tracing tools and code analysis tools, it can provide a large number of valuable clues and basic information for the manual analysis part, thereby significantly reducing the workload of manual sorting.

[0132] 2) Manual analysis section.

[0133] In this embodiment of the application, the manual analysis part can be further divided into three sub-parts, as follows:

[0134] a. Core processing flow analysis.

[0135] System administrators or architects can study business requirements documents, system design documents, and other materials. By relying on their understanding of the business and professional knowledge, as well as the basic process information displayed in the process analysis module 105, they can sort out multiple business processes within the container orchestration management system and clarify the microservices involved in each business process.

[0136] For example, in an e-commerce system, users need to thoroughly analyze the microservices involved in the order processing flow, from when a user places an order, through inventory checks, payment processing, to order confirmation, and clarify the specific scope and function of each microservice.

[0137] b. Determine the roles of microservices.

[0138] After identifying the microservices, users can use the four-layer general role model or other role models, combined with the functional characteristics, business logic, and call relationships of the microservices in various business processes (such as the basic process information displayed in the process analysis module 105), to label each microservice with its role in different business process implementations by adding tags to the microservice's metadata. This makes it easier for the container orchestration management system to identify and manage the microservices.

[0139] For example, for the inventory query microservice, in the order processing flow and promotional activity flow, it is necessary to manually determine that the inventory query microservice is mainly responsible for interacting with external resources (such as the inventory database) in data interaction, shielding the differences in underlying database access, so that users can mark the inventory query microservice as a resource access service role.

[0140] The identification and labeling of microservice roles requires comprehensive consideration of specific business scenarios.

[0141] c. Analysis of the number of microservices.

[0142] For each business process, users can combine historical business data, system performance reports, and the experience of business experts to analyze the quantitative relationships (i.e., proportional relationships) between the microservices associated with that business process.

[0143] For example, the order processing flow involves order creation microservices, inventory query microservices, and payment processing microservices. Within the order processing flow, users analyze data such as order volume over a period of time, resource utilization of each microservice, and system response time to determine the proportional relationships between these three microservices.

[0144] (2) Strategy Configuration Center 104. Strategy Configuration Center 104 is used to configure the scaling strategy of the container orchestration management system, that is, to configure the scaling configuration parameters of different microservice roles in each business process.

[0145] In this embodiment, the policy configuration center 104 can provide a human-computer interaction interface (such as a policy configuration interface) to present the policy configuration interface in a visual way, allowing users to intuitively set parameters. At the same time, the policy configuration center 104 provides an application programming interface (API) to facilitate the container orchestration management system to obtain and modify scaling policies through the API to adapt to dynamic changes in business.

[0146] Users can determine the scaling strategies for each business process based on the pre-defined roles of different microservices associated with each business process and the basic process information (such as business logic characteristics and historical call data) displayed by the process analysis module 105. Users input these scaling strategies into the container orchestration management system via a human-computer interaction interface. The container orchestration management system then obtains and records the user-input scaling strategies for each business process through the human-computer interaction interface.

[0147] In this embodiment, the scaling strategy may include scaling configuration parameters for each microservice role associated with each business process. The scaling strategy may also include, but is not limited to: the proportional relationship between microservices associated with the business process, target load score, business process priority, load threshold for performing scaling operations (i.e., a first preset load threshold), load threshold for performing scaling operations (i.e., a second preset load threshold), resource conflict handling algorithm, and version information of the scaling strategy. The first preset load threshold is greater than the second preset load threshold.

[0148] The target load score is the expected load score. The scaling configuration parameters for each microservice role associated with the business process may include, but are not limited to: application-layer metrics for that microservice role, and the weighting coefficients corresponding to each application-layer metric. The priority of a business process can be understood as its priority relative to the microservice, or resource priority.

[0149] Resource conflict arises from resource contention among multiple business processes with overlapping microservices. A resource conflict resolution algorithm is a resource allocation algorithm used by container orchestration systems to address resource contention among multiple business processes with overlapping microservices that require scaling when resources are strained. For example, a resource conflict resolution algorithm might employ a method that reduces resource usage to handle lower-priority business processes.

[0150] For example, the promotional activity process prioritizes the inventory query microservice over the order processing process. Based on the resource conflict handling algorithm, when the container orchestration management system is under resource pressure, the order processing process reduces the query frequency or uses cached data, thereby reducing the order processing process's use of the inventory query microservice.

[0151] Version information for scaling strategies may include, but is not limited to, modification time, personnel involved in the modification, and reason for modification. Version information is used for strategy retrospective analysis and auditing.

[0152] (3) Indicator Acquisition Layer 101. The indicator acquisition layer 101 is used to collect the values ​​of various monitoring indicators (i.e., monitoring indicator values) of the container orchestration management system. The monitoring indicators can specifically include the following two categories.

[0153] 1) Application layer metrics.

[0154] The metric collection layer 101 can continuously collect the values ​​of multiple application-layer metrics (i.e., application-layer metric values) for each microservice associated with various business processes. Application-layer metrics are used to determine whether to perform scaling up or down operations.

[0155] In this embodiment, different microservices may use different programming languages. The metric collection layer 101 can configure the corresponding software development kit (SDK) for different microservices and use the SDK to collect multiple application layer metric values ​​for the corresponding microservices.

[0156] 2) Host layer metrics.

[0157] The indicator collection layer 101 can continuously collect the values ​​of host layer indicators (i.e., host layer indicator values) of each node.

[0158] In this embodiment, a custom metric client component (Prometheus client component), such as a Prometheus node exporter, can be deployed within the node or container where each microservice resides. The metric collection layer 101 uses the custom metric client component to collect host-level metric values ​​from each node. Host-level metrics are used to determine the available resources of the container orchestration management system.

[0159] To avoid data loss and facilitate historical review, analysis, and querying, the container orchestration and management system can also include a time-series database of custom metrics (Prometheus). The metric acquisition layer 101 can use Hypertext Transfer Protocol (HTTP) or general Remote Procedure Call (gRPC) to store the collected monitoring metric values ​​in the time-series database.

[0160] In this way, the decision engine 102 can periodically obtain various monitoring indicator values ​​from the time series database for subsequent scaling up and down operations.

[0161] In this embodiment, users can utilize open-source data visualization and monitoring platforms to configure visualization interfaces for monitoring metrics, such as Grafana's dashboard. The metric acquisition layer 101 collects various monitoring metric values ​​and presents them in chart form on the visualization interface, facilitating users' observation of the container orchestration and management system's operational status and assisting users in determining scaling strategies.

[0162] (4) Decision Engine 102. Decision Engine 102 is used to make decisions on scaling up and down microservices associated with business processes.

[0163] The decision engine 102 acquires monitoring metrics collected by the metric collection layer 101, such as reading monitoring metrics collected by the metric collection layer 101 from a time series database.

[0164] For the first microservice associated with the target business process, the decision engine 102 uses the weight coefficients of multiple application layer indicators of the first microservice in the scaling strategy of the target business process (i.e., the weight coefficients of multiple application layer indicator values) to perform weighted summation on multiple application layer indicator values ​​using the following formula (1) to obtain the current load score of the first microservice corresponding to the target business process, i.e., the current load score corresponding to the target business process.

[0165]

[0166] In formula (1), LoadScore i M represents the current load score of microservice i corresponding to the target business process, n represents the number of application layer metrics (i.e., the number of application layer metric values), and M represents the current load score of microservice i corresponding to the target business process. j This represents the value of application layer metric j (i.e., application layer metric value j), w j This represents the weight coefficient of the application layer indicator j corresponding to the target business process (the weight coefficient corresponding to the application layer indicator value j).

[0167] In this embodiment, the decision engine 102 can be specifically used to: use the weight coefficients of multiple application layer indicator values ​​of the first microservice corresponding to the target business process to perform weighted summation on the multiple application layer indicator values ​​to obtain the initial load score of the first microservice corresponding to the target business process; and use the correction factor of the first microservice corresponding to the target business process to correct the initial load score to obtain the current load score of the first microservice corresponding to the target business process. That is, there is a correspondence between the weight coefficients of the multiple application layer indicator values ​​of the target business process and the first microservice, and there is a correspondence between the correction factor of the target business process and the first microservice. The decision engine 102 can use the following formula (2) to determine the current load score of the first microservice corresponding to the target business process.

[0168]

[0169] In formula (2), LoadScore i M represents the current load score of microservice i corresponding to the target business process, n represents the number of application layer metrics (i.e., the number of application layer metric values), and M represents the current load score of microservice i corresponding to the target business process. j This represents the value of application layer metric j (i.e., application layer metric value j), w jrepresents the weight coefficient of application layer metric j corresponding to the target business process (the weight coefficient of application layer metric value j), and C represents the correction factor of the first microservice corresponding to the target business process. The initial load score for microservice i corresponding to the target business process.

[0170] In this embodiment, the correction factor C can be determined based on the context of the target business process. For example, if the first microservice is a critical path service associated with the target business process, the correction factor C is set to 0.1; if the first microservice is not a critical path service associated with the target business process, the correction factor C is set to 0, and so on. As another example, if the first microservice is a microservice that multiple microservices associated with the target business process depend on, the correction factor C is set to 0.1; if the first microservice is a microservice that only one microservice associated with the target business process depends on, or if there are no microservice dependencies, the correction factor C is set to 0, and so on.

[0171] In this embodiment, the current load score of the microservice corresponding to the target business process consists of three parts: a basic metric value (i.e., an application layer metric value), a weighting coefficient, and a correction factor. The decision engine 102 uses these three factors to determine the current load score, ensuring that the current load score adapts to the business characteristics of the business process and meets performance requirements.

[0172] After obtaining the current load score, the decision engine 102 determines whether to trigger the scaling up / down process of the first microservice based on the current load score and the scaling up / down strategy, and generates scaling up / down instructions if the scaling up / down process is triggered. The scaling up / down process includes scaling up and scaling down, and the scaling up / down instructions include scaling up instructions and scaling down instructions.

[0173] In this embodiment of the application, the decision engine 102 generates scaling instructions in the following two ways.

[0174] Scenario 1: Microservices do not overlap.

[0175] In Case 1, the target business process is only one, and the first microservice is associated with only one business process, meaning the first microservice is called by only one business process. In this case, the decision engine 102 can specifically be used to: if the current load score is greater than a first preset load threshold, or if the current load score is less than a second preset load threshold, then calculate the first expected number of replicas of the first microservice using a linear algorithm based on the current load score and the target load score.

[0176] In this embodiment, the decision engine 102 compares the current load score, the first preset load threshold, and the second preset load threshold. If the current load score is greater than the first preset load threshold, it indicates that the first microservice meets the scaling conditions and triggers the scaling process. That is, the decision engine 102 can calculate the first expected number of replicas of the first microservice based on the current load score and the target load score using the linear algorithm shown in formula (3).

[0177] If the current load score is less than the second preset load threshold, it means that the first microservice meets the scaling-down condition and triggers the scaling-down process. That is, the decision engine 102 can use the linear algorithm shown in formula (3) to calculate the first expected number of replicas of the first microservice based on the current load score and the target load score.

[0178]

[0179] In formula (3), Q0 represents the first expected number of replicas, Q1 represents the current number of replicas, LS1 represents the current load score or total load score, and LS0 represents the target load score. This indicates the rounding up algorithm.

[0180] The expansion and reduction processes are explained below.

[0181] 1) Capacity expansion processing.

[0182] In some embodiments, when the current load score is greater than a first preset load threshold, the decision engine 102 can generate a scaling instruction carrying a first desired number of replicas, and then send the scaling instruction to the interface server 103. The interface server 103, according to the scaling instruction, scales the number of replicas of the first microservice to the first desired number of replicas.

[0183] In some embodiments, the target business process may also be associated with other microservices besides the first microservice, such as a second microservice. The number of other microservices can be one or more. When the current load score is greater than a first preset load threshold, the decision engine 102 can specifically be used to: determine the second expected number of replicas of the other microservices associated with the target business process based on the proportional relationship between the microservices associated with the target business process and the first expected number of replicas; and generate a scaling instruction carrying the first expected number of replicas and the second expected number of replicas.

[0184] In this embodiment, the ratio between the first expected number of replicas and the second expected number of replicas is the same as the ratio between the first microservice and other microservices.

[0185] When the container orchestration management system has sufficient resources, the decision engine 102 sends a scaling instruction carrying the first desired number of replicas and the second desired number of replicas to the interface server 103. Based on this scaling instruction, the interface server 103 can scale up the number of replicas of the first microservice to the first desired number, and scale up the number of replicas of other microservices (such as the second microservice) to the second desired number, thus maintaining a dynamic proportional relationship among the microservices associated with the target business process. This multi-microservice coordination mechanism avoids imbalances in the collaboration of microservices associated with the business process, and solves the problem of bottleneck microservices appearing due to the disruption of the dynamic proportional relationship between microservices, thus dragging down overall performance and wasting resources.

[0186] In some embodiments, when the container orchestration management system is under resource constraints—that is, when the available resources of the container orchestration management system are less than the second required resources corresponding to the second total expected number of replicas—the second total expected number of replicas is the sum of the first expected number of replicas and the second expected number of replicas of other microservices associated with the target business process. The decision engine 102 can generate a scaling instruction in any of the following ways: The second required resources are the resources required for the operation of the microservices with the first expected number of replicas and the other microservices with the second expected number of replicas.

[0187] In Method 1, the decision engine 102 can determine the expected number of replicas 1 for the first microservice and the expected number of replicas 2 for other microservices associated with the target business process based on the proportional relationship between the first microservice and other microservices associated with the target business process, as well as the available resources of the container orchestration management system. The proportional relationship between the expected number of replicas 1 and the expected number of replicas 2 satisfies the proportional relationship between the first microservice and other microservices associated with the target business process. An expansion instruction carrying the expected number of replicas 1 and the expected number of replicas 2 is generated. The target business process can be associated with multiple other microservices, and each other microservice corresponds to one expected number of replicas 2.

[0188] At this time, according to the expansion instruction, the interface server 103 can expand the number of replicas of the first microservice to the desired number of replicas 1, and expand the number of replicas of other microservices associated with the target business process to the desired number of replicas 2, so that the microservices associated with the target business process maintain a dynamic proportional relationship.

[0189] In method 2, decision engine 102 can compare available resources with the fourth required resource corresponding to the first expected number of replicas. The fourth required resource is the resource required for the first microservice to run with the first expected number of replicas.

[0190] If the available resources are greater than or equal to the fourth required resource, the decision engine 102 can calculate the difference between the available resources and the fourth required resource to obtain the first remaining resource. Based on the first remaining resource, it determines the sixth expected replica number of other microservices associated with the target business process, where the required resource corresponding to the sixth expected replica number is less than or equal to the first remaining resource. It then generates an expansion instruction carrying the first expected replica number and the sixth expected replica number. At this time, the interface server 103, based on this expansion instruction, can expand the replica number of the first microservice to the first expected replica number and expand the replica number of other microservices associated with the target business process to the sixth expected replica number.

[0191] If the available resources are less than the fourth required resource corresponding to the first expected number of replicas, the decision engine 102 can determine the seventh expected number of replicas for the first microservice based on the available resources, where the required resource corresponding to the seventh expected number of replicas is less than or equal to the available resources; and generate an expansion instruction carrying the seventh expected number of replicas. At this time, the interface server 103 can expand the number of replicas of the first microservice to the seventh expected number of replicas according to the expansion instruction, without expanding the number of replicas of other microservices associated with the target business process.

[0192] In this embodiment of the application, when the container orchestration management system is under resource constraints, the decision engine 102 prioritizes ensuring the performance of microservices with excessive load, thereby avoiding the problem of dragging down the overall system performance due to excessive load of a certain microservice.

[0193] 2) Volume reduction treatment.

[0194] In some embodiments, when the current load score is less than a second preset load threshold, the decision engine 102 can generate a scaling-down instruction carrying a first desired number of replicas, and then send the scaling-down instruction to the interface server 103. The interface server 103 then scales down the number of replicas of the first microservice to the first desired number of replicas according to the scaling-down instruction.

[0195] In some embodiments, the target business process may also be associated with other microservices besides the first microservice, such as a second microservice. The number of other microservices can be one or more. When the current load score is less than a second preset load threshold, the decision engine 102 may be specifically used to: determine the second expected number of replicas of other microservices associated with the target business process based on the proportional relationship between the microservices associated with the target business process and the first expected number of replicas; and generate a scaling-down instruction carrying the first expected number of replicas and the second expected number of replicas.

[0196] In this embodiment, the ratio between the first expected number of replicas and the second expected number of replicas is the same as the ratio between the first microservice and other microservices.

[0197] The decision engine 102 sends a scaling-down instruction carrying the first desired number of replicas and the second desired number of replicas to the interface server 103. Based on this scaling-down instruction, the interface server 103 can scale down the number of replicas of the first microservice to the first desired number, and scale down the number of replicas of other microservices associated with the target business process to the second desired number, thus maintaining a dynamic proportional relationship among the microservices associated with the target business process. This multi-microservice coordination mechanism avoids imbalances in the collaboration of microservices associated with the business process, and solves the problem of bottleneck microservices appearing due to the disruption of the dynamic proportional relationship between microservices, thus dragging down overall performance and wasting resources.

[0198] Scenario 2: Microservice overlap.

[0199] In scenario 2, there are multiple target business processes, such as the first business process and the second business process being target business processes, and the first microservice being shared by multiple target business processes.

[0200] In this case, the decision engine 102 can be used to: use the weight coefficient of each target business process to perform weighted summation on the current load scores corresponding to multiple target business processes to obtain the total load score; if the total load score is greater than the first preset load threshold, or if the total load score is less than the second preset load threshold, then use a linear algorithm to calculate the first expected number of replicas of the first microservice based on the total load score and the target load score.

[0201] In this embodiment of the application, the container orchestration management system pre-configures the weight coefficient of each target business process relative to the first microservice, that is, the weight coefficient of each target business process.

[0202] The decision engine 102 can use the following formula (4) to determine the total load score of the microservice.

[0203]

[0204] In formula (4), TotalLoadScore i LoadScore represents the total load score of microservice i. j w represents the current load score of microservice i corresponding to business process j. j represents the weight coefficient of business process j, and n represents the number of business processes in shared microservice i.

[0205] After obtaining the total load score of the first microservice, the decision engine 102 compares the total load score with the first preset load threshold and the second preset load threshold. If the total load score is greater than the first preset load threshold, it means that the first microservice meets the scaling conditions and triggers the scaling process. That is, the decision engine 102 can calculate the first expected number of replicas of the first microservice based on the total load score and the target load score using the linear algorithm shown in formula (3).

[0206] If the total load score is less than the second preset load threshold, it means that the first microservice meets the scaling-down condition and triggers the scaling-down process. That is, the decision engine 102 can use the linear algorithm shown in formula (3) to calculate the first expected number of replicas of the first microservice based on the total load score and the target load score.

[0207] The expansion and reduction processes are explained below.

[0208] 1) Capacity expansion processing.

[0209] In some embodiments, when the total load score exceeds a first preset load threshold, the decision engine 102 can generate a scaling instruction carrying a first desired number of replicas, and then send the scaling instruction to the interface server 103. The interface server 103 then scales up the number of replicas of the first microservice to the first desired number of replicas according to the scaling instruction.

[0210] In some embodiments, each target business process may also be associated with other microservices besides the first microservice. For example, both the first and second business processes may be target business processes, the first business process may also include a second microservice, and the second business process may also include a third microservice. The number of other microservices associated with each target business process can be one or more. When the total load score exceeds a first preset load threshold, the decision engine 102 may specifically be used to: determine the second expected number of replicas of other microservices associated with each target business process based on the proportional relationship between the microservices associated with each target business process and the first expected number of replicas; and generate a scaling instruction based on the first expected number of replicas and the second expected number of replicas of other microservices associated with each target business process.

[0211] In this embodiment of the application, for each target business process, the ratio between the first expected number of replicas and the second expected number of replicas is the same as the ratio between the first microservice and other microservices.

[0212] When the container orchestration management system has sufficient resources (i.e., the available resources of the container orchestration management system are greater than or equal to the first required resources corresponding to the first total expected number of replicas), the decision engine 102 can specifically be used to generate scaling instructions carrying the first expected number of replicas and the total expected number of replicas. Specifically, the total expected number of replicas includes the number of second expected replicas of other microservices associated with each target business process, and the first required resources are the resources required for the operation of the first microservice (with the first expected number of replicas) and other microservices (with the total expected number of replicas) associated with multiple target business processes.

[0213] The decision engine 102 sends a scaling instruction carrying the first desired number of replicas and all second desired numbers of replicas to the interface server 103. Based on this scaling instruction, the interface server 103 can scale up the number of replicas of the first microservice to the first desired number, and scale up the number of replicas of other microservices associated with each target business process to the corresponding second desired number, thus maintaining a dynamic proportional relationship among the microservices associated with the target business process. This multi-microservice coordination mechanism avoids imbalances in the collaboration of microservices associated with business processes, and solves the problem of bottleneck microservices appearing due to the disruption of the dynamic proportional relationship between microservices, thus dragging down overall performance and wasting resources.

[0214] In some embodiments, when the container orchestration management system is under resource constraints, that is, when the available resources of the container orchestration management system are less than the first required resources corresponding to the first total expected number of replicas, the first total expected number of replicas is the sum of the first expected number of replicas and all the second expected number of replicas, the decision engine 102 can generate scaling instructions based on the priorities of multiple target business processes.

[0215] In this embodiment of the application, the decision engine 102 may generate expansion instructions in any of the following ways.

[0216] Method 1: The available resources of the container orchestration management system are less than the first required resources, and the available resources of the container orchestration management system are greater than or equal to the second required resources corresponding to the second total expected replica count. The second total expected replica count is the sum of the first expected replica count and the second expected replica counts of other microservices associated with the first target business process. The first target business process is the highest priority target business process among multiple target business processes, i.e., the second required resources are the resources required by the first target business process.

[0217] Decision engine 102 can add a first expected number of replicas and a second expected number of replicas of other microservices associated with the first target business process to the scaling instruction. The second total expected number of replicas is the sum of the first expected number of replicas and the second expected number of replicas of other microservices associated with the first target business process. The first target business process is the highest priority target business process among multiple target business processes.

[0218] The decision engine 102 can traverse other target business processes except the first target business process in order of priority from high to low, obtain the current business process, and update the available resources according to the expected number of replicas of each microservice included in the scaling instruction.

[0219] If the updated available resources are greater than or equal to the third required resources corresponding to the third total expected replica count, the decision engine 102 can add the second expected replica count of other microservices associated with the current business process to the scaling instruction, and the third total expected replica count is the sum of the second expected replica counts of other microservices associated with the current business process; if the updated available resources are less than the third required resources, the decision engine 102 can determine the replica count of other microservices associated with the current business process as the third expected replica count, and the required resources corresponding to the third expected replica count are less than or equal to the updated available resources, and add the third expected replica count to the scaling instruction.

[0220] In this embodiment of the application, updating the available resources according to the expected number of replicas of each microservice included in the expansion instruction can be understood as: determining the remaining available resources after expansion according to the expected number of replicas of each microservice included in the expansion instruction, where the remaining available resources are the updated available resources.

[0221] The decision engine 102 can generate a scaling instruction for each microservice associated with a target business process, and send the scaling instruction to the interface server 103. In this way, the interface server 103 can receive multiple scaling instructions. Alternatively, the decision engine 102 can generate a scaling instruction that, after traversing all target business processes, includes a first expected number of replicas and a second expected number of replicas for other microservices associated with all target business processes. The decision engine 102 sends this scaling instruction to the interface server 103, so that the interface server 103 can receive a single scaling instruction.

[0222] According to the received expansion instruction, the interface server 103 can expand the number of replicas of the first microservice to the first expected number of replicas, and expand the number of replicas of other microservices associated with each target business process to the corresponding second or third expected number of replicas, so that the microservices associated with the high-priority target business processes maintain a dynamic proportional relationship.

[0223] In this embodiment, the decision engine 102 can also be used to process multiple target business processes using a resource-reducing processing method. Among the multiple target business processes, the reduction in resource usage for the first business process is greater than the reduction in resource usage for the second business process, and the priority of the first business process is lower than the priority of the second business process. This effectively reduces resource contention by low-priority business processes, ensuring the operation of high-priority business processes.

[0224] Method 2: Available resources are less than the second required resources corresponding to the second total expected number of replicas. Decision engine 102 can determine the fourth expected number of replicas of the first microservice and the fifth expected number of replicas of other microservices associated with the first target business process based on the proportional relationship between the microservices associated with the first target business process and the available resources of the container orchestration management system; the proportional relationship between the fourth expected number of replicas and the fifth expected number of replicas satisfies the proportional relationship between the first microservice and other microservices associated with the first target business process; and generate expansion instructions carrying the fourth expected number of replicas and the fifth expected number of replicas.

[0225] At this time, according to the received expansion instruction, the interface server 103 can expand the number of replicas of the first microservice to the fourth expected number of replicas, and expand the number of replicas of other microservices associated with the first target business process to the fifth expected number of replicas, so that the microservices associated with the first target business process maintain a dynamic proportional relationship.

[0226] Method 3: Available resources are less than the second required resources corresponding to the second total expected number of replicas. Decision engine 102 can compare available resources with the fourth required resources corresponding to the first expected number of replicas.

[0227] If the available resources are greater than or equal to the fourth required resources, the decision engine 102 can calculate the difference between the available resources and the fourth required resources to obtain the first remaining resources. Based on the first remaining resources, the sixth expected number of replicas of other microservices associated with the first target business process is determined, and the required resources corresponding to the sixth expected number of replicas are less than or equal to the first remaining resources. An expansion instruction carrying the first expected number of replicas and the sixth expected number of replicas is generated. At this time, the interface server 103 can expand the number of replicas of the first microservice to the first expected number of replicas and expand the number of replicas of other microservices associated with the first target business process to the sixth expected number of replicas according to the expansion instruction.

[0228] If the available resources are less than the fourth required resources, the decision engine 102 can determine the seventh expected number of replicas for the first microservice based on the available resources. The required resources corresponding to the seventh expected number of replicas are less than or equal to the available resources. A scaling instruction carrying the seventh expected number of replicas is then generated. At this time, the interface server 103 can scale up the number of replicas for the first microservice to the seventh expected number of replicas based on this scaling instruction, without scaling up the number of replicas for other microservices.

[0229] In this embodiment of the application, when the container orchestration management system is under resource constraints, the decision engine 102 prioritizes ensuring the microservices with excessive load and the microservices associated with high-priority business processes, thereby avoiding the problem of dragging down the overall system performance due to the excessive load of a certain microservice and solving the problem of low-priority business processes preempting the resources of high-priority business processes.

[0230] In this embodiment of the application, the decision engine 102 can also generate expansion instructions using method 4, as follows:

[0231] Method 4: Available resources are less than the resources required by the first requirement.

[0232] Decision engine 102 can determine the expected number X of each microservice associated with each target business process based on the proportional relationship between the microservices associated with each target business process and the available resources of the container orchestration management system. The proportional relationship of the expected number of each microservice associated with each target business process satisfies the proportional relationship between the microservices associated with each target business process, and the resource requirement corresponding to the sum of the expected number of each microservice associated with all target business processes is less than or equal to the available resource system. It then generates a scaling instruction carrying the expected number X of each microservice associated with each target business process.

[0233] In this embodiment, the decision engine 102 can also be used to process multiple target business processes using a resource-reducing processing method. Among the multiple target business processes, the reduction in resource usage for the first business process is greater than the reduction in resource usage for the second business process, and the priority of the first business process is lower than the priority of the second business process. This effectively reduces resource contention by low-priority business processes, ensuring the operation of high-priority business processes.

[0234] 2) Volume reduction treatment.

[0235] In some embodiments, when the total load score is less than a second preset load threshold, the decision engine 102 can generate a scaling-down instruction carrying a first desired number of replicas, and then send the scaling-down instruction to the interface server 103. The interface server 103 then scales down the number of replicas of the first microservice to the first desired number of replicas according to the scaling-down instruction.

[0236] In some embodiments, each target business process may also be associated with other microservices besides the first microservice, such as a second microservice. For each target business process, the number of other microservices can be one or more. When the total load score is less than a second preset load threshold, the decision engine 102 may specifically be used to: determine the second expected number of replicas of the other microservices associated with each target business process based on the proportional relationship between the microservices associated with each target business process and the first expected number of replicas; and generate a scaling instruction carrying the first expected number of replicas and the second expected number of replicas of the other microservices associated with each target business process.

[0237] In this embodiment of the application, for each target business process, the ratio between the first expected number of replicas and the second expected number of replicas is the same as the ratio between the first microservice and other microservices.

[0238] The decision engine 102 sends a scaling-down instruction carrying the first desired number of replicas and the second desired number of replicas to the interface server 103. Based on this scaling-down instruction, the interface server 103 can scale down the number of replicas of the first microservice to the first desired number, and scale down the number of replicas of other microservices associated with each target business process to the corresponding second desired number, thus maintaining a dynamic proportional relationship among the microservices associated with the target business process. This multi-microservice coordination mechanism avoids imbalances in the collaboration of microservices associated with business processes, and solves the problem of bottleneck microservices appearing due to the disruption of the dynamic proportional relationship between microservices, which drags down overall performance and wastes resources.

[0239] In this embodiment, the decision engine 102 can also obtain host-layer metric values ​​collected by the metric collection layer 101, and use the host-layer metric values ​​of each node to determine the available resources of the container orchestration management system. Based on the available resources of the container orchestration management system, the decision engine 102 can determine available nodes, and then use these available nodes to deploy replicas of microservices to complete the scaling process.

[0240] In this embodiment, the decision engine 102 can determine whether each microservice needs scaling up or down based on load scores and scaling strategies. Considering the dependencies and overlaps between microservices related to business processes, when cross-process resource conflicts occur (such as microservice overlap or resource scarcity), the engine coordinates between business processes based on their priority, resource allocation strategies according to the proportional relationship between microservices, and resource conflict algorithms, generating a final scaling up or down decision, such as the aforementioned scaling up or scaling down instruction. When generating scaling up or down instructions, the decision engine 102 considers the proportional relationship information between microservices, ensuring that the scaling up or down operations of each microservice related to the business process conform to the proportional relationship. The decision engine 102 can record each decision process and result for subsequent strategy optimization analysis.

[0241] The decision engine 102 can also perform pre-analysis of potential resource conflicts, such as analyzing the priority of two processes, the current resource status, and the business impact. If the current load score is less than the first load score threshold, a resource allocation plan is formulated, that is, the expected number of microservice replicas is determined.

[0242] (5) Interface server 103. Interface server 103 is used to execute scaling instructions.

[0243] In this embodiment, the interface server 103 can be a Kubernetes API Server. The decision engine 102 can send scaling instructions to the interface server 103 via an HTTP / 2 channel encrypted with Transport Layer Security (TLS). The scaling instructions can include information such as the microservice name, scaling type (scaling up / scaling down), and the desired number of replicas.

[0244] According to scaling instructions, interface server 103 can perform scaling operations on the corresponding microservice Deployments. By working in conjunction with the container orchestration mechanism, it enables dynamic adjustment of resources in the container orchestration management system. For example, in response to a scaling instruction, interface server 103 starts new replicas on available nodes in the container orchestration management system; in response to a scaling instruction, interface server 103 shuts down low-load replicas according to a policy. When executing scaling operations, interface server 103 strictly coordinates the number of replicas for each microservice according to the scaling requirements of the multiple microservices involved in the scaling instructions and their quantitative relationships, ensuring the consistency of the quantitative relationships of microservices associated with the business process.

[0245] After the scaling up and down operation is completed, the interface server 103 can send the operation results back to the decision engine 102 so that the decision engine 102 can perform subsequent processing.

[0246] In this embodiment of the application, the decision engine 102 can monitor the execution progress and results of scaling operations in real time.

[0247] If scaling down fails or times out, the decision engine 102 can resend the scaling down command to the interface server 103. If the scaling down fails for a preset number of consecutive times, the decision engine 102 can confirm the scaling down failure, log it, and notify the administrator.

[0248] If scaling down fails or times out, the decision engine 102 can adjust the scaling down command, i.e., adjust the scaling down strategy. The adjusted scaling down command can include only the expected replica data of each microservice associated with high-priority business processes, or only the expected replica data of microservices with high load, to achieve local adjustment and resolve anomalies caused by the adjustment of the number of microservices. For example, if a microservice cannot be scaled down according to the number of microservices due to resource limitations, the decision engine 102 can record detailed anomaly information to notify the administrator for handling.

[0249] For example, if the inventory query microservice cannot be scaled up according to the quantity relationship due to insufficient node resources, the decision engine 102 can try to temporarily adjust the scaling plan of the order creation microservice, or find available resources on other nodes to meet the scaling needs of the inventory query microservice, and record the abnormal situation so that the administrator can troubleshoot the problem later.

[0250] If scaling up or down fails or times out, the decision engine 102 can pause the operation, check the system, analyze the cause, and then retry to ensure that the dynamic adjustment of resources proceeds smoothly.

[0251] The technical solution provided in this application is a microservice scaling solution based on multiple business processes and considering the quantitative relationship between microservices, which has the following beneficial effects:

[0252] (a) Precise resource allocation;

[0253] 1. Define exclusive scaling strategies for each microservice role in each business process, fully considering the business characteristics and resource requirements of each business process, to achieve precise allocation of microservice resources.

[0254] 2. To address the different roles of microservices in different business processes, different scaling metrics (i.e., application layer metrics) and weighting systems are set to make resource allocation more aligned with actual business needs.

[0255] (ii) Effectively resolve resource competition;

[0256] 1. Considering the overlap of microservices related to multiple business processes, by setting the priority of resource requirements of business processes for overlapping microservices (i.e., the priority of business processes) and scaling strategies, the resource competition of different business processes for the same microservice can be effectively coordinated.

[0257] 2. Cross-process coordination mechanisms can make reasonable decisions quickly when resource conflicts occur, avoiding resource waste and unreasonable allocation.

[0258] (III) Ensuring a Balanced Microservice Collaboration;

[0259] 1. Considering the quantitative relationships (i.e., proportional relationships) between microservices related to business processes, the number of replicas of microservices is strictly adjusted according to these quantitative relationships during scaling up and down, ensuring a balanced collaboration among microservices. For example, in the order processing flow, the number of replicas (i.e., the number of instances) of the order creation microservice, inventory query microservice, and payment processing microservice is always kept in a reasonable ratio. This avoids processing bottlenecks or resource waste caused by too many or too few instances of a particular microservice, enabling the order processing flow to operate efficiently and stably.

[0260] 2. A scaling strategy based on the quantitative relationships between microservices related to business processes enhances the container orchestration management system's ability to cope with business fluctuations. Whether during peak or off-peak periods, it ensures that the collaborative work between microservices related to business processes remains unaffected, maintaining the stable performance of the container orchestration management system. For example, during major e-commerce promotions, order processing volumes surge. By scaling according to the quantitative relationships between microservices, order backlogs caused by insufficient processing capacity of a single microservice are effectively avoided, ensuring the smooth operation of the entire order processing flow.

[0261] (iv) Improve system performance and stability;

[0262] 1. The decision engine 102 can monitor the execution progress and results of scaling operations in real time and dynamically adjust scaling strategies. This mechanism can optimize resource allocation in a timely manner as business develops and system operating status changes, maintaining the high-performance operation of the container orchestration management system in different business scenarios.

[0263] Furthermore, by constructing a strategy effectiveness evaluation index system, collecting system operation data and business feedback, and analyzing the effectiveness of the current scaling-up and scaling-down strategies in real time, the strategies can be adjusted as needed. For example, resource utilization deviations exceeding a certain threshold or business processing latency reaching a specific percentage can be addressed. Adjustments can be made, for instance, by modifying the first load score threshold, second load score threshold, weighting coefficients, business process priorities, and the proportional relationship between microservices through the strategy configuration center's visual interface or API.

[0264] By leveraging the collaborative work of various modules within the container orchestration management system, dynamic updates to scaling strategies are achieved. For instance, the decision engine interacts with the strategy configuration center based on evaluation results to update the scaling strategies.

[0265] 2. Precise resource allocation, effective resource contention resolution mechanisms, and guarantees for the balance of microservice collaboration reduce system failures and processing delays caused by insufficient or unreasonable resource allocation, improve system stability and reliability, reduce the risk of business interruption, and ensure business continuity.

[0266] (v) Good scalability;

[0267] The technical solution provided in this application can easily adapt to the addition and changes of the core processing flow of the system. When a new business process is added to the container orchestration management system, it is only necessary to use the system architecture document, business requirement description and other materials in the process analysis module to sort out the microservices and microservice roles involved in the business process, and then configure the corresponding scaling strategy for it in the policy configuration center according to its business characteristics, using the predefined data analysis model and policy configuration interface. The new process can be seamlessly integrated into the resource management system of the container orchestration management system without large-scale changes to the overall container orchestration management architecture.

[0268] Corresponding to the above-described container orchestration management system embodiments, this application also provides a microservice scaling method, such as... Figure 5 As shown, applied to a container orchestration management system, the method includes:

[0269] Step S501: Obtain multiple application layer metric values ​​of the first microservice associated with the target business process;

[0270] Step S502: Using the weight coefficients of multiple application layer indicator values ​​of the first microservice corresponding to the target business process, perform weighted summation on the multiple application layer indicator values ​​to obtain the current load score of the first microservice corresponding to the target business process.

[0271] Step S503: Determine the first expected number of replicas for the first microservice based on the current load score;

[0272] Step S504: Perform scaling up or down processing based on the first expected number of replicas.

[0273] In some embodiments, step S502 may include:

[0274] By using the weight coefficients of multiple application layer metrics values ​​of the first microservice corresponding to the target business process, the multiple application layer metrics values ​​are weighted and summed to obtain the initial load score of the first microservice corresponding to the target business process.

[0275] The initial load score is corrected by using the correction factor of the first microservice corresponding to the target business process, so as to obtain the current load score of the first microservice corresponding to the target business process.

[0276] In some embodiments, the number of target business processes is multiple;

[0277] Step S503 above may include:

[0278] By using the weight coefficient of each target business process, the current load scores corresponding to multiple target business processes are weighted and summed to obtain the total load score;

[0279] If the total load score is greater than the first preset load threshold, or if the total load score is less than the second preset load threshold, then the first expected number of replicas of the first microservice is calculated using a linear algorithm based on the total load score and the target load score, where the first preset load threshold is greater than the second preset load threshold.

[0280] In some embodiments, each target business process is also associated with other microservices besides the first microservice;

[0281] Step S504 above may include:

[0282] Based on the proportional relationship between the microservices associated with each target business process and the first expected number of replicas, determine the second expected number of replicas of the other microservices associated with each target business process;

[0283] Scaling is performed based on the first expected number of replicas and the second expected number of replicas of other microservices associated with each target business process.

[0284] In some embodiments, if the total load score is greater than a first preset load threshold, the above-mentioned scaling up / down process based on the first expected number of replicas and the second expected number of replicas of other microservices associated with each target business process includes:

[0285] If the available resources of the container orchestration management system are greater than or equal to the first required resources corresponding to the first total expected number of replicas, then the number of replicas of the first microservice will be scaled up or down to the first expected number of replicas, and the number of replicas of other microservices associated with each target business process will be scaled up or down to the corresponding second expected number of replicas. The first total expected number of replicas is the sum of the first expected number of replicas and all the second expected number of replicas.

[0286] If the available resources are less than the resources required by the first target business process, the microservices associated with the multiple target business processes will be scaled up according to their priorities.

[0287] In some embodiments, the step of scaling up the microservices associated with multiple target business processes according to their priorities includes:

[0288] If the available resources are greater than or equal to the second required resources corresponding to the second total expected number of replicas, then the number of replicas of the first microservice is expanded to the first expected number of replicas, and the number of replicas of other microservices associated with the first target business process is expanded to the corresponding second expected number of replicas. The second total expected number of replicas is the sum of the first expected number of replicas and the second expected number of replicas of other microservices associated with the first target business process. The first target business process is the target business process with the highest priority among multiple target business processes.

[0289] According to the priority from high to low, traverse the other target business processes except the first target business process to obtain the current business process, and update the available resources according to the determined expected number of replicas of each microservice.

[0290] If the updated available resources are greater than or equal to the third required resources corresponding to the third total expected replica count, then the replica count of other microservices associated with the current business process will be expanded to the corresponding second expected replica count, and the third total expected replica count will be the sum of the second expected replica counts of other microservices associated with the current business process.

[0291] If the updated available resources are less than the third required resources, then based on the available resources, the number of replicas of other microservices associated with the current business process is determined to be the third expected replica number, and the required resources corresponding to the third expected replica number are less than or equal to the updated available resources; the number of replicas of other microservices associated with the current business process is expanded to the third expected replica number.

[0292] In some embodiments, the step of scaling up the microservices associated with multiple target business processes according to their priorities includes:

[0293] If the available resources are less than the second required resources corresponding to the second total expected number of replicas, where the second total expected number of replicas is the sum of the first expected number of replicas and the second expected number of replicas of other microservices associated with the first target business process, and the first target business process is the highest priority target business process among multiple target business processes, then scaling up or down will be performed using any of the following methods:

[0294] Method 1: Based on available resources, determine the fourth expected number of replicas of the first microservice and the fifth expected number of replicas of other microservices associated with the first target business process. The ratio of the fourth expected number of replicas to the fifth expected number of replicas satisfies the ratio between the first microservice associated with the first target business process and other microservices. Expand the number of replicas of the first microservice to the fourth expected number of replicas, and expand the number of replicas of other microservices associated with the first target business process to the fifth expected number of replicas.

[0295] Method 2: If the available resources are greater than or equal to the fourth required resources corresponding to the first expected number of replicas, then calculate the difference between the available resources and the fourth required resources to obtain the first remaining resources; based on the first remaining resources, determine the sixth expected number of replicas for other microservices associated with the first target business process, where the required resources corresponding to the sixth expected number of replicas are less than or equal to the first remaining resources; expand the number of replicas for the first microservice to the first expected number of replicas, and expand the number of replicas for other microservices associated with the first target business process to the sixth expected number of replicas.

[0296] If the available resources are less than the fourth required resources, then the seventh expected number of replicas of the first microservice is determined based on the available resources. The required resources corresponding to the seventh expected number of replicas are less than or equal to the available resources. The number of replicas of the first microservice is then increased to the seventh expected number of replicas.

[0297] In some embodiments, the above microservice scaling method may further include:

[0298] If the available resources are less than the resources required for the first target business process, then a resource reduction approach is adopted to process multiple target business processes. Among the multiple target business processes, the reduction in resource usage for the first business process is greater than the reduction in resource usage for the second business process, and the priority of the first business process is lower than that of the second business process.

[0299] In some embodiments, the number of target business processes is one;

[0300] Step S503 above may include:

[0301] If the current load score is greater than the first preset load threshold, or if the current load score is less than the second preset load threshold, then the first expected number of replicas of the first microservice is calculated using a linear algorithm based on the current load score and the target load score.

[0302] In some embodiments, the target business process is also associated with other microservices besides the first microservice;

[0303] Step S504 above may include:

[0304] Based on the proportional relationship between the microservices associated with the target business process and the first expected number of replicas, determine the second expected number of replicas for other microservices;

[0305] The number of replicas of the first microservice is scaled up or down to the first desired number of replicas, and the number of replicas of the other microservices is scaled up or down to the second desired number of replicas.

[0306] In some embodiments, the above microservice scaling method may further include:

[0307] Collect host-level metric values ​​for each node in the container orchestration management system;

[0308] By using the host-level metrics of each node, the available resources of the container orchestration management system can be determined.

[0309] In some embodiments, the above microservice scaling method may further include:

[0310] The scaling strategies for each business process are obtained through the human-computer interaction interface. The scaling strategies include the scaling configuration parameters for each microservice role in each business process.

[0311] Record the scaling strategies for each business process.

[0312] In some embodiments, the above microservice scaling method may further include:

[0313] Retrieve inter-service call data in the container orchestration management system;

[0314] Analyze the call data and microservice code to determine the basic process information of the container orchestration management system. The basic process information includes the candidate microservices associated with each business process and the dependencies between each candidate microservice.

[0315] The basic information of the process is displayed through a human-computer interaction interface, so that users can input the scaling strategies for each business process based on the basic information of the process.

[0316] In the technical solution provided in this application embodiment, the container orchestration management system configures corresponding weight coefficients for multiple application-layer metrics of different microservices associated with different business processes. Using the values ​​of these multiple application-layer metrics and their weight coefficients, the current load score of different microservices corresponding to different business processes is determined. Then, based on the current load score, the expected number of replicas of the microservices is determined for scaling up and down. In this solution, the application-layer metrics and weight coefficients can be configured according to the business characteristics of different business processes. Utilizing multiple application-layer metrics and weight coefficients adapted to the business characteristics of the business processes for scaling up and down overcomes the drawbacks of using a single metric threshold for scaling up and down, adapting to the business characteristics of different business processes, and thus improving the accuracy of resource allocation.

[0317] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements any of the microservice scaling methods described above.

[0318] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the microservice scaling methods described in the above embodiments.

[0319] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0320] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0321] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the method, medium, and program product embodiments are basically similar to the system embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the system embodiments.

[0322] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A method for scaling up and down microservices, characterized in that, Applied to a container orchestration management system, the method includes: Obtain multiple application-layer metric values ​​of the first microservice associated with the target business process; Using the weight coefficients of multiple application layer indicator values ​​of the first microservice corresponding to the target business process, the multiple application layer indicator values ​​are weighted and summed to obtain the current load score of the first microservice corresponding to the target business process. Based on the current load score, determine the first expected number of replicas for the first microservice; The capacity is adjusted based on the first desired number of replicas.

2. The method according to claim 1, characterized in that, The step of using the weight coefficients of multiple application layer metric values ​​of the first microservice corresponding to the target business process to perform weighted summation of the multiple application layer metric values ​​to obtain the current load score of the first microservice corresponding to the target business process includes: Using the weight coefficients of multiple application layer indicator values ​​of the first microservice corresponding to the target business process, the multiple application layer indicator values ​​are weighted and summed to obtain the initial load score of the first microservice corresponding to the target business process. The initial load score is corrected by using the correction factor of the first microservice corresponding to the target business process to obtain the current load score of the first microservice corresponding to the target business process.

3. The method according to claim 1, characterized in that, The number of the target business processes is multiple; The step of determining the first expected number of replicas of the first microservice based on the current load score includes: By using the weight coefficient of each target business process, the current load scores corresponding to multiple target business processes are weighted and summed to obtain the total load score; If the total load score is greater than the first preset load threshold, or if the total load score is less than the second preset load threshold, then the first expected number of replicas of the first microservice is calculated using a linear algorithm based on the total load score and the target load score, wherein the first preset load threshold is greater than the second preset load threshold.

4. The method according to claim 3, characterized in that, Each target business process is also associated with other microservices besides the first microservice; The step of scaling up or down the first microservice according to the first expected number of replicas includes: Based on the proportional relationship between the microservices associated with each target business process and the first expected number of replicas, determine the second expected number of replicas of other microservices associated with each target business process; Scaling is performed based on the first expected number of replicas and the second expected number of replicas of other microservices associated with each target business process.

5. The method according to claim 4, characterized in that, If the total load score is greater than the first preset load threshold, then the step of scaling up or down based on the first expected number of replicas and the second expected number of replicas of other microservices associated with each target business process includes: If the available resources of the container orchestration management system are greater than or equal to the first demand resources corresponding to the first total expected number of replicas, then the number of replicas of the first microservice is scaled up or down to the first expected number of replicas, and the number of replicas of other microservices associated with each target business process is scaled up or down to the corresponding second expected number of replicas. The first total expected number of replicas is the sum of the first expected number of replicas and all the second expected number of replicas. If the available resources are less than the first required resources, then the microservices associated with the multiple target business processes are scaled up according to their priorities.

6. The method according to claim 5, characterized in that, The step of scaling up the microservices associated with the multiple target business processes according to their priorities includes: If the available resources are greater than or equal to the second required resources corresponding to the second total expected number of replicas, then the number of replicas of the first microservice is expanded to the first expected number of replicas, and the number of replicas of other microservices associated with the first target business process is expanded to the corresponding second expected number of replicas. The second total expected number of replicas is the sum of the first expected number of replicas and the second expected number of replicas of other microservices associated with the first target business process. The first target business process is the target business process with the highest priority among the plurality of target business processes. According to the priority from high to low, traverse the other target business processes except the first target business process to obtain the current business process, and update the available resources according to the determined expected number of replicas of each microservice. If the updated available resources are greater than or equal to the third required resources corresponding to the third total expected replica count, then the replica count of other microservices associated with the current business process will be expanded to the corresponding second expected replica count, and the third total expected replica count is the sum of the second expected replica counts of other microservices associated with the current business process. If the updated available resources are less than the third required resources, then based on the available resources, the number of replicas of other microservices associated with the current business process is determined as the third expected number of replicas, and the required resources corresponding to the third expected number of replicas are less than or equal to the updated available resources; the number of replicas of other microservices associated with the current business process is expanded to the third expected number of replicas.

7. The method according to claim 5, characterized in that, The step of scaling up the microservices associated with the multiple target business processes according to their priorities includes: If the available resources are less than the second required resources corresponding to the second total expected replica count, where the second total expected replica count is the sum of the first expected replica count and the second expected replica counts of other microservices associated with the first target business process, and the first target business process is the highest priority target business process among the plurality of target business processes, then scaling up or down is performed using any of the following methods: Method 1: Based on the available resources, determine the fourth expected number of replicas of the first microservice and the fifth expected number of replicas of other microservices associated with the first target business process. The ratio of the fourth expected number of replicas to the fifth expected number of replicas satisfies the ratio between the first microservice and other microservices associated with the first target business process. Expand the number of replicas of the first microservice to the fourth expected number of replicas, and expand the number of replicas of other microservices associated with the first target business process to the fifth expected number of replicas. Method 2: If the available resources are greater than or equal to the fourth required resources corresponding to the first expected number of replicas, then calculate the difference between the available resources and the fourth required resources to obtain the first remaining resources; based on the first remaining resources, determine the sixth expected number of replicas for other microservices associated with the first target business process, wherein the required resources corresponding to the sixth expected number of replicas are less than or equal to the first remaining resources; expand the number of replicas for the first microservice to the first expected number of replicas, and expand the number of replicas for other microservices associated with the first target business process to the sixth expected number of replicas; If the available resources are less than the fourth required resources, then the seventh expected number of replicas of the first microservice is determined based on the available resources, wherein the required resources corresponding to the seventh expected number of replicas are less than or equal to the available resources; and the number of replicas of the first microservice is increased to the seventh expected number of replicas.

8. The method according to claim 5, characterized in that, The method further includes: If the available resources are less than the first required resources, then a resource reduction processing method is adopted to process multiple target business processes. Among the multiple target business processes, the reduction in resource usage of the first business process is greater than the reduction in resource usage of the second business process, and the priority of the first business process is lower than that of the second business process.

9. The method according to claim 1, wherein the target business process is further connected with other microservices besides the first microservice; The step of scaling up or down the first microservice according to the first expected number of replicas includes: Based on the proportional relationship between the microservices associated with the target business process and the first expected number of replicas, determine the second expected number of replicas for the other microservices; The number of replicas of the first microservice is scaled up or down to the first desired number of replicas, and the number of replicas of the other microservices is scaled up or down to the second desired number of replicas.

10. The method according to any one of claims 5-9, characterized in that, The method further includes: Collect host-level index values ​​for each node in the container orchestration and management system; The available resources of the container orchestration and management system are determined by using the host-level index values ​​of each node.

11. The method according to any one of claims 1-9, characterized in that, The method further includes: The scaling strategies for each business process are obtained through the human-computer interaction interface, and the scaling strategies include the scaling configuration parameters for each microservice role in each business process. Record the scaling strategies for each business process.

12. The method according to claim 11, characterized in that, The method further includes: Obtain inter-service call data in the container orchestration and management system; The call data and microservice code are analyzed to determine the basic process information of the container orchestration management system. The basic process information includes the candidate microservices associated with each business process and the dependencies between each candidate microservice. The basic information of the process is displayed through the human-computer interaction interface, so that users can input the scaling strategies of each business process based on the basic information of the process.

13. A container orchestration management system, characterized in that, The container orchestration and management system includes an indicator collection layer, a decision engine, and an interface server; The indicator collection layer is used to collect multiple application layer indicator values ​​of the first microservice associated with the target business process. The decision engine is used to perform a weighted summation of the multiple application layer indicator values ​​of the first microservice corresponding to the target business process by using the weight coefficients of the multiple application layer indicator values ​​of the first microservice corresponding to the target business process, so as to obtain the current load score of the first microservice corresponding to the target business process. Determine the first expected number of replicas of the first microservice based on the current load score; generate a scaling up / down instruction based on the first expected number of replicas, and send the scaling up / down instruction to the interface server; The interface server is used to perform scaling up or down processing based on the number of microservice replicas in the scaling up / down instruction.

Images