Flow control method and system based on dual-gateway cooperation

Abstract

The invention relates to the technical field of access control, and discloses a flow control method and system based on double-gateway cooperation, and the method comprises the steps: obtaining an incoming flow request, carrying out the access frequency statistics according to the request, obtaining an access frequency value, carrying out the access judgment according to the access frequency value, and obtaining an initial judgment result; performing context behavior analysis based on a judgment result to obtain a time sequence dependence intensity value, marking diversified requests according to the intensity value and constructing paths, finishing path screening and merging, obtaining service logic groups, identifying key services according to the service logic groups, optimizing channels and configuring weights, and generating a refined routing path. And further analyzing a path structure and labeling a time sequence to obtain a context data set, calculating a resource rate and adjusting a quota, generating a resource quota table, finally completing quota comparison, instruction forwarding and stability scoring based on the quota table, and completing current limiting configuration updating if the stability is insufficient. The method can solve the problem of unbalanced resource allocation.

Description

A Traffic Control Method and System Based on Dual Gateway Collaboration Technical Field

[0001] This invention relates to the field of access control technology, and in particular to a flow control method and system based on dual gateway collaboration. Background Technology

[0002] Access control technology, as an important means of ensuring system security and stability, has gradually expanded from the initial static permission verification to dynamic, context-aware intelligent control mechanisms. Especially in multi-tenant systems, high-concurrency platforms, and distributed microservice environments, access requests not only carry static attributes such as user identity and permission level, but also dynamic characteristics such as business priority, resource sensitivity, and behavioral patterns.

[0003] Existing methods establish request scheduling mechanisms based on leaky bucket or token bucket algorithms. At the service gateway layer, a maximum token issuance rate and maximum buffer capacity are preset per second. All requests must acquire a token before entering the backend business chain. These algorithms dynamically determine whether to allow requests based on the request arrival interval, thereby suppressing system load pressure caused by sudden request bursts. In actual deployments, engineers often configure fixed thresholds based on historical average request rates and set rejection ratios for overload situations. While such rate limiting solutions are simple to implement and have fast response times, making them suitable for scenarios such as network attack protection and static request distribution, they have technical limitations in dealing with real-world applications characterized by high business volatility and significant differences in request value.

[0004] In summary, existing methods suffer from resource allocation imbalances caused by homogeneous request processing. Summary of the Invention

[0005] This invention provides a traffic control method based on dual gateway collaboration to solve the problem of resource allocation imbalance.

[0006] Firstly, to address the aforementioned technical problems, this invention provides a traffic control method based on dual-gateway collaboration, comprising:

[0007] The process involves: acquiring incoming traffic requests; statistically analyzing access frequency based on these requests to obtain access frequency values; calculating admission criteria based on these access frequency values ​​to obtain initial traffic admission criteria results; performing context behavior analysis based on these initial traffic admission criteria results to obtain operation trajectories and calculate dependency strength to obtain temporal dependency strength values; generating a transaction execution path set based on preset operation combination rules when the temporal dependency strength value exceeds a preset trigger threshold; calculating resource call overlap rates for each path in the transaction execution path set and classifying the paths to obtain business logic groups; selecting the channel with the strongest throughput capacity as the critical business transmission path based on the business logic groups and performing dynamic resource regulation to obtain refined routing paths; parsing the path node relationships and marking timestamps based on the refined routing paths to obtain a context dataset; calculating the resource consumption rate for the context dataset and calculating quotas based on a preset baseline rate to obtain a resource quota table; performing stability assessment based on the resource quota table to obtain stability indicators; and updating abnormal rate limiting based on the stability indicators to obtain the updated global rate limiting configuration.

[0008] Secondly, the present invention provides a traffic control system based on dual gateway collaboration, comprising: a data acquisition module for acquiring incoming traffic requests; a judgment result module for performing access frequency statistics based on the incoming traffic requests to obtain access frequency values, and performing admission judgment calculations based on the access frequency values ​​to obtain an initial traffic admission judgment result; a dependency strength module for performing context behavior analysis based on the initial traffic admission judgment result to obtain operation trajectories and calculate dependency strength to obtain a temporal dependency strength value; and a business logic module for generating paths based on preset operation combination rules when the temporal dependency strength value is greater than a preset trigger threshold, obtaining a set of transaction execution paths, and processing each path in the set of transaction execution paths. The system calculates resource call overlap rate and categorizes paths to obtain business logic groups. A routing path module selects the channel with the strongest throughput as the critical business transmission path based on the business logic groups and performs dynamic resource control to obtain refined routing paths. A resource quota table module parses path node relationships and marks timestamps based on the refined routing paths to obtain a context dataset. It then calculates the resource consumption rate of the context dataset and calculates quotas based on a preset baseline rate to obtain a resource quota table. A global rate limiting configuration module performs stability assessment based on the resource quota table to obtain stability indicators and updates abnormal rate limiting based on the stability indicators to obtain the updated global rate limiting configuration.

[0009] Compared with the prior art, the present invention has the following beneficial effects: (1) By performing access frequency statistics and token comparison on incoming traffic requests, the present invention can determine the access qualification of request behavior in advance at the initial stage of the request, realize the rapid interception of abnormal frequency or sudden requests, improve the system's pre-control capability, and reduce the back-end processing load pressure.

[0010] (2) The present invention constructs an ordered operation trajectory based on context access records and calculates the temporal dependency strength, which can effectively identify the calling order and tight coupling relationship between services, thereby realizing a path analysis that is more in line with the actual business execution order in the flow control process, which helps to improve the accuracy of subsequent request routing.

[0011] (3) This invention uses resource call overlap rate calculation to filter out key resource paths and combines historical processing capabilities to dynamically select the optimal channel, so that the system can prioritize the core transaction, payment and other key business traffic, improve the system's stability and service continuity, and avoid important business being mistakenly limited or delayed.

[0012] (4) The present invention uses the stability score as the basis for judgment, automatically identifies abnormal time windows, and derives the optimal flow limiting configuration parameters according to the static mapping table, so as to realize the dynamic adjustment of the global flow limiting strategy, effectively cope with sudden traffic fluctuations, and ensure the overall service quality. Attached Figure Description

[0013] Figure 1 is a schematic flowchart of the flow control method based on dual gateway collaboration provided in the first embodiment of the present invention; Figure 2 is a schematic diagram of the flow control system structure based on dual gateway collaboration provided in the second embodiment of the present invention. Detailed Implementation

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

[0015] Referring to Figure 1, the first embodiment of the present invention provides a traffic control method based on dual gateway collaboration, including the following steps: S11, obtaining an incoming traffic request; S12, performing access frequency statistics based on the incoming traffic request to obtain an access frequency value, and performing admission judgment calculation based on the access frequency value to obtain an initial traffic admission judgment result; S13, performing context behavior analysis based on the initial traffic admission judgment result to obtain an operation trajectory and calculate the dependency strength to obtain a temporal dependency strength value; S14, when the temporal dependency strength value is greater than a preset trigger threshold, generating a path based on preset operation combination rules to obtain a transaction execution path set, and calculating the time-series dependency strength value for each path in the transaction execution path set. S15. Based on the resource call overlap rate, path classification is performed to obtain business logic groups; S16. Based on the business logic groups, the channel with the strongest throughput is selected as the key business transmission path, and dynamic resource regulation is performed to obtain a refined routing path; S17. Based on the refined routing path, the path node relationship is parsed and timestamps are marked to obtain a context dataset, and the resource consumption rate is calculated on the context dataset. The quota is calculated in combination with the preset baseline rate to obtain a resource quota table; S18. Based on the resource quota table, quota comparison, instruction forwarding, and stability scoring are performed to obtain stability indicators, and based on the stability indicators, instability identification and rate limiting configuration updates are performed to obtain the updated global rate limiting configuration.

[0016] It should be noted that the dual gateways described in this invention can be deployed in a primary-backup architecture, where the primary gateway is responsible for executing this traffic control method and the backup gateway synchronizes global rate limiting configuration to achieve rapid switching; or they can be deployed as a peer-to-peer cluster, where each gateway independently executes this method and makes collaborative decisions based on a shared context dataset and resource quota table to share the traffic load.

[0017] In step S11, the incoming traffic request is obtained.

[0018] It's worth noting that the process of acquiring incoming traffic requests is handled by the gateway device deployed on the access side. The system sets up a listening port, and when an external user or device sends a request message over the network, the gateway immediately captures the inbound message. This request is encapsulated in the standard HTTP protocol format. After receiving the request, the gateway parses key fields from the message header, including the source IP address, request method, destination URI, and an additional business identifier field. For example, when a user clicks the submit order button on an e-commerce platform, the HTTPS request generated by their browser will be captured and parsed by the access gateway within approximately 20 milliseconds, extracting the business identifier field containing the user's identity code and the request path field.

[0019] In step S12, based on the incoming traffic request, access frequency statistics are performed to obtain an access frequency value. Based on the access frequency value, an access control calculation is performed to obtain an initial traffic access control result. This includes: extracting the service identity identifier of the incoming traffic request; using the service identity identifier as an index, extracting historical request records within the corresponding time window from a preset local access log, and counting the number of requests to obtain an access frequency value; calculating the number of tokens based on a preset frequency classification for the access frequency value to obtain the final number of available tokens; and comparing the token consumption based on the final number of available tokens and the service identity identifier to obtain the initial traffic access control result.

[0020] It is worth noting that the security feature code and business identity field are extracted sequentially from the incoming traffic requests. The business identity is a user identifier in string form, such as "User123".

[0021] After extraction, using the business identity as the primary key, the system retrieves the access behavior of that identity within a set statistical period by calling the preset local access log cache or database records. The retrieval operation summarizes the access count based on all valid requests within the current time window, such as the past 60 minutes, and the statistical result is recorded as the access frequency value. The frequency value reflects the request activity and is used to measure whether the request behavior has an abuse tendency. For example, "User123" made 68 requests in the past hour.

[0022] Subsequently, the access frequency values ​​are categorized according to a preset frequency classification. For example, requests below 60 are considered low-frequency requests, with a token allocation rate of 10 per second and a bucket capacity of 100. Requests between 60 and 100 are considered medium-frequency requests, with a token allocation rate of 6 per second and a bucket capacity of 60. Requests exceeding 100 enter high-frequency control, with the rate reduced to 4 per second and the bucket capacity limited to 40. Combining the current system clock, the system calculates the number of tokens to be added by multiplying the time from the current time to the last token update by the token generation rate. If the calculated result, when added to the remaining quantity, exceeds the bucket capacity, the bucket capacity is used as the upper limit, ultimately yielding the currently available token inventory. For example, the system is configured with a token generation rate of 6 per second and a bucket capacity limit of 60. Since 7 seconds have passed since the last token update, 6 is multiplied by 7, calculating the number of tokens to be added as 42. If the original token inventory is 25, the theoretical total is 67. Since this value exceeds the bucket capacity limit, the system limits the actual token inventory to 60, which will be the final number of available tokens used for the current admission decision.

[0023] The preset frequency grading is based on a full analysis of access log data from the past 30 days. This analysis statistically analyzes the distribution of request counts for each business identity within a unit of time, and calculates the median, upper quartile, and 95th percentile of this distribution as the grading benchmark. Specifically, the low-frequency threshold is set below the median, the mid-frequency threshold is set between the median and the upper quartile, and the high-frequency threshold is greater than the upper quartile and close to the 95th percentile.

[0024] Finally, based on the business operation type indicated in the incoming request, the corresponding token consumption weight in the configuration file is queried. For example, a browsing request consumes 1 token, an order request consumes 5 tokens, and a payment request consumes 7 tokens. The current token inventory is compared with the weight required for the operation. If the number of available tokens is greater than or equal to the weight value required for the request, the traffic request is marked as "admission allowed" and output as the initial traffic admission judgment result; otherwise, it is marked as "admission denied," and subsequent processing of the request is terminated. For example, in a practical application, if user "User123" initiates an order request with an operation weight of 5 and currently available tokens of 27, then the request meets the admission criteria.

[0025] The token consumption weight in the configuration file is calculated using maximum-min normalization with CPU utilization as a reference metric. For example, based on historical data, browsing requests average 3% CPU utilization, order placement 12%, and payment 20%, so the normalized results are as follows: The order is placed as follows Payment is When scaled up to 10, the weights are 0, 5.3, and 10, which are rounded to obtain integer weights of 0, 5, and 10. To avoid the system ignoring processing costs due to a browsing weight of 0, the lower limit of the browsing category is adjusted to 1. At the same time, considering that although payment requests consume the most resources, their weight should not be too high, so the upper limit is set to 7. The final smoothed weights are set as follows: browsing 1, order placement 5, and payment 7.

[0026] In step S13, based on the initial traffic admission judgment result, context behavior analysis is performed to obtain the operation trajectory and calculate the dependency strength to obtain the temporal dependency strength value. This includes: based on the initial traffic admission judgment result, backtracking forward according to a preset sliding time window and sorting the backtracking records by corresponding timestamps to construct an ordered access sequence; sequentially reading the request URI field of each request record in the access sequence, converting the request URI field into a specific operation name based on a preset URI mapping table, and concatenating the specific operation names in order to form an operation trajectory; sequentially matching the operation trajectory with a preset standard business process to calculate the matching degree score; calculating the time interval between adjacent requests in the operation trajectory, and statistically analyzing the proportion of time intervals less than a preset continuous threshold to obtain a temporal continuity score; and performing a weighted average calculation on the matching degree score and the temporal continuity score to obtain the temporal dependency strength value.

[0027] It is worth noting that the initial traffic access judgment result is parsed to extract the user identity, session number, and timestamp fields of the request. Subsequently, using the timestamp of the current request as the endpoint, the process traces backward according to the sliding window time length, queries the local access log for historical request records with the same session number as the current request, and filters out records whose timestamps fall within the window range, forming an ordered access sequence. For example, the current request's timestamp is 14:30 on October 10, 2023, and the sliding window length is set to 30 minutes. The system rewinds to 14:00, retrieves historical request records with session number Session_A from the local access log, and filters out 6 records with timestamps between 14:00 and 14:30: 14:02:15 (browsing products), 14:05:20 (browsing products), 14:08:33 (searching keywords), 14:13:47 (viewing details), 14:17:05 (adding to cart), and 14:24:58 (browsing the cart). The system arranges these records in ascending order of time, forming an ordered access sequence for the current request.

[0028] Each record in the ordered access sequence is sorted by its timestamp field to ensure a strictly ascending time order. After sorting, starting from the first record, the system sequentially reads the request URI field from each record, such as " / home", " / product / view / 123", " / cart / add / 123", etc., and converts them into uniform operation names using a pre-defined URI mapping table, such as "Enter Homepage", "Browse Products", and "Add to Cart". After conversion, the system concatenates these operation names according to the sorted record order, for example, "Enter Homepage → Browse Products → Browse Products → Add to Cart → View Cart → Submit Order". The entire concatenation process maintains the original chronological order of the requests, forming a directed operation trajectory. The pre-defined URI mapping table is manually configured and generated by system administrators based on various request paths and their corresponding business functions, usually derived from backend interface documentation or business routing rules. For example, " / product / view" is mapped to "Browse Products", and " / cart / add" is mapped to "Add to Cart", to achieve a unified conversion from request paths to operation names.

[0029] Subsequently, the operation trajectory is compared with the standard operation process. The standard process is manually set and clearly defines the sequence of various typical business behaviors, such as "browse products → add to cart → submit order". The system sequentially matches each operation in the current operation trajectory with the standard process. If the sequence matches and no steps are skipped, it is scored as 1 point; otherwise, it is scored as 0 points. Assuming the standard process contains 3 operation steps, and the user's operation trajectory completes 2 steps in sequence, the sequence matching degree is 2 divided by 3, resulting in 0.67.

[0030] Next, the time interval between two adjacent requests in the operation trajectory is statistically analyzed to determine whether it is less than the set continuity threshold of 10 minutes. If there are a total of 5 sets of adjacent requests, and 4 of them have an interval of no more than 10 minutes, then the time continuity score is 4 divided by 5, resulting in 0.8.

[0031] Finally, the temporal dependency strength value is calculated by weighted averaging using the order matching degree and temporal continuity score as two independent dimensions. If the system presets the order matching weight to be 0.6 and the temporal continuity weight to be 0.4, then the temporal dependency strength value of this request is 0.6×0.67+0.4×0.8=0.402+0.32=0.722.

[0032] The continuous threshold is statistically set based on the temporal distribution characteristics of historical request behavior. A large number of user access sequences over a past period are sampled and analyzed. The data approximately follows a normal distribution, and the mean plus twice the standard deviation is used as the basis for setting the threshold. For example, if the mean is 6 minutes and the standard deviation is 2 minutes, then the continuous threshold is set to 10 minutes.

[0033] The weighting of the sequence matching score and the time continuity score is based on correlation analysis with the final business stability indicator. The system calculates the Pearson correlation coefficients between these two dimensions and the target variable (such as business link success rate) using a large amount of historical data. If the correlation coefficient of the sequence matching score is significantly higher than that of the time continuity score, for example, 0.72 and 0.58, the system sets the weight of sequence matching to 0.6 and the weight of time continuity to 0.4.

[0034] In step S14, when the temporal dependency strength value is greater than a preset trigger threshold, a path is generated based on a preset operation combination rule to obtain a transaction execution path set. The resource call overlap rate is calculated for each path in the transaction execution path set, and the paths are categorized to obtain business logic groups. This includes: generating request diversification tags when the temporal dependency strength value is greater than the preset trigger threshold; traversing all request diversification tags based on the preset operation combination rule and querying behavior paths to obtain a transaction execution path set; calculating the resource call overlap rate for each path in the transaction execution path set and constructing a resource overlap relationship matrix based on the overlap rate results between all pairs of paths; traversing the resource overlap relationship matrix and aggregating path pairs with overlap rates greater than a preset overlap threshold to obtain business logic groups.

[0035] It's worth noting that when the temporal dependency strength value exceeds the preset trigger threshold of 0.75, the request corresponding to the temporal dependency strength value is marked as a high-dependency request. The system extracts the URI field of each request from the request list within the current session and calls a preset URI mapping table to convert these URI paths into standard operation names. Subsequently, the system categorizes and counts the requests within the current sliding window based on the operation name. If the number of operation types reaches or exceeds three, a request diversification label is generated. This label includes the type of operation, the time span, and the total number of operations. For example, if a user continuously initiates three requests with different URIs " / product / view", " / cart / add", and " / order / pay" within 60 seconds, the system maps these to three operation types: "browse product", "add to cart", and "submit payment". Since the number of operation types reaches three, the system generates a request diversification label accordingly and records the operation type as 3, the time span as 60 seconds, and the total number of requests as 3.

[0036] The preset trigger threshold is set based on the time-series dependency strength values ​​of all completed business requests within the past 30 days as a sample dataset. The mean and standard deviation of this dataset are calculated to construct an approximate normal distribution curve. Analysis revealed that the strength values ​​are concentrated around 0.5, with a standard deviation of approximately 0.12. The tail end of the distribution, located one to two standard deviations to the right of the mean, is selected as the high-dependency request trigger threshold region. Specifically, the upper limit of the threshold is calculated as 0.5 + 2 × 0.12 = 0.74, calculated by adding twice the standard deviation to the mean. The system ultimately rounds this up to 0.75.

[0037] Subsequently, all request diversity tags are traversed, and a set of transaction execution paths is constructed according to preset operation combination rules. The preset operation combination rules are as follows: product search → product comparison → return to homepage is a single information query behavior path; address editing → coupon selection → order submission is an order preparation path; login authentication → real-name verification → risk control check can be combined into an identity verification path.

[0038] Subsequently, the system iterates through the set of transaction execution paths, extracts the backend service interfaces involved in each path, and constructs a mapping table of "path ID → interface list". For example, path A calls interfaces {inventory service, payment service, product service}, while path B calls interfaces {inventory service, payment service, coupon service}. The system then compares the interface sets of any two paths, counts the number of intersections, i.e., the number of service interfaces called repeatedly; and records the total number of service interface lists in the paths being compared. The overlap rate is calculated by dividing the absolute value of the interface intersection by the minimum of the absolute values ​​of the number of interfaces in path A and path B, where the absolute value represents the number of elements in the set. The path with the smallest number of interfaces is used as the standardization benchmark to avoid calculation deviations due to different path lengths. Taking path A and path B as an example, the intersection is {inventory service, payment service}, the intersection size is 2, path A has 3 total interfaces, and path B has 3, so the overlap rate is 2÷3=0.666.

[0039] After calculating the resource call overlap rate between paths, the system uses the overlap rate results between all pairs of paths as input to construct a resource overlap relationship matrix. This matrix uses path IDs as row and column coordinates, with each cell recording the overlap rate value between the corresponding two paths. The system iterates through this matrix, filtering out path pairs with an overlap rate greater than a set merging threshold. For example, path pairs with an overlap rate greater than the preset overlap threshold of 0.5 are considered to have a resource contention relationship, and a group of paths with indirect overlap relationships is aggregated into a single business logic group.

[0040] The preset overlap threshold is calculated by pairwise mapping of resource call overlap rates for all transaction execution paths generated within the past week, constructing a complete overlap rate distribution sample set. On this sample set, the system calculates a mean resource call overlap rate of 0.31 and a standard deviation of 0.09. Based on the normal distribution trend of the overlap rate, the overlap threshold is set using the mean plus twice the standard deviation. Specifically, it is calculated as 0.31 + 2 × 0.09 = 0.49. The system ultimately rounds this value up to 0.5 as the threshold for judging the resource call overlap rate.

[0041] In step S15, based on the business logic grouping, the channel with the strongest throughput is selected as the critical business transmission path, and dynamic resource adjustment is performed to obtain a refined routing path. This includes: performing criticality identification processing based on the business logic grouping to obtain a critical business identifier; scanning resource channels based on the critical business identifier and selecting the channel with the highest average request processing capacity as the critical business transmission path; allocating dedicated resource segments to the critical business transmission path to obtain a refined routing path.

[0042] It's worth noting that these business logic groups are traversed sequentially, with paths involving "payment confirmation" and "order submission" marked as "high priority," and paths involving only "product browsing" marked as "normal priority." If an operation name in the current group matches the "high priority" tag, the system generates a protection decision requirement for that group and writes it into the corresponding critical business identifier. The critical business identifier contains service quality objectives related to that group, such as maximum response latency, minimum request success rate, and service availability requirements. For example, if the business group involves payment operations, the system will write the target requirements of a maximum response time of no more than 200 milliseconds, a request success rate of no less than 99%, and a service availability of no less than 99.9% into the critical business identifier.

[0043] Subsequently, a resource channel scanning operation is performed on groups based on the critical service identifier, selecting the channel with the strongest throughput from multiple available transmission channels as the transmission path for the critical service. For example, by statistically analyzing the real-time request processing volume of each channel over the past 5 minutes, it is determined that channel A has an average request processing capacity of 5000 requests per second, while other channels have a lower average request processing capacity than channel A. Therefore, channel A is preferentially selected as the transmission path for the critical service.

[0044] Finally, dedicated resource segments are allocated to the transmission paths of critical services to obtain refined routing paths. For example, 70% of the resource weight in this channel is allocated to the current critical service group, and the remaining resources are allocated to non-critical services. If, during a peak promotional period, the system detects a surge in payment requests to 400 per second within one minute, the channel weight for critical services will be increased to 90%. Here, allocating dedicated resource segments means configuring guaranteed bandwidth quotas and / or maximum concurrent connection limits for the transmission path of the critical service to ensure its transmission capacity.

[0045] The initial resource allocation ratio for critical business channels was set at 70%, based on the statistical results of the average resource utilization ratio of critical business operations over the past 30 days, which ranged between 65% and 75%. A trigger threshold of 400 requests per second was used for dynamic adjustment, derived from the upper quartile of access density during promotional activities, effectively reflecting sudden traffic spikes. After triggering, the channel weight was increased to 90% through multiple comparative experiments simulating the impact of different resource allocation ratios on system performance under high concurrency. The system simulation tested the response time and success rate changes when critical business operations occupied 60%, 70%, 80%, and 90% of channel resources. The results showed that when the allocation ratio was 90%, critical business operations could stably maintain a response time within 200 milliseconds with a success rate exceeding 99%, while non-critical business operations still had 10% of resources available, preventing overall congestion. Therefore, 90% was selected as the optimal increase value during peak periods.

[0046] In step S16, based on the refined routing path, the relationship between path nodes is parsed and timestamps are added to obtain a context dataset. The resource consumption rate of the context dataset is then calculated, and a quota is calculated based on a preset baseline rate to obtain a resource quota table. This includes: identifying the upstream and downstream relationships and redundancy structures of each node in the refined routing path to obtain topology features; adding timestamps based on the topology features to form a context dataset; calculating the resource consumption rate of the context dataset within a preset sliding time window to obtain a resource growth rate; and adjusting the original resource quota of the context dataset if the resource growth rate is greater than the preset baseline rate to obtain a resource quota table.

[0047] It is worth noting that identifying the upstream and downstream relationships of each node in a refined routing path, the existence of redundant forwarding paths, and the path depth extracts topological features. For example, if a payment link path sequentially passes through an access gateway, distributed routing nodes, core switching nodes, and the payment service interface, and there are backup channels in between, then the path is identified as a linear backbone + redundant branch topology.

[0048] After completing topology feature matching, fingerprint information from the packet headers of key traffic along the path is extracted, including fields such as source IP, destination port, protocol type, and session identifier. Simultaneously, the arrival time of each packet is appended as a timestamp, constructing a raw context dataset containing both content and timing. For example, in payment request packets, the destination ports are concentrated in the range of 443 to 8443, and the protocol is mostly HTTPS. The system tags this type of traffic and associates it with its timestamp information to distinguish it from ordinary browsing behavior.

[0049] Subsequently, resource consumption trends are calculated for the context dataset. Specifically, a fixed-length sliding time window is set, such as 5 seconds. Within this time range, the total number of bytes in all data packets within the aggregated context is accumulated, and the arrival frequency of the data packets is recorded. Then, the system calculates the resource growth rate per unit time based on the difference between the first and last byte values ​​of this time period. For example, if the cumulative byte count of a certain context relationship increases from 320KB to 1.8MB within 5 seconds, its resource growth rate is (1.8MB - 0.32MB) divided by 5 seconds, approximately 0.296MB / s. The system compares this rate with a preset baseline rate. If it exceeds 2.5 times the baseline value, the system determines that the context relationship exhibits a sudden resource consumption trend.

[0050] The preset baseline rate is derived from historical business traffic statistics. For example, if the system analyzes data from the past 30 days and finds that the average byte growth rate within a 5-second window in a normal payment business flow is approximately 0.1 MB / s, this value is used as the baseline growth rate for resource consumption. Subsequently, when the system detects that the actual growth rate of a certain aggregation context exceeds 2.5 times this value, i.e., exceeds 0.25 MB / s, it will determine that there is a sudden increase in resource consumption in that context.

[0051] After identifying a sudden increase in demand, a quota adjustment factor is set to 1.4. This factor is multiplied by the original resource usage quota; for example, if the original allocation was 12%, it will be adjusted to 16.8%. The system dynamically updates the resource usage ratio corresponding to the current path accordingly. For instance, during a peak promotional period, if a certain payment path is frequently accessed, the system will increase its bandwidth guarantee from the original 300Mbps to 420Mbps based on the detection results to ensure that user payments do not time out.

[0052] Ultimately, the system will output all the analysis results of the context relationships as a unified resource quota table.

[0053] The quota adjustment factor was set based on comparative experiments of a large number of historical business requests under different quota configurations. Using typical payment requests from the past 30 days as samples, the system set quota occupancy ratios to the default value (12%), 1.2 times (14.4%), 1.4 times (16.8%), and 1.6 times (19.2%), respectively. The response time and success rate performance corresponding to each ratio were tested under a high-concurrency simulation environment. Experimental results showed that when the quota was maintained at the default value of 12%, the response time exceeded 250 milliseconds under high concurrency, and the success rate dropped to 93%. When increased to 1.2 times, the response time slightly decreased to 220 milliseconds, and the success rate rebounded to 96%. Under a quota of 1.4 times, the response time was compressed to 190 milliseconds, and the success rate stabilized at 99%. Further increasing to 1.6 times did not significantly reduce the response time, but the overall system resource pressure increased significantly, and the congestion rate of non-critical business operations rose. Based on the above analysis, 1.4 was selected as the optimal quota adjustment factor.

[0054] In step S17, a stability assessment is performed based on the resource quota table to obtain a stability index. Then, based on the stability index, an abnormal rate limiting update is performed to obtain an updated global rate limiting configuration. This includes: extracting the resource occupancy ratio of critical paths based on the resource quota table, comparing the resource occupancy ratio with the remaining bandwidth or processing capacity of the target service node, and generating a forwarding instruction if the quota requirement is met; executing the forwarding instruction and collecting load data to obtain payment response data; generating a stability index based on the payment response data; if the stability index is lower than a preset stability threshold for two consecutive preset time periods, the current time period is identified as an unstable window, and the traffic peak characteristics of the unstable window are obtained; and updating the rate limiting parameters based on the traffic peak characteristics to obtain the updated global rate limiting configuration.

[0055] It's worth noting that the system extracts the resource usage ratio corresponding to each critical path from the quota table and compares this ratio with the current remaining bandwidth or processing capacity of the target service node. If the quota value is less than or equal to the node's real-time remaining capacity, the system immediately generates a forwarding instruction to distribute the corresponding business request to that node. Taking an e-commerce platform as an example, if the path quota for a payment request is 500 Mbps, and the node's real-time available bandwidth is 700 Mbps, then the system determines that resources are sufficient and will execute the forwarding.

[0056] Upon receiving the forwarding instruction, the target service node immediately executes its business logic, such as processing payment instructions and recording account status. During execution, the system synchronously collects load data from the node, including CPU utilization, memory usage, and concurrent request counts, and encapsulates this data into feedback signals. These feedback signals are encrypted during the return process and appended with a 32-bit checksum. The checksum generation process involves extracting key fields from the message, such as the request sequence number, generation timestamp, and node load summary, and concatenating these fields in a fixed order into a raw string. For example, "REQ20260122001", "1705908923", "CPU=45", "MEM=61", and "LAT=188" are concatenated into a complete data string. Subsequently, the system performs a hash calculation on this string, commonly using MD5 or SHA-256, to quickly generate a unique checksum, such as "A12F3C5D78B9E0AB12345678CDEF9AB1". Ultimately, the system embeds the verification code as a field in the response message for the receiving end to compare and verify. When the receiving end receives the message, it regenerates the verification code using the same field order and compares it. If they match, the message is marked as valid, and a payment response data with a success status code is generated accordingly. If they do not match, the message is marked as abnormal and entered into the payment response data.

[0057] Subsequently, the system records the time and identifies the status of each received payment response data, extracting the response latency and error status codes. Response latency refers to the time difference between the client sending the request and the server returning confirmation, calculated in milliseconds. Error status codes are returned by the server after processing the request; for example, status code 200 indicates successful processing, and status code 500 indicates an internal service error. Based on this, the system calculates the average response latency and the proportion of various error status codes per minute, thereby constructing a unified system stability index. Specifically, the system stability index uses a percentage-based scoring system, comprehensively considering both response latency and error status code proportions. First, the difference between the response time and return time for each request is calculated to obtain the response latency. A full score threshold of 200 milliseconds is set; if a request responds within 200 milliseconds, this part scores 100 points. If the response latency exceeds 200 milliseconds but is less than 500 milliseconds, approximately 0.33 points are deducted linearly for every 1 millisecond exceeding this threshold; if it exceeds 500 milliseconds, this item scores 0 points. Secondly, the system calculates the proportion of error status codes occurring within the current time window and assigns weight coefficients based on the severity of different error types. For example, the weight of error type 500 is 1.0, 408 request timeout is 0.8, and 404 resource not found is 0.3. The system multiplies the proportion of each type of error by its corresponding weight and sums the results to obtain the error deduction value for that time window. Finally, the system stability index is the base response score minus the error deduction value, with the value ranging from 0 to 100. For example, if the average request response time during a certain period is 230 milliseconds, corresponding to a base score of 90, and 8% of 500 errors, 5% of 408 errors, and 2% of 404 errors occur simultaneously, the corresponding deduction is 8 × 1.0 + 5 × 0.8 + 2 × 0.3 = 12.6. Therefore, the final system stability index is 90 minus 12.6, resulting in 77.4 points. The following are the calculation weights for each type of status code:

[0058] To assign weights to various error status codes in the system stability metrics, a correlation analysis method based on the impact of historical failures was employed. Specifically, a large amount of response data from the past 30 days was selected, and the frequency of each error type (e.g., 500, 408, 404, etc.) was statistically analyzed at different time intervals. This frequency was then compared with key business performance metrics (e.g., request success rate, average response time, order completion rate, etc.) during the same period using Pearson correlation coefficient analysis. If the frequency of a certain error status is highly positively correlated with a decline in key business performance (e.g., correlation coefficient greater than 0.8), this type of error is classified as a high-impact error and assigned a high weight (e.g., 1.0). If the correlation is moderate (correlation coefficient between 0.5 and 0.8), a moderate weight is assigned (e.g., 0.6 to 0.8). If the correlation is low or unstable, a smaller weight is assigned (e.g., below 0.3). For example, historical statistics show that the correlation coefficient between the frequency of 500 errors and the decrease in the system's average order completion rate is 0.91, and the system sets its weight to 1.0 accordingly; while the correlation coefficient of 404 errors is only 0.25, indicating that it has a small impact on the overall business, so its corresponding weight is only set to 0.3.

[0059] The system updates stability metrics every five minutes. If the stability metrics fall below the stability threshold of 60 for two consecutive periods, the current time period is marked as an unstable window. Subsequently, the system extracts the arrival timestamp sequence of all requests within this unstable window to generate corresponding traffic peak characteristics, including request density per unit time, burst request duration, and peak duration. For example, the system detects that the request density reaches 1300 requests per second during a certain period, with the peak lasting for 3 minutes.

[0060] Based on the peak traffic characteristics, the system queries a preset static mapping relationship to match the token generation rate and bucket capacity corresponding to the current request rate. For example, if a peak request volume of 1300 requests per second is detected within a high-concurrency time window, the system will look up the corresponding interval of 1100 to 1300 requests per second in the mapping table, and accordingly select a token generation rate of 900 tokens per second and a bucket capacity of 3000 tokens. The system then writes this set of parameters into the rate limiting rule table and synchronously distributes the updated rate limiting parameters to all access nodes. In this way, each entry node will control the request rate and burst buffer capacity according to a unified strategy, forming consistent traffic control behavior.

[0061] Ultimately, based on this distribution process, the system obtains an updated global rate limiting configuration, effectively responding to sudden traffic surges and preventing service overload.

[0062] The default static mapping relationship is as follows: when the peak request volume is between 700 and 900 times / second, the corresponding token generation rate is set to 600 times / second and the bucket capacity is 1500. When the peak request volume is between 900 and 1100 times / second, the token generation rate is increased to 750 times / second and the bucket capacity is set to 2500. When the peak request volume is between 1100 and 1300 times / second, the system-configured token generation rate is 900 times / second and the corresponding bucket capacity is 3000. If the peak request volume increases to the range of 1300 to 1500 times / second, the system will adjust the token generation rate to 1050 times / second and increase the bucket capacity to 4000.

[0063] The stability threshold was set at 60, derived from historical response data using a normal distribution statistical method. The system first collected a large amount of system stability score data from the past 30 days, with each score calculated based on a weighted average of response latency and error state. The historical data distribution approximates normality, with a mean of 74 and a standard deviation of 7 for all scores. The threshold was then calculated by subtracting twice the standard deviation of 74 from the mean. 2×7=60 is used as the lower limit threshold for stability.

[0064] The pre-defined static mapping relationship was constructed using both offline simulation and real-world test data. Specifically, the system team pre-defined several typical peak traffic ranges, such as 800 times / second, 1000 times / second, 1200 times / second, and 1400 times / second, and tested the impact of different token generation rates and bucket capacity configurations on the system's processing capacity in a simulated environment. For example, at a traffic volume of 1200 times / second, different combinations of generation rates of 700, 800, and 900 tokens / second and bucket capacities of 2000, 2500, and 3000 were tested, recording the system's maximum response latency, error rate, resource utilization, and other performance metrics. Finally, the optimal parameter combination that maintained a response time below 200 milliseconds, an error rate below 1%, and balanced system load under this traffic volume was selected and written into the static mapping table.

[0065] Referring to Figure 2, a second embodiment of the present invention provides a traffic control system based on dual gateway collaboration, comprising: a data acquisition module for acquiring incoming traffic requests; a judgment result module for performing access frequency statistics based on the incoming traffic requests to obtain access frequency values, and performing admission judgment calculations based on the access frequency values ​​to obtain an initial traffic admission judgment result; a dependency strength module for performing context behavior analysis based on the initial traffic admission judgment result to obtain operation trajectories and calculate dependency strength to obtain a temporal dependency strength value; and a business logic module for generating a path based on preset operation combination rules when the temporal dependency strength value is greater than a preset trigger threshold to obtain a transaction execution path set, and processing the transaction execution path set... The system calculates the resource call overlap rate for each path and categorizes the paths to obtain business logic groups. The routing path module selects the channel with the strongest throughput as the key business transmission path based on the business logic groups and performs dynamic resource control to obtain refined routing paths. The resource quota table module parses the path node relationships and marks timestamps based on the refined routing paths to obtain a context dataset. It then calculates the resource consumption rate of the context dataset and calculates the quota based on a preset baseline rate to obtain a resource quota table. The global rate limiting configuration module performs stability assessment based on the resource quota table to obtain stability indicators and updates the rate limiting for abnormal situations based on the stability indicators to obtain the updated global rate limiting configuration.

[0066] It should be noted that the flow control system based on dual gateway collaboration provided in this embodiment of the invention is used to execute all the process steps of the flow control method based on dual gateway collaboration in the above embodiment. The working principles and beneficial effects of the two are one-to-one, so they will not be described again.

[0067] It should be noted that the system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the system embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0068] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A flow control method based on dual-gateway collaboration, characterized in that, include: Get incoming traffic requests; Based on the incoming traffic request, access frequency statistics are performed to obtain access frequency values. Based on the access frequency values, admission judgment calculation is performed to obtain initial traffic admission judgment results. Based on the initial traffic admission judgment results, context behavior analysis is performed to obtain operation trajectories and calculate dependency strength to obtain time-series dependency strength values. When the time-series dependency strength value is greater than the preset trigger threshold, a path is generated based on the preset operation combination rules to obtain a transaction execution path set. The resource call overlap rate is calculated for each path in the transaction execution path set, and the paths are classified to obtain business logic groups. According to the business logic groups, the channel with the strongest throughput is selected as the key business transmission path, and dynamic resource adjustment is performed to obtain a refined routing path. Based on the refined routing path, the path node relationships are parsed and timestamps are marked to obtain a context dataset. The resource consumption rate is calculated on the context dataset, and the quota is calculated in combination with the preset baseline rate to obtain a resource quota table. Based on the resource quota table, a stability assessment is performed to obtain stability indicators. Based on the stability indicators, anomaly rate limiting is updated to obtain the updated global rate limiting configuration.

2. The flow control method based on dual gateway collaboration according to claim 1, characterized in that, The step of performing access frequency statistics based on the incoming traffic request to obtain an access frequency value, and then performing access judgment calculation based on the access frequency value to obtain an initial traffic access judgment result, includes: extracting the business identity identifier of the incoming traffic request; using the business identity identifier as an index to extract historical request records within the corresponding time window from a preset local access log, and counting the number of requests to obtain an access frequency value; calculating the number of tokens based on the access frequency value according to a preset frequency classification to obtain the final number of available tokens; and comparing the token consumption based on the final number of available tokens and the business identity identifier to obtain the initial traffic access judgment result.

3. The flow control method based on dual-gateway collaboration according to claim 1, characterized in that, The step of performing contextual behavior analysis based on the initial traffic access judgment result to obtain the operation trajectory and calculate the dependency strength to obtain the temporal dependency strength value includes: based on the initial traffic access judgment result, backtracking forward according to a preset sliding time window and sorting the backtracking records according to the corresponding timestamps to construct an ordered access sequence; sequentially reading the request URI field of each request record in the access sequence, and converting the request URI field into a specific operation name based on a preset URI mapping table, and concatenating the specific operation names in order to form an operation trajectory; sequentially matching the operation trajectory with a preset standard business process and calculating the matching degree score; calculating the time interval between adjacent requests in the operation trajectory, and statistically analyzing the proportion of the time interval less than a preset continuous threshold to obtain a time continuity score; and performing a weighted average calculation on the matching degree score and the time continuity score to obtain the temporal dependency strength value.

4. The flow control method based on dual gateway collaboration according to claim 1, characterized in that, When the temporal dependency strength value is greater than a preset trigger threshold, a path is generated based on preset operation combination rules to obtain a transaction execution path set. The resource call overlap rate is calculated for each path in the transaction execution path set, and the paths are categorized to obtain business logic groups. This includes: generating request diversification tags when the temporal dependency strength value is greater than the preset trigger threshold; traversing all request diversification tags based on preset operation combination rules and querying behavior paths to obtain a transaction execution path set; calculating the resource call overlap rate for each path in the transaction execution path set and constructing a resource overlap relationship matrix based on the overlap rate results between all pairs of paths; traversing the resource overlap relationship matrix and aggregating path pairs with overlap rates greater than a preset overlap threshold to obtain business logic groups.

5. The flow control method based on dual gateway collaboration according to claim 1, characterized in that, The step of selecting the channel with the strongest throughput as the critical service transmission path based on the business logic grouping and performing dynamic resource adjustment to obtain a refined routing path includes: performing criticality identification processing based on the business logic grouping to obtain a critical service identifier; scanning resource channels based on the critical service identifier and selecting the channel with the highest average request processing capacity as the critical service transmission path; and allocating dedicated resource segments to the critical service transmission path to obtain a refined routing path.

6. The flow control method based on dual gateway collaboration according to claim 1, characterized in that, The process of parsing the path node relationships and marking timestamps based on the refined routing path to obtain a context dataset, and calculating the resource consumption rate of the context dataset, combined with a preset baseline rate to calculate the quota, and obtaining a resource quota table includes: identifying the upstream and downstream relationships and redundancy structure of each node in the refined routing path to obtain topology features; marking timestamps based on the topology features to form a context dataset; calculating the resource consumption rate of the context dataset within a preset sliding time window to obtain the resource growth rate; and adjusting the original resource quota of the context dataset if the resource growth rate is greater than the preset baseline rate to obtain a resource quota table.

7. The flow control method based on dual gateway collaboration according to claim 1, characterized in that, The process of performing stability assessment based on the resource quota table to obtain stability indicators, and then performing abnormal rate limiting updates based on the stability indicators to obtain updated global rate limiting configurations, includes: extracting the resource occupancy ratio of critical paths based on the resource quota table, comparing the resource occupancy ratio with the remaining bandwidth or processing capacity of the target service node, and generating a forwarding instruction if the quota requirements are met; executing the forwarding instruction and collecting load data to obtain payment response data; generating stability indicators based on the payment response data; identifying the current time period as an unstable window when the stability indicator is lower than a preset stability threshold for two consecutive preset time periods, and obtaining the traffic peak characteristics of the unstable window; and updating rate limiting parameters based on the traffic peak characteristics to obtain updated global rate limiting configurations.

8. A flow control system based on dual gateway collaboration, characterized in that, include: The data acquisition module is used to acquire incoming traffic requests; The judgment result module is used to perform access frequency statistics based on the incoming traffic request, obtain the access frequency value, and perform admission judgment calculation based on the access frequency value to obtain the initial traffic admission judgment result. The dependency strength module is used to perform context behavior analysis based on the initial traffic admission judgment result, obtain the operation trajectory and calculate the dependency strength to obtain the time-series dependency strength value. The business logic module is used to generate a set of transaction execution paths based on preset operation combination rules when the time-series dependency strength value is greater than a preset trigger threshold, calculate the resource call overlap rate for each path in the set of transaction execution paths, and classify the paths to obtain business logic groups. The routing path module is used to select the channel with the strongest throughput as the key business transmission path according to the business logic grouping, and to perform dynamic resource adjustment to obtain a refined routing path. The resource quota table module is used to parse the path node relationship and mark the timestamp according to the fine-grained routing path to obtain the context dataset, and calculate the resource consumption rate of the context dataset, and calculate the quota in combination with the preset baseline rate to obtain the resource quota table. The global rate limiting configuration module is used to perform stability assessment based on the resource quota table, obtain stability indicators, and perform abnormal rate limiting updates based on the stability indicators to obtain the updated global rate limiting configuration.

Images