Request flow limiting method and device, electronic equipment and storage medium

Abstract

The invention provides a request flow limiting method, and relates to the technical field of application interface flow limiting and the like. The method comprises the steps that a calling request sent by a calling party is received, and the calling request comprises a first identifier of the calling party and a second identifier corresponding to a target application programming interface API; obtaining a first token from a first token bucket associated with the first identifier and the second identifier; under the condition that the first token is acquired, acquiring a second token from a second token bucket associated with the second identifier; under the condition that the second token is acquired, acquiring a third token from a third token bucket associated with an application system to which the target API belongs; and under the condition that the third token is obtained, allowing the calling party to call the target API. Different interfaces, calling parties and application systems are subjected to differential current limiting, the precision and reliability of request current limiting are improved, and system resources can be reasonably utilized.

Description

Technical Field

[0001] The present application relates to technical fields such as application interface current limiting, and in particular to a request current limiting method, device, electronic device and storage medium. Background Art

[0002] Interface current limiting is designed to limit the number of requests within a certain time window to avoid performance impact or service interruption due to excessive load, so as to maintain the availability and stability of the application system. It can also prevent slow system operation or downtime caused by traffic surge, and ensure that the service can smoothly handle a large number of requests. It is an important technical means to improve system performance, stability, and optimize the user experience. Summary of the invention

[0003] The present application aims to solve one of the technical problems in the related art at least to some extent.

[0004] To this end, the first purpose of this application is to propose a request current limiting method to achieve multiple current limiting in multiple dimensions of interface, caller and application, which is more reliable and helps to make more rational use of system resources.

[0005] The second objective of the present application is to provide a request current limiting device.

[0006] The third objective of the present application is to provide an electronic device.

[0007] A fourth objective of the present application is to provide a computer-readable storage medium.

[0008] A fifth object of the present application is to provide a computer program product.

[0009] To achieve the above-mentioned purpose, the first embodiment of the present application proposes a request current limiting method, including:

[0010] Receiving a call request sent by a caller, wherein the call request includes a first identifier of the caller and a second identifier corresponding to a target application programming interface API;

[0011] Obtain a first token from a first token bucket associated with the first identifier and the second identifier;

[0012] When the first token is obtained, obtaining a second token from a second token bucket associated with the second identifier;

[0013] When the second token is obtained, obtaining a third token from a third token bucket associated with the application system to which the target API belongs;

[0014] In case the third token is obtained, the caller is allowed to call the target API.

[0015] To achieve the above-mentioned purpose, the second embodiment of the present application proposes a request current limiting device, including:

[0016] A receiving module, configured to receive a call request sent by a caller, wherein the call request includes a first identifier of the caller and a second identifier corresponding to a target application programming interface API;

[0017] A first acquisition module, configured to acquire a first token from a first token bucket associated with the first identifier and the second identifier;

[0018] A second acquisition module, configured to acquire a second token from a second token bucket associated with the second identifier when the first token is acquired;

[0019] A third acquisition module, configured to acquire a third token from a third token bucket associated with the application system to which the target API belongs, when the second token is acquired;

[0020] A processing module is used to allow the caller to call the target API when the third token is obtained.

[0021] To achieve the above-mentioned purpose, the third aspect of the present application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0022] The memory stores computer-executable instructions;

[0023] The processor executes the computer-executable instructions stored in the memory to implement the request current limiting method as described in the first aspect embodiment.

[0024] To achieve the above-mentioned purpose, the fourth aspect embodiment of the present application proposes a computer-readable storage medium, in which computer execution instructions are stored. When the computer execution instructions are executed by a processor, they are used to implement the request current limiting method as in the first aspect embodiment.

[0025] To achieve the above-mentioned purpose, the fifth aspect of the present application proposes a computer program product, including a computer program, which, when executed by a processor, implements the request current limiting method as described in the first aspect.

[0026] The request current limiting method, device, electronic device and storage medium provided in the present application gradually obtain tokens from the token buckets associated with the caller, interface and application system, thereby realizing current limiting judgment of the call request in different dimensions, and only allowing the API to be called when a token is obtained in each token bucket, thereby completing the flow control of the interface call request, improving the accuracy and reliability of the request current limiting, and being more conducive to the rational use of system resources.

[0027] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0029] Figure 1 A flowchart of a request current limiting method provided in an embodiment of the present application;

[0030] Figure 2 A flowchart of another request current limiting method provided in an embodiment of the present application;

[0031] Figure 3 A schematic diagram of a flow chart of requesting current limiting provided in an embodiment of the present application; and

[0032] Figure 4 A schematic diagram of the structure of a request current limiting device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0033] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0034] The request current limiting method and device according to the embodiments of the present application are described below with reference to the accompanying drawings.

[0035] Figure 1 A flowchart of a request current limiting method provided in an embodiment of the present application.

[0036] In the existing technical solutions, the current limiting is performed indiscriminately for a certain interface or an Internet Protocol (IP) address, that is, for different interfaces or IPs, the number of requests allowed per unit time is usually the same. Such solutions have a single dimension of current limiting and low precision. In addition, when the caller sending the request is a cluster service, since the IP of each node in the cluster is different, it is impossible to achieve unified current limiting for the cluster.

[0037] To address this problem, an embodiment of the present application provides a request current limiting method to achieve differentiated current limiting for different interfaces, callers, and application systems. The current limiting dimension is higher, the accuracy and reliability of request current limiting are improved, and it is more conducive to the rational use of system resources.

[0038] like Figure 1 As shown, the request current limiting method includes the following steps:

[0039] Step 101: Receive a call request sent by a caller.

[0040] The caller is the entity that initiates the interface call, which can be a program, system or service.

[0041] It should be noted that when the caller is a cluster service, the calling IP of each node in the cluster service is different. Since the current limiting method of this application does not limit the current for a single IP, but limits the current from the caller dimension, this application can support the application scenario of unified current limiting of cluster service requests.

[0042] The call request includes a first identifier of the caller and a second identifier corresponding to the target application programming interface (API). The first identifier of each caller is unique and can be the identity document ID of the caller. The target API is the API interface requested by the caller, and the second identifier can be the name or number of the target API.

[0043] In the embodiment of the present application, different callers can request to call the API interface opened by the application system to obtain the required data or services according to their own business needs.

[0044] In the embodiment of the present application, the first identifier and the second identifier are included in the message of the call request. In order to ensure the security of the request, the caller can encrypt and sign the message when sending the call request. Then, after the request current limiting system receives the call request, the message interception processor can be used to process the received original message and decrypt the message, thereby completing the authentication of the call request and improving the security of the request.

[0045] Step 102: Obtain a first token from a first token bucket associated with the first identifier and the second identifier.

[0046] The first token bucket is used to limit the rate of call requests sent by a specific caller (i.e., the caller corresponding to the first identifier) ​​to a specific API interface (i.e., the interface corresponding to the second identifier). Multiple first tokens can be stored in the first token bucket, and the first token plays the role of a license. One first token can represent a caller that is allowed to call the API once.

[0047] It should be noted that in this application, multiple first token buckets can be set in advance in the request current limiting system, each first token bucket is associated with a caller and an API interface, at least one of the callers and API interfaces associated with different first token buckets is different, and the maximum number of tokens and / or token generation speed corresponding to different first token buckets may also be different. Therefore, the rate at which different callers call different APIs can be differentially controlled by simulating multiple fixed-capacity buckets and regularly adding tokens to the buckets.

[0048] In an embodiment of the present application, the first token bucket associated with the first identifier and the second identifier in the request current limiting system can be first determined, and then, if there is still an available first token in the first token bucket, it means that the rate at which the current target caller calls the target API has not reached the maximum rate limit set by the system, and the target API can continue to be called, so the first token can be obtained from the first token bucket at this time.

[0049] In the embodiment of the present application, the code can be written in the computer programming language Java, the redis-Cell module is introduced, and the token bucket algorithm is used to implement current limiting.

[0050] Step 103: When the first token is obtained, obtain a second token from a second token bucket associated with the second identifier.

[0051] Among them, the second token bucket is used to limit the rate at which a specific API interface (i.e., the interface corresponding to the second identifier) ​​is called by all callers. A plurality of second tokens can be stored in the second token bucket, and one second token can represent that the API is allowed to be called once.

[0052] In the embodiment of the present application, multiple second token buckets can be set in advance in the request current limiting system, and each second token bucket is associated with an API interface identifier. Because there may be many callers calling the same API interface in a unit time, and the number of requests that the API interface can load is limited, so when determining that the caller with the first identifier is allowed to call the target API, it is also necessary to determine whether the rate at which the current target API is called by all callers exceeds the threshold.

[0053] Therefore, after obtaining the first token, you can first determine the second token bucket associated with the second identifier in the request current limiting system, and then, if there are still available second tokens in the second token bucket, it means that the rate at which the current target API is called has not reached the maximum rate limit set by the system, and the target API can continue to be called, so the second token can be obtained from the second token bucket at this time.

[0054] Step 104: When the second token is obtained, a third token is obtained from a third token bucket associated with the application system to which the target API belongs.

[0055] It should be noted that when determining whether the current caller can call the target API, the request volume of the application system to which the target API belongs per unit time is also required. Since an application system may contain multiple APIs, when each API is frequently called, the burden on the application system may be large, which is easy to affect service performance. Therefore, in the embodiment of the present application, it is also necessary to perform overall traffic restrictions on the application system dimension.

[0056] The third token bucket is used to control the rate at which all APIs of a certain application system are called. A plurality of third tokens can be stored in the third token bucket, and one third token can represent a permission to call an API in the application system once.

[0057] In the embodiment of the present application, when request current limiting is performed on a single application system, only one third token bucket needs to be set, and in a system adopting a microservice architecture, a third token bucket can be set for each type of microservice. Therefore, after obtaining the second token, the third token bucket associated with the application system to which the target API belongs in the request current limiting system can be determined first, and then if there are still available third tokens in the third token bucket, it means that the rate at which all APIs in the current application system are called has not reached the maximum limit rate set by the system, and the target API can continue to be called, so the third token can be obtained from the third token bucket at this time.

[0058] Step 105: When the third token is obtained, the caller is allowed to call the target API.

[0059] In an embodiment of the present application, after obtaining the third token, it can be determined that when current limiting is performed in each dimension of the caller, interface, and application, the current caller calling the target API will not cause problems such as too frequent calls and excessive server burden. Therefore, the caller can be allowed to call the target API, thereby completing the judgment process of whether the request needs to be limited.

[0060] It should be noted that in an embodiment of the present application, a configuration center can be introduced to dynamically configure the token buckets associated with each caller, interface, and application system, thereby realizing dynamic configuration of the current limiting strategy in the three dimensions of caller, interface, and application system, so that the current limiting strategy can be updated without downtime or interruption of service.

[0061] In this embodiment, a call request sent by a caller is first received, and a first token is obtained from a first token bucket associated with the first identifier and the second identifier according to the first identifier and the second identifier contained in the call request. Then, when the first token is obtained, a second token is obtained from a second token bucket associated with the second identifier. After that, when the second token is obtained, a third token is obtained from a third token bucket associated with the application system to which the target API belongs. Finally, when the third token is obtained, the caller is allowed to call the target API. Thus, by gradually obtaining tokens from the token buckets associated with the caller, the interface, and the application system, flow limiting judgment of the call request in different dimensions is realized, and when tokens are obtained in each token bucket, the API call is allowed, thereby completing the flow control of the interface call request, improving the accuracy and reliability of the request flow limiting, and being more conducive to the rational use of system resources.

[0062] This embodiment provides another request current limiting method. Figure 2 A flowchart of a request current limiting method provided in an embodiment of the present application.

[0063] like Figure 2 As shown, the request current limiting method may include the following steps:

[0064] Step 201: Receive a call request sent by a caller.

[0065] For a detailed description of the above step 201, please refer to other embodiments of the present application and will not be repeated here.

[0066] Step 202: Obtain a first token bucket associated with the first identifier and the second identifier.

[0067] In an embodiment of the present application, the first identifier and the second identifier can be matched with identifiers associated with all token buckets in the request current limiting system to obtain a first token bucket associated not only with the first identifier but also with the second identifier.

[0068] It should be noted that the first token bucket is pre-generated and configured in the request current limiting system, and the current limiting strategy corresponding to the first token bucket can be determined according to the associated caller and interface.

[0069] Optionally, the third identifier of at least one candidate caller that currently needs to be throttled and the fourth identifier of at least one candidate API can be obtained first. Then, at least one first candidate token bucket can be generated, and each first candidate token bucket can be associated with a combination of a third identifier and a fourth identifier.

[0070] For example, the third identifier of at least one candidate caller that currently needs to be limited is caller A, caller B and caller C, and the fourth identifier of at least one candidate API is interface api_1, interface api_2 and interface api_3. Then, each caller is combined with all interfaces separately, and 3+3+3=9 combinations of the third identifier and the fourth identifier can be obtained, and 9 first candidate token buckets can be generated.

[0071] It should be noted that, in some embodiments, there may be some interfaces whose call rates are not restricted, and it is not necessary to configure a token bucket for the interface. For example, when the interface api_3 is not restricted, there are three combinations (i.e., caller A and interface api_3, caller B and interface api_3, and caller C and interface api_3) that do not require the generation of a token bucket, and at this time, six first candidate token buckets are generated.

[0072] Afterwards, for the first candidate token bucket, the first token generation speed of the first candidate token bucket may be determined based on the importance of the candidate caller corresponding to the third identifier and the load threshold of the candidate API corresponding to the fourth identifier.

[0073] In an embodiment of the present application, different weights can be assigned to different callers (such as different services, interfaces, functions, etc.) according to the needs and goals of the business party, so that the importance of the candidate caller corresponding to the third identifier can be determined. The higher the weight, the higher the importance, and more system resources should be allocated to the caller. The token generation speed in the token bucket corresponding to the caller can be increased, so that the maximum number of times the caller calls the API per unit time increases. In addition, the load threshold of each candidate API can be determined based on the historical call rate of each candidate API and the performance consumption of the interface. The larger the load threshold, the higher the number of times the interface can be called per unit time without affecting performance, so the first token generation speed of the first candidate token bucket corresponding to the interface can be appropriately increased.

[0074] In an embodiment of the present application, an initial value of the token generation speed of a token bucket can be set first, and then the order of importance of all candidate callers and the order of load thresholds of all candidate APIs can be comprehensively considered to increase or decrease the initial value and determine the first token generation speed of each first candidate token bucket.

[0075] For example, the importance of all candidate callers is ranked from large to small: caller A>caller B>caller C, and the load thresholds of candidate APIs are ranked from large to small: interface api_3>interface api_1>interface api_2, and the call rate of interface api_3 does not need to be limited. Then the first token generation speed of the first candidate token bucket can be shown in the following Table 1:

[0076] Table 1

[0077]

[0078] In an embodiment of the present application, the token generation speed of different token buckets is determined based on the performance consumption of the interface and the caller weight determined by the business party. System resources can be tilted towards certain callers to reasonably allocate system resources and ensure business development needs.

[0079] Step 203, determining the number of first tokens currently in the first token bucket and the target number of tokens required to be consumed by the call request.

[0080] In the embodiment of the present application, since the first token is taken out from the first token bucket each time the caller calls the target API as a license for calling the target API, the tokens in the first token bucket are being consumed, and the first tokens in the first token bucket are being added at a fixed token generation rate. Therefore, the number of first tokens in the first token bucket is constantly changing. It can be determined whether enough tokens can be taken out of the first token bucket and whether there are enough resources to execute the call request based on the relationship between the current number of first tokens in the first token bucket and the target number of tokens that need to be consumed by the call request.

[0081] It should be noted that the target number of tokens required for a request can be determined based on the size of the request or the amount of resources required, etc. The larger the size of the request or the amount of resources required, the more tokens are required for the request. For example, a lightweight request may require 1 token, while a heavy-load request may require multiple tokens, such as 5.

[0082] Step 204: When the number of first tokens is greater than or equal to the target number, obtain the first token.

[0083] In an embodiment of the present application, when the number of first tokens is greater than or equal to the target number, it can be determined that sufficient tokens can be taken out from the first token bucket to execute the call operation of the target API, so the target number of first tokens can be taken out from the first token bucket.

[0084] Step 205: After obtaining the first token, obtain a second token bucket associated with the second identifier.

[0085] In an embodiment of the present application, the second identifier can be matched with identifiers associated with all token buckets in the request current limiting system to obtain a second token bucket associated with the second identifier.

[0086] It should be noted that the second token bucket is pre-generated and configured in the request current limiting system, and the current limiting strategy corresponding to the second token bucket can be determined according to the associated interface.

[0087] Optionally, at least one second candidate token bucket may be generated, and each second candidate token bucket may be associated with a fourth identifier. Then, for the second candidate token bucket, the second token generation speed of the second candidate token bucket is determined based on the load threshold of the candidate API corresponding to the fourth identifier.

[0088] For example, if the fourth identifier is interface api_1, interface api_2, and interface api_3, then three second candidate token buckets can be generated, and these three second candidate token buckets are associated with interface api_1, interface api_2, and interface api_3 respectively. If the load thresholds of the candidate APIs are ranked from large to small as: interface api_3>interface api_1>interface api_2, and the call rate of interface api_3 does not need to be limited, then the second token generation speed of the second candidate token bucket can be as shown in Table 2 below:

[0089] Table 2

[0090] Candidate API Token generation speed (per second) Interface api_1 35 Interface api_2 25 Interface api_3 No restrictions

[0091] It should be noted that the second token generation speed is less than the sum of the first token generation speeds of all first candidate token buckets associated with the fourth identifier. As shown in Table 1 and Table 2, the three first token generation speeds corresponding to the interface api_1 are 20, 15, and 5, respectively, and the second token generation speed corresponding to the interface api_1 is 35, so it can be seen that 20+15+5=40>35.

[0092] Because an API interface may be called by multiple callers at the same time, and the amount of data that the API interface can carry is limited, making the second token generation speed smaller than the sum of all first token generation speeds can prevent the callers from calling the same interface at a high concurrency and exhausting application resources.

[0093] Step 206: Determine the number of second tokens currently in the second token bucket.

[0094] Step 207: When the number of second tokens is greater than or equal to the target number, obtain the second token.

[0095] In the embodiment of the present application, the logic of obtaining the first token from the first token bucket and the logic of obtaining the second token from the second token bucket are the same, so the detailed description of step 206 and step 207 can be obtained by analogy with the contents of the above-mentioned step 203 and step 204.

[0096] Step 208: When the second token is obtained, obtain a third token bucket associated with the application system to which the target API belongs.

[0097] In an embodiment of the present application, an application system may include multiple API interfaces. Therefore, the token generation speed of the third token bucket should be determined based on the resource usage of the system during peak periods, the volume of all interface calls, and the current limiting strategy of the first candidate token bucket and the second candidate token bucket configured previously. While ensuring that the application server resources are relatively stable, the token generation speed can be adjusted to the maximum.

[0098] Step 209: Determine the number of third tokens currently in the third token bucket.

[0099] Step 210: When the number of third tokens is greater than or equal to the target number, obtain the third token.

[0100] In the embodiment of the present application, the logic of obtaining the third token from the third token bucket and the logic of obtaining the first token from the first token bucket are the same, so the detailed description of step 209 and step 210 can be obtained by analogy with the contents of the above-mentioned steps 203 and 204.

[0101] Step 211: When the third token is obtained, the caller is allowed to call the target API.

[0102] For a detailed description of the above step 201, please refer to other embodiments of the present application and will not be repeated here.

[0103] It should be noted that in the embodiment of the present application, in the process of obtaining tokens from the first token bucket, the second token bucket, and the third token bucket in sequence, once it is determined that the number of tokens in any token bucket is less than the target number, the corresponding token cannot be obtained to continue the token acquisition operation of the next token bucket, and the caller can be rejected from calling the target API, and an error prompt message is returned to the caller. This can avoid the problem of excessive load in any dimension of the caller, interface, and application system, which affects the performance and efficiency of the server.

[0104] Combine the following Figure 3The following describes each process of request current limiting. Figure 3 It is a flowchart of the request current limiting process.

[0105] Depend on Figure 3 , the application system can simultaneously receive Hypertext Transfer Protocol (HTTP) requests sent by caller A, caller B, and caller C, and perform current limiting judgment in parallel. The three call request messages can respectively include the interface api_1 of the target call of caller A, the interface api_2 of the target call of caller B, and the interface api_3 of the target call of caller C. Interface api_1, interface api_2, and interface api_3 are the three interfaces of the current application system.

[0106] Then, each http request is sent to the message interception processor to decrypt the message and authenticate the request. After authentication, the http request can be sent to the current limiting interceptor, which is divided into three modules, including small bucket interface current limiting (i.e., the first token bucket in the above embodiment), large bucket interface current limiting (i.e., the second token bucket in the above embodiment), and application current limiting (i.e., the third token bucket in the above embodiment). Each current limiting module is implemented using the redis-Cell token bucket algorithm.

[0107] like Figure 3 As shown, the small bucket can be used to limit the request flow. If the token is not obtained in the small bucket, the process is terminated and the http request is rejected. Alternatively, if the token can be obtained in the small bucket, the large bucket can be used to limit the request flow. If the token is not obtained in the large bucket, the process is terminated and the http request is rejected. Alternatively, if the token can be obtained in the large bucket, the application-level token bucket can be used to limit the request flow. If the token is not obtained in the application-level token bucket, the process is terminated and the http request is rejected. Alternatively, if the token can be obtained in the application-level token bucket, caller A can be allowed to call interface api_1, caller B can call interface api_2, and caller C can be allowed to call interface api_3.

[0108] In order to implement the above embodiment, the present application also proposes a request current limiting device.

[0109] Figure 4 A schematic diagram of the structure of a request current limiting device provided in an embodiment of the present application.

[0110] like Figure 4 As shown, the request current limiting device 400 includes:

[0111] The receiving module 401 is used to receive a call request sent by a caller, wherein the call request includes a first identifier of the caller and a second identifier corresponding to a target application programming interface API;

[0112] A first acquisition module 402, configured to acquire a first token from a first token bucket associated with the first identifier and the second identifier;

[0113] A second acquisition module 403 is used to acquire a second token from a second token bucket associated with the second identifier when the first token is acquired;

[0114] A third acquisition module 404 is used to acquire a third token from a third token bucket associated with the application system to which the target API belongs when the second token is acquired;

[0115] The processing module 405 is used to allow the caller to call the target API when the third token is obtained.

[0116] Furthermore, the first acquisition module 402 may be specifically configured to:

[0117] Obtain a first token bucket associated with the first identifier and the second identifier;

[0118] Determine the number of first tokens currently in the first token bucket and the target number of tokens required to be consumed by the call request;

[0119] When the number of first tokens is greater than or equal to the target number, the first token is acquired.

[0120] Furthermore, the first acquisition module 402 may also be used to:

[0121] Obtaining a third identifier of at least one candidate caller that currently needs to be throttled, and a fourth identifier of at least one candidate API;

[0122] Generate at least one first candidate token bucket, and associate each first candidate token bucket with a combination of a third identifier and a fourth identifier;

[0123] For the first candidate token bucket, a first token generation speed of the first candidate token bucket is determined based on the importance of the candidate caller corresponding to the third identifier and the load threshold of the candidate API corresponding to the fourth identifier.

[0124] Furthermore, the second acquisition module 403 may be specifically used for:

[0125] Obtain a second token bucket associated with the second identifier;

[0126] Determine the number of second tokens currently in the second token bucket;

[0127] When the second token number is greater than or equal to the target number, a second token is acquired.

[0128] Furthermore, the second acquisition module 403 may also be used to:

[0129] Generate at least one second candidate token bucket, and associate each second candidate token bucket with a fourth identifier;

[0130] For the second candidate token bucket, based on the load threshold of the candidate API corresponding to the fourth identifier, the second token generation speed of the second candidate token bucket is determined, wherein the second token generation speed is less than the sum of the first token generation speeds of all first candidate token buckets associated with the fourth identifier.

[0131] Furthermore, the third acquisition module 404 may be specifically used for:

[0132] Obtain a third token bucket associated with the application system to which the target API belongs;

[0133] Determine the number of third tokens currently in the third token bucket;

[0134] When the third token number is greater than or equal to the target number, a third token is acquired.

[0135] Furthermore, the request current limiting device 400 may further include:

[0136] The sending module is used to reject the caller's call to the target API and return an error prompt message to the caller when the number of tokens in any token bucket is less than the target number.

[0137] It should be noted that the above explanation of the embodiment of the request current limiting method is also applicable to the request current limiting device of this embodiment, and will not be repeated here.

[0138] In an embodiment of the present application, by gradually acquiring tokens from the token buckets associated with the caller, the interface, and the application system, flow limiting judgments of call requests in different dimensions are implemented, and when tokens are acquired in each token bucket, API calls are allowed, thereby completing the flow control of interface call requests, improving the accuracy and reliability of request flow limiting, and being more conducive to the rational use of system resources.

[0139] In order to implement the above embodiments, the present application also proposes an electronic device, comprising: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method provided by the above embodiments.

[0140] In order to implement the above embodiments, the present application also proposes a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the methods provided by the above embodiments.

[0141] In order to implement the above embodiments, the present application also proposes a computer program product, including a computer program, which implements the methods provided by the above embodiments when executed by a processor.

[0142] The collection, storage, use, processing, transmission, provision and disclosure of user personal information involved in this application are in compliance with relevant laws and regulations and do not violate public order and good morals.

[0143] It should be noted that personal information from users should be collected for legitimate and reasonable purposes and should not be shared or sold outside of these legitimate uses. In addition, such collection / sharing should be carried out after receiving the user's informed consent, including but not limited to notifying the user to read the user agreement / user notice and sign the agreement / authorization including authorization of relevant user information before the user uses the function. In addition, any necessary steps should be taken to protect and safeguard access to such personal information data and ensure that others who have access to personal information data comply with its privacy policy and procedures.

[0144] The present application is expected to provide an implementation scheme for users to selectively block the use or access of personal information data. That is, the present disclosure is expected to provide hardware and / or software to prevent or block access to such personal information data. Once the personal information data is no longer needed, the risk can be minimized by limiting data collection and deleting the data. In addition, when applicable, such personal information is de-identified to protect the privacy of the user.

[0145] In the description of the aforementioned embodiments, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0146] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In the description of this application, the meaning of "plurality" is at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0147] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0148] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute the instructions), or in combination with these instruction execution systems, devices or apparatuses. For the purpose of this specification, "computer-readable medium" can be any device that can contain, store, communicate, propagate or transmit a program for use by an instruction execution system, device or apparatus, or in combination with these instruction execution systems, devices or apparatuses. More specific examples of computer-readable media (a non-exhaustive list) include the following: an electrical connection with one or more wires (electronic device), a portable computer disk box (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disk read-only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or processing in other suitable ways if necessary, and then stored in a computer memory.

[0149] It should be understood that the various parts of the present application can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0150] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiment.

[0151] In addition, each functional unit in each embodiment of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0152] The storage medium mentioned above may be a read-only memory, a magnetic disk or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limiting the present application. A person of ordinary skill in the art may change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A request current limiting method, characterized in that: include: Receiving a call request sent by a caller, wherein the call request includes a first identifier of the caller and a second identifier corresponding to a target application programming interface API; Obtain a first token from a first token bucket associated with the first identifier and the second identifier; When the first token is obtained, obtaining a second token from a second token bucket associated with the second identifier; When the second token is obtained, obtaining a third token from a third token bucket associated with the application system to which the target API belongs; In case the third token is obtained, the caller is allowed to call the target API.

2. The method according to claim 1, characterized in that The acquiring a first token from a first token bucket associated with the first identifier and the second identifier includes: Obtain a first token bucket associated with the first identifier and the second identifier; Determine the number of first tokens currently in the first token bucket and the target number of tokens required to be consumed by the call request; When the first token number is greater than or equal to the target number, a first token is acquired.

3. The method according to claim 2, characterized in that Before obtaining the first token bucket corresponding to the first identifier and the second identifier, the method further includes: Obtaining a third identifier of at least one candidate caller that currently needs to be throttled, and a fourth identifier of at least one candidate API; Generate at least one first candidate token bucket, and associate each of the first candidate token buckets with a combination of the third identifier and the fourth identifier; For the first candidate token bucket, a first token generation speed of the first candidate token bucket is determined based on the importance of the candidate caller corresponding to the third identifier and the load threshold of the candidate API corresponding to the fourth identifier.

4. The method according to any one of claims 1 to 3, characterized in that: The step of acquiring a second token from a second token bucket associated with the second identifier upon acquiring the first token comprises: Obtain a second token bucket associated with the second identifier; Determine the number of second tokens currently in the second token bucket; When the second token number is greater than or equal to the target number, a second token is acquired.

5. The method according to claim 4, characterized in that Before acquiring the second token bucket associated with the second identifier, the method further includes: Generate at least one second candidate token bucket, and associate each of the second candidate token buckets with one of the fourth identifiers; For the second candidate token bucket, based on the load threshold of the candidate API corresponding to the fourth identifier, determine the second token generation speed of the second candidate token bucket, wherein the second token generation speed is less than the sum of the first token generation speeds of all first candidate token buckets associated with the fourth identifier.

6. The method according to any one of claims 1 to 5, characterized in that: The step of obtaining, when the second token is obtained, a third token from a third token bucket associated with the application system to which the target API belongs includes: Acquire a third token bucket associated with the application system to which the target API belongs; Determine the number of third tokens currently in the third token bucket; When the third token number is greater than or equal to the target number, a third token is acquired.

7. The method according to any one of claims 1 to 6, characterized in that: Also includes: In the case where the number of tokens in any token bucket is less than the target number, the caller is denied from calling the target API, and an error prompt message is returned to the caller.

8. A request current limiting device, characterized in that: include: A receiving module, configured to receive a call request sent by a caller, wherein the call request includes a first identifier of the caller and a second identifier corresponding to a target application programming interface API; A first acquisition module, configured to acquire a first token from a first token bucket associated with the first identifier and the second identifier; A second acquisition module, configured to acquire a second token from a second token bucket associated with the second identifier when the first token is acquired; A third acquisition module, configured to acquire a third token from a third token bucket associated with the application system to which the target API belongs, when the second token is acquired; A processing module is used to allow the caller to call the target API when the third token is obtained.

9. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the request current limiting method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the request current limiting method according to any one of claims 1 to 7.

11. A computer program product, characterized in that It includes a computer program, which, when executed by a processor, implements the request current limiting method described in any one of claims 1 to 7.

Images