Configuration parameter optimization method and device based on micro-service architecture, computer equipment, readable storage medium and program product

Abstract

The invention relates to a configuration parameter optimization method and device based on a micro-service architecture, computer equipment, a readable storage medium and a program product. The method comprises the steps of obtaining calling link data of a to-be-optimized micro-service application in a micro-service architecture, determining a key path based on the calling link data, determining a key service which has the greatest influence on the overall performance from the key path, and further optimizing the overall performance of the to-be-optimized micro-service application through a Bayesian optimization algorithm. The multiple configuration parameters of the key service in the to-be-optimized micro-service application are subjected to collaborative optimization to determine the target values of the multiple configuration parameters, so that the multiple configuration parameters in the micro-service architecture are automatically adjusted, manual intervention is reduced, the optimization efficiency is improved, and the optimization efficiency is improved through the multi-parameter collaborative optimization mode. The optimal configuration can be found among multiple parameters, so that the overall performance is improved.

Description

Technical Field

[0001] The present application relates to the field of microservice technology, and in particular to a configuration parameter optimization method, apparatus, computer equipment, readable storage medium, and program product based on a microservice architecture. Background Art

[0002] With the widespread adoption of cloud computing and microservices architecture, more and more enterprises are migrating their businesses to cloud-native environments. Cloud-native microservices architectures are characterized by service decomposition and modularization, enabling flexible deployment and scaling of applications through containerization and orchestration technologies. The independence and elasticity of microservices enable the system to quickly respond to changing requirements while facilitating fault isolation and maintenance. In a cloud-native environment, microservices typically consist of front-end services, business logic services, and data storage services. Each service runs in an independent container and interacts through an API (Application Programming Interface). While this architecture offers high availability and scalability, it also introduces complex configuration management issues. Parameter settings for different microservices (such as thread pool size and cache configuration) can significantly impact application performance.

[0003] Traditionally, resource configuration and parameter adjustment for microservice applications have relied on empirical experience or simple automated strategies. While these methods can improve the performance of individual services, they are unable to effectively optimize multiple service parameters across the entire microservice architecture. This optimization process is particularly time-consuming and inefficient when faced with large-scale systems and complex application scenarios. Summary of the Invention

[0004] Based on this, it is necessary to provide a configuration parameter optimization method, device, computer equipment, readable storage medium and program product based on a microservice architecture that can collaboratively optimize multiple configurations to address the above technical problems.

[0005] In a first aspect, the present application provides a configuration parameter optimization method based on a microservice architecture, the method comprising:

[0006] Obtain call link data of the microservice application to be optimized in the microservice architecture, and determine a critical path based on the call link data, where the critical path is a call link path with the longest service delay in the call link data;

[0007] Determine a key service on the critical path, where the key service is the service on the critical path that has the greatest impact on the overall performance of the microservice application to be optimized;

[0008] By using a Bayesian optimization algorithm, multiple configuration parameters of the key service in the microservice application to be optimized are collaboratively optimized to determine target values of the multiple configuration parameters of the key service in the microservice application to be optimized.

[0009] In one embodiment, obtaining call link data of the microservice application to be optimized and determining the critical path based on the call link data includes:

[0010] Obtain the call relationships between services in the microservice application to be optimized, as well as the response times corresponding to the call relationships;

[0011] Generate a call link graph based on the call relationships between services and the corresponding response times. The call link graph includes nodes and edges. Each node represents a service, and each edge represents the call relationship between corresponding services. The edges have corresponding weights, which are used to represent the response time of the corresponding call relationship.

[0012] Based on the call link graph, a call link path with the longest service delay in the call link graph is identified, and the call link path with the longest service delay is determined as the critical path.

[0013] In one embodiment, identifying, based on the call link graph, a call link path with the longest service delay in the call link graph includes:

[0014] Traversing the call link graph to obtain all call link paths in the call link graph;

[0015] For each of the call link paths, accumulating the weights of the corresponding edges in the call link path to determine the path delay duration corresponding to the call link path;

[0016] Based on the path delay duration corresponding to each of the call link paths, the call link path with the longest path delay duration is determined as the call link path with the longest service delay in the call link graph.

[0017] In one embodiment, determining the critical service from the critical path includes:

[0018] For each service in the critical path, obtaining a correlation coefficient between a first delay of the service and a second delay of the critical path;

[0019] Determine a service in the critical path whose correlation coefficient is greater than a correlation coefficient threshold as a candidate service;

[0020] For the candidate service, obtaining a delay volatility index of the candidate service, where the delay volatility index is used to characterize a degree of dispersion of a delay distribution of the candidate service;

[0021] When it is determined that the delay volatility index of the candidate service is greater than a preset index threshold, the candidate service is determined as the key service.

[0022] In one embodiment, obtaining a delay volatility indicator of the candidate service for the candidate service includes:

[0023] For the candidate service, respectively obtain the P99 delay and P50 delay of the candidate service;

[0024] A ratio between the P99 delay and the P50 delay is calculated, and the ratio is determined as a delay fluctuation indicator of the candidate service.

[0025] In one embodiment, obtaining, for each service in the critical path, a correlation coefficient between the first delay of the service and the second delay of the critical path includes:

[0026] Obtaining a historical delay data sequence of each service in the critical path and a path delay sequence corresponding to the critical path;

[0027] According to the historical delay data sequence of each service and the path delay sequence of the corresponding critical path, based on the Pearson correlation statistical method, the correlation coefficient between the first delay of each service and the second delay of the critical path is obtained.

[0028] In a second aspect, the present application provides a configuration parameter optimization device based on a microservice architecture, the device comprising:

[0029] A critical path determination module is configured to obtain call link data of the microservice application to be optimized in the microservice architecture, and determine a critical path based on the call link data, where the critical path is the call link path with the longest service delay in the call link data;

[0030] A key service determination module is used to determine a key service from the key path, where the key service is the service on the key path that has the greatest impact on the overall performance of the microservice application to be optimized;

[0031] The optimization module is used to collaboratively optimize multiple configuration parameters of the key service in the microservice application to be optimized through a Bayesian optimization algorithm to determine target values of the multiple configuration parameters of the key service in the microservice application to be optimized.

[0032] In a third aspect, the present application provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the above method when executing the computer program.

[0033] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of the above method when executed by a processor.

[0034] In a fifth aspect, the present application provides a computer program product, comprising a computer program, which implements the steps of the above method when executed by a processor.

[0035] The above-mentioned configuration parameter optimization method, device, computer equipment, computer-readable storage medium and computer program product based on the microservice architecture obtain the call link data of the microservice application to be optimized in the microservice architecture, determine the critical path based on the call link data, and determine the key service with the greatest impact on the overall performance from the critical path. Then, through the Bayesian optimization algorithm, the multiple configuration parameters of the key services in the microservice application to be optimized are collaboratively optimized to determine the target values of the multiple configuration parameters, thereby realizing automatic adjustment of multiple configuration parameters in the microservice architecture, which not only reduces manual intervention and improves optimization efficiency, but also finds the optimal configuration among multiple parameters through multi-parameter collaborative optimization, thereby improving overall performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments of the present application or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying any creative work.

[0037] Figure 1 Schematic diagram of a process for optimizing configuration parameters based on a microservice architecture in one embodiment;

[0038] Figure 2 A schematic diagram of a process for determining critical path steps in one embodiment;

[0039] Figure 3 A flowchart illustrating key service steps in one embodiment;

[0040] Figure 4 Schematic diagram of the process of Bayesian optimization step in one embodiment;

[0041] Figure 5 This is a structural block diagram of a configuration parameter optimization device based on a microservice architecture in one embodiment;

[0042] Figure 6 FIG. 1 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0043] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0044] Although manual parameter tuning based on experience or simple automation strategies can improve the performance of microservice applications to a certain extent, they still face some challenges and shortcomings in actual applications. Specifically, they are as follows:

[0045] (1) Lack of dynamic adjustment capabilities: Traditional optimization methods rely on offline data for configuration adjustments and lack the ability to respond to real-time load and system state changes. In real-world environments, the load of microservices may fluctuate dramatically, and static optimization cannot cope with such real-time changes.

[0046] (2) Complex parameter dependencies: Due to the complex dependencies between multiple services in a microservice architecture, for example, changes in certain parameters may affect the performance of other services. Traditional methods often fail to fully consider the mutual impact between different services when dealing with such complex cross-service and cross-parameter dependencies, resulting in optimization results that fail to achieve the expected results.

[0047] (3) High-dimensional search space: With the increase in the number of microservices and the number of adjustable parameters, the search space for parameter configuration becomes extremely large. Traditional optimization methods have difficulty effectively searching such a complex high-dimensional space within a limited time. This may result in a large number of redundant calculations and experiments, resulting in an inefficient optimization process. Especially in a production environment, a long tuning process may affect the stability and availability of the application.

[0048] Based on this, the present application provides a configuration parameter optimization method based on a microservice architecture, which determines the critical path based on the call link data of the microservice application to be optimized in the microservice architecture, and determines the key services from the critical path. By introducing the Bayesian optimization algorithm, multiple configuration parameters of the key services are collaboratively optimized to achieve automatic adjustment of the configuration of multiple configuration parameters in the microservice application, which not only reduces manual intervention but also achieves the best application performance.

[0049] In one embodiment, Figure 1 As shown, a configuration parameter optimization method based on a microservice architecture is provided, which may include the following steps:

[0050] Step 102: Obtain call link data of the microservice application to be optimized in the microservice architecture, and determine the critical path based on the call link data.

[0051] The microservice application to be optimized can be an application in a microservices architecture that requires parameter optimization. In a microservices architecture, a microservice application typically consists of multiple services, including front-end services, business logic services, and data storage services. These services have complex call dependencies, and each service may be called as part of a request. Therefore, a performance bottleneck in a service not only affects the service itself but can also have a knock-on effect on other closely dependent services. Optimizing microservices applications isn't limited to improving the performance of a single service; it also needs to consider the interactions between different services.

[0052] In a microservices architecture, services communicate through call chains, typically completed through API requests. The critical path refers to the service path with the longest response time during the entire request processing process. This refers to the call chain path with the longest service latency as shown in the call chain data. Each service on the critical path impacts the response time of the entire request and the overall performance of the system. A failure or performance bottleneck in any service will directly increase the latency of the entire request, impacting the user experience.

[0053] Therefore, in this embodiment, the call link data of the microservice application to be optimized in the microservice architecture can be obtained by analyzing the call relationship between services, and the critical path can be determined based on the call link data, that is, the path with the greatest impact on system performance can be identified, so as to improve the overall application performance of the microservice application by optimizing the configuration parameters of the services on the critical path.

[0054] Step 104: Determine the key services from the critical path.

[0055] Key services are the services on the critical path that have the greatest impact on the overall performance of the microservice application being optimized. These services are also the service nodes on the critical path that have the greatest impact on overall performance. The performance of a particular call link in a microservice application depends crucially on the services with the worst performance and the most instability on that link. Therefore, further analysis of the services on the critical path is necessary to identify the key services that determine microservice application performance and optimize them to improve the overall performance of the microservice application.

[0056] Step 106 , collaboratively optimize multiple configuration parameters of key services in the microservice application to be optimized using a Bayesian optimization algorithm to determine target values of the multiple configuration parameters.

[0057] Typically, a service has multiple adjustable parameters, also known as configuration parameters (such as thread pool size and cache configuration). Different configurations of these parameters will directly affect the overall performance of the system. Therefore, the goal of microservice application performance evaluation is to find the optimal configuration by testing different parameter configurations, thereby achieving optimal application performance.

[0058] Based on this, in this embodiment, the Bayesian optimization algorithm can be used to collaboratively optimize multiple configuration parameters of key services in the microservice application to be optimized, thereby determining the target values of multiple configuration parameters of key services in the microservice application to be optimized, so as to automatically adjust multiple configuration parameters in the microservice architecture.

[0059] In the above-mentioned configuration parameter optimization method based on microservice architecture, the call link data of the microservice application to be optimized in the microservice architecture is obtained, the critical path is determined based on the call link data, and the key service with the greatest impact on the overall performance is determined from the critical path. Then, through the Bayesian optimization algorithm, multiple configuration parameters of the key service in the microservice application to be optimized are collaboratively optimized to determine the target values of multiple configuration parameters, thereby realizing automatic adjustment of multiple configuration parameters in the microservice architecture. This not only reduces manual intervention and improves optimization efficiency, but also finds the optimal configuration among multiple parameters through multi-parameter collaborative optimization, thereby improving overall performance.

[0060] In an exemplary embodiment, Figure 2 As shown, in step 102, the call link data of the microservice application to be optimized in the microservice architecture is obtained, and the critical path is determined based on the call link data, which may specifically include:

[0061] Step 202: Obtain the call relationships between services in the microservice application to be optimized, and the response times corresponding to the call relationships.

[0062] Since different services in a microservice architecture have complex call dependencies, and each service may be called as part of a request, the first step in critical path identification is to collect call link data for the microservice application. Specifically, the call relationships between the services in the microservice application to be optimized, as well as the response times corresponding to the call relationships, can be obtained. For example, a distributed link tracking tool (such as Jaeger) can be used to record the flow of each request and the response time of each service, so that the call relationships and corresponding response times between the services in the microservice application can be accurately tracked, that is, call link data can be collected.

[0063] Step 204: Generate a call chain graph based on the call relationship between the services and the corresponding response time.

[0064] The call link graph includes nodes and edges. Each node represents a service, and each edge represents the call relationship between corresponding services. The edge has a corresponding weight, which is used to represent the response time of the corresponding call relationship.

[0065] In this embodiment, a call chain graph can be constructed based on the call chain data collected in the above steps, namely the call relationships between services in a microservice application and the corresponding response times. For example, if service A calls service B, service A and service B are nodes in the graph, and there is an edge between service A and service B. The weight of this edge is the response time from service A to service B.

[0066] Step 206: Based on the call link graph, identify the call link path with the longest service delay in the call link graph, and determine the call link path with the longest service delay as the critical path.

[0067] Service latency refers to the sum of the response times of all services along the call path, or in other words, the sum of the weights of the edges along the call path. A call path is the series of service calls a request undergoes from initiation to completion. In a microservices architecture, a microservice application is split into multiple small, independent services, each implementing specific business functionality. When a user request reaches the system, it may be passed between multiple services, and each service may call other services to complete its functionality.

[0068] For example, in this embodiment, the call link graph can be traversed to obtain all possible call link paths in the call link graph. The path delay duration of each call link path is then calculated. For example, for each call link path, the weights of the corresponding edges in the path can be accumulated to obtain the path delay duration corresponding to the call link path. Based on the path delay duration corresponding to each call link path, the call link path with the longest path delay duration is selected as the critical path.

[0069] In the above embodiment, the call relationships between services in the microservice application to be optimized, as well as the corresponding response times, are obtained. A call chain graph is then generated based on the call relationships and response times between the services. Based on the call chain graph, the call chain path with the longest service delay in the call chain graph is identified and designated as the critical path. By employing a weighted longest path algorithm, the call chain in the microservice architecture is analyzed to identify the critical path with the greatest performance impact, thereby optimizing performance bottlenecks and improving overall response speed.

[0070] In an exemplary embodiment, Figure 3 As shown, in step 104, key services are determined from the critical path, which may specifically include:

[0071] Step 302: For each service in the critical path, obtain a correlation coefficient between a first delay of the service and a second delay of the critical path.

[0072] Because the performance of a particular call path in a microservice application depends critically on the service with the worst performance and the most instability along that path, further analysis of the services along the critical path is necessary to identify the key services that determine the performance of the microservice application and optimize them to improve the overall performance of the microservice application.

[0073] Based on this, in this embodiment, the contribution of each service's performance change in the critical path to the overall path delay can be quantified. For example, this embodiment can use the Pearson Correlation Coefficient (PCC) for measurement. That is, for each service in the critical path, the correlation coefficient (PCC) between the first delay of the service and the second delay of the critical path can be obtained.

[0074] Specifically, the historical delay data sequence of each service in the critical path and the path delay sequence of the corresponding critical path can be obtained; thus, based on the historical delay data sequence of each service and the path delay sequence of the corresponding critical path, the correlation coefficient between the first delay of each service and the second delay of the critical path is obtained based on the Pearson correlation statistical method.

[0075] In one scenario, to adapt to real-time load changes, the performance change of each service in the critical path and the contribution of the overall path delay to the performance change can be quantified based on the real-time load conditions. Multiple service delay measurements under different loads for each service in the critical path, as well as multiple path delay measurements of the corresponding critical path under the corresponding loads, can be obtained. Based on the multiple service delay measurements under different loads for each service and the multiple path delay measurements of the corresponding critical path, the correlation coefficient between the first delay of each service and the second delay of the critical path can be obtained based on the Pearson correlation statistical method.

[0076] For example, the PCC can be calculated using the following formula (1):

[0077]

[0078] Among them, l ni ∈l n , l ni =[l n1 ,l n2 ,...,l nk ] represents multiple service delay measurements of service node n under different loads.pi ∈L p , L pi =[L p1 ,L p2 ,...,L pk ] represents the multiple path delay measurement values of the critical path p in these requests, and k is the number of experiments. It represents the average value of multiple service delay measurements of service node n under different loads. It represents the average value of multiple path delay measurements of the critical path p in these requests.

[0079] PCC can reflect the linear correlation between the service node delay change and the total path delay change. The stronger the correlation, the more significant the impact of the node on the path performance.

[0080] Step 304 : Determine services in the critical path whose correlation coefficients are greater than a correlation coefficient threshold as candidate services.

[0081] Candidate services can be service nodes with a significant impact on the path, determined based on the PCC. Because the PCC reflects the linear correlation between the delay variation of a service node and the total delay variation of the path, and the stronger the correlation, the more significant the service node's impact on path performance. Therefore, a correlation coefficient threshold can be pre-set based on actual application scenarios. This allows service nodes with a correlation coefficient greater than the threshold to be selected as candidate services based on the PCC of each service node on the critical path.

[0082] For example, the correlation coefficient threshold in this embodiment can be any value between 0.5 and 0.7. If the PCC value of a service node is less than or equal to the correlation coefficient threshold, the service node is considered to contribute little to the overall performance of the path and does not need to be included in the subsequent analysis of key services. If the PCC value of a service node is greater than the correlation coefficient threshold, the service node is considered to contribute significantly to the overall performance of the path and can be selected as a candidate service for subsequent analysis of key services.

[0083] Step 306: Obtain a delay volatility indicator of the candidate service.

[0084] The latency volatility indicator is used to characterize the degree of dispersion in the candidate service's latency distribution. In this embodiment, the latency volatility indicator for a candidate service can be the ratio of the candidate service's P99 latency to its P50 latency over different time periods. The P99 latency refers to the value at which 99% of the request latencies in a set of latency data are less than or equal to this value. For example, if the P99 latency of an HTTP application is 2 milliseconds, this means that 99% of network request response times do not exceed 2 milliseconds. The P50 latency, on the other hand, indicates that 50% of all latencies are less than or equal to this value, i.e., the median latency.

[0085] Specifically, for each candidate service, the P99 delay and P50 delay of the candidate service in different time periods can be obtained respectively; and the ratio between the P99 delay and the P50 delay is calculated, and the ratio is determined as the delay volatility indicator of the corresponding candidate service to evaluate the stability of its response time.

[0086] In this embodiment, for service nodes with higher PCC values, i.e., candidate services, this embodiment further introduces a delay volatility index to screen key services, thereby improving the recognition accuracy of key services.

[0087] Step 308: If it is determined that the delay volatility index of the candidate service is greater than a preset index threshold, the candidate service is determined as a key service.

[0088] Among them, the preset indicator threshold can be a preset threshold for the delay volatility indicator for screening key services. For example, when the ratio of P99 to P50 is greater than 2.5 to 3.0, it means that there is a significant long-tail delay problem; and when it is greater than 3.5, it is almost certain to be a performance bottleneck; if it is lower than 1.5, it means that the performance of the service node is relatively stable. Therefore, the larger the ratio of P99 to P50, the more unstable the service performance of the service node is, and it may become a system performance bottleneck. In this embodiment, the preset indicator threshold can be any value between 2.5 and 3.0. For example, if the preset indicator threshold is 2.8, then when the delay volatility indicator of a candidate service is greater than 2.8, the candidate service can be determined as a key service.

[0089] The above embodiment uses a dual screening mechanism to more accurately identify key service nodes that truly impact system performance, thus providing a basis for subsequent optimization. Only service nodes that meet both high correlation and significant latency volatility are identified as key services. This dual screening mechanism not only ensures that the extracted key service nodes have significant room for improvement during the performance optimization process, but also effectively reduces the search space for subsequent Bayesian optimization to automatically adjust microservice parameters, thereby reducing latency and improving optimization efficiency and system stability.

[0090] In an exemplary embodiment, Figure 4 As shown, in step 106, a Bayesian optimization algorithm is used to collaboratively optimize multiple configuration parameters of key services in the microservice application to be optimized to determine target values of the multiple configuration parameters. Specifically, the following steps may be included:

[0091] Step 402: Sampling is performed based on the default configuration of the service as an initialization benchmark.

[0092] Specifically, a preliminary configuration can be performed for the key services obtained above. In this embodiment, the default configuration of the service can be selected as the initialization baseline. These default configurations can be obtained through the initial system settings or experience. For example, for the Redis service, parameters such as redis.maxmemory and redis.hz can be adjusted. At this stage, the system performance data corresponding to each configuration can be recorded as preliminary experimental data.

[0093] Step 404: construct a proxy model based on the Gaussian process to predict system performance under different parameter configurations.

[0094] Using the data from the initial sampling, Bayesian optimization can use Gaussian processes (GPs) to construct surrogate models to approximate the objective function. The GPs define a covariance function to represent the similarity between different configurations, thereby predicting system performance under different parameter configurations.

[0095] In this embodiment, the model formula can be expressed as follows:

[0096] f(x)~GP(m(x),k(x,x′)), (2)

[0097] Where f(x) is the predicted value of the objective function, m(x) is the mean function, and k(x, x′) is the covariance function. This model is used to estimate performance under different configuration parameters while providing uncertainty in the predicted values, thereby guiding the optimization process.

[0098] Since performance evaluation of microservice applications is one of the key steps in achieving configuration optimization, the goal of microservice application performance evaluation is to find the optimal configuration by testing different parameter configurations, thereby achieving the best application performance.

[0099] For example, assume that the configuration parameters of a microservice application can be viewed as a high-dimensional vector, where each dimension corresponds to an adjustable parameter. Suppose the parameter configuration of a microservice application is a vector c = (c1, c2, ..., c N ), where N represents the number of adjustable configuration parameters, and each c irepresents the value of the i-th configuration parameter. The set of all possible parameter configurations is recorded as C. The goal is to find an optimal parameter configuration to achieve the best performance of the microservice application, which is the following formula (3):

[0100]

[0101] Here, f(c) represents the performance of the microservice application obtained through load testing under configuration c, and c* is the configuration parameter in set c that maximizes function f(c).

[0102] In a cloud-native environment, microservice applications have a variety of performance metrics, such as requests per second and system latency. This embodiment uses P99 end-to-end latency as a performance evaluation metric. End-to-end latency refers to the time it takes for a user to send a request and receive a response, while P99 latency represents the delay within which 99% of requests are within this value. This effectively reflects the responsiveness of microservice applications under high load. To maximize application performance, the latency metric is inverted, meaning the optimization goal is to minimize latency.

[0103] Therefore, the objective function can be expressed as follows (4):

[0104] f(c)=-P99_latency(c), (4)

[0105] The objective function f(c) improves the performance of microservices by reflecting the minimization of latency, that is, by minimizing the P99 latency.

[0106] Step 406: Use expected improvement as a collection function to find potential excellent configurations and mine the optimal solution.

[0107] The key to Bayesian optimization lies in balancing exploration and exploitation. Exploration involves sampling unknown areas to find potential optimal configurations, while exploitation involves further exploring optimal solutions in currently known optimal areas. This example uses Expected Improvement (EI) as the acquisition function to achieve a balanced approach.

[0108] For example, the expected improvement can be expressed using the following formula (5):

[0109] EI(x)=E[max(f(x)-f(x * ),0)], (5)

[0110] Among them, f(x) is the predicted value of the objective function, f(x * ) is the currently known optimal target value, and E represents the expectation.

[0111] In step 408 , through optimization iterations, the model gradually converges and outputs the optimal configuration.

[0112] In each optimization iteration, Bayesian optimization selects the next parameter configuration to evaluate based on the expected improvement acquisition function. After testing the new configuration, new performance data is generated and added to the training dataset. This new data is used to update the Gaussian process model, and the next round of optimization continues. As the optimization continues, the model gradually converges until the maximum number of iterations is reached, ultimately finding the optimal configuration. In this way, Bayesian optimization effectively guides the parameter configuration search process, gradually converging towards the optimal solution.

[0113] The aforementioned Bayesian optimization provides an efficient, automated parameter tuning method for cloud-native microservice architectures. By optimizing the adjustable parameters of multiple services within a microservice architecture, and taking into account the complex dependencies between services, multiple parameters are collaboratively adjusted to improve the performance of the entire system. This is particularly effective when dealing with parameter spaces with high dimensions and complex dependencies, effectively finding a near-optimal configuration. Furthermore, this process is automated. Compared to traditional manual tuning methods, this method can find a near-optimal configuration in a shorter time and dynamically adapt to changes in load. It dynamically adjusts parameter configurations based on real-time load conditions to ensure that microservices consistently maintain optimal performance under varying loads, thereby improving the application's responsiveness and stability. Furthermore, automated configuration adjustments reduce manual intervention and improve system management efficiency.

[0114] In an exemplary embodiment, a power grid project successfully avoided the tedious process of manual parameter adjustment after adopting the above-mentioned configuration parameter optimization method based on the microservice architecture. Through this method, the power grid project can automatically adjust multiple service parameters in the microservice architecture, such as hz (number of dispatches per second), maxmemory-samples (number of memory samples) in redis, worker_connections (maximum number of connections per worker process), keepalive_requests (control of the maximum number of requests allowed on a persistent connection) in nginx, etc., thereby ensuring the stability and delay control of the system under high load conditions. This optimization measure enables the power grid system to maintain a low-latency response during peak traffic periods, improves the reliability of the system and service quality, and provides users with a better experience.

[0115] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0116] Based on the same inventive concept, the embodiments of the present application also provide a microservice architecture-based configuration parameter optimization device for implementing the aforementioned microservice architecture-based configuration parameter optimization method. The implementation solution provided by this device is similar to the implementation solution described in the aforementioned method. Therefore, the specific limitations of one or more microservice architecture-based configuration parameter optimization device embodiments provided below can be found in the above-mentioned limitations of the microservice architecture-based configuration parameter optimization method, and will not be repeated here.

[0117] In an exemplary embodiment, Figure 5 As shown, a configuration parameter optimization device based on a microservice architecture is provided, comprising: a critical path determination module 502, a critical service determination module 504 and an optimization module 506, wherein:

[0118] A critical path determination module 502 is configured to obtain call link data of the microservice application to be optimized in the microservice architecture, and determine a critical path based on the call link data, where the critical path is the call link path with the longest service delay in the call link data;

[0119] A key service determination module 504 is configured to determine a key service from the key path, where the key service is the service on the key path that has the greatest impact on the overall performance of the microservice application to be optimized;

[0120] The optimization module 506 is configured to collaboratively optimize multiple configuration parameters of the key service in the microservice application to be optimized using a Bayesian optimization algorithm to determine target values of the multiple configuration parameters of the key service in the microservice application to be optimized.

[0121] In an exemplary embodiment, the critical path determination module is specifically configured to:

[0122] Obtain the call relationships between services in the microservice application to be optimized, as well as the response times corresponding to the call relationships;

[0123] Generate a call link graph based on the call relationships between services and the corresponding response times. The call link graph includes nodes and edges. Each node represents a service, and each edge represents the call relationship between corresponding services. The edges have corresponding weights, which are used to represent the response time of the corresponding call relationship.

[0124] Based on the call link graph, a call link path with the longest service delay in the call link graph is identified, and the call link path with the longest service delay is determined as the critical path.

[0125] In an exemplary embodiment, the critical path determination module may further be used to:

[0126] Traversing the call link graph to obtain all call link paths in the call link graph;

[0127] For each of the call link paths, accumulating the weights of the corresponding edges in the call link path to determine the path delay duration corresponding to the call link path;

[0128] Based on the path delay duration corresponding to each of the call link paths, the call link path with the longest path delay duration is determined as the call link path with the longest service delay in the call link graph.

[0129] In an exemplary embodiment, the key service determination module is specifically configured to:

[0130] For each service in the critical path, obtaining a correlation coefficient between a first delay of the service and a second delay of the critical path;

[0131] Determine a service in the critical path whose correlation coefficient is greater than a correlation coefficient threshold as a candidate service;

[0132] For the candidate service, obtaining a delay volatility index of the candidate service, where the delay volatility index is used to characterize a degree of dispersion of a delay distribution of the candidate service;

[0133] When it is determined that the delay volatility index of the candidate service is greater than a preset index threshold, the candidate service is determined as the key service.

[0134] In an exemplary embodiment, the key service determination module may further be used to:

[0135] For the candidate service, respectively obtain the P99 delay and P50 delay of the candidate service;

[0136] A ratio between the P99 delay and the P50 delay is calculated, and the ratio is determined as a delay fluctuation indicator of the candidate service.

[0137] In an exemplary embodiment, the key service determination module may further be used to:

[0138] Obtaining a historical delay data sequence of each service in the critical path and a path delay sequence corresponding to the critical path;

[0139] According to the historical delay data sequence of each service and the path delay sequence of the corresponding critical path, based on the Pearson correlation statistical method, the correlation coefficient between the first delay of each service and the second delay of the critical path is obtained.

[0140] Each module in the configuration parameter optimization device based on the microservice architecture can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in the computer device in the form of software, so that the processor can call and execute the corresponding operations of each module.

[0141] In an exemplary embodiment, a computer device is provided, the internal structure of which can be shown as follows: Figure 6 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O) and a communication interface. The processor, memory and input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store configuration parameter data of microservices. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a configuration parameter optimization method based on a microservice architecture is implemented.

[0142] Those skilled in the art will understand that Figure 6 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0143] In an exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps in the above method embodiments when executing the computer program.

[0144] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0145] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0146] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0147] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, database or other media used in the embodiments provided in this application may include at least one of non-volatile memory and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processor involved in the various embodiments provided herein may be, but are not limited to, a general-purpose processor, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a programmable logic unit (PLC), a data processing logic unit based on quantum computing, an artificial intelligence (AI) processor, and the like.

[0148] The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0149] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A configuration parameter optimization method based on microservice architecture, characterized in that: The method comprises: Obtain call link data of the microservice application to be optimized in the microservice architecture, and determine a critical path based on the call link data, where the critical path is a call link path with the longest service delay in the call link data; Determine a key service on the critical path, where the key service is the service on the critical path that has the greatest impact on the overall performance of the microservice application to be optimized; By using a Bayesian optimization algorithm, multiple configuration parameters of the key service in the microservice application to be optimized are collaboratively optimized to determine target values of the multiple configuration parameters of the key service in the microservice application to be optimized.

2. The method according to claim 1, characterized in that The obtaining of call link data of the microservice application to be optimized and determining the critical path based on the call link data includes: Obtain the call relationships between services in the microservice application to be optimized, as well as the response times corresponding to the call relationships; Generate a call link graph based on the call relationships between services and the corresponding response times. The call link graph includes nodes and edges. Each node represents a service, and each edge represents the call relationship between corresponding services. The edges have corresponding weights, which are used to represent the response time of the corresponding call relationship. Based on the call link graph, a call link path with the longest service delay in the call link graph is identified, and the call link path with the longest service delay is determined as the critical path.

3. The method according to claim 2, characterized in that The step of identifying, based on the call link graph, a call link path having the longest service delay in the call link graph includes: Traversing the call link graph to obtain all call link paths in the call link graph; For each of the call link paths, accumulating the weights of the corresponding edges in the call link path to determine the path delay duration corresponding to the call link path; Based on the path delay duration corresponding to each of the call link paths, the call link path with the longest path delay duration is determined as the call link path with the longest service delay in the call link graph.

4. The method according to claim 1, wherein The determining of the key service from the key path includes: For each service in the critical path, obtaining a correlation coefficient between a first delay of the service and a second delay of the critical path; Determine a service in the critical path whose correlation coefficient is greater than a correlation coefficient threshold as a candidate service; For the candidate service, obtaining a delay volatility index of the candidate service, where the delay volatility index is used to characterize a degree of dispersion of a delay distribution of the candidate service; When it is determined that the delay volatility index of the candidate service is greater than a preset index threshold, the candidate service is determined as the key service.

5. The method according to claim 4, characterized in that The acquiring, for the candidate service, a delay volatility indicator of the candidate service includes: For the candidate service, respectively obtain the P99 delay and P50 delay of the candidate service; A ratio between the P99 delay and the P50 delay is calculated, and the ratio is determined as a delay fluctuation indicator of the candidate service.

6. The method according to claim 4, characterized in that The obtaining, for each service in the critical path, a correlation coefficient between a first delay of the service and a second delay of the critical path includes: Obtaining a historical delay data sequence of each service in the critical path and a path delay sequence corresponding to the critical path; According to the historical delay data sequence of each service and the path delay sequence of the corresponding critical path, based on the Pearson correlation statistical method, the correlation coefficient between the first delay of each service and the second delay of the critical path is obtained.

7. A configuration parameter optimization device based on microservice architecture, characterized in that: The device comprises: A critical path determination module is configured to obtain call link data of the microservice application to be optimized in the microservice architecture, and determine a critical path based on the call link data, where the critical path is the call link path with the longest service delay in the call link data; A key service determination module is configured to determine a key service from the key path, where the key service is the service on the key path that has the greatest impact on the overall performance of the microservice application to be optimized; The optimization module is used to collaboratively optimize multiple configuration parameters of the key service in the microservice application to be optimized through a Bayesian optimization algorithm to determine target values of the multiple configuration parameters of the key service in the microservice application to be optimized.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images