Request processing method and apparatus, and device and storage medium

Abstract

Provided in the present application are a request processing method and apparatus, and a device and a storage medium. The method comprises: when it is detected that a downstream service is overloaded, acquiring request volume data of at least one upstream service for the downstream service; determining a target upstream service from the at least one upstream service on the basis of the request volume data; determining a target rate limit value of the target upstream service; and on the basis of the target rate limit value, processing the request volume of the target upstream service for the downstream service. The present application can effectively protect the downstream services in a calling link, and avoid the problem of downstream services being incapable of operating normally when the downstream services are overloaded, such that the performance of the downstream services can be improved.

Description

Request processing method, device, equipment and storage medium

[0001] This application claims priority to the Chinese invention patent application entitled “Request processing method, apparatus, device and storage medium” and application number 202410339316.7, filed on March 22, 2024. The entire contents of that application are incorporated by reference into this application. Technical Field

[0002] The embodiments of the present application relate to the field of Internet technology, and in particular to a request processing method, apparatus, device, and storage medium. Background Art

[0003] Current limiting is a common overload protection measure. When traffic increases, limiting requests can effectively prevent system overload. Related technologies use a method called current limiting based on the service's own central processing unit (CPU) metrics, queue time, and other factors. However, this current limiting method is only suitable for protecting upstream services themselves and cannot effectively protect downstream services in the call chain, resulting in malfunctions when downstream services are overloaded. Summary of the Invention

[0004] The embodiments of the present application provide a request processing method, apparatus, device, and storage medium, which can effectively protect downstream services in the call link, avoid the situation where downstream services cannot work normally when overloaded, and thus improve the performance of downstream services.

[0005] In a first aspect, an embodiment of the present application provides a request processing method, including:

[0006] When a downstream service is detected to be overloaded, obtaining request volume data of at least one upstream service for the downstream service;

[0007] determining a target upstream service from at least one upstream service according to the request volume data;

[0008] Determine a target flow limit value for the target upstream service;

[0009] The request volume of the target upstream service for the downstream service is processed according to the target current limit value.

[0010] In a second aspect, an embodiment of the present application provides a request processing device, including:

[0011] A data acquisition module, configured to acquire request volume data of at least one upstream service for the downstream service when an overload of the downstream service is detected;

[0012] a service determination module, configured to determine a target upstream service from at least one upstream service according to the request volume data;

[0013] A current limiting determination module, configured to determine a target current limiting value for the target upstream service;

[0014] The request control module is used to process the request volume of the target upstream service for the downstream service according to the target current limit value.

[0015] In a third aspect, an embodiment of the present application provides an electronic device, including:

[0016] A processor and a memory, the memory being used to store a computer program, and the processor being used to call and run the computer program stored in the memory to execute the request processing method as described in the embodiment of the first aspect.

[0017] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium for storing a computer program, wherein the computer program enables a computer to execute the request processing method as described in the embodiment of the first aspect.

[0018] In a fifth aspect, an embodiment of the present application provides a computer program product comprising program instructions. When the program instructions are executed on an electronic device, the electronic device executes the request processing method as described in the embodiment of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0020] FIG1 is a flowchart of a request processing method provided in an embodiment of the present application;

[0021] FIG2 is a flowchart of another request processing method provided in an embodiment of the present application;

[0022] FIG3 is an exemplary schematic diagram of a specific request processing provided in an embodiment of the present application;

[0023] FIG4 is a schematic block diagram of a request processing device provided in an embodiment of the present application;

[0024] FIG5 is a schematic block diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0025] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0026] It should be noted that the terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products, or devices.

[0027] In the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or solution described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or solutions. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0028] In the description of the embodiments of this application, unless otherwise specified, "a plurality of" refers to two or more than two, i.e., at least two. "at least one" refers to one or more than one. "Any" refers to any one or any several.

[0029] Normally, limiting the flow of requests can effectively prevent system overload. In related technologies, flow limiting can be performed based on the service's own CPU indicators, sorting time, etc. However, this flow limiting method is only suitable for scenarios that protect the upstream service itself, and cannot effectively protect downstream services in the call link, resulting in the downstream service not being able to work properly when overloaded, thereby affecting the performance of the downstream service. In order to solve the above technical problems, the present application provides a request processing method, apparatus, device and storage medium that can effectively protect downstream services in the call link, avoid the situation where downstream services cannot work properly when overloaded, and thus improve the performance of downstream services.

[0030] The technical solution disclosed in the embodiment of the present application obtains request volume data of at least one upstream service for the downstream service when a downstream service overload is detected, so as to determine the target upstream service from the at least one upstream service based on the request volume data, and then determine the target flow limit value for the target upstream service, and process the request volume of the target upstream service for the downstream service according to the target flow limit value. The present application determines the target upstream service that causes the overload of the downstream service based on the request volume data of the upstream service, and then determines the target flow limit value of the target upstream service, and then limits the request volume of the target upstream service according to the target flow limit value, thereby effectively protecting the downstream service in the call link, avoiding the situation where the downstream service cannot work normally when it is overloaded, and thus improving the performance of the downstream service.

[0031] The technical solution of the present application is described in detail below through some embodiments. The embodiments described below can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0032] Figure 1 is a flow chart of a request processing method provided by an embodiment of the present application. The embodiment of the present application can be applied to downstream service scenarios in the protection call chain. The request processing method can be executed by a request processing device, which can be composed of hardware and / or software and can be integrated into an electronic device. In the present application, the electronic device can be a server, etc., but is not limited to this. Among them, the server can be a single server or a server cluster, etc., and no restrictions are imposed on it here.

[0033] As shown in FIG1 , the method may include the following steps:

[0034] S101 , when a downstream service is detected to be overloaded, obtaining request volume data of at least one upstream service for the downstream service.

[0035] In this application, the downstream service can be one downstream service or multiple downstream services, etc., which is not limited here.

[0036] Considering that the overload protection implementation principle for each downstream service is the same, in order to clearly illustrate the present application, a downstream service is used as an example for specific explanation in the following embodiment.

[0037] In some optional embodiments, during the operation of a downstream service in any system, whether the downstream service is overloaded can be detected based on an overload detection indicator. When the downstream service is detected to be overloaded, data on the amount of requests sent by at least one upstream service to the downstream service can be obtained from the request statistics module, so as to determine the upstream service that caused the overload of the downstream service based on the data on the amount of requests sent by the at least one upstream service to the downstream service.

[0038] The request statistics module is used to collect and store request volume data of downstream services. The downstream services themselves will count the request volume data sent by different upstream services and regularly send the counted request volume data to the request statistics module so that the request statistics module can record the data information of downstream services requested by upstream services.

[0039] In this application, "regularly" can be understood as a preset period, and this preset period is an adjustable parameter that can be set according to actual request statistics needs and is not restricted here. For example, assuming the preset period is 30 seconds, the downstream service can automatically send the request volume data sent by different upstream services to the request statistics module every 30 seconds.

[0040] It should be understood that the request volume data is the number of requests sent by the upstream service to the downstream service.

[0041] In some optional embodiments, the present application detects whether the downstream service is overloaded based on an overload detection indicator, specifically based on the central processing unit (CPU) occupancy rate, request timeout rate and / or request failure rate of the downstream service.

[0042] As an optional implementation, detecting whether a downstream service is overloaded may include the following steps based on the CPU usage, request timeout rate, and / or request failure rate of the downstream service:

[0043] Step 1: Determine whether the CPU usage of the downstream service is greater than a first threshold, whether the request timeout rate is greater than a second threshold, and / or whether the request failure rate is greater than a third threshold.

[0044] Step 2: If the CPU usage of the downstream service is greater than a first threshold, the request timeout rate is greater than a second threshold, and / or the request failure rate is greater than a third threshold, then determine that the downstream service is overloaded.

[0045] Step three: if the CPU usage of the downstream service is less than or equal to the first threshold, the request timeout rate is less than or equal to the second threshold, and the request failure rate is less than or equal to the third threshold, then it is determined that the downstream service is not overloaded.

[0046] The first threshold, the second threshold, and the third threshold can be set according to the performance of the downstream service, and this application does not impose any restrictions on this. In other words, the first threshold, the second threshold, and the third threshold are adjustable parameters.

[0047] It should be understood that the above request timeout rate refers to the ratio of the downstream service being unable to respond to the upstream service request within a period of time. In addition, the request timeout rate can be calculated using the following formula:

[0048] Request timeout rate = (number of request timeouts / total number of requests) * 100%.

[0049] The number of request timeouts refers to the number of timeouts that occurred in upstream service requests within a period of time; the total number of requests refers to the total number of requests sent by the upstream service within the above period of time.

[0050] For example, suppose an upstream service sends a total of 100 call requests to downstream service F1 within time period X1, and 20 of them time out.

[0051] In addition, the request failure rate mentioned above refers to the ratio of upstream services failing to request downstream services within a period of time. And, the request failure rate can be calculated using the following formula:

[0052] Request failure rate = (number of failed requests / total number of requests) * 100%.

[0053] The number of request failures refers to the number of failures that occurred in upstream service requests within a period of time; the total number of requests refers to the total number of requests sent by the upstream service within the above period of time.

[0054] For example, suppose an upstream service sends a total of 200 call requests to downstream service F1 within time period X1, and 10 of them fail.

[0055] S102: Determine a target upstream service from at least one upstream service according to the request volume data.

[0056] The above target upstream service can be understood as an abnormal upstream service.

[0057] In some optional embodiments, the present application may determine the total request volume data sent by each upstream service in at least one upstream service to the downstream service within the first time period from the acquired request volume data of at least one upstream service for the downstream service. Afterwards, the total request volume data corresponding to each upstream service is sorted in descending order to obtain a sorting result. Furthermore, a preset number of upstream services are selected from the sorting result, and the selected upstream services are determined as candidate upstream services. The preset number can be flexibly set according to the number of at least one upstream service, and there is no restriction on it here.

[0058] It can be understood that the number of the above candidate upstream services is at least one.

[0059] The first time period described above can be understood as the target time period. Furthermore, the target time period can be flexibly set based on the target upstream service detection requirements and is not subject to any restrictions herein. In other words, the target time period is an adjustable parameter. For example, the target time period can be set to 30 seconds, 50 seconds, or 1 minute, etc.

[0060] After determining at least one candidate upstream service, the present application may determine a target upstream service from the at least one candidate upstream service according to a preset method, wherein the preset method may be any screening method for determining a target upstream service from the candidate upstream services, and is not limited thereto.

[0061] As an optional implementation, in determining the target upstream service from at least one candidate upstream service, the total request volume data corresponding to each candidate upstream service can be compared with a preset value to determine which candidate upstream services have total request volume data exceeding the preset value and which candidate upstream services have total request volume data that does not exceed the preset value. Furthermore, the candidate upstream service whose total request volume data exceeds the preset value is determined as the target upstream service.

[0062] The preset value can be calculated by averaging the total number of requests sent by each upstream service to the downstream service over at least two historical time periods, and using the average value as the preset value corresponding to each upstream service. The historical time period is a time period of the same length as the first time period.

[0063] For example, assuming the first time period is 30 seconds, a first historical time period and a second historical time period, each 30 seconds long, can be determined. Then, historical total request volume data 100 sent by upstream service W1 to downstream service F1 during the first historical time period, and historical total request volume data 102 sent by upstream service W1 to downstream service F1 during the second historical time period, can be obtained. Then, based on the historical total request volume data 100 corresponding to the first historical time period and the historical total request volume data 102 corresponding to the second historical time period, the preset value corresponding to the first time period and upstream service W1 can be calculated as (100+102) / 2=101.

[0064] That is, the present application can calculate the preset value corresponding to each upstream service based on the historical total request volume data of each upstream service in at least two historical time periods.

[0065] In some optional embodiments, considering that the aforementioned request volume data is obtained when a downstream service overload is detected, it may be the request volume data for the same downstream service from all upstream services that communicate with the downstream service. Therefore, when the present application determines the target upstream service, it is optional to obtain the total request volume data sent by each upstream service in all upstream services to the downstream service within the first time period from the obtained request volume data. Then, based on the total request volume data, determine which upstream services have a substantial increase in requests sent to the downstream service. Furthermore, the upstream service corresponding to the substantial increase in requests is determined as the target upstream service.

[0066] For example, assuming that the downstream service F1 has three upstream services, namely upstream service W1, upstream service W2 and upstream service W3, then from the obtained request volume data, the total request volume data sent by upstream service W1 to downstream service F1 in the last minute (min) (i.e., the target time period) is 100 times, the total request volume data sent by upstream service W2 to downstream service F1 is 102 times, and the total request volume data sent by upstream service W3 to downstream service F1 is 800 times. If it is determined that the total request volume data sent by upstream service W1 to downstream service F1 in the previous minute adjacent to the last minute and before the last minute is 101 times, If the total request volume data sent by W2 to downstream service F1 is 100 times and the total request volume data sent by upstream service W3 to downstream service F1 is 101 times, and the total request volume data sent by upstream service W1 to downstream service F1 in the previous minute adjacent to and before the previous minute is 99 times, the total request volume data sent by upstream service W2 to downstream service F1 is 105, and the total request volume data sent by upstream service W3 to downstream service F1 is 98, it can be determined that the total request volume data sent by upstream service W3 to downstream service F1 in the last minute has increased significantly compared to the total request volume data sent in the previous minute and the minute before that. At this time, upstream service W3 can be determined as the target upstream service.

[0067] In other optional embodiments, when the present application determines the target upstream service, it may optionally determine the total request volume data sent by each upstream service among all upstream services to the downstream service within the first time period based on the acquired request volume data. Thereafter, it is determined whether the total request volume data sent by each upstream service among all upstream services to the downstream service within the first time period exceeds a preset value. If the total request volume data sent by any upstream service among all upstream services to the downstream service within the first time period exceeds a preset value, the upstream service is determined to be the target upstream service. If the total request volume data sent by any upstream service among all upstream services to the downstream service within the first time period does not exceed the preset value, the upstream service is determined to be a normal upstream service.

[0068] It should be understood that the above-mentioned preset value is set in the same manner as the preset value in determining the target upstream service from the candidate upstream services.

[0069] S103: Determine a target current limit value for the target upstream service.

[0070] In some optional embodiments, the maximum successful request volume data of the target upstream service in the second time period can be obtained from the request statistics module, and the maximum successful request volume data can be determined as the target flow limit value of the target upstream service.

[0071] The second time period may be any historical time period of the same length as the first time period, or any historical time period of a different length from the first time period, and this application does not impose any specific restrictions on this.

[0072] In addition, the maximum successful request volume data refers to the request data volume that the downstream service successfully responds to the request sent by the upstream service within a certain period of time.

[0073] For example, assuming that upstream service W3 is determined to be the target upstream service, the maximum successful request volume data 150 of the target upstream service W3 in the past three days can be obtained from the request statistics module, and the maximum successful request volume data 150 can be determined as the target flow limit value of the target upstream service W3.

[0074] S104: Process the request volume of the target upstream service for the downstream service according to the target current limit value.

[0075] The processing of the request volume of the target upstream service to the downstream service can be understood as performing flow limiting processing on the request volume of the target upstream service to the downstream service.

[0076] In some optional embodiments, the present application may adjust the flow limit value of the downstream service for the target upstream service according to the target flow limit value, so that the downstream service limits the request volume of the target upstream service for the downstream service based on the target flow limit value.

[0077] For example, assuming the target upstream service is upstream service W3, and the target rate limit value of target upstream service W3 is 150, then when the original rate limit value of downstream service F1 for target upstream service W3 is 180, the original rate limit value 180 of target upstream service W3 can be adjusted to the target rate limit value 150. Then, the rate limit of the target upstream service W3 for downstream service F1 is implemented according to the target rate limit value 150, thereby alleviating the overload of downstream service F1.

[0078] The technical solution disclosed in the embodiment of the present application obtains request volume data of at least one upstream service for the downstream service when a downstream service overload is detected, so as to determine the target upstream service from the at least one upstream service based on the request volume data, and then determine the target flow limit value for the target upstream service, and process the request volume of the target upstream service for the downstream service according to the target flow limit value. The present application determines the target upstream service that causes the overload of the downstream service based on the request volume data of the upstream service, and then determines the target flow limit value of the target upstream service, and then limits the request volume of the target upstream service according to the target flow limit value, thereby effectively protecting the downstream service in the call link, avoiding the situation where the downstream service cannot work normally when it is overloaded, and thus improving the performance of the downstream service.

[0079] The request processing method provided by the embodiment of the present application is further explained below in conjunction with Figure 2. As shown in Figure 2, after step S104 shown in Figure 1, the following steps S201 to S203 are also included:

[0080] S201, detect whether the downstream service is overloaded according to a preset period, if the downstream service is not overloaded, execute step S202, if the downstream service is overloaded, execute step S203.

[0081] S202: If the downstream service is not overloaded, continue to process the request volume of the target upstream service for the downstream service according to the target current limit value.

[0082] S203: If the downstream service is overloaded, a current limiting optimization step is performed to process the request volume of the target upstream service for the downstream service.

[0083] In this application, the preset period can be set according to the overload detection requirements of the downstream service. For example, the preset period can be set to 10 seconds or 20 seconds, etc. This application does not impose any restrictions on this.

[0084] After processing the target upstream service's request volume for the downstream service based on the target current limit, the present application can periodically detect whether the downstream service is overloaded according to a preset period to detect whether the overload condition of the downstream service has been alleviated. The specific implementation of detecting whether the downstream service is overloaded can be found in step S101 of the aforementioned embodiment, and will not be elaborated on here.

[0085] If the downstream service's overload condition is detected to have been alleviated, that is, the downstream service is not overloaded, it indicates that the downstream service can normally respond to requests sent by the upstream service. At this time, the target upstream service's request volume to the downstream service will continue to be limited according to the target limit value. If the downstream service's overload condition is detected to have not been alleviated, that is, the downstream service is still in an overloaded state, it indicates that the downstream service may not be able to operate normally. In this case, it is necessary to continue to optimize the request volume of the target upstream service to alleviate the overload condition of the downstream service.

[0086] In some optional embodiments, performing flow limiting optimization on the request volume of the target upstream service may include the following steps:

[0087] Step S1: Taking the target current limiting value as the current current limiting value, and determining a new target current limiting value according to the current current limiting value and the current limiting optimization parameter.

[0088] In this application, the new target current limit value is determined based on the current current limit value and the current limit optimization parameter, which can be achieved by the following formula: lim it QPS'=lim it QPS*a

[0089] Wherein, lim it QPS' is the new target current limit value, lim it QPS is the current current limit value, a is the current limit optimization parameter, and a is an adjustable parameter, such as 0.9 or 0.8.

[0090] It should be understood that the query per second (QPS) refers to the number of requests that a downstream service can process within a certain period of time.

[0091] Step S2: Process the request volume of the target upstream service for the downstream service according to the new target current limit value.

[0092] Step S3: Check whether the downstream service is overloaded according to a preset period.

[0093] Step S4: If the downstream service is not overloaded, continue to process the request volume of the target upstream service for the downstream service according to the new target current limit value.

[0094] Step S5: If the downstream service is overloaded, continue to perform the current limiting optimization step until it is detected that the downstream service is not overloaded.

[0095] The current limiting optimization step is continued, specifically, steps S1 to S5 are executed.

[0096] The technical solution disclosed in the embodiment of the present application obtains request volume data of at least one upstream service for the downstream service when a downstream service overload is detected, so as to determine the target upstream service from the at least one upstream service based on the request volume data, and then determine the target flow limit value for the target upstream service, and process the request volume of the target upstream service for the downstream service according to the target flow limit value. The present application determines the target upstream service that causes the overload of the downstream service based on the request volume data of the upstream service, and then determines the target flow limit value of the target upstream service, and then flows the flow limit of the request volume of the target upstream service according to the target flow limit value, thereby effectively protecting the downstream service in the call link, avoiding the situation where the downstream service cannot work normally when it is overloaded, and thus improving the performance of the downstream service.

[0097] In order to more clearly illustrate the request processing method provided in the embodiment of the present application, an exemplary description is given below in conjunction with FIG3 , as follows:

[0098] As shown in Figure 3, assume that an online system includes a downstream service D and three upstream services, namely upstream services A, B, and C. As upstream services A, B, and C send requests to downstream service D, the system checks whether downstream service D is overloaded based on CPU usage, request timeout rate, and / or request failure rate, every 30 seconds. If downstream service D is determined to be overloaded, the system determines the total number of requests sent by upstream services A, B, and C to downstream service D over the last 50 seconds based on the request volume data sent by upstream services A, B, and C to downstream service D.

[0099] Then, based on the total request volume data sent by upstream services A, B, and C to downstream service D in the last 50 seconds, the upstream service experiencing traffic anomaly among upstream services A, B, and C is determined. If it is determined that the total request volume data sent by upstream service C to downstream service D in the last 50 seconds is greater than a preset value, and the total request volume data sent by upstream services A and B to downstream service D in the last 50 seconds is less than or equal to the preset value, upstream service C is determined to be the target upstream service.

[0100] At this point, the maximum successful request volume data 90 within the past two days is obtained from the historical request volume data sent by the target upstream service C to the downstream service D. This maximum successful request volume data 90 is determined as the target rate limit value for the target upstream service C. The rate of requests from the target upstream service C to the downstream service D is then limited based on the target rate limit value 90.

[0101] After limiting the request volume of the target upstream service C according to the target flow limit value 90, continue to detect whether the downstream service D is still overloaded according to the CPU occupancy rate, request timeout rate and / or request failure rate according to the preset period of 30 seconds. If the downstream service D is still overloaded, the target flow limit value 90 of the target upstream service C is used as the current flow limit value, and the new target flow limit value for the target upstream service C is calculated based on the current flow limit value and the flow limit optimization parameters, such as 90*0.9=81. Then, based on the new target flow limit value 81, the request volume of the target upstream service C is limited. In addition, continue to detect whether the downstream service D is still overloaded according to the CPU occupancy rate, request timeout rate and / or request failure rate according to the preset period of 30 seconds. If the downstream service D is not overloaded, continue to limit the request volume of the target upstream service C according to the new target flow limit value 81.

[0102] That is to say, according to the request processing method provided in the embodiment of the present application, when the downstream service is overloaded, the source of the abnormal traffic can be automatically analyzed and the source of the abnormal traffic can be limited, thereby effectively protecting the downstream services in the call link and avoiding the situation where the downstream service cannot work normally when it is overloaded, thereby improving the performance of the downstream service.

[0103] A request processing device proposed in an embodiment of the present application will be described below with reference to FIG4 . As shown in FIG4 , the request processing device 400 includes: a data acquisition module 410 , a service determination module 420 , a current limiting determination module 430 , and a request control module 440 .

[0104] The data acquisition module 410 is configured to acquire request volume data of at least one upstream service for the downstream service when an overload of the downstream service is detected;

[0105] A service determination module 420 is configured to determine a target upstream service from at least one upstream service based on the request volume data;

[0106] A current limiting determination module 430 is configured to determine a target current limiting value for the target upstream service;

[0107] The request control module 440 is configured to process the request volume of the target upstream service for the downstream service according to the target current limit value.

[0108] In an optional implementation of the embodiment of the present application, the service determination module 420 includes:

[0109] A first determining unit is configured to determine, based on the request volume data, total request volume data sent by at least one upstream service to the downstream service within a first time period, and determine at least one candidate upstream service;

[0110] The second determining unit is configured to determine a target upstream service from at least one candidate upstream service.

[0111] In an optional implementation method of an embodiment of the present application, the second determination unit is specifically used to: determine whether the total request volume data sent by at least one of the candidate upstream services to the downstream service within the first time period exceeds a preset value; if the total request volume data sent by any of the candidate upstream services to the downstream service within the first time period exceeds the preset value, then determine that the candidate upstream service is the target upstream service.

[0112] In an optional implementation of the embodiment of the present application, when the request volume data corresponds to each of the upstream services in all upstream services, the service determination module 420 is specifically configured to:

[0113] Determine, based on each of the request volume data, total request volume data sent by each of the upstream services in all upstream services to the downstream service within a first time period;

[0114] Determining whether a total amount of request data sent by each of the upstream services to the downstream service within a first time period exceeds a preset value;

[0115] If the total request volume data sent by any upstream service among all upstream services to the downstream service within the first time period exceeds a preset value, the upstream service is determined to be the target upstream service.

[0116] In an optional implementation of the embodiment of the present application, the current limiting determination module 430 is specifically configured to:

[0117] Obtain data on a maximum number of successful requests to the target upstream service within a second time period;

[0118] The maximum successful request amount data is determined as the target flow limit value of the target upstream service.

[0119] In an optional implementation of the embodiment of the present application, the request control module 440 is specifically configured to:

[0120] According to the target current limit value, the current limit value of the downstream service for the target upstream service is adjusted, so that the downstream service processes the request volume of the target upstream service for the downstream service based on the target current limit value.

[0121] In an optional implementation of the embodiment of the present application, the request processing device 400 further includes:

[0122] An overload detection module, configured to detect whether the downstream service is overloaded according to a preset period;

[0123] The request control module 440 is also used to continue to process the request volume of the target upstream service for the downstream service according to the target current limiting value if the downstream service is not overloaded; if the downstream service is overloaded, execute the current limiting optimization step to process the request volume of the target upstream service for the downstream service.

[0124] In an optional implementation of the embodiment of the present application, the request control module 440 is further configured to:

[0125] Taking the target current limiting value as the current current limiting value, and determining a new target current limiting value according to the current current limiting value and the current limiting optimization parameter;

[0126] Processing the request volume of the target upstream service for the downstream service according to the new target current limit value;

[0127] Checking whether the downstream service is overloaded according to a preset period;

[0128] If the downstream service is not overloaded, the request volume of the target upstream service for the downstream service continues to be processed according to the new target current limit value; otherwise, the current limit optimization step continues to be executed until it is detected that the downstream service is not overloaded.

[0129] In an optional implementation of the embodiment of the present application, the overload detection module includes:

[0130] a third determining unit, configured to determine whether a CPU occupancy rate of the downstream service is greater than a first threshold, whether a request timeout rate is greater than a second threshold, and / or whether a request failure rate is greater than a third threshold;

[0131] The fourth determining unit is configured to determine that the downstream service is overloaded if the CPU occupancy rate of the downstream service is greater than a first threshold, the request timeout rate is greater than a second threshold, and / or the request failure rate is greater than a third threshold.

[0132] It should be understood that the device embodiment and the aforementioned method embodiment may correspond to each other, and similar descriptions can refer to the method embodiment. To avoid repetition, no further description is given here. Specifically, the device 400 shown in FIG4 can execute the method embodiment corresponding to FIG1, and the aforementioned and other operations and / or functions of each module in the device 400 are respectively for implementing the corresponding processes in each method in FIG1. ​​For the sake of brevity, no further description is given here.

[0133] The above describes the device 400 of the embodiment of the present application from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that the functional module can be implemented in hardware form, can be implemented by instructions in software form, and can also be implemented by a combination of hardware and software modules. Specifically, the steps of the first aspect method embodiment in the embodiment of the present application can be completed by the hardware integrated logic circuit and / or software form instructions in the processor, and the steps of the first aspect method disclosed in conjunction with the embodiment of the present application can be directly embodied as being executed by a hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. Optionally, the software module can be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps in the above-mentioned first aspect method embodiment in conjunction with its hardware.

[0134] FIG5 is a schematic block diagram of an electronic device provided in an embodiment of the present application. The electronic device in the present application includes a first server and a second server. As shown in FIG5 , the electronic device 500 may include:

[0135] The memory 510 and the processor 520 are configured to store a computer program and transmit the program code to the processor 520. In other words, the processor 520 can call and run the computer program from the memory 510 to implement the request processing method of the first aspect of the embodiment of the present application.

[0136] For example, the processor 520 may be configured to execute the above-mentioned request processing method according to instructions in the computer program.

[0137] In some optional embodiments, the request processing method includes:

[0138] When a downstream service is detected to be overloaded, obtaining request volume data of at least one upstream service for the downstream service;

[0139] determining a target upstream service from at least one upstream service according to the request volume data;

[0140] Determine a target current limit value for the target upstream service;

[0141] The request volume of the target upstream service for the downstream service is processed according to the target current limit value.

[0142] In some optional embodiments, determining a target upstream service from at least one upstream service based on the request volume data includes:

[0143] Determine, based on the request volume data, total request volume data sent by at least one upstream service to the downstream service within a first time period, and determine at least one candidate upstream service;

[0144] A target upstream service is determined from at least one of the candidate upstream services.

[0145] In some optional embodiments, determining a target upstream service from at least one candidate upstream service includes:

[0146] Determining whether a total request volume data sent by at least one of the candidate upstream services to the downstream service within a first time period exceeds a preset value;

[0147] If the total request volume data sent by any candidate upstream service to the downstream service within the first time period exceeds the preset value, the candidate upstream service is determined to be the target upstream service.

[0148] In some optional embodiments, when the request volume data corresponds to each of the upstream services in all upstream services, determining a target upstream service from at least one upstream service based on the request volume data includes:

[0149] Determine, based on each of the request volume data, total request volume data sent by each of the upstream services in all upstream services to the downstream service within a first time period;

[0150] Determining whether a total amount of request data sent by each of the upstream services to the downstream service within a first time period exceeds a preset value;

[0151] If the total request volume data sent by any upstream service among all upstream services to the downstream service within the first time period exceeds a preset value, the upstream service is determined to be the target upstream service.

[0152] In some optional embodiments, determining the target current limit value of the target upstream service includes:

[0153] Obtain data on a maximum number of successful requests to the target upstream service within a second time period;

[0154] The maximum successful request amount data is determined as the target flow limit value of the target upstream service.

[0155] In some optional embodiments, processing the request volume of the target upstream service for the downstream service according to the target current limit value includes:

[0156] According to the target current limit value, the current limit value of the downstream service for the target upstream service is adjusted, so that the downstream service processes the request volume of the target upstream service for the downstream service based on the target current limit value.

[0157] In some optional embodiments, the method further comprises:

[0158] Checking whether the downstream service is overloaded according to a preset period;

[0159] If the downstream service is not overloaded, continue to process the request volume of the target upstream service for the downstream service according to the target current limit value;

[0160] If the downstream service is overloaded, a current limiting optimization step is performed to process the request volume of the target upstream service for the downstream service.

[0161] In some optional embodiments, the current limiting optimization step includes:

[0162] Taking the target current limiting value as the current current limiting value, and determining a new target current limiting value according to the current current limiting value and the current limiting optimization parameter;

[0163] Processing the request volume of the target upstream service for the downstream service according to the new target current limit value;

[0164] Checking whether the downstream service is overloaded according to a preset period;

[0165] If the downstream service is not overloaded, the request volume of the target upstream service for the downstream service continues to be processed according to the new target current limit value; otherwise, the current limit optimization step continues to be executed until it is detected that the downstream service is not overloaded.

[0166] In some optional embodiments, the method further comprises:

[0167] Determining whether a CPU occupancy rate of the downstream service is greater than a first threshold, whether a request timeout rate is greater than a second threshold, and / or whether a request failure rate is greater than a third threshold;

[0168] If the CPU occupancy rate of the downstream service is greater than a first threshold, the request timeout rate is greater than a second threshold, and / or the request failure rate is greater than a third threshold, it is determined that the downstream service is overloaded.

[0169] In some embodiments of the present application, the processor 520 may include but is not limited to:

[0170] General-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0171] In some embodiments of the present application, the memory 510 includes but is not limited to:

[0172] Volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM bus random access memory (DR RAM).

[0173] In some embodiments of the present application, the computer program may be divided into one or more modules, which are stored in the memory 510 and executed by the processor 520 to implement the request processing method provided by the present application. The one or more modules may be a series of computer program instruction segments capable of implementing specific functions, and the instruction segments are used to describe the execution process of the computer program in the electronic device.

[0174] As shown in FIG5 , the electronic device 500 may further include:

[0175] The transceiver 530 may be connected to the processor 520 or the memory 510 .

[0176] The processor 520 may control the transceiver 530 to communicate with other devices. Specifically, it may send information or data to other devices or receive information or data sent by other devices. The transceiver 530 may include a transmitter and a receiver. The transceiver 530 may further include an antenna, which may be one or more.

[0177] It should be understood that the various components in the electronic device are connected via a bus system, wherein the bus system includes not only a data bus but also a power bus, a control bus and a status signal bus.

[0178] The present application also provides a computer storage medium having a computer program stored thereon. When the computer program is executed by a computer, the computer is enabled to execute the request processing method of the first aspect method embodiment described above.

[0179] In some optional embodiments, the request processing method includes:

[0180] When a downstream service is detected to be overloaded, obtaining request volume data of at least one upstream service for the downstream service;

[0181] determining a target upstream service from at least one upstream service according to the request volume data;

[0182] Determine a target current limit value for the target upstream service;

[0183] The request volume of the target upstream service for the downstream service is processed according to the target current limit value.

[0184] In some optional embodiments, determining a target upstream service from at least one upstream service based on the request volume data includes:

[0185] Determine, based on the request volume data, total request volume data sent by at least one upstream service to the downstream service within a first time period, and determine at least one candidate upstream service;

[0186] A target upstream service is determined from at least one of the candidate upstream services.

[0187] In some optional embodiments, determining a target upstream service from at least one candidate upstream service includes:

[0188] Determining whether a total request volume data sent by at least one of the candidate upstream services to the downstream service within a first time period exceeds a preset value;

[0189] If the total request volume data sent by any candidate upstream service to the downstream service within the first time period exceeds the preset value, the candidate upstream service is determined to be the target upstream service.

[0190] In some optional embodiments, when the request volume data corresponds to each of the upstream services in all upstream services, determining a target upstream service from at least one upstream service based on the request volume data includes:

[0191] Determine, based on each of the request volume data, total request volume data sent by each of the upstream services in all upstream services to the downstream service within a first time period;

[0192] Determining whether a total amount of request data sent by each of the upstream services to the downstream service within a first time period exceeds a preset value;

[0193] If the total request volume data sent by any upstream service among all upstream services to the downstream service within the first time period exceeds a preset value, the upstream service is determined to be the target upstream service.

[0194] In some optional embodiments, determining the target current limit value of the target upstream service includes:

[0195] Obtain data on a maximum number of successful requests to the target upstream service within a second time period;

[0196] The maximum successful request amount data is determined as the target flow limit value of the target upstream service.

[0197] In some optional embodiments, processing the request volume of the target upstream service for the downstream service according to the target current limit value includes:

[0198] According to the target current limit value, the current limit value of the downstream service for the target upstream service is adjusted, so that the downstream service processes the request volume of the target upstream service for the downstream service based on the target current limit value.

[0199] In some optional embodiments, the method further comprises:

[0200] Checking whether the downstream service is overloaded according to a preset period;

[0201] If the downstream service is not overloaded, continue to process the request volume of the target upstream service for the downstream service according to the target current limit value;

[0202] If the downstream service is overloaded, a current limiting optimization step is performed to process the request volume of the target upstream service for the downstream service.

[0203] In some optional embodiments, the current limiting optimization step includes:

[0204] Taking the target current limiting value as the current current limiting value, and determining a new target current limiting value according to the current current limiting value and the current limiting optimization parameter;

[0205] Processing the request volume of the target upstream service for the downstream service according to the new target current limit value;

[0206] Checking whether the downstream service is overloaded according to a preset period;

[0207] If the downstream service is not overloaded, the request volume of the target upstream service for the downstream service continues to be processed according to the new target current limit value; otherwise, the current limit optimization step continues to be executed until it is detected that the downstream service is not overloaded.

[0208] In some optional embodiments, the method further comprises:

[0209] Determining whether a CPU occupancy rate of the downstream service is greater than a first threshold, whether a request timeout rate is greater than a second threshold, and / or whether a request failure rate is greater than a third threshold;

[0210] If the CPU occupancy rate of the downstream service is greater than a first threshold, the request timeout rate is greater than a second threshold, and / or the request failure rate is greater than a third threshold, it is determined that the downstream service is overloaded.

[0211] When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a digital video disc (DVD)), or a semiconductor medium (e.g., a solid state drive (SSD)).

[0212] Those skilled in the art will appreciate that the modules and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0213] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules is merely a logical function division. In actual implementation, there may be other division methods, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0214] Modules described as separate components may or may not be physically separate, and components displayed as modules may or may not be physical modules, i.e., they may be located in one place or distributed across multiple network elements. Some or all of the modules may be selected based on actual needs to achieve the purpose of the present embodiment. For example, the functional modules in the various embodiments of the present application may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into a single module.

[0215] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0216] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A request processing method, comprising: When a downstream service is detected to be overloaded, obtaining request volume data of at least one upstream service for the downstream service; determining a target upstream service from at least one upstream service according to the request volume data; Determine a target current limit value for the target upstream service; The request volume of the target upstream service for the downstream service is processed according to the target current limit value.

2. The method according to claim 1, wherein determining a target upstream service from at least one upstream service based on the request volume data comprises: Determine, based on the request volume data, total request volume data sent by at least one upstream service to the downstream service within a first time period, and determine at least one candidate upstream service; A target upstream service is determined from at least one of the candidate upstream services.

3. The method according to claim 2, wherein determining a target upstream service from at least one candidate upstream service comprises: Determining whether a total request volume data sent by at least one of the candidate upstream services to the downstream service within a first time period exceeds a preset value; If the total request volume data sent by any candidate upstream service to the downstream service within the first time period exceeds the preset value, the candidate upstream service is determined to be the target upstream service.

4. The method according to claim 1 , wherein when the request volume data corresponds to each of the upstream services in all upstream services, determining a target upstream service from at least one upstream service based on the request volume data comprises: Determine, based on each of the request volume data, total request volume data sent by each of the upstream services in all upstream services to the downstream service within a first time period; Determining whether a total amount of request data sent by each of the upstream services to the downstream service within a first time period exceeds a preset value; If the total request volume data sent by any upstream service among all upstream services to the downstream service within the first time period exceeds a preset value, the upstream service is determined to be the target upstream service.

5. The method according to claim 1, wherein determining the target rate limiting value of the target upstream service comprises: Obtain data on a maximum number of successful requests to the target upstream service within a second time period; The maximum successful request amount data is determined as the target flow limit value of the target upstream service.

6. The method according to claim 1, wherein processing the request volume of the target upstream service for the downstream service according to the target current limit value comprises: According to the target current limit value, the current limit value of the downstream service for the target upstream service is adjusted, so that the downstream service processes the request volume of the target upstream service for the downstream service based on the target current limit value.

7. The method according to any one of claims 1 to 6, further comprising: Checking whether the downstream service is overloaded according to a preset period; If the downstream service is not overloaded, continue to process the request volume of the target upstream service for the downstream service according to the target current limit value; If the downstream service is overloaded, a current limiting optimization step is performed to process the request volume of the target upstream service for the downstream service.

8. The method according to claim 7, wherein the current limiting optimization step comprises: Taking the target current limiting value as the current current limiting value, and determining a new target current limiting value according to the current current limiting value and the current limiting optimization parameter; Processing the request volume of the target upstream service for the downstream service according to the new target current limit value; Checking whether the downstream service is overloaded according to a preset period; If the downstream service is not overloaded, the request volume of the target upstream service for the downstream service continues to be processed according to the new target current limit value; otherwise, the current limit optimization step continues to be executed until it is detected that the downstream service is not overloaded.

9. The method according to claim 1, further comprising: Determining whether a CPU occupancy rate of the downstream service is greater than a first threshold, whether a request timeout rate is greater than a second threshold, and / or whether a request failure rate is greater than a third threshold; If the CPU occupancy rate of the downstream service is greater than a first threshold, the request timeout rate is greater than a second threshold, and / or the request failure rate is greater than a third threshold, it is determined that the downstream service is overloaded.

10. A request processing device, comprising: A data acquisition module, configured to acquire request volume data of at least one upstream service for the downstream service when an overload of the downstream service is detected; a service determination module, configured to determine a target upstream service from at least one upstream service according to the request volume data; A current limiting determination module, configured to determine a target current limiting value for the target upstream service; The request control module is used to process the request volume of the target upstream service for the downstream service according to the target current limit value.

11. An electronic device comprising: A processor and a memory, the memory being used to store a computer program, and the processor being used to call and run the computer program stored in the memory to execute the request processing method according to any one of claims 1 to 9. 12 . A computer-readable storage medium for storing a computer program, wherein the computer program causes a computer to execute the request processing method according to claim 1 .

13. A computer program product comprising program instructions, wherein when the program instructions are executed on an electronic device, the electronic device executes the request processing method according to any one of claims 1 to 9.

Images