Weight-based dynamic throttling control method and system

Abstract

The application discloses a weight-based dynamic flow control method and system. The gateway method comprises the following steps: capturing multi-dimensional request data carried by an access request sent by each target service as a real-time metering sequence; performing abnormality detection on the sequence and a pre-trained abnormality detection model to generate an abnormality detection result of each target service; obtaining basic parameters of each service; calculating a normalized dynamic weight of each target service at a current time according to the basic parameters and the abnormality detection result; updating a current flow control parameter of each target service according to the normalized dynamic weight to obtain a latest flow control parameter of each target service; and performing flow control on the access request based on the latest flow control parameter of each target service. Therefore, the application realizes adaptive and differentiated control of the distributed system flow, and improves the stability, load balancing efficiency and overall reliability of the system in a high-concurrency and flow fluctuation scenario.

Description

Technical Field

[0001] This application relates to the fields of high-end manufacturing and industrial internet technology, and in particular to a weight-based dynamic current limiting control method and system. Background Technology

[0002] With the deep integration of high-end manufacturing and the Industrial Internet, modern manufacturing widely adopts distributed architectures to realize distributed manufacturing systems. In distributed manufacturing systems, due to the dynamic scheduling of production tasks and the uneven distribution of user access, service request volume exhibits significant spatiotemporal fluctuations. Therefore, precise flow control mechanisms have become crucial for ensuring the stable operation of distributed manufacturing systems.

[0003] In related technologies, the flow control mechanism mainly uses a static threshold rate limiting algorithm. When the real-time traffic reaches a preset static threshold, the system will either drop or queue subsequent requests.

[0004] However, static thresholds cannot adapt to the dynamic fluctuations in system concurrency performance and lack elastic scaling capabilities. In scenarios with sudden traffic surges, fixed rate limiting thresholds often lead to a sharp increase in system response latency, and may even cause system crashes due to resource exhaustion. Moreover, they cannot guarantee the high-priority stability of critical services when resources are scarce. Secondly, in multi-level cluster architectures, static threshold methods are limited to single-point or local views, making it difficult to achieve fine-grained resource coordination across services and nodes. This results in uneven traffic distribution, with some nodes becoming performance bottlenecks due to overload, while other nodes remain idle, causing severe load imbalance. Finally, existing methods lack intelligent anomaly detection capabilities, making it difficult to identify anomalies in a timely manner. This causes the triggering of rate limiting policies to lag behind the actual occurrence of faults or lead to misjudgments, failing to meet the requirements of high-availability systems. Summary of the Invention

[0005] This application provides a weighted dynamic current limiting control method and system. To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments. Its sole purpose is to present some concepts in a simple form as a prelude to the detailed description that follows.

[0006] In a first aspect, embodiments of this application provide a weight-based dynamic current limiting control method, the method comprising: By deploying probes on the gateway, multi-dimensional request data carried by each target service's access request is captured in real time and used as a real-time metering sequence. Anomaly detection is performed based on real-time traffic metering sequences and pre-trained anomaly detection models to generate anomaly detection results for each target service. Obtain the business priority constant, health status and real-time load data of the deployed master node, and historical baseline for each service as basic parameters; calculate the normalized dynamic weight of each target service at the current moment based on the basic parameters and anomaly detection results. Based on the normalized dynamic weights, update the current rate limiting control parameters of each target service to obtain the latest rate limiting control parameters of each target service; Rate limiting is applied to access requests based on the latest rate limiting parameters for each target service.

[0007] Optionally, anomaly detection is performed based on real-time traffic metering sequences and pre-trained anomaly detection models to generate anomaly detection results for each target service, including: The real-time traffic metering sequence is input into the pre-trained anomaly detection model; the pre-trained anomaly detection model is obtained by modeling based on historical traffic data and its abnormal traffic behavior; Output the anomaly risk value for each target service; If the abnormal risk value is less than or equal to a preset threshold, each access request to the target service is determined to be normal traffic behavior, and a normal traffic behavior label and a low-risk score are generated; or... If the abnormal risk value is greater than the preset threshold, the access request for each target service is determined to be abnormal traffic behavior, and an abnormal traffic behavior label and a high risk score are generated. Normal traffic behavior labels and low-risk scores, or abnormal traffic behavior labels and high-risk scores, are used as the anomaly detection results for each target service.

[0008] Optionally, based on the basic parameters and anomaly detection results, calculate the normalized dynamic weight of each target service at the current time, including: Obtain the risk score from the anomaly detection results; Based on real-time load data and historical baselines, calculate the load deviation, which measures the degree of deviation of the current load from the historical normal level. Based on the health status of the deployed master nodes, calculate a health factor that reflects the reliability of the bearer nodes; The dynamic weight of each target service at the current moment is obtained by weighting and summing the business priority constant, load deviation, health factor, and risk score in the anomaly detection results. The dynamic weight of each target service at the current moment is normalized to obtain the normalized dynamic weight of each target service at the current moment; where the normalized dynamic weight is used to represent the proportion of total resources that each service should occupy.

[0009] Optionally, the formula for calculating the load deviation is:

[0010] in, Indicates at time , No. One service The load deviation is the percentage of the load that is deviating from the historical normal load. The larger the load deviation, the further the current load deviates from the normal load level. Indicates at time For services Real-time load data, Indicates service Historical baseline This represents the load deviation calculation function, used to quantify the difference between real-time data and historical baseline; The formula for calculating the health factor is:

[0011] in, Indicates at time ,Serve The health factor indicates that the node is healthier; a higher value means a healthier node. Indicates the service provider The health status of the master node is defined as a state vector that includes at least several metrics such as CPU utilization, memory utilization, and error rate. This represents the health mapping function, which is used to aggregate and map the multidimensional health status indicators of nodes into scalar health values. The expression for calculating dynamic weights is:

[0012] in, Indicates at time Serve Dynamic weights, Indicates service The business priority constant is a preset positive scalar. Indicates at time Serve Risk score, These are adjustable weighting coefficients. .

[0013] Optionally, based on the normalized dynamic weights, update the current rate limiting parameters for each target service to obtain the latest rate limiting parameters for each target service, including: Based on the normalized dynamic weight of each target service at the current moment, allocate dedicated rate limiting control capacity and dedicated control rate to each target service; The dedicated rate limiting capacity and dedicated rate allocated to each target service are used as the dedicated rate limiting parameters for each target service at the current moment. When the time between the current moment and the previous state supplement time reaches the preset period, traverse each target service; Based on the specific rate limiting parameters, update the current rate limiting control parameters for each target service to obtain the latest rate limiting control parameters for each target service.

[0014] Optionally, based on the normalized dynamic weight of each target service at the current moment, allocate dedicated rate limiting capacity and dedicated control rate to each target service, including: Calculate the overall system load based on real-time load data; Based on the overall system load, determine the basic current limiting control capacity and basic control rate of the entire system; Calculate the dedicated rate limiting capacity for each target service by using the normalized dynamic weight and basic rate limiting capacity of each target service at the current moment; The specific control rate for each target service is calculated using its normalized dynamic weight and basic control rate at the current moment; where, The formula for calculating the dedicated rate limiting capacity for each target service is:

[0015] in, At any moment For the first One service The dedicated current limiting control capacity is calculated. At any moment The basic current limiting control capacity of the entire system At any moment Serve Normalized dynamic weights, It is a scaling factor used to enlarge or reduce the overall calculation results based on weight allocation; The formula for calculating the dedicated control rate for each target service is:

[0016] in, At any moment For the first One service The dedicated control rate for calculation, At any moment The basic control rate of the entire system. At any moment Serve Normalized dynamic weights.

[0017] Optionally, rate limiting control can be performed on access requests based on the latest rate limiting control parameters for each target service, including: Identify pending access requests; where pending access requests are access requests sent by each target service. Obtain the current rate limiting status of the first service to which the pending access request belongs from the latest rate limiting control parameters of each target service; Based on the current rate limiting control status, determine whether the status value of the first service is 0; If not, allow pending access requests to pass through, and reduce the status value in the current rate limiting control state by a preset step size; If so, reject the pending access request.

[0018] Optionally, a pre-trained anomaly detection model is generated by following these steps: Obtain normal and abnormal traffic behavior data for each target service within a historical time period to form the original training dataset; The original training dataset is preprocessed to generate a sequence of feature vectors for model training; the feature vector sequence contains single-point data and temporal evolution patterns preserved by splicing consecutive samples. Choose a machine learning model architecture suitable for anomaly detection in time series or high-dimensional data as the base model; The feature vector sequence is used as a training sample and input into the base model, enabling the model to learn and model historical normal traffic behavior patterns and distinguish abnormal traffic behavior that deviates from historical normal traffic behavior patterns, and output the model loss value. When the model loss value reaches its minimum, a pre-trained anomaly detection model is generated; or, if the model loss value has not reached its minimum, the step of inputting the feature vector sequence as training samples into the base model continues until the model loss value reaches its minimum.

[0019] Optionally, the original training dataset is preprocessed to generate a sequence of feature vectors for model training, including: Obtain the traffic behavior type for each historical traffic data sample in the original training dataset; Based on the traffic behavior type, a behavior category label is assigned to each historical traffic data sample, resulting in multiple labeled historical traffic data samples. The behavior category label is used to identify whether the sample belongs to normal or abnormal traffic behavior. The abnormal traffic behavior can be further refined into specific abnormal traffic behavior patterns. The abnormal traffic behavior patterns include at least sudden flood attacks, connection exhaustion attacks, and service failures causing a surge in error rates. For each labeled historical traffic data sample, a feature extraction operation is performed to extract distinctive traffic features from each labeled historical traffic data sample. The extracted traffic features are combined into a fixed-dimensional feature vector in a predefined order; the feature vector and its corresponding behavior category label together constitute the training sample unit. Multiple training sample units belonging to the same target service and being sequential in time are concatenated in chronological order to generate the feature vector sequence used to characterize the temporal evolution pattern of traffic; wherein, the temporal context information retained by concatenating consecutive sample units is used to enable the pre-trained anomaly detection model to identify abnormal traffic behaviors that are difficult to determine based on single-point data.

[0020] Secondly, embodiments of this application provide a weight-based dynamic current limiting control system, the system comprising: The request data capture module is used to capture multi-dimensional request data carried by each access request sent by the target service in real time through probes deployed on the gateway, as a real-time metering sequence; The anomaly detection module is used to perform anomaly detection based on real-time traffic metering sequences and pre-trained anomaly detection models, and generate anomaly detection results for each target service. The dynamic weight calculation module is used to obtain the business priority constant, the health status and real-time load data of the deployed master node, and the historical baseline as basic parameters for each service; based on the basic parameters and anomaly detection results, it calculates the normalized dynamic weight of each target service at the current moment. The rate limiting control parameter update module is used to update the current rate limiting control parameters of each target service according to the normalized dynamic weight, so as to obtain the latest rate limiting control parameters of each target service. The rate limiting module is used to perform rate limiting on access requests based on the latest rate limiting parameters for each target service.

[0021] The technical solutions provided in this application embodiment may include the following beneficial effects: In this embodiment, on the one hand, by calculating normalized dynamic weights in real time, the dedicated rate limiting control parameters for each target service can be dynamically updated. This mechanism ensures that when sudden traffic surges cause system resource strain, high-priority services have higher dynamic weights, thus allocating larger processing capacity and faster processing speeds. This ensures that even with limited global resources, their requests can still be prioritized, guaranteeing the stability and low latency of critical business links and achieving global elastic scaling. On the other hand, when an overloaded node causes a decline in the health of the services it supports, the dynamic adjustment mechanism ensures that the dynamic weight of the service will decrease accordingly. The system will guide more traffic to higher-weighted services of the same type or other services deployed on healthy nodes, thereby achieving cross-service and cross-node traffic scheduling and load coordination in the distributed system. This solves the problems of uneven traffic distribution and resource idleness, improving the overall resource utilization of the cluster. Furthermore, when a pre-trained anomaly detection model identifies abnormal traffic in a service, its dynamic weight will be immediately lowered due to a high-risk score, leading to a reduction in the rate limiting quota allocated to it. This achieves proactive and rapid suppression of abnormal traffic, significantly improving the system's defense capabilities against unknown threats and overall availability.

[0022] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0024] Figure 1 This is a schematic diagram of the method flow of a weight-based dynamic current limiting control method provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating an anomaly detection result generation process provided in an embodiment of this application; Figure 3 This is a schematic diagram of a normalized dynamic weight generation process provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating the proportion of total resources that each service should occupy at the current moment, provided in an embodiment of this application. Figure 5 This is a schematic diagram illustrating the current current limiting control parameter update process provided in an embodiment of this application; Figure 6 This is a schematic diagram of a current limiting control process provided in an embodiment of this application; Figure 7 This is a schematic diagram illustrating the details of anomaly detection and dynamic rate limiting in a given scenario, as provided in an embodiment of this application. Figure 8 This is a flowchart illustrating an anomaly detection model training method provided in an embodiment of this application; Figure 9 This is a schematic diagram of a weight-based dynamic current limiting control system provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] The following description and accompanying drawings fully illustrate specific embodiments of this application to enable those skilled in the art to practice them.

[0026] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0027] In the following description, when referring to the accompanying drawings, the same numbers in different drawings denote the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of systems and methods consistent with some aspects of this application as detailed in the appended claims.

[0028] In the description of this application, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0029] Currently, the traffic control mechanism mainly uses a static threshold rate limiting algorithm. When the real-time traffic reaches a preset static threshold, the system will either drop or queue subsequent requests.

[0030] The inventors recognized that static thresholds cannot adapt to the dynamic fluctuations in system concurrency performance and lack elastic scaling capabilities. In scenarios with sudden traffic surges, fixed rate limiting thresholds often lead to a sharp increase in system response latency, and may even cause system crashes due to resource exhaustion. Furthermore, they cannot guarantee the high-priority stability of critical services when resources are scarce. Secondly, in multi-level cluster architectures, static threshold methods are limited to single-point or local views, making it difficult to achieve fine-grained resource coordination across services and nodes. This results in uneven traffic distribution, with some nodes becoming performance bottlenecks due to overload, while other nodes remain idle, causing severe load imbalance. Finally, existing methods lack intelligent anomaly detection capabilities, making it difficult to identify anomalies in a timely manner. This causes the triggering of rate limiting policies to lag behind the actual occurrence of faults or lead to misjudgments, failing to meet the requirements of high-availability systems.

[0031] To address the aforementioned issues, this application provides a weighted dynamic rate limiting control method and system to resolve the problems existing in the related technologies. In the embodiments of this application, on the one hand, by calculating normalized dynamic weights in real time, the dedicated rate limiting control parameters for each target service can be dynamically updated. This mechanism ensures that when sudden traffic surges cause system resource strain, high-priority services have higher dynamic weights, thus receiving larger processing capacity and faster processing rates. Therefore, even with limited global resources, their requests can still be prioritized, ensuring the stability and low latency of critical business links and achieving global elastic scaling. On the other hand, when an overloaded node causes a decline in the health of the services it supports, the dynamic adjustment mechanism ensures that the dynamic weight of the service will decrease accordingly. The system will guide more traffic to higher-weighted services of the same type or other services deployed on healthy nodes, thereby achieving cross-service and cross-node traffic scheduling and load coordination in the distributed system, solving the problems of uneven traffic distribution and resource idleness, and improving the overall resource utilization of the cluster. On the other hand, when a pre-trained anomaly detection model identifies an anomaly in the traffic of a certain service, its dynamic weight will be immediately reduced due to the high-risk score, which will lead to a reduction in the rate limiting quota allocated to it. This achieves proactive and rapid suppression of abnormal traffic, significantly improving the system's ability to defend against unknown threats and its overall availability. The following exemplary embodiments will be used to describe this in detail.

[0032] The following will be combined with the appendix Figure 1 -Appendix Figure 8 This application provides a detailed description of the weight-based dynamic current limiting control method provided in its embodiments. This method can be implemented using a computer program and can run on a weight-based dynamic current limiting control system based on the von Neumann architecture. The computer program can be integrated into the application or run as a standalone utility application.

[0033] Please see Figure 1This document provides a flowchart illustrating a weight-based dynamic rate limiting control method, applicable to a gateway, as described in an embodiment of this application. Figure 1 As shown, the method in this application embodiment includes the following steps: S101 uses probes deployed on the gateway to capture multi-dimensional request data carried by each target service's access request in real time, as a real-time metering sequence. In this system, a gateway is a network switching node device that serves as the logical boundary and traffic aggregation point between different networks or protocols. A probe is a lightweight data collection agent deployed on the gateway. Through techniques such as bypass listening, hook injection, or middleware interception, it performs real-time sniffing and metadata extraction of data packets flowing through the gateway in a non-intrusive or low-intrusive manner, acting as the data sensing terminal for the traffic metering module. A target service is the object to which control is applied; it can be represented as one or more independently identifiable backend business logic units, such as a specific application programming interface (API). Each target service is the basic unit of granularity for dynamic weight calculation and rate limiting policy execution. An access request is a network interaction command unit initiated by the client, intending to invoke the functions provided by the target service or obtain resources.

[0034] Multi-dimensional request data is a set of quantitative indicators extracted from access requests, capable of characterizing their features and system impact from multiple perspectives. These multi-dimensional dimensions include, but are not limited to: time dimensions (e.g., request arrival timestamps, response times); traffic dimensions (e.g., request packet size, payload length); concurrency dimensions (e.g., instantaneous concurrent connections, active sessions); and protocol / application dimensions (e.g., request method, application programming interface endpoint, protocol type, return status code). The real-time measurement sequence is an ordered stream of indicator data generated chronologically by probes continuously capturing multi-dimensional request data according to a preset sampling period or event-driven method.

[0035] In some embodiments of this application, probes deployed on the gateway intercept and parse access requests flowing through the gateway in real time, extracting multi-dimensional data such as request rate, number of concurrent connections, and response time, and aggregating them by target service within a set time window, ultimately generating a continuously output, time-series traffic indicator sequence, providing real-time data input for subsequent anomaly identification and dynamic rate limiting decisions.

[0036] In one possible implementation, an API gateway deployed on a hybrid cloud manufacturing platform needs to dynamically rate-limit three core microservices on the platform: device status query, production order placement, and real-time video streaming. In the API gateway (such as a custom gateway based on Nginx / Envoy / Kong), a lightweight probe (such as a Lua plugin or eBPF program) is enabled and configured. The three microservices mentioned above ( / api / v1 / device / status, / api / v1 / order / submit, / api / v1 / video / stream) are configured as target services.

[0037] At this point, when a machine tool terminal sends an HTTP POST request to the gateway, calling the ` / api / v1 / order / submit` interface to submit a new production order, the access request reaches the gateway. The probe is then triggered, parsing the request message and capturing its multi-dimensional request data. This multi-dimensional request data may include, for example: protocol / endpoint (HTTP / 1.1, POST / api / v1 / order / submit), timestamp (2023-10-27T14:30:25.123Z), client identifier (Client-IP: 192.168.1.100, User-ID: workshop_01), request size (e.g., Content-Length: 1500 bytes), and related metrics (currently, the number of active connections from the same client IP to this service is 5). The probe then formats and aggregates the captured data, along with data captured from other requests, in chronological order to obtain a real-time metering sequence.

[0038] S102, perform anomaly detection based on real-time traffic metering sequence and pre-trained anomaly detection model, and generate anomaly detection results for each target service; The pre-trained anomaly detection model is a machine learning or deep learning algorithm instance trained and solidified offline using historical traffic data of the target service. This model can learn and encode normal traffic behavior patterns from real-time input data, and thereby identify anomaly risk values ​​that deviate statistically significantly from the learned patterns. The anomaly detection result comprises two core components: anomaly labels and risk scores. An anomaly label is a binary or multi-class classification identifier used to directly determine whether the current traffic behavior is normal or a specific type of anomaly (such as sudden traffic spikes, DDoS attacks, or service failures). The risk score is a quantified confidence or deviation value (e.g., a score between 0 and 1) used to characterize the degree of certainty that the current traffic behavior is anomaly or the extent of deviation from the normal baseline.

[0039] In this embodiment, the specific process of generating anomaly detection results for each target service based on real-time traffic metering sequences and pre-trained anomaly detection models includes: inputting the real-time traffic metering sequences into the pre-trained anomaly detection model; wherein the pre-trained anomaly detection model is obtained by modeling based on historical traffic data and its abnormal traffic behavior; outputting anomaly risk values ​​corresponding to each target service; if the anomaly risk value is less than or equal to a preset threshold, determining that the access request for each target service is normal traffic behavior, and generating a normal traffic behavior label and a low-risk score; or, if the anomaly risk value is greater than the preset threshold, determining that the access request for each target service is abnormal traffic behavior, and generating an abnormal traffic behavior label and a high-risk score; and using the normal traffic behavior label and low-risk score or the abnormal traffic behavior label and high-risk score as the anomaly detection result for each target service.

[0040] In one possible implementation, during gateway startup or configuration hot update, a pre-trained anomaly detection model (stored as a serialized file, such as ONNX or PMML format) is loaded into the gateway process's memory. Subsequently, the gateway's anomaly detection engine continuously receives real-time metering sequence data points, aggregated by service and time window, pushed by the traffic metering module. For each arriving data point, the engine first extracts and assembles a feature vector according to the input format required by the model. Then, this feature vector is input into the model instance in memory, triggering a forward propagation calculation. The model's internal algorithm calculates an anomaly risk value representing the degree of anomaly in the current state. The calculated anomaly risk value is immediately compared with a preset threshold pre-configured in memory or the configuration center. If the risk value ≤ the preset threshold, a judgment result is generated as: {Traffic behavior label: "Normal", Risk score: Low risk score}. If the risk value > the preset threshold, a judgment result is generated as: {Traffic behavior label: "Abnormal", Risk score: High risk score}. Here, the low-risk score and high-risk score can be the risk value itself, or values ​​mapped according to predetermined rules (such as the Sigmoid function). The judgment result is used as the anomaly detection result (including label and score).

[0041] For example, the API gateway of a manufacturing cloud platform needs to perform real-time anomaly detection on the device data reporting service ( / api / device / telemetry). The operations team collects historical monitoring data of this service over the past three months (including QPS, response time, error rate, etc.) and trains an anomaly detection model using the Isolation Forest algorithm. This model learns the typical traffic patterns of the device data reporting service on normal working days (e.g., QPS is typically between 50-200, and the average response time is <100ms). The trained model file is deployed to the gateway node. The traffic metering probe generates a real-time metering sequence for this service every second, for example: {"service":"device_telemetry","qps":650,"avg_latency": 350,"error_rate":0.15,...}. The anomaly detection module reads this data, constructs a feature vector [650,350,0.15,...], and inputs it into the pre-trained Isolation Forest model. After calculation, the model determined that the current QPS (650) far exceeded the historical normal range (50-200), and the latency was significantly increased. Therefore, the abnormal risk value corresponding to this service was output as 0.92. Comparing the risk value of 0.92 with the preset threshold of 0.8: 0.92 > 0.8. Therefore, it was determined to be abnormal, and the abnormal detection result was generated as: {“Traffic Behavior Tag”: “Traffic Surge”, “Risk Score”: 0.92}.

[0042] For example Figure 2 As shown, Figure 2 This is a schematic diagram illustrating the anomaly detection result generation process provided in this application. When an external system initiates an access request, the gateway captures multi-dimensional request data (such as QPS, response time, request path, etc.) in real time through deployed probes, and aggregates this raw data into a real-time measurement sequence according to time windows. Subsequently, this sequence is input into a pre-trained anomaly detection model pre-loaded in memory. The model calculates an anomaly risk value characterizing the degree of current traffic anomaly through forward propagation. Next, the system enters a decision node to determine the magnitude of the anomaly risk value and a threshold. The risk value is binary-classified based on a preset threshold boundary: if the risk value is less than or equal to the threshold, it is determined to be normal traffic behavior, and a normal traffic behavior label and a low-risk score are output; if the risk value is greater than the threshold, it is determined to be abnormal traffic behavior, and an abnormal traffic behavior label and a high-risk score are output. Finally, the results from both branches are unified into an anomaly detection result. This result not only includes a qualitative label of the traffic behavior but also a quantitative risk score, which is used as input for subsequent business modules such as dynamic weight scheduling, rate limiting and circuit breaking, or alarm linkage.

[0043] S103: Obtain the business priority constant, health status and real-time load data of the deployed master node, and historical baseline as basic parameters for each service; calculate the normalized dynamic weight of each target service at the current moment based on the basic parameters and anomaly detection results. The business priority constant is a static parameter pre-set for each service during the system configuration phase, used to quantify the business importance of the service in a mathematical model. The health status of the deployed master node refers to a set of real-time operational metrics for the main computing nodes (servers, containers, or instances) running a target service. It is typically a multi-dimensional vector, including but not limited to: CPU utilization, memory utilization, disk I / O, network bandwidth, process liveness, service error rate, etc. This status reflects the node's ability and reliability in handling requests. Real-time load data refers to performance metrics collected for the target service within the current or most recent short time window (e.g., the last second or several seconds), reflecting its resource consumption and request pressure. Specifically, it includes, but is not limited to: Request Rate (QPS), concurrent connections, average response time, request / response data volume, thread pool utilization, etc. The historical baseline is a statistically significant reference standard, referring to the normal range or typical pattern of various load metrics (such as QPS, response time) of the target service over a relatively long and stable historical period (e.g., the past 7 days, 30 days). It can be calculated in advance using statistical methods (such as calculating the mean, quantiles, and periodic patterns).

[0044] In some embodiments of this application, the specific process of calculating the normalized dynamic weight of each target service at the current moment based on basic parameters and anomaly detection results includes: obtaining the risk score from the anomaly detection results; calculating the load deviation degree, which measures the degree of deviation of the current load from the historical normal level, based on real-time load data and historical baselines; calculating the health factor, which reflects the reliability of the bearer node, based on the health status of the deployed master node; weighted summing of the business priority constant, load deviation degree, health factor, and risk score from the anomaly detection results to obtain the dynamic weight of each target service at the current moment; and normalizing the dynamic weight of each target service at the current moment to obtain the normalized dynamic weight of each target service at the current moment; wherein, the normalized dynamic weight is used to characterize the proportion of total resources that each service should occupy.

[0045] Specifically, the formula for calculating load deviation is:

[0046] in, Indicates at time , No. One service The load deviation is the percentage of the load that is deviating from the historical normal load. The larger the load deviation, the further the current load deviates from the normal load level. Indicates at time For services Real-time load data, Indicates service Historical baseline This represents the load deviation calculation function, used to quantify the difference between real-time data and historical baselines.

[0047] Specifically, the formula for calculating the health factor is as follows:

[0048] in, Indicates at time ,Serve The health factor indicates that the node is healthier; a higher value means a healthier node. Indicates the service provider The health status of the master node is defined as a state vector that includes at least several metrics such as CPU utilization, memory utilization, and error rate. This represents the health mapping function, which is used to aggregate and map the multidimensional health status indicators of nodes into scalar health values.

[0049] Specifically, the expression for calculating dynamic weights is:

[0050] in, Indicates at time Serve Dynamic weights, Indicates service The business priority constant is a preset positive scalar. Indicates at time Serve Risk score, These are adjustable weighting coefficients. .

[0051] For example Figure 3 As shown, Figure 3This is a schematic diagram of a normalized dynamic weight generation process provided in this application. After obtaining three types of core input parameters, real-time load data and historical baseline data are used together to calculate the load deviation; a health factor (reflecting the reliability of the bearer node) is calculated based on the master node's health status; the business priority constant, which is the input of static business configuration, is obtained; and a risk score is received from the model output of the anomaly detection module. In the aggregation phase, the system performs a weighted summation calculation on the four dimensions of the business priority constant, load deviation, health factor, and risk score to generate an unnormalized dynamic weight value. Subsequently, the system performs normalization processing on the dynamic weights of all target services to ensure that the sum of the normalized weights of all services is 1. The final output normalized dynamic weight clearly represents the proportion of total resources that each service should occupy at the current moment. The proportion of total resources that each service should occupy at the current moment is, for example... Figure 4 As shown.

[0052] S104, Update the current rate limiting control parameters of each target service according to the normalized dynamic weights to obtain the latest rate limiting control parameters of each target service; In some embodiments of this application, the specific process of updating the current rate limiting control parameters of each target service according to the normalized dynamic weight includes: allocating a dedicated rate limiting control capacity and a dedicated control rate to each target service according to the normalized dynamic weight of each target service at the current time; using the dedicated rate limiting control capacity and dedicated control rate allocated to each target service as the dedicated rate limiting parameters of each target service at the current time; traversing each target service when the duration between the current time and the previous state supplement time reaches a preset period; updating the current rate limiting control parameters of each target service according to the dedicated rate limiting parameters to obtain the latest rate limiting control parameters of each target service.

[0053] The dedicated rate limiting capacity is the maximum number of licenses dynamically allocated to each target service to control the instantaneous request backlog it can handle. The dedicated control rate is the rate at which processing licenses are replenished for each target service per unit of time. The preset period is a pre-defined, fixed time interval (e.g., 100 milliseconds, 1 second). The current rate limiting parameter is a dynamically changing runtime value used to record the number of immediately usable processing licenses held by each target service at the current moment. The current rate limiting parameter decreases as requests are processed and is periodically replenished according to the preset period and the dedicated control rate.

[0054] In one possible implementation, upon receiving the normalized dynamic weights of all target services published by the dynamic weight scheduling module, the overall system load is first assessed to determine the current system-level basic rate limiting capacity and basic control rate. Then, each target service is iterated over, and its latest normalized dynamic weight is used to calculate a new dedicated rate limiting capacity and dedicated control rate. These two new values ​​are stored as the dedicated rate limiting parameters for that service at the current moment. Each time a timer triggers, this module iterates over all target services, reads their latest dedicated rate limiting parameters, updates the current rate limiting parameters for each target service, and obtains the latest rate limiting parameters for each target service.

[0055] In some embodiments of this application, the specific process of allocating dedicated rate limiting capacity and dedicated control rate to each target service based on the normalized dynamic weight of each target service at the current moment includes: calculating the overall system load based on real-time load data; determining the basic rate limiting capacity and basic control rate of the entire system based on the overall system load; calculating the dedicated rate limiting capacity of each target service using the normalized dynamic weight and basic rate limiting capacity of each target service at the current moment; and calculating the dedicated control rate of each target service using the normalized dynamic weight and basic control rate of each target service at the current moment.

[0056] Specifically, the formula for calculating the dedicated rate limiting capacity for each target service is as follows:

[0057] in, At any moment For the first One service The dedicated current limiting control capacity is calculated. At any moment The basic current limiting control capacity of the entire system At any moment Serve Normalized dynamic weights, It is a scaling factor used to enlarge or reduce the overall calculation results based on weight allocation.

[0058] Specifically, the formula for calculating the dedicated control rate for each target service is as follows:

[0059] in, At any moment For the first One service The dedicated control rate for calculation, At any moment The basic control rate of the entire system. At any moment Serve Normalized dynamic weights.

[0060] In some embodiments of this application, the specific process of updating the current rate limiting control parameters of each target service based on the dedicated rate limiting parameters includes: obtaining the dedicated rate limiting capacity and dedicated control rate from the dedicated rate limiting parameters; obtaining the current rate limiting control parameters of each target service; multiplying the dedicated control rate by the preset replenishment period to obtain the number of licenses to be replenished; and calculating the latest rate limiting control parameters of each target service based on the dedicated rate limiting capacity, the current rate limiting control parameters, and the number of licenses to be replenished.

[0061] The formula for calculating the number of licenses that should be supplemented is as follows:

[0062] in, This is the number of licenses that should be supplemented. It is a service Dedicated control rate, It is a preset replenishment cycle.

[0063] The calculation formula for the latest current limiting control parameters is as follows:

[0064] in, These are the latest current limiting control parameters. It is a service Dedicated current limiting control capacity, It is a service The current current limiting control parameters. The function ensures that the total sum does not exceed the service limit. Dedicated current limiting control capacity .

[0065] For example Figure 5 As shown, Figure 5This application provides a schematic diagram of the current rate limiting control parameter update process. By acquiring real-time load data, the overall system load is calculated, and basic rate limiting parameters, namely the system-level basic capacity and basic rate, are determined. Simultaneously, pre-calculated normalized dynamic weights are multiplied by the basic capacity and basic rate to generate an independent control limit and recovery speed for each service. That is, dedicated capacity = weight × basic capacity and dedicated rate = weight × basic rate, which precisely realizes resource allocation according to weight ratios. The process then determines whether a preset period has been reached. If not, the system enters a waiting state, still using the control parameters from the previous period to process requests. Once the preset fixed period is reached, the operation of updating the current rate limiting control parameters for each target service is triggered. Only then do the new dedicated capacity and dedicated rate officially take effect, updating the current rate limiting control parameters for each target service.

[0066] S105 performs rate limiting on access requests based on the latest rate limiting parameters for each target service.

[0067] In some embodiments of this application, the specific process of performing rate limiting control on access requests based on the latest rate limiting control parameters of each target service includes: determining the access request to be processed; wherein, the access request to be processed is an access request sent by each target service; obtaining the current rate limiting control status of the first service to which the access request to be processed belongs from the latest rate limiting control parameters of each target service; determining whether the status value of the first service is 0 according to the current rate limiting control status; if not, allowing the access request to be processed to pass, and reducing the status value in the current rate limiting control status by a preset step size; if yes, rejecting the access request to be processed.

[0068] The status value is the specific value of the latest rate limiting control parameter, referring to the number of processing licenses that each target service holds and can use immediately at the current moment. The preset step size is a fixed amount that should be deducted from the current rate limiting control status after a single pending access request is allowed to pass.

[0069] In one possible implementation, upon receiving a new data packet and parsing it into a complete access request, the request is marked as a pending access request and enters the rate limiting decision pipeline. The gateway immediately extracts key routing information (such as the HTTP Path, RPC Service / Method) from the request to determine its target service identifier, i.e., the first service. Based on the identifier of the first service, the decision logic atomically reads the current rate limiting control status value from the latest rate limiting control parameters corresponding to that service in shared memory or a high-performance concurrent data structure. The decision logic compares the read status value with the permission consumption threshold. Sufficient permission (status value > 0): The request is allowed. Subsequently, the status value must be immediately subtracted by a preset step size atomically. Insufficient permission (status value <= 0): The request is rejected. In this case, there is no need to modify the status value; a rate limiting response (such as HTTP 429) can be directly returned to the client.

[0070] For example Figure 6 As shown, Figure 6 This is a schematic diagram of a rate limiting control process provided in this application. The gateway first determines the current pending access request and identifies the target service to which the request belongs, marking it as the first service. The gateway extracts the current rate limiting control state corresponding to the first service from the latest rate limiting control parameter set. The gateway judges the extracted current rate limiting control state value of the first service, checking if it is equal to 0. If the judgment result is no (i.e., state > 0, indicating that there is still a processing permission available): the gateway allows the pending access request to pass and forwards it to the backend service; subsequently, the gateway reduces the current rate limiting control state value of the service according to a preset step size (e.g., step = 1), executing the operation state = state - step to reflect that one processing permission has been consumed; the process ends. If the judgment result is yes (i.e., state = 0, indicating that there is no processing permission available): the gateway directly rejects the access request and does not forward it; the process ends. Details of anomaly detection and dynamic rate limiting in one scenario are as follows: Figure 7 As shown.

[0071] In this embodiment, on the one hand, by calculating normalized dynamic weights in real time, the dedicated rate limiting control parameters for each target service can be dynamically updated. This mechanism ensures that when sudden traffic surges cause system resource strain, high-priority services have higher dynamic weights, thus allocating larger processing capacity and faster processing speeds. This ensures that even with limited global resources, their requests can still be prioritized, guaranteeing the stability and low latency of critical business links and achieving global elastic scaling. On the other hand, when an overloaded node causes a decline in the health of the services it supports, the dynamic adjustment mechanism ensures that the dynamic weight of the service will decrease accordingly. The system will guide more traffic to higher-weighted services of the same type or other services deployed on healthy nodes, thereby achieving cross-service and cross-node traffic scheduling and load coordination in the distributed system. This solves the problems of uneven traffic distribution and resource idleness, improving the overall resource utilization of the cluster. Furthermore, when a pre-trained anomaly detection model identifies abnormal traffic in a service, its dynamic weight will be immediately lowered due to a high-risk score, leading to a reduction in the rate limiting quota allocated to it. This achieves proactive and rapid suppression of abnormal traffic, significantly improving the system's defense capabilities against unknown threats and overall availability.

[0072] Please see Figure 8 This is a flowchart illustrating an anomaly detection model training method provided in this application. Figure 8 As shown, the method in this application embodiment includes the following steps: S201, Obtain normal traffic behavior data and abnormal traffic behavior data for each target service within the historical time period to form the original training dataset; S202, preprocesses the original training dataset to generate a sequence of feature vectors for model training; the feature vector sequence contains single-point data and temporal evolution patterns preserved by splicing consecutive samples. It should be noted that the feature vector sequence contains single-point data and preserves the temporal evolution pattern by splicing continuous samples, which helps to identify slow DDoS or periodic failures.

[0073] In some embodiments of this application, the specific process of preprocessing the original training dataset to generate a feature vector sequence for model training includes: obtaining the traffic behavior type of each historical traffic data sample in the original training dataset; assigning a behavior category label to each historical traffic data sample according to the traffic behavior type, resulting in multiple labeled historical traffic data samples; wherein, the behavior category label is used to identify whether the sample belongs to normal traffic behavior or abnormal traffic behavior; the abnormal traffic behavior can be refined into specific abnormal traffic behavior patterns; the abnormal traffic behavior patterns include at least sudden flood attacks, connection exhaustion attacks, and service failures causing a surge in error rates; for each labeled historical traffic data sample... Historical traffic data samples are used to perform feature extraction operations to extract discriminative traffic features from each labeled historical traffic data sample. The extracted traffic features are combined into fixed-dimensional feature vectors in a predefined order. The feature vectors and their corresponding behavior category labels together constitute training sample units. Multiple training sample units belonging to the same target service and being consecutive in time are concatenated in chronological order to generate the feature vector sequence used to characterize the temporal evolution pattern of traffic. The temporal context information retained by concatenating consecutive sample units is used to enable the pre-trained anomaly detection model to identify abnormal traffic behaviors that are difficult to determine based on single-point data.

[0074] It should be noted that refining the abnormal traffic behavior patterns can make subsequent rate limiting strategies more targeted.

[0075] S203, Select a machine learning model architecture suitable for anomaly detection in time series or high-dimensional data as the base model; S204, input the feature vector sequence as training samples into the base model, so that the model can learn and model historical normal traffic behavior patterns and distinguish abnormal traffic behavior that deviates from historical normal traffic behavior patterns, and output the model loss value. S205, when the model loss value reaches the minimum, generate a pre-trained anomaly detection model; or, when the model loss value has not reached the minimum, continue to execute the step of inputting the feature vector sequence as training samples into the base model until the model loss value reaches the minimum.

[0076] In this embodiment, on the one hand, by calculating normalized dynamic weights in real time, the dedicated rate limiting control parameters for each target service can be dynamically updated. This mechanism ensures that when sudden traffic surges cause system resource strain, high-priority services have higher dynamic weights, thus allocating larger processing capacity and faster processing speeds. This ensures that even with limited global resources, their requests can still be prioritized, guaranteeing the stability and low latency of critical business links and achieving global elastic scaling. On the other hand, when an overloaded node causes a decline in the health of the services it supports, the dynamic adjustment mechanism ensures that the dynamic weight of the service will decrease accordingly. The system will guide more traffic to higher-weighted services of the same type or other services deployed on healthy nodes, thereby achieving cross-service and cross-node traffic scheduling and load coordination in the distributed system. This solves the problems of uneven traffic distribution and resource idleness, improving the overall resource utilization of the cluster. Furthermore, when a pre-trained anomaly detection model identifies abnormal traffic in a service, its dynamic weight will be immediately lowered due to a high-risk score, leading to a reduction in the rate limiting quota allocated to it. This achieves proactive and rapid suppression of abnormal traffic, significantly improving the system's defense capabilities against unknown threats and overall availability.

[0077] The following are system embodiments of this application, which can be used to execute the method embodiments of this application. For details not disclosed in the system embodiments of this application, please refer to the method embodiments of this application.

[0078] Please see Figure 9 This illustration shows a schematic diagram of a weighted dynamic current limiting control system provided in an exemplary embodiment of this application. This weighted dynamic current limiting control system can be implemented as all or part of an electronic device through software, hardware, or a combination of both. The system 1 includes a request data acquisition module 10, an anomaly detection module 20, a dynamic weight calculation module 30, a current limiting control parameter update module 40, and a current limiting control module 50.

[0079] The request data capture module 10 is used to capture multi-dimensional request data carried by each access request sent by the target service in real time through probes deployed on the gateway, as a real-time metering sequence. Anomaly detection module 20 is used to perform anomaly detection based on real-time traffic metering sequence and pre-trained anomaly detection model, and generate anomaly detection results for each target service; The dynamic weight calculation module 30 is used to obtain the business priority constant, health status and real-time load data of the deployed master node, and historical baseline as basic parameters for each service; and calculates the normalized dynamic weight of each target service at the current moment based on the basic parameters and anomaly detection results. The rate limiting control parameter update module 40 is used to update the current rate limiting control parameters of each target service according to the normalized dynamic weight, so as to obtain the latest rate limiting control parameters of each target service. The rate limiting control module 50 is used to perform rate limiting control on access requests based on the latest rate limiting control parameters for each target service.

[0080] It should be noted that the weighted dynamic current limiting control system provided in the above embodiments is only illustrated by the division of the above functional modules when executing the weighted dynamic current limiting control method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the equipment can be divided into different functional modules to complete all or part of the functions described above. In addition, the weighted dynamic current limiting control system and the weighted dynamic current limiting method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0081] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0082] In this embodiment, on the one hand, by calculating normalized dynamic weights in real time, the dedicated rate limiting control parameters for each target service can be dynamically updated. This mechanism ensures that when sudden traffic surges cause system resource strain, high-priority services have higher dynamic weights, thus allocating larger processing capacity and faster processing speeds. This ensures that even with limited global resources, their requests can still be prioritized, guaranteeing the stability and low latency of critical business links and achieving global elastic scaling. On the other hand, when an overloaded node causes a decline in the health of the services it supports, the dynamic adjustment mechanism ensures that the dynamic weight of the service will decrease accordingly. The system will guide more traffic to higher-weighted services of the same type or other services deployed on healthy nodes, thereby achieving cross-service and cross-node traffic scheduling and load coordination in the distributed system. This solves the problems of uneven traffic distribution and resource idleness, improving the overall resource utilization of the cluster. Furthermore, when a pre-trained anomaly detection model identifies abnormal traffic in a service, its dynamic weight will be immediately lowered due to a high-risk score, leading to a reduction in the rate limiting quota allocated to it. This achieves proactive and rapid suppression of abnormal traffic, significantly improving the system's defense capabilities against unknown threats and overall availability.

[0083] This application also provides a computer-readable medium having program instructions stored thereon, which, when executed by a processor, implement the weight-based dynamic current limiting control method provided in the above-described method embodiments.

[0084] This application also provides a computer program product containing instructions that, when run on a computer, cause the computer to execute the weight-based dynamic flow limiting control method of the various method embodiments described above.

[0085] Please see Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 10 As shown, the electronic device 1000 may include a memory 1001. Various functions of the electronic device 1000 and data processing are performed by running or executing instructions, programs, code sets, or instruction sets stored in the memory 1001, and by calling data stored in the memory 1001.

[0086] The memory 1001 may include random access memory (RAM) or read-only memory. Optionally, the memory 1001 may include a non-transitory computer-readable storage medium. The memory 1001 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 1001 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Figure 10 As shown, the memory 1001, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a weight-based dynamic rate limiting control application.

[0087] exist Figure 10 In the electronic device 1000 shown, the weighted dynamic current limiting control application stored in memory 1001 is invoked, and the following operations are performed: By deploying probes on the gateway, multi-dimensional request data carried by each target service's access request is captured in real time and used as a real-time metering sequence. Anomaly detection is performed based on real-time traffic metering sequences and pre-trained anomaly detection models to generate anomaly detection results for each target service. Obtain the business priority constant, health status and real-time load data of the deployed master node, and historical baseline for each service as basic parameters; calculate the normalized dynamic weight of each target service at the current moment based on the basic parameters and anomaly detection results. Based on the normalized dynamic weights, update the current rate limiting control parameters of each target service to obtain the latest rate limiting control parameters of each target service; Rate limiting is applied to access requests based on the latest rate limiting parameters for each target service.

[0088] In one embodiment, when processor 1001 performs anomaly detection based on real-time traffic metering sequences and a pre-trained anomaly detection model to generate anomaly detection results for each target service, it specifically performs the following operations: The real-time traffic metering sequence is input into the pre-trained anomaly detection model; the pre-trained anomaly detection model is obtained by modeling based on historical traffic data and its abnormal traffic behavior; Output the anomaly risk value for each target service; If the abnormal risk value is less than or equal to a preset threshold, each access request to the target service is determined to be normal traffic behavior, and a normal traffic behavior label and a low-risk score are generated; or... If the abnormal risk value is greater than the preset threshold, the access request for each target service is determined to be abnormal traffic behavior, and an abnormal traffic behavior label and a high risk score are generated. Normal traffic behavior labels and low-risk scores, or abnormal traffic behavior labels and high-risk scores, are used as the anomaly detection results for each target service.

[0089] In one embodiment, when the processor 1001 calculates the normalized dynamic weight of each target service at the current moment based on the basic parameters and anomaly detection results, it specifically performs the following operations: Obtain the risk score from the anomaly detection results; Based on real-time load data and historical baselines, calculate the load deviation, which measures the degree of deviation of the current load from the historical normal level. Based on the health status of the deployed master nodes, calculate a health factor that reflects the reliability of the bearer nodes; The dynamic weight of each target service at the current moment is obtained by weighting and summing the business priority constant, load deviation, health factor, and risk score in the anomaly detection results. The dynamic weight of each target service at the current moment is normalized to obtain the normalized dynamic weight of each target service at the current moment; where the normalized dynamic weight is used to represent the proportion of total resources that each service should occupy.

[0090] In one embodiment, when processor 1001 updates the current rate limiting control parameters of each target service according to the normalized dynamic weights to obtain the latest rate limiting control parameters of each target service, it specifically performs the following operations: Based on the normalized dynamic weight of each target service at the current moment, allocate dedicated rate limiting control capacity and dedicated control rate to each target service; The dedicated rate limiting capacity and dedicated rate allocated to each target service are used as the dedicated rate limiting parameters for each target service at the current moment. When the time between the current moment and the previous state supplement time reaches the preset period, traverse each target service; Based on the specific rate limiting parameters, update the current rate limiting control parameters for each target service to obtain the latest rate limiting control parameters for each target service.

[0091] In one embodiment, when the processor 1001 allocates dedicated rate limiting capacity and dedicated control rate to each target service based on the normalized dynamic weight of each target service at the current moment, it specifically performs the following operations: Calculate the overall system load based on real-time load data; Based on the overall system load, determine the basic current limiting control capacity and basic control rate of the entire system; Calculate the dedicated rate limiting capacity for each target service by using the normalized dynamic weight and basic rate limiting capacity of each target service at the current moment; The specific control rate for each target service is calculated using the normalized dynamic weight and basic control rate of each target service at the current moment.

[0092] In one embodiment, when processor 1001 performs rate limiting control on access requests based on the latest rate limiting control parameters for each target service, it specifically performs the following operations: Identify pending access requests; where pending access requests are access requests sent by each target service. Obtain the current rate limiting status of the first service to which the pending access request belongs from the latest rate limiting control parameters of each target service; Based on the current rate limiting control status, determine whether the status value of the first service is 0; If not, allow pending access requests to pass through, and reduce the status value in the current rate limiting control state by a preset step size; If so, reject the pending access request.

[0093] In one embodiment, when the processor 1001 generates a pre-trained anomaly detection model, it specifically performs the following operations: Obtain normal and abnormal traffic behavior data for each target service within a historical time period to form the original training dataset; The original training dataset is preprocessed to generate a sequence of feature vectors for model training; the feature vector sequence contains single-point data and temporal evolution patterns preserved by splicing consecutive samples. Choose a machine learning model architecture suitable for anomaly detection in time series or high-dimensional data as the base model; The feature vector sequence is used as a training sample and input into the base model, enabling the model to learn and model historical normal traffic behavior patterns and distinguish abnormal traffic behavior that deviates from historical normal traffic behavior patterns, and output the model loss value. When the model loss value reaches its minimum, a pre-trained anomaly detection model is generated; or, if the model loss value has not reached its minimum, the step of inputting the feature vector sequence as training samples into the base model continues until the model loss value reaches its minimum.

[0094] In one embodiment, when processor 1001 performs preprocessing on the original training dataset to generate a sequence of feature vectors for model training, it specifically performs the following operations: Obtain the traffic behavior type for each historical traffic data sample in the original training dataset; Based on the traffic behavior type, a behavior category label is assigned to each historical traffic data sample, resulting in multiple labeled historical traffic data samples. The behavior category label is used to identify whether the sample belongs to normal or abnormal traffic behavior. The abnormal traffic behavior can be further refined into specific abnormal traffic behavior patterns. The abnormal traffic behavior patterns include at least sudden flood attacks, connection exhaustion attacks, and service failures causing a surge in error rates. For each labeled historical traffic data sample, a feature extraction operation is performed to extract distinctive traffic features from each labeled historical traffic data sample. The extracted traffic features are combined into a fixed-dimensional feature vector in a predefined order; the feature vector and its corresponding behavior category label together constitute the training sample unit. Multiple training sample units belonging to the same target service and being sequential in time are concatenated in chronological order to generate the feature vector sequence used to characterize the temporal evolution pattern of traffic; wherein, the temporal context information retained by concatenating consecutive sample units is used to enable the pre-trained anomaly detection model to identify abnormal traffic behaviors that are difficult to determine based on single-point data.

[0095] In this embodiment, on the one hand, by calculating normalized dynamic weights in real time, the dedicated rate limiting control parameters for each target service can be dynamically updated. This mechanism ensures that when sudden traffic surges cause system resource strain, high-priority services have higher dynamic weights, thus allocating larger processing capacity and faster processing speeds. This ensures that even with limited global resources, their requests can still be prioritized, guaranteeing the stability and low latency of critical business links and achieving global elastic scaling. On the other hand, when an overloaded node causes a decline in the health of the services it supports, the dynamic adjustment mechanism ensures that the dynamic weight of the service will decrease accordingly. The system will guide more traffic to higher-weighted services of the same type or other services deployed on healthy nodes, thereby achieving cross-service and cross-node traffic scheduling and load coordination in the distributed system. This solves the problems of uneven traffic distribution and resource idleness, improving the overall resource utilization of the cluster. Furthermore, when a pre-trained anomaly detection model identifies abnormal traffic in a service, its dynamic weight will be immediately lowered due to a high-risk score, leading to a reduction in the rate limiting quota allocated to it. This achieves proactive and rapid suppression of abnormal traffic, significantly improving the system's defense capabilities against unknown threats and overall availability.

[0096] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The weighted dynamic current limiting control program can be stored in a computer-readable storage medium. When executed, the program can include the processes of the embodiments of the methods described above. The storage medium for the weighted dynamic current limiting control program can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0097] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A weight-based dynamic current limiting control method, characterized in that, Applied to a gateway, the method includes: By deploying probes on the gateway, multi-dimensional request data carried by each target service's access request is captured in real time and used as a real-time metering sequence. Anomaly detection is performed based on the real-time traffic metering sequence and the pre-trained anomaly detection model to generate anomaly detection results for each target service. Obtain the business priority constant, health status and real-time load data of the deployed master node, and historical baseline for each service as basic parameters; calculate the normalized dynamic weight of each target service at the current moment based on the basic parameters and the anomaly detection results. Based on the normalized dynamic weights, update the current rate limiting control parameters of each target service to obtain the latest rate limiting control parameters of each target service; Rate limiting is applied to the access requests based on the latest rate limiting parameters for each target service.

2. The method according to claim 1, characterized in that, The step of performing anomaly detection based on the real-time traffic metering sequence and the pre-trained anomaly detection model, and generating anomaly detection results for each target service, includes: The real-time traffic metering sequence is input into a pre-trained anomaly detection model; wherein, the pre-trained anomaly detection model is obtained by modeling based on historical traffic data and its abnormal traffic behavior; Output the abnormal risk value corresponding to each target service; If the abnormal risk value is less than or equal to a preset threshold, the access request for each target service is determined to be normal traffic behavior, and a normal traffic behavior label and a low-risk score are generated; or, If the abnormal risk value is greater than a preset threshold, the access request for each target service is determined to be an abnormal traffic behavior, and an abnormal traffic behavior label and a high-risk score are generated. The normal traffic behavior label and low-risk score, or the abnormal traffic behavior label and high-risk score, are used as the anomaly detection results for each target service.

3. The method according to claim 1, characterized in that, The step of calculating the normalized dynamic weight of each target service at the current moment based on the basic parameters and the anomaly detection results includes: Obtain the risk score from the anomaly detection results; Based on the real-time load data and historical baseline, calculate the load deviation, which measures the degree of deviation of the current load from the historical normal level. Based on the health status of the deployed master nodes, calculate a health factor that reflects the reliability of the bearer nodes; The dynamic weight of each target service at the current moment is obtained by weighted summing of the business priority constant, the load deviation, the health factor, and the risk score in the anomaly detection result. The dynamic weight of each target service at the current moment is normalized to obtain the normalized dynamic weight of each target service at the current moment; wherein, the normalized dynamic weight is used to characterize the proportion of total resources that each service should occupy.

4. The method according to claim 3, characterized in that, The formula for calculating the load deviation is: in, Indicates at time , No. One service The load deviation is the percentage of the load that is deviating from the historical normal load. The larger the load deviation, the further the current load deviates from the normal load level. Indicates at time For services Real-time load data, Indicates service Historical baseline This represents the load deviation calculation function, used to quantify the difference between real-time data and historical baseline; The calculation formula for the health factor is as follows: in, Indicates at time ,Serve The health factor indicates that the node is healthier; a higher value means a healthier node. Indicates the service provider The health status of the master node is defined as a state vector that includes at least several metrics such as CPU utilization, memory utilization, and error rate. This represents the health mapping function, which is used to aggregate and map the multidimensional health status indicators of nodes into scalar health values. The expression for calculating the dynamic weight is: in, Indicates at time Serve Dynamic weights, Indicates service The business priority constant is a preset positive scalar. Indicates at time Serve Risk score, These are adjustable weighting coefficients. .

5. The method according to claim 1, characterized in that, The step of updating the current rate limiting control parameters of each target service according to the normalized dynamic weights to obtain the latest rate limiting control parameters of each target service includes: Based on the normalized dynamic weight of each target service at the current moment, allocate dedicated rate limiting control capacity and dedicated control rate to each target service; The dedicated rate limiting control capacity and dedicated control rate allocated to each target service are used as the dedicated rate limiting parameters for each target service at the current moment. When the time between the current moment and the previous state supplement time reaches a preset period, each target service is traversed; Based on the specific rate limiting parameters, update the current rate limiting control parameters of each target service to obtain the latest rate limiting control parameters of each target service.

6. The method according to claim 5, characterized in that, The step of allocating dedicated rate-limiting capacity and dedicated control rate to each target service based on the normalized dynamic weight of each target service at the current time includes: Calculate the overall system load based on the real-time load data; Based on the overall system load, determine the basic current limiting control capacity and basic control rate of the entire system; The dedicated rate limiting capacity of each target service is calculated using the normalized dynamic weight of each target service at the current moment and the basic rate limiting capacity. The specific control rate for each target service is calculated using the normalized dynamic weight of each target service at the current moment and the basic control rate; wherein... The calculation expression for the dedicated rate limiting control capacity of each target service is as follows: in, At any moment For the first One service The dedicated current limiting control capacity is calculated. At any moment The basic current limiting control capacity of the entire system At any moment Serve Normalized dynamic weights, It is a scaling factor used to enlarge or reduce the overall calculation results based on weight allocation; The expression for calculating the dedicated control rate for each target service is as follows: in, At any moment For the first One service The dedicated control rate for calculation, At any moment The basic control rate of the entire system. At any moment Serve Normalized dynamic weights.

7. The method according to claim 1, characterized in that, The process of performing rate limiting control on the access requests based on the latest rate limiting control parameters for each target service includes: Identify pending access requests; wherein, the pending access requests are access requests sent by each target service; Obtain the current rate limiting control status of the first service to which the pending access request belongs from the latest rate limiting control parameters of each target service; Based on the current rate limiting control status, determine whether the status value of the first service is 0; If not, allow the pending access request to pass through, and reduce the status value in the current rate limiting control state by a preset step size; If so, reject the pending access request.

8. The method according to claim 1, characterized in that, Generate a pre-trained anomaly detection model by following these steps: Obtain normal and abnormal traffic behavior data for each target service within a historical time period to form the original training dataset; The original training dataset is preprocessed to generate a feature vector sequence for model training; the feature vector sequence contains single-point data and temporal evolution patterns preserved by splicing consecutive samples. Choose a machine learning model architecture suitable for anomaly detection in time series or high-dimensional data as the base model; The feature vector sequence is used as a training sample and input into the base model, so that the model learns and models historical normal traffic behavior patterns and distinguishes abnormal traffic behavior that deviates from the historical normal traffic behavior patterns, and outputs the model loss value. When the model loss value reaches its minimum, a pre-trained anomaly detection model is generated; or, if the model loss value has not reached its minimum, the step of inputting the feature vector sequence as training samples into the base model continues until the model loss value reaches its minimum.

9. The method according to claim 8, characterized in that, The preprocessing of the original training dataset to generate a sequence of feature vectors for model training includes: Obtain the traffic behavior type of each historical traffic data sample in the original training dataset; Based on the traffic behavior type, a behavior category label is assigned to each historical traffic data sample to obtain multiple labeled historical traffic data samples; wherein, the behavior category label is used to identify whether the sample belongs to normal traffic behavior or abnormal traffic behavior; the abnormal traffic behavior can be further refined into specific abnormal traffic behavior patterns; the abnormal traffic behavior patterns include at least sudden flood attacks, connection exhaustion attacks, and service failures causing a surge in error rates; For each labeled historical traffic data sample, a feature extraction operation is performed to extract distinctive traffic features from each labeled historical traffic data sample. The extracted traffic features are combined into a fixed-dimensional feature vector in a predefined order; wherein the feature vector and its corresponding behavior category label together constitute a training sample unit. Multiple training sample units belonging to the same target service and being sequential in time are concatenated in chronological order to generate the feature vector sequence used to characterize the temporal evolution pattern of traffic; wherein, the temporal context information retained by concatenating consecutive sample units is used to enable the pre-trained anomaly detection model to identify abnormal traffic behaviors that are difficult to determine based on single-point data.

10. A weight-based dynamic current limiting control system, characterized in that, The system includes: The request data capture module is used to capture multi-dimensional request data carried by each access request sent by the target service in real time through probes deployed on the gateway, as a real-time metering sequence; The anomaly detection module is used to perform anomaly detection based on the real-time traffic metering sequence and the pre-trained anomaly detection model, and generate anomaly detection results for each target service. The dynamic weight calculation module is used to obtain the business priority constant, the health status and real-time load data of the deployed master node, and the historical baseline of each service as basic parameters; and to calculate the normalized dynamic weight of each target service at the current moment based on the basic parameters and the anomaly detection results. The rate limiting control parameter update module is used to update the current rate limiting control parameters of each target service according to the normalized dynamic weight, so as to obtain the latest rate limiting control parameters of each target service; The rate limiting control module is used to perform rate limiting control on the access requests based on the latest rate limiting control parameters of each target service.

Images