Flow control method and device and readable storage medium

Abstract

The invention discloses a flow control method and device and a readable storage medium, and the method comprises the steps: stopping receiving a first request sent by a sending device in a mode of receiving the request at a rate smaller than or equal to a first threshold value under the condition that the rate of the first request sent by the first sending device is greater than the first threshold value; after stopping receiving the first request sent by the sending device in the first mode, starting to receive a second request sent by a second sending device in a mode of receiving the request at a rate less than or equal to a second threshold value; and when the rate of the second request sent by the sending device is less than the second threshold value, recovering to receive the third request sent by the sending device in the first mode. In the above process, normal operation of partial service traffic can be ensured by intermittently releasing the load source, and whether the first request is recovered to the normal traffic can be determined in time, so that interception of the sending device sending the first request is canceled in time, and the service performance of the system is ensured.

Description

Technical Field

[0001] The present application relates to the field of flow control, and in particular to a flow control method, device and readable storage medium. Background Art

[0002] Currently, the method in which the application programming interface (API) gateway performs traffic control from the resource dimension through traffic control algorithms such as counter algorithm and token bucket algorithm consumes a large amount of computing resources to obtain information such as user identity, which is then used to determine whether the traffic has reached a preset threshold. In addition, when the traffic sent by multiple user devices continues to trigger the traffic control algorithm, the API gateway's processor may be overloaded, resulting in performance degradation of the API interface, increased response time, and even server downtime of the API gateway.

[0003] In order to solve the problem of API gateway's own performance degradation caused by continuous traffic triggering traffic control, the inlet traffic can be controlled from an overall dimension by monitoring indicators such as the average response time (RT), number of concurrent threads and query rate per second (QPS) of the inlet traffic. In the above process, the control operation requires manual intervention, which takes a long time to control the traffic. In addition, there is a certain lag in the control operation, and the overload source cannot be blocked in time. In addition, since it is impossible to distinguish between normal business traffic and abnormal traffic that affects processor performance, normal business traffic is also subject to traffic control, which affects the normal operation of the system business. Summary of the invention

[0004] The present application discloses a flow control method, device and readable storage medium. After intercepting a request sent by an overload source, by intermittently receiving the request sent by the overload source, it is possible to promptly determine whether the request sent by the overload source has been restored to normal flow, and when the request has been restored to normal flow, the interception of the request sent by the overload source is promptly canceled, and by intermittently receiving the request sent by the overload source, some normal business requests can be forwarded to the back-end server to ensure the normal operation of the system business.

[0005] In a first aspect, an embodiment of the present application provides a flow control method, the method comprising: when the rate of first requests sent by a first sending device is greater than a first threshold, stop receiving the first request sent by the sending device at a rate less than or equal to the first threshold; after stopping receiving the first request sent by the sending device in the first manner, start receiving the second request sent by the second sending device at a rate less than or equal to a second threshold, wherein the second sending device may be one or more first sending devices; when the rate of the second request sent by the sending device is less than the second threshold, resume receiving the third request sent by the sending device in the first manner.

[0006] To summarize, the present application can determine whether the traffic of the request sent by the first sending device has returned to normal by intermittently receiving the second request and determining the rate of the second request. When it is determined that the traffic of the request sent by the first sending device has returned to normal, the reception of the request sent by the first sending device can be restored in time to avoid intercepting normal business requests, thereby improving the normal operation efficiency of the system business.

[0007] Exemplarily, the method further includes: when a rate of second requests sent by the second sending device is equal to a second threshold, stopping receiving the first request sent by the first sending device in the first manner.

[0008] In the above process, the second request can be well controlled by the existing traffic control strategy, and normal business traffic will not frequently trigger traffic control operations. Receiving only the second request can ensure the normal operation of the system business to a certain extent. When the rate of requests sent by the first sending device is not lower than the second threshold, it may still lead to frequent execution of traffic control operations. Therefore, continuing to intercept the requests sent by the first sending device can better ensure the performance of the API gateway.

[0009] Exemplarily, the first request includes a first access identifier, which is used to indicate a first sending device that sends the first request, and the first access identifier includes one or more of a source Internet Protocol (IP) address, a user identification document (ID), and a resource type. Among them, the source IP address is used to indicate the address of the device that sends the first request in the network, the user ID is used to indicate a specific user who uses the system or service that sends the first request, and the resource type is used to indicate the category of the object that is accessed, operated, or processed corresponding to the first request. The second request also includes the first access identifier, which is used to indicate a second sending device that sends the second request, and the second sending device is one or more of the first sending devices.

[0010] When the first access identifier is the first source IP address, the first request and the second request are both sent by the device corresponding to the first source IP address. When the first access identifier is the first user identifier, the first request and the second request are both sent by the user corresponding to the first user identifier. When the first access identifier is the first resource type, the first request and the second request are requests for the same resource type and can be sent by different sending devices.

[0011] The overload source can be determined through the first access identifier included in the first request, so that when the rate of the first request triggers the first threshold, the overload source can be quickly determined and the first request sent by the overload source can be intercepted. Compared with the current method of overall control of inlet traffic from the system dimension, overload traffic and normal business traffic can be distinguished to ensure the normal operation of system services. Intercepting the overload source can avoid frequent requests triggering the flow control operation of the flow control unit, reduce the performance loss caused by the API gateway's flow control and logical calculations such as identity authentication, and reduce the load pressure of the API gateway.

[0012] Exemplarily, before stopping receiving the first request sent by the sending device in the first manner, the method further includes: marking the first sending device that sends the first request as an overload source according to a first access identifier included in the first request.

[0013] In the above process, after the rate of the first request reaches the second threshold, the existing traffic control strategy cannot control the traffic well, and will more frequently trigger the traffic control of algorithms such as the counter algorithm and the token bucket algorithm, rejecting more first requests. At this time, the first sending device that sends the first request is marked as a suspected overload source. After that, the rate of the first request is continuously monitored. When the rate of the first request reaches the first threshold, it can be quickly determined that the first sending device that sends the first request is an overload source, so as to intercept the first request for the overload source to reduce the system load, thereby avoiding continuous triggering of the API gateway's traffic control operations, reducing the API gateway's frequent traffic counting, verifying the identity of the user sending the request, and other operations caused by computing resource consumption, ensuring the performance of the API gateway, and ensuring that requests sent by other non-overload sources are processed normally, which can improve system performance.

[0014] In a second aspect, an embodiment of the present application provides a flow control device, which includes a system protection unit. The system protection unit is used to stop receiving the first request sent by the first sending device in a first manner when the rate of the first request sent by the first sending device is greater than a first threshold, wherein the first manner is to receive the request at a rate less than or equal to the first threshold; and is also used to start receiving the second request sent by the second sending device in a second manner after stopping receiving the first request sent by the first sending device in the first manner, wherein the second manner is to receive the request at a rate less than or equal to the second threshold; and is also used to resume receiving the third request sent by the first sending device in the first manner when the rate of the second request sent by the second sending device is less than the second threshold.

[0015] Exemplarily, the system protection unit is further configured to: when a rate of second requests sent by the second sending device is equal to a second threshold, stop receiving the first request sent by the first sending device in the first manner.

[0016] Exemplarily, the first request includes a first access identifier, which is used to indicate a first sending device that sends the first request, and includes one or more of a source Internet Protocol IP address, a user identifier ID, and a resource type.

[0017] Exemplarily, the second request includes a first access identifier, where the first access identifier is used to indicate a second sending device that sends the second request, and the second sending device is one or more of the first sending devices.

[0018] Exemplarily, before stopping receiving the first request sent by the sending device in the first manner, the system protection unit is further configured to: mark the first sending device sending the first request as an overload source according to the first access identifier included in the first request.

[0019] In a third aspect, an embodiment of the present application provides a computing device cluster, which includes at least one computing device, and the computing device includes a processor and a memory. The processor is used to execute instructions stored in the memory so that the computing device executes the flow control method described in the first aspect.

[0020] In a fourth aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when executed by a computing device, enables the computing device to implement the flow control method described in the first aspect.

[0021] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, comprising computer program instructions, which, when executed by a computing device, enable the computing device to implement the flow control method described in the first aspect.

[0022] Based on the implementations provided in the above aspects, this application can also be further combined to provide more implementations. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for describing the embodiments.

[0024] Figure 1 is a schematic diagram of a counter algorithm provided in an embodiment of the present application;

[0025] Figure 2 It is a structural schematic diagram of a flow control system provided by an embodiment of the present application;

[0026] Figure 3 is a schematic diagram of the structure of another flow control system provided in an embodiment of the present application;

[0027] Figure 4 is a flow chart of a flow control method provided by an embodiment of the present application;

[0028] Figure 5 is a schematic diagram of a traffic model provided in an embodiment of the present application;

[0029] Figure 6 is a schematic diagram of a change in processor usage provided by an embodiment of the present application;

[0030] Figure 7 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0031] Figure 8 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0032] Fig. 9 It is a structural diagram of one or more computing devices connected via a network provided by an embodiment of the present application. DETAILED DESCRIPTION

[0033] The following will describe the technical solutions in the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0034] Currently, the following three methods are usually used to control traffic from the resource dimension, or to control the application inlet traffic from the overall dimension. Among them, the inlet traffic is the amount of request data sent by the sender or other system to the API gateway, and is the traffic entering the backend application through the API gateway. For example,

[0035] The first is the counter algorithm: Figure 1 As shown, Figure 1 It is a schematic diagram of a counter algorithm provided in an embodiment of the present application. The counter algorithm sets a counter (counter) to accumulate the number of requests received within a specified time interval (time window / time interval). When the request reaches the maximum number threshold, flow control is performed. As shown in the figure, when the cumulative number of requests reaches 100 times within 1 minute, flow control is performed, and requests exceeding 100 are not processed. Afterwards, within the next time threshold, the counter is reset, the number of processed requests is cleared, and the count is restarted. In a possible implementation, the time interval specified by the counter algorithm and the maximum number threshold of requests can also be set to other possible values, which are not specifically limited in this application.

[0036] Moreover, the counter algorithm has critical problems, such as Figure 1 As shown in the figure, 100 requests were sent instantly at 0:59, and 100 requests were sent instantly at 1:00, so the user sent 200 requests in this 1 second. Since the maximum number threshold previously determined is 100 requests per minute, the user can instantly exceed the maximum number threshold by making a burst request at the reset node of the time window.

[0037] In the above process, resetting and updating the counter will bring certain computing overhead, and when a large number of requests suddenly exceed the processing capacity of the processor, a large number of requests will be rejected, which will in turn trigger more retry requests, increasing the processing burden of the gateway.

[0038] The second is the token bucket algorithm: the token bucket algorithm determines the number of tokens by generating a fixed number of tokens and a fixed rate of token issuance. When a request arrives, a token is taken from the token bucket and processed after it is obtained. If the token is not obtained, an exponential backoff waiting strategy is used to gradually increase the waiting time at a certain time interval and retry, thereby achieving flow control.

[0039] For example, if the maximum capacity of the token bucket is determined to be 20 tokens, and the token issuance rate is determined to be 5 / second, and requests are sent at a rate of 10 / second, there are requests that cannot obtain tokens. In the case where a request cannot obtain a token, it does not try again immediately, but waits for a shorter time (for example, 1 second) to obtain the token again. If the token is still not obtained this time, the waiting time for the next token acquisition operation will increase exponentially (for example, 2 seconds, 4 seconds, 8 seconds, etc.).

[0040] The above process can avoid the problem of network congestion or further increase of system burden caused by frequent retries when the system is busy or fails, increase the possibility of success, and reduce excessive consumption of system resources. However, continuous generation of tokens and management of the status of token buckets require computing resources, and the exponential backoff wait when there is no token and the subsequent processing after obtaining the token require additional computing and processing logic.

[0041] The above two algorithms are methods for flow control from the resource dimension. In the scenario of large concurrency and multiple overload sources, when the flow control is performed by the counter algorithm, the counter update and judgment operations increase dramatically; when the flow control is performed by the token bucket algorithm, the operations of checking the status of the token bucket, generating new tokens, and allocating tokens to requests are also more frequent. When there are multiple overload sources, the tokens may be exhausted quickly, resulting in a large number of requests waiting for tokens. It is necessary to continuously process the request to obtain tokens and the management of the waiting queue, which increases the computational complexity. In addition, during the execution of the above two algorithms, the authentication calculation also requires authentication and permission checks for each request, resulting in excessive consumption of the CPU and memory resources of the API gateway, further increasing the computational burden, thereby affecting its performance, and even causing response delays, processing errors, or service interruptions, resulting in reduced reliability of the API gateway.

[0042] The third is a system-level flow control method: In the embodiment of the present application, the Sentinel system adaptive protection module is used as an example to illustrate. The Sentinel system adaptive protection module monitors multiple dimensions of indicators such as application load, overall average response time (RT), query per second (QPS) and number of threads. When a certain indicator reaches the corresponding preset threshold, the system protection is triggered to control the application entrance flow, for example, reduce the allowed QPS or temporarily reject some new requests. Among them, the application load is the use of resources including the processor (central processing unit, CPU) utilization rate, memory utilization rate, etc., which is used to indicate the current pressure on the system; the overall average RT is the average time spent processing each request, which is used to indicate the processing efficiency of the system; the entrance QPS is the number of requests entering the system per second, which is used to determine the size of the flow; the number of threads is the number of threads processing requests, which is used to indicate the concurrent processing capacity of the system; the entrance flow is the flow of external first entry into the application to obtain information or trigger operations, for example, the request sent by the user to the website server, the first call request initiated by the user to the Dubbo server, etc.

[0043] The above method continuously adjusts the flow control strategy by monitoring multiple indicators to achieve a balance between the system's inlet flow and load, ensuring that the system does not receive too many requests, so that components such as the CPU work within their processing capabilities, and that the API gateway performance is not overloaded due to receiving a large number of requests instantly. However, since the above flow control method only considers the overall state of the system, it lacks certain flexibility and cannot accurately distinguish between normal and abnormal flows, resulting in some key normal business flows being mistakenly intercepted because the overall indicators reach the threshold.

[0044] Furthermore, the above-mentioned traffic control methods lack effective means for locating the overload source, and have no mechanism for blocking the overload source. Manual step-by-step investigation and setting are required to implement traffic blocking at the network layer or system layer, which is inefficient. At the same time, there is no mechanism for automatically unblocking the overload source, so that after the overload problem has been solved, the processor or other resources, services, etc. are still in a restricted state, resulting in the system being only partially available, affecting the overall performance and service quality of the system.

[0045] To solve the above problems, an embodiment of the present application provides a flow control method. When the rate of a first request sent by a first sending device reaches a first threshold, the first request sent by the first sending device is stopped from being received in a first manner. Then, in the next time interval, a second request sent by a second sending device at a rate less than or equal to the second threshold is received in a second manner. Since the second sending device is one or more of the first sending devices, when the rate of the second request is less than the second threshold, it is determined that the flow corresponding to all requests sent by the first sending device has returned to normal. The first request can be better controlled by a flow control algorithm such as a counter algorithm or a token bucket algorithm, and the reception of the request sent by the first sending device in the first manner is restored. In the above flow control method, the interception of the request sent by the sending device is more flexible. By receiving the second request, the operation of some normal business requests can be guaranteed. By continuously determining the request rate, it can be determined in time whether the request has returned to normal flow. When the request has returned to normal flow, the interception of the request sent by the sending device is canceled in time, and the flow control strategy is adjusted to ensure the overall performance and service quality of the system. The above flow control method is applied to Figure 2 In the flow control system shown.

[0046] like Figure 2 As shown, Figure 22 is a schematic diagram of a flow control system provided by an embodiment of the present application, the system includes a service system 210, a flow control system 220 and a transmitter 230, wherein there is a communication connection between the service system 210, the flow control system 220 and the transmitter 230, which may be a wired connection or a wireless connection, which is not specifically limited in the present application. Among them, the number of service systems 210 and transmitters 230 that establish communication connections with the flow control system 220 may be one or more, which is not specifically limited in the present application.

[0047] Optionally, the service system 210 can be deployed on a computing device, usually on different computing devices, wherein the computing device includes a bare metal server (BMS), a virtual machine, a container or an edge computing device. Among them, BMS refers to a general physical server, such as an ARM server or an X86 server; a virtual machine refers to a complete computer system with complete hardware system functions implemented by network function virtualization (NFV) technology and simulated by software, running in a completely isolated environment; a container refers to a group of processes that are resource-constrained and isolated from each other; an edge computing device refers to a device that is closer to the data source and end user and has low latency and high bandwidth characteristics, such as intelligent routing, edge servers, etc. The service system 210 can also be deployed in a computing device cluster, which may include multiple of the above computing devices.

[0048] Optionally, the service system 210 is used to receive requests sent by the traffic control system, and perform relevant data processing and calculations according to the content and requirements of the requests, and return the processing results or response information to the traffic control system. The service system can also monitor and record the processing process of the requests in order to perform performance optimization and other operations.

[0049] Optionally, the traffic control system 220 is an API gateway, or an API gateway cluster, which can be deployed on different computing devices, or on the same computing device, which also includes a bare metal server, a virtual machine, a container, or an edge computing device.

[0050] Optionally, the traffic control system 220 performs traffic control and load balancing to provide a single entry point for the sender to access the service system and accurately route the request to the computing devices in the corresponding service system so that they can communicate with each other; to perform traffic control by limiting the frequency and concurrency of the sender's access to the service system; to perform identity authentication, authorization, and access control operations; and to promptly interrupt requests when the service system fails or responds too slowly to ensure system availability.

[0051] When the service system 210 and the traffic control system 220 are deployed on different computing devices, the service system 210 and the traffic control system 220 can be deployed on different computing devices in the same computing device cluster, or deployed on different computing devices in different computing clusters. The specific decision can be made according to the actual application scenario, and this application does not make any specific limitation.

[0052] Optionally, the sending end 230 and the flow control system 220 can be deployed on different computing devices, or the sending end 230 is deployed on a terminal device and the flow control system 220 is deployed on a computing device. When the sending end 230 and the flow control system 220 are deployed on different computing devices, the sending end 230 and the flow control system 220 can be deployed on different computing devices in the same computing device cluster, or on different computing devices in different computing clusters, which can be determined according to the actual application scenario and is not specifically limited in this application.

[0053] Optionally, the sending end 230 can be deployed on a terminal device or a computing device, wherein the terminal device includes a personal computer, a smart phone, a handheld processing device, a tablet computer, a mobile notebook, etc., which is not specifically limited here. The computing device can be a BMS, a virtual machine, a container, or an edge computing device. The specific description can be referred to the above content, which is not repeated here.

[0054] It should be understood that the above Figure 2 The flow control system shown is only a possible example provided by the embodiment of the present application. The system may also include more devices, which is not specifically limited in the present application.

[0055] Furthermore, the flow control system 220 can be further divided into a plurality of unit modules, for example, Figure 2 As shown, the flow control system 220 may include a flow control unit 221 and a system protection unit 222. It should be understood that Figure 2 This is an exemplary division method. The flow control system 220 may also include more or fewer units. The above units may be merged or split, and this application does not make any specific limitation on this.

[0056] The flow control unit 221 may be a flow control software development kit (SDK), which is usually provided in the form of software and includes a series of interfaces, functions, class libraries, documents, etc., to help developers easily integrate the flow control function in their applications. The system protection unit 222 may also be implemented by software. In addition, the flow control unit 221 and the system protection unit 222 may also be implemented by hardware.

[0057] For example, the implementation of the system protection unit 222 is described below by taking the system protection unit 222 as an example. Similarly, the implementation of the flow control unit 221 can refer to the implementation of the system protection unit 222.

[0058] The system protection unit 222 is taken as an example of a software functional unit, and the system protection unit 222 may include code running on a computing instance. Among them, the computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the above-mentioned computing instance may be one or more. For example, the system protection unit 222 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple data centers with close geographical locations. Among them, usually a region may include multiple AZs.

[0059] The system protection unit 222 is taken as an example of a hardware functional unit, and the system protection unit 222 may include at least one computing device, such as a server, etc. Alternatively, the system protection unit 222 may also be a device implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), etc. The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0060] The functions of each unit module in the flow control system 220 are described below.

[0061] The flow control unit 221 is used to determine the requested rate and perform flow control operations according to the requested rate.

[0062] Specifically, the flow control unit first receives multiple requests sent by the sender. When the rate of receiving requests is very small and the flow control unit performs flow control through a counter algorithm, the request does not trigger the flow control unit to stop processing requests that exceed the maximum number threshold within a fixed time interval, or, when the rate of receiving requests is very small and the flow control unit performs flow control through a token bucket algorithm, the request does not trigger an exponential backoff waiting operation, and the flow control unit forwards the received requests to multiple computing devices in the service system. As the rate of received requests increases, the flow control unit begins to perform flow control operations through a counter algorithm, a token bucket algorithm, or other possible flow control algorithms, such as limiting the processing and forwarding rate of requests, temporarily delaying the processing of some requests, and sorting the priorities of requests, etc., which are not specifically limited in this application. In the above process, the flow control unit intercepts some business requests and forwards normal business requests to computing devices in the service system.

[0063] In a specific implementation, when the initial request rate is 200 / s, the request does not reach the maximum number threshold (300) of requests within the time interval (1 second). At this time, the request will not trigger the flow control unit to perform flow control operations. Later, during the traffic increase period, when the request rate increases by more than 300 / s, the request triggers the flow control unit to perform flow control operations, and one or more requests exceeding 300 per second are not processed.

[0064] Afterwards, the rate of requests received by the traffic control unit reaches a second threshold and continues to increase until the rate of requests reaches the first threshold. At this time, the traffic of requests reaches a higher level, and the requests will more frequently trigger the traffic control unit to perform traffic control operations through a counter algorithm, a token bucket algorithm, or other possible traffic control algorithms, which will further reduce the processing and forwarding rate of requests, temporarily delay the processing of a larger number of requests, and adopt a stricter priority sorting for request forwarding. This application does not make any specific limitations on this.

[0065] In a specific implementation, when the request rate increases from 300 / s to 1600 / s, the flow control unit can perform better flow control on the requests through a counter algorithm, a token bucket algorithm, or other possible flow control algorithms. However, when the request rate exceeds 1600 / s and continues to increase, the requests will frequently trigger the flow control unit to perform flow control operations.

[0066] The traffic control unit can intercept some business requests to avoid excessive pressure on the service system and ensure the normal operation of the requests.

[0067] The system protection unit 222 is used to monitor the rate of requests, and when the rate of first requests sent by the first sending device is greater than a first threshold, stop receiving the first requests sent by the first sending device in a first manner, wherein the first manner is to receive requests at a rate less than or equal to the first threshold, and determine the first overload source based on the first access identifier included in the first request.

[0068] When the rate of requests is lower than the second threshold, the system protection unit does not perform operations related to flow control, but monitors the rate of requests received by the flow control unit. When the rate of requests increases to the second threshold, it determines that the requested flow has reached a higher level, and begins to frequently trigger the flow control unit to perform flow control operations, preliminarily determining the suspected overload source. When the rate of requests increases from the second threshold to the first threshold, the requested flow is at a very high level, causing a significant impact on the flow control system and service system, resulting in an increase in the response delay corresponding to the request, rapid consumption of processor resources, and reduced service quality. If the rate of requests continues to maintain the first threshold and a rate greater than the first threshold, the flow control system will stop responding and crash. Therefore, when the system protection unit monitors the rate of requests and determines that the rate of requests increases to the first threshold, it identifies and blocks the overload source.

[0069] In the above process, the suspected overload source and the overload source are determined according to the access identifier included in the request, and the access identifier includes one or more of the source Internet Protocol (IP) address, the user identification document (ID) and the resource type, wherein the source IP address is used to indicate the address of the device that issues the request in the network, for example, the source IP address assigned when the computer or mobile phone is connected to the network is 192.168.1.100; the user ID is used to indicate a specific user using the system or service, for example, "user1"; the resource type is used to indicate the category of the object being accessed, operated or processed, for example, documents (doc, pdf), pictures (jpg, png), videos (mp4, avi), etc. In a possible implementation, the access identifier can also include more types and quantities of data, which is not specifically limited in this application, and the source IP address is used as an example in the embodiment of the present application. For example, when the rate of the first request including the first source IP address reaches the first threshold, the first sending device that sends the first request is determined according to the first source IP address included in the first request, and the first request sent by the first sending device is stopped.

[0070] In a possible implementation, when the request rate exceeds the second threshold and directly increases to the first threshold, the overload source is directly determined according to the access identifier of the request, and the overload source is used to indicate which requests to stop receiving in the subsequent interception process.

[0071] In the above process, the system protection unit pre-determines the suspected overload source according to the access identifier included in the request, and can quickly determine the overload source. Then, the request for the overload source is intercepted, and the requests sent by the overload source can be distinguished from the normal requests sent by other devices. Compared with the current method of controlling the inlet traffic from the system dimension, the operation of normal requests can be guaranteed. Intercepting the overload source can avoid frequent triggering of the traffic control operation of the traffic control unit by requests, and can reduce the performance loss caused by the API gateway's traffic control and logical calculations such as identity authentication, and can reduce the load pressure of the API gateway.

[0072] The system protection unit 222 is also used to start receiving the second request sent by the second sending device in a second manner after stopping receiving the first request sent by the first sending device in the first manner, wherein the second manner is to receive the request at a rate less than or equal to a second threshold, and when the rate of the second request sent by the second sending device is less than the second threshold, resume receiving the third request sent by the first sending device in the first manner.

[0073] When the blocking time of the overload source reaches the first time threshold, the system protection unit may receive a request sent by the overload source in the next time interval, the request having a rate less than or equal to a second threshold.

[0074] In one possible implementation, when all requests sent by an overload source are received and the request rate is lower than a second threshold, it is determined that the requests sent by the overload source are reduced to a normal level and no longer put pressure on the performance of the flow control unit and the performance of the back-end service system. At this time, the interception of the requests sent by the overload source is canceled, so that the flow control unit receives and processes the requests in the second manner to perform flow control.

[0075] In another possible implementation, when receiving partial requests sent by an overload source, or receiving all requests sent by an overload source and the request rate is equal to a second threshold, after the end of this time interval, the system protection unit still stops receiving the first request sent by the first sending device in the first manner.

[0076] The system protection unit can dynamically adjust the flow control of the overload source by blocking the overload source and intermittently releasing it. By intermittently receiving some requests, it can promptly determine whether the flow of the requests sent by the overload source has returned to the normal level, and ensure that the overload source is blocked in time when the flow returns to the normal level, so as to avoid intercepting normal requests and causing the system function to continue to be affected.

[0077] To summarize, an embodiment of the present application provides a flow control system which, through a flow control unit and a system protection unit, supports identification and blocking of overload sources on the basis of basic flow control, and performs flow control more flexibly, thereby distinguishing overload flow that causes system overload from normal flow that can be better controlled by a token bucket algorithm or a counter algorithm, thereby ensuring that some requests can be processed normally and improving the system's operating performance.

[0078] In a possible implementation, the traffic control system 220 can also be deployed as an intrusive plug-in in the microservice system. After receiving the inlet traffic, according to the rate of the inlet traffic, the system protection unit 222 is used to intercept the overload traffic, and the traffic control unit 221 is used to intercept the normal traffic and send the normal business traffic to the application system for processing, directly providing the application system with the ability of traffic control and overload protection, as shown in the following example. Figure 3 As shown, Figure 3 It is a structural schematic diagram of another flow control system provided in an embodiment of the present application.

[0079] Combination of the above Figure 2 , Figure 3 The application scenarios and flow control system of the technical solution provided by this application are introduced. Next, Figure 4 A flow control method provided by an embodiment of the application is introduced in detail.

[0080] like Figure 4 As shown, Figure 4 is a flow chart of a flow control method provided in an embodiment of the present application. The method is applied to Figure 2 In the traffic control system in the system shown, the embodiment of the present application is explained by taking the application to API gateway as an example, and the method includes the following steps.

[0081] S410: When a rate of first requests sent by the first sending device is greater than a first threshold, stop receiving first requests sent by the first sending device in a first manner.

[0082] The first method is to receive requests at a rate less than or equal to the first threshold.

[0083] In a possible implementation, before the rate of the first request sent by the first sending device reaches the first threshold, the API gateway receives multiple requests sent by multiple sending devices included in the sending end, including the first request sent by the first sending device, and the API gateway receives the first request in a first manner, and continuously monitors the rate of the first request. When the rate of the first request is low, the API gateway will not be triggered to perform a flow control operation. The flow control operation is that the API gateway temporarily delays the processing of the request according to a flow control algorithm such as a token bucket algorithm and a counter algorithm, and limits the processing forwarding rate of the request, etc., wherein the flow control algorithm also includes a sliding window algorithm, a leaky bucket algorithm, etc., which is not specifically limited in this application. However, as the rate of the first request increases, the first request will trigger the API gateway to perform a flow control operation through a flow control algorithm such as a token bucket algorithm and a counter algorithm, for example, limiting the processing forwarding rate of the request, temporarily delaying the processing of some requests, and sorting the priority of the request, etc., which is not specifically limited in this application, thereby intercepting some business requests and sending some normal first requests to the backend service system for processing.

[0084] In a specific implementation, when the API gateway performs flow control through a counter algorithm, it is determined that the maximum number of requests that can be processed within one second in the counter algorithm is 200. When the rate of the first request is 100 / second, the API gateway does not perform flow control operations and sends the 100 requests received within one second to the backend service system. In the next second, when the rate of the first request increases from 100 / s to 300 / second, the API gateway sends the 200 requests received within one second to the backend service system and stops processing the 100 first requests that exceed 200 within this time period.

[0085] In a possible implementation, when a first request sent by a receiving sending end triggers a flow control operation, the rate of the first request is continuously monitored, and when it is determined that the rate of the first request reaches the second threshold first, the first sending device that sends the first request is marked as a suspected overload source according to the first access identifier included in the first request, wherein the second threshold is used to indicate the request rate threshold that frequently triggers the flow control operation of the flow control system, and the access identifier can be a source IP address, a user identifier, or a resource type, and the source IP address is used to indicate the address of the device that sends the request in the network; the user ID is used to indicate a specific user using the system or service, for example, "user1"; the resource type is used to indicate the category of the object being accessed, operated or processed, for example, documents (doc, pdf), pictures (jpg, png), videos (mp4, avi), etc. In a possible implementation, the access identifier can also include more types and quantities of data, which are not specifically limited in this application.

[0086] When it is determined that the rate of the first request has reached the second threshold, the suspected overload source is preliminarily determined based on the first access identifier included in the first request, and then the rate of the first request continues to be monitored. When the rate of the first request gradually increases but does not reach the first threshold, the first request will begin to frequently trigger flow control operations, causing the API gateway processor to need to perform larger flow control calculations and identity authentication and other operations, which will face greater pressure, but will not trigger an overload. Therefore, by determining the suspected overload source based on the first access identifier included in the first request, the overload source can be quickly determined in the subsequent process, and the first request sent by the overload source can be intercepted in time, so that the requests sent by the overload source can be distinguished from the normal requests sent by other devices to ensure system operation performance.

[0087] In a possible implementation, when the rate of the first request varies between the second threshold and the first threshold, the API gateway continuously monitors the rate of the first request corresponding to the suspected overload source and frequently performs flow control on the first request.

[0088] In a possible implementation, when the rate of the first request decreases from a rate above the second threshold to a rate below the second threshold, the API gateway cancels the identification of the suspected overload source, and only continuously monitors the rate of the first request, and performs better flow control on the first request through a counter algorithm or a token bucket algorithm.

[0089] When the rate of first requests sent by the first sending device is greater than a first threshold, stop receiving the first requests sent by the first sending device in a first manner.

[0090] When the rate of the first request increases to a value greater than the first threshold, the API gateway needs to perform more frequent flow control calculations to determine whether the request is within the allowed flow range, and whether it is necessary to limit the flow of the request or stop processing it. At the same time, it is also necessary to perform authentication calculations to verify whether the source of each request is legal, whether the user has the corresponding authority, etc. The above calculations require a large amount of computing resources. If they exceed the processing capacity of the API gateway, the API gateway processor will be overloaded, affecting the normal operation and service quality of the system. Stopping the reception of the first request sent by the first sending device in the first manner can intercept the first request in a timely manner and reduce the system load, thereby avoiding the situation where the first request continues to frequently trigger flow control, reducing the computing resource consumption caused by the API gateway's frequent flow counting and verification of the identity of the user sending the request, and ensuring the performance of the API gateway.

[0091] When the API gateway also receives requests from other sending devices with a rate lower than the first threshold, the API gateway only blocks the overload source corresponding to the first request, and still performs normal flow control operations on other requests with rates lower than the first threshold, and sends the requests to the backend service system, thereby reducing the impact of overload source blocking on normal traffic and ensuring system business performance.

[0092] In one possible implementation, when the rate of the first request increases to a first threshold, the first sending device that sends the first request is marked as an overload source based on the first access identifier included in the first request, for subsequent blocking operations of the API gateway to ensure that only the first request is stopped from being received, thereby reducing the impact of the overload source blocking on normal traffic and ensuring system business performance.

[0093] When the time for stopping receiving the first request sent by the first sending device in the first manner reaches a first time threshold, step S420 is executed.

[0094] S420: Start receiving a second request sent by a second sending device in a second manner.

[0095] The second method is to receive requests at a rate less than or equal to the second threshold.

[0096] The second request also includes the first access identifier included in the first request, and is a request sent by a part or all of the first sending device that sent the first request.

[0097] Specifically, when the time for stopping receiving the first request sent by the first sending device in the first manner reaches a first time threshold, the overload source is released, and within a second time threshold, the second request sent by the second sending device is received in the second manner.

[0098] Compared with the current flow control method, the above process can receive and process some requests by intermittently releasing the load source, thereby ensuring the normal operation of some requests and improving system performance.

[0099] S430: Determine whether the rate of second requests sent by the second sending device is less than a second threshold.

[0100] Within the second time threshold, the API gateway receives the second request and continuously monitors the rate of the second request to determine whether the rate of the second request sent by the second sending device is less than the second threshold. The maximum rate of the second request that the API gateway can receive is the second threshold.

[0101] Within the second time threshold, when the rate of the second request is equal to the second threshold, the processor of the API gateway is still under great pressure and is at risk of overload, and still stops receiving the first request sent by the first sending device in the first manner and returns to execute step S410.

[0102] In the above process, the second request with a receiving rate of the second threshold can ensure that some business requests are processed normally and ensure the business performance of the system. However, since the risk of API gateway overload cannot be eliminated, the overload source continues to be blocked in the next time interval after the second time threshold, and the reception of the first request is stopped. This can reduce the number of frequent triggering of flow control operations caused by the first request when the traffic is still high, and reduce the computing resources consumed by the API gateway to perform flow control operations.

[0103] Within the second time threshold, when the rate of the second request is less than the second threshold, it is determined that the overload risk of the API gateway disappears, the blocking of the overload source is released, and the reception of the third request sent by the first sending device in the first manner is restored, and step S440 is executed.

[0104] S440: Receive a third request sent by the first sending device in the first manner.

[0105] When the rate of the second request is less than the second threshold, the API gateway resumes receiving the third request sent by the first sending device in the first manner.

[0106] Compared with the current traffic control method, the above process can timely determine whether the rate of the first request is reduced to the second threshold and whether the traffic has returned to the normal level by intermittently releasing the load source. When it is determined that the traffic of the first request has returned to normal, the first request can be promptly restored to avoid intercepting normal business requests, thereby improving the normal operation efficiency of the system business.

[0107] In a specific implementation, a single API gateway is configured with eight processor cores and sixteen gigabytes (GB) of memory; the single-core single-IP second-level automatic tracing threshold is configured to be 400 / s, that is, for each processor core, when the number of requests from a single source IP address reaches 400 times per second, an operation of determining a suspected overload source based on the source IP address is executed; the single-core single-IP second-level automatic interception threshold is configured to be 1600 / s, that is, after determining the suspected overload source, when the number of requests from a single source IP address reaches 1600 times per second, an operation of blocking the overload source is executed. In addition, the first time threshold for blocking the overload source is configured to be 1 second, and the second time threshold for intermittently releasing the overload source is also configured to be 1 second.

[0108] Since the above embodiment of the present application provides a flow control method for the API gateway, the API gateway determines the rate of different requests according to the inlet flow, thereby intercepting the overload flow and some normal flow, therefore, it is necessary to determine the second threshold and the first threshold corresponding to the API gateway according to the maximum rate threshold that does not trigger the flow control operation of the API gateway, the relevant data corresponding to each of the above processor cores, and the proportional relationship between the hypertext transfer protocol (HTTP) and the secure hypertext transfer protocol (HTTPS). Among them, the proportional relationship between HTTP and HTTPS is the ratio between the number of requests transmitted through the HTTP protocol and the number of requests transmitted through the HTTPS protocol within a certain time interval in a specific network environment or application scenario, which is used to indicate the reasonable planning of API gateway resources. For example, when the proportion of requests transmitted by the HTTPS protocol is relatively large, more computing resources are required to process encryption and decryption operations.

[0109] In an embodiment of the present application, the maximum rate threshold for not triggering the API gateway flow control operation is 300 / s, the single-core single-IP second-level automatic tracing threshold is 400 / s, the single-core single-IP second-level automatic interception threshold is 1600 / s, and the ratio of HTTP and HTTPS is 1:2. The second threshold of the API gateway is determined to be 1900 / s. Specifically, 1900 / s is the maximum rate threshold for not triggering the API gateway flow control operation (300 / s), the single-core single-IP second-level automatic tracing threshold (400 / s), the ratio of HTTP and HTTPS, and the number of processor cores included in the API gateway. The first threshold of the API gateway is determined to be 6700 / s. 6700 / s is the maximum rate threshold for not triggering the API gateway flow control operation (300 / s), the single-core single-IP second-level automatic interception threshold (1600 / s), the ratio of HTTP and HTTPS, and the number of processor cores included in the API gateway.

[0110] The above method for determining the first threshold and the second threshold is only one possible implementation method. The first threshold and the second threshold can be determined based on the maximum rate threshold that does not trigger the API gateway traffic control operation, the single-core single-IP second-level automatic tracing threshold, the single-core single-IP second-level automatic interception threshold, and the proportional relationship between HTTP and HTTPS. In a possible implementation, the first threshold and the second threshold can also be determined based on more or fewer types of data, which is not specifically limited in this application.

[0111] The following takes the first threshold value as 6700 / s and the second threshold value as 1900 / s as an example to illustrate the complete process of the flow control method.

[0112] like Figure 5 As shown, Figure 5 It is a schematic diagram of a traffic model provided in an embodiment of the present application.

[0113] The rate of first requests received by the API gateway in the first second is 300 / s. At this time, the first request does not trigger the API gateway to perform flow control operations, which is normal business traffic. In the second second, the rate of first requests received by the API gateway rises to 500 / s, triggering the normal flow control of the API gateway. The API gateway stops processing the 200 first requests that exceed 300 / s. In the third second, the rate of first requests received by the API gateway rises to 1400 / s. The API gateway performs flow control operations on the 1100 first requests that exceed 300 / s. Within four seconds, the rate of the first request increased to 1900 / s, reaching the second threshold, triggering an important alarm for the overload source. The API gateway determined the first suspected overload source based on the first source IP address included in the first request. Afterwards, within the fifth and sixth seconds, the rate of the first request increased to 3300 / s and 6300 / s, respectively. The first request frequently triggered the API gateway to perform flow control operations. Within the seventh second, the rate of the first request increased to 6700 / s, reaching the first threshold, triggering an emergency alarm for the overload source. The API gateway determined the first suspected overload source as the first overload source and initiated a traffic control operation on the first overload source. The API gateway performs a blocking operation and performs overload tracing flow control within the eighth second. It stops receiving the first request with a rate of 7000 / s. After that, it receives the first request sent by the first overload source within 1900 / s within the ninth second. Since the rate of all first requests sent by the first overload source still exceeds the first threshold, the API gateway still blocks the first overload source within the tenth second and stops receiving the first request. Until the thirteenth second, the API gateway receives all first requests sent by the first overload source, but the rate of the first request still reaches the second threshold. At this time, the first overload source is regarded as the first suspected overload source and Do not immediately unblock the first overload source. Within the fourteenth second, continue to block the first overload source and stop receiving the first request sent by the first overload source. Within the fifteenth second, the API gateway receives all first requests sent by the first overload source, and the rate of the first requests (1400 / s) is less than the second threshold. It is determined that the rate of the first requests has returned to normal, and the blockage of the first overload source is unblocked. Receiving the first requests is resumed. The rate of the received first requests continues to be determined every second thereafter. Repeat the above process to determine whether the rate of the first requests reaches the second threshold and the first threshold.

[0114] As the request rate changes, when the API gateway operates according to a flow control method provided in the above-mentioned embodiment of the present application, the utilization rate of the processor of the API gateway will change differently according to different flow control operations. For example, when the rate of received requests is very low, the API gateway does not need to perform flow control operations. At this time, the utilization rate of the processor is low. When the rate of received requests increases, the API gateway starts to perform flow control operations, and as the request rate increases, the frequency of flow control operations gradually increases. At this time, the processor of the API gateway performs flow control counting and verification operations, and the utilization rate of the processor gradually increases. The rate of change varies with the request rate. When the request rate increases to the first threshold, the API gateway is triggered to perform an overload source blocking operation. At this time, the load pressure of the API gateway can be reduced, and the number of flow control counting and verification operations performed by the processor is reduced, which can significantly reduce the utilization rate of the processor. The above-mentioned specific change process is shown in the figure below.

[0115] like Figure 6 As shown, Figure 6 This is a schematic diagram of a processor usage change provided in an embodiment of the present application. In the schematic diagram of the processor usage change, the horizontal axis is time and the vertical axis is CPU usage.

[0116] Specifically, when the API gateway is configured reasonably, the API gateway receives the first request. During the time period from 20:00:00 to 20:16:24, when the rate of the first request gradually increases from a lower value, the first request changes from a situation where it never triggers the flow control operation of the API gateway to a situation where it frequently triggers the flow control operation of the API gateway, causing the CPU usage rate to increase rapidly from a lower stable value. When the rate of the first request reaches the first threshold, an overload source emergency alarm is triggered, and the API gateway blocks the overload source corresponding to the first request and stops receiving the first request. At 20:36:04, when the API gateway blocks the overload source, the CPU usage rate drops significantly. When the rate of the first request drops from the first threshold to below the second threshold, the API gateway eliminates the blockage of the overload source and resumes receiving the first request.

[0117] In summary, the flow control method provided by the embodiment of the present application can timely determine whether the request sent by the overload source has been restored to normal flow by intermittently receiving the request sent by the overload source after intercepting the request sent by the overload source, and when the request has been restored to normal flow, timely cancel the interception of the request sent by the overload source, adjust the flow control strategy, prevent the accidental interception of normal flow, improve the system operation efficiency, and intermittently receive the request sent by the overload source, so that some normal business requests can be forwarded to the back-end service system to ensure the normal operation of some businesses. Moreover, compared with the current method of frequently triggering flow control operations, this method intercepts the overload source, which can reduce the computing resource consumption caused by the API gateway frequently counting traffic, verifying the identity of the user sending the request, and other operations, thereby ensuring the performance of the API gateway.

[0118] like Figure 7 As shown, Figure 7 is a schematic diagram of a computing device provided in an embodiment of the present application, the computing device is used to deploy Figure 2 The flow control system shown in the figure is realized Figure 4 The computing device 700 includes at least a bus 710, a processor 720, a memory 730, and a communication interface 740. The processor 720, the memory 730, and the communication interface 740 communicate with each other via the bus 710. It should be understood that the present application does not limit the number of processors and memories in the computing device 700.

[0119] The bus 710 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 The bus 710 is represented by only one line, but it does not mean that there is only one bus or one type of bus. The bus 710 may include a path for transmitting information between various components of the computing device 700 (eg, the processor 720, the memory 730, and the communication interface 770).

[0120] The processor 720 may include any one or more processors such as a central processing unit (CPU), a microprocessor (MP) or a digital signal processor (DSP), etc., for executing program codes.

[0121] The memory 730 may include a volatile memory, such as a random access memory (RAM). The memory 730 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD) or a solid state drive (SSD). The memory may also include a combination of the above types. The memory 730 stores executable program code, and the memory stores executable program code corresponding to one or more units of the flow control unit 221 and the system protection unit 222. The processor 720 executes the executable program code to respectively implement the functions of the aforementioned flow control unit 221 and the system protection unit 222, thereby realizing Figure 2 The flow control method shown, that is, the memory 730 stores instructions for executing the flow control method. In addition, the memory 730 may also store more types and quantities of data, such as a generated road network topology map, a road network flow map, etc., which is not specifically limited in this application.

[0122] The communication interface 740 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 700 and other devices or a communication network.

[0123] Need to explain, Figure 7 This is only one possible implementation of the embodiment of the present application. In actual applications, the computing device may also include more or fewer components, and the present application does not make any specific limitations on this.

[0124] like Figure 8 As shown, Figure 8 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application, the computing device cluster includes at least one computing device, the computing device may be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device may also be a terminal device such as a desktop computer, a laptop computer, or a smart phone. The memory 730 in one or more computing devices 700 in the computing device cluster may store the same instructions for executing the flow control method provided in the present application.

[0125] In some possible implementations, the memory 730 of one or more computing devices 700 in the computing device cluster may also store partial instructions for executing the flow control method. In other words, the combination of one or more computing devices 700 may jointly execute instructions for executing the flow control method.

[0126] It should be noted that the memory 730 in different computing devices 700 in the computing device cluster can store different instructions, which are respectively used to execute partial functions of multiple units. That is, the instructions stored in the memory 730 in different computing devices 700 can implement the functions of one or more units in the traffic control unit 221 and the system protection unit 222.

[0127] In some possible implementations, one or more computing devices in the computing device cluster may be connected via a network, which may be a wide area network or a local area network. Fig. 9 It is a structural diagram of one or more computing devices connected via a network provided by an embodiment of the present application.

[0128] like Fig. 9 As shown, computing device 700A includes bus 710A, processor 720A, memory 730A and communication interface 740A, and computing device 700B includes bus 710B, processor 720B, memory 730B and communication interface 740B. The two computing devices 700A and 700B are connected via a network. Specifically, the network is connected via the communication interface in each computing device. In this type of possible implementation, the memory 730A in computing device 700A stores instructions for executing the functions of flow control unit 221. At the same time, the memory 730B in computing device 700B stores instructions for executing the functions of system protection unit 222. Computing device 700A and computing device 700B can implement the flow control method provided in the present application through data interaction.

[0129] The embodiment of the present application further provides a computer-readable storage medium, in which instructions are stored. When the instructions are executed on a processor, Figure 4 The flow control method flow shown is realized.

[0130] The embodiment of the present application further provides a computer program product. When the computer program product is run on a processor, Figure 4 The flow control method flow shown is realized.

[0131] When the computer program instructions are loaded or executed on the computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.

[0132] Computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. Computer-readable storage media may be any available medium that a computer can access or a data storage node such as a server, data center, etc. that includes at least one set of available media. Available media may be magnetic media (e.g., floppy disks, hard disks, tapes), optical media (e.g., high-density digital video discs (DVDs), or semiconductor media).

[0133] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present application.

Claims

1. A flow control method, characterized in that: The method comprises: When the rate of the first request sent by the first sending device is greater than a first threshold, stop receiving the first request sent by the first sending device in a first manner, wherein the first manner is receiving requests at a rate less than or equal to the first threshold; After stopping receiving the first request sent by the first sending device in the first manner, starting to receive the second request sent by the second sending device in a second manner, wherein the second manner is receiving requests at a rate less than or equal to a second threshold; When the rate of second requests sent by the second sending device is less than a second threshold, the receiving of third requests sent by the first sending device in the first manner is resumed.

2. The method according to claim 1, characterized in that: The method further comprises: When the rate of second requests sent by the second sending device is equal to the second threshold, stop receiving first requests sent by the first sending device in the first manner.

3. The method according to claim 1 or 2, characterized in that: The first request includes a first access identifier, which is used to indicate the first sending device that sends the first request, including one or more of a source Internet Protocol IP address, a user identifier ID, and a resource type.

4. The method according to claim 3, characterized in that The second request includes the first access identifier, where the first access identifier is used to indicate the second sending device that sends the second request, and the second sending device is one or more of the first sending devices.

5. The method according to claim 3 or 4, characterized in that: Before stopping receiving the first request sent by the sending device in the first manner, the method further includes: According to the first access identifier included in the first request, the first sending device that sends the first request is marked as an overload source.

6. A flow control device, characterized in that: The device comprises: a system protection unit, configured to stop receiving the first request sent by the first sending device in a first manner when the rate of the first request sent by the first sending device is greater than a first threshold, wherein the first manner is receiving the request at a rate less than or equal to the first threshold; The system protection unit is further configured to start receiving a second request sent by a second sending device in a second manner after stopping receiving the first request sent by the first sending device in the first manner, wherein the second manner is receiving requests at a rate less than or equal to the second threshold; The system protection unit is further configured to resume receiving the third request sent by the first sending device in the first manner when the rate of the second request sent by the second sending device is less than a second threshold.

7. The device according to claim 6, characterized in that The system protection unit is also used for: When the rate of second requests sent by the second sending device is equal to the second threshold, stop receiving first requests sent by the first sending device in the first manner.

8. The device according to claim 6 or 7, characterized in that The first request includes a first access identifier, which is used to indicate the first sending device that sends the first request, including one or more of a source Internet Protocol IP address, a user identifier ID, and a resource type.

9. The device according to claim 8, characterized in that The second request includes the first access identifier, where the first access identifier is used to indicate the second sending device that sends the second request, and the second sending device is one or more of the first sending devices.

10. The device according to claim 8 or 9, characterized in that Before stopping receiving the first request sent by the sending device in the first manner, the system protection unit is further used to: According to the first access identifier included in the first request, the first sending device that sends the first request is marked as an overload source.

11. A computing device cluster, characterized in that: The method comprises at least one computing device, wherein the computing device comprises a processor and a memory, wherein the processor is configured to execute instructions stored in the memory, so that the computing device executes the method according to any one of claims 1 to 5.

12. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device, the computing device is enabled to implement the method according to any one of claims 1 to 5.

13. A computer-readable storage medium, characterized in that: The method comprises computer program instructions, and when the computer program instructions are executed by a computing device, the computing device is caused to implement the method according to any one of claims 1 to 5.

Images