Request scheduling method and device

Abstract

The invention provides a request scheduling method and device, the method is applied to a reverse proxy gateway, the reverse proxy gateway is deployed between a client and a plurality of service nodes, the method comprises the following steps: based on a preset trigger condition, collecting multi-dimensional performance indexes of the plurality of service nodes, and aiming at each-dimensional performance index, scheduling the service nodes according to the multi-dimensional performance indexes; calculating a smooth value of the performance index based on historical data of the performance index in the sliding time window; calculating a dynamic health degree index of each service node based on the smoothing value of the multi-dimensional performance index; for each service node, calculating a comprehensive scheduling score of the service node according to the dynamic health degree index, the real-time concurrent connection number and the dynamic weight factor; and based on the comprehensive scheduling score, selecting a target node with optimal comprehensive evaluation among the health degree, the real-time external load and the historical response feedback from the plurality of service nodes, and forwarding the client request to the target node. According to the invention, the client request can be allocated to the appropriate node, and the service performance and the overall stability are comprehensively improved.

Description

Technical Field

[0001] This application belongs to the field of computer science, and specifically relates to a request scheduling method and apparatus. Background Technology

[0002] A distributed system is a system composed of multiple independent computing nodes interconnected through a network. These nodes work collaboratively, appearing as a unified system to the outside world, capable of sharing resources, coordinating computing tasks, and providing reliable services. A reverse proxy, located between the client and server, is an intermediate layer used to receive client requests and forward them to internal service nodes. It can hide the internal network structure and achieve load balancing.

[0003] In existing distributed systems and microservice architectures, mainstream reverse proxy systems, such as Nginx and HAProxy, generally employ static or semi-static algorithms for load balancing and scheduling. These algorithms lack real-time awareness and dynamic feedback capabilities regarding the status of backend nodes during runtime, specifically manifesting in the following fixed patterns: 1. Round-robin: Distribute requests sequentially according to a preset order, ignoring differences in node load.

[0004] 2. Least connections: This method makes decisions based solely on the number of instantaneous connections, without considering the node's processing capacity.

[0005] 3. Weighted random: Traffic is allocated based on preset fixed weights, and the weights cannot be adjusted according to changes in node performance.

[0006] The aforementioned simple, fixed algorithm lacks the ability to perceive and dynamically respond to the node's operating status in large-scale distributed environments where node states and network conditions are highly dynamic (such as real-time fluctuations in CPU (Central Processing Unit) load, memory usage, thread pool congestion, link latency, and jitter). This can easily lead to the following problems: 1. The existing system lacks a mechanism for continuous collection of node indicators, making it unable to obtain sufficient historical data sequences. Scheduling decisions can only be based on instantaneous sampled values, which are greatly affected by instantaneous jitter and are prone to problems such as "frequent switching" or "incorrect judgment of node status", leading to system instability.

[0007] 2. The node priority cannot be automatically adjusted based on the real-time performance of the node (such as response timeout or error), resulting in erroneous nodes being continuously selected.

[0008] In summary, the static load balancing mechanism of traditional reverse proxies lacks dynamic perception and feedback capabilities, which can easily distribute requests to unsuitable nodes, leading to increased response latency, request backlog, and even triggering an avalanche effect, thereby affecting the availability and stability of the system. Summary of the Invention

[0009] In view of the above problems, embodiments of this application provide a request scheduling method and apparatus that overcomes or at least partially solves the above problems.

[0010] In a first aspect, embodiments of this application provide a request scheduling method applied to a reverse proxy gateway, wherein the reverse proxy gateway is deployed between a client and multiple service nodes, and the method includes: Based on preset triggering conditions, multi-dimensional performance indicators of the multiple service nodes are collected, and for each performance indicator, a smoothed value of the performance indicator is calculated based on historical data of the performance indicator within a sliding time window. For each service node, a dynamic health index is calculated based on the smoothed value of the multidimensional performance indicators corresponding to the service node. The dynamic health index comprehensively represents the health status of the service node. For each service node, a comprehensive scheduling score is calculated based on the service node's dynamic health index, real-time concurrent connections, and dynamic weight factor. The dynamic weight factor of the service node is dynamically adjusted based on the service node's historical response results for handling client requests. Based on the comprehensive scheduling scores corresponding to the multiple service nodes, a target node is selected from the multiple service nodes, and the received client requests are forwarded to the target node. The target node is the service node that is optimally evaluated based on the comprehensive scheduling scores, considering health, real-time external load, and historical response feedback. The dynamic weighting factor is a quantitative representation of the historical response feedback.

[0011] Secondly, embodiments of this application provide a request scheduling device applied to a reverse proxy gateway, wherein the reverse proxy gateway is deployed between a client and multiple service nodes, and the device includes: The data acquisition and calculation module is used to collect multi-dimensional performance indicators of the multiple service nodes based on preset triggering conditions, and to calculate the smoothed value of each performance indicator based on historical data of the performance indicators within a sliding time window. The calculation module is used to calculate the dynamic health index of each service node based on the smoothed value of the multidimensional performance index corresponding to the service node. The dynamic health index comprehensively represents the health status of the service node. The calculation and processing module is used to calculate the comprehensive scheduling score of each service node based on its dynamic health index, real-time concurrent connection count, and dynamic weight factor. The dynamic weight factor of the service node is dynamically adjusted based on the historical response results of the service node in processing client requests. The scheduling module is used to select a target node from the multiple service nodes based on the comprehensive scheduling scores corresponding to each of the multiple service nodes, and forward the received client requests to the target node. The target node is the service node that is optimally evaluated based on the comprehensive scheduling scores, considering health, real-time external load, and historical response feedback. The dynamic weighting factor is a quantitative representation of the historical response feedback.

[0012] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0013] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0014] In this embodiment, based on preset triggering conditions, multi-dimensional performance indicators corresponding to multiple service nodes are collected. For each performance indicator, a smoothed value is calculated based on historical data within a sliding time window. For each service node, a dynamic health index is calculated based on the smoothed value of the multi-dimensional performance indicators corresponding to the service node. By fusing the smoothed values ​​of the multi-dimensional performance indicators, the comprehensive performance of the service node can be quantified into a unified, cross-dimensionally comparable value, thereby achieving dynamic quantification of the comprehensive health status of the service node. For each service node, a dynamic weighting factor is adjusted based on the dynamic health index, the real-time concurrent connection count, and the historical response results of the service node in handling client requests. Calculating the comprehensive scheduling score allows for simultaneous consideration of the service node's intrinsic health status and real-time external load, avoiding biases caused by relying solely on a single dimension for decision-making. Furthermore, by combining adaptive adjustments with dynamic weighting factors, it enables dynamic correction of service node priorities, improving scheduling stability in scenarios with fluctuating service node status. Based on the comprehensive scheduling score, the target node is selected from multiple service nodes based on a comprehensive evaluation of health, real-time external load, and historical response feedback. Receiving client requests is then forwarded to the target node, ensuring that requests are allocated to appropriate nodes. This not only accelerates the response speed of individual requests but also effectively prevents local node overload, thereby achieving a comprehensive improvement in service performance and overall stability. Attached Figure Description

[0015] Figure 1 This is an implementation architecture diagram of the request scheduling method provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the implementation of the request scheduling method provided in this application embodiment; Figure 3 This is a flowchart illustrating the implementation of the dynamic health index of the computing service node provided in this application embodiment; Figure 4 This is a flowchart illustrating the implementation of updating the dynamic health index based on the request execution result, as provided in this application embodiment. Figure 5 This is a schematic diagram of the request scheduling device provided in an embodiment of this application; Figure 6 A schematic diagram of the electronic device structure provided in an embodiment of this application is shown. Detailed Implementation

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

[0017] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0018] The request scheduling method provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0019] The request scheduling method provided in this application embodiment is applied to a reverse proxy gateway, such as... Figure 1 As shown, the reverse proxy gateway is deployed between the client and multiple service nodes, which form a service cluster. In practical applications, the client is typically a client cluster. The reverse proxy gateway is used to receive and schedule requests from multiple clients; for example, Figure 1 Only one client is shown to illustrate the communication relationship. After receiving a request from the client, the reverse proxy gateway selects a suitable service node from among multiple service nodes and forwards the client's request to the appropriate service node for processing. For example... Figure 2 As shown, the method includes the following steps: Step 201: Based on preset trigger conditions, collect multi-dimensional performance indicators of multiple service nodes, and calculate the smoothing value of each performance indicator based on historical data of the performance indicators within the sliding time window.

[0020] When a preset trigger condition is detected, the reverse proxy gateway collects multi-dimensional performance metrics for each service node. The preset trigger conditions may be time-based or event-based. The reverse proxy gateway collects multi-dimensional performance metrics when it detects these preset time-based and / or event-based trigger conditions.

[0021] As an optional implementation, data acquisition is accomplished through lightweight data probes deployed on each service node. These lightweight data probes are embedded or attached to the service nodes in the form of proxies. These probes are used to efficiently and with low overhead capture multi-dimensional performance indicators reflecting the operational status of the service nodes in real time, providing a reliable basis for decision-making. The reverse proxy gateway actively pulls or receives data reported from each data probe, thus forming a complete data acquisition chain and providing a real-time and reliable basis for scheduling decisions.

[0022] After collecting multi-dimensional performance metrics from multiple service nodes based on preset trigger conditions, the reverse proxy gateway calculates smoothed performance metrics for each service node based on historical data within a sliding time window. This process suppresses transient jitter noise and yields stable, smoothed metric values ​​that reflect the performance trends of the service nodes, preventing scheduling decisions from oscillating due to transient interference. The duration of the sliding time window can be configured according to actual needs.

[0023] Step 202: For each service node, calculate the dynamic health index of the service node based on the smoothed value of the multi-dimensional performance indicators corresponding to the service node. The dynamic health index comprehensively represents the health status of the service node.

[0024] For each service node, after calculating the smoothed values ​​of each performance metric, a dynamic health index is calculated based on the smoothed values ​​of the multi-dimensional performance metrics corresponding to the service node. The calculated dynamic health index comprehensively represents the health status of the service node and is positively correlated with the health level of the service node; for example, the higher the dynamic health index of a service node, the healthier the service node is.

[0025] Step 203: For each service node, calculate the comprehensive scheduling score of the service node based on the dynamic health index, real-time concurrent connection count, and dynamic weight factor. The dynamic weight factor of the service node is dynamically adjusted based on the historical response results of the service node in processing client requests.

[0026] In addition to calculating the dynamic health index of a service node based on the smoothed values ​​of the multi-dimensional performance indicators corresponding to each service node, it is also necessary to consider the real-time concurrent connection count and the dynamic weight factor of the service node (which is dynamically adjusted based on the historical response results of the service node in handling client requests) for each service node. The comprehensive scheduling score of the service node is then calculated based on the dynamic health index, the real-time concurrent connection count, and the dynamic weight factor.

[0027] The real-time concurrent connection count of a service node is the total number of active, established connections between the reverse proxy gateway and the service node. It indicates the external load of the service node and is a key quantitative indicator characterizing the real-time external load of the service node (the larger the real-time concurrent connection count, the larger the real-time external load, and the smaller the real-time concurrent connection count, the smaller the real-time external load). This value directly reflects the concurrent request pressure that the service node is currently processing.

[0028] The dynamic weight factor of a service node can be corrected in a closed loop based on the historical scheduling results of the service node. For example, by recording the actual response result of the service node to the client request (the result is the historical response result), the dynamic weight factor can be adjusted to correct the factor. This enables the adjustment of the service node priority based on the adaptive adjustment mechanism, thereby improving the scheduling stability in scenarios with fluctuating service node status.

[0029] For each service node, a comprehensive scheduling score is calculated by combining a dynamic health index and the number of concurrent connections in real time. This can take into account the service capacity and current pressure of the service node, overcome the limitations of relying on a single dimension for decision-making, and by combining dynamic weight factors, the priority of service nodes can be adjusted based on an adaptive adjustment mechanism to achieve closed-loop control based on a feedback mechanism, thereby dynamically avoiding unsuitable service nodes and improving scheduling stability.

[0030] Step 204: Based on the comprehensive scheduling scores corresponding to multiple service nodes, select the target node from among the multiple service nodes and forward the received client requests to the target node. The target node is the service node that is determined based on the comprehensive scheduling score and is the best in terms of health, real-time external load and historical response feedback. The dynamic weight factor is a quantitative representation of historical response feedback.

[0031] After calculating the comprehensive scheduling score of multiple service nodes, the service node with the best comprehensive evaluation among the multiple service nodes in terms of health, real-time external load and historical response feedback is selected based on the comprehensive scheduling score. The selected service node is used as the target node, and the currently received client requests are forwarded to the target node to select the appropriate service node from the multiple service nodes, and the appropriate service node handles the client requests.

[0032] Real-time external load specifically refers to the external pressure from client requests, characterized by the number of real-time concurrent connections; health is characterized by a dynamic health index, reflecting the internal resource and performance status of the service node; historical response feedback is carried by a dynamic weighting factor (historical response feedback is quantified through the dynamic weighting factor of the service node), which is dynamically adjusted based on the historical response results (such as success, failure, and timeout) of the service node in handling client requests; by seeking the optimal service node through a comprehensive evaluation of these three factors, the target node is selected. For example, ideally, the target node is the node that simultaneously possesses the best health status, the minimum real-time external load, and the best historical feedback performance; in practice, it is usually represented by the optimal service node comprehensively evaluated under multi-dimensional constraints.

[0033] By comprehensively considering the health of service nodes, real-time external load, and dynamic weighting factors, the optimal target node is selected based on comprehensive evaluation. The current client request is then sent to the most suitable target node, which enables intelligent scheduling of requests, reduces the response latency and failure risk of a single request, and maximizes the overall throughput of the service cluster.

[0034] After selecting a target node, one or more received client requests can be forwarded to that node. Typically, a single-request-level forwarding strategy is used, meaning each client request independently undergoes a complete scheduling decision process, ensuring that each scheduling is based on the latest and most accurate service node status.

[0035] The above-described implementation scheme of this application, based on preset triggering conditions, collects multi-dimensional performance indicators corresponding to multiple service nodes. For each performance indicator, a smoothed value is calculated based on historical data of the performance indicator within a sliding time window. For each service node, a dynamic health index is calculated based on the smoothed value of the multi-dimensional performance indicators corresponding to the service node. By fusing the smoothed values ​​of the multi-dimensional performance indicators, the comprehensive performance of the service node can be quantified into a unified, cross-dimensionally comparable value, thereby achieving dynamic quantification of the comprehensive health status of the service node. For each service node, a dynamic weighting factor is adjusted based on the dynamic health index, the real-time concurrent connection count, and the historical response results of the service node in handling client requests. Calculating the comprehensive scheduling score allows for simultaneous consideration of the service node's intrinsic health status and real-time external load, avoiding biases caused by relying solely on a single dimension for decision-making. Furthermore, by combining adaptive adjustments with dynamic weighting factors, it enables dynamic correction of service node priorities, improving scheduling stability in scenarios with fluctuating service node status. Based on the comprehensive scheduling score, the target node is selected from multiple service nodes based on a comprehensive evaluation of health, real-time external load, and historical response feedback. Receiving client requests is then forwarded to the target node, ensuring that requests are allocated to appropriate nodes. This not only accelerates the response speed of individual requests but also effectively prevents local node overload, thereby achieving a comprehensive improvement in service performance and overall stability.

[0036] As an optional embodiment of this application, the comprehensive scheduling score is negatively correlated with the dynamic health index and positively correlated with the real-time concurrent connection count and the dynamic weight factor, and the dynamic health index of the service node is positively correlated with the health level of the service node; when selecting a target node from multiple service nodes based on the comprehensive scheduling scores corresponding to multiple service nodes, the following is included: Select the service node with the lowest comprehensive scheduling score from among multiple service nodes, and determine the selected service node as the target node; The adjustment rule for the dynamic weighting factor is as follows: if the historical response result fails or times out, the dynamic weighting factor is increased; if the historical response result indicates continuous success, the dynamic weighting factor is decreased.

[0037] The dynamic health index in this application embodiment is positively correlated with the health level of the service node; the real-time concurrent connection count is positively correlated with the real-time external load, that is, the larger the real-time concurrent connection count, the larger the real-time external load; the dynamic weight factor is dynamically adjusted based on the historical response results of the service node in processing client requests: if the historical response result fails or times out, the dynamic weight factor is increased; if the historical response result indicates continuous success, the dynamic weight factor is decreased. That is, the better the historical response result (such as continuous successful response), the smaller the value of the dynamic weight factor. From another perspective, the dynamic weight factor can be regarded as a penalty factor. The better the dynamic weight factor (the smaller the value), the higher the historical reliability of the service node, and the lighter the penalty it should receive in scheduling. The larger the dynamic weight factor, the lower the historical reliability of the service node, and the heavier the penalty it should receive in scheduling.

[0038] To select service nodes that are healthy, lightly loaded, and have a favorable dynamic weighting factor (small dynamic weighting factor), the designed comprehensive scheduling score is negatively correlated with the dynamic health index, but positively correlated with the real-time concurrent connection count and the dynamic weighting factor. Based on this, when selecting a target node from multiple service nodes, the service node with the lowest comprehensive scheduling score is selected, thus identifying the service node with high health, few connections, and a favorable dynamic weighting factor as the appropriate target node.

[0039] When selecting target nodes, priority is given to service nodes with the highest health, the fewest real-time connections, and the optimal dynamic weighting factor. However, in practical applications, these three factors often cannot be simultaneously optimized. Therefore, a comprehensive scheduling score is introduced to achieve a trade-off: this score is designed to be negatively correlated with health and positively correlated with real-time concurrent connections and the dynamic weighting factor. Ultimately, the service node with the lowest comprehensive scheduling score is selected, thus choosing the service node that is optimal in terms of a comprehensive evaluation of health, real-time external load, and historical response feedback.

[0040] By calculating a comprehensive scheduling score for each service node that is negatively correlated with the dynamic health index and positively correlated with the real-time concurrent connection count and dynamic weight factor, the service node with the lowest score among multiple service nodes is selected as the target node based on the comprehensive scheduling score. This approach comprehensively considers the health of the service node, the external load, and the performance of historical request processing to determine the optimal service node. This avoids allocating requests to service nodes that are healthy but overloaded, service nodes with light external load but potential health risks, and service nodes that are in acceptable real-time condition but have unreliable historical response performance.

[0041] The process of triggering the collection of multidimensional performance metrics from service nodes is described below. When collecting multidimensional performance metrics from multiple service nodes based on preset triggering conditions, at least one of the following is included: Collect multi-dimensional performance indicators of multiple service nodes according to the preset collection cycle; Based on preset trigger events, multi-dimensional performance indicators of multiple service nodes are collected. The preset trigger events include at least one of the following: service node abnormal events, service node change events, and external command events.

[0042] The reverse proxy gateway collects multi-dimensional performance metrics from multiple service nodes based on at least one of time-triggered and event-triggered conditions. These multi-dimensional performance metrics include, for example, at least two of CPU utilization, memory utilization, request response time, request error rate, and network latency.

[0043] For scenarios involving the collection of multi-dimensional performance metrics based on time-triggered conditions, the reverse proxy gateway collects multi-dimensional performance metrics from multiple service nodes according to a preset collection period. In other words, the reverse proxy gateway periodically collects multi-dimensional performance metrics from service nodes. For example, the collection period can be set to 0.5 seconds, 1 second, or other time values ​​as needed. The reverse proxy gateway collects multi-dimensional performance metrics from multiple service nodes at specific time intervals to achieve regular and continuous monitoring of the service nodes.

[0044] For scenarios involving the collection of multi-dimensional performance metrics based on event-triggered conditions, the reverse proxy gateway initiates the collection of multi-dimensional performance metrics for multiple service nodes in response to at least one of the following: abnormal service node events, service node change events, and external command events. For example, the reverse proxy gateway might trigger the collection of multi-dimensional performance metrics for multiple service nodes when it detects an abnormal event (such as persistently high CPU utilization or a sudden increase in request error rate); similarly, it might trigger the collection of multi-dimensional performance metrics for multiple service nodes when it detects a service node change event (such as detecting a new service node coming online, an existing service node going offline, or being removed); or it could trigger the collection of multi-dimensional performance metrics for multiple service nodes upon receiving an external command event (such as receiving a collection command from an administrator).

[0045] By collecting multi-dimensional performance indicators of service nodes based on time-triggered conditions, we can periodically understand the overall operating trend of multiple service nodes; by collecting multi-dimensional performance indicators of service nodes based on event-triggered conditions, we can promptly understand the status of service nodes when changes occur; the data collection mechanism that integrates time-triggered and event-triggered conditions can balance the comprehensiveness of routine monitoring with the real-time nature of event response, providing a data foundation for subsequent scheduling.

[0046] The following describes the process of calculating the dynamic health index of service nodes. Before calculating the dynamic health index, it is necessary to calculate the smoothed values ​​of the performance indicators for each dimension. When calculating the smoothed values ​​of the performance indicators for each dimension based on historical data of the performance indicators within the sliding time window, the following steps are involved: The EWMA exponentially weighted moving average smoothing process is applied to each performance index using Formula 1 to obtain the smoothed values ​​for each performance index: Formula 1 in, This represents the smoothed value of the performance metric at the current moment. This represents the aggregated sample value of the performance metric at the current moment. Represents the smoothing coefficient. This represents the smoothed value maintained by the performance metric before this calculation. This value is obtained through recursive calculation and is equivalent to performing an exponentially weighted average of the historical data of the performance metric within the sliding time window.

[0047] For each of the multiple service nodes, after collecting multi-dimensional performance metrics, a time-series smoothing mechanism called EWMA (Exponentially Weighted Moving Average) is used to smooth each performance metric, resulting in a smoothed value for each dimension. Service node performance metrics (such as CPU utilization, request response time, and request error rate) often exhibit momentary fluctuations (noise). EWMA can smooth noise, preserve performance trends, and maintain high sensitivity to recent changes, thus achieving stable and responsive state awareness.

[0048] As an aggregated sample value, it refers to a representative statistical value obtained by continuously measuring the corresponding performance metric within the statistical period between the current collection time and the previous collection time. Its specific calculation method depends on the characteristics of the metric. For example, CPU utilization and memory utilization are the average utilization rates within this statistical period; request response time is the average response time of all requests within this statistical period; request error rate is the proportion of erroneous requests within this statistical period; and network latency is the average network round-trip time within this statistical period. For the periodic collection of multi-dimensional performance metrics, the length of the statistical period is the same as the length of the collection period.

[0049] parameter Its functions are as follows: The closer it is to 1, the more it relies on the latest samples, reacts faster, and can quickly track real changes, but it is also more susceptible to transient noise. The closer to 0, the smoother the response, the slower the reaction, and the stronger the noise resistance. In practical applications, Common recommended values ​​are between 0.2 and 0.5. For example, tests have shown that a value of 0.3-0.5 is the optimal range. Within this range, as much trend information of the performance metric is retained as much as possible, while also maintaining high sensitivity.

[0050] This represents the smoothed value of the performance metric maintained before this calculation. It is a state variable in the EWMA algorithm, obtained recursively, and is equivalent to performing an exponentially weighted average of the historical data of the performance metric within the sliding time window. For example, in a periodic data acquisition scenario, if the current period is the t-th acquisition period... This represents the smoothed value calculated and saved at the end of the previous acquisition cycle. After each calculation is completed, the previous smoothed value will be updated immediately with the new smoothed value, thus achieving recursive smoothing.

[0051] The standard EWMA algorithm uses exponentially weighted information from all historical data. In this embodiment, older historical data is not very valuable, so the smoothed value is calculated recursively. Its effect is equivalent to performing an exponentially weighted average of historical data within a sliding time window, thereby enabling calculations based on recent data.

[0052] By calculating the smoothed value of the performance indicators based on historical data of the performance indicators within the sliding time window using the above formula, the performance indicators of the service nodes can be smoothed in time, reducing instantaneous noise interference while preserving the trend of the performance indicators.

[0053] Specifically, after calculating the smoothed values ​​of performance metrics, when calculating the dynamic health index of a service node based on the smoothed values ​​of the multi-dimensional performance metrics corresponding to the service node, the following are included: Figure 3 The following steps are shown: Step 301: Map the smoothed values ​​of the performance indicators of each dimension corresponding to the service node to a unified scaling range according to preset rules.

[0054] Step 302: The performance index values ​​of each dimension mapped to a unified scaling interval are weighted and summed together with their corresponding weights to obtain the dynamic health index of the service node.

[0055] Since the dimensions of multidimensional performance indicators are different, direct addition is meaningless. By mapping the smoothed values ​​of each performance indicator to a unified scaling interval according to preset rules (such as normalizing and projecting to the same range), it is easier to fuse the multidimensional performance indicators in the future.

[0056] Among them, the numerical values ​​of each performance index mapped to a unified scaling interval are positively correlated with the index quality. As a specific implementation method, the following formula (such as Formula 4) is used to map performance indices of different dimensions to [0, 1], and higher values ​​represent better indices.

[0057] (Formula 4) This represents the numerical value of a performance metric that is mapped to a uniform scaling range. This represents the actual smoothed value of the performance metric. This represents the minimum smoothed value of the performance metric. This represents the maximum smoothed value of the performance metric. and It can be dynamically calculated based on historical experience to avoid distortion caused by extreme values.

[0058] Since the multidimensional performance metrics of a service node include at least two of the following: CPU utilization, memory utilization, request response time, request error rate, and network latency, lower values ​​for each metric indicate better performance. The smaller, The higher the value, the better the metric quality. Specifically: lower CPU utilization and memory utilization indicate a lighter resource load, better health, and stronger ability to handle subsequent requests, thus resulting in better metric quality; lower request response time and network latency indicate a faster response speed to clients, thus resulting in better metric quality; and lower request error rate indicates a higher success rate and stability of the service node, thus resulting in better metric quality.

[0059] By mapping performance indicators of different dimensions to a unified scaling range based on Formula 4, a foundation is provided for comprehensively evaluating performance indicators of different dimensions; and higher values ​​represent better indicators, so that the level of indicator values ​​can directly reflect the performance of service nodes.

[0060] Optionally, in step 302, the performance index values ​​of each dimension mapped to a unified scaling interval are weighted and summed with their corresponding weights to obtain the dynamic health index of the service node, including: Based on the currently effective weight configuration, the indicator values ​​of each performance indicator that will be mapped to a unified scaling range are weighted and calculated to obtain the dynamic health index corresponding to the service node. The dynamic health index is a comprehensive index that integrates multiple performance indicators to assess the health of the service node. The weights corresponding to each performance metric can be dynamically adjusted based on at least one of the preset strategy, historical scheduling results, and machine learning model.

[0061] After mapping the smoothed values ​​of each performance indicator to a unified scaling range to obtain the indicator values ​​of each performance indicator, the indicator values ​​of each performance indicator are weighted and calculated based on the currently effective weight configuration associated with the multi-dimensional performance indicators. The dynamic health index corresponding to the service node is obtained through weighted calculation. The obtained dynamic health index is a comprehensive index that integrates the multi-dimensional performance indicators to assess the health of the service node.

[0062] As a specific implementation method, the following formula (such as Formula 5) is used to perform weighted calculations on the performance index values ​​of each dimension that are mapped to a unified scaling interval to determine the dynamic health index of the service node.

[0063] Formula 5 This refers to a metric value that represents a smoothed value of CPU utilization mapped to a uniform scaling range. This represents a metric value that smooths out memory utilization and maps it to a uniform scaling range. This represents a metric value that smooths the request response time to a uniform scaling range. This represents a metric value that smooths the request error rate to a uniform scaling range. A metric value representing the smoothed value of network latency mapped to a uniform scaling interval; , , , , These are the weights for each performance metric, used to indicate the importance of the performance metric. The weights can be dynamically adjusted based on at least one of a preset strategy, historical scheduling results, and machine learning models. By weighting and merging the metric values ​​mapped to a unified scaling interval according to the importance of each performance metric, a single comparable dynamic health index H is obtained. This enables better integration of multiple metrics to score the health of service nodes.

[0064] The weights corresponding to each performance metric can be dynamically adjusted based on preset strategies. For example, if the volatility of a certain performance metric exceeds a preset threshold, its weight can be dynamically reduced to suppress excessive interference from noise in the health assessment. The weights corresponding to each performance metric can also be dynamically adjusted based on historical scheduling performance. For example, if a selected high-health service node consistently performs poorly in subsequent request processing over a period of time, the weights of certain performance metrics that contribute excessively to the dynamic health index can be reduced. Finally, the weights corresponding to each performance metric can be dynamically adjusted based on machine learning models. For example, a reinforcement learning model can be constructed, taking historical multi-dimensional performance metrics and weight configurations as input, and global performance (such as a reduction in global average latency) as a reward signal. Through continuous training, the weight configuration can be optimized.

[0065] By using a weighted calculation method to determine the dynamic health index, the health assessment of service nodes can be integrated with multi-dimensional performance indicators to obtain a comprehensive assessment result. By dynamically adjusting the weights of each performance indicator, the focus on different performance indicators can be intelligently adjusted to adapt to different scenarios and achieve continuous optimization of weights.

[0066] In an optional embodiment of this application, the method further includes: In response to the detection of abnormal service nodes among multiple service nodes, a decay and recovery process is triggered, and the dynamic health index of the abnormal service nodes is updated based on Formula 2: Formula 2 This is the updated dynamic health index. The previous dynamic health index. The attenuation coefficient is... This is a recovery term used to smooth out the rebound; In response to the abnormal service node returning to normal and remaining so for a period of time, exit the current decay and recovery process and resume the dynamic health index calculation process based on weighted summation; The abnormal conditions of abnormal service nodes include at least one of the following: network connection interruption or heartbeat loss, sudden change in performance indicators, sudden change in dynamic health index, or receiving a node failure warning.

[0067] When the service node is normal, the dynamic health index is calculated through the dynamic health index calculation process to update the dynamic health index. If an abnormal service node is identified, the decay and recovery process is triggered. This process is to protect the service node from sudden abnormalities. Its purpose is to quickly isolate the abnormal service node when an abnormality occurs and smoothly restore its service after the abnormality is eliminated.

[0068] Abnormal service node conditions include at least one of the following: network connection interruption or heartbeat loss, sudden change in performance metrics, sudden change in dynamic health index, or receipt of a node failure warning. For example, if a service node fails in multiple consecutive connection attempts, or if the reverse proxy gateway fails to receive any heartbeat packets from the service node for an extended period, the service node is determined to be an abnormal service node. Alternatively, if one or more performance metrics of the service node change drastically, the service node is determined to be an abnormal service node. Or, if the dynamic health index of the service node changes drastically, the service node is determined to be an abnormal service node. Furthermore, if a node failure warning is received for a specific service node, that service node is determined to be an abnormal service node.

[0069] After identifying an abnormal service node among multiple service nodes, instead of calculating the dynamic health index of that abnormal service node through the dynamic health index calculation process, it is necessary to directly trigger the decay and recovery process for that abnormal service node, updating its dynamic health index based on Formula 2 mentioned above. In Formula 2, As a decay factor (e.g., 0.2–0.5), it is used for rapid weight reduction and recovery terms. Smaller values ​​(e.g., 0.01–0.05) are used for smooth recovery. When calculated using Formula 2, the updated dynamic health index is significantly lower than before the update, thus leading to isolation in subsequent scheduling decisions due to a high overall scheduling score, preventing the receipt of new requests. As a recovery measure, it ensures that the dynamic health index recovers at an extremely slow rate when service nodes are isolated.

[0070] The performance metrics of this service node need to be monitored in real time. When these performance metrics continuously return to normal and stabilize within a preset range over multiple consecutive monitoring periods, the anomaly of the service node is considered to have been eliminated. At this point, the attenuation and recovery process needs to be exited immediately, and the conventional dynamic health index calculation process based on multi-dimensional performance metric collection, EWMA smoothing, and weighted summation should be resumed to calculate the dynamic health index of the service node using the conventional dynamic health index calculation process.

[0071] In the above implementation process, when abnormal service nodes are identified, they are quickly isolated to prevent them from receiving new requests, thus ensuring business continuity. This provides a solution for dealing with sudden service node anomalies and provides a basic guarantee for maintaining the stability and reliability of the entire service cluster.

[0072] The following describes the process of calculating the comprehensive scheduling score based on the dynamic health index, real-time concurrent connections, and dynamic weighting factors. The calculation of the comprehensive scheduling score for a service node includes: Based on the service node's dynamic health index, real-time concurrent connections, and dynamic weighting factor, Formula 3 is used to calculate the service node's comprehensive scheduling score: Formula 3 in, Let represent the overall scheduling score of the i-th service node. This represents the dynamic health index of the i-th service node. Represents a constant greater than 0. This represents the number of concurrent connections in real time for the i-th service node. This represents the dynamic weight factor of the i-th service node, where i ranges from 1 to m, and m is the number of service nodes. The dynamic weighting factor is dynamically adjusted based on the historical response results of the service node in handling client requests: it increases if the service node fails to respond or times out, and decreases if the service node provides consecutive successful responses. Different service nodes have their own independent dynamic weighting factor, and the dynamic weighting factor of a service node is dynamically adjusted according to the historical response results of the service node in handling requests.

[0073] For any given service node, its overall scheduling score is based on a dynamic health index and a constant. Real-time concurrent connections and dynamic weighting factors Determined. Constant For example, a pre-set small constant greater than 0, based on The range of values ​​for a given value is determined, for example, the constant. for or In the above formula The system converts higher health scores into lower scores, prioritizing higher health scores, based on real-time concurrent connections and constants. And when the dynamic weighting factor is fixed, The larger the value, the lower the overall scheduling score. There is a negative correlation between the overall scheduling score and the overall scheduling score. Positively correlated with the overall scheduling score, under the condition that other parameters are fixed, The smaller the value, the lower the overall scheduling score. The larger the value, the higher the overall scheduling score; dynamic weight factor Positively correlated with the overall scheduling score, under the condition that other parameters are fixed, the dynamic weighting factor... The smaller the value, the lower the overall scheduling score; dynamic weighting factor. The higher the value, the higher the overall scheduling score.

[0074] Dynamic weighting factor The dynamic weighting factor is dynamically adjusted based on the historical response results of the service node in handling client requests. Its value reflects the historical response performance of the service node (such as its reliability). Better historical response performance (e.g., consecutive successful responses, high service node reliability) results in a higher weighting factor. The smaller the value, the worse the historical response performance (such as request processing failures or timeouts, and poor service node reliability). The larger the value, the higher the factor's closed-loop adjustment logic based on historical response results (success / failure / timeout) is: increase the factor if the response fails or times out. Consecutive successful responses reduce .

[0075] In the process of calculating the integrated scheduling score This applies to the number of concurrent connections in real time. In case of response failure or timeout, An increase in the number of concurrent connections significantly amplifies the negative impact of the real-time concurrent connection count on the score (leading to an increase in the overall scheduling score), thereby rapidly reducing the selection priority of service nodes and preventing requests from continuing to flood into those service nodes.

[0076] In this embodiment, the dynamic health index It focuses on reflecting the real-time health status of service nodes. It calculates based on the smoothed values ​​of multi-dimensional performance indicators collected in real time, and can objectively and stably assess the overall health status of service nodes. By not interfering with this, the purity of the health assessment was maintained. It focuses on reflecting the reliability of historical requests to service nodes and has a dynamic health index. Independent action. If Simultaneously affecting health, a single service node failure can lead to an excessive amplification of both the health score and the load penalty. Therefore, the processing method in this application embodiment achieves a synergy between rapid fault isolation and stable health assessment. It can quickly reduce the scheduling priority of a service node when it is abnormal, while ensuring that the health status of the service node is not excessively distorted by a single event. Thus, it maintains overall stability while improving fault tolerance and ensuring scheduling agility.

[0077] It should be noted that in this embodiment, the weighting of the dynamic health index and the number of real-time concurrent connections in the overall scheduling score is flexible. Taking Formula 3 above as an example, the weight of the dynamic health index is set to 1 by default, while the actual weight of the number of real-time concurrent connections is determined by... Dynamic adjustment. In actual deployment, fixed adjustment coefficients can be introduced for the dynamic health index and the number of real-time concurrent connections. For example, a weight of 1 can be set for the dynamic health index and a weight of 2 can be set for the number of real-time concurrent connections. Weights 1 and 2 are fixed weight coefficients used to statically adjust the basic importance ratio between health and external load. This serves as a dynamic weighting factor. Based on this ratio, external loads are further dynamically penalized or rewarded based on historical response performance, thereby achieving more refined weight control.

[0078] By analyzing the dynamic health index and constant The sum of the reciprocals of the values ​​is combined with the number of connections and dynamic weighting factors to calculate a comprehensive scheduling score. This score takes into account the health of the service node, the external load, and the performance in handling historical requests. Based on the comprehensive scheduling score, the service node with the lowest score is selected from multiple service nodes to determine the optimal service node in terms of health, real-time external load, and historical response feedback.

[0079] In an optional embodiment of this application, such as Figure 4 The method further includes the following steps: Step 401: In response to the client request being forwarded to the target node and processed, receive the request execution result returned by the target node.

[0080] Step 402: Based on the request execution result, update the relevant performance indicators of the target node. The relevant performance indicators are at least some of the indicators in the multi-dimensional performance indicators.

[0081] Step 403: Based on the latest multidimensional performance metrics corresponding to the target node, recalculate the dynamic health index of the target node to be applied to the scheduling decision of subsequent client requests.

[0082] After the client request is forwarded to the target node determined based on the comprehensive scheduling score, and the target node processes the client request, the system receives the request execution result after the target node processes the client request. The request execution result includes, for example, the processing status of the request (success or failure) and the performance data generated during the processing of the request (such as the response time of this request).

[0083] After obtaining the request execution result from the target node, the relevant performance metrics of the target node are updated based on the request execution result. These relevant performance metrics are, for example, at least some of the metrics in a multi-dimensional performance metric set, and are those that can be directly derived or updated from the feedback of a single request. For example, based on the success or failure status of this request, the successful and failed request counts of the node are updated to update the request error rate; another example is incorporating the request response time of this request into the node's request response time series to calculate a new average value, thereby updating the request response time.

[0084] After updating the relevant performance metrics of the target node, the dynamic health index of the target node is recalculated based on the latest multidimensional performance metrics corresponding to the target node. The processing results of a single request can be synchronized to the target node in a timely manner, and the target node can update its health status. In the next round of scheduling, the latest dynamic health index can be used to apply the latest dynamic health index to the scheduling decision of subsequent client requests.

[0085] In the above implementation scheme, after the target node processes the client request, the relevant performance indicators of the target node are updated based on the request execution result, and the dynamic health index of the target node is recalculated to ensure that the scheduling decision of the client request is based on the latest node status, thus guaranteeing the reliability and real-time accuracy of the scheduling decision.

[0086] It is important to note that the aforementioned update mechanism of the dynamic health index provides a stable and comprehensive health assessment, while the dynamic weighting factor provides agile feedback on the reliability of service nodes, together forming a scheduling mechanism that is both stable and agile.

[0087] This application provides a request scheduling device applied to a reverse proxy gateway, wherein the reverse proxy gateway is deployed between a client and multiple service nodes, such as... Figure 5 As shown, the device includes: The data acquisition and calculation module 51 is used to collect multi-dimensional performance indicators of the multiple service nodes based on preset triggering conditions, and to calculate the smoothed value of each performance indicator based on historical data of the performance indicators within a sliding time window. The calculation module 52 is used to calculate the dynamic health index of each service node based on the smoothed value of the multidimensional performance index corresponding to the service node. The dynamic health index comprehensively represents the health status of the service node. The calculation and processing module 53 is used to calculate the comprehensive scheduling score of each service node based on the dynamic health index, real-time concurrent connection count and dynamic weight factor of the service node. The dynamic weight factor of the service node is dynamically adjusted based on the historical response results of the service node in processing client requests. The scheduling module 54 is used to select a target node from the multiple service nodes based on the comprehensive scheduling scores corresponding to the multiple service nodes, and forward the received client requests to the target node. The target node is the service node that is optimally evaluated based on the comprehensive scheduling scores, health, real-time external load and historical response feedback. The dynamic weighting factor is a quantitative representation of the historical response feedback.

[0088] Optionally, the comprehensive scheduling score is negatively correlated with the dynamic health index and positively correlated with the real-time concurrent connection count and the dynamic weight factor, and the dynamic health index of the service node is positively correlated with the health level of the service node; the scheduling module is further used for: The service node with the lowest comprehensive scheduling score among the multiple service nodes is selected and determined as the target node. The adjustment rule for the dynamic weighting factor is as follows: if the historical response result fails or times out, the dynamic weighting factor is increased; if the historical response result indicates continuous success, the dynamic weighting factor is decreased.

[0089] Optionally, the acquisition and calculation module includes at least one of the following sub-modules: The first acquisition submodule is used to acquire multi-dimensional performance indicators of the multiple service nodes according to a preset acquisition cycle. The second acquisition submodule is used to acquire multi-dimensional performance indicators of the multiple service nodes based on preset trigger events. The preset trigger events include at least one of the following: service node abnormal events, service node change events, and external instruction events.

[0090] Optionally, the acquisition and calculation module is further used for: The EWMA exponentially weighted moving average smoothing process is applied to each performance index using Formula 1 to obtain the smoothed values ​​for each performance index: Formula 1 in, This represents the smoothed value of the performance metric at the current moment. This represents the aggregated sample value of the performance metric at the current moment. Represents the smoothing coefficient. This represents the smoothed value maintained by the performance metric before this calculation. This value is obtained through recursive calculation and is equivalent to performing an exponentially weighted average of the historical data of the performance metric within the sliding time window.

[0091] Optionally, the computing module includes: The mapping submodule is used to map the smoothed values ​​of the performance indicators of each dimension corresponding to the service node to a unified scaling range according to a preset rule; The calculation and acquisition submodule is used to perform weighted summation of the indicator values ​​of each dimension of performance indicators mapped to a unified scaling interval, combined with the corresponding weights, to obtain the dynamic health index of the service node.

[0092] Optionally, the numerical values ​​of each performance metric mapped to a uniform scaling interval are positively correlated with the metric quality, and the calculation and acquisition submodule is further used for: Based on the currently effective weight configuration, the indicator values ​​of each performance indicator that will be mapped to a unified scaling range are weighted and calculated to obtain the dynamic health index corresponding to the service node. The dynamic health index is a comprehensive index that integrates multiple performance indicators to assess the health of the service node. The weights corresponding to each performance metric can be dynamically adjusted based on at least one of a preset strategy, historical scheduling results, and machine learning model; the multi-dimensional performance metrics include at least two of the following: CPU utilization, memory utilization, request response time, request error rate, and network latency.

[0093] Optionally, the device further includes: The switch update module is used to respond to the detection of an abnormal service node among the multiple service nodes, triggering a decay and recovery process, and updating the dynamic health index of the abnormal service node based on Formula 2: Formula 2 This is the updated dynamic health index. The previous dynamic health index. The attenuation coefficient is... This is a recovery term used to smooth out the rebound; The recovery module is used to exit the current decay and recovery process and resume the dynamic health index calculation process based on weighted summation after the abnormal service node has returned to normal and has been in operation for a period of time. The abnormal conditions of the abnormal service node include at least one of the following: network connection interruption or heartbeat loss, sudden change in performance indicators, sudden change in dynamic health index, or receiving a node failure warning.

[0094] Optionally, the computation processing module is further configured to: Based on the dynamic health index, real-time concurrent connections, and dynamic weighting factor of the service node, the comprehensive scheduling score of the service node is calculated using Formula 3: Formula 3 in, Let represent the overall scheduling score of the i-th service node. This represents the dynamic health index of the i-th service node. Represents a constant greater than 0. This represents the number of concurrent connections in real time for the i-th service node. This represents the dynamic weight factor of the i-th service node, where i ranges from 1 to m, and m is the number of service nodes.

[0095] Optionally, the device further includes: The receiving module is used to receive the request execution result returned by the target node in response to the client request being forwarded to the target node and processed. The update module is used to update the relevant performance indicators of the target node according to the execution result of the request, wherein the relevant performance indicators are at least some of the indicators in the multidimensional performance indicators; The update calculation module is used to recalculate the dynamic health index of the target node based on the latest multidimensional performance indicators corresponding to the target node, so as to apply it to the scheduling decision of subsequent client requests.

[0096] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0097] This application also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the various processes of the above-described request scheduling method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0098] For example, Figure 6 A schematic diagram of the physical structure of an electronic device is shown. (For example...) Figure 6 As shown, the electronic device may include a processor 610, a communications interface 620, a memory 630, and a communication bus 640. The processor 610, communications interface 620, and memory 630 communicate with each other via the communication bus 640. The processor 610 can call logical instructions stored in the memory 630. The processor 610 is used to execute various processes of the request scheduling method according to the embodiments of this application, which will not be described in detail here.

[0099] Furthermore, the logical instructions in the aforementioned memory 630 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0100] This application also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described request scheduling method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0101] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0102] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0103] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A request scheduling method applied to a reverse proxy gateway, characterized in that, The reverse proxy gateway is deployed between the client and multiple service nodes, and the method includes: Based on preset triggering conditions, multi-dimensional performance indicators of the multiple service nodes are collected, and for each performance indicator, a smoothed value of the performance indicator is calculated based on historical data of the performance indicator within a sliding time window. For each service node, a dynamic health index is calculated based on the smoothed value of the multidimensional performance indicators corresponding to the service node. The dynamic health index comprehensively represents the health status of the service node. For each service node, a comprehensive scheduling score is calculated based on the service node's dynamic health index, real-time concurrent connections, and dynamic weight factor. The dynamic weight factor of the service node is dynamically adjusted based on the service node's historical response results for handling client requests. Based on the comprehensive scheduling scores corresponding to the multiple service nodes, a target node is selected from the multiple service nodes, and the received client requests are forwarded to the target node. The target node is the service node that is optimally evaluated based on the comprehensive scheduling scores, considering health, real-time external load, and historical response feedback. The dynamic weighting factor is a quantitative representation of the historical response feedback.

2. The method according to claim 1, characterized in that, The comprehensive scheduling score is negatively correlated with the dynamic health index and positively correlated with the number of real-time concurrent connections and the dynamic weight factor. The dynamic health index of the service node is positively correlated with the health level of the service node. The step of selecting a target node from among the multiple service nodes based on their respective comprehensive scheduling scores includes: The service node with the lowest comprehensive scheduling score among the multiple service nodes is selected and determined as the target node. The adjustment rule for the dynamic weighting factor is as follows: if the historical response result fails or times out, the dynamic weighting factor is increased; if the historical response result indicates continuous success, the dynamic weighting factor is decreased.

3. The method according to claim 1, characterized in that, The collection of multi-dimensional performance metrics of the multiple service nodes based on preset triggering conditions includes at least one of the following: Collect multi-dimensional performance indicators of the multiple service nodes according to the preset collection period; Based on preset trigger events, multi-dimensional performance indicators of the multiple service nodes are collected. The preset trigger events include at least one of the following: service node abnormal events, service node change events, and external instruction events.

4. The method according to claim 1, characterized in that, The calculation of smoothed values ​​for each performance indicator, based on historical data of the performance indicator within a sliding time window, includes: The EWMA exponentially weighted moving average smoothing process is applied to each performance index using Formula 1 to obtain the smoothed values ​​for each performance index: Formula 1 in, This represents the smoothed value of the performance metric at the current moment. This represents the aggregated sample value of the performance metric at the current moment. Represents the smoothing coefficient. This represents the smoothed value maintained by the performance metric before this calculation. This value is obtained through recursive calculation and is equivalent to performing an exponentially weighted average of the historical data of the performance metric within the sliding time window.

5. The method according to claim 1 or 4, characterized in that, The calculation of the dynamic health index of the service node based on the smoothed value of the multidimensional performance indicators corresponding to the service node includes: The smoothed values ​​of the performance indicators corresponding to the service nodes are mapped to a unified scaling range according to preset rules; The dynamic health index of the service node is obtained by weighting and summing the performance index values ​​of each dimension mapped to a unified scaling interval and combining them with their corresponding weights.

6. The method according to claim 5, characterized in that, The numerical values ​​of performance indicators mapped to a uniform scaling interval are positively correlated with the quality of the indicators. The dynamic health index of the service node is obtained by weighting and summing the performance index values ​​of each dimension mapped to a unified scaling interval, combined with their corresponding weights. Based on the currently effective weight configuration, the indicator values ​​of each performance indicator that will be mapped to a unified scaling range are weighted and calculated to obtain the dynamic health index corresponding to the service node. The dynamic health index is a comprehensive index that integrates multiple performance indicators to assess the health of the service node. The weights corresponding to each performance metric can be dynamically adjusted based on at least one of a preset strategy, historical scheduling results, and machine learning model; the multi-dimensional performance metrics include at least two of the following: CPU utilization, memory utilization, request response time, request error rate, and network latency.

7. The method according to claim 5, characterized in that, Also includes: In response to the detection of an abnormal service node among the multiple service nodes, a decay and recovery process is triggered, and the dynamic health index of the abnormal service node is updated based on Formula 2: Formula 2 This is the updated dynamic health index. The previous dynamic health index. The attenuation coefficient is... This is a recovery term used to smooth out the rebound; In response to the abnormal service node returning to normal and remaining so for a period of time, the current attenuation and recovery process is exited, and the dynamic health index calculation process based on weighted summation is resumed. The abnormal conditions of the abnormal service node include at least one of the following: network connection interruption or heartbeat loss, sudden change in performance indicators, sudden change in dynamic health index, or receiving a node failure warning.

8. The method according to claim 2, characterized in that, The step of calculating the comprehensive scheduling score of the service node based on its dynamic health index, real-time concurrent connections, and dynamic weighting factor includes: Based on the dynamic health index, real-time concurrent connections, and dynamic weighting factor of the service node, the comprehensive scheduling score of the service node is calculated using Formula 3: Formula 3 in, Let represent the overall scheduling score of the i-th service node. This represents the dynamic health index of the i-th service node. Represents a constant greater than 0. This represents the number of concurrent connections in real time for the i-th service node. This represents the dynamic weight factor of the i-th service node, where i ranges from 1 to m, and m is the number of service nodes.

9. The method according to claim 1, characterized in that, Also includes: In response to the client request being forwarded to the target node and processed, the system receives the request execution result returned by the target node. Based on the result of the request execution, update the relevant performance indicators of the target node, wherein the relevant performance indicators are at least some of the indicators in the multidimensional performance indicators; Based on the latest multidimensional performance metrics corresponding to the target node, the dynamic health index of the target node is recalculated and applied to the scheduling decision of subsequent client requests.

10. A request scheduling device, applied to a reverse proxy gateway, characterized in that, The reverse proxy gateway is deployed between the client and multiple service nodes, and the device includes: The data acquisition and calculation module is used to collect multi-dimensional performance indicators of the multiple service nodes based on preset triggering conditions, and to calculate the smoothed value of each performance indicator based on historical data of the performance indicators within a sliding time window. The calculation module is used to calculate the dynamic health index of each service node based on the smoothed value of the multidimensional performance index corresponding to the service node. The dynamic health index comprehensively represents the health status of the service node. The calculation and processing module is used to calculate the comprehensive scheduling score of each service node based on its dynamic health index, real-time concurrent connection count, and dynamic weight factor. The dynamic weight factor of the service node is dynamically adjusted based on the historical response results of the service node in processing client requests. The scheduling module is used to select a target node from the multiple service nodes based on the comprehensive scheduling scores corresponding to each of the multiple service nodes, and forward the received client requests to the target node. The target node is the service node that is optimally evaluated based on the comprehensive scheduling scores, considering health, real-time external load, and historical response feedback. The dynamic weighting factor is a quantitative representation of the historical response feedback.

Images