Service invocation link dynamic arrangement method, system and device

Abstract

This application relates to the field of intelligent service technology, and particularly to a method, system, and device for dynamic orchestration of service call links. The method includes: acquiring real-time status information of each service node in the service call link; determining service nodes whose service parameters need optimization based on the real-time status information; determining the correlation between the service parameters of each service node in the service call link and overall performance indicators; determining a first optimization parameter for the service node in the core processing area that needs optimization based on a preset performance indicator range and correlation; and determining a second optimization parameter for the service node in the auxiliary processing area that needs optimization based on the first optimization parameter. Therefore, the dynamic orchestration method for service call links provided by this application can solve the problem of difficulty in accurately analyzing the dynamic interactions of different areas in the service call link, which leads to the inability to effectively optimize the service call link from a cross-regional perspective.

Description

Technical Field

[0001] This application belongs to the field of intelligent service technology, and in particular relates to a method, system and device for dynamic orchestration of service call links. Background Technology

[0002] A service call chain refers to the sum of a series of service nodes and their call relationships that a service request traverses from initiation to completion in a distributed system. It not only records the order of service calls but also includes information such as the status and performance data of each calling node. By analyzing the service call chain, developers and operations personnel can clearly understand the system's operational status, quickly locate problems, and optimize system performance.

[0003] In existing technologies, the service call chain structure is dynamic and uncertain. As business develops and the system evolves, new service nodes are constantly added, while older nodes are phased out or modified, and the call relationships between services also change. Furthermore, complex dynamic interaction and coordination mechanisms exist between different regions within the service call chain. Performance changes in one region can be propagated through service calls, affecting other regions and even the entire chain's performance. Therefore, existing technologies struggle to accurately analyze the dynamic interactions between different regions within the service call chain, making it impossible to effectively optimize the service call chain from a cross-regional perspective. Summary of the Invention

[0004] This application provides a method, system, and device for dynamic orchestration of service call links, which can solve the problem that it is difficult to accurately analyze the dynamic interaction of each region in the service call link, resulting in the inability to effectively optimize the service call link from a cross-regional perspective.

[0005] In a first aspect, embodiments of this application provide a method for dynamic orchestration of service invocation chains, including: Obtain real-time status information of each service node in the service call chain; wherein, the real-time status information includes service response time, service success rate and service resource consumption value, and the service call chain includes service nodes in the core processing area and the auxiliary processing area; The service nodes whose service parameters need to be optimized are determined based on the real-time status information of each node; wherein, the service parameters include traffic control parameters, resource allocation parameters, and timeout control parameters. Determine the correlation between the service parameters of each service node in the service call chain and the overall performance indicators; wherein, the overall performance indicators include end-to-end latency and system throughput; Based on the preset performance index range and the correlation, the first optimization parameter of the service node that needs to be optimized in the core processing area is determined; Based on the first optimization parameters, the second optimization parameters for the service nodes that need to be optimized in the auxiliary processing area are determined.

[0006] The technical solutions described in this application embodiment have at least the following technical effects: The service call link dynamic orchestration method provided in this application embodiment obtains real-time status information of each service node in the service call link; determines the service nodes whose service parameters need optimization based on the real-time status information; determines the correlation between the service parameters of each service node in the service call link and the overall performance indicators; determines the first optimization parameters of the service nodes in the core processing area that need optimization based on the preset performance indicator range and correlation; and determines the second optimization parameters of the service nodes in the auxiliary processing area that need optimization based on the first optimization parameters. Therefore, the service call link dynamic orchestration method provided in this application embodiment comprehensively considers the performance status and interrelationships of each service node in the core processing area and the auxiliary processing area, which is beneficial for achieving systematic optimization and improving the performance and stability of the entire service call link. By obtaining the status information of the service nodes in real time and dynamically adjusting the service parameters according to the preset performance indicator range and correlation, it can adapt to changes in the system operation process in a timely manner, which is beneficial for improving the accuracy and effectiveness of optimizing the service call link.

[0007] In one possible implementation of the first aspect, the method further includes: If the rate of change of the real-time status information is determined to be greater than a preset threshold, the performance of each service node in the service call chain is evaluated with confidence, and a performance confidence value for each service node is generated. The flow control parameters are adjusted based on the performance confidence value.

[0008] In one possible implementation of the first aspect, adjusting the flow control parameters based on the performance confidence value includes: When it is determined that the service nodes in the service call chain need to be adjusted based on the performance confidence value, the node status is determined according to the real-time status information; wherein, the node status is used to reflect the real-time performance status of each service node; The node priority is obtained by fusing and identifying the node status and the service call chain's operational scenario information; wherein, the operational scenario information includes request frequency and business priority. The flow control parameters are adjusted according to the node priority.

[0009] In one possible implementation of the first aspect, the method further includes: If adjustments to service nodes in the service call chain are determined based on the real-time status information, the resource allocation parameters and timeout control parameters are optimized according to the real-time status information and the running scenario information.

[0010] In one possible implementation of the first aspect, obtaining the real-time status information of each service node in the service call chain includes: Obtain historical request data; wherein, the historical request data includes arrival time, service time, and response time; The mean service time is obtained by fitting the exponential distribution parameters using the maximum likelihood estimation based on the historical request data. The queuing time is calculated based on the average service time and the historical request data. The service response time is obtained based on the queuing time and the service time.

[0011] In one possible implementation of the first aspect, determining the service nodes whose service parameters need optimization based on the real-time status information includes: The path length is obtained by inputting the real-time status information as features into the isolated forest model; wherein, the isolated forest model is trained based on the historical request data; An anomaly score is calculated based on the path length; wherein, the anomaly score is used to quantify the anomaly probability of each of the service nodes; The service nodes whose service parameters need optimization are identified based on the anomaly scores.

[0012] In one possible implementation of the first aspect, determining the first optimization parameter of the service node requiring optimization in the core processing region based on the preset performance index range and the correlation includes: An objective function is constructed based on the aforementioned correlation; wherein, the objective function is used to quantify the optimization objective, which includes minimizing response time and maximizing resource utilization. Calculate the solution set based on the objective function; The first optimization parameter is obtained by selecting a solution from the solution set that satisfies the preset performance index range.

[0013] In one possible implementation of the first aspect, determining the second optimization parameters of the service node to be optimized in the auxiliary processing region based on the first optimization parameters includes: The load prediction value is obtained based on the first optimization parameters; wherein, the load prediction value includes the number of requests and the number of concurrent requests; The asynchronous call ratio is calculated based on the load forecast and the maximum throughput of the core processing area; wherein, the asynchronous call ratio refers to the proportion of requests processed asynchronously in the auxiliary processing area to the total number of requests; The second optimized parameter for the service parameters of the auxiliary processing area is obtained based on the asynchronous call ratio.

[0014] Secondly, embodiments of this application provide a dynamic orchestration system for service invocation links, including: The acquisition module is used to acquire real-time status information of each service node in the service call chain; wherein, the real-time status information includes service response time, service success rate and service resource consumption value, and the service call chain includes service nodes in the core processing area and the auxiliary processing area; The service node module is used to determine the service nodes whose service parameters need to be optimized based on the real-time status information; wherein the service parameters include traffic control parameters, resource allocation parameters, and timeout control parameters. The correlation module is used to determine the correlation between the service parameters of each service node in the service call chain and the overall performance indicators; wherein, the overall performance indicators include end-to-end latency and system throughput. The first optimization parameter module is used to determine the first optimization parameters of the service node that needs to be optimized in the core processing area based on the preset performance index range and the correlation relationship. The second optimization parameter module is used to determine the second optimization parameters of the service node that needs to be optimized in the auxiliary processing area based on the first optimization parameters.

[0015] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method as described in any one of the first aspects above.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any of the first aspects above.

[0017] Fifthly, embodiments of this application provide a computer program product that, when run on an electronic device, causes the electronic device to perform the method described in any one of the first aspects above.

[0018] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, 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 drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating a method for dynamically orchestrating service call chains according to an embodiment of this application; Figure 2 This is a schematic diagram of the implementation process of step S700 in the service call link dynamic orchestration method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the implementation process of step S100 in the service call chain dynamic orchestration method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the implementation process of steps S200, S400 and S500 in the service call link dynamic orchestration method provided in an embodiment of this application; Figure 5 This is a schematic diagram of system throughput in a service call link dynamic orchestration method provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of the service call chain dynamic orchestration system provided in the embodiments of this application; Figure 7 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0021] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0022] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0023] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0024] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0025] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0026] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0027] In related technologies, the service call chain structure is dynamic and uncertain. As business develops and the system evolves, new service nodes are constantly added, while old nodes are phased out or modified, and the call relationships between services also change. Furthermore, complex dynamic interaction and coordination mechanisms exist between different regions within the service call chain. Performance changes in one region can be propagated through service calls, affecting other regions and even the entire chain's performance. Therefore, existing technologies struggle to accurately analyze the dynamic interactions between different regions within the service call chain, making it impossible to effectively optimize the service call chain from a cross-regional perspective.

[0028] To address the aforementioned issues, embodiments of this application provide a method, system, and device for dynamic orchestration of service call links. This method involves: acquiring real-time status information of each service node in the service call link; determining service nodes whose service parameters require optimization based on the real-time status information; determining the correlation between the service parameters of each service node in the service call link and overall performance indicators; determining first optimization parameters for service nodes in the core processing area that require optimization based on preset performance indicator ranges and correlations; and determining second optimization parameters for service nodes in the auxiliary processing area that require optimization based on the first optimization parameters. Therefore, the dynamic orchestration method for service call links provided by embodiments of this application comprehensively considers the performance status and interrelationships of each service node in both the core processing area and the auxiliary processing area, which is beneficial for achieving systematic optimization and improving the performance and stability of the entire service call link. By acquiring the status information of service nodes in real time and dynamically adjusting service parameters according to preset performance indicator ranges and correlations, it can adapt to changes during system operation in a timely manner, which is beneficial for improving the accuracy and effectiveness of optimizing the service call link.

[0029] The service call link dynamic orchestration method provided in this application embodiment can be applied to electronic devices. In this case, the electronic device is the execution subject of the service call link dynamic orchestration method provided in this application embodiment. This application embodiment does not impose any restrictions on the specific type of electronic device.

[0030] For example, electronic devices can be tablets, augmented reality (AR) / virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), desktop computers, laptops, handheld communication devices, handheld computing devices, satellite wireless devices, customer premises equipment (CPEs), and / or other devices used for communication over wireless systems, as well as next-generation communication systems, such as mobile terminals in 5G networks or mobile terminals in future evolved Public Land Mobile Network (PLMN) networks, but are not limited to these.

[0031] To better understand the dynamic orchestration method for service call chains provided in the embodiments of this application, the specific implementation process of the dynamic orchestration method for service call chains provided in the embodiments of this application will be described by way of example below.

[0032] Figure 1This paper presents a schematic flowchart illustrating a dynamic orchestration method for service call chains provided in an embodiment of this application. The dynamic orchestration method for service call chains includes: S100: Obtain real-time status information of each service node in the service call chain. This real-time status information includes service response time, service success rate, and service resource consumption. The service call chain includes service nodes in the core processing area and the auxiliary processing area.

[0033] For example, a distributed tracing system (such as Jaeger or Zipkin) combined with monitoring tools (such as Prometheus + Grafana) can be used to collect real-time status information of each service node. For instance, a monitoring agent (such as Telegraf or Datadog Agent) can be deployed on each service node to report metrics via an HTTP / 2 interface or a Kafka message queue. Cross-service call chains can be associated using TraceIDs; for example, the OpenTelemetry standard can be used to pass Trace context between services, making the node status of core processing areas (such as order processing services) and auxiliary processing areas (such as log services) traceable.

[0034] S200 determines the service nodes whose service parameters need optimization based on real-time status information. These service parameters include traffic control parameters, resource allocation parameters, and timeout control parameters.

[0035] For example, service response time thresholds (e.g., core processing area ≤ 200ms, auxiliary processing area ≤ 150ms), service success rate thresholds (e.g., ≥ 98%), and service resource consumption thresholds (e.g., CPU ≤ 80%) can be set. Service nodes requiring parameter optimization are determined by comparing real-time status information with preset thresholds. Alternatively, rolling window statistics (e.g., average value of the most recent hour + 3σ) can be used to identify service nodes requiring parameter optimization. For instance, if the average response time of service node E between 10:00 and 10:05 is 210ms with a standard deviation of 15ms, and the current value of 240ms exceeds the average + 2σ (240ms), optimization is triggered.

[0036] S300 determines the correlation between the service parameters of each service node in the service call chain and the overall performance indicators. The overall performance indicators include end-to-end latency and system throughput.

[0037] For example, historical data (such as service parameter adjustment records and overall performance metrics for the past 7 days) can be obtained, including traffic control parameters (such as QPS rate limits), resource allocation parameters (such as CPU / memory limits), timeout control parameters (such as request timeout thresholds), and corresponding end-to-end latency (such as P99 latency) and system throughput (such as QPS). The system throughput is as follows: Figure 5As shown, linear regression or multivariate analysis is used to fit the relationship between the service parameters of each service node in the service call chain and the overall performance index.

[0038] S400 determines the first optimization parameters of the service nodes that need to be optimized in the core processing area based on the preset performance index range and correlation.

[0039] For example, based on a preset performance index range (e.g., end-to-end latency ≤ 200ms, throughput ≥ 1500QPS) and correlations, the values ​​of the first optimization parameters for the service nodes to be optimized in the core processing region can be solved through constraint optimization. The optimal parameters can be obtained using linear programming or gradient descent algorithms. For instance, the objective function might be to minimize end-to-end latency or maximize system throughput, with constraints being the service parameter range and the preset performance index range.

[0040] S500, based on the first optimization parameters, determine the second optimization parameters of the service nodes that need to be optimized in the auxiliary processing area.

[0041] For example, the call relationship between service nodes in the auxiliary processing region and service nodes in the core processing region can be obtained (such as the frequency and data volume of core nodes calling auxiliary nodes). Based on the changes in the service parameters of service nodes in the core processing region, the service parameters of service nodes in the auxiliary processing region can be derived and determined. For example, if the QPS limit of service node K in the core processing region is reduced from 1000 to 900, and the request volume of service node L in the auxiliary processing region decreases by 10%, then the timeout control parameter of service node L in the auxiliary processing region can be adjusted from 500ms to 450ms.

[0042] In one possible implementation, please refer to Figure 2 The methods also include: S600, when it is determined that the rate of change of real-time status information is greater than a preset threshold, performs a confidence assessment on the performance of each service node in the service call chain and generates a performance confidence value for each service node.

[0043] For example, real-time status information of service nodes can be collected in real time through a monitoring system (such as Prometheus), and the instantaneous rate of change of the real-time status information can be calculated according to a fixed time window (such as 10 seconds). A sliding window algorithm can be used to calculate the relative rate of change of the real-time status information. If the rate of change exceeds a preset threshold (such as service response time change rate > 15%, service success rate change rate > 5%, service resource consumption change rate > 10%), a performance confidence assessment is triggered. The performance confidence value (a probability value between 0 and 1) of each service node can be obtained by weighted summation based on the difference between the rate of change of the real-time status information and the preset threshold.

[0044] S700 adjusts flow control parameters based on performance confidence values.

[0045] For example, the confidence level can be determined based on the performance confidence value: high confidence (performance confidence value > 0.8), medium confidence (performance confidence value: 0.5~0.8), or low confidence (performance confidence value < 0.5). For high-confidence service nodes: maintain the current flow control parameters (e.g., QPS rate limit); for medium-confidence service nodes: dynamically adjust the QPS rate limit, for example, new QPS rate limit = current QPS rate limit × (1 - α × (1 - confidence level)), where α is an adjustment coefficient (e.g., 0.2); for low-confidence service nodes: forcibly adjust the QPS rate limit (e.g., reduce it to 50% of the current QPS rate limit).

[0046] By incorporating multiple metrics, including change rates and confidence levels, through steps S600 to S700, the number of erroneous optimizations can be reduced, avoiding excessive rate limiting or resource allocation due to misjudgments. Change rate detection and confidence level assessment facilitate early identification of potential risks. Adjusting parameters based on node confidence levels improves resource utilization. In fluctuating load scenarios, high-confidence nodes maintain stable performance, while low-confidence nodes alleviate pressure through rate limiting, thus enhancing the system's anti-interference capabilities.

[0047] Optionally, please refer to Figure 2 S700 adjusts flow control parameters based on performance confidence values, including: S710, when adjusting service nodes in the service call chain based on performance confidence values, determines node status based on real-time status information. Node status reflects the real-time performance status of each service node.

[0048] For example, when adjusting service nodes in a service call chain based on performance confidence values ​​(e.g., performance confidence value < 0.5), the node status can be determined using statistical methods (e.g., sliding window standard deviation, Bayesian inference) by combining historical data and real-time status information. For instance, if the historical average service response time of service node A is 150ms with a standard deviation of 20ms, and the current real-time response time is 180ms, exceeding the historical average by 2σ (190ms is the threshold), then the node status in terms of service response time = 1 - (180 - 150) / (190 - 150) = 0.75. The node status of the service node is determined by weighted summation of the node status values ​​from various aspects of the real-time status information. The node status can be categorized as healthy (> 0.8), sub-healthy (0.6~0.8), and abnormal (< 0.6).

[0049] The S720 integrates and identifies node status and service call chain runtime scenario information to obtain node priority. The runtime scenario information includes request frequency and business priority.

[0050] For example, a priority score can be generated by weighting and summing the request frequency and business priority in the node status and running scenario information, thus obtaining the node priority.

[0051] The S730 adjusts flow control parameters based on node priority.

[0052] For example, high-priority and low-priority nodes can be determined based on node priority ranking. For high-priority nodes: increase the traffic allocation ratio and lower the rate limiting threshold (e.g., from 1000 QPS to 1200 QPS); for low-priority nodes: reduce traffic allocation and raise the rate limiting threshold (e.g., from 500 QPS to 400 QPS) or enable a circuit breaker mechanism. A proportional-integral-derivative (PID) controller or a reinforcement learning model can be used to dynamically adjust the traffic control parameters based on the priority score. For example, if service node G is high-priority, its current traffic is 800 QPS, the target traffic is 1000 QPS, and the adjustment step size is 50 QPS / second, the target traffic can be reached.

[0053] Through steps S710 to S730, traffic is dynamically adjusted based on priority, preventing low-priority nodes from consuming excessive resources. Integrating request frequency and business priority improves the stability of critical services (such as payments). Real-time performance confidence assessment and priority calculation facilitate real-time traffic adjustment.

[0054] In one possible implementation, please refer to Figure 2 The methods also include: S800, when determining to adjust service nodes in the service call chain based on real-time status information, optimizes resource allocation parameters and timeout control parameters according to real-time status information and runtime scenario information.

[0055] For example, when node status is obtained based on real-time status information, and adjustments to service nodes in the service call chain are determined based on the node status (e.g., node status value < 0.6), a priority score can be generated by weighted summation of request frequency and business priority in the node status and runtime scenario information. Resource allocation parameters (e.g., CPU / memory quota) can be dynamically adjusted based on the priority score. A regression model (e.g., XGBoost) can be trained using historical data, with node status and request frequency and business priority in the runtime scenario information as inputs, and optimal timeout control parameters (e.g., timeout threshold) as outputs. Historical data can be divided into a training set (first 80%), a validation set (middle 10%), and a test set (last 10%) in chronological order. Parameters (e.g., learning rate, tree depth, subsampling ratio, etc.) can be adjusted using grid search or Bayesian optimization. The model is fitted on the training set, and metrics (e.g., MAE, RMSE, MAPE) are evaluated on the validation set to obtain the regression model.

[0056] Through step S800 above, resources are dynamically allocated using a priority-weighted model, which helps ensure sufficient resources for critical business operations. By integrating real-time status and operational scenario information, dynamic optimization of resource allocation and timeout control is achieved, which helps to solve the problems of staticity, high false positive rate, and insufficient user differentiation of traditional methods, and improves system stability and user experience.

[0057] In one possible implementation, please refer to Figure 3 S100, obtain real-time status information of each service node in the service call chain, including: S110, Obtain historical request data. This historical request data includes arrival time, service time, and response time.

[0058] For example, arrival time: the timestamp of the request entering the system; service time: the actual time taken for the node to process the request; response time: the time from the arrival of the request to its completion.

[0059] S120, based on historical request data, use maximum likelihood estimation to fit the exponential distribution parameters to obtain the mean service time.

[0060] For example, the mean service time can be obtained by fitting the parameters of an exponential distribution using maximum likelihood estimation based on historical request data. For instance, the service time may follow an exponential distribution. The mean service time is obtained by estimating the parameter μ (i.e., the reciprocal of the mean service time) through MLE.

[0061] S130 calculates the queuing time based on the average service time and historical request data.

[0062] For example, the average request arrival rate λ can be calculated based on the arrival time intervals in historical request data, and the queuing time can be calculated based on the average request arrival rate and the average service time θ. Queuing time = ρ θ / μ(1-ρ), where ρ=λ / μ, μ=1 / θ.

[0063] S140, the service response time is obtained based on the queuing time and service time.

[0064] For example, the queuing time and service time can be added together to obtain the service response time.

[0065] By performing steps S110 to S140 above, queuing time is calculated based on queuing theory, which helps to more accurately reflect system congestion. Through parameter fitting and queuing theory modeling, it is beneficial to achieve high-precision response time prediction and dynamic load management.

[0066] In one possible implementation, please refer to Figure 4 S200, based on various real-time status information, determines the service nodes whose service parameters need optimization, including: S210: Input the real-time state information as features into the Isolation Forest model to obtain the path length. The Isolation Forest model is trained based on historical request data.

[0067] For example, historical request data can be normalized (e.g., Min-Max scaled to [0,1]) to eliminate the influence of dimensions, and multiple isolated trees (iTrees) can be constructed. Each tree recursively partitions the data (randomly selecting features and split points) until all samples are isolated or the tree depth limit is reached. For example, using 100 trees with a subsample size of 256, the model parameters (such as split threshold and tree structure) are saved after training to obtain an isolated forest model. The normalized real-time state data is then input into the trained isolated forest model. The path length in each isolated tree is equal to the number of splits from the root node to the leaf node. The average of the number of splits across all trees is used to obtain the path length.

[0068] S220 calculates the anomaly score based on the path length. The anomaly score is used to quantify the anomaly probability of each service node.

[0069] For example, an anomaly score can be calculated based on the path length. For instance, anomaly score = Where c(n) is the average path length correction term of the binary search tree (n is the number of samples, c(n) = 2H(n-1)-2(n-1) / n, and H is the harmonic number).

[0070] S230 identifies service nodes whose service parameters need optimization based on abnormal scores.

[0071] For example, an abnormal score threshold (such as 0.6) can be set. If the abnormal score is greater than the abnormal score threshold, the service node is marked as needing to optimize its service parameters.

[0072] Through steps S210 to S230 above, normal behavior is dynamically modeled using an isolated forest model, enabling adaptive anomaly detection. Calculating anomaly scores using multi-dimensional features improves detection accuracy. Achieving multi-dimensional, adaptive, real-time anomaly detection through the isolated forest model enhances system stability and operational efficiency.

[0073] In one possible implementation, please refer to Figure 4 S400, based on preset performance index ranges and correlations, determines the first optimization parameters for service nodes in the core processing area that need to be optimized, including: S410, Construct the objective function based on the correlation. The objective function quantifies the optimization objectives, which include minimizing response time and maximizing resource utilization.

[0074] For example, historical data (such as service parameter adjustment records and overall performance metrics for the past 7 days) can be obtained, including traffic control parameters (QPS rate limit), resource allocation parameters (CPU / memory limits), timeout control parameters (request timeout thresholds), and corresponding end-to-end latency (such as P99 latency) and system throughput (such as QPS). Linear regression or multivariate analysis is used to fit the relationship between service parameters and overall performance metrics for each service node in the service call chain. Based on the relationship between response time (end-to-end latency) and service parameters, and the relationship between resource utilization (throughput) and service parameters, a weighted sum that minimizes response time and minimizes resource consumption is constructed to obtain the objective function.

[0075] S420, calculate the solution set based on the objective function.

[0076] For example, the solution set of service parameters of the service node to be optimized can be calculated based on the objective function using optimization algorithms (such as gradient descent, genetic algorithm, etc.).

[0077] S430: Select a solution from the solution set that meets the preset performance index range to obtain the first optimization parameters.

[0078] For example, a solution that meets a preset performance index range (such as end-to-end latency ≤ 200ms, throughput ≥ 1500QPS) can be selected from the solution set to obtain the first optimization parameters.

[0079] Through steps S410 to S430, a weighted objective function is used to balance response time and resource consumption. Utilizing optimization algorithms to automatically calculate the solution set facilitates automated optimization and reduces manual intervention. Selecting solutions that satisfy the constraints from the solution set improves feasibility.

[0080] In one possible implementation, please refer to Figure 4 S500, based on the first optimization parameters, determines the second optimization parameters of the service nodes to be optimized in the auxiliary processing area, including: S510, the load prediction value is obtained based on the first optimization parameters. The load prediction value includes the number of requests and the number of concurrent requests.

[0081] For example, the load prediction value includes the number of requests (Q) and the number of concurrent requests (C). The first optimization parameters include flow control parameters, resource allocation parameters, and timeout control parameters. The flow control parameters can refer to QPS rate limiting, the resource allocation parameters can refer to CPU / memory limits, and the timeout control parameters can refer to request timeout thresholds. The load prediction value can be obtained by training a prediction model (such as XGBoost, Support Vector Regression (SVR), etc.) on historical data (including flow control parameters, resource allocation parameters, timeout control parameters, and corresponding request and concurrent requests of multiple service nodes) based on the first optimization parameters. The historical data can be divided into a training set (first 80%), a validation set (middle 10%), and a test set (last 10%) in chronological order. Parameters (such as learning rate, tree depth, subsampling ratio, etc.) can be adjusted using grid search or Bayesian optimization. The model is fitted on the training set, and metrics (such as MAE, RMSE, MAPE) are evaluated on the validation set to obtain the prediction model.

[0082] S520 calculates the asynchronous call ratio based on the load forecast and the maximum throughput of the core processing area. The asynchronous call ratio refers to the proportion of requests processed asynchronously in the auxiliary processing area out of the total number of requests.

[0083] For example, the load forecast can be based on the number of requests (Q) and the maximum throughput of the core processing area (T). max Determine the asynchronous call ratio. If Q > T max If it is determined that some requests need to be processed asynchronously, the asynchronous call ratio α = max(0, (Q﹣T)). max ) / Q).

[0084] S530 obtains the second optimized parameter of the service parameters of the auxiliary processing area based on the asynchronous call ratio.

[0085] For example, the second optimization parameters include flow control parameters, resource allocation parameters, and timeout control parameters. These can be based on the average processing time (T) of the asynchronous request.async ) and the system's tolerance for latency (D) max ), calculate the maximum queue length: Q max =α λ (D max -T async ), where λ is the total number of requests. If the queue length exceeds Q. max If this happens, rate limiting will be triggered; for example, new asynchronous requests will be rejected when the queue length is ≥60. Resources can be allocated based on the type of asynchronous task (e.g., I / O-intensive or compute-intensive). If the auxiliary processing area uses containerization or a thread pool, its size N can be set as: N = α λ T async (1+β), where β is the redundancy coefficient (e.g., 0.2 to handle sudden traffic spikes). This can be based on the historical processing time distribution of asynchronous tasks in historical data (e.g., the 95th quantile T). 95 Set the timeout period T timeout =min(D max T95 γ), where γ is the safety factor (e.g., 1.5 to cover abnormal situations).

[0086] Steps S510 to S530, combined with the first optimization parameter, improve prediction accuracy. The asynchronous ratio is automatically calculated based on the predicted load and core area throughput to avoid overload. Dynamically adjusting service parameters in auxiliary areas using the asynchronous ratio improves resource utilization. Alleviating pressure on the core area through asynchronous processing enhances overall system stability.

[0087] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0088] Corresponding to the service call chain dynamic orchestration method described in the above embodiments, this application also provides a service call chain dynamic orchestration system, the various modules of which can implement the various steps of the service call chain dynamic orchestration method. Figure 6 The diagram shows a structural block diagram of the service call chain dynamic orchestration system provided in the embodiments of this application. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0089] Reference Figure 6 The system includes: The acquisition module is used to acquire real-time status information of each service node in the service call chain; wherein, the real-time status information includes service response time, service success rate and service resource consumption value, and the service call chain includes service nodes in the core processing area and the auxiliary processing area; The service node module is used to determine the service nodes whose service parameters need to be optimized based on the real-time status information; wherein the service parameters include traffic control parameters, resource allocation parameters, and timeout control parameters. The correlation module is used to determine the correlation between the service parameters of each service node in the service call chain and the overall performance indicators; wherein, the overall performance indicators include end-to-end latency and system throughput. The first optimization parameter module is used to determine the first optimization parameters of the service node that needs to be optimized in the core processing area based on the preset performance index range and the correlation relationship. The second optimization parameter module is used to determine the second optimization parameters of the service node that needs to be optimized in the auxiliary processing area based on the first optimization parameters.

[0090] It should be noted that the information interaction and execution process between the above modules are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0091] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0092] This application also provides an electronic device. Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 7 As shown, the electronic device 7 of this embodiment includes: at least one processor 70 ( Figure 7 Only one is shown in the image), at least one memory 71 ( Figure 7(Only one is shown in the image) and a computer program 72 stored in the at least one memory 71 and executable on the at least one processor 70. When the processor 70 executes the computer program 72, it causes the electronic device 7 to implement the steps in any of the above-described service call link dynamic orchestration method embodiments, or causes the electronic device 7 to implement the functions of each module / unit in the above-described system embodiments.

[0093] For example, the computer program 72 may be divided into one or more modules / units, which are stored in the memory 71 and executed by the processor 70 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program 72 in the electronic device 7.

[0094] The electronic device 7 can be a desktop computer, laptop, handheld computer, cloud server, or other computing device. This electronic device may include, but is not limited to, a processor 70 and a memory 71. Those skilled in the art will understand that... Figure 7 The example of electronic device 7 is merely an illustration and does not constitute a limitation on electronic device 7. It may include more or fewer components than shown, or combine certain components, or different components. For example, it may also include input / output devices, network access devices, buses, etc.

[0095] The processor 70 can be a Central Processing Unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0096] In some embodiments, the memory 71 may be an internal storage unit of the electronic device 7, such as a hard disk or memory of the electronic device 7. In other embodiments, the memory 71 may be an external storage device of the electronic device 7, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 7. Furthermore, the memory 71 may include both internal and external storage units of the electronic device 7. The memory 71 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 71 can also be used to temporarily store data that has been output or will be output.

[0097] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0098] This application provides a computer program product that, when run on an electronic device, causes the electronic device to perform the steps in any of the above method embodiments.

[0099] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to an electronic device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0100] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0101] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0102] In the embodiments provided in this application, it should be understood that the disclosed electronic devices and methods can be implemented in other ways. For example, the electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0103] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0104] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for dynamically orchestrating service call chains, characterized in that, include: Obtain real-time status information of each service node in the service call chain; wherein, the real-time status information includes service response time, service success rate and service resource consumption value, and the service call chain includes service nodes in the core processing area and the auxiliary processing area; The service nodes whose service parameters need to be optimized are determined based on the real-time status information of each node; wherein, the service parameters include traffic control parameters, resource allocation parameters, and timeout control parameters. Determine the correlation between the service parameters of each service node in the service call chain and the overall performance indicators; wherein, the overall performance indicators include end-to-end latency and system throughput; Based on the preset performance index range and the correlation, the first optimization parameter of the service node that needs to be optimized in the core processing area is determined; Based on the first optimization parameters, the second optimization parameters for the service nodes that need to be optimized in the auxiliary processing area are determined.

2. The service call chain dynamic orchestration method as described in claim 1, characterized in that, The method further includes: If the rate of change of the real-time status information is determined to be greater than a preset threshold, the performance of each service node in the service call chain is evaluated with confidence, and a performance confidence value for each service node is generated. The flow control parameters are adjusted based on the performance confidence value.

3. The service call chain dynamic orchestration method as described in claim 2, characterized in that, Adjusting the flow control parameters based on the performance confidence value includes: When it is determined that the service nodes in the service call chain need to be adjusted based on the performance confidence value, the node status is determined according to the real-time status information; wherein, the node status is used to reflect the real-time performance status of each service node; The node priority is obtained by fusing and identifying the node status and the service call chain's operational scenario information; wherein, the operational scenario information includes request frequency and business priority. The flow control parameters are adjusted according to the node priority.

4. The service call chain dynamic orchestration method as described in claim 3, characterized in that, The method further includes: If adjustments to service nodes in the service call chain are determined based on the real-time status information, the resource allocation parameters and timeout control parameters are optimized according to the real-time status information and the running scenario information.

5. The service call chain dynamic orchestration method as described in claim 1, characterized in that, The process of obtaining real-time status information of each service node in the service call chain includes: Obtain historical request data; wherein, the historical request data includes arrival time, service time, and response time; The mean service time is obtained by fitting the exponential distribution parameters using the maximum likelihood estimation based on the historical request data. The queuing time is calculated based on the average service time and the historical request data. The service response time is obtained based on the queuing time and the service time.

6. The service call chain dynamic orchestration method as described in claim 5, characterized in that, The process of determining the service nodes whose service parameters need optimization based on the real-time status information includes: The path length is obtained by inputting the real-time status information as features into the isolated forest model; wherein, the isolated forest model is trained based on the historical request data; An anomaly score is calculated based on the path length; wherein, the anomaly score is used to quantify the anomaly probability of each of the service nodes; The service nodes whose service parameters need optimization are identified based on the anomaly scores.

7. The service call chain dynamic orchestration method as described in claim 1, characterized in that, The step of determining the first optimization parameters of the service nodes requiring optimization in the core processing region based on the preset performance index range and the correlation includes: An objective function is constructed based on the aforementioned correlation; wherein, the objective function is used to quantify the optimization objective, which includes minimizing response time and maximizing resource utilization. Calculate the solution set based on the objective function; The first optimization parameter is obtained by selecting a solution from the solution set that satisfies the preset performance index range.

8. The service call chain dynamic orchestration method as described in claim 1, characterized in that, The step of determining the second optimization parameters of the service nodes in the auxiliary processing region that need to be optimized based on the first optimization parameters includes: The load prediction value is obtained based on the first optimization parameters; wherein, the load prediction value includes the number of requests and the number of concurrent requests; The asynchronous call ratio is calculated based on the load forecast and the maximum throughput of the core processing area; wherein, the asynchronous call ratio refers to the proportion of requests processed asynchronously in the auxiliary processing area to the total number of requests; The second optimized parameter for the service parameters of the auxiliary processing area is obtained based on the asynchronous call ratio.

9. A dynamic orchestration system for service call chains, characterized in that, include: The acquisition module is used to acquire real-time status information of each service node in the service call chain; wherein, the real-time status information includes service response time, service success rate and service resource consumption value, and the service call chain includes service nodes in the core processing area and the auxiliary processing area; The service node module is used to determine the service nodes whose service parameters need to be optimized based on the real-time status information; wherein the service parameters include traffic control parameters, resource allocation parameters, and timeout control parameters. The correlation module is used to determine the correlation between the service parameters of each service node in the service call chain and the overall performance indicators; wherein, the overall performance indicators include end-to-end latency and system throughput. The first optimization parameter module is used to determine the first optimization parameters of the service node that needs to be optimized in the core processing area based on the preset performance index range and the correlation relationship. The second optimization parameter module is used to determine the second optimization parameters of the service node that needs to be optimized in the auxiliary processing area based on the first optimization parameters.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 8.

Images