Gateway service overload analysis decision method and device

Abstract

The invention provides an analysis and decision method and device for gateway service overload. The objective of the invention is to realize that a target gateway needs to have a certain self-protection capability when a service is overloaded, and the stability and reliability of the target gateway service are ensured. The method comprises the following steps: acquiring operation state data of a target gateway, wherein the operation state data represents a health state of the target gateway; determining a current state partition of the target gateway according to the running state data, wherein the state partition comprises a healthy area, a pre-control area and an overload area; under the condition that the target gateway is in the pre-control area, determining a request target list according to the current request condition of the target gateway; the request target list manages a preset number of first request targets with the maximum request times; and under the condition that the target gateway is in the overload area, performing upper limit control on a first request frequency of a first request target in the request target list.

Description

Technical Field

[0001] The present disclosure relates to the technical field of content distribution networks, and in particular to a gateway service overload analysis and decision-making method and device. Background Art

[0002] CDN (Content Delivery Network) integrates global node resources to provide local distribution services to customers in various regions. Currently, nearly 80% of global traffic is accelerated by CDN. CDN gateway is the first "entrance" after user request distribution. After processing the request according to user configuration, it pulls the requested content from the source station and caches it in the CDN cache module.

[0003] In normal scenarios, the CDN gateway receives access requests from various users and provides services for them. However, in some scenarios, there will be bursts of traffic accessing the CDN node, causing a sudden increase in the number of requests from edge machines in a short period of time. A large number of requests accessing at the same time will also occupy server resources until the resources are exhausted or even crash.

[0004] Therefore, when the service is overloaded, the CDN gateway needs to have a certain self-protection capability to ensure the stability and reliability of the CDN service. Summary of the invention

[0005] In order to overcome the problems existing in the related art, the present disclosure provides a gateway service overload analysis and decision-making method and device. The technical solution of the present disclosure is as follows: According to a first aspect of an embodiment of the present disclosure, a gateway service overload analysis and decision-making method is provided, comprising: Acquire operation status data of the target gateway, wherein the operation status data represents the health status of the target gateway; According to the running status data, determining the current state partition of the target gateway, wherein the state partition includes a healthy zone, a pre-control zone, and an overload zone; When the target gateway is in the pre-control area, a request target list is determined according to the current request status of the target gateway; the request target list manages a preset first request target with the largest number of requests; When the target gateway is in the overload zone, an upper limit control is performed on the first request number of the first request target in the request target list.

[0006] Optionally, each first request target managed by the request target list is sorted in the request target list according to the first request times corresponding to each of them; when the target gateway is in the pre-control area, the request target list is determined according to the current request situation of the target gateway, including: In the case where a new request is written to the underlying data area of ​​the target gateway, determining a second request target corresponding to the new request; Compare the second request number corresponding to the second request target with the first request number corresponding to the first request target at the end of the request target list, the first request number corresponding to the first request target at the end of the request target list being the first request number with the least number of times in the request target list; Determining, according to the comparison result, whether the second request target is managed by the request target list; In a case where the second request target is managed by the request target list, the order of the request target list is updated.

[0007] Optionally, determining, according to the comparison result, whether the second request target is managed by the request target list includes: When the second request number is less than or equal to the first request number, determining that the second request target is not managed by the request target list; When the second request number is greater than the first request number, the second request target is replaced to the position of the last first request target, so that the second request target is managed by the request target list.

[0008] Optionally, in a case where the second request target is managed by the request target list, updating the sorting of the request target list includes: Compare the second request number corresponding to the second request target with the first request number corresponding to the previous first request target; When the second request number is less than or equal to the first request number, completing updating the sorting of the request target list; When the second request number is greater than the first request number, exchanging the positions of the first request target and the second request target; According to the above steps, the first request number corresponding to the previous first request target is compared in sequence until there is no previous first request target, or the second request number is less than or equal to the first request number, and the update of the sorting of the request target list is completed.

[0009] Optionally, when the target gateway is in the overload zone, upper limit control is performed on the first request number of the first request target in the request target list, including: Determining a control reference value according to a request status of the request target list in the pre-control area; According to the control reference value, a target control index of the first request target in the request target list is subjected to step-by-step upper limit control; the target control index represents the number of requests for the first request target per unit time.

[0010] Optionally, according to the control reference value, stepwise upper limit control is performed on the target control index of the request target list, including: Determine the time period and downward adjustment ratio of the step-up upper limit control; Determine the first request target with the largest number of first requests in the request target list as the control request target; Determining an upper limit value corresponding to a control cycle according to the control reference value and the downward adjustment ratio; In the control cycle, the upper limit value is determined as the upper limit of the target control indicator of the control request target; The control request target, requests that exceed the upper limit of the target control indicator, are forwarded to a high-performance sandbox, which is an isolated environment or node for processing requests.

[0011] Optionally, determining the control reference value according to the request status of the request target list in the pre-control area includes: According to the case where the target gateway is in the pre-control area, the value of the target regulation indicator corresponding to each first request target in the request target list; Determine, according to the sampling period and the value of the target control index, the average control value corresponding to each first request target; The control reference value is determined by averaging the control values.

[0012] Optionally, it also includes: In the process of performing step-by-step upper limit control on the target regulation indicator of the first request target in the request target list, updating the first request target with the largest number of first requests in the request target list in real time; and determining the state partition of the target gateway in real time; When the target gateway is restored to the healthy zone or the pre-control zone, the step-by-step upper limit control of the target regulation indicator of the first request target in the request target list is stopped.

[0013] Optionally, obtain the running status data of the target gateway, including: Collecting first data and second data of a target gateway; Determine, based on the first data and the second data, respectively a cumulative first data year-on-year increase and a cumulative second data year-on-year increase; Through data modeling, the machine health value of the target gateway is obtained; Determining the current state partition of the target gateway according to the running state data includes: Compare the accumulated first data on a month-on-month basis, the accumulated second data on a month-on-month basis, and the machine health value with corresponding thresholds to obtain a comparison result; According to the comparison result, the state partition of the target gateway is determined.

[0014] According to a second aspect of an embodiment of the present disclosure, a gateway service overload analysis and decision-making device is provided, comprising: A data acquisition module, used to acquire the operation status data of the target gateway, wherein the operation status data represents the health status of the target gateway; A matching module, used to determine the state partition of the target gateway according to the running state data, wherein the state partition includes a healthy zone, a pre-control zone and an overload zone; An analysis module is used to determine a request target list according to the current request status of the target gateway when the target gateway is in the pre-control area; the request target list manages a preset first request target with the largest number of requests; The decision module is used to perform an upper limit control on the first request number of the first request target in the request target list when the target gateway is in the overload area.

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

[0016] According to a fourth aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of analyzing and deciding on gateway service overload as described in the first aspect are implemented.

[0017] According to a fifth aspect of an embodiment of the present disclosure, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the steps of analyzing and deciding on gateway service overload described in the first aspect are implemented.

[0018] The present disclosure can monitor the health status of the gateway in real time by acquiring the operating status data of the target gateway, and divide the status of the target gateway into a healthy zone, a pre-control zone, and an overload zone based on the operating status data, so that the system can take corresponding measures according to different states, thereby improving the efficiency and accuracy of responding to gateway service overloads and ensuring timely intervention when requests suddenly increase. When the gateway is in the pre-control zone, the request target list can be determined according to the current request situation, so that when the gateway is in the overload zone, the domain name that actually causes the gateway overload problem can be quickly located and processed. When the gateway is in the overload zone, the user experience problem caused by directly rejecting new requests is avoided by upper-limiting the number of requests for the first request target in the request target list. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0020] Figure 1 It is a schematic diagram of the steps of a gateway service overload analysis and decision-making method shown in an embodiment of the present disclosure; Figure 2 is a schematic diagram of a confirmation algorithm for requesting a target list shown in an embodiment of the present disclosure; Figure 3 is a schematic diagram of a specific implementation of a confirmation algorithm shown in an embodiment of the present disclosure; Figure 4 is a schematic diagram of real-time sorting of a request target list shown in an embodiment of the present disclosure; Figure 5 It is a general decision diagram of a gateway service overload analysis and decision method shown in an embodiment of the present disclosure; Figure 6 It is a flowchart of a gateway service overload analysis and decision-making method shown in an embodiment of the present disclosure; Figure 7 It is a block diagram of a gateway service overload analysis and decision-making device shown in an embodiment of the present disclosure; Figure 8 It is a schematic diagram of an electronic device shown in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0021] The following will be combined with the drawings in the embodiments of the present disclosure to clearly and completely describe the technical solutions in the embodiments of the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, rather than all of the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present disclosure.

[0022] The terms "first", "second", etc. in the specification and claims of the present disclosure are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable when appropriate, so that the embodiments of the present disclosure can be implemented in an order other than those illustrated or described herein, and the objects distinguished by "first", "second", etc. are generally of the same type, and the number of objects is not limited. For example, the first object can be one or more. In addition, "and / or" in the specification and claims represents at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0023] For ease of understanding, the professional terms involved in the present disclosure are first explained.

[0024] CDN (Content Delivery Network): provides multiple edge cache servers to store the resources required by users in the nearest server, thereby reducing request latency.

[0025] QPS (Queries per second) is a measure of the amount of traffic a specific query server handles within a specified time. On the Internet, the performance of machines that serve as domain name system servers is often measured by the query rate per second.

[0026] CDN's resource management and scheduling capabilities can estimate peak values ​​by analyzing historical node bandwidth and traffic data, but the results of business estimates are likely to deviate from the actual traffic. When the actual requests of the CDN service node exceed the upper limit it can carry, the CDN gateway itself needs to have self-protection capabilities to reduce system pressure and ensure the normal service of most businesses.

[0027] In the current related technologies, the method of handling CDN gateway service overload is to record indicators such as QPS and request failure rate. When the QPS of a single CDN node exceeds the set threshold, the request failure rate is combined to determine whether the service is in an overload state. After the service is overloaded, new requests forwarded to the machine are directly rejected to prevent excessive resource consumption. After turning on overload protection, the service needs to be restored. The current common method is to periodically send a detection signal when the service is in a dormant state to detect whether the CDN node service has returned to normal.

[0028] However, the above CDN service overload processing and recovery solutions still have some problems: (1) The condition for determining service overload is to determine whether indicators such as QPS and request failure rate exceed the threshold. However, in the CDN scenario, the load capacity of the rs machine of each CDN node is different, and the threshold is not easy to set uniformly. In addition, the existing technology for indicators such as QPS and request failure rate usually relies on statistics of gateway access logs. The method of storing logs on disk and then counting them has a lag, and it is very likely that the number of requests has exceeded the CDN service capacity, but has not been processed in time.

[0029] (2) After enabling overload protection, the current common decision is to directly reject new requests to prevent too many requests from crashing the server. However, not all requests are the "culprits" that cause service overload. The top-level domain names with sudden increases in requests should be quickly located and handled in a targeted manner. Secondly, directly rejecting new requests is not user-friendly enough. After the service is overloaded, user availability needs to be guaranteed as much as possible.

[0030] (3) The service recovery plan is to detect the machines that are already in overload protection during the period. However, even if the periodic detection request is successful, it does not mean that the machine can resume normal service status. More indicators still need to be considered. Otherwise, after it is turned on, the CDN machine still has the risk of being exhausted by sudden traffic.

[0031] Therefore, a real-time analysis and decision-making method for CDN gateway service overload is needed. In the scenario of CDN gateway service overload, it can analyze and locate the sudden increase in requests at the domain name granularity in real time, and enable adaptive overload protection and recovery to ensure the stability and reliability of CDN services.

[0032] In order to solve the above problems, the present disclosure provides a gateway service overload analysis and decision-making method, which can perform real-time analysis to quickly locate the sudden increase in requests, and specifically process the top-level domain names with the sudden increase in requests to ensure the availability and stability of CDN services, thereby solving the defects of the existing methods such as low efficiency in locating service overload, direct rejection of all new requests, and low accuracy in restoring services.

[0033] Figure 11 is a schematic diagram of the steps of a gateway service overload analysis and decision-making method shown in an embodiment of the present disclosure. Figure 1 As shown, the method may specifically include the following steps: Step S11: Acquire the running status data of the target gateway, wherein the running status data represents the health status of the target gateway.

[0034] Before the request log is written to the disk, various performance indicators of the target gateway are collected in real time, including but not limited to CPU usage, memory usage, disk IO usage, network bandwidth utilization, service port response time, etc. The total number of requests and abnormal requests per unit time can be counted, and the abnormal request ratio can be calculated. Based on the collected indicator data, the health value of the target gateway is calculated using a preset algorithm.

[0035] The meaning of the stage before requesting the log to be flushed to disk is The running status data is determined based on the health value, abnormal request ratio, etc. The running status data can mark the health status of the current target gateway.

[0036] Step S12: According to the running status data, determine the current state partition of the target gateway: the state partition includes a healthy zone, a pre-control zone and an overload zone.

[0037] The health status can reflect whether the target gateway is overloaded. The service load of the current target gateway can be determined through the running status data, so as to determine which state partition the current target gateway is in.

[0038] When the target gateway is in the healthy zone, it indicates that the gateway is in good operating condition and all performance indicators are within the normal range. No additional intervention or adjustment is required and the system can operate normally.

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

[0040] When the target gateway is in the overload zone, it means that the gateway's operating status is extremely unhealthy and the system can no longer effectively handle the current number of requests, which may cause service interruption or serious degradation of user experience. At this time, immediate measures need to be taken to reduce the current gateway's burden and restore it to a healthy state as soon as possible.

[0041] Step S13: when the target gateway is in the pre-control area, determine a request target list according to the current request status of the target gateway; the request target list manages a preset number of first request targets with the largest number of requests.

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

[0043] Analyze the current request data, determine the number of visits to each request target, and determine the top N request targets with the largest number of visits as the first request targets that need to be managed in the request target list.

[0044] Based on real-time request data, the request target list is updated regularly or irregularly to ensure the accuracy and timeliness of the list.

[0045] Step S14: When the target gateway is in the overload area, an upper limit control is performed on the first request number of the first request target in the request target list.

[0046] The request target list manages a plurality of first request targets, where the first request targets are the request targets ranked top N in terms of the number of requests among the request targets received by the target gateway.

[0047] The upper limit of the first request number of the first request target in the target list can be controlled, so that the request targets with the top request number can be processed in a targeted manner. The upper limit control of the number of first requests to the first request target can be achieved by monitoring the QPS of the first request target and performing upper limit control on the QPS.

[0048] By adopting the embodiments of the present disclosure, the health status of the gateway can be accurately evaluated by acquiring the operating status data of the target gateway in real time. According to the operating status data, the target gateway is divided into a healthy zone, a pre-control zone, and an overload zone. This dynamic partition management can be flexibly adjusted according to the actual load conditions to ensure that appropriate measures are taken in different states. When the gateway is in the pre-control zone, the system can identify potential overload risks in advance and determine the request target list based on the current request situation. Measures can be taken before the problem occurs to reduce the risk. When the gateway enters the overload zone, the system will perform an upper limit control on the first request target with the top request count in the request target list, which can ensure user availability as much as possible when the service is overloaded, avoid directly rejecting requests, and thus improve the user experience.

[0049] Among them, in an optional embodiment, obtaining the operating status data of the target gateway includes: collecting first data and second data of the target gateway; determining the cumulative first data year-on-year and the cumulative second data year-on-year respectively based on the first data and the second data; obtaining the machine health value of the target gateway through data modeling; determining the current state partition of the target gateway based on the operating status data, including: comparing the cumulative first data year-on-year, the cumulative second data year-on-year and the machine health value with corresponding thresholds respectively to obtain a comparison result; determining the state partition of the target gateway based on the comparison result.

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

[0051] Monitor the performance indicators of the target gateway in real time. The first data may be QPS, and the second data may be the abnormal request ratio. The first data and the second data may be obtained through log records, monitoring tools, or API (Application Programming Interface) interfaces. The cumulative first data and the cumulative second data may be determined based on the month-on-month formula, which may specifically be the QPS month-on-month sudden increase rate and the abnormal ratio sudden increase rate.

[0052] Obtain indicator data related to machine performance, such as CPU (Central Processing Unit) usage, memory usage, disk IO (Input / Output) usage, network bandwidth utilization, etc. This can be collected through a monitoring system or performance monitoring tool. These indicator data are used to evaluate the health status of the target gateway through data modeling to obtain the machine health value of the target gateway.

[0053] According to experience or historical data, the threshold of each state partition is set. Specifically, it can be expressed as a threshold of a healthy zone, a threshold of a pre-control zone, and a threshold of an overload zone. The threshold of the healthy zone, the threshold of the pre-control zone, and the threshold of the overload zone can be a comprehensive threshold, which includes the cumulative first data year-on-year, the cumulative second data year-on-year, and the machine health value and the corresponding thresholds.

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

[0055] In a specific implementation, KL can be set as the threshold of the machine health value, RL can be set as the threshold of the QPS month-on-month surge rate, and FL can be set as the threshold of the abnormal proportion surge rate. When the target gateway health value is less than KL, the QPS month-on-month surge rate is less than RL, and the abnormal proportion surge rate is less than FL, the target gateway is in the healthy zone; when the machine health value is greater than KL, and the QPS month-on-month surge rate is higher than RL, the machine is in the pre-control zone; when the machine health value is greater than KH, and the QPS month-on-month surge rate is higher than RH, and the abnormal request proportion is higher than x times the target gateway abnormal request proportion baseline value when it is in the healthy zone, the machine is in the overload zone.

[0056] By adopting the embodiments of the present disclosure, by collecting the indicator data of the target gateway to comprehensively monitor the operation status of the gateway, potential performance bottlenecks and abnormal situations can be discovered in a timely manner. By calculating the month-on-month changes of the cumulative first data and the second data, the changing trend of the gateway performance can be intuitively reflected, which can help the system quickly identify abnormal fluctuations and take timely measures. According to the operating status data and the set thresholds, the target gateway is dynamically divided into a healthy zone, a pre-control zone, and an overload zone, which can be flexibly adjusted according to the actual load conditions to ensure that appropriate measures are taken under different conditions. Through dynamic monitoring and status partition management, the gateway can be effectively prevented from crashing under high load conditions, and the availability of the service can be improved, thereby improving the user experience.

[0057] Among them, in an optional embodiment, each first request target managed by the request target list is sorted in the request target list according to the first request times corresponding to each of them; when the target gateway is in the pre-control area, the request target list is determined according to the current request situation 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 second request times corresponding to the second request target is compared with the first request times corresponding to the first request target at the end of the request target list, and the first request times corresponding to the first request target at the end of the request target list is the first request times with the least times in the request target list; according to the comparison result, it is determined whether the second request target is managed by the request target list; if the second request target is managed by the request target list, the sorting of the request target list is updated.

[0058] When the target gateway enters the pre-control area, real-time analysis based on sliding windows can be started. Under the dynamic change of a large amount of request data, the request times of the request targets can be captured and sorted in real time at the minimum cost. This ensures that the top request targets can be located before the target gateway enters the overload area. These request targets can be managed through the request target list.

[0059] The underlying data area of ​​the CDN gateway allocates a special area as the area corresponding to the request target list. The request target list is an ordered array. The first request target in the request target list is sorted from high to low based on the number of requests. The first request target at the end of the request target list is the request target with the least number of first requests, and the first request target at the beginning of the request target list is the request target with the most number of first requests.

[0060] The request target list is actually an ordered array. Each element in the array represents a request target and its corresponding request count. The last request target is the first request target with the lowest request count in the request target list, and the first request target is the first request target with the highest request count in the request target list. For example, if the request target list manages the top 10 request targets, the first element at the very beginning is the first request target with the highest request count, and the last element is the first request target with the 10th highest request count.

[0061] In order to efficiently manage these request targets, the request target list does not store the first request target itself, but the index of the first request target in the underlying data area, which can be pointed to by the data area index. Whenever a request target needs to be obtained from the request target list, the system will read the specific information of the request target from the underlying data area through its corresponding data area index. In specific implementation, the data area index can be represented by data_index.

[0062] Monitor that a new request arrives at the target gateway, record the relevant information of the request, determine the corresponding second request target according to the content or characteristics of the new request, and determine the second request number of the second request target.

[0063] The first request target at the end is obtained from the request target list, and its corresponding first request number is recorded. In specific implementation, the data area index corresponding to the last element in the request target list can be obtained, and the actual first request target can be accessed from the underlying data area according to the data area index to determine the first request number corresponding to the first request target.

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

[0065] Since the design of the request target list is ordered, after the new request data is inserted, it is only necessary to pay attention to the first request target at the end of the request target list and the second request target corresponding to the current new request data to quickly determine whether the second request target corresponding to the current new request data needs to be managed by the request target list, without traversing the entire request target list. Therefore, at least only one comparison is required to determine whether the second request target is managed by the request target list, thereby determining whether the request target list needs to be updated with the minimum number of comparisons.

[0066] In the case where the second request target is managed by the request target list, the order of the request target list needs to be updated, including inserting the second request target into the appropriate position in the list to keep the list in descending order according to the number of requests. At the same time, if the request target list is full, the system needs to remove one or more request targets in the list to make room for the new second request target.

[0067] In addition, whether a request target is managed by the request target list can be indicated by the list index it carries, and the list index 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 ranking of the corresponding request target in the request target list, and the larger the corresponding number of requests. When the value of TOPN_index is 0, it means that the corresponding request target is not managed by the request target list.

[0068] When a new request is written to the underlying data area, it is compared at least once. It is compared at most N times, where N is the number of first request targets managed by the request target list. Due to the imbalance of requests, most of them only need to be compared once to update the request target list.

[0069] By adopting the embodiments of the present disclosure, through the dynamic management of the request target list, it is possible to respond to the current request situation of the target gateway in real time, ensuring that the request target at the top level of the number of requests is located. When the target gateway is in the pre-control area, the request target can be effectively managed and monitored, which helps to maintain the stability of the system. When the second request target is managed, the order of the request target list is updated in time to ensure that the list always reflects the current request situation. This real-time update mechanism improves the response speed and accuracy of the system.

[0070] Among them, in an optional embodiment, determining whether the second request target is managed by the request target list includes: when the second request number is less than or equal to the first request number, determining that the second request target is not managed by the request target list; when the second request number is greater than the first request number, replacing the second request target to the position of the last first request target so that the second request target is managed by the request target list.

[0071] If the second request number of the second request target is greater than the first request number of the last request target, it means that the second request target has a higher request number and is a request target that needs more attention from the system than the last request target. Therefore, the second request target needs to replace the first request target for comparison and be managed by the request target list, that is, the second request target is replaced to the last position in the request target list, and the first request target, which was originally at the last position, is no longer managed by the request target list. In specific implementation, the last data area index in the request target list points to the subscript of the second request target in the underlying data area, and the list index corresponding to the second request target points to the last subscript in the request target list, which is specifically 1.

[0072] If the second request number of the second request target is less than or equal to the first request number of the last first request target, it means that the request number of the second request target is lower or equal, and there is no need to replace the first request target for comparison to be managed by the request target list.

[0073] When the second request target needs to replace the first request target for comparison and is managed by the request target list, the request target list will be updated again. Specifically, the order 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.

[0074] In the case where the second request target does not need to replace the first request target for comparison and is managed by the request target list, the request target list does not need to be updated, and the state before the comparison with the second request target is maintained. The process ends.

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

[0076] In a specific implementation, when request data is written to the underlying data area, the TOPN_index corresponding to the second request target corresponding to the request data defaults to 0, and the second request number of the second request target is compared with the minimum first request number in the request target list. If it is less than or equal to, the comparison is stopped; if it is greater, the order is exchanged with the minimum first request target, and the TOPN_index of the second request target points to the last subscript in the request target list.

[0077] By adopting the embodiment of the present disclosure, the second request target is inserted into the request target list by replacement, which ensures that the request target list always keeps the latest high-frequency request data and enhances the dynamic adaptability of the system. Through simple comparison and exchange logic, the implementation of the algorithm is more intuitive, easy to understand and maintain. This simplified design reduces the complexity of development and maintenance. Since the request target list is updated in real time, the system can quickly locate high-frequency requests that affect the service, which is convenient for operation and maintenance personnel to troubleshoot and handle faults, and improves the maintainability of the system.

[0078] Among them, in an optional embodiment, when the second request target is managed by the request target list, the sorting of the request target list is updated, including: comparing the second request number corresponding to the second request target with the first request number corresponding to the previous first request target; when the second request number is less than or equal to the first request number, completing the updating of the sorting of the request target list; when the second request number is greater than the first request number, exchanging the positions of the first request target and the second request target; and comparing with the first request number corresponding to the previous first request target in turn according to the above steps until there is no previous first request target, or, when the second request number is less than or equal to the first request number, completing the updating of the sorting of the request target list.

[0079] 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 to update the order of the request target list.

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

[0081] The second request number of the second request target is compared with the first request number of the first request target.

[0082] If the second request number is less than or equal to the first request number, it means that at this time, the request number of the second request target is not high enough, and there is no need to exchange positions, and the update process ends.

[0083] If the second request number is greater than the first request number, the second request target is swapped with the first request target. The TOPN_index of the second request target can be pointed to a new position, that is, the position of the second request target in the request target list after the replacement operation. The position can indicate the number of the second request target in the request target list. The request target list modifies the data area index managed by the position to the subscript of the second request target in the index area.

[0084] After exchanging positions, the second request target continues to be compared with the first request target preceding the second request target until there is no previous first request target, or, when the second request number is less than or equal to the first request number, the update of the sorting of the request target list is completed.

[0085] Once there are no more previous first request targets to be compared, or all necessary swaps are completed (the second request count is less than or equal to the first request count), the sorting process of updating the request target list ends.

[0086] By using the embodiments of the present disclosure, the system can update the request target list in real time by comparing the number of requests and performing necessary exchanges, ensuring that the list always reflects the frequency of current requests, so that the system can quickly respond to traffic changes and adjust the processing strategy in a timely manner. During the update process, only necessary elements are compared, avoiding traversal of the entire list, reducing computational complexity, and improving the processing efficiency of the system. By continuous comparison and exchange, it is ensured that the target with the highest number of requests is always at the front of the list. In the event of a sudden increase in traffic, the system can quickly adjust the order of request targets and identify new high-frequency requests in a timely manner.

[0087] Through the confirmation algorithm of the request target list disclosed in the present invention, when the target gateway is in the pre-control area, the request targets at the million-level can be obtained in real time within milliseconds, and the request targets include the TOPN domain names and IP addresses, so as to quickly locate the request targets that really affect the target gateway service overload.

[0088] In addition, after obtaining the TOPN request target, it is also possible to determine whether intervention is required through alarms.

[0089] Figure 2 Schematic diagram of a confirmation algorithm for a request target list shown in an embodiment of the present disclosure. The TOPN area shown in the figure is the area corresponding to the request target list, and the data area is the area where the request target is actually stored. The comparison rules include two cases: In the first case, if the request target to be compared is not in the TOPN area, it will be compared with the first request targets managed in the request target list in order from back to front 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 will be exchanged with the first request target in the request target list.

[0090] In the second case, if the request target to be compared is located in the TOPN area, then the request target to be compared is only compared with the first request targets located in front of it in turn 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 is exchanged with the first request target in the request target list.

[0091] Figure 3 It is a schematic diagram of a specific implementation of the confirmation algorithm shown in the embodiment of the present disclosure, including steps 1 to 7.

[0092] Step 1: A new request data is written into the data area, and the request target corresponding to the request data is determined to be 222.222.222.222, and the request target is determined to be the second request target. The second request number corresponding to the second request target is 9, and the initial list index defaults to 0.

[0093] Step 2: Find the data area index corresponding to the end of the request target list in order from back to front.

[0094] Step 3: According to the data area index, find the actual first request target from the data area, and the number of requests for the first request target is 2.

[0095] Step 4: Compare the second request number of the second request target with the request number of the first request target, and determine that the second request number is greater than the first request number.

[0096] Step 5: Swap the first request target and the second request target. Specifically, the list index corresponding to the second request target points to the last index of the request target list, and the data area index corresponding to the last index of the request target list points to the second request target's index in the data area.

[0097] Step 6: The second request target continues to be compared with the previous first request target in the order from back to front. At this time, through the actual first request target pointed to by the previous data area index, it is determined that the first request number of the first request target is 6. At this time, the second request number is greater than the first request number.

[0098] 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 subscript 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 subscript of the second request target in the data area. Continue to compare with the previous first request target, but at this time the first request number of the first request target is 10, and the second request number is less than the first request number, so the final result is obtained.

[0099] Among them, in an optional embodiment, when the target gateway is in the overload zone, the first request number of the first request target in the request target list is subject to upper limit control, including: determining a control reference value according to the request situation of the request target list in the pre-control zone; according to the control reference value, performing a step-by-step upper limit control on the target control indicator of the first request target in the request target list; the target control indicator represents the number of requests of the first request target per unit time.

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

[0101] The regulation reference value may be an average number of requests of the first request target when the target gateway is in the pre-control area.

[0102] Since the key top-level request targets have been analyzed and located in real time when the target gateway is in the pre-control area, all first request targets can be directly extracted from the current request target list, including the first request target and its corresponding request times. Based on the request data in the pre-control area, the control reference value is calculated.

[0103] Figure 4 FIG. 1 is a schematic diagram of a real-time sorting of a request target list shown in an embodiment of the present disclosure. Figure 4 As shown, when it is necessary to obtain the sorting result in the request target list, the request target list can be traversed in order from front to back, and the specific position of the data area can be located according to the data area index pointed to by the data area index at the corresponding position to obtain the actual first request target.

[0104] The target control index is defined, that is, the maximum number of requests allowed for the first request target within a unit time. The target control index may be QPS. By performing upper limit control on the defined target control index, the upper limit control of the first number of requests for the first request target is achieved.

[0105] The target regulation indicators are subjected to step-by-step upper limit control. The meaning of step-by-step upper limit control is to set multiple adjustment cycles, and each adjustment cycle uses a stricter upper limit control strategy than the previous adjustment cycle.

[0106] By adopting the embodiments of the present disclosure, by implementing an upper limit control on the number of requests of the first request target, the request traffic in overload conditions can be effectively reduced, the exhaustion of target gateway resources can be prevented, and the stability and reliability of the system can be ensured. By implementing upper limit control, request failures due to overload can be avoided, thereby improving the user's access experience and ensuring that user requests can be processed in a timely manner. Step-by-step upper limit control allows the system to gradually reduce the upper limit of the number of requests in different time periods. This flexible control method can better adapt to traffic fluctuations and reduce the impact on the system.

[0107] Among them, in an optional embodiment, according to the control reference value, the target control indicator of the request target list is subjected to step-by-step upper limit control, including: determining the time period and downward adjustment ratio of the step-by-step upper limit control; determining the first request target with the largest number of first requests in the request target list as the control request target; determining the upper limit value corresponding to the control period according to the control reference value and the downward adjustment ratio; within the control period, determining the upper limit value as the upper limit of the target control indicator of the control request target; forwarding requests for the control request target that exceed the upper limit of the target control indicator to a high-performance sandbox, which is an isolated environment or node for processing requests.

[0108] You can analyze historical data over a period of time to understand the fluctuations, peaks, and valleys of the request volume. Based on historical data and analysis results, set the time period for step-by-step upper limit control. The upper limit control strategy for each time period is different. Based on the actual needs of the system and historical data, select an appropriate downward adjustment ratio, which will be used to calculate the new upper limit value.

[0109] All first request targets and their corresponding first request times are extracted from the request target list. The first request target with the largest first request times is determined as the control request target as the focus of subsequent control. The first request target with the largest first request times will be updated in real time during the step-by-step upper limit control process, and the first request target with the largest first request times after the update will be determined as the control request target.

[0110] According to the request situation when the target gateway is in the pre-control area, a control reference value is obtained. The control reference value is determined based on the target control index of the control request target in the past period of time, for example, the average number of requests for the control request target in the past period of time.

[0111] Multiply the control reference value by the downward adjustment ratio to calculate the upper limit of the current control cycle. This upper limit refers to the upper limit of the target control index of QPS.

[0112] In the current control cycle, the calculated upper limit value is set as the upper limit of the target control indicator of the control request target to ensure that the number of requests for the control request target does not exceed this number of requests in the cycle.

[0113] During the regulation cycle, the number of requests to the regulation request target can be monitored in real time to ensure that it does not exceed the set upper limit. If the number of requests to the regulation request target exceeds the upper limit of the target regulation indicator, the forwarding mechanism is triggered. Requests exceeding the upper limit are forwarded to the high-performance sandbox node, which is an isolated environment specifically used to handle these excess requests, ensuring normal access to user requests without affecting the stability of the main system.

[0114] In a specific implementation, when the step ratio of downward adjustment is 0.8, assuming that the target control index of the control request target within the unit time of the pre-control zone is 1000, then the upper limit of the target control index of the domain name in the first time period is set to 1000*0.8=800. Then, in the first time period, the target control index of the control request target cannot exceed 800, and the excess part needs to be forwarded. If the target gateway is still in the overload zone at the end of the first time period, then continue to enter the second time period, and the upper limit of the second time period can be determined by the upper limit of the first time period. Then, in the second time period, the upper limit of the target control index of the domain name is set to 800*0.8=640. In the second time period, 640 is used as the upper limit of the target control index to control the upper limit of the target control index of the control request target. The part of the target control index exceeding 640 in the entire second period is forwarded to the high-performance sandbox node.

[0115] After the regulation cycle ends, the performance of the regulation request target can be evaluated, and data such as the number of requests and the number of forwarded requests can be analyzed to determine the effectiveness of the upper limit control. Based on the evaluation results, the time period, downward adjustment ratio or other related parameters can be adjusted to improve the subsequent regulation effect and system performance.

[0116] By adopting the embodiments of the present disclosure, by setting an upper limit on the number of requests, it is possible to effectively control traffic and prevent the system from being overloaded due to too many requests, thereby improving the stability and reliability of the system. The upper limit value is dynamically calculated based on the control reference value and the downward adjustment ratio, so that the system can be flexibly adjusted according to the actual request situation, enhancing the adaptability and responsiveness of the system. By forwarding requests that exceed the upper limit to a high-performance sandbox, request failures due to overload can be avoided, improving the user's access experience and ensuring that user requests can be properly handled. As business needs change, the system can flexibly adjust the upper limit control strategy to support future expansion and upgrades, ensuring that the system continues to adapt to changing business needs.

[0117] Among them, in an optional embodiment, a control reference value is determined according to the request situation of the request target list in the pre-control area, including: according to the value of the target control indicator corresponding to each first request target in the request target list when the target gateway is in the pre-control area; according to the sampling period and the value of the target control indicator, an average control value corresponding to each first request target is determined; and the control reference value is determined by the average control value.

[0118] Continuously monitor the request status of each first request target in the request target list, record the request data in the pre-control area, and ensure the accuracy and timeliness of the data. Determine the number of requests received by each first request target within a certain period of time, that is, the value of the target control indicator corresponding to each first request target.

[0119] You can set a suitable sampling period to calculate the average control value of the requested target, such as the past one minute, five minutes, etc.

[0120] By counting the first request targets in the request target list within the sampling period, and then dividing the total number of requests by the length of the sampling period, the corresponding average control value is obtained. For example, if the sampling period is expressed in seconds within a 5-minute sampling period. For example, if the total number of requests for a TOPN domain name is 3,000 times, its QPS average is 3,000 / 300 = 10 QPS.

[0121] The average control values ​​of all first request targets can be summarized to form a control reference value list. According to business requirements and system performance, a suitable control reference value can be selected from the average control values, which can be the average, median or other statistical methods of all targets. The average control value corresponding to the first request target can also be used as the control reference value of the first request target.

[0122] By adopting the embodiments of the present disclosure, by real-time monitoring of the request target and calculating the control reference value, the flow control strategy can be adjusted in time to avoid system overload and ensure the stability of the service. When the system is in the pre-control area, potential flow anomalies are identified in advance and corresponding control measures are taken to reduce the risk of service interruption. By dynamically calculating the control reference value, the system can quickly adapt to flow changes and support more request targets and business expansion.

[0123] Among them, in an optional embodiment, it also includes: in the process of performing step-by-step upper limit control on the target regulation indicator of the first request target in the request target list, updating the first request target with the largest number of first requests in the request target list in real time; and determining the state partition of the target gateway in real time; when the target gateway returns to the healthy zone or the pre-control zone, stopping the step-by-step upper limit control on the target regulation indicator of the first request target in the request target list.

[0124] The number of requests of each first request target in the request target list is continuously monitored.

[0125] Specifically, an appropriate time window can be set for counting and updating the number of requests. At the end of each time window, the number of requests of all first request targets in the request target list is compared. The first request target with the largest number of requests is identified in real time.

[0126] When the first request target with the largest number of requests is updated, if the current target gateway is still in the overload zone, an upper limit control is performed on the first request target with the largest number of requests after the update.

[0127] Regularly obtain the target gateway's machine health value, cumulative first data month-on-month, and cumulative second data month-on-month indicators to determine its state partition. Once the target gateway returns to the healthy zone or pre-control zone, immediately stop the stepped upper limit control of the current maximum request target. After stopping the upper limit control, resume the normal request processing process and allow the current maximum request target to accept more requests.

[0128] According to the implementation effect and the status changes of the target gateway, timely adjust the monitoring and control strategies to ensure stable operation of the system.

[0129] By adopting the embodiments of the present disclosure, the system can quickly identify and regulate the first request target with the largest number of requests in the request target list in real time, thereby effectively managing the request traffic. Regularly obtaining the machine health value of the target gateway, cumulative data month-on-month and other indicators provides a basis for judging the system status, and can adjust the monitoring and control strategies in time to ensure the stable operation of the system under different loads. When the target gateway returns to the healthy zone or the pre-control zone, the stepped upper limit control is automatically stopped, and the normal request processing process is restored to reduce manual intervention.

[0130] Figure 5 FIG. 1 is a schematic diagram of an overall decision-making method for analyzing and deciding gateway service overload according to an embodiment of the present disclosure. Figure 5As shown, data indicators such as QPS and abnormal request ratio are obtained in real time; the machine health value is obtained; when various indicators are less than the health zone threshold, the target gateway is determined to be in the health zone, and no additional decision is made at this time; when various indicators are greater than the pre-control zone threshold, the target gateway is determined to be in the pre-control zone, and the request target list is determined in real time based on the sliding window, and the request target list can be reported to the monitoring component; when various indicators are greater than the overload zone threshold, a step-by-step upper limit control is performed based on the request target list, and the excess part triggers a forwarding operation to forward it to a high-performance sandbox.

[0131] Figure 6 1 is a flow chart of a gateway service overload analysis and decision-making method shown in an embodiment of the present disclosure. Figure 6 As shown: The first step is to collect indicator data and calculate the month-on-month growth rate. The CDN gateway collects the QPS of requests and the percentage of abnormal requests per minute in real time, and calculates the month-on-month QPS sudden increase rate and abnormal percentage sudden increase rate based on the month-on-month growth formula.

[0132] The second step is to obtain the machine health value. The CDN gateway, that is, the target gateway, regularly obtains the machine health value, which represents the quality coefficient of the server. The machine health value is modeled based on six indicators: CPU utilization, disk IO utilization, machine IO load, memory utilization, network card utilization, and service port response time. The overall idea of ​​its calculation is to first smooth each indicator using the exponentially weighted moving average algorithm, and then normalize it using the min-max standard.

[0133] The third step is to locate the status partition based on multiple indicator data. The CDN gateway makes a comprehensive judgment based on the QPS month-on-month sudden increase rate, abnormal percentage sudden increase rate, and machine health value data in the first and second steps to determine which partition the service status is in.

[0134] Step 4: If the location is in the healthy zone, no additional operation is required and the current cycle ends directly.

[0135] Step 5. If the positioning is in the pre-control area, proceed to step 6.

[0136] Step 6: Real-time analysis based on sliding windows. The gateway starts real-time analysis. At this time, the CDN gateway receives a large number of requests, and the request data changes dynamically. The request targets with the top N requests are sorted in real time. The request targets include domain names and access IP addresses.

[0137] Step 7: Record the QPS of the TOPN request target as the initial benchmark value. The QPS of the TOPN request target can be obtained in real time according to the result of step 6 and used as the initial benchmark value.

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

[0139] Step 9: If the positioning is in the overload area, go to step 10.

[0140] Step 10: Get the average QPS of the TOPN request target during the sampling period. The service status is already in an extremely unhealthy state, so it is necessary to enable the self-protection mode to control the upper limit of the QPS of the TOPN request target. According to step 6, the QPS of the TOPN request target can be directly obtained, so the average QPS of the TOPN request target during the sampling period can be directly obtained.

[0141] In the eleventh step, the QPS upper limit of the TOPN request target is obtained according to the step ratio. The result of the tenth step is multiplied by the preset step ratio to obtain the QPS upper limit corresponding to each request target in the TOPN.

[0142] Step 12: formulate a self-protection strategy based on the upper limit value. The CDN gateway executes the corresponding restriction strategy based on the QPS upper limit of each TOPN request target obtained in step 11, and the validity period is until the next cycle.

[0143] Step 13: Determine whether the current TOPN request target QPS exceeds the upper limit. Determine in real time whether the current QPS exceeds the upper limit according to the self-protection strategy in step 12. If it exceeds the upper limit, proceed to step 14.

[0144] Step 14: Forward excess requests to the sandbox node. Forward the part of the TOPN request target whose QPS exceeds the upper limit to the high-performance sandbox node in the same region according to the access IP to ensure normal access by users.

[0145] Based on the same technical concept, the present disclosure provides a gateway service overload analysis and decision-making device. Figure 7 1 is a block diagram of a gateway service overload analysis and decision-making device shown in an embodiment of the present disclosure. Figure 7 As shown, the device comprises: The data acquisition module 710 is used to acquire the operation status data of the target gateway, wherein the operation status data represents the health status of the target gateway; The matching module 720 is used to determine the state partition of the target gateway according to the running state data: the state partition includes a healthy zone, a pre-control zone and an overload zone; The analysis module 730 is used to determine a request target list according to the current request status of the target gateway when the target gateway is in the pre-control area; the request target list manages the first request target with the largest number of requests; The decision module 740 is used to perform an upper limit control on the first request number of the first request target in the request target list when the target gateway is in the overload area.

[0146] The present disclosure also provides an electronic device, referring to Figure 8 , Figure 8 is a schematic diagram of an electronic device shown in an embodiment of the present disclosure. 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 communication. A computer program is stored in the memory 810. The computer program can be run on the processor 820, thereby implementing the steps in the analysis and decision-making method for gateway service overload disclosed in the embodiment of the present disclosure.

[0147] The embodiment of the present disclosure further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps in the gateway service overload analysis and decision-making method disclosed in the embodiment of the present disclosure are implemented.

[0148] The embodiment of the present disclosure further provides a computer program product, including a computer program, which, when executed by a processor, implements the steps in the gateway service overload analysis and decision-making method disclosed in the embodiment of the present disclosure.

[0149] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0150] It should be understood by those skilled in the art that the embodiments of the present disclosure may be provided as methods, devices or computer program products. Therefore, the embodiments of the present disclosure may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the embodiments of the present disclosure may 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.

[0151] The embodiments of the present disclosure are described with reference to the flowcharts and / or block diagrams of the methods, apparatuses, electronic devices, and computer program products according to the embodiments of the present disclosure. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0152] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0153] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0154] Although some embodiments of the present disclosure have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiment and all changes and modifications that fall within the scope of the present disclosure.

[0155] The above is a detailed introduction to a gateway service overload analysis and decision-making method and device provided by the present invention. This article uses specific examples to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. At the same time, for general technical personnel in this field, according to the ideas of the present invention, there will be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be understood as a limitation on the present invention.

Claims

1. A gateway service overload analysis and decision-making method, characterized in that: include: Acquire operation status data of the target gateway, wherein the operation status data represents the health status of the target gateway; According to the running status data, determining the current state partition of the target gateway, wherein the state partition includes a healthy zone, a pre-control zone, and an overload zone; When the target gateway is in the pre-control area, determining a request target list according to a current request situation of the target gateway; The request target list manages the first request target with the largest number of requests. When the target gateway is in the overload zone, an upper limit control is performed on the first request number of the first request target in the request target list.

2. The method according to claim 1, characterized in that The first request targets managed by the request target list are sorted in the request target list according to their corresponding first request times; When the target gateway is in the pre-control area, determining a request target list according to the current request status of the target gateway includes: In the case where a new request is written to the underlying data area of ​​the target gateway, determining a second request target corresponding to the new request; Compare the second request number corresponding to the second request target with the first request number corresponding to the first request target at the end of the request target list, the first request number corresponding to the first request target at the end of the request target list being the first request number with the least number of times in the request target list; Determining, according to the comparison result, whether the second request target is managed by the request target list; In a case where the second request target is managed by the request target list, the order of the request target list is updated.

3. The method according to claim 2, characterized in that Determining, according to the comparison result, whether the second request target is managed by the request target list includes: When the second request number is less than or equal to the first request number, determining that the second request target is not managed by the request target list; When the second request number is greater than the first request number, the second request target is replaced to the position of the last 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: In a case where the second request target is managed by the request target list, updating the sorting of the request target list includes: Compare the second request number corresponding to the second request target with the first request number corresponding to the previous first request target; When the second request number is less than or equal to the first request number, completing updating the sorting of the request target list; When the second request number is greater than the first request number, exchanging the positions of the first request target and the second request target; According to the above steps, the first request number corresponding to the previous first request target is compared in sequence until there is no previous first request target, or the second request number is less than or equal to the first request number, and the update of 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, upper limit control is performed on the first request number of the first request target in the request target list, including: Determining a control reference value according to a request status of the request target list in the pre-control area; According to the control reference value, a target control index of the first request target in the request target list is subjected to step-by-step upper limit control; the target control index represents the number of requests for the first request target per unit time.

6. The method according to claim 1, characterized in that According to the control reference value, a step-by-step upper limit control is performed on the target control index of the request target list, including: Determine the time period and downward adjustment ratio of the step-up upper limit control; Determine the first request target with the largest number of first requests in the request target list as the control request target; Determining an upper limit value corresponding to a control cycle according to the control reference value and the downward adjustment ratio; In the regulation cycle, the upper limit value is determined as the target regulation indicator upper limit of the regulation request target; The control request target, requests that exceed the upper limit of the target control indicator, 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 Determining a control reference value according to the request status of the request target list in the pre-control area includes: According to the case where the target gateway is in the pre-control area, the value of the target regulation indicator corresponding to each first request target in the request target list; Determine, according to the sampling period and the value of the target control index, 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 to 7, characterized in that: Also includes: In the process of performing step-by-step upper limit control on the target regulation indicator of the first request target in the request target list, updating the first request target with the largest number of first requests in the request target list in real time; and, determining in real time the state partition in which the target gateway is located; When the target gateway is restored to the healthy zone or the pre-control zone, the step-by-step upper limit control of the target regulation indicator of the first request target in the request target list is stopped.

9. The method according to claim 1, characterized in that: Get the running status data of the target gateway, including: Collecting first data and second data of a target gateway; Determine, based on the first data and the second data, respectively a cumulative first data year-on-year increase and a cumulative second data year-on-year increase; Through data modeling, the machine health value of the target gateway is obtained; Determining the current state partition of the target gateway according to the running state data includes: Compare the accumulated first data on a month-on-month basis, the accumulated second data on a month-on-month basis, and the machine health value with corresponding thresholds to obtain a comparison result; According to the comparison result, the state partition of the target gateway is determined.

10. A gateway service overload analysis and decision-making device, characterized in that: include: A data acquisition module, used to acquire the operation status data of the target gateway, wherein the operation status data represents the health status of the target gateway; A matching module, configured to determine the state partition of the target gateway according to the running state data, wherein the state partition includes a healthy zone, a pre-control zone, and an overload zone; An analysis module, configured to determine a request target list according to a current request status of the target gateway when the target gateway is in the pre-control area; The request target list manages the first request target with the largest number of preset requests; The decision module is used to perform an upper limit control on the first request number of the first request target in the request target list when the target gateway is in the overload area.

Images