Request traffic limiting method and device, computer equipment and readable storage medium

Abstract

The invention relates to a request traffic limiting method and device, computer equipment, a computer readable storage medium and a computer program product. Under the condition that a micro-service request is received, an overload protection identifier can be inquired through a key value obtained by integrating a uniform resource identifier and a request mode. And under the condition that the overload protection identifier is queried, determining that the micro-service request needs to be subjected to overload protection, so that the micro-service request is added to the request queue without distributing tokens to process the micro-service request. Due to the fact that under the overload condition, the micro-service requests corresponding to the uniform resource identifiers and the request modes can be configured in advance, overload protection needs to be carried out on the micro-service requests, overload protection is carried out on the micro-service requests when the corresponding micro-service requests are received, and therefore request flow limiting can be carried out according to the actual system loads of the micro-service system. Therefore, while reasonable current limiting is carried out, limitation on system processing capacity is reduced, and important micro-service requests can be responded in time.

Description

Technical Field

[0001] The present application relates to the technical field of distributed systems, and in particular to a method, apparatus, computer device, computer-readable storage medium, and computer program product for request flow restriction. Background Art

[0002] Traffic limiting is a protection mechanism for microservice systems facing large amounts of sudden and abnormal traffic. Microservice systems have a large number of users and many concurrent requests, making them vulnerable to attacks from abnormal traffic. When the peak traffic exceeds the maximum load of the server, the stability of online services cannot be guaranteed, and even an avalanche effect may occur, affecting the normal operation of the entire system. Therefore, a method of request traffic limiting is usually introduced in microservice systems. In related technologies, a threshold for the number of pending requests is usually set, and when the number of pending requests exceeds the threshold, new requests are rejected. As a result, the processing capacity of the system may be limited. Summary of the invention

[0003] Based on this, it is necessary to provide a request flow limitation method, apparatus, computer equipment, computer-readable storage medium and computer program product that can reduce the limitation on the processing capacity of the microservice system in response to the above technical problems.

[0004] In a first aspect, the present application provides a method for limiting request flow, including:

[0005] When a microservice request is received, obtain the requested uniform resource identifier and the request method used;

[0006] The result of integrating the uniform resource identifier and the request method is used as the key value, and based on the key value, the corresponding overload protection flag of the microservice request is queried;

[0007] When the overload protection identifier corresponding to the microservice request is queried, it is determined that no token needs to be allocated for the microservice request, and the microservice request is added to the request queue; the request queue is used to provide the microservice request for processing.

[0008] In one embodiment, the method further comprises:

[0009] If the overload protection flag corresponding to the microservice request is not found, if there is a token in the token bucket, a token is selected from the token bucket and assigned to the microservice request. The token indicates that the microservice request has the permission to be added to the request queue.

[0010] Add the microservice request to the request queue.

[0011] In one embodiment, the method further comprises:

[0012] If there is no token in the token bucket, the microservice request is rejected.

[0013] In one embodiment, the request queue includes a normal queue and a priority queue; adding a microservice request to the request queue includes:

[0014] Based on the key value, query the corresponding priority of the microservice request;

[0015] If the corresponding priority of the microservice request is found, the microservice request is added to the priority queue; if the corresponding priority of the microservice request is not found, the microservice request is added to the ordinary queue.

[0016] In one embodiment, the method further comprises:

[0017] In response to the overload protection configuration operation, a triplet for configuring overload protection is obtained and written into the overload protection configuration file; the triplet includes a uniform resource identifier, a request method, and an overload protection identifier. The overload protection configuration file is used for querying the corresponding overload protection identifier of the microservice request based on the key value.

[0018] In one embodiment, the method further comprises:

[0019] In response to the priority configuration operation, a triplet for configuring the priority is obtained and written into a priority configuration file; the triplet includes a uniform resource identifier, a request method, and a priority, and the priority configuration file is used for querying the corresponding priority of the microservice request based on the key value.

[0020] In one embodiment, there is a quantity ratio configuration relationship between the common queue and the priority queue when processing microservice requests; the method further includes:

[0021] In the process of taking out microservice requests from the ordinary queue and the priority queue for processing, according to the quantity ratio configuration relationship, the corresponding number of microservice requests in the priority queue are processed first, and then the corresponding number of microservice requests in the ordinary queue are processed.

[0022] In a second aspect, the present application further provides a request flow limiting device, comprising:

[0023] The acquisition module is used to obtain the requested uniform resource identifier and the request method used when receiving a microservice request;

[0024] The query module is used to use the integration result of the uniform resource identifier and the request method as the key value, and query the overload protection identifier corresponding to the microservice request based on the key value;

[0025] The adding module is used to determine that no token needs to be allocated for the microservice request when the overload protection identifier corresponding to the microservice request is queried, and add the microservice request to the request queue; the request queue is used to provide the microservice request for processing.

[0026] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0027] When a microservice request is received, obtain the requested uniform resource identifier and the request method used;

[0028] The result of integrating the uniform resource identifier and the request method is used as the key value, and based on the key value, the corresponding overload protection flag of the microservice request is queried;

[0029] When the overload protection identifier corresponding to the microservice request is queried, it is determined that no token needs to be allocated for the microservice request, and the microservice request is added to the request queue; the request queue is used to provide the microservice request for processing.

[0030] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the following steps are implemented:

[0031] When a microservice request is received, obtain the requested uniform resource identifier and the request method used;

[0032] The result of integrating the uniform resource identifier and the request method is used as the key value, and based on the key value, the corresponding overload protection flag of the microservice request is queried;

[0033] When the overload protection identifier corresponding to the microservice request is queried, it is determined that no token needs to be allocated for the microservice request, and the microservice request is added to the request queue; the request queue is used to provide the microservice request for processing.

[0034] In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor:

[0035] When a microservice request is received, obtain the requested uniform resource identifier and the request method used;

[0036] The result of integrating the uniform resource identifier and the request method is used as the key value, and based on the key value, the corresponding overload protection flag of the microservice request is queried;

[0037] When the overload protection identifier corresponding to the microservice request is queried, it is determined that no token needs to be allocated for the microservice request, and the microservice request is added to the request queue; the request queue is used to provide the microservice request for processing.

[0038] The above-mentioned request flow limiting method, device, computer equipment, computer-readable storage medium and computer program product can first query the overload protection identifier through the key value obtained by integrating the uniform resource identifier and the request method when receiving a microservice request. When the overload protection identifier is queried, it is determined that the microservice request needs to be overload protected, so that it is not necessary to allocate a token and add it to the request queue to process the microservice request. Since it is possible to configure in advance which microservice requests corresponding to the uniform resource identifier and the request method need to be overload protected in the case of overload, and overload protection is performed on the corresponding microservice request when it is received, the request flow can be limited according to the actual system load of the microservice system and the actual overcurrent protection requirements. As a result, while performing reasonable flow limiting, the limitation on the system processing capacity is reduced, and important microservice requests can be responded to in a timely manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0040] FIG1 is a diagram showing an application environment of a method for limiting request flow in one embodiment;

[0041] FIG2 is a schematic diagram of a flow chart of a method for requesting flow restriction in one embodiment;

[0042] FIG3 is a schematic diagram of a flow chart of a method for requesting flow restriction in another embodiment;

[0043] FIG4 is a schematic diagram of a simplified flow chart of a method for requesting flow restriction in yet another embodiment;

[0044] FIG5 is a schematic diagram of the interaction process between a user and a current limiting control agent in one embodiment;

[0045] FIG6 is a structural block diagram of a request flow limiting device in one embodiment;

[0046] FIG. 7 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0048] The current method of introducing request flow restrictions in microservice systems usually sets a threshold for the number of pending requests, and rejects new requests when the number of pending requests exceeds the threshold. As a result, it cannot be automatically adjusted according to the actual system load or network conditions, lacks flexibility, and may limit the system's processing capacity.

[0049] In addition, in addition to executing microservice functions, the request current limiting function is usually also executed by the microservice system, which makes the microservice system perform multiple functions. This will reduce the reliability of the microservice system and increase the difficulty of management. Finally, currently, one current limiting service is usually deployed for each of the multiple microservice functions, which is responsible for uniformly handling the current limiting logic. However, such a centralized current limiting mode is vulnerable to single-point attacks, resulting in a large number of microservices being inaccessible.

[0050] In response to the above problems, an embodiment of the present application provides a request flow limiting method, which can be applied in an application environment as shown in Figure 1. Among them, the terminal 102 communicates with the server 104 through the network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated on the server 104, or it can be placed on the cloud or other network servers. The terminal 102 can send a microservice request to the server 104, and the server 104 can obtain the requested uniform resource identifier and the request method used when receiving the microservice request. The integration result after integrating the uniform resource identifier and the request method is used as the key value, and based on the key value, the corresponding overload protection identifier of the microservice request is queried. In the case of querying the corresponding overload protection identifier of the microservice request, it is determined that there is no need to allocate a token for the microservice request, and based on the key value, the microservice request is added to the request queue; the request queue is used to provide microservice requests for processing.

[0051] The terminal 102 may be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, IoT devices, and portable wearable devices. The IoT devices may be smart speakers, smart TVs, smart air conditioners, smart car devices, projection devices, etc. Portable wearable devices may be smart watches, smart bracelets, head-mounted devices, etc. Head-mounted devices may be virtual reality (VR) devices, augmented reality devices, smart glasses, etc. The server 104 may be an independent physical server, or a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides cloud computing services.

[0052] In an exemplary embodiment, as shown in FIG2 , a request flow restriction method is provided, which is described by taking the method applied to the server in FIG1 as an example, and includes the following steps 202 to 206. Among them:

[0053] Step 202: upon receiving a microservice request, obtain the requested uniform resource identifier and the request method used.

[0054] Among them, the uniform resource identifier refers to a string used to identify the name of an Internet resource, and the request method can refer to the request method of the Hypertext Transfer Protocol (HTTP), including POST, GET, HEAD, PUT, PATCH, OPTIONS, DELETE, CONNECT, and TRACE. Microservice requests can carry uniform resource identifiers and request methods.

[0055] Step 204: Use the integrated result of the uniform resource identifier and the request method as the key value, and query the overload protection identifier corresponding to the microservice request based on the key value.

[0056] Among them, the integration method can be to splice the uniform resource identifier and the request method, which is not specifically limited in the embodiments of the present application. To query the overload protection identifier corresponding to the microservice request, you can query in the overload protection configuration file. In the overload protection configuration file, the key value and the overload protection identifier can be stored correspondingly. By configuring the overload protection configuration file in advance, you can determine in advance which microservice requests corresponding to the uniform resource identifier and the request method need to be overloaded, rather than refusing to process when overloaded.

[0057] Step 206, when the overload protection identifier corresponding to the microservice request is queried, it is determined that no token needs to be allocated for the microservice request, and the microservice request is added to the request queue; the request queue is used to provide the microservice request for processing.

[0058] When the overload protection flag corresponding to the microservice request is found, it means that the overload protection has been configured in advance for the microservice request corresponding to the uniform resource identifier and the request method. Therefore, no token is allocated for the microservice request, but the microservice request is directly added to the request queue. The microservice request can be processed later by calling the microservice request in the request queue.

[0059] In the above-mentioned request flow limiting method, when a microservice request is received, the overload protection identifier can be queried first through the key value obtained by integrating the uniform resource identifier and the request method. When the overload protection identifier is queried, it is determined that the microservice request needs to be overload protected, so that there is no need to allocate a token and add it to the request queue to process the microservice request. Since it is possible to configure in advance which microservice requests corresponding to the uniform resource identifier and the request method need to be overload protected in the case of overload, and overload protection is performed on the corresponding microservice requests when they are received, request flow limitation can be performed according to the actual system load of the microservice system and the actual overcurrent protection requirements. As a result, while reasonable flow limitation is performed, the limitation on the system processing capacity is reduced, and important microservice requests can be responded to in a timely manner.

[0060] In an exemplary embodiment, the method further comprises:

[0061] If the overload protection flag corresponding to the microservice request is not found, if there is a token in the token bucket, a token is selected from the token bucket and assigned to the microservice request. The token indicates that the microservice request has the permission to be added to the request queue.

[0062] Add the microservice request to the request queue.

[0063] Specifically, if the overload protection identifier corresponding to the microservice request is not found, it means that the overload protection is not configured in advance for the microservice request corresponding to the uniform resource identifier and the request method. Therefore, it is necessary to allocate a token from the token bucket for the microservice request so that the microservice request can be added to the request queue to wait for processing. Therefore, it can be determined whether the token bucket has a token. If there is a token, a token can be selected from the token bucket, and the number of tokens in the token bucket can be reduced simultaneously. The selected token is allocated to the microservice request, and thus the microservice request can be added to the request queue.

[0064] In this embodiment, since a token can be normally allocated to the microservice request when the overload protection identifier corresponding to the microservice request is not queried, whether to reject the microservice request is determined according to whether the token is allocated. Therefore, the request flow can be reasonably limited according to the actual system load of the microservice system and the actual overcurrent protection requirements.

[0065] In an exemplary embodiment, the method further comprises:

[0066] If there is no token in the token bucket, the microservice request is rejected.

[0067] In this embodiment, since a token can be normally allocated to the microservice request when the overload protection identifier corresponding to the microservice request is not queried, whether to reject the microservice request is determined according to whether the token is allocated. Therefore, the request flow can be reasonably limited according to the actual system load of the microservice system and the actual overcurrent protection requirements.

[0068] In an exemplary embodiment, the request queue includes a common queue and a priority queue; adding a microservice request to the request queue includes:

[0069] Based on the key value, query the corresponding priority of the microservice request;

[0070] If the corresponding priority of the microservice request is found, the microservice request is added to the priority queue; if the corresponding priority of the microservice request is not found, the microservice request is added to the ordinary queue.

[0071] The processing order of the microservice requests in the priority queue can be sorted according to the priority of the microservice requests; that is, microservice requests with higher priorities can be processed first, and then microservice requests with lower priorities. Microservice requests in the ordinary queue can be processed according to the arrival time sequence. In addition, microservice requests in the priority queue can be processed before microservice requests in the ordinary queue.

[0072] To query the corresponding priority of the microservice request, you can query it in the priority configuration file. In the priority configuration file, the key value and priority can be stored correspondingly. By configuring the priority configuration file in advance, you can determine in advance which microservice requests corresponding to the uniform resource identifier and request method need to set the priority. For a microservice request, if the corresponding priority can be queried, it is added to the priority queue and the corresponding priority is marked in the priority queue; otherwise, the microservice request is added to the normal queue.

[0073] In this embodiment, when it is determined that overflow protection is required for a microservice request, there is no need to allocate a token to the microservice request, and the corresponding priority of the microservice request can be further queried. If the corresponding priority of the microservice request is found, the microservice request can be added to the priority queue; if the corresponding priority of the microservice request is not found, the microservice request can be added to the ordinary queue. Since the importance of different microservice requests can be distinguished through the priority queue, the possibility of server resources being occupied by low-priority microservice requests is reduced.

[0074] In an exemplary embodiment, the method further comprises:

[0075] In response to the overload protection configuration operation, a triplet for configuring overload protection is obtained and written into the overload protection configuration file; the triplet includes a uniform resource identifier, a request method, and an overload protection identifier. The overload protection configuration file is used for querying the corresponding overload protection identifier of the microservice request based on the key value.

[0076] As can be seen from the above content, the overload protection configuration file can be set in advance. Specifically, the user can configure it in the form of a triple by adding a triple. Among them, the triple can include a uniform resource identifier, a request method and an overload protection identifier, and the three can be stored correspondingly.

[0077] In this embodiment, since it is possible to configure in advance which uniform resource identifiers and microservice requests corresponding to the request methods need to be overload protected in the case of an overload, and to perform overload protection on the corresponding microservice requests when they are received, it is possible to limit the request flow according to the actual system load of the microservice system and the actual overcurrent protection requirements.

[0078] In an exemplary embodiment, the method further comprises:

[0079] In response to the priority configuration operation, a triplet for configuring the priority is obtained and written into a priority configuration file; the triplet includes a uniform resource identifier, a request method, and a priority, and the priority configuration file is used for querying the corresponding priority of the microservice request based on the key value.

[0080] As can be seen from the above content, the priority configuration file can be set in advance. Specifically, the user can configure in the form of a triple by adding a triple. Among them, the triple can include a uniform resource identifier, a request method and a priority, and the three can be stored correspondingly.

[0081] In this embodiment, since priorities can be configured in advance for different microservice requests, the microservice requests can be added to the priority queue according to the priorities to distinguish the importance of different microservice requests, thereby reducing the possibility of server resources being occupied by low-priority microservice requests.

[0082] In an exemplary embodiment, there is a quantity ratio configuration relationship between the common queue and the priority queue when processing microservice requests; the method further includes:

[0083] In the process of taking out microservice requests from the ordinary queue and the priority queue for processing, according to the quantity ratio configuration relationship, the corresponding number of microservice requests in the priority queue are processed first, and then the corresponding number of microservice requests in the ordinary queue are processed.

[0084] Specifically, since microservice requests in the priority queue are generally processed first, and microservice requests in the ordinary queue are processed later, this may cause starvation of microservice requests in the ordinary queue. In order to reduce the occurrence of this phenomenon, the relationship between the number ratio of the two queues can be configured. For example, it can be configured as 4:1, that is, the number ratio between the priority queue and the ordinary queue is configured as 4:1. In specific implementation, the microservice requests in 4 priority queues can be processed first, and then the microservice requests in 1 ordinary queue can be processed. In this way, the starvation of microservice requests in the ordinary queue can be reduced.

[0085] In this embodiment, since the flow limiting can be achieved, the processing distribution of the two queues can be divided by configuring the quantity ratio between the ordinary queue and the priority queue, thereby reducing the starvation phenomenon caused by the microservice requests in the ordinary queue not being processed.

[0086] For ease of understanding, the complete method flow provided in the embodiment of the present application is now described. Among them, the microservice request mentioned in the embodiment of the present application can be initiated by the user. The user can initiate a microservice request to the microservice system, and the microservice system can allow the user to create multiple identity accounts to initiate microservice requests. The request flow limiting method provided in the embodiment of the present application can be executed by the proxy Agent used for flow limiting control on the server. The proxy Agent can be deployed in the same Pod container with the microservice, so that the microservice system only executes the microservice function, and the flow limiting service is executed by the proxy Agent. Based on the above description, referring to Figure 3, the specific implementation can be shown in the following process steps:

[0087] Step 302: Create an overload protection configuration file and a priority configuration file.

[0088] Specifically, the user can configure an overload protection profile for request current limiting, which can be represented by a triple. The triple includes a uniform resource identifier, a request method, and an overload protection flag. The request method may refer to an HTTP request method, which may include Get, Post, Put, and Delete, etc. The overload protection flag may indicate whether overload protection is required. The triple may be written into the overload protection profile line by line.

[0089] In addition, users can also configure priority profiles, which can be represented by triples. The triples include uniform resource identifiers, request methods, and priorities. Priority is used to characterize the importance of microservice requests. The higher the priority, the easier it is for the corresponding microservice requests to be processed. After users create or configure overload protection profiles and priority profiles, the current limiting control agent can promptly identify file changes and send the latest profiles to the corresponding current limiting agent agents of each microservice for update.

[0090] Step 304: Perform protection interception processing on the microservice request according to the overload protection configuration file.

[0091] Specifically, when the current limiting agent receives a microservice request, it first parses the microservice request to obtain the uniform resource identifier and the request method. Then, it reads the overload protection configuration file and converts the triples therein into a hash table. Among them, the key value in the hash table is a string obtained by concatenating the uniform resource identifier and the request method. By concatenating the uniform resource identifier and the request method corresponding to the microservice request, a key value to be queried can be obtained, and the hash table is queried based on the key value. If the corresponding overload protection identifier is not found, it means that the microservice request does not require protection interception processing. At this point, the normal verification token current limiting process can be entered.

[0092] If the corresponding overload protection identifier is found, the priority corresponding to the key value can be further queried in the priority configuration file. If a priority exists, the microservice request can be added to the priority queue. Otherwise, it can be added to the normal queue. Because of overload protection, regardless of whether there is a priority, there is no need to perform token bucket current limiting operations, and it can be added directly to the queue. Therefore, even if the system enters an overload state, microservice requests that need to be intercepted and protected will not be discarded due to token bucket current limiting, thereby ensuring the processing stability of the core API.

[0093] Step 306: If the microservice request does not require protection interception processing, the token verification flow control is performed.

[0094] Specifically, the current limiting agent can first determine whether there are enough tokens in the token bucket. If there are tokens in the bucket, a token is taken out of the bucket and the current number of tokens is reduced. If there is no token, current limiting protection is performed and the microservice request is rejected. When the token is successfully taken out, the agent parses the microservice request, constructs a key value composed of a uniform resource identifier and a request method as an index, and queries the priority configuration file to see if there is a priority configuration for the API (that is, the API that sends the microservice request). If there is a priority configuration, the microservice request and the priority are bound and added to the priority queue. Otherwise, the microservice request is added to the normal queue. Because it is a priority queue, even microservice requests that come later will be given priority due to their higher priority.

[0095] Step 308: Divert the microservice requests in the common queue and the priority queue.

[0096] Specifically, by diverting through dual queues, while realizing the current limiting function, it is also possible to prevent a large number of requests after the current limiting from overwhelming the system. At the same time, in order to ensure that the microservice requests sent through the core API can be processed in a timely manner. When the microservice system finds that there are requests in the priority queue, it will first grab the request from the priority queue and process it, which may cause starvation of ordinary requests. Therefore, there can also be a proportional configuration relationship between priority requests and ordinary requests in terms of processing quantity, that is, the microservice system is allowed to read an ordinary request from the ordinary queue for business processing after processing several priority requests.

[0097] Among them, the brief flowchart of the above process can refer to Figure 4. In addition, the interaction between the user and the current limiting control agent, as well as the specific current limiting control process can refer to Figure 5. The above process proposes a service overload protection strategy based on the overload protection profile, which allows microservice requests sent through the core API to be promptly processed when the microservice system is already overloaded and current limited, thereby ensuring its stability. In addition, through the priority queue, microservice requests sent through APIs of different importance are distinguished, thereby preventing server resources from being occupied by low-priority requests. Finally, the request flow limit is implemented through the proxy Agent used for current limiting control, rather than by the microservice itself, so that the current limiting function of the microservice can be implemented in a non-invasive manner, and the single point problem of independent deployment of the current limiting service is avoided.

[0098] The request flow limiting method proposed above can ensure the stability and immediacy of the core interfaces and services of the microservice system under high concurrency, as well as the flow limiting operation of non-core APIs based on priority queues and overload protection strategies. The scenarios in which this method can be applied include:

[0099] (1) Cloud services and API management platforms: In cloud platforms or internal microservice architectures that provide API services, the call frequency and importance of different APIs may vary greatly. This solution can automatically adjust the access rights and priorities of each API based on the configuration to ensure the stable operation of key services while reasonably allocating resources to other APIs.

[0100] (2) High-performance Web server: For high-traffic websites or applications, especially e-commerce, financial or social platforms, this solution can help prioritize key operations such as payment and login during peak hours to ensure user experience. At the same time, it limits low-priority activity traffic to prevent system overload.

[0101] It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0102] Based on the same inventive concept, the embodiment of the present application also provides a request flow limiting device for implementing the request flow limiting method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more request flow limiting device embodiments provided below can refer to the limitations of the request flow limiting method above, and will not be repeated here.

[0103] In an exemplary embodiment, as shown in FIG6 , a request flow restriction device is provided, including: an acquisition module 602, a query module 604 and an adding module 606, wherein:

[0104] The acquisition module 602 is used to obtain the requested uniform resource identifier and the request method used when receiving a microservice request;

[0105] The query module 604 is used to use the integration result of the uniform resource identifier and the request method as the key value, and query the overload protection identifier corresponding to the microservice request based on the key value;

[0106] The adding module 606 is used to determine that no token needs to be allocated for the microservice request when the overload protection identifier corresponding to the microservice request is queried, and add the microservice request to the request queue; the request queue is used to provide the microservice request for processing.

[0107] In an exemplary embodiment, the adding module 606 is also used to, if the overload protection identifier corresponding to the microservice request is not queried, select a token from the token bucket and allocate it to the microservice request if there is a token in the token bucket, and the token indicates that the microservice request has the permission to be added to the request queue; add the microservice request to the request queue.

[0108] In an exemplary embodiment, the adding module 606 is further configured to reject the microservice request if no token exists in the token bucket.

[0109] In an exemplary embodiment, the request queue includes a normal queue and a priority queue; the adding module 606 is specifically used to query the corresponding priority of the microservice request based on the key value; when the corresponding priority of the microservice request is queried, the microservice request is added to the priority queue; when the corresponding priority of the microservice request is not queried, the microservice request is added to the normal queue.

[0110] In an exemplary embodiment, the acquisition module 602 is also used to respond to the overload protection configuration operation, obtain a triplet for configuring overload protection, and write it into the overload protection configuration file; the triplet includes a uniform resource identifier, a request method and an overload protection identifier, and the overload protection configuration file is used for querying the corresponding overload protection identifier of the microservice request based on the key value.

[0111] In an exemplary embodiment, the acquisition module 602 is also used to respond to the priority configuration operation, obtain a triplet for configuring the priority, and write it into the priority configuration file; the triplet includes a uniform resource identifier, a request method and a priority, and the priority configuration file is used for querying the corresponding priority of the microservice request based on the key value.

[0112] In an exemplary embodiment, there is a quantity ratio configuration relationship between the common queue and the priority queue when processing microservice requests; the acquisition module 602 is also used to give priority to processing a corresponding number of microservice requests in the priority queue according to the quantity ratio configuration relationship, and then process a corresponding number of microservice requests in the common queue in the process of taking out microservice requests from the common queue and the priority queue for processing.

[0113] Each module in the above-mentioned request flow restriction device can be implemented in whole or in part by software, hardware or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module above.

[0114] In an exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be shown in FIG7. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. The processor, the memory and the input / output interface are connected via a system bus, and the communication interface is connected to the system bus via the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store microservice requests. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a request flow restriction method is implemented.

[0115] Those skilled in the art will understand that the structure shown in FIG. 7 is merely a block diagram of a partial structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different arrangement of components.

[0116] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the following steps are implemented:

[0117] When a microservice request is received, obtain the requested uniform resource identifier and the request method used;

[0118] The result of integrating the uniform resource identifier and the request method is used as the key value, and based on the key value, the corresponding overload protection flag of the microservice request is queried;

[0119] When the overload protection identifier corresponding to the microservice request is queried, it is determined that no token needs to be allocated for the microservice request, and the microservice request is added to the request queue; the request queue is used to provide the microservice request for processing.

[0120] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0121] If the overload protection flag corresponding to the microservice request is not found, if there is a token in the token bucket, a token is selected from the token bucket and assigned to the microservice request. The token indicates that the microservice request has the permission to be added to the request queue.

[0122] Add the microservice request to the request queue.

[0123] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0124] If there is no token in the token bucket, the microservice request is rejected.

[0125] In one embodiment, the request queue includes a normal queue and a priority queue; when the processor executes the computer program, the following steps are also implemented:

[0126] Based on the key value, query the corresponding priority of the microservice request;

[0127] If the corresponding priority of the microservice request is found, the microservice request is added to the priority queue; if the corresponding priority of the microservice request is not found, the microservice request is added to the ordinary queue.

[0128] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0129] In response to the overload protection configuration operation, a triplet for configuring overload protection is obtained and written into the overload protection configuration file; the triplet includes a uniform resource identifier, a request method, and an overload protection identifier. The overload protection configuration file is used for querying the corresponding overload protection identifier of the microservice request based on the key value.

[0130] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0131] In response to the priority configuration operation, a triplet for configuring the priority is obtained and written into a priority configuration file; the triplet includes a uniform resource identifier, a request method, and a priority, and the priority configuration file is used for querying the corresponding priority of the microservice request based on the key value.

[0132] In one embodiment, there is a quantity ratio configuration relationship between the common queue and the priority queue when processing microservice requests; when the processor executes the computer program, the following steps are also implemented:

[0133] In the process of taking out microservice requests from the ordinary queue and the priority queue for processing, according to the quantity ratio configuration relationship, the corresponding number of microservice requests in the priority queue are processed first, and then the corresponding number of microservice requests in the ordinary queue are processed.

[0134] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0135] When a microservice request is received, obtain the requested uniform resource identifier and the request method used;

[0136] The result of integrating the uniform resource identifier and the request method is used as the key value, and based on the key value, the corresponding overload protection flag of the microservice request is queried;

[0137] When the overload protection identifier corresponding to the microservice request is queried, it is determined that no token needs to be allocated for the microservice request, and the microservice request is added to the request queue; the request queue is used to provide the microservice request for processing.

[0138] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0139] If the overload protection flag corresponding to the microservice request is not found, if there is a token in the token bucket, a token is selected from the token bucket and assigned to the microservice request. The token indicates that the microservice request has the permission to be added to the request queue.

[0140] Add the microservice request to the request queue.

[0141] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0142] If there is no token in the token bucket, the microservice request is rejected.

[0143] In one embodiment, the request queue includes a normal queue and a priority queue; when the computer program is executed by the processor, the following steps are also implemented:

[0144] Based on the key value, query the corresponding priority of the microservice request;

[0145] If the corresponding priority of the microservice request is found, the microservice request is added to the priority queue; if the corresponding priority of the microservice request is not found, the microservice request is added to the ordinary queue.

[0146] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0147] In response to the overload protection configuration operation, a triplet for configuring overload protection is obtained and written into the overload protection configuration file; the triplet includes a uniform resource identifier, a request method, and an overload protection identifier. The overload protection configuration file is used for querying the corresponding overload protection identifier of the microservice request based on the key value.

[0148] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0149] In response to the priority configuration operation, a triplet for configuring the priority is obtained and written into a priority configuration file; the triplet includes a uniform resource identifier, a request method, and a priority, and the priority configuration file is used for querying the corresponding priority of the microservice request based on the key value.

[0150] In one embodiment, there is a quantity ratio configuration relationship between the common queue and the priority queue when processing microservice requests; when the computer program is executed by the processor, the following steps are also implemented:

[0151] In the process of taking out microservice requests from the ordinary queue and the priority queue for processing, according to the quantity ratio configuration relationship, the corresponding number of microservice requests in the priority queue are processed first, and then the corresponding number of microservice requests in the ordinary queue are processed.

[0152] In one embodiment, a computer program product is provided, comprising a computer program, which, when executed by a processor, implements the following steps:

[0153] When a microservice request is received, obtain the requested uniform resource identifier and the request method used;

[0154] The result of integrating the uniform resource identifier and the request method is used as the key value, and based on the key value, the corresponding overload protection flag of the microservice request is queried;

[0155] When the overload protection identifier corresponding to the microservice request is queried, it is determined that no token needs to be allocated for the microservice request, and the microservice request is added to the request queue; the request queue is used to provide the microservice request for processing.

[0156] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0157] If the overload protection flag corresponding to the microservice request is not found, if there is a token in the token bucket, a token is selected from the token bucket and assigned to the microservice request. The token indicates that the microservice request has the permission to be added to the request queue.

[0158] Add the microservice request to the request queue.

[0159] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0160] If there is no token in the token bucket, the microservice request is rejected.

[0161] In one embodiment, the request queue includes a normal queue and a priority queue; when the computer program is executed by the processor, the following steps are also implemented:

[0162] Based on the key value, query the corresponding priority of the microservice request;

[0163] If the corresponding priority of the microservice request is found, the microservice request is added to the priority queue; if the corresponding priority of the microservice request is not found, the microservice request is added to the ordinary queue.

[0164] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0165] In response to the overload protection configuration operation, a triplet for configuring overload protection is obtained and written into the overload protection configuration file; the triplet includes a uniform resource identifier, a request method, and an overload protection identifier. The overload protection configuration file is used for querying the corresponding overload protection identifier of the microservice request based on the key value.

[0166] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0167] In response to the priority configuration operation, a triplet for configuring the priority is obtained and written into a priority configuration file; the triplet includes a uniform resource identifier, a request method, and a priority, and the priority configuration file is used for querying the corresponding priority of the microservice request based on the key value.

[0168] In one embodiment, there is a quantity ratio configuration relationship between the common queue and the priority queue when processing microservice requests; when the computer program is executed by the processor, the following steps are also implemented:

[0169] In the process of taking out microservice requests from the ordinary queue and the priority queue for processing, according to the quantity ratio configuration relationship, the corresponding number of microservice requests in the priority queue are processed first, and then the corresponding number of microservice requests in the ordinary queue are processed.

[0170] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0171] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0172] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A method for limiting request flow, characterized in that: The method comprises: When a microservice request is received, obtain the requested uniform resource identifier and the request method used; Using the integration result of the uniform resource identifier and the request method as the key value, and querying the overload protection identifier corresponding to the microservice request based on the key value; When an overload protection identifier corresponding to the microservice request is queried, it is determined that no token needs to be allocated for the microservice request, and the microservice request is added to a request queue; the request queue is used to provide microservice requests for processing.

2. The method according to claim 1, characterized in that The method further comprises: In the case where the overload protection identifier corresponding to the microservice request is not found, if there is a token in the token bucket, a token is selected from the token bucket and allocated to the microservice request, and the token indicates that the microservice request has the permission to be added to the request queue; Add the microservice request to the request queue.

3. The method according to claim 2, characterized in that The method further comprises: If there is no token in the token bucket, the microservice request is rejected.

4. The method according to claim 1 or 2, characterized in that: The request queue includes a common queue and a priority queue; adding the microservice request to the request queue includes: Based on the key value, query the corresponding priority of the microservice request; If the priority level corresponding to the microservice request is found, the microservice request is added to the priority queue; if the priority level corresponding to the microservice request is not found, the microservice request is added to the common queue.

5. The method according to claim 1, characterized in that The method further comprises: In response to the overload protection configuration operation, a triplet for configuring overload protection is obtained and written into an overload protection configuration file; the triplet includes a uniform resource identifier, a request method, and an overload protection identifier, and the overload protection configuration file is used for querying the corresponding overload protection identifier of the microservice request based on the key value.

6. The method according to claim 4, characterized in that The method further comprises: In response to the priority configuration operation, a triplet for configuring the priority is obtained and written into a priority configuration file; the triplet includes a uniform resource identifier, a request method, and a priority, and the priority configuration file is used for querying the corresponding priority of the microservice request based on the key value.

7. The method according to claim 4, characterized in that There is a quantity ratio configuration relationship between the common queue and the priority queue when processing microservice requests; the method further includes: In the process of taking out microservice requests from the common queue and the priority queue for processing, a corresponding number of microservice requests in the priority queue are preferentially processed according to the quantity ratio configuration relationship, and then a corresponding number of microservice requests in the common queue are processed.

8. A request flow limiting device, characterized in that: The device comprises: The acquisition module is used to obtain the requested uniform resource identifier and the request method used when receiving a microservice request; A query module, used to use the integration result of the uniform resource identifier and the request method as a key value, and query the overload protection identifier corresponding to the microservice request based on the key value; The adding module is used to determine that it is not necessary to allocate a token for the microservice request when the overload protection identifier corresponding to the microservice request is queried, and add the microservice request to the request queue; the request queue is used to provide microservice requests for processing.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images