An analysis decision method and device for gateway service overload

Abstract

The present disclosure provides a method and device for analyzing the overload of a gateway service. The method aims to enable the target gateway to have certain self-preservation capabilities when the service is overloaded, so as to ensure the stability and reliability of the target gateway service. The method comprises: obtaining running state data of a target gateway, the running state data representing the health state of the target gateway; determining the state partition in which the target gateway is currently located according to the running state data; the state partition comprises a health zone, a pre-control zone and an overload zone; in the case that the target gateway is in the pre-control zone, determining a request target list according to the current request situation of the target gateway; the request target list manages a first request target with the maximum number of requests; in the case that the target gateway is in the overload zone, performing upper limit control on the first number of requests of the first request target in the request target list.

Description

Technical Field

[0001] This disclosure relates to the field of content delivery network technology, and in particular to a method and apparatus for analyzing and making decisions about gateway service overload. Background Technology

[0002] A CDN (Content Delivery Network) integrates global node resources to provide localized distribution services to customers in various locations. Currently, nearly 80% of global traffic is accelerated by CDNs. As the first "entry point" after a user request is distributed, the CDN gateway processes the request according to the user's configuration, pulls the requested content from the origin server, and caches it in the CDN caching module.

[0003] In normal scenarios, the CDN gateway receives access requests from various users and serves them. However, in some scenarios, there may be sudden traffic to the CDN node, causing a surge in the number of requests on the edge machine in a short period of time. The large number of requests at the same time will also consume server resources until the resources are exhausted or even crash.

[0004] Therefore, when services are overloaded, CDN gateways need to have a certain degree of self-protection capability to ensure the stability and reliability of CDN services. Summary of the Invention

[0005] To overcome the problems existing in related technologies, this disclosure provides a method and apparatus for analyzing and making decisions on gateway service overload. The technical solution of this disclosure is as follows:

[0006] According to a first aspect of the present disclosure, a method for analyzing and making decisions regarding gateway service overload is provided, comprising:

[0007] Obtain the operating status data of the target gateway, wherein the operating status data represents the health status of the target gateway;

[0008] Based on the operational status data, the current state partition of the target gateway is determined: the state partition includes a health zone, a pre-control zone, and an overload zone;

[0009] When the target gateway is in the pre-control zone, a request target list is determined based on the current request status of the target gateway; the request target list manages a preset first request target with the highest number of requests.

[0010] When the target gateway is in the overload zone, the number of first requests to the first target in the request target list is capped.

[0011] Optionally, each first request target managed by the request target list is sorted in the request target list according to its corresponding number of first requests; when the target gateway is in the pre-control zone, the request target list is determined based on the current request status of the target gateway, including:

[0012] When a new request is written to the underlying data area of ​​the target gateway, the second request target corresponding to the new request is determined;

[0013] The number of second requests corresponding to the second request target is compared with the number of first requests corresponding to the first request target at the end of the request target list. The number of first requests corresponding to the first request target at the end of the request target list is the number of first requests with the fewest number of times in the request target list.

[0014] Based on the comparison results, determine whether the second request target is managed by the request target list;

[0015] If the second request target is managed by the request target list, update the sorting of the request target list.

[0016] Optionally, based on the comparison result, determining whether the second request target is managed by the request target list includes:

[0017] If the number of the second request is less than or equal to the number of the first request, it is determined that the second request target is not managed by the request target list;

[0018] If the number of second requests is greater than the number of first requests, the second request target is replaced by the last position of the first request target, so that the second request target is managed by the request target list.

[0019] Optionally, when the second request target is managed by the request target list, updating the sorting of the request target list includes:

[0020] Compare the number of second requests corresponding to the second request target with the number of first requests corresponding to the previous first request target;

[0021] If the number of the second request is less than or equal to the number of the first request, the sorting of the request target list is updated.

[0022] If the number of second requests is greater than the number of first requests, swap the positions of the first request target and the second request target.

[0023] The above steps are followed to compare the number of requests with the number of requests corresponding to the previous first request target in turn, until there is no previous first request target, or the number of requests is less than or equal to the number of requests, at which point the sorting of the request target list is completed.

[0024] Optionally, when the target gateway is in the overload zone, an upper limit is controlled on the number of first requests to the first target in the request target list, including:

[0025] Based on the request status of the requested target list in the pre-control zone, determine the control reference value;

[0026] Based on the control reference value, a tiered upper limit control is applied to the target control index of the first request target in the request target list; the target control index represents the number of requests made by the first request target per unit time.

[0027] Optionally, based on the control reference value, a tiered upper limit control is applied to the target control indicators of the requested target list, including:

[0028] Determine the time period and downward adjustment ratio for the tiered upper limit control;

[0029] The first request target with the highest number of first requests in the request target list is determined as the control request target;

[0030] Based on the aforementioned control reference value and the aforementioned reduction ratio, the upper limit value corresponding to the control cycle is determined;

[0031] Within the control period, the upper limit value is determined as the upper limit of the target control indicator for the control request target;

[0032] Requests exceeding the upper limit of the target control index are forwarded to a high-performance sandbox, which is an isolated environment or node for processing requests.

[0033] Optionally, based on the request status of the requested target list in the pre-control zone, a control reference value is determined, including:

[0034] Based on the target gateway being in the pre-control zone, the values ​​of the target control indicators corresponding to each first request target in the request target list;

[0035] Based on the sampling period and the value of the target control index, determine the average control value corresponding to each first request target;

[0036] The control reference value is determined by averaging the control values.

[0037] Optionally, it also includes:

[0038] During the process of implementing tiered upper limit control on the target regulation index of the first request target in the request target list, the first request target with the highest number of first requests in the request target list is updated in real time; and the state partition of the target gateway is determined in real time.

[0039] If the target gateway recovers to the healthy zone or the pre-control zone, the tiered upper limit control of the target regulation index of the first requested target in the requested target list shall be stopped.

[0040] Optionally, obtain the target gateway's operational status data, including:

[0041] Collect the first and second data from the target gateway;

[0042] Based on the first data and the second data, determine the cumulative month-on-month change of the first data and the cumulative month-on-month change of the second data, respectively;

[0043] The machine health value of the target gateway is obtained through data modeling;

[0044] Based on the operational status data, the current state partition of the target gateway is determined, including:

[0045] The cumulative first data month-on-month change, the cumulative second data month-on-month change, and the machine health value are compared with their respective thresholds to obtain comparison results;

[0046] Based on the comparison results, the state partition in which the target gateway is located is determined.

[0047] According to a second aspect of the present disclosure, a gateway service overload analysis and decision-making apparatus is provided, comprising:

[0048] The data acquisition module is used to acquire the operating status data of the target gateway, wherein the operating status data represents the health status of the target gateway;

[0049] The matching module is used to determine the current state partition of the target gateway based on the operating status data: the state partition includes a health zone, a pre-control zone, and an overload zone;

[0050] The analysis module is used to determine a list of request targets based on the current request status of the target gateway when the target gateway is in the pre-control zone; the list of request targets manages a preset first request target with the highest number of requests.

[0051] The decision module is used to control the upper limit of the number of requests for the first request target in the request target list when the target gateway is in the overload zone.

[0052] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when executed by the processor, the computer program implements the steps of analyzing and making decisions regarding gateway service overload as described in the first aspect.

[0053] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of analysis and decision-making regarding gateway service overload as described in the first aspect.

[0054] According to a fifth aspect of the present disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the gateway service overload analysis and decision-making steps described in the first aspect.

[0055] This disclosure enables real-time monitoring of the gateway's health status by acquiring its operational status data. Based on this data, the gateway's state is categorized into healthy, pre-control, and overload zones. This allows the system to take appropriate measures according to different states, improving the efficiency and accuracy of responses to gateway service overload and ensuring timely intervention during request surges. When the gateway is in the pre-control zone, a request target list can be determined based on the current request situation. This allows for rapid identification and handling of the domains truly causing the gateway overload issue when the gateway is in the overload zone. When the gateway is in the overload zone, an upper limit is placed on the number of requests to the first request target in the request target list, avoiding user experience issues caused by directly rejecting new requests. Attached Figure Description

[0056] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments of this disclosure will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0057] Figure 1 This is a schematic diagram illustrating the steps of a gateway service overload analysis and decision-making method according to an embodiment of this disclosure;

[0058] Figure 2 This is a schematic diagram illustrating an algorithm for confirming a request target list according to an embodiment of this disclosure;

[0059] Figure 3 This is a schematic diagram illustrating a specific implementation of the verification algorithm in an embodiment of this disclosure;

[0060] Figure 4This is a schematic diagram illustrating real-time sorting of a request target list according to an embodiment of this disclosure;

[0061] Figure 5 This is a schematic diagram illustrating the overall decision-making process of a gateway service overload analysis and decision-making method according to an embodiment of this disclosure;

[0062] Figure 6 This is a flowchart illustrating a gateway service overload analysis and decision-making method according to an embodiment of this disclosure;

[0063] Figure 7 This is a block diagram of a gateway service overload analysis and decision-making device shown in an embodiment of this disclosure;

[0064] Figure 8 This is a schematic diagram of an electronic device shown in an embodiment of this disclosure. Detailed Implementation

[0065] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0066] The terms "first," "second," etc., used in this disclosure and in the claims are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this disclosure can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0067] To facilitate understanding, the technical terms used in this disclosure will be explained first.

[0068] CDN (Content Delivery Network): Provides multiple edge caching servers to store the resources needed by users in the nearest server, thereby reducing request latency.

[0069] QPS (Queries per second) is a measure of the amount of traffic a specific query server processes within a given time. On the Internet, the performance of machines that act as Domain Name System (DNS) servers is often measured in terms of queries per second.

[0070] CDN resource management and scheduling capabilities can estimate peak traffic by analyzing historical bandwidth and traffic data of nodes. However, the estimated results may deviate from the actual traffic volume. When the actual requests to a CDN service node exceed its capacity, the CDN gateway needs to have self-protection capabilities to reduce system pressure and ensure the normal service of most businesses.

[0071] Currently, in related technologies, the method for handling CDN gateway service overload is to record metrics such as QPS and request failure rate. When the QPS of a single CDN node exceeds a set threshold, the request failure rate is used to determine whether the service is overloaded. Once overloaded, new requests forwarded to that machine are directly rejected to prevent excessive resource consumption. After enabling overload protection, service recovery is required. A common method is to periodically send a liveness probe signal when the service is in a dormant state to detect whether the CDN node's service has returned to normal.

[0072] However, the above-mentioned CDN service overload handling and recovery solutions still have some problems:

[0073] (1) The criteria for determining service overload are based on whether metrics such as QPS and request failure rate exceed the threshold. However, in a CDN scenario, the capacity of each CDN node's server access machine is different, and the threshold is not easy to set uniformly. Furthermore, existing technologies for metrics such as QPS and request failure rate usually rely on statistical gateway access logs. The method of writing logs to disk and then performing statistics is lagging, and it is very likely that the request volume has exceeded the CDN service capacity, but it has not been processed in time.

[0074] (2) After enabling overload protection, the common decision is to directly reject new requests to prevent excessive requests from crashing the server. However, not all requests are the "culprits" causing service overload. The top-level domains with the sudden increase in requests should be quickly identified and dealt with accordingly. Secondly, directly rejecting new requests is not a user-friendly approach. After service overload, it is necessary to ensure user availability as much as possible.

[0075] (3) The service recovery solution is to probe the machines that are already under overload protection within a period of time. However, even if the periodic probe requests are successful, it does not mean that the machines can be restored to normal service status. More indicators still need to be considered. Otherwise, after activation, CDN machines are still at risk of being exhausted by sudden traffic surges.

[0076] Therefore, a real-time analysis and decision-making method for CDN gateway service overload is needed. In scenarios where CDN gateway service is overloaded, it should be able to analyze and locate sudden increases in requests at the domain name level in real time, and enable adaptive overload protection and recovery to ensure the stability and reliability of CDN services.

[0077] To address the aforementioned issues, this disclosure provides an analysis and decision-making method for gateway service overload. This method can analyze in real time to quickly locate sudden surges in requests and specifically handle top-level domains experiencing sudden surges in requests to ensure the availability and stability of CDN services. This solves the shortcomings of existing methods, such as low efficiency in locating service overload, direct rejection of all new requests, and low accuracy in restoring services.

[0078] Figure 1 This is a schematic diagram illustrating the steps of a gateway service overload analysis and decision-making method according to an embodiment of this disclosure. Figure 1 As shown, the method may specifically include the following steps:

[0079] Step S11: Obtain the operating status data of the target gateway, wherein the operating status data represents the health status of the target gateway.

[0080] Before requesting logs to be written to disk, various performance metrics of the target gateway are collected in real time, including but not limited to CPU utilization, memory utilization, disk I / O utilization, network bandwidth utilization, and service port response time. The system can count the total number of requests and the number of abnormal requests per unit time, and calculate the percentage of abnormal requests. Based on the collected metric data, a preset algorithm is used to calculate the health value of the target gateway.

[0081] The meaning of the stages before requesting to write the log to disk.

[0082] The operational status data is determined based on health values, the percentage of abnormal requests, etc., and the operational status data can indicate the current health status of the target gateway.

[0083] Step S12: Based on the operating status data, determine the current state partition of the target gateway: the state partition includes a health zone, a pre-control zone, and an overload zone.

[0084] Health status reflects whether the target gateway is overloaded. By analyzing the operational status data, the current service load of the target gateway can be determined, thereby identifying which state partition the target gateway is currently in.

[0085] When the target gateway is in the health zone, it means that the gateway is operating well and all performance indicators are within the normal range. At this time, no additional intervention or adjustment is required and the system can operate normally.

[0086] When the target gateway is in the pre-control zone, it means that the gateway is in a sub-healthy state. Although it has not yet reached overload, there are potential risks. At this time, it is necessary to enable the real-time analysis function to monitor the request situation so that measures can be taken in time when the traffic increases further to prevent it from entering the overload zone.

[0087] When the target gateway is in the overload zone, it indicates that the gateway's operating status is extremely unhealthy, and the system is unable to effectively handle the current request volume, which may lead to service interruption or a severe deterioration in user experience. Immediate measures are needed to alleviate the current burden on the gateway and restore it to a healthy state as quickly as possible.

[0088] Step S13: When the target gateway is in the pre-control zone, determine the request target list according to the current request status of the target gateway; the request target list manages a preset first request target with the highest number of requests.

[0089] The request target list is determined based on both domain name granularity and IP address (Internet Protocol Address) granularity. This means that each domain name and IP address corresponds to a separate request target list. Specifically, the request target list corresponding to a domain name determines the number of requests for each domain name, and the request target list corresponding to an IP address determines the number of requests for each IP address.

[0090] Analyze the current request data to determine the number of times each request target is accessed, and identify the top N request targets with the highest number of accesses as the first request targets in the request target list that need to be managed.

[0091] The list of request targets is updated periodically or irregularly based on real-time request data to ensure its accuracy and timeliness.

[0092] Step S14: When the target gateway is in the overload zone, the upper limit is controlled on the number of first requests to the first target in the request target list.

[0093] The request target list manages multiple first request targets. The first request target is the N request targets with the highest number of requests received by the target gateway.

[0094] It allows for setting a limit on the number of requests made to the first request target in the target list, thus enabling targeted processing of top-ranking request targets.

[0095] By monitoring the QPS of the first request target and controlling the upper limit of the QPS, the upper limit of the number of first requests to the first request target can be achieved.

[0096] By employing embodiments of this disclosure, the health status of a target gateway can be accurately assessed through real-time acquisition of its operational status data. Based on this data, the target gateway is divided into a healthy zone, a pre-control zone, and an overload zone. This dynamic partitioning management can be flexibly adjusted according to actual load conditions, ensuring appropriate measures are taken under different conditions. When the gateway is in the pre-control zone, the system can identify potential overload risks in advance and determine a list of request targets based on current request activity, allowing for preventative measures to mitigate risks before problems occur. When the gateway enters the overload zone, the system imposes an upper limit on the top request target in the request target list, ensuring user availability as much as possible during service overload and avoiding direct request rejection, thereby improving user experience.

[0097] In one optional embodiment, acquiring the operational status data of the target gateway includes: collecting first data and second data of the target gateway; determining the cumulative first data month-on-month change and the cumulative second data month-on-month change, respectively, based on the first data and the second data; obtaining the machine health value of the target gateway through data modeling; and determining the current state partition of the target gateway based on the operational status data, including: comparing the cumulative first data month-on-month change, the cumulative second data month-on-month change, and the machine health value with corresponding thresholds to obtain comparison results; and determining the state partition of the target gateway based on the comparison results.

[0098] Before requesting the log to be written to disk, the first data, the second data, and the machine health value are collected in real time.

[0099] Real-time monitoring of the target gateway's performance metrics. The first metric can be QPS (Queries Per Second), and the second metric can be the percentage of abnormal requests. Both metrics can be obtained through log recording, monitoring tools, or APIs (Application Programming Interfaces). The cumulative month-on-month changes for the first and second metrics can be determined using month-on-month formulas; specifically, these could be the month-on-month increase rate of QPS and the increase rate of abnormal request percentages.

[0100] Acquire machine performance-related metrics, such as CPU (Central Processing Unit) utilization, memory utilization, disk I / O (Input / Output) utilization, and network bandwidth utilization. This data can be collected through monitoring systems or performance monitoring tools. Use this metric data to perform data modeling to assess the health status of the target gateway and obtain its machine health value.

[0101] Based on experience or historical data, thresholds are set for each state partition. Specifically, this can be represented by thresholds for the health zone, the pre-control zone, and the overload zone. The thresholds for the health zone, the pre-control zone, and the overload zone can be a combined threshold, which includes the cumulative first data month-on-month change, the cumulative second data month-on-month change, and the machine health value, respectively, and their corresponding thresholds.

[0102] Based on the comparison results, the system will output the current state partition of the target gateway.

[0103] In one specific implementation, KL can be set as the threshold for machine health, RL as the threshold for QPS surge rate, and FL as the threshold for abnormal request surge rate. When the target gateway's health value is less than KL, the QPS surge rate is less than RL, and the abnormal request surge rate is less than FL, the target gateway is in the healthy zone. When the machine's health value is greater than KL and the QPS surge rate is greater than RL, the machine is in the pre-control zone. When the machine's health value is greater than KH, the QPS surge rate is greater than RH, and the abnormal request percentage is greater than x times the baseline value of the abnormal request percentage of the target gateway when it is in the healthy zone, the machine is in the overload zone.

[0104] By employing embodiments of this disclosure, comprehensive monitoring of the gateway's operational status through the collection of target gateway metrics data enables the timely detection of potential performance bottlenecks and anomalies. Calculating the month-on-month changes in cumulative first and second data points provides a clear picture of gateway performance trends, helping the system quickly identify abnormal fluctuations and take timely measures. Based on operational status data and set thresholds, the target gateway is dynamically divided into a healthy zone, a pre-control zone, and an overload zone, allowing for flexible adjustments based on actual load conditions to ensure appropriate measures are taken under different circumstances. Dynamic monitoring and status partitioning management effectively prevent gateway crashes under high load, improving service availability and ultimately enhancing user experience.

[0105] In one optional embodiment, each first request target managed by the request target list is sorted in the request target list according to its corresponding first request count. When the target gateway is in the pre-control zone, the request target list is determined based on the current request status of the target gateway, including: when a new request is written to the underlying data area of ​​the target gateway, determining the second request target corresponding to the new request; comparing the second request count corresponding to the second request target with the first request count corresponding to the last first request target in the request target list, wherein the first request count corresponding to the last first request target in the request target list is the first request count with the fewest counts in the request target list; determining whether the second request target is managed by the request target list based on the comparison result; and updating the sorting of the request target list when the second request target is managed by the request target list.

[0106] Once the target gateway enters the pre-control zone, real-time analysis based on a sliding window can be initiated. This allows for the capture and sorting of request counts of target requests in real time with minimal cost, even amidst dynamic changes in large volumes of request data. This ensures that top-ranking request targets can be identified before the target gateway enters the overload zone. These target requests can be managed through a request target list.

[0107] The CDN gateway allocates a dedicated area in its underlying data zone as the area corresponding to the request target list. The request target list is an ordered array. Based on the number of requests, the first request target in the list is sorted from highest to lowest. The last first request target in the list is the one with the fewest first request counts, and the first first request target is the one with the most first request counts.

[0108] The request target list is actually an ordered array. Each element in the array represents a request target and its corresponding number of requests. The last request target in the list is the first request target with the fewest requests, and the first request target is the first request target with the most requests. For example, if the request target list manages the top 10 request targets, then the first element is the first request target with the highest number of requests, and the last element is the tenth request target with the highest number of requests.

[0109] To efficiently manage these request targets, the request target list does not store the first request target itself, but rather its index in the underlying data area. This index can be accessed through the data area index. Whenever a request target needs to be retrieved from the request target list, the system reads its specific information from the underlying data area using its corresponding data area index. In practice, the data area index can be represented by `data_index`.

[0110] A new request is detected arriving at the target gateway, and relevant information about the request is recorded. Based on the content or characteristics of the new request, its corresponding second request target is determined, and the number of second requests to the second request target is determined.

[0111] Retrieve the last request target from the request target list and record its corresponding first request count. In practice, this could involve obtaining the data area index corresponding to the last element in the request target list, accessing the actual first request target from the underlying data area based on the data area index, and determining the first request count for that first request target.

[0112] The first number of requests is compared with the second number of requests to determine whether the second request target is managed by the request target list.

[0113] Because the request target list is designed to be ordered, after new request data is inserted, we only need to focus on the first request target at the end of the list and the second request target corresponding to the new request data to quickly determine whether the second request target corresponding to the new request data needs to be managed by the request target list, without having to traverse the entire request target list. Therefore, it only requires a minimum of one comparison to determine whether the second request target is managed by the request target list, thus determining whether the request target list needs to be updated with the fewest comparisons.

[0114] When a second request target is managed by a request target list, the sorting of the request target list needs to be updated. This includes inserting the second request target into the appropriate position in the list to maintain the list sorted from highest to lowest request frequency. Simultaneously, if the request target list is full, the system needs to remove one or more request targets from the list to make room for a new second request target.

[0115] Additionally, whether a request target is managed by the request target list can be indicated by its list index, which points to the position of the request target in the request target list. The list index can be represented by `TOPN_index`. The larger the value of `TOPN_index`, the higher the corresponding request target is in the request target list, and the greater the number of requests it will receive. A value of 0 for `TOPN_index` indicates that the corresponding request target is not managed by the request target list.

[0116] When a new request is written to the underlying data area, a minimum of one comparison is performed. A maximum of N comparisons are performed, where N is the number of the first request target managed by the request target list. Due to the imbalance of requests, the request target list is updated with only one comparison for the vast majority of requests.

[0117] By employing embodiments of this disclosure, dynamic management of the request target list enables real-time response to the current request status of the target gateway, ensuring the accurate identification of top-ranking request targets. When the target gateway is in a pre-controlled zone, effective management and monitoring of request targets contribute to maintaining system stability. When a second request target is managed, the order of the request target list is updated promptly to ensure the list always reflects the current request status. This real-time update mechanism improves the system's response speed and accuracy.

[0118] In one optional embodiment, determining whether the second request target is managed by the request target list includes: if the number of the second request is less than or equal to the number of the first request, determining that the second request target is not managed by the request target list; if the number of the second request is greater than the number of the first request, replacing the second request target with the last position of the first request target, so that the second request target is managed by the request target list.

[0119] If the number of requests for the second request target is greater than the number of requests for the first request target at the very end, it indicates that the second request target has a higher number of requests and is therefore a more important target for the system to monitor. Consequently, the second request target needs to replace the first request target in the request target list; that is, the second request target should be moved to the very end of the list, and the original first request target will no longer be managed by the list. In practice, the index of the last data area in the request target list points to the index of the second request target in the underlying data area, and the list index corresponding to the second request target points to the index of the very end of the request target list, specifically 1.

[0120] If the number of requests for the second request target is less than or equal to the number of requests for the first request target at the very end, it means that the number of requests for the second request target is low or equal, and there is no need to replace the first request target being compared in the request target list management.

[0121] If the second request target needs to replace the first request target being compared, and the request target list is managed by the request target list, the request target list will be updated. Specifically, the sorting of the request target list can be updated to ensure that the list is arranged from high to low according to the number of requests.

[0122] If the second request target does not need to replace the first request target being compared, and the request target list is managed by the request target list, there is no need to update the request target list; maintain the state before the comparison with the second request target. End the process.

[0123] Therefore, the request target list can be updated with the fewest number of comparisons. For example, in this embodiment, if the number of second requests is less than the number of first requests, it means that the current request target list does not need to be updated, and only one comparison was performed, without traversing all elements in the request target list.

[0124] In one specific implementation, when request data is written to the underlying data area, the TOPN_index of the second request target corresponding to the request data is 0 by default. The second request count of the second request target is compared with the minimum first request count in the request target list. If it is less than or equal to, the comparison stops; if it is greater, the order is swapped with the minimum first request target, and the TOPN_index of the second request target points to the last index of the request target list.

[0125] By employing embodiments of this disclosure, a second request target is inserted into the request target list through replacement, ensuring that the request target list always maintains the latest high-frequency request data and enhancing the system's dynamic adaptability. Through simple comparison and exchange logic, the algorithm's implementation is intuitive, easy to understand and maintain. This simplified design reduces the complexity of development and maintenance. Because the request target list is updated in real time, the system can quickly locate high-frequency requests affecting services, facilitating troubleshooting and handling by operations and maintenance personnel, and improving system maintainability.

[0126] In one optional embodiment, when the second request target is managed by the request target list, updating the sorting of the request target list includes: comparing the second request count corresponding to the second request target with the first request count corresponding to the previous first request target; updating the sorting of the request target list if the second request count is less than or equal to the first request count; swapping the positions of the first request target and the second request target if the second request count is greater than the first request count; and comparing the second request count with the first request count corresponding to the previous first request target sequentially according to the above steps until there is no previous first request target, or if the second request count is less than or equal to the first request count, updating the sorting of the request target list.

[0127] If a request target is already managed by the request target list, the request target also needs to be compared with other request targets managed by the request target list to determine whether the order of the request target list should be updated.

[0128] In the request target list, find the first request target that precedes the second request target, and obtain its request count, i.e., the first request count. The second request target is a newly managed request target in the request target list or a request target whose request count has changed. The first request target is a request target that was previously managed by the request target list.

[0129] Compare the number of second requests to the second request target with the number of first requests to the first request target.

[0130] If the number of requests for the second request is less than or equal to the number of requests for the first request, it means that the number of requests for the target of the second request is not high enough, and there is no need to swap positions. The update process ends.

[0131] If the number of second requests exceeds the number of first requests, the second request target and the first request target are swapped. The TOPN_index of the second request target can be set to a new position, which is the position of the second request target in the request target list after the replacement operation. This position can indicate which position the second request target is in the request target list. The index of the data area managed by this position in the request target list is modified to the subscript of the second request target in the index area.

[0132] After the second request target is swapped, it continues to be compared with the first request target preceding the second request target until there is no preceding first request target, or the number of second requests is less than or equal to the number of first requests, at which point the sorting of the request target list is completed.

[0133] Once there are no more preceding first request targets to compare, or all necessary swaps have been completed (the number of second requests is less than or equal to the number of first requests), the process of updating the sorting of the request target list ends.

[0134] By employing embodiments of this disclosure, the system can update the request target list in real time by comparing request counts and performing necessary swaps. This ensures the list always reflects the frequency of current requests, enabling the system to quickly respond to traffic changes and adjust processing strategies promptly. During the update process, only necessary elements are compared, avoiding traversal of the entire list, reducing computational complexity, and improving system processing efficiency. Through continuous comparison and swapping, the system ensures that the target with the highest request count always remains at the top of the list. In the event of a sudden surge in traffic, the system can quickly adjust the order of request targets and promptly identify new high-frequency requests.

[0135] The algorithm disclosed herein for confirming the list of request targets enables the real-time acquisition of millions of request targets within milliseconds, including TOPN domain names and IPs, when the target gateway is in the pre-control zone. This allows for the rapid identification of the request targets that are truly causing service overload on the target gateway.

[0136] In addition, after obtaining the target of the TOPN request, an alarm can be used to determine whether intervention is required.

[0137] Figure 2 This is a schematic diagram illustrating a request target list confirmation algorithm according to an embodiment of this disclosure. The TOPN region shown in the diagram corresponds to the request target list, and the data region is the area where the request targets are actually stored. The comparison rules include two cases:

[0138] In the first case, if the request target to be compared is not located in the TOPN region, then it is compared with each of the first request targets managed in the request target list in reverse order, until the number of requests of the request target to be compared is less than or equal to the number of requests of the first request target. Otherwise, the order of the request target is swapped with the first request target in the request target list.

[0139] In the second scenario, if the request target to be compared is located in the TOPN region, then the request target to be compared is only compared sequentially with each of the first request targets preceding it, until the number of requests of the request target to be compared is less than or equal to the number of requests of the first request target. Otherwise, the order of the request target is swapped with the first request target in the request target list.

[0140] Figure 3 This is a schematic diagram illustrating a specific implementation of the verification algorithm shown in this embodiment of the disclosure. It includes steps 1-7.

[0141] Step 1: A new request data is written to the data area. The request target corresponding to this request data is determined to be 222.222.222.222. This request target is designated as the second request target. The second request count corresponding to this second request target is 9. The initial list index is 0 by default.

[0142] Step 2: Find the index of the data area at the very end of the request target list, following the order from back to front.

[0143] Step 3: Based on the data area index, find the actual first request target in the data area. The number of requests for the first request target is 2.

[0144] Step 4: Compare the number of requests for the second request target with the number of requests for the first request target. At this point, determine that the number of requests for the second request is greater than the number of requests for the first request.

[0145] Step 5: Swap the first request target and the second request target. Specifically, the list index corresponding to the second request target is set to the last index of the request target list, and the data area index corresponding to the last index of the request target list is set to the index of the second request target in the data area.

[0146] Step 6: The second request target continues to be compared with the previous first request target in reverse order. At this point, the first request count of the first request target is determined to be 6 by using the index of the previous data area to point to the actual first request target. At this time, the second request count is greater than the first request count.

[0147] Step 7: Swap the order of the second request target and the first request target. Specifically, the list index of the second request target points to the index of the second-to-last element in the request target list, and the data area index corresponding to the second-to-last element in the request target list points to the index of the second request target in the data area. Continue comparing it with the previous first request target, but now the first request target has a first request count of 10, and the second request count is less than the first request count, thus obtaining the final result.

[0148] In one optional embodiment, when the target gateway is in the overload zone, an upper limit control is applied to the number of requests for the first request target in the request target list, including: determining a control reference value based on the request status of the request target list in the pre-control zone; and applying a step-wise upper limit control to the target control index of the first request target in the request target list based on the control reference value; wherein the target control index represents the number of requests made by the first request target per unit time.

[0149] Monitor the health value and current request status of the target gateway in real time to confirm that it is in the overload zone.

[0150] The control reference value can be the average number of requests to the first target when the target gateway is in the pre-control zone.

[0151] Since key top-level request targets have been identified in real-time while the target gateway is in the pre-control zone, all first-level request targets, including the first-level request targets and their corresponding request counts, can be directly extracted from the current request target list. Based on the request data from the pre-control zone, control reference values ​​are calculated.

[0152] Figure 4 This is a schematic diagram illustrating real-time sorting of a request target list according to an embodiment of this disclosure. According to... Figure 4 As shown, when it is necessary to obtain the sorted results in the list of request targets, the list of request targets can be traversed in order from front to back. Based on the data area index pointed to by the corresponding data area index, the specific location of the data area can be located to obtain the actual first request target.

[0153] Define a clear target control metric, namely the maximum allowed number of requests for the primary target request per unit of time. This target control metric can be QPS (Queries Per Second). By setting an upper limit on this target control metric, the upper limit on the number of primary requests for the primary target request can be achieved.

[0154] The target control indicators are subject to tiered upper limit control. Tiered upper limit control means setting multiple adjustment cycles, with each adjustment cycle using a stricter upper limit control strategy compared to the previous one.

[0155] By employing embodiments of this disclosure and controlling the upper limit on the number of requests to the first target, request traffic under overload conditions can be effectively reduced, preventing the exhaustion of target gateway resources and ensuring system stability and reliability. Implementing upper limit control avoids request failures due to overload, thereby improving the user experience and ensuring that user requests are processed promptly. Step-by-step upper limit control allows the system to gradually reduce the upper limit on the number of requests over different time periods. This flexible control method can better adapt to traffic fluctuations and reduce the impact on the system.

[0156] In one optional embodiment, a tiered upper limit control is applied to the target control indicators of the request target list based on a control reference value. This includes: determining the time period and reduction ratio of the tiered upper limit control; identifying the first request target with the highest number of first requests in the request target list as the control request target; determining the upper limit value corresponding to the control period based on the control reference value and the reduction ratio; determining the upper limit value as the target control indicator upper limit for the control request target within the control period; and forwarding requests from the control request target that exceed the target control indicator upper limit to a high-performance sandbox, where the high-performance sandbox is an isolated environment or node used for processing requests.

[0157] Historical data over a period of time can be analyzed to understand fluctuations in request volume, peak periods, and trough periods. Based on historical data and analysis results, a tiered upper limit control time period can be set. The upper limit control strategy differs for each time period. Based on the system's actual needs and historical data, an appropriate reduction ratio is selected; this ratio will be used to calculate the new upper limit.

[0158] Extract all first request targets and their corresponding first request counts from the request target list. The first request target with the highest first request count is identified as the control request target and will be the focus of subsequent control. The first request target with the highest first request count will be updated in real time during the tiered upper limit control process; the updated first request target with the highest first request count will be identified as the control request target.

[0159] Based on the request situation when the target gateway is in the pre-control zone, obtain the control reference value. The control reference value is determined based on the target control indicators of the target request over a period of time, such as the average number of requests to the target request over a period of time.

[0160] Multiply the reference value for regulation by the downward adjustment ratio to calculate the upper limit of the current regulation cycle. This upper limit refers to the upper limit of the target regulation indicator for QPS.

[0161] Within the current control period, the calculated upper limit value will be set as the upper limit of the target control indicator for the control request target, ensuring that the number of requests for the control request target does not exceed this number within the period.

[0162] During the control period, the number of requests to the target control request can be monitored in real time to ensure that it does not exceed the set upper limit. If the number of requests to the target control request exceeds the upper limit of the target control indicator, a forwarding mechanism is triggered. Requests exceeding the upper limit are forwarded to a high-performance sandbox node. This node is an isolated environment specifically designed to handle these excessive requests, ensuring normal access for users without affecting the stability of the main system.

[0163] In one specific implementation, with a current adjustment tier ratio of 0.8, assuming the target adjustment index for the requested domain within the pre-control zone is 1000 per unit time, then the upper limit of the target adjustment index for this domain in the first time period is set to 1000 * 0.8 = 800. Therefore, within the first time period, the target adjustment index for the requested domain cannot exceed 800; any excess must be forwarded. If the target gateway is still in the overload zone at the end of the first time period, then a second time period begins. The upper limit of the second time period can be determined from the upper limit of the first time period. Thus, in the second time period, the upper limit of the target adjustment index for this domain is set to 800 * 0.8 = 640. In the second time period, 640 is used as the upper limit to control the target adjustment index of the requested domain. Throughout the second period, any portion of the target adjustment index exceeding 640 is forwarded to the high-performance sandbox node.

[0164] After the control period ends, the performance of the control request targets can be evaluated by analyzing data such as the number of requests and the number of forwarded requests to determine the effectiveness of the upper limit control. Based on the evaluation results, the time period, the reduction ratio, or other relevant parameters can be adjusted to improve the subsequent control effect and system performance.

[0165] By employing embodiments of this disclosure, setting an upper limit on the number of requests effectively controls traffic, preventing system overload due to excessive requests and thus improving system stability and reliability. The upper limit is dynamically calculated based on a control reference value and a reduction ratio, allowing the system to flexibly adjust according to actual request conditions, enhancing its adaptability and responsiveness. Forwarding requests exceeding the limit to a high-performance sandbox avoids request failures due to overload, improving user experience and ensuring user requests are properly processed. As business needs change, the system can flexibly adjust the upper limit control strategy, supporting future expansion and upgrades, ensuring the system continuously adapts to evolving business requirements.

[0166] In one optional embodiment, determining the control reference value based on the request status of the request target list in the pre-control zone includes: determining the target control index value corresponding to each first request target in the request target list when the target gateway is in the pre-control zone; determining the average control value corresponding to each first request target based on the sampling period and the value of the target control index; and determining the control reference value through the average control value.

[0167] Continuously monitor the request status of each primary request target in the request target list, record the request data within the pre-control zone, and ensure the accuracy and timeliness of the data. Determine the number of requests received by each primary request target within a certain period of time, i.e., the value of the target control indicator corresponding to each primary request target.

[0168] A suitable sampling period can be set to calculate the average control value of the requested target. For example, the past one minute, five minutes, etc.

[0169] By statistically analyzing each first request target in the request target list within the sampling period, and then dividing the total number of requests by the sampling period length, the corresponding average control value is obtained. For example, if the sampling period is expressed in seconds within a 5-minute sampling period, and the total number of requests for a certain TOPN domain is 3000, then its average QPS is 3000 / 300 = 10 QPS.

[0170] The average control values ​​of all first-request targets can be aggregated to form a control reference value list. Based on business needs and system performance, an appropriate control reference value can be selected from the average control values; this can be the average, median, or other statistical methods used for all targets. Alternatively, the average control value corresponding to the first-request target can be used as the control reference value for that first-request target.

[0171] By employing embodiments of this disclosure, and through real-time monitoring of the request targets and calculation of control reference values, traffic control strategies can be adjusted promptly to avoid system overload and ensure service stability. When the system is in a pre-control zone, potential traffic anomalies can be identified in advance, and corresponding control measures can be taken to reduce the risk of service interruption. Through dynamic calculation of control reference values, the system can quickly adapt to traffic changes, supporting more request targets and business expansion.

[0172] In one optional embodiment, the method further includes: during the process of implementing tiered upper limit control on the target control indicators of the first request target in the request target list, updating the first request target with the highest number of first requests in the request target list in real time; and determining the state partition where the target gateway is located in real time; and stopping the tiered upper limit control on the target control indicators of the first request target in the request target list when the target gateway recovers to the healthy zone or the pre-control zone.

[0173] Continuously monitor the number of requests for each first request target in the request target list.

[0174] Specifically, an appropriate time window can be set to count and update the number of requests. At the end of each time window, the number of requests for all first request targets in the request target list is compared. The first request target with the highest number of requests is identified in real time.

[0175] If the target with the highest number of requests is updated, and the current target gateway is still in the overload zone, then the upper limit of the target with the highest number of requests after the update will be controlled.

[0176] Periodically acquire metrics such as the target gateway's machine health value, cumulative first data month-on-month change, and cumulative second data month-on-month change to determine its current status zone. Once the target gateway recovers to the healthy zone or pre-control zone, immediately cease the tiered upper limit control on the current highest request target. After ceasing upper limit control, resume normal request processing flow, allowing the current highest request target to accept more requests.

[0177] Based on the implementation results and changes in the status of the target gateway, adjust the monitoring and control strategies in a timely manner to ensure stable system operation.

[0178] By employing embodiments of this disclosure, the system can quickly identify and appropriately regulate the first request target with the highest number of requests in the request target list through real-time updates, thereby effectively managing request traffic. Regularly acquiring indicators such as the machine health value and cumulative data comparison of the target gateway provides a basis for judging the system status, enabling timely adjustments to monitoring and control strategies to ensure stable system operation under different loads. When the target gateway recovers to the healthy zone or pre-control zone, the tiered upper limit control automatically stops, restoring the normal request processing flow and reducing manual intervention.

[0179] Figure 5 This is a schematic diagram illustrating the overall decision-making process for a gateway service overload analysis and decision-making method as shown in an embodiment of this disclosure. According to... Figure 5 As shown, real-time data metrics such as QPS and abnormal request percentage are obtained; machine health values ​​are acquired; if various metrics are below the health zone threshold, the target gateway is determined to be in the health zone, and no further decisions are made; if various metrics are above the pre-control zone threshold, the target gateway is determined to be in the pre-control zone, and a request target list is determined in real-time based on a sliding window, which can be reported to the monitoring component; if various metrics are above the overload zone threshold, a tiered upper limit control is implemented based on the request target list, and the excess is triggered to forward to the high-performance sandbox.

[0180] Figure 6 This is a flowchart illustrating a gateway service overload analysis and decision-making method according to an embodiment of this disclosure. Figure 6 As shown:

[0181] The first step is to collect metric data and calculate the month-on-month comparison. The CDN gateway collects the QPS of requests in real time and the percentage of abnormal requests per minute. At the same time, according to the month-on-month comparison formula, the month-on-month increase rate of QPS and the increase rate of abnormal requests are obtained.

[0182] The second step is to obtain machine health values. The CDN gateway, i.e., the target gateway, periodically obtains machine health values, which represent the quality coefficient of the server. The machine health value is modeled based on six indicators: CPU utilization, disk I / O utilization, machine I / O load, memory utilization, network card utilization, and service port response time. The overall calculation approach is to first smooth each indicator using an exponentially weighted moving average algorithm, and then normalize it using the min-max standard.

[0183] The third step is to locate the status partition based on multiple metrics. The CDN gateway makes a comprehensive judgment based on data such as the QPS month-on-month surge rate, the abnormal percentage surge rate, and machine health values ​​from the first and second steps, thereby determining which partition the service is currently in.

[0184] Fourth step: If the location is in the healthy zone, no additional operation is required, and the current cycle can be ended directly.

[0185] Fifth step: If the location is within the pre-controlled area, proceed to the sixth step.

[0186] Step 6: Real-time analysis based on a sliding window. The gateway enables real-time analysis. At this time, the CDN gateway receives a large number of requests, and the request data changes dynamically. The requests are sorted in real time to obtain the top N request targets, which include domain names and access IPs.

[0187] Step 7: Record the QPS of the TOPN request target as the initial baseline value. The QPS of the TOPN request target can be obtained in real time based on the results of step 6, and used as the initial baseline value.

[0188] Step 8: The CDN gateway is already in a sub-healthy state. At this time, the TOPN data results can be reported to the alarm component to provide early warning.

[0189] Step 9: If the location is in the overload zone, proceed to step 10.

[0190] Step 10: Obtain the average QPS of the TOPN request target during the sampling period. The service status is already in an extremely unhealthy state, therefore, it is necessary to enable self-preservation mode to control the upper limit of the QPS of the TOPN request target. Based on step 6, the QPS of the TOPN request target can be obtained directly, thus allowing us to directly obtain the average QPS of the TOPN request target during the sampling period.

[0191] Step 11: Obtain the QPS cap for each TOPN request target based on the step ratio. Multiply the result of step 10 by the preset step ratio to obtain the QPS cap for each request target in TOPN.

[0192] Step 12: Develop a self-protection strategy based on the upper limit. The CDN gateway executes the corresponding limiting strategy based on the QPS limit of each request target of TOPN obtained in Step 11. The effective period lasts until the next cycle.

[0193] Step 13: Determine if the current TOPN request target QPS exceeds the limit. Based on the self-preservation strategy in step 12, continuously check if the current QPS exceeds the limit. If it does, proceed to step 14.

[0194] Step 14: Forward excess requests to sandbox nodes. Forward any TOPN requests exceeding the QPS limit to high-performance sandbox nodes in the same region based on the accessing IP address, ensuring normal user access.

[0195] Based on the same technical concept, this disclosure provides an analysis and decision-making device for gateway service overload. Figure 7 This is a block diagram illustrating a gateway service overload analysis and decision-making device according to an embodiment of this disclosure. Figure 7 As shown, the device includes:

[0196] The data acquisition module 710 is used to acquire the operating status data of the target gateway, wherein the operating status data represents the health status of the target gateway;

[0197] The matching module 720 is used to determine the current state partition of the target gateway based on the operating status data: the state partition includes a health zone, a pre-control zone, and an overload zone;

[0198] Analysis module 730 is used to determine a request target list based on the current request status of the target gateway when the target gateway is in the pre-control zone; the request target list manages a preset first request target with the highest number of requests.

[0199] The decision module 740 is used to control the upper limit of the number of requests for the first request target in the request target list when the target gateway is in the overload zone.

[0200] This disclosure also provides an electronic device, with reference to... Figure 8 , Figure 8 This is a schematic diagram of an electronic device according to an embodiment of this disclosure. For example... Figure 8 As shown, the electronic device 800 includes a memory 810 and a processor 820. The memory 810 and the processor 820 are connected via a bus. The memory 810 stores a computer program that can run on the processor 820 to implement the steps in the analysis and decision-making method for gateway service overload disclosed in this embodiment.

[0201] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in the gateway service overload analysis and decision-making method disclosed in this disclosure.

[0202] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the steps in the gateway service overload analysis and decision-making method disclosed in this disclosure.

[0203] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0204] Those skilled in the art will understand that the embodiments disclosed herein can be provided as methods, apparatus, or computer program products. Therefore, the embodiments disclosed herein can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments disclosed herein can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0205] This disclosure describes embodiments of methods, apparatus, electronic devices, and computer program products according to embodiments of this disclosure with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0206] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0207] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0208] Although some embodiments of the present disclosure have been described, those skilled in the art, upon learning the basic inventive concept, can make further changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the present disclosure.

[0209] The above provides a detailed description of the analysis and decision-making method and apparatus for gateway service overload provided by this disclosure. Specific examples have been used to illustrate the principles and implementation methods of this disclosure. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this disclosure. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this disclosure. Therefore, the content of this specification should not be construed as a limitation of this disclosure.

Claims

1. A method for analyzing and making decisions regarding gateway service overload, characterized in that, include: Obtain the operating status data of the target gateway, wherein the operating status data represents the health status of the target gateway; Based on the operational status data, the current state partition of the target gateway is determined: the state partition includes a health zone, a pre-control zone, and an overload zone; When the target gateway is in the pre-control zone, a list of request targets is determined based on the current request status of the target gateway. The list of request targets is determined based on the number of requests made by each target, and the target targets are determined based on their domain names and IP addresses. The list of request targets manages a preset first request target with the highest number of requests. When the target gateway is in the overload zone, the number of first requests to the first target in the request target list is capped. This includes obtaining the target gateway's operational status data, including: Collect first and second data from the target gateway. The first data is QPS, and the second data is the percentage of abnormal requests. Based on the first data and the second data, determine the cumulative month-on-month change of the first data and the cumulative month-on-month change of the second data, respectively; The machine health value of the target gateway is obtained through data modeling; Based on the operational status data, the current state partition of the target gateway is determined, including: The cumulative first data month-on-month change, the cumulative second data month-on-month change, and the machine health value are compared with their respective thresholds to obtain comparison results; Based on the comparison results, the state partition in which the target gateway is located is determined.

2. The method according to claim 1, characterized in that, Each first request target managed by the request target list is sorted in the request target list according to its corresponding number of first requests; When the target gateway is within the pre-control zone, a list of request targets is determined based on the current request status of the target gateway, including: When a new request is written to the underlying data area of ​​the target gateway, the second request target corresponding to the new request is determined; The number of second requests corresponding to the second request target is compared with the number of first requests corresponding to the first request target at the end of the request target list. The number of first requests corresponding to the first request target at the end of the request target list is the number of first requests with the fewest number of times in the request target list. Based on the comparison results, determine whether the second request target is managed by the request target list; If the second request target is managed by the request target list, update the sorting of the request target list.

3. The method according to claim 2, characterized in that, Based on the comparison results, determining whether the second request target is managed by the request target list includes: If the number of the second request is less than or equal to the number of the first request, it is determined that the second request target is not managed by the request target list; If the number of second requests is greater than the number of first requests, the second request target is replaced by the last position of the first request target, so that the second request target is managed by the request target list.

4. The method according to claim 2, characterized in that, When the second request target is managed by the request target list, updating the sorting of the request target list includes: Compare the number of second requests corresponding to the second request target with the number of first requests corresponding to the previous first request target; If the number of the second request is less than or equal to the number of the first request, the sorting of the request target list is updated. If the number of second requests is greater than the number of first requests, swap the positions of the first request target and the second request target. The above steps are followed to compare the number of requests with the number of requests corresponding to the previous first request target in turn, until there is no previous first request target, or the number of requests is less than or equal to the number of requests, at which point the sorting of the request target list is completed.

5. The method according to claim 1, characterized in that, When the target gateway is in the overload zone, an upper limit is imposed on the number of first requests to the first target in the request target list, including: Based on the request status of the requested target list in the pre-control zone, determine the control reference value; Based on the control reference value, a tiered upper limit control is applied to the target control index of the first request target in the request target list; the target control index represents the number of requests made by the first request target per unit time.

6. The method according to claim 1, characterized in that, Based on the control reference value, a tiered upper limit control is applied to the target control indicators of the requested target list, including: Determine the time period and downward adjustment ratio for the tiered upper limit control; The first request target with the highest number of first requests in the request target list is determined as the control request target; Based on the aforementioned control reference value and the aforementioned reduction ratio, the upper limit value corresponding to the control cycle is determined; Within the control period, the upper limit value is determined as the upper limit of the target control indicator for the control request target; Requests exceeding the upper limit of the target control index are forwarded to a high-performance sandbox, which is an isolated environment or node for processing requests.

7. The method according to claim 5, characterized in that, Based on the request status of the target list in the pre-control zone, determine the control reference value, including: Based on the target gateway being in the pre-control zone, the values ​​of the target control indicators corresponding to each first request target in the request target list; Based on the sampling period and the value of the target control index, determine the average control value corresponding to each first request target; The control reference value is determined by averaging the control values.

8. The method according to any one of claims 5-7, characterized in that, Also includes: During the process of implementing tiered upper limit control on the target adjustment index of the first request target in the request target list, the first request target with the largest number of first requests in the request target list is updated in real time. In addition, the state partition in which the target gateway is located is determined in real time; If the target gateway recovers to the healthy zone or the pre-control zone, the tiered upper limit control of the target regulation index of the first requested target in the requested target list shall be stopped.

9. A gateway service overload analysis and decision-making device, characterized in that, include: The data acquisition module is used to acquire the operating status data of the target gateway, wherein the operating status data represents the health status of the target gateway; The matching module is used to determine the current state partition of the target gateway based on the operating status data: the state partition includes a health zone, a pre-control zone, and an overload zone; The analysis module is used to determine a list of request targets based on the current request status of the target gateway when the target gateway is in the pre-control zone. The list of request targets is determined based on the number of requests made by each target, and the target targets are determined based on their domain names and IP addresses. The list of request targets manages a preset first request target with the highest number of requests. The decision module is used to control the upper limit of the number of requests for the first request target in the request target list when the target gateway is in the overload zone; The data acquisition module is further configured to: Collect first and second data from the target gateway. The first data is QPS, and the second data is the percentage of abnormal requests. Based on the first data and the second data, determine the cumulative month-on-month change of the first data and the cumulative month-on-month change of the second data, respectively; The machine health value of the target gateway is obtained through data modeling; The matching module is also used for: The cumulative first data month-on-month change, the cumulative second data month-on-month change, and the machine health value are compared with their respective thresholds to obtain comparison results; Based on the comparison results, the state partition in which the target gateway is located is determined.

Images