A method and system for service overload hierarchical protection

Abstract

The present invention provides a method for hierarchical protection of service overload, which comprises the following steps: 1. Counting the waiting time from the receipt of a request to the start of execution, determining whether the service is overloaded, and proceeding to step 2; 2. Setting a service overload level, and storing the service overload level in a Redis cache; 3. After receiving the request, the service prioritizes determining the service level parameters passed in by the client; if the service level parameters do not exist, determining the service parameters of the service itself; if the service parameters are greater than or equal to the service overload level, prioritizing the request, and proceeding to step 4; 4. If the service overload level is greater than or equal to level 2, performing a hash function on the user ID to obtain a hash value hashcode, using the modulus value of the hash value hashcode%3 plus 1 as the user priority level; if both the user priority level and the service level parameters are greater than or equal to the service overload level, prioritizing the request; otherwise, discarding the request. The present invention can effectively improve the user experience of the system by ensuring available services as much as possible under burst traffic.

Description

Technical Field

[0001] The present invention relates to the technical field of service overload protection, and in particular to a method and system for hierarchical protection of service overload. Background Art

[0002] Service overload occurs when the number of requests to a system exceeds its maximum capacity, resulting in excessive system load. This manifests as increased response latency, and users may experience slow or unavailable load times. This triggers further retries, and the service continues to process invalid requests, causing valid requests to drop to zero, or even causing an avalanche in the entire system. Popular internet scenarios often experience bursts of traffic, such as flash sales, major emergencies, and malicious attacks, which can place pressure on the system several times higher than usual. Common solutions to service overload include limiting traffic and downgrading, but these single-dimensional approaches only meet simple requirements and often only ensure that the system remains operational without effectively guaranteeing the availability of the protected traffic. Summary of the Invention

[0003] To overcome the above problems, the purpose of the present invention is to provide a method for hierarchical protection of service overload, which combines multiple dimensions of service level and user level to perform overload protection, thereby improving the user experience.

[0004] The present invention is implemented by the following scheme: a method for hierarchical protection of service overload, the method comprising the following steps:

[0005] Step S1: Count the waiting time from the receipt of a request to the start of its execution, obtain a first average waiting time per second based on the waiting time, preset N requests to obtain a second average waiting time for N requests, and determine whether the sum of the first average waiting time and the second average waiting time exceeds a threshold value T milliseconds. If so, it indicates that the service is overloaded and the process proceeds to step S2; if not, no operation is performed and counting continues;

[0006] Step S2: Set the service overload level. If the service overload level is greater than or equal to the threshold T and less than 2T milliseconds, it is level 1; if the service overload level is greater than or equal to the threshold 2T and less than 4T milliseconds, it is level 2; if the service overload level is greater than or equal to the threshold 4T milliseconds, it is level 3. Store the service overload level in the Redis cache.

[0007] Step S3: After receiving the request, the service first determines the service level parameter passed in by the client. If it exists, it determines whether the service level parameter is greater than or equal to the service overload level. If it is, it prioritizes requesting to complete the service; otherwise, it discards it. If it does not exist, it determines the service parameters of the service itself. If it is greater than or equal to the service overload level, it prioritizes requesting to complete the service; otherwise, it discards it and requests the downstream service to bring the service level parameter together.

[0008] Furthermore, the step S2 is further specified as follows: setting the overload level L of the current service, the threshold T is 50, then if the sum of the average waiting time is less than 50 milliseconds, the service is not overloaded L=0, if the sum of the average waiting time is greater than or equal to 50 milliseconds and less than 100 milliseconds, it is set to the service overload level L=1, if the sum of the average waiting time is greater than or equal to 100 milliseconds and less than 200 milliseconds, it is set to the service overload level L=2, if the sum of the average waiting time is greater than or equal to 200 milliseconds, it is set to the service overload level L=3; store the overload level in the redis cache, set the cache expiration time to 8-15 seconds, the default service overload status is 10 seconds, if no service overload is detected, the service overload status will be deleted after 10 seconds.

[0009] Furthermore, the step S3 is further specified as follows: each service will pre-configure its own default service level parameter. After receiving the request, the service will first determine the service level parameter bizlevel passed in by the client. If it exists, it will determine whether the service level parameter bizlevel is greater than or equal to the service overload level. If so, the request will be completed with priority; otherwise, it will be discarded; if the service level parameter bizlevel does not exist in the parameters passed in by the client, bizlevel will be assigned to the service level parameter pre-configured by the service itself; the service overload level in the redis cache will be read and saved in the memory, and the memory needs to be updated and re-read regularly; it will be determined whether bizlevel is greater than or equal to the service overload level. If it is, the request will be allowed, otherwise it will be discarded, and the downstream service will be requested to bring the service level parameter together; ensuring that the entire link is protected.

[0010] Furthermore, in step S3, if the service overload level is greater than or equal to level 2, the user ID is used to perform a hash function to obtain a hash value hashcode, and the modulus value of the hash value hashcode%3 plus 1 is used as the user priority level. If the user priority level and the service level parameters are both greater than or equal to the service overload level, the request is prioritized, otherwise it is discarded.

[0011] Furthermore, if the service overload level is greater than or equal to level 2, it is also necessary to add the judgment of user priority. When the service overload level continues to increase, in order to further protect the availability of important business services, it is necessary to discard some users' requests and ensure the priority of some users; the user ID is used to perform a hash function calculation to obtain a hash value hashcode, and the hash value hashcode and the highest service overload level 3 are modulo, that is, (hashcode%3)+1 to obtain the result as the user priority level. The request is allowed only if the user priority level and business level parameters are greater than or equal to the service overload level; and the hash function is replaced every hour.

[0012] The present invention also provides a system for service overload hierarchical protection, the system comprising: a request waiting time calculation module, an overload level setting module, and an overload request processing module;

[0013] The request waiting time calculation module calculates the waiting time from the receipt of a request to the start of execution, obtains a first average waiting time per second based on the waiting time, presets N requests to obtain a second average waiting time of N requests, and determines whether the sum of the first average waiting time and the second average waiting time exceeds a threshold value T milliseconds. If so, it indicates that the service is overloaded and the overload level setting module is entered; if not, no operation is performed and the statistics are continued;

[0014] The overload level setting module sets the service overload level. A service overload level greater than or equal to a threshold value T and less than 2T milliseconds is level 1, a service overload level greater than or equal to a threshold value 2T and less than 4T milliseconds is level 2, and a service overload level greater than or equal to a threshold value 4T milliseconds is level 3. The service overload level is stored in the Redis cache.

[0015] After the service receives the request, the overload request processing module will give priority to judging the service level parameters passed in by the client. If they exist, it will judge whether the service level parameters are greater than or equal to the service overload level. If they are, it will give priority to requesting to complete the service; otherwise, it will be discarded; if they do not exist, it will judge the service parameters of the service itself. If they are greater than or equal to the service overload level, it will give priority to requesting to complete the service; otherwise, it will be discarded and the downstream service will be requested to bring the service level parameters together.

[0016] Furthermore, the overload level setting module is further specified as follows: setting the overload level L of the current service, the threshold T is 50, then if the sum of the average waiting time is less than 50 milliseconds, the service is not overloaded L=0, if the sum of the average waiting time is greater than or equal to 50 milliseconds and less than 100 milliseconds, it is set to the service overload level L=1, if the sum of the average waiting time is greater than or equal to 100 milliseconds and less than 200 milliseconds, it is set to the service overload level L=2, if the sum of the average waiting time is greater than or equal to 200 milliseconds, it is set to the service overload level L=3; store the overload level in the redis cache, set the cache expiration time to 8-15 seconds, the default service overload status is 10 seconds, if no service overload is detected, the service overload status will be deleted after 10 seconds.

[0017] Furthermore, the overload request processing module is further specified as follows: each service will pre-configure its own default business level parameters. After receiving the request, the service will first determine the business level parameter bizlevel passed in by the client. If it exists, it will determine whether the business level parameter bizlevel is greater than or equal to the service overload level. If so, the request will be completed first; otherwise, it will be discarded; if the business level parameter bizlevel does not exist in the parameters passed in by the client, bizlevel will be assigned to the business level parameter pre-configured by the service itself; the service overload level in the redis cache will be read and saved in the memory, and the memory needs to be updated and re-read regularly; it will be determined whether bizlevel is greater than or equal to the service overload level. If it is, the request will be allowed, otherwise it will be discarded, and the downstream service will be requested to bring the business level parameter together; ensuring that the entire link is protected.

[0018] Furthermore, in the overload request processing module, if the service overload level is greater than or equal to level 2, the user ID is used to perform a hash function to obtain a hash value hashcode, and the modulus value of the hash value hashcode%3 plus 1 is used as the user priority level. If the user priority level and the service level parameters are both greater than or equal to the service overload level, the request is prioritized, otherwise it is discarded.

[0019] Furthermore, if the service overload level is greater than or equal to level 2, it is also necessary to add the judgment of user priority. When the service overload level continues to increase, in order to further protect the availability of important business services, it is necessary to discard some users' requests and ensure the priority of some users; the user ID is used to perform a hash function calculation to obtain a hash value hashcode, and the hash value hashcode and the highest service overload level 3 are modulo, that is, (hashcode%3)+1 to obtain the result as the user priority level. The request is allowed only if the user priority level and business level parameters are greater than or equal to the service overload level; and the hash function is replaced every hour.

[0020] The beneficial effects of the present invention are as follows: the present invention is provided with service level and user level, and overload protection is performed by combining multiple dimensions of service level and user level, which effectively improves the user experience of the system to ensure available services as much as possible under burst traffic. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 It is a schematic flow chart of the method of the present invention.

[0022] Figure 2 It is a diagram of the system working principle of the present invention. DETAILED DESCRIPTION

[0023] The present invention will be further described below with reference to the accompanying drawings.

[0024] See also Figure 1 A method for hierarchical protection of service overload is shown, the method comprising the following steps:

[0025] Step S1: Count the waiting time from the receipt of a request to the start of its execution, obtain a first average waiting time per second based on the waiting time, preset N requests to obtain a second average waiting time for N requests, and determine whether the sum of the first average waiting time and the second average waiting time exceeds a threshold value T milliseconds. If so, it indicates that the service is overloaded and the process proceeds to step S2; if not, no operation is performed and counting continues;

[0026] Step S2: Set the service overload level. If the service overload level is greater than or equal to the threshold T and less than 2T milliseconds, it is level 1; if the service overload level is greater than or equal to the threshold 2T and less than 4T milliseconds, it is level 2; if the service overload level is greater than or equal to the threshold 4T milliseconds, it is level 3. Store the service overload level in the Redis cache.

[0027] Step S3: After receiving the request, the service first determines the service level parameter passed in by the client. If it exists, it determines whether the service level parameter is greater than or equal to the service overload level. If it is, it prioritizes requesting to complete the service; otherwise, it discards it. If it does not exist, it determines the service parameters of the service itself. If it is greater than or equal to the service overload level, it prioritizes requesting to complete the service; otherwise, it discards it and requests the downstream service to bring the service level parameter together.

[0028] The present invention will be further described below in conjunction with a specific embodiment:

[0029] The present invention provides a method for hierarchical protection of service overload, the main ideas of which are as follows: 1. Count the waiting time from the receipt of a request to the start of processing, calculate whether the average waiting time per second and the sum of the average waiting time of 1,000 requests exceed 50 milliseconds, and if so, it indicates service overload. 2. Calculate the service overload level, exceeding 50 milliseconds is level 1, exceeding 100 milliseconds is level 2, and exceeding 200 milliseconds is level 3. Store the service overload level in the Redis cache and set an expiration time of 10 seconds. 3. After the service receives the request, it first determines the service level parameters passed in by the client. If they do not exist, it determines the service parameters of the service itself. If they are greater than or equal to the service overload level, the request is prioritized; otherwise, it is discarded. The downstream service is requested along with the service level parameters to ensure that the entire link is protected. If the service overload level is greater than or equal to level 2, the user ID is hashed to obtain a hashcode, and the hashcode is used to calculate the modulus value of %3 plus 1 as the user priority level. If both the user priority level and the service level are greater than or equal to the service overload level, the request is prioritized; otherwise, it is discarded. And the hash function is changed every hour to avoid the priority always being given to fixed users.

[0030] A method for hierarchical protection of service overload,

[0031] Step 1: Count the waiting time from the receipt of a request to the start of execution. Calculate whether the average waiting time per second and the sum of the average waiting time of 1,000 requests exceeds 50 milliseconds. If this exceeds 50 milliseconds, it indicates service overload.

[0032] Count the waiting time for each request from the time it is received to the time it starts executing. For example, if the timestamp when the request is received is 1660570486000 and the timestamp when the request starts executing is 1660570486010, then the waiting time for the request is 1660570486000 - 1660570486010 = 10 milliseconds. This does not calculate the complete execution time of the request's entire lifecycle, but rather how long the request waited before being executed.

[0033] According to the calculation rules of the waiting time, the average waiting time T1 within 1 second and the average waiting time T2 of nearly 1,000 requests are calculated, and the sum of T1+T2 is calculated as the overload judgment basis Q. If Q is greater than 50 milliseconds (50 milliseconds is the threshold T milliseconds in one embodiment), it is considered an overload state.

[0034] Step 2: Calculate the service overload level. If it exceeds 50 milliseconds, it is level 1; if it exceeds 100 milliseconds, it is level 2; and if it exceeds 200 milliseconds, it is level 3. Store the service overload level in the Redis cache and set the expiration time to 10 seconds.

[0035] Calculate the overload level L of the current service. If the overload judgment basis Q is less than 50 milliseconds, the service is not overloaded L=0. If the overload judgment basis Q is greater than or equal to 50 milliseconds and less than 100 milliseconds, the overload level L is set to 1. If the overload judgment basis Q is greater than or equal to 100 milliseconds and less than 200 milliseconds, the overload level L is set to 2. If the overload judgment basis Q is greater than or equal to 200 milliseconds, the overload level L is set to 3.

[0036] Store the overload level in the Redis cache with the cache key overload-level. Set the cache expiration time to 8-15 seconds. The default service overload status is 10 seconds. If no service overload is detected, the service overload status will be deleted after 10 seconds.

[0037] Step 3: After receiving the request, the service first checks the service level parameter passed in by the client. If it exists, it determines whether the service level parameter is greater than or equal to the service overload level. If so, the request is prioritized; otherwise, it is discarded. If it does not exist, the service's own service parameters are checked. If they are greater than or equal to the service overload level, the request is prioritized; otherwise, it is discarded. The service level parameter is included in the request to the downstream service to ensure that the entire link is protected.

[0038] Each service will be pre-configured with its own default service level parameters. For example, for more important services such as user services and payment services, the user experience needs to be prioritized, so the service level parameter is set to 3; for example, the points service has a medium priority, so the service level parameter is set to 2; for example, the comment service has a relatively low priority, so the service level parameter is set to 1.

[0039] To ensure the integrity of the entire link and avoid the situation where a high-level user service calls a downstream low-level service and becomes unavailable, which would otherwise cause the user service to become unavailable, the service-level parameters passed in by the client are obtained first and then transparently transmitted when calling downstream to ensure that the service-level parameters of the entire link are consistent.

[0040] After receiving the request, the service first determines the business level parameter bizlevel passed in by the client. If the parameter passed in by the client does not contain bizlevel, the bizlevel is assigned to the business level parameter pre-configured by the service itself.

[0041] Read the service overload level from Redis and save a copy in memory. This needs to be updated periodically and re-read. Check whether the bizlevel is greater than or equal to the service overload level. If so, the request is allowed; otherwise, it is discarded.

[0042] If the service overload level is greater than or equal to level 2, the user ID is hashed to obtain a hashcode. The hashcode is then calculated modulo 3 and added to the value of 1 to determine the user's priority level. If both the user priority and the service level are greater than or equal to the service overload level, the request is prioritized; otherwise, it is discarded. The hash function is changed every hour to prevent a fixed user from always being prioritized.

[0043] If the service overload level is greater than or equal to 2, in addition to the judgment of the service level parameters in step 3, the judgment of the user priority level also needs to be added. When the service overload level continues to increase, in order to further protect the availability of important business services, it is necessary to discard some user requests and ensure the priority of some users.

[0044] The user ID is hashed to obtain a hash value, hashcode. The hash value is modulo the highest service level parameter, 3, and the result is (hashcode%3)+1, which is used as the user priority level. The request is allowed only if both the user priority level and the service priority level are greater than or equal to the service overload level. The hash function is changed every hour to prevent the priority from always being fixed on a certain group of users.

[0045] See also Figure 2As shown, the present invention also provides a system for service overload hierarchical protection, the system comprising: a request waiting time calculation module, an overload level setting module, and an overload request processing module;

[0046] The request waiting time calculation module calculates the waiting time from the receipt of a request to the start of execution, obtains a first average waiting time per second based on the waiting time, presets N requests to obtain a second average waiting time of N requests, and determines whether the sum of the first average waiting time and the second average waiting time exceeds a threshold value T milliseconds. If so, it indicates that the service is overloaded and the overload level setting module is entered; if not, no operation is performed and the statistics are continued;

[0047] For example, to calculate the waiting time for each request from the time it is received to the time it starts executing, if the timestamp when the request is received is 1660570486000 and the timestamp when the request starts executing is 1660570486010, then the waiting time for the request is 1660570486000 - 1660570486010 = 10 milliseconds. This calculation does not measure the complete execution time of the request's entire lifecycle, but rather how long the request waited before it was executed.

[0048] According to the calculation rules of the waiting time, the average waiting time T1 within 1 second and the average waiting time T2 of the last 1000 requests are calculated, and the sum of T1+T2 is calculated as the overload judgment basis Q. If Q is greater than 50 milliseconds (50 milliseconds is the threshold T milliseconds in one embodiment), it is considered an overload state.

[0049] The overload level setting module sets the service overload level. A service overload level greater than or equal to a threshold value T and less than 2T milliseconds is level 1, a service overload level greater than or equal to a threshold value 2T and less than 4T milliseconds is level 2, and a service overload level greater than or equal to a threshold value 4T milliseconds is level 3. The service overload level is stored in the Redis cache.

[0050] The overload level setting module is further specifically as follows: setting the overload level L of the current service, the threshold T is 50, then if the sum of the average waiting time is less than 50 milliseconds, the service is not overloaded L=0, if the sum of the average waiting time is greater than or equal to 50 milliseconds and less than 100 milliseconds, it is set to the service overload level L=1, if the sum of the average waiting time is greater than or equal to 100 milliseconds and less than 200 milliseconds, it is set to the service overload level L=2, if the sum of the average waiting time is greater than or equal to 200 milliseconds, it is set to the service overload level L=3; storing the overload level in the redis cache, setting the cache expiration time to 8-15 seconds, the default service overload status is 10 seconds, and if no service overload is detected, the service overload status will be deleted after 10 seconds.

[0051] After the service receives the request, the overload request processing module will give priority to judging the service level parameters passed in by the client. If they exist, it will judge whether the service level parameters are greater than or equal to the service overload level. If they are, it will give priority to requesting to complete the service; otherwise, it will be discarded; if they do not exist, it will judge the service parameters of the service itself. If they are greater than or equal to the service overload level, it will give priority to requesting to complete the service; otherwise, it will be discarded and the downstream service will be requested to bring the service level parameters together.

[0052] The overload request processing module is further specified as follows: each service will pre-configure its own default business level parameters. After receiving the request, the service will first determine the business level parameter bizlevel passed in by the client. If it exists, it will determine whether the business level parameter bizlevel is greater than or equal to the service overload level. If so, the request will be completed with priority; otherwise, it will be discarded; if the business level parameter bizlevel does not exist in the parameters passed in by the client, bizlevel will be assigned to the business level parameter pre-configured by the service itself; the service overload level in the Redis cache will be read and saved in the memory, and the memory needs to be updated and re-read regularly; it will be determined whether bizlevel is greater than or equal to the service overload level. If it is, the request will be allowed; otherwise, it will be discarded, and the downstream service will be requested to bring the business level parameter together; ensuring that the entire link is protected.

[0053] Among them, in the overload request processing module, if the service overload level is greater than or equal to level 2, the user ID is used to perform a hash function to obtain a hash value hashcode, and the modulus value of the hash value hashcode%3 plus 1 is used as the user priority level. If the user priority level and the service level parameters are both greater than or equal to the service overload level, the request is prioritized, otherwise it is discarded.

[0054] If the service overload level is greater than or equal to level 2, it is also necessary to add the judgment of user priority. When the service overload level continues to increase, in order to further protect the availability of important business services, it is necessary to discard some users' requests and guarantee the priority of some users. The hash function is calculated using the user ID to obtain the hash value hashcode, and the hash value hashcode and the highest service overload level 3 are modulo, that is, (hashcode%3)+1 to obtain the result as the user priority level. The request is allowed only if the user priority level and business level parameters are greater than or equal to the service overload level. The hash function is replaced every hour.

[0055] The above description is only a preferred embodiment of the present invention. All equivalent changes and modifications made according to the scope of the patent application of the present invention should fall within the scope of the present invention.

Claims

1. A method for hierarchical service overload protection, characterized by: The method comprises the following steps: Step S1: Count the waiting time from the receipt of a request to the start of its execution, obtain a first average waiting time per second based on the waiting time, preset N requests to obtain a second average waiting time for N requests, and determine whether the sum of the first average waiting time and the second average waiting time exceeds a threshold value T milliseconds. If so, it indicates that the service is overloaded and the process proceeds to step S2; if not, no operation is performed and counting continues; Step S2: Set the service overload level. If the service overload level is greater than or equal to the threshold T and less than 2T milliseconds, it is level 1; if the service overload level is greater than or equal to the threshold 2T and less than 4T milliseconds, it is level 2; if the service overload level is greater than or equal to the threshold 4T milliseconds, it is level 3. Store the service overload level in the Redis cache. Step S3: After receiving the request, the service first determines the service level parameter passed in by the client. If it exists, it determines whether the service level parameter is greater than or equal to the service overload level. If so, it prioritizes the request to complete the service; otherwise, it discards the request. If it does not exist, it determines the service parameters of the service itself. If they are greater than or equal to the service overload level, it prioritizes the request to complete the service; otherwise, it discards the request and requests the downstream service to bring the service level parameter. In step S3, if the service overload level is greater than or equal to level 2, a hash function is performed on the user ID to obtain a hash value hashcode, and the modulus value of the hash value hashcode%3 plus 1 is used as the user priority level. If the user priority level and the service level parameters are both greater than or equal to the service overload level, the request is prioritized; otherwise, it is discarded; If the service overload level is greater than or equal to level 2, it is also necessary to add the judgment of user priority. When the service overload level continues to increase, in order to further protect the availability of important business services, it is necessary to discard some users' requests and guarantee the priority of some users. The hash function is calculated using the user ID to obtain the hash value hashcode, and the hash value hashcode and the highest service overload level 3 are modulo, that is, (hashcode%3)+1 to obtain the result as the user priority level. The request is allowed only if the user priority level and business level parameters are greater than or equal to the service overload level. The hash function is replaced every hour.

2. The method for hierarchical service overload protection according to claim 1, characterized in that: The step S2 is further specifically as follows: setting the overload level L of the current service, the threshold T is 50, then if the sum of the average waiting time is less than 50 milliseconds, the service is not overloaded L=0, if the sum of the average waiting time is greater than or equal to 50 milliseconds and less than 100 milliseconds, the service overload level is set to L=1, if the sum of the average waiting time is greater than or equal to 100 milliseconds and less than 200 milliseconds, the service overload level is set to L=2, if the sum of the average waiting time is greater than or equal to 200 milliseconds, the service overload level is set to L=3; storing the overload level in the redis cache, setting the cache expiration time to 8-15 seconds, the default service overload status is 10 seconds, and if no service overload is detected, the service overload status will be deleted after 10 seconds.

3. The method for hierarchical service overload protection according to claim 1, characterized in that: Step S3 is further specifically as follows: each service will pre-configure its own default service level parameter. After receiving the request, the service will first determine the service level parameter bizlevel passed in by the client. If it exists, it will determine whether the service level parameter bizlevel is greater than or equal to the service overload level. If so, the service will be completed with priority request; Otherwise, it is discarded; if the business level parameter bizlevel does not exist in the parameters passed by the client, bizlevel is assigned to the business level parameter pre-configured by the service itself; the service overload level in the Redis cache is read and saved in memory, and the memory needs to be updated and re-read regularly; it is determined whether bizlevel is greater than or equal to the service overload level. If so, the request is allowed; otherwise, it is discarded and the downstream service is requested to include the business level parameter; this ensures that the entire link is protected.

4. A system for hierarchical service overload protection, characterized by: The system includes: a request waiting time calculation module, an overload level setting module, and an overload request processing module; The request waiting time calculation module calculates the waiting time from the receipt of a request to the start of execution, obtains a first average waiting time per second based on the waiting time, presets N requests to obtain a second average waiting time of N requests, and determines whether the sum of the first average waiting time and the second average waiting time exceeds a threshold value T milliseconds. If so, it indicates that the service is overloaded and the overload level setting module is entered; if not, no operation is performed and the statistics are continued; The overload level setting module sets the service overload level. A service overload level greater than or equal to a threshold value T and less than 2T milliseconds is level 1, a service overload level greater than or equal to a threshold value 2T and less than 4T milliseconds is level 2, and a service overload level greater than or equal to a threshold value 4T milliseconds is level 3. The service overload level is stored in the Redis cache. The overload request processing module, after receiving the request, first determines the service level parameter passed in by the client, if it exists, then determines whether the service level parameter is greater than or equal to the service overload level, if so, first requests to complete the service; otherwise, discards it; if it does not exist, then determines the service parameter of the service itself, if it is greater than or equal to the service overload level, then first requests to complete the service; otherwise, discards it, and requests the downstream service to bring the service level parameter together; in the overload request processing module, if the service overload level is greater than or equal to level 2, the user ID is used to perform a hash function to obtain a hash value hashcode, and the modulus value of the hash value hashcode%3 plus 1 is used as the user priority level. If the user priority level and the service level parameter are greater than or equal to level 2, then the user ID is used to perform a hash function to obtain a hash value hashcode, and the modulus value of the hash value hashcode%3 plus 1 is used as the user priority level. If the number of requests is greater than or equal to the service overload level, the request will be given priority, otherwise it will be discarded; if the service overload level is greater than or equal to level 2, the user priority level needs to be judged. When the service overload level continues to increase, in order to further protect the availability of important business services, some user requests need to be discarded to ensure the priority of some users; the user ID is used to perform a hash function to obtain a hash value hashcode, and the hash value hashcode and the highest service overload level 3 are modulo, that is, (hashcode%3)+1 to obtain the result as the user priority level. The request will be allowed only if the user priority level and business level parameters are both greater than or equal to the service overload level; and the hash function is replaced every hour.

5. The system for hierarchical service overload protection according to claim 4, characterized in that: The overload level setting module is further specifically as follows: setting the overload level L of the current service, the threshold T is 50, then if the sum of the average waiting time is less than 50 milliseconds, the service is not overloaded L=0, if the sum of the average waiting time is greater than or equal to 50 milliseconds and less than 100 milliseconds, it is set to the service overload level L=1, if the sum of the average waiting time is greater than or equal to 100 milliseconds and less than 200 milliseconds, it is set to the service overload level L=2, if the sum of the average waiting time is greater than or equal to 200 milliseconds, it is set to the service overload level L=3; storing the overload level in the redis cache, setting the cache expiration time to 8-15 seconds, the default service overload status is 10 seconds, and if no service overload is detected, the service overload status will be deleted after 10 seconds.

6. The system for hierarchical service overload protection according to claim 4, characterized in that: The overload request processing module is further specifically configured as follows: each service will pre-configure its own default service level parameter. After receiving the request, the service will first determine the service level parameter bizlevel passed in by the client. If it exists, it will determine whether the service level parameter bizlevel is greater than or equal to the service overload level. If so, it will prioritize the request to complete the service; Otherwise, it is discarded; if the business level parameter bizlevel does not exist in the parameters passed by the client, bizlevel is assigned to the business level parameter pre-configured by the service itself; the service overload level in the Redis cache is read and saved in memory, and the memory needs to be updated and re-read regularly; it is determined whether bizlevel is greater than or equal to the service overload level. If so, the request is allowed; otherwise, it is discarded and the downstream service is requested to include the business level parameter; this ensures that the entire link is protected.

Images