Dynamic interface request flow control method and device, terminal and medium

Abstract

The invention discloses an interface request flow dynamic control method and device, a terminal and a medium, and relates to the technical field of the Internet, and the scheme provided by the invention enables a flow control strategy to reflect the actual processing capability of a server in real time by establishing the dynamic association between a flow limiting threshold and a resource state. By analyzing the relationship between the resource utilization rate and the request processing capacity, it is found that higher request processing capacity is allowed in the idle state of the resources, and the processing threshold should be reduced when the resources are nearly fully loaded. A linkage mechanism of a flow pressure index and resource capacity scheduling is further considered, when the flow pressure exceeds a preset interval, an elastic capacity expansion and contraction operation is triggered, cooperative closed-loop control of flow limiting and capacity expansion is achieved, and a flow limiting threshold value and the resource capacity form dynamic matching.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet, and particularly relates to an interface request flow dynamic control method and device, a terminal and a medium. BACKGROUND

[0002] With the rapid development of Internet business, the request flow faced by system interface presents significant volatility: for example, the killing activity of e-commerce platform, the hot event of social software, the periodic report generation of enterprise service and the like, which can all cause the surge of interface request quantity in a short time (peak flow can reach 10-100 times of daily flow). If the system cannot effectively cope with such flow fluctuation, it can cause service response delay, resource exhaustion and even overall collapse, directly affecting user experience and business continuity.

[0003] To cope with flow fluctuation, the industry generally adopts two core technical means of "flow limiting" and "capacity expansion". Flow limiting (such as through token bucket algorithm or gateway layer filter) intercepts excessive requests by presetting fixed request rate threshold (such as QPS) to prevent system overload; capacity expansion (such as through automatic scaling group of cloud platform or Kubernetes HPA) dynamically increases computing resources by monitoring resource indicators (such as CPU, memory usage) to improve overall system processing capacity.

[0004] However, the flow limiting and capacity expansion mechanisms of the current mainstream implementation scheme are independent of each other, lack of coordination, and often cause response lag, resource waste and the like in actual application scenarios, therefore, how to make the two work together to maximize resource utilization rate while ensuring system stability has become a technical problem to be solved by the technical personnel in the field. SUMMARY

[0005] The present application provides an interface request flow dynamic control method, device, terminal and medium, which is used to realize the purpose of ensuring system stability while maximizing resource utilization.

[0006] To solve the above technical problem, the first aspect of the present application provides an interface request flow dynamic control method, comprising:

[0007] collecting QPS data of Internet interface and resource usage monitoring data of server in real time;

[0008] calculating a dynamic flow limiting threshold according to the resource monitoring data, in combination with preset resource usage indicator data and dynamic flow limiting threshold calculation formula;

[0009] determining a flow pressure index according to the numerical difference between the QPS data and the dynamic flow limiting threshold;

[0010] According to a comparison result of the traffic pressure index and the traffic pressure index interval, a resource capacity scheduling strategy of the service end is determined.

[0011] Preferably, the resource usage index data comprises a request processing reference threshold, a safe resource usage rate threshold, and a maximum tolerable threshold of resource usage rate, wherein the reference threshold is a maximum request processing capacity of the service end in a resource idle state.

[0012] Preferably, the dynamic throttling threshold calculation formula is specifically:

[0013]

[0014] In the formula, is the dynamic throttling threshold, is a request processing reference threshold, is the resource usage monitoring data, is the safe resource usage rate threshold, is the maximum tolerable threshold of resource usage rate, is an adjustment coefficient for balancing throttling intensity.

[0015] Preferably, it further comprises:

[0016] According to an interface priority classification of the Internet interface, in combination with a preset corresponding relationship between the interface priority classification and a redundancy coefficient, a redundancy coefficient corresponding to the Internet interface is determined;

[0017] The historical traffic peak value of the Internet interface is counted, and according to the historical traffic peak value and the redundancy coefficient, a request processing reference threshold of the Internet interface is determined.

[0018] Preferably, according to a numerical difference between the QPS data and the dynamic throttling threshold, the traffic pressure index is determined to comprise:

[0019] According to a ratio or difference between the QPS data and the dynamic throttling threshold, the traffic pressure index is determined.

[0020] Preferably, according to a comparison result of the traffic pressure index and the traffic pressure index interval, the resource capacity scheduling strategy of the service end is determined to comprise:

[0021] When the traffic pressure index exceeds the range of the traffic pressure index interval and is greater than the upper limit of the traffic pressure index interval, service end capacity expansion logic is triggered;

[0022] When the traffic pressure index exceeds the range of the traffic pressure index interval and is less than the lower limit of the traffic pressure index interval, service end capacity reduction logic is triggered.

[0023] Preferably, determining the resource capacity scheduling strategy of the service end further comprises:

[0024] When the service end expansion logic trigger is detected, the excess requests are buffered through a preset cache queue;

[0025] When the service end expansion is completed, the excess requests in the cache queue are pushed to the service end.

[0026] The second aspect of the present application provides an interface request flow dynamic control device, comprising:

[0027] A data acquisition unit is configured to acquire QPS data of an Internet interface and resource usage monitoring data of a service end in real time;

[0028] A dynamic throttling threshold calculation unit is configured to calculate a dynamic throttling threshold according to the resource monitoring data, in combination with preset resource usage index data and a dynamic throttling threshold calculation formula;

[0029] A flow pressure index calculation unit is configured to determine a flow pressure index according to a numerical difference between the QPS data and the dynamic throttling threshold;

[0030] A resource capacity scheduling strategy determination unit is configured to determine a resource capacity scheduling strategy of the service end according to a comparison result of the flow pressure index and the flow pressure index interval.

[0031] The third aspect of the present application provides an interface request flow dynamic control terminal, comprising a memory and a processor;

[0032] The memory is configured to store program code corresponding to the interface request flow dynamic control method provided by the first aspect of the present application;

[0033] The processor is configured to read and execute the program code to implement the interface request flow dynamic control method.

[0034] The fourth aspect of the present application provides a computer readable storage medium, which stores program code for being read and executed by a processor to implement the interface request flow dynamic control method provided by the first aspect of the present application.

[0035] From the above technical solutions, the present application has the following advantages:

[0036] The scheme provided in the application establishes dynamic association of the flow limiting threshold and the resource state, so that the flow control strategy can reflect the actual processing capacity of the server in real time. By analyzing the relationship between resource utilization and request processing capacity, it is found that a higher request processing capacity is allowed in the resource idle state, and the processing threshold should be reduced when the resource is close to full load. Further considering the linkage mechanism of flow pressure index and resource capacity scheduling, when the flow pressure exceeds the preset interval, the elastic expansion and contraction operation is triggered to realize the collaborative closed-loop control of flow limiting and expansion, so that the flow limiting threshold and the resource capacity form dynamic matching. BRIEF DESCRIPTION OF DRAWINGS

[0037] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0038] Figure 1 The flowchart of an interface request flow dynamic control method embodiment provided by the present application.

[0039] Figure 2 The architecture diagram of an interface request flow dynamic control device embodiment provided by the present application.

[0040] Figure 3 The architecture diagram of an interface request flow dynamic control terminal embodiment provided by the present application. DETAILED DESCRIPTION

[0041] In the prior art, the rapid development of Internet business leads to significant volatility of interface request flow. For example, the killing activity of e-commerce platform or the hot event of social software may cause the interface request to increase to tens of times of the daily level. The traditional technology intercepts excess requests by fixed flow limiting threshold, or performs expansion operation based on resource utilization, but the flow limiting and expansion mechanisms operate independently. The fixed flow limiting threshold cannot adapt to the dynamic change of resource load state, and the expansion decision simply relying on resource indicators has response lag, resulting in service response delay or resource waste.

[0042] In order to solve the above problems, it is necessary to establish dynamic association of the flow limiting threshold and the resource state, so that the flow control strategy can reflect the actual processing capacity of the server in real time. In view of this, the present application provides an interface request flow dynamic control method, device, terminal and medium, which is used to realize the purpose of maximizing resource utilization while ensuring system stability.

[0043] In order to make the purposes, characteristics and advantages of the present application more obvious and easy to understand, the technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the embodiments described below are only some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor fall within the scope of protection of the present application.

[0044] First, a detailed description of an embodiment of the interface request flow dynamic control method provided by the present application is given as follows.

[0045] Referring to Figure 1 The interface request flow dynamic control method provided by the present application includes the following steps.

[0046] Step 101, collecting QPS data of an Internet interface and resource usage monitoring data of a server in real time;

[0047] Step 102, calculating a dynamic flow limiting threshold value according to the resource monitoring data, in combination with a preset resource usage index data and a dynamic flow limiting threshold value calculation formula;

[0048] Step 103, determining a flow pressure index according to the numerical difference between the QPS data and the dynamic flow limiting threshold value;

[0049] Step 104, determining a resource capacity scheduling strategy of the server according to the comparison result of the flow pressure index and a flow pressure index interval.

[0050] It should be noted that the QPS data refers to the number of requests per second, which can be collected in real time by a flow statistics module of an interface gateway, and is used to quantify the request load of the current interface. The resource usage monitoring data refers to the CPU utilization, memory occupancy or number of active threads of the server, which can be obtained by an operating system monitoring tool or a container orchestration platform, and reflects the real-time resource state of the server. The dynamic flow limiting threshold value refers to the upper limit of the request processing capacity dynamically adjusted according to the current resource usage rate, which is mapped to a threshold value by a mathematical formula, so that the threshold value changes adaptively with the resource load. The flow pressure index refers to the ratio or difference between the current QPS and the dynamic flow limiting threshold value, which can be generated by division or subtraction, and is used to determine whether the request flow exceeds the system processing capacity. The resource capacity scheduling strategy refers to the decision of increasing or decreasing the number of server instances, which can trigger the creation or destruction of virtual machine instances through a cloud platform API, so as to realize the elastic scaling of computing resources.

[0051] Specifically, the service end deployment resource monitoring agent continuously collects CPU and memory usage data, and the interface gateway counts the QPS values of each interface. When the resource usage is below the safety threshold, the dynamic throttling threshold calculation formula outputs a higher value, allowing more requests to be processed; when the resource usage approaches the maximum tolerance threshold, the calculation formula outputs a lower value to protect system stability. Compare real-time QPS with dynamic throttling threshold, if QPS exceeds the threshold, generate high flow pressure index. When the index continuously exceeds the upper limit of the preset interval, trigger the automatic expansion process to increase the service end instance; when the index is lower than the lower limit of the interval, trigger the shrinkage process to release idle resources, the execution of the expansion / shrinkage process synchronously changes the resource usage index data of the service end, and then drives the dynamic throttling threshold to continue dynamic adjustment according to the actual index, the whole process forms a closed loop control, so that the throttling threshold and the resource capacity form a dynamic matching.

[0052] The present scheme dynamically associates resource usage rate and throttling threshold, so that the flow control strategy reflects the change of system processing capacity in real time, and simultaneously triggers expansion / shrinkage operation based on flow pressure index, realizing collaborative optimization of throttling and resource scheduling. This two-way linkage mechanism solves the response lag problem and avoids the situation of over-allocation or insufficient allocation of resources.

[0053] Through the above technical scheme, the application can dynamically adjust the interface request processing capacity in a high-concurrency scenario, prevent the service end from crashing due to sudden traffic overload, and automatically reduce the throttling threshold when the resource usage rate rises to protect system stability. At the same time, according to the change of traffic pressure, the size of computing resources is adjusted in time, which optimizes the resource utilization rate on the premise of ensuring service availability. This scheme is especially suitable for Internet services with periodic traffic fluctuations, such as course registration interfaces of online education platforms or transaction peak processing interfaces of financial systems.

[0054] On the basis of the above basic embodiment, the present embodiment further proposes that the resource usage index data includes a request processing reference threshold, a safety resource usage rate threshold, and a maximum tolerance threshold of resource usage rate, wherein the reference threshold is the maximum request processing capacity of the service end in the resource idle state.

[0055] The request processing baseline threshold refers to the maximum number of requests the server can stably handle without additional load. This threshold serves as the basis for dynamic rate limiting adjustments, reflecting the server's basic processing capacity. The security resource utilization threshold is the critical value that triggers resource alerts. Specifically, it can be set at 60%~70% of the server's CPU utilization. When resource usage monitoring data reaches this threshold, the system will activate the alert mechanism. This threshold is used to intervene in advance before resource pressure reaches its limit, preventing sudden traffic surges from exhausting resources. The maximum tolerable resource utilization threshold is the upper limit of resource usage the server can withstand. Specifically, it can be set at 90% of the server's CPU utilization as the forced rate limiting trigger point. This threshold is used to forcibly activate rate limiting policies when resources are close to full load, preventing system crashes.

[0056] Based on this, this embodiment further refines the specific expression of the dynamic current limiting threshold calculation formula, as follows:

[0057]

[0058] In the formula, For dynamic rate limiting thresholds, This is the baseline threshold for request processing, specifically representing the system's performance when resources are idle ( The maximum processing capacity (e.g., 1000 QPS). For resource usage monitoring data, The threshold for safe resource utilization. This is the maximum tolerable threshold for resource utilization. The resource utilization monitoring data refers to the real-time collected server-side resource utilization indicators, which can be represented by data such as CPU utilization, memory usage, or thread pool activity, to avoid single-dimensional bias and to quantify the current system load status. The adjustment factor α is used to balance the intensity of rate limiting. Its value typically ranges from 0.8 to 1.0. A larger α value indicates stricter rate limiting under resource pressure. The specific value can be determined based on the business scenario. For financial payment and medical data systems, α is typically 0.9-1.0. These systems have extremely low tolerance for error rates and response latency, requiring rapid rate limiting under resource pressure to prevent crashes. For systems prioritizing throughput (such as content distribution and log query interfaces), α is typically 0.8-0.9. These systems can tolerate short-term high loads and are more focused on reducing request rejections.

[0059] The formula logic is explained as follows:

[0060] When resource utilization is below the safety threshold ( When QPS_threshold = Base_QPS (no limit);

[0061] When the resource usage is between the safe threshold and the maximum threshold (Res_safe < Res_usage < Res_max), the QPS_threshold decreases linearly with the increase of Res_usage;

[0062] When the resource usage exceeds the maximum threshold (Res_usage > Res_max), the QPS_threshold decreases to Base_QPS x (1-a) (such as 200 QPS), and the system is forced to be protected.

[0063] Specifically, the dynamic throttling threshold calculation formula dynamically adjusts the throttling threshold by associating the request processing reference threshold with the real-time resource usage, in combination with the difference between the safe resource usage threshold and the maximum tolerable resource usage threshold. When the resource usage is close to the safe threshold, the calculation formula automatically reduces the throttling threshold to reduce system pressure; when the resource usage is low, a higher throttling threshold is allowed to improve request processing efficiency. For example, when the resource usage monitoring data reaches the safe threshold, the calculation formula will narrow the dynamic throttling threshold range, thereby triggering the throttling mechanism to avoid resource depletion; when the resource usage falls below the safe threshold, the dynamic throttling threshold expands accordingly, releasing the processing capacity of the server.

[0064] The present scheme dynamically calculates the resource usage monitoring data and the preset threshold, so that the throttling threshold can adapt to changes in system load in real time, avoiding request overload when resources are insufficient, and reducing waste of processing capacity when resources are idle. Through the above technical scheme, the present application can dynamically adjust the throttling strategy according to the actual resource state of the server, reduce the throttling threshold in time when the system load is high to protect the stability of the server, and improve the request processing efficiency when the resources are idle, thereby realizing the coordinated cooperation of the throttling mechanism and the resource expansion strategy, effectively balancing the system stability and resource utilization.

[0065] Further, the present application further proposes to determine the traffic pressure index according to the difference between the QPS data and the dynamic throttling threshold, including: determining the traffic pressure index according to the ratio or difference between the QPS data and the dynamic throttling threshold.

[0066] On this basis, the present embodiment further proposes to determine the resource capacity scheduling strategy of the server according to the comparison result of the traffic pressure index and the traffic pressure index interval, including: triggering the server expansion logic when the traffic pressure index exceeds the range of the traffic pressure index interval and is greater than the upper limit of the traffic pressure index interval; triggering the server contraction logic when the traffic pressure index exceeds the range of the traffic pressure index interval and is less than the lower limit of the traffic pressure index interval.

[0067] ​It should be noted that the traffic pressure index refers to the system load intensity index quantified by the numerical difference between the QPS data and the dynamic traffic limiting threshold, which can be calculated by ratio method or difference method, and is used to reflect the pressure degree caused by the interface request traffic to the server in real time. The traffic pressure index interval refers to the pre-set system resource capacity adjustment trigger range, which can be determined by historical operation data analysis to determine the upper and lower threshold values as the basis for determining whether resource scheduling needs to be performed. The server expansion logic refers to the operation process of increasing computing resources to improve system processing capacity, which can be realized by calling virtual machine instances or container replicas through cloud platform API. The server scaling logic refers to the operation process of reducing idle resources to reduce operating costs, which can be realized by shutting down idle instances or releasing unused resources.

[0068] Taking the ratio calculation method as an example, the calculation formula of the traffic pressure index Pressure can be referred to:

[0069] Pressure = QPS / QPS_threshold, wherein QPS is the QPS data.

[0070] When Pressure>1.2 (i.e., the actual request amount exceeds the dynamic threshold by 20%) and lasts for 30 seconds, expansion is triggered, and the number of new nodes is: new node number = ceil(current node number x (Pressure-1.0) x β) (β is the expansion coefficient, default 1.5, to ensure that the processing capacity after expansion has redundancy), when Pressure<0.5 (i.e., the actual request amount is less than the dynamic threshold by 50%) and lasts for 5 minutes, scaling is triggered, and the number of nodes to be reduced is: reduced node number = floor(current node number x (1.0-Pressure) x γ) (γ is the scaling coefficient, default 0.5, to avoid excessive scaling leading to subsequent pressure being unable to be handled), the expansion coefficient (β) and the scaling coefficient (γ) are used to control the number of nodes to be increased or decreased, to avoid excessive expansion or scaling.

[0071] It can be understood that the core design of β (expansion coefficient, default 1.2-1.8) and γ (scaling coefficient, default 0.3-0.6) mentioned in the above embodiments is "initial preset baseline value, and then dynamically calibrated according to business scenarios, resource costs, and historical feedback" - to avoid poor adaptability caused by completely static constants. The initial preset value is only a "starting reference" (such as β=1.5 and γ=0.5 in a general scenario), which will be adjusted in real time by the "coefficient optimization module" of the linkage control center in actual operation, to ensure that the number of expansion and scaling is accurately matched with the actual demand.

[0072] Specifically, in the e-commerce platform's killing scene, when the QPS data is 8000 requests per second and the dynamic throttling threshold is 6000, the ratio calculation obtains a stress index of 1.33, at which time the system is in an overload state triggering the expansion logic; in the enterprise service periodic report scene, when the QPS data is 200 requests per second and the dynamic throttling threshold is 500, the difference calculation obtains a stress index of -300, at which time the system is in a low load state triggering the shrinkage logic. By supporting both ratio and difference calculation methods, the stress index generation strategy can be selected according to the business scenario: for resource-sensitive financial transaction systems, difference calculation can avoid misjudgment caused by transient traffic fluctuations; for content distribution systems with high tolerance for traffic surges, ratio calculation can identify potential risks earlier.

[0073] The scheme correlates and analyzes the QPS data with the dynamically calculated dynamic throttling threshold, considers the current actual carrying capacity of the system, supports two differentiated stress evaluation dimensions, makes the generation process of the traffic stress index both dynamically adaptive and retains the policy configurability. Through the above technical scheme, the application can accurately quantify the traffic stress degree according to the real-time processing capacity of the system, quickly identify sudden traffic surges through ratio calculation during e-commerce promotions, and accurately judge the resource idle state through difference calculation during the night low peak period, thereby ensuring service stability while effectively avoiding resource waste.

[0074] The scheme correlates and analyzes the QPS data with the dynamically calculated dynamic throttling threshold, considers the current actual carrying capacity of the system, supports two differentiated stress evaluation dimensions, makes the generation process of the traffic stress index both dynamically adaptive and retains the policy configurability. Through the above technical scheme, the application can accurately quantify the traffic stress degree according to the real-time processing capacity of the system, quickly identify sudden traffic surges through ratio calculation during e-commerce promotions, and accurately judge the resource idle state through difference calculation during the night low peak period, thereby ensuring service stability while effectively avoiding resource waste.

[0075] On this basis, the embodiment further proposes that when it is detected that the server expansion logic is triggered, the excess requests are cached in a preset cache queue; and when the server expansion is completed, the excess requests in the cache queue are pushed to the server.

[0076] The cache queue is a data structure for temporarily storing interface requests that exceed the current processing capacity of the server. It can be implemented using an in-memory queue or a distributed message queue. Its role is to avoid request loss due to insufficient server resources during the expansion process. The server expansion logic trigger is an operation that automatically starts the resource expansion process based on the comparison result of the resource usage monitoring data and the preset threshold. It can be implemented by calling the cloud platform elastic computing interface or container orchestration tool. Its role is to ensure that the server resources can dynamically adapt to changes in traffic pressure.

[0077] Specifically, when the server resource usage rate exceeds the safety threshold and the traffic pressure index exceeds the upper limit of the preset interval, the automatic expansion process is triggered. At this time, if the new interface request exceeds the current processing capacity, it will be temporarily stored in the cache queue. The capacity of the cache queue can be set according to the historical traffic peak value, for example, set to twice the average traffic of the last 24 hours. After the expansion is completed, the server resource scale is expanded, and at this time, the requests in the cache queue are pushed to the server for processing according to the first-in first-out principle. To avoid queue backlog leading to request response timeout, the upper limit of the queue storage time can be set, for example, requests exceeding 30 seconds are automatically discarded and an error prompt is returned.

[0078] The present scheme dynamically adjusts the correlation between the cache queue capacity and the expansion response time, realizes the organic linkage of traffic limiting and expansion, and effectively solves the contradiction between request loss and resource idling during server expansion through the above technical scheme. In the e-commerce flash sale scenario, when sudden traffic surge triggers expansion, user requests can be temporarily cached instead of being rejected, and the processing continues after the new computing nodes are ready, avoiding user loss during the activity. At the same time, the capacity and time limit mechanism of the cache queue prevents infinite queue backlog caused by expansion failure, ensuring the overall stability of the system.

[0079] Further, the present application also proposes to classify the internet interfaces according to interface priority, determine the redundancy coefficient corresponding to the internet interface according to the corresponding relationship between the preset interface priority classification and the redundancy coefficient, and determine the request processing reference threshold of the internet interface according to the historical traffic peak value and the redundancy coefficient.

[0080] The interface priority classification refers to classification according to the service importance or service level of the interface, and can be implemented by using a preset service type label or a service level agreement, for example, payment interfaces are classified as high priority, and query interfaces are classified as low priority. The redundancy coefficient is a scale factor used to adjust the request processing reference threshold, and can be implemented by using a numerical mapping table based on the priority level, for example, a high priority interface corresponds to a larger redundancy coefficient, and a low priority interface corresponds to a smaller redundancy coefficient. The historical traffic peak refers to the maximum request amount of the Internet interface in a preset time period, and can be obtained by log analysis or traffic monitoring tools. The request processing reference threshold is the maximum request processing capability of the server in the idle state of resources, and can be calculated according to the product of the historical traffic peak and the redundancy coefficient.

[0081] Specifically, when determining the request processing reference threshold, first, the corresponding redundancy coefficient is matched according to the interface priority classification. For example, if an interface is classified as high priority, its redundancy coefficient can be 1.5; if it is classified as low priority, the redundancy coefficient can be 1.0. Then, the historical traffic peak of the interface is counted, for example, the highest QPS value in the past 30 days is 1000. Finally, the request processing reference threshold is obtained by multiplying the historical traffic peak and the redundancy coefficient. For example, the reference threshold of the high priority interface is 1000x1.5=1500, and the reference threshold of the low priority interface is 1000x1.0=1000. Thus, the interfaces of different priorities can dynamically adjust the reference threshold based on the historical traffic, avoiding the problem of unreasonable resource allocation caused by fixed threshold.

[0082] The present scheme dynamically calculates the reference threshold by introducing priority classification and redundancy coefficient in combination with historical traffic data, so that the resource allocation is more in line with the actual business needs. Through the above technical scheme, the present application can dynamically adjust the request processing reference threshold according to the business importance of the interface, ensure that the high priority interface obtains sufficient redundant resource support at the traffic peak, and at the same time avoid that the low priority interface occupies too much redundant resource in the low load scenario. In addition, the reference threshold is calculated in combination with the historical traffic peak, which can reduce the misjudgment caused by sudden traffic, and make the triggering of the flow limiting and expansion strategy more accurate and reasonable.

[0083] The above is a detailed description of an interface request traffic dynamic control method embodiment provided by the present application, and the following is a detailed description of related embodiments such as an interface request traffic dynamic control device, a terminal, and a storage medium provided by the present application.

[0084] Please refer to Figure 2 The embodiment provides an interface request traffic dynamic control device, which comprises:

[0085] The data acquisition unit 201 is configured to acquire QPS data of an Internet interface and resource usage monitoring data of a server in real time.

[0086] The dynamic throttling threshold calculation unit 202 is configured to calculate a dynamic throttling threshold according to the resource monitoring data, in combination with preset resource usage index data and a dynamic throttling threshold calculation formula.

[0087] The flow pressure index calculation unit 203 is configured to determine a flow pressure index according to a numerical difference between the QPS data and the dynamic throttling threshold.

[0088] The resource capacity scheduling strategy determination unit 204 is configured to determine a resource capacity scheduling strategy of the server according to a comparison result of the flow pressure index and a flow pressure index interval.

[0089] Specifically, the data acquisition unit continuously collects interface QPS and server resource usage, the dynamic throttling threshold calculation unit adjusts the current maximum request processing capacity allowed in real time according to the proportion relationship between the resource usage and the preset safe resource usage threshold and the maximum tolerance threshold of the resource usage, through the dynamic throttling threshold calculation formula. The flow pressure index calculation unit calculates the ratio of the current QPS and the dynamic throttling threshold to generate a quantitative index reflecting the system load state. The resource capacity scheduling strategy determination unit compares the flow pressure index with the preset interval, if it exceeds the upper limit, the expansion logic is triggered, if it is lower than the lower limit, the contraction logic is triggered. When the expansion logic is triggered, the excess requests can be temporarily stored in the cache queue, and then redistributed to the server for processing after the resource expansion is completed.

[0090] The scheme dynamically calculates the throttling threshold and comprehensively considers the flow pressure index and the resource usage state, to realize the collaborative control of the throttling mechanism and the expansion strategy. For example, when the resource usage rate approaches the safe threshold, the dynamic throttling threshold calculation unit automatically reduces the request processing upper limit, and at the same time, the flow pressure index calculation unit feeds back the load change in real time, so that the resource scheduling strategy can predict the capacity demand in advance, and avoid the response lag caused by independent decision.

[0091] Through the above technical scheme, the application can dynamically balance the request processing capability and the resource utilization rate in a high concurrency scenario. For example, in the e-commerce platform's flash sale activity, when the rapid increase in traffic leads to a rapid increase in resource usage, the dynamic throttling threshold calculation unit timely reduces the amount of requests allowed to be processed, to prevent the server from being overloaded; at the same time, the flow pressure index calculation unit identifies the continuous high pressure state, triggers the resource capacity scheduling strategy determination unit to start the expansion process, and cooperates with the cache queue to temporarily store the excess requests, to ensure that the system can still maintain basic service capability during the expansion period. The collaborative mechanism effectively solves the problems of resource waste and service interruption caused by independent operation of throttling and expansion in the traditional scheme.

[0092] Further, asFigure 3 As shown, the interface request flow dynamic control terminal proposed in this embodiment comprises a memory 33 and a processor 31, the memory 33 and the processor 31 can be connected through a communication bus 34; the memory 33 is used for storing program code, the program code corresponds to the interface request flow dynamic control method; the processor 31 is used for reading and executing the program code to realize the interface request flow dynamic control method.

[0093] Among them, the memory 33 refers to the hardware device for storing program code, which can be realized by solid state disk or memory chip, and its function is to provide executable instruction set for the processor. The processor 31 refers to the operation unit for executing program code, which can be realized by multi-core CPU or distributed computing chip, and its function is to dynamically adjust the interface flow control strategy by analyzing the logical steps in the program code.

[0094] Specifically, the terminal defines the flow control logic through the program code stored in the memory, such as the steps of collecting QPS data in real time, calculating dynamic flow limiting threshold, determining flow pressure index and resource scheduling strategy, etc. When the processor executes the program code, first, the real-time monitoring data is obtained from the server and the interface layer, then the threshold value is generated according to the preset resource usage index and dynamic flow limiting formula, the pressure index is calculated by comparing the current QPS with the threshold value, and finally the expansion or contraction operation is triggered according to the interval where the pressure index is located. In this process, the algorithm logic defined in the program code can ensure that the flow limiting threshold is dynamically adjusted with the resource usage rate, and the resource scheduling strategy is matched with the flow pressure state in real time.

[0095] In some specific embodiments, the program code can be packaged as a micro-service module running independently and deployed in a cloud server cluster. For example, the memory can use a distributed file system to store the configuration parameters of different interfaces, and the processor can execute the flow control tasks of multiple interfaces in parallel through containerization technology. In addition, the program code can contain an exception handling mechanism, for example, when the resource expansion fails, the degradation strategy is automatically enabled.

[0096] Further, the computer readable storage medium proposed in this embodiment has program code saved therein, and the program code is used for being read and executed by the processor to realize the interface request flow dynamic control method.

[0097] The computer-readable storage medium refers to a physical carrier capable of persistently storing program code, and can be implemented by a solid state disk, a mechanical hard disk or a distributed storage system. The computer-readable storage medium ensures persistent storage and fast reading of the program code. The program code refers to a computer program including executable instructions, and can be written in Java, Python or C++ language. The program code guides the processor to execute each step of the traffic dynamic control method, including real-time collection of QPS data, calculation of a dynamic throttling threshold, determination of a traffic pressure index and a resource scheduling strategy.

[0098] Specifically, when the program code is executed by the processor, first, the QPS data of the Internet interface and the server resource usage monitoring data are collected in real time. Then, according to the resource usage index data and the dynamic throttling threshold calculation formula, the current maximum request processing capacity allowed is dynamically adjusted. Then, by comparing the difference between the QPS data and the dynamic throttling threshold, a traffic pressure index reflecting the current load state of the system is generated. Finally, according to the pressure interval in which the index is located, the corresponding resource expansion or contraction operation is triggered. In this process, the program code temporarily stores excess requests through a preset cache queue, and then processes the requests in the queue after the resource adjustment is completed, so as to avoid request loss.

[0099] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the terminal, the device and the unit described above can refer to the corresponding process in the foregoing method embodiments, which will not be described here.

[0100] In the several embodiments provided in the present application, it should be understood that the disclosed terminal, device and method can be implemented by other means. For example, the device embodiments described above are only schematic, for example, the division of the units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units or components shown or discussed can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0101] The terms "first", "second", "third", "fourth", and the like in the description of the application and in the claims of the foregoing application, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the use of the terms so termed herein is solely for descriptive purposes and not for pronouncing the limitations of the application described herein. For example, a generic component shown as having a "first" and a "second" part can include one "part" in some embodiments, or two or more "parts" in other embodiments. Similarly, if an embodiment includes "first", "second", and "third" steps, the application to include only "first" and "second" steps, or to include only "first" and "third" steps, or to include only "second" and "third" steps is contemplated. The terms "first", "second", "third", "fourth", and the like in the description of the application and in the claims of the foregoing application, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the use of the terms so termed herein is solely for descriptive purposes and not for pronouncing the limitations of the application described herein. For example, a generic component shown as having a "first" and a "second" part can include one "part" in some embodiments, or two or more "parts" in other embodiments. Similarly, if an embodiment includes "first", "second", and "third" steps, the application to include only "first" and "second" steps, or to include only "first" and "third" steps, or to include only "second" and "third" steps is contemplated. Moreover, the terms "comprise", "comprising", "include", "including", and "contains", "containing" as well as their conjugates, are intended to cover a process, a method, a system, a product, or an apparatus that comprises, includes, or contains the listed elements but not excluding elements not listed. In other words, when the application is described as comprising or including a list of elements, the application is not necessarily limited to the listed elements, but can also include additional elements not expressly listed or inherent to such process, method, system, product, or apparatus.

[0102] It should be understood that, in the application, "at least one" means one or more, and "multiple" means two or more. "And / or" is used to describe the relationship between associated objects, which means that there can be three relationships, for example, "A and / or B" can mean that there are only A, only B, and A and B at the same time. A, B can be singular or plural. The character " / " generally represents that the associated objects before and after are in an "or" relationship. "At least one of the following" or similar expressions means any combination of these items, including any combination of single or multiple items. For example, at least one of a, b or c can mean a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

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

[0104] In addition, the functional units in each embodiment of the application can be integrated into one processing unit, or each unit can exist physically, or two or more units can be integrated into one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0105] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or say the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0106] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacements for some technical features; and these modifications or replacements do not make the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for dynamic control of interface request traffic, characterized in that, include: Real-time collection of QPS data from internet interfaces and resource usage monitoring data from the server; Based on the resource monitoring data, combined with the preset resource usage index data and the dynamic flow limiting threshold calculation formula, the dynamic flow limiting threshold is calculated. The flow pressure index is determined based on the difference between the QPS data and the dynamic flow limiting threshold. Based on the comparison results between the traffic pressure index and the traffic pressure indicator range, the resource capacity scheduling strategy of the server is determined.

2. The method for dynamic control of interface request traffic according to claim 1, characterized in that, The resource usage metrics data include: a request processing baseline threshold, a security resource utilization rate threshold, and a maximum tolerable resource utilization rate threshold, wherein the baseline threshold is the maximum request processing capacity of the server when resources are idle.

3. The method for dynamic control of interface request traffic according to claim 2, characterized in that, The specific formula for calculating the dynamic current limiting threshold is as follows: In the formula, The dynamic current limiting threshold is... The baseline threshold for request processing, For the resource usage monitoring data, The threshold for the utilization rate of the security resources. This is the maximum tolerable threshold for resource utilization. This is an adjustment factor used to balance the current limiting intensity.

4. A method for dynamic control of interface request traffic according to claim 2 or 3, characterized in that, Also includes: Based on the interface priority classification of the Internet interface, and combined with the preset correspondence between interface priority classification and redundancy coefficient, the redundancy coefficient corresponding to the Internet interface is determined. The historical peak traffic of the Internet interface is statistically analyzed, and the request processing baseline threshold of the Internet interface is determined based on the historical peak traffic and the redundancy coefficient.

5. The method for dynamic control of interface request traffic according to claim 1, characterized in that, Based on the difference between the QPS data and the dynamic flow limiting threshold, the flow pressure index is determined as follows: The flow pressure index is determined based on the ratio or difference between the QPS data and the dynamic flow limiting threshold.

6. The method for dynamic control of interface request traffic according to claim 1, characterized in that, Based on the comparison between the traffic pressure index and the traffic pressure indicator range, the resource capacity scheduling strategy for the server is determined as follows: When the traffic pressure index exceeds the range of the traffic pressure indicator range and is greater than the upper limit of the traffic pressure indicator range, the server expansion logic is triggered. When the traffic pressure index exceeds the range of the traffic pressure indicator range but is less than the lower limit of the traffic pressure indicator range, the server-side scaling down logic is triggered.

7. The method for dynamic control of interface request traffic according to claim 6, characterized in that, After determining the resource capacity scheduling strategy of the server, the following is also included: When the server-side scaling logic is detected to be triggered, excess requests are cached through a pre-defined cache queue. Once the server capacity is expanded, excess requests in the cache queue will be pushed to the server.

8. A device for dynamic control of interface request traffic, characterized in that, include: The data acquisition unit is used to collect QPS data from the Internet interface and resource usage monitoring data from the server in real time. The dynamic rate limiting threshold calculation unit is used to calculate the dynamic rate limiting threshold based on the resource monitoring data, combined with preset resource usage index data and the dynamic rate limiting threshold calculation formula. The flow pressure index calculation unit is used to determine the flow pressure index based on the numerical difference between the QPS data and the dynamic flow limiting threshold. The resource capacity scheduling strategy determination unit is used to determine the resource capacity scheduling strategy of the server based on the comparison result between the traffic pressure index and the traffic pressure index range.

9. A terminal for dynamically controlling interface request traffic, characterized in that, include: Memory and processor; The memory is used to store program code, which corresponds to the interface request traffic dynamic control method as described in any one of claims 1 to 7; The processor is used to read and execute the program code to implement the interface request traffic dynamic control method.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains program code that is read and executed by a processor to implement the interface request traffic dynamic control method as described in any one of claims 1 to 7.

Images