Method and system for degrading service control

Abstract

The present disclosure relates to a degraded service control method and system, which is applied to the degraded service control field, can return normal service data to the user through a single request degradation strategy, and can improve the user experience. The method comprises the following steps: receiving a target service request sent by a terminal device; based on the load balancing principle, calling a target service API to execute the target service request, the target service request corresponding to a target service service carrying the target service API; in the case that the service result returned by the target service API for the target service request indicates an exception, executing a single request degradation strategy for the target service request to obtain target service data corresponding to the target service request; and sending the target service data to the terminal device.

Description

Technical Field

[0001] This application relates to the field of degraded service control. More specifically, it relates to a degraded service control method, device, and system. Background Technology

[0002] With the rapid development of the internet, providing users with continuous and normal business services is a basic requirement for software systems. Conversely, complex situations such as sudden surges in traffic, unpredictable failures, and resource shortages are unavoidable and can easily lead to business service interruptions. To ensure high availability, the mainstream technology in the industry employs "degradation" security measures for cloud systems.

[0003] The key technical aspects of degradation measures are: accurate and timely detection of system anomalies and automatic triggering of degradation; comprehensive coverage of anomaly scenarios; and minimal impact on user experience from the provided degradation data. Due to the complexity and difficulty in comprehensively monitoring the conditions for identifying degradation, many systems still rely on manual monitoring to switch to degradation, failing to leverage the technological advantages. To achieve the desired goals, automated degradation is widely used in the industry, with common solutions including: 1. Monitoring the consumption of service resources (Central Processing Unit (CPU), memory, or input / output (I / O) bandwidth) in the resource space where the business service resides. If the consumption of service resources exceeds a threshold, automatically switch to degraded data; 2. Monitoring the status of the data returned by the business service. If the proportion of abnormal results in the returned data exceeds a threshold, automatically switch to degraded data.

[0004] However, as daily use becomes more widespread, the above-mentioned automated degradation scheme has the following drawbacks: after the consumption of service resources exceeds the threshold or the proportion of abnormal results in the returned data exceeds the threshold, it is converted into degradation data. This means that abnormal requests that occur before the threshold is exceeded (i.e., before the overall degradation conditions are met) will send abnormal results, affecting the user experience. Summary of the Invention

[0005] To address, or at least partially address, the aforementioned technical problems, embodiments of this application provide a service degradation control method, device, and system that can return normal business data to users through a single-request degradation strategy, thereby improving user experience.

[0006] In a first aspect, embodiments of this application provide a service degradation control method, comprising: receiving a target service request sent by a terminal device; executing the target service request by calling a target business API based on the principle of load balancing, wherein the target service request corresponds to a target business service carrying the target business API; if the business result returned by the target business API for the target service request indicates an anomaly, executing a single request degradation strategy for the target service request to obtain target business data corresponding to the target service request; and sending the target business data to the terminal device.

[0007] Secondly, embodiments of this application provide a degraded service control device, including: a memory configured to store a computer program; and a processor configured to, when the computer program is invoked, cause the degraded service control device to implement the degraded service control method as described in the first aspect.

[0008] Thirdly, this application provides a degradation service control system, including: a degradation service, a stream processing platform, a data acquisition service, a data storage service, a global degradation adjustment service, and a degradation policy backend service; the degradation service is configured to: receive a target service request sent by a terminal device through a gateway, the target service request corresponding to a target business service carrying a target business API; the degradation service includes multiple PODs, and the degradation service manages the business API of at least one business service, including the target business service, through multiple PODs; based on the abnormality ratio of the global POD corresponding to the degradation service, it determines the target global degradation policy to be executed in the current global time window, and determines the target data type to which the target service request belongs; the global PODs... The anomaly percentage is the average percentage of anomalies occurring when calling the business API across multiple PODs within the previous global time window. Different global degradation strategies target different data types of service requests for degradation processing. If the target global degradation strategy does not perform degradation processing on service requests of the target data type, the target business API is called to execute the target service request based on load balancing principles. If the target business API returns an anomaly for the target service request, a single-request degradation strategy is executed to obtain the target business data corresponding to the target service request. If the result is normal, the business result is identified as the target business data. If the global degradation strategy targets the service request for the target data type, the pre-stored degradation data corresponding to the target service request is identified as the target business data. The target business data and target data type are returned to the target terminal via the gateway. The stream processing platform is configured to receive the target business data and target data type returned by the degradation service via the gateway. The acquisition service is configured to consume messages from the stream processing platform and save the target business data and target data type to the data storage service. The degradation strategy backend service is configured to configure a global degradation strategy and / or a single-request degradation strategy based on the data type, or based on the operation... The maintenance personnel configure global degradation policies and / or single-request degradation policies; push the configured global degradation policies and / or single-request degradation policies to the degradation service through the stream processing platform; the global degradation adjustment service is configured to: periodically obtain the real-time global POD anomaly ratio corresponding to the degradation service; update the correspondence between the global anomaly ratio range and the preset degradation policy according to the real-time global POD anomaly ratio, so as to update the degradation level of the global degradation policy, and send the updated global degradation policy degradation level to the degradation policy backend service; the degradation policy backend service is also configured to: update the degradation level of the global degradation policy, and push the updated global degradation policy degradation level to the degradation service through the stream processing platform.

[0009] Fourthly, embodiments of this application provide a computer program product, including: when the computer program product is run on a computer, causing the computer to implement the degradation service control method as shown in the first aspect.

[0010] The technical solution provided in this application has the following advantages compared with the prior art: In this application embodiment, a target service request sent by a terminal device is received; based on the principle of load balancing, a target service API is called to execute the target service request, and the target service request corresponds to the target service carrying the target service API; if the business result returned by the target service API for the target service request indicates an anomaly, a single request degradation strategy is executed for the target service request to obtain the target service data corresponding to the target service request; and the target service data is sent to the terminal device. Thus, when the business result returned by the target service API for the target service request indicates an anomaly, a single request degradation strategy is executed for the target service request to obtain the target service data corresponding to the target service request, and the business service data with a normal indication is returned to the user. Therefore, abnormal requests that occur before the overall degradation condition is reached can be returned to the user with normal business data through a single request degradation strategy, which can improve the user experience. Attached Figure Description

[0011] To more clearly illustrate the implementation methods in the embodiments of this application or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0012] Figure 1 One of the flowcharts of a degraded service control method according to some embodiments is shown;

[0013] Figure 2 A second flowchart illustrating a degraded service control method according to some embodiments is shown;

[0014] Figure 3 The third flowchart illustrates a degraded service control method according to some embodiments;

[0015] Figure 4 A schematic diagram is shown illustrating the determination of a single-request degradation strategy according to some embodiments;

[0016] Figure 5 A schematic diagram is shown illustrating the determination based on a global degradation strategy in some embodiments;

[0017] Figure 6 The fourth flowchart illustrates a degraded service control method according to some embodiments;

[0018] Figure 7 The fifth flowchart illustrates a degraded service control method according to some embodiments;

[0019] Figure 8 A flowchart of a degraded service control method according to some embodiments is shown as sixth;

[0020] Figure 9 The seventh flowchart illustrates a degraded service control method according to some embodiments;

[0021] Figure 10 A schematic diagram illustrating the global degradation strategy adjustment according to some embodiments is shown;

[0022] Figure 11 A schematic diagram of the framework structure of a degraded service control device according to some embodiments is shown;

[0023] Figure 12 A schematic diagram of the framework structure of a degraded service control system according to some embodiments is shown;

[0024] Figure 13 A schematic diagram of an example structure of a degraded service control system according to some embodiments is shown;

[0025] Figure 14 A schematic diagram illustrating the configuration of a global degradation policy according to some embodiments is shown;

[0026] Figure 15 A schematic diagram illustrating a single-request degradation strategy configuration according to some embodiments is shown;

[0027] Figure 16 A flowchart illustrating the logical processing of the degraded service-query interface according to some embodiments is shown.

[0028] Figure 17 A logical flowchart is shown to match a global degradation policy and a single-request degradation policy according to the degradation service in some embodiments;

[0029] Figure 18 A flowchart illustrating the logical processing of the degraded service-origin interface according to some embodiments is shown. Detailed Implementation

[0030] To make the objectives and implementation methods of this application clearer, the exemplary implementation methods of this application will be clearly and completely described below with reference to the accompanying drawings of the exemplary embodiments of this application. Obviously, the exemplary embodiments described are only some embodiments of this application, and not all embodiments.

[0031] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0032] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0033] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0034] Next, some of the terms and related technologies used in this application will be explained to facilitate understanding by those skilled in the art.

[0035] If a service request fails, the status code returned by the Application Programming Interface (API) determines whether the service request was successful. Typically, a status code of "200" indicates a successful service request, while a code other than "200" indicates a failed service request.

[0036] Business services include, but are not limited to, at least one of the following: a homepage business service for providing homepage services, a second-level page business service for providing second-level page (detail page) services, a filter page business service for providing filter page (category page) services, and a topic page business service for providing special topic pages (such as special topic pages corresponding to events). Each business service will deploy multiple running instances (hereinafter referred to as PODs), and each business service will host multiple business APIs.

[0037] Automatic degradation for anomalies throughout the entire lifecycle can automatically degrade any abnormal request in the entire lifecycle to return normal business results (degraded data) to the user.

[0038] With the rapid development of the internet, providing users with continuous and normal business services is a basic requirement for software systems. Conversely, complex situations such as sudden surges in traffic, unpredictable failures, and resource shortages are unavoidable and can easily lead to business service interruptions. To ensure high availability, mainstream industry technologies employ "rate limiting" and "degradation" security measures for cloud systems.

[0039] Rate limiting technology typically involves real-time statistics of request volume within a unit window to determine if it exceeds a set maximum concurrency threshold. Requests exceeding the threshold are then redirected to pre-set data. While this measure offers high timeliness, the fixed pre-set data can disrupt normal user experience. Therefore, cloud systems tend to use "degradation" to ensure a better user experience.

[0040] Compared to rate limiting, degradation is more complex, and its key technical aspects include: accurate and timely detection of system anomalies and automatic triggering of degradation; comprehensive coverage of anomaly scenarios; and providing degradation data with minimal impact on user experience. Due to the complexity and difficulty in comprehensively monitoring the conditions for identifying degradation, many systems still rely on manual monitoring to switch to degradation, failing to leverage the technological advantages. To achieve the desired goals, automated degradation is still widely used in the industry, with common solutions as follows:

[0041] 1. Monitor the consumption of service resources (Central Processing Unit (CPU), memory, or input / output (I / O) bandwidth) in the resource space where the business service is located. If the consumption of service resources exceeds the threshold, automatically switch to degraded data.

[0042] 2. Monitor the status of returned data from business services. If the proportion of abnormal results in the returned data exceeds the threshold, automatically switch to degraded data.

[0043] However, as daily use becomes more widespread, the above-mentioned automated degradation scheme has the following drawbacks: when the consumption of service resources exceeds the threshold or the proportion of abnormal results in the returned data exceeds the threshold, it will be converted to degradation data. This means that abnormal requests that occur before the threshold is exceeded will send abnormal results, affecting the user experience.

[0044] As its daily use becomes more widespread, the shortcomings of the above solution have become apparent, mainly as follows:

[0045] 1. When the consumption of service resources exceeds the threshold or the proportion of abnormal results in the returned data exceeds the threshold, the data is converted to degraded data. This means that abnormal requests that occur before the threshold is exceeded will send abnormal results, affecting the user experience. Automatic degradation of abnormalities throughout the entire lifecycle is not achieved.

[0046] 2. The cloud service uses a cluster deployment, where a single service deploys multiple PODs. If an individual POD experiences an anomaly with a high anomaly rate, it may cause the overall anomaly rate to exceed the threshold, thus triggering an overall degradation. The criteria for determining whether to trigger an overall degradation are too sensitive, which can easily lead to frequent overall degradation triggers. Furthermore, it can cause PODs that are not experiencing anomalies or have a low anomaly rate to also trigger degradation, thus impacting the user experience.

[0047] 3. Degraded data provided after exceeding the threshold often leads to user complaints due to excessive data loss, and there is a lack of effective measures to determine the minimum lossy data based on the severity of business anomalies.

[0048] 4. When the system provides degraded data, it often needs to call business services. If it still calls business services that are already experiencing problems to obtain degraded data, it will not reduce the pressure on the existing abnormal business services and will cause the abnormal situation to worsen. If the degraded data is obtained by a separately deployed business service (a business service that is deployed separately to provide degraded data and is only used when providing degraded data, and is not used when it is not needed to provide degraded data (that is, when the overall degrade is not triggered), it will also cause serious consumption of server resources due to the additional deployment of a large number of business services.

[0049] In summary, there is an urgent need for an automated degradation solution that can "monitor abnormal business conditions in real time and precisely control the impact of degradation." This invention, by building an automatic degradation service device, differentiates between "individual degradation of business requests" and "overall degradation of the business cluster," employing a progressive, layered, and adaptive automatic degradation approach. Based on the degree of degradation loss of various types of business data, it precisely adapts the minimum lossy data corresponding to the level of business anomaly, achieving the ultimate goals of "protecting the business system" and "minimizing the impact on user experience."

[0050] To illustrate this solution in more detail, the following will use examples to illustrate it. Figures 1 to 10 To explain, it is understandable that Figures 1 to 10 The steps involved may include more or fewer steps in actual implementation, and the order of these steps may also be different, depending on whether the degradation service control method provided in the embodiments of this application can be implemented.

[0051] Figure 1 The flowchart illustrates the steps of implementing a degraded service control method according to one or more embodiments of this application. The executing entity of the degraded service control method can be a service device, or a functional module or entity within the service device capable of implementing the degraded service control method; no limitation is made here. The degraded service control method may include the following steps S101 to S104.

[0052] S101, Receive the target service request sent by the terminal device.

[0053] In some embodiments of this application, the target service request may be a service request triggered on the homepage displayed by the user on the terminal device, a service request triggered on a second-level page displayed by the user on the terminal device, a service request triggered on a category page displayed by the user on the terminal device, a service request triggered on a topic page displayed by the user on the terminal device, or a service request triggered on other pages displayed by the user on the terminal device. The specific request can be determined according to the actual situation and is not limited here.

[0054] S102. Based on the principle of load balancing, call the target business API to execute the target service request.

[0055] In some embodiments of this application, the target service request corresponds to a target business service that carries the target business API. The target service request is a service request for a target business service, which carries multiple business APIs, including the target business API. The target service request can be executed through any one of the business APIs carried by the target business service to return the business result corresponding to the target service request. The target business API is the business API matched to the target service request based on load balancing principles to execute the target service request.

[0056] S103. If the business result returned by the target business API for the target service request is abnormal, execute a single request degradation strategy for the target service request to obtain the target business data corresponding to the target service request.

[0057] If the service result indicating an anomaly is directly returned to the terminal device, the user receives an abnormal result, severely impacting the user experience. Therefore, in some embodiments of this application, a single-request degradation strategy is executed for the target service request to obtain the target service data corresponding to the target service request. In this way, returning the service data indicating a normal service to the user improves the user experience.

[0058] S104. Send the target service data to the terminal device.

[0059] When the business result returned by the target business API for executing the target service request indicates an anomaly, a single request degradation strategy is executed for that target service request to obtain the target business data corresponding to the target service request. The business service data indicating a normal result is then returned to the user. In this way, abnormal requests that occur before the overall degradation conditions are met can return normal business data to the user through the single request degradation strategy, which can improve the user experience.

[0060] In some embodiments of this application, the degradation service control method provided in S101 to S104 above can be applied to existing automated degradation services that determine the conditions for entering overall degradation based on whether the consumption of service resources exceeds a threshold or the proportion of abnormal results in the returned data exceeds a threshold, in order to solve the problem that abnormal requests that occur before the overall degradation conditions are met will issue abnormal results and affect user experience; it can also be applied to the automated degradation service provided in the embodiments of this application to solve the problem that abnormal requests that occur before the overall degradation conditions are met will issue abnormal results and affect user experience.

[0061] To achieve automated service degradation, this application embodiment constructs a degradation service control system for controlling and maintaining the degradation services provided in this application embodiment.

[0062] In some embodiments of this application, the degradation service control system includes a degradation service. The degradation service management system manages the business APIs of at least one business service (including the target business service) through the degradation service. The degradation service deploys multiple Points of Demand (PODs). Based on load balancing principles, the degradation service executes service requests received from terminal devices by calling the corresponding business APIs of each business service through each POD. If an abnormal business result is returned after executing the service request received from the terminal device through the POD's call to the corresponding business APIs, the degradation service can execute a corresponding single-request degradation strategy to obtain a normal business result. The single-request degradation strategy can be to directly use the pre-stored degradation data corresponding to the service request as the normal business result, or it can determine different single-request degradation strategies based on the data type of the service request and the abnormal proportion of a single POD to obtain a normal business result. The degradation service can obtain the single-POD exception ratio by statistically analyzing the exception situation of the business API carried by each business service in each POD. Then, based on the single-POD exception ratio of a POD, the degradation service determines the single-request degradation strategy corresponding to the exception request on that POD (the service request executed by calling the business API through that POD and the returned business result indicates an exception).

[0063] In some embodiments of this application, combined with Figure 1 ,like Figure 2 As shown, prior to S103 above, the degradation service control method provided in this application embodiment may further include S105 and S106 as described below.

[0064] S105. Determine the proportion of abnormal single PODs corresponding to the target business API.

[0065] The target single POD anomaly ratio is used to indicate the proportion of target POD calls to business APIs that are abnormal within the previous single POD time window before the current single POD time window; the target POD is the POD among the multiple PODs that calls the target business API to execute the target service request.

[0066] In this process, each POD of the downgraded service will calculate the proportion of abnormal calls to the business API within a fixed single POD time window. This proportion will be updated at the end of each window. In this embodiment, the single POD time window can be set to 30 seconds (it can be configured and adjusted according to the actual situation. The shorter the window period of the single POD time window, the more sensitive it is to the abnormality of the business API).

[0067] The single POD exception ratio is the ratio of the number of POD calls to business APIs that failed within the previous single POD time window (i.e., the number of exception requests) to the number of business API requests received by the POD within the previous single POD time window (i.e., the total number of requests allocated to the POD).

[0068] S106. If the abnormal proportion of the target single POD is within the range of the abnormal proportion of the target single POD, the target predetermined degradation strategy corresponding to the range of the abnormal proportion of the target single POD shall be determined as the single request degradation strategy.

[0069] Different single POD anomaly proportion ranges correspond to different predetermined degradation strategies.

[0070] In some embodiments of this application, at least two single-POD anomaly ratio ranges (including a target single-POD anomaly ratio range) can be set. When the target single-POD anomaly ratio falls within the target single-POD anomaly ratio range, the predetermined target degradation policy corresponding to the target single-POD anomaly ratio range is determined as the single-request degradation policy for the target service request. Thus, when the target single-POD anomaly ratio falls within different single-POD anomaly ratio ranges, the single-request degradation policy executed for the target service request is different.

[0071] In this embodiment, operations and maintenance personnel can configure predetermined degradation strategies corresponding to different single POD anomaly ratio ranges, that is, configure different single request degradation strategies for different single POD anomaly ratio ranges. The higher the single POD anomaly ratio, the higher the degree of data loss required by the corresponding single request degradation strategy. A retry strategy for service requests can also be configured to achieve the goal of recognizing that the higher the single POD anomaly ratio, the more business API traffic pressure is distributed by the single POD.

[0072] In this embodiment of the application, a suitable single request degradation strategy is determined based on the single POD anomaly ratio range corresponding to the target business API, thereby enabling the determination of a suitable single request degradation strategy based on the business system pressure.

[0073] In some embodiments of this application, the predetermined degradation strategies corresponding to different anomaly ratio ranges can be set from the perspective of whether to implement degradation strategies for service requests of different data types, and can also be combined with whether to execute a retry strategy first in the predetermined degradation strategies corresponding to different anomaly ratio ranges.

[0074] In some embodiments of this application, a predetermined degradation strategy corresponding to a certain percentage of anomalies can be set to first execute a retry strategy, and then set whether to execute a degradation strategy for service requests of different data types; the predetermined degradation strategy corresponding to a certain percentage of anomalies does not execute a retry strategy, and directly sets whether to execute a degradation strategy for service requests of different data types. The specific settings can be made according to the actual situation, and are not limited here.

[0075] In some embodiments of this application, four abnormal proportion ranges (a first abnormal proportion range, a second abnormal proportion range, a third abnormal proportion range, and a fourth abnormal proportion range) are set, along with a predetermined degradation strategy corresponding to each abnormal proportion range, as detailed below:

[0076] When the abnormal proportion of the target single POD falls within the first abnormal proportion range, the predetermined degradation strategy (hereinafter referred to as the first predetermined degradation strategy) is to first execute a retry strategy (hereinafter referred to as retry strategy 1). If the retry strategy succeeds, the returned data corresponding to the retry strategy is used as the target business data. If the retry strategy fails, the first degradation strategy is executed. The first degradation strategy is to determine the pre-stored degradation data corresponding to the target service request as the target business data when the data type of the target service request is of the first type. If the data type of the target service request is of a type other than the first type, the retry strategy is executed again (hereinafter referred to as retry strategy 2). The retry strategy is to call the business API corresponding to the target POD to execute the target service request based on the load balancing principle; and / or,

[0077] When the abnormal proportion of the target single POD falls within the second abnormal proportion range, the predetermined degradation strategy (hereinafter referred to as the second predetermined degradation strategy) is to first execute the retry strategy (hereinafter referred to as retry strategy 1). If the retry strategy succeeds, the returned data corresponding to the retry strategy is used as the target business data. If the retry strategy fails, the second degradation strategy is executed. The second degradation strategy is to determine the pre-stored degradation data corresponding to the target service request as the target business data when the data type of the target service request is one of the first type and the second type. If the data type of the target service request is one other than the first type and the second type, the retry strategy is executed again (hereinafter referred to as retry strategy 2); and / or,

[0078] When the abnormal proportion of the target single POD falls within the third abnormal proportion range, the predetermined degradation strategy (hereinafter referred to as the third predetermined degradation strategy) is to first execute the retry strategy (hereinafter referred to as retry strategy 1). If the retry strategy succeeds, the returned data corresponding to the retry strategy is used as the target business data. If the retry strategy fails, the third degradation strategy is executed. The third degradation strategy determines the pre-stored degradation data corresponding to the target service request as the target business data. The data type of the target service request is one of the first type, the second type, and the third type; and / or,

[0079] If the abnormal proportion of the target single POD is within the fourth abnormal proportion range, the target's predetermined downgrade strategy (hereinafter referred to as the fourth predetermined downgrade strategy) is the third downgrade strategy;

[0080] Among them, each value in the first abnormal proportion range is less than the minimum value in the second abnormal proportion range, each value in the second abnormal proportion range is less than the minimum value in the third abnormal proportion range, and each value in the third abnormal proportion range is less than the minimum value in the fourth abnormal proportion range; the importance of the data corresponding to the first type is less than the importance of the data corresponding to the second type, and the importance of the data corresponding to the second type is less than the importance of the data corresponding to the third type.

[0081] In some embodiments of this application, the importance of data corresponding to a data type can be determined based on the degree of impact of that data type on the user. For example, the higher the degree of impact of a data type on the user, the higher the importance of that data type; or, the greater the pressure on the business system to obtain a data type, the higher the importance of that data type; or, the more important a data type is from an operational perspective, the higher its importance; the importance of different data types can also be determined from other angles or aspects.

[0082] It is understood that the aforementioned first predetermined degradation strategy first executes a retry strategy for target service requests of any data type (i.e., retrying to obtain the target business data corresponding to the target service request by calling the business API). If the retry strategy fails, a degradation strategy is executed for target service requests of data type 1, that is, the pre-stored degradation data corresponding to the target service request is returned to the terminal device as the target business data. For target service requests of data types other than type 1, the retry strategy is executed again (i.e., retrying to obtain the target business data corresponding to the target service request by calling the business API again).

[0083] The aforementioned second predetermined degradation strategy involves first executing a retry strategy for target service requests of any data type (i.e., retrying to obtain the target service data corresponding to the target service request by calling the business API). If the retry strategy fails, a degradation strategy is executed for target service requests of data type one of the first and second types, that is, the pre-stored degradation data corresponding to the target service request is returned to the terminal device as the target service data. For target service requests of data type other than the first and second types, the retry strategy is executed again (i.e., retrying to obtain the target service data corresponding to the target service request by calling the business API again).

[0084] The aforementioned third predetermined degradation strategy first executes a retry strategy for target service requests of any data type (i.e., retrying to obtain the target business data corresponding to the target service request by calling the business API). If the retry strategy fails, a degradation strategy is executed for target service requests of one of the first, second, and third data types, that is, the pre-stored degradation data corresponding to the target service request is returned to the terminal device as the target business data (i.e., if the retry strategy fails, a degradation strategy is executed for target service requests of all data types).

[0085] The aforementioned fourth predetermined degradation strategy is to execute a degradation strategy for target service requests whose data type is one of the first, second, and third types, that is, to return the pre-stored degradation data corresponding to the target service request as the target service data to the terminal device (i.e., to directly execute the degradation strategy for target service requests of all data types).

[0086] The first to fourth predetermined degradation strategies described above are based on three data types: Type 1, Type 2, and Type 3. In practice, if there are more data types, more predetermined degradation strategies can be set. The specific strategy can be determined according to the actual situation and is not limited here.

[0087] It is understandable that the degradation level of the first predetermined degradation strategy is lower than that of the second predetermined degradation strategy, the degradation level of the second predetermined degradation strategy is lower than that of the third predetermined degradation strategy, and the degradation level of the third predetermined degradation strategy is lower than that of the fourth predetermined degradation strategy. The higher the proportion of anomalies in the target single POD corresponding to the target POD, the higher the degradation level of the predetermined degradation strategy matched for the target service request may be. The higher the degradation level of the predetermined degradation strategy, the more data types may be targeted for the degradation strategy.

[0088] For example, based on the characteristics of operational orchestration and user behavior, internet business data can be basically divided into four categories: static data, personalized recommendation data, user profile data, and user-customized data, as shown in Table 1 below:

[0089] Table 1

[0090]

[0091] The proposed degradation strategy is divided into four degradation levels based on the degree of impact on user experience caused by different data types (i.e., according to the degree of impact on users). The system allows for flexible configuration of whether each data type can be degraded at each degradation level. If degradation is possible, the pre-stored degradation data is used as the target business data for the corresponding target service request. The data types of degradation data corresponding to the different degradation levels defined in this application are detailed in Table 2 below.

[0092] Table 2

[0093]

[0094] For example, the first type can be personalized recommendation data, and the first predetermined degradation strategy can be a retry strategy plus a mildly lossy strategy (Level 1 degradation strategy); the second type can be user profile data, and the second predetermined degradation strategy can be a retry strategy plus a moderately lossy strategy (Level 2 degradation strategy); the third type can be user-customized data, and the third predetermined degradation strategy can be a retry strategy plus a severely lossy strategy (Level 3 degradation strategy); the fourth predetermined degradation strategy can be a severely lossy strategy (Level 3 degradation strategy). Degrading only static data is completely lossless. Therefore, for target service requests with static data types, a global degradation strategy is executed by default (i.e., when the data type of the target service request is determined to be static data, the degradation strategy is directly executed (pre-stored degradation data is used as the target business data), without needing to execute the target service request by calling the business API).

[0095] In some embodiments of this application, degradation levels are divided according to the data type of the business service, so as to automatically adapt the degradation data with the least loss based on the abnormal situation of the business service and provide data with the least impact on the user experience.

[0096] In some embodiments of this application, a retry strategy may not be executed for a predetermined degradation strategy corresponding to each abnormality ratio range. Instead, the angle setting for whether to perform a degradation strategy for service requests of different data types can be directly set. The specific settings can be made according to the actual situation and are not limited here.

[0097] For example, based on the descriptions in Tables 1 and 2 above, four anomaly weight ranges can also be set, and then pre-defined degradation strategies corresponding to different anomaly weight ranges can be set. Specifically: when the target anomaly weight range is anomaly weight range 1, the target pre-defined degradation strategy is to execute a degradation strategy for target service requests with static data type (determining the pre-stored degradation data as the target business data), and not execute a degradation strategy for target service requests with data type other than static data (personalized recommendation data, user profile data, or user-customized data) (i.e., executing the target service request by calling the business API), and execute a retry strategy (hereinafter referred to as retry strategy 2); when the target anomaly weight range is anomaly weight range 2, the target pre-defined degradation strategy is to execute a degradation strategy for target service requests with data type static data or personalized recommendation data (determining the pre-stored degradation data as the target business data), and not execute a degradation strategy for target service requests with data type other than static data and personalized recommendation data (user profile data or user-customized data) (i.e., executing the target service request by calling the business API), and execute a retry strategy (hereinafter referred to as retry strategy 2); When the business API executes the target service request, a retry strategy (hereinafter referred to as retry strategy 2) is implemented. When the target exception ratio range is exception ratio range 3, the target pre-defined degradation strategy is to implement a degradation strategy for target service requests with data types of static data, personalized recommendation data, or user profile data (pre-stored degradation data is determined as target business data), and not to implement a degradation strategy for target service requests with data types other than static data, personalized recommendation data, and user profile data (user-customized data) (i.e., the target service request is executed by calling the business API), and a retry strategy (hereinafter referred to as retry strategy 2) is implemented. When the target exception ratio range is exception ratio range 4, the target pre-defined degradation strategy is to implement a degradation strategy for target service requests with data types of static data, personalized recommendation data, user profile data, or user-customized data (pre-stored degradation data is determined as target business data).

[0098] It should be noted that a separate single-request degradation strategy is set for static data at this time, so the global degradation strategy mentioned above does not need to be executed.

[0099] In this embodiment of the application, whether a separate single-request degradation strategy is set for static data or a global degradation strategy is executed by default can be determined according to the actual situation, and no limitation is made here.

[0100] In some embodiments of this application, retry strategy 1 involves executing the target service request by calling the business API corresponding to the target POD only once based on the load balancing principle. Retry strategy 2 involves executing the target service request by calling the business API corresponding to the target POD a maximum of N times based on the load balancing principle. If a normal business result is returned after any one execution of the target service request by calling the business API corresponding to the target POD based on the load balancing principle, the normal business result is returned to the terminal device as the target business data. If an abnormal business result is returned each time after N executions of the target service request by calling the business API corresponding to the target POD based on the load balancing principle, the business result is set to null and returned to the terminal device as the target business data, i.e., empty data is returned to the terminal device. Alternatively, pre-stored degraded data corresponding to the target service request can be returned to the terminal device as the target business data. The specific method can be determined according to the actual situation and is not limited here.

[0101] In some embodiments of this application, the degradation service can automatically adapt the degradation method (global degradation strategy or single-request degradation strategy) and degradation scope (degradation level) according to the actual business system situation, ensuring protection against all possible anomalies in the business system. The degradation service calculates the degree of business service anomaly in real time. Moderate or mild anomalies are handled by automatic single-request degradation, while severe anomalies are handled by global automatic degradation, solving the problems of insufficient coverage of business anomalies and oversensitivity leading to accidental triggering of global degradation in related technologies.

[0102] In some embodiments of this application, combined with Figure 2 ,like Figure 3 As shown, prior to S102 above, the degradation service control method provided in this application embodiment may also include S107 to S109 below, and S102 above can be specifically implemented by S102a below.

[0103] S107. Determine the global POD anomaly ratio corresponding to the downgraded service.

[0104] The global POD anomaly ratio is the average ratio of the percentage of each POD that called the business API and experienced anomalies within the previous global time window before the current global time window.

[0105] This involves obtaining the IP addresses of all PODs in the downgraded service, accessing all PODs within a fixed global time window to obtain the anomaly ratio of the corresponding PODs, and calculating the global POD anomaly ratio according to the "average calculation" rule. In this embodiment, the fixed global time window can be set to 3 minutes (which can be configured and adjusted according to actual conditions; the shorter the window period (window duration) of the global time window, the more sensitive it is to global anomaly changes).

[0106] The global POD exception ratio is the sum of the exception ratios of all PODs in the previous global time window (the ratio of the number of exceptions in the corresponding POD calls to the number of business API requests received), and the ratio of the number of PODs in the downgraded service.

[0107] It should be noted that if a POD in a downgraded service does not have an anomaly ratio calculated, it will not be included in the global POD anomaly ratio calculation. Additionally, a minimum number of PODs must be set to participate in the global POD anomaly ratio calculation. If the number is below this minimum, the calculation for the current window period will be invalid, and the global POD anomaly ratio from the previous window period will be used.

[0108] S108. Determine whether the global POD anomaly ratio is within the preset global anomaly ratio range.

[0109] If the global POD abnormality ratio is within the preset global abnormality ratio range, execute S109 below; if the global POD abnormality ratio is not within the preset global abnormality ratio range, execute S102a below.

[0110] S102a. If the global POD abnormality ratio is not within the preset global abnormality ratio range, the target service API is called to execute the target service request based on the load balancing principle.

[0111] S109. If the global POD anomaly ratio is within the preset global anomaly ratio range, execute the preset global degradation strategy for the target service request to obtain the pre-stored degradation data corresponding to the target service request.

[0112] In some embodiments of this application, a preset global anomaly ratio threshold can be set. If the global POD anomaly ratio is greater than or equal to the preset global anomaly ratio threshold, it is determined that the global POD anomaly ratio is within the preset global anomaly ratio range; if the global POD anomaly ratio is less than the preset global anomaly ratio threshold, it is determined that the global POD anomaly ratio is not within the preset global anomaly ratio range.

[0113] As a measurement device for the abnormal state of business APIs, the degradation service has the advantages of independence and versatility. The degradation service calculates the "abnormal proportion of business APIs in a single POD (i.e., the abnormal proportion of a single POD)" and the "abnormal proportion of business APIs across all PODs (i.e., the abnormal proportion of global PODs)" in real time, realizing timely detection of the abnormality level of the business cluster (at least one business service managed by the degradation service), automatically adapting to the global degradation strategy or the single-request degradation strategy, and returning pre-stored degradation data with minimal loss of user experience to the terminal device.

[0114] The degradation service acts as an observer, used to statistically analyze the request result data (business results corresponding to service requests) returned by multiple business services, in order to obtain the proportion of single POD anomalies and the proportion of global POD anomalies, and determine the degradation strategy corresponding to the service request based on the proportion of single POD anomalies or the proportion of global POD anomalies.

[0115] For example, a preset global anomaly weight threshold is set to 50%, such as... Figure 4 and Figure 5 As shown, the downgraded service is deployed with 5 PODs, namely POD a, POD b, POD c, POD d, and POD e; the target service corresponding to the target service request is deployed with 10 PODs, namely POD 1, POD 2, POD 3, POD 4, POD 5, POD 6, POD 7, POD 8, POD 9, and POD 10.

[0116] Figure 4 The middle section represents the 500 service requests based on the target business service received by the degradation service from the terminal device through the gateway within the previous single POD time window. The degradation service executes these 500 requests by calling the business API in the target business service. The breakdown of the single POD anomaly ratio for each POD in the degradation service's POD a-POD e is then calculated. Figure 4 It is known that among the 10 PODs of the target business service, some POD processes have crashed or returned exceptions when calling the business API. The individual POD exception rate perceived by each POD of the degraded service is less than 20% (all less than 50%). Since the target business service can still provide basic normal business services, it is not suitable to perform degradation processing on all service requests. It is more appropriate to automatically degrade the exception requests of the business API (service requests that return exception results from the business API) (i.e., automatic degradation processing for single requests). Therefore, within the current single POD time window, the degradation service can determine the single request degradation strategy corresponding to the target service request based on the exception rate of the target single POD corresponding to the target POD in POD a-POD e.

[0117] Figure 5The middle section represents 500 service requests based on the target business service received by the degradation service from the terminal device through the gateway within the previous global time window. The degradation service calls the business API in the target business service to execute these 500 requests. The single POD anomaly ratio corresponding to each POD in the degradation service (POD a-POD e) is statistically calculated. If multiple PODs among the 10 PODs deployed in the target business service experience process crashes or most business APIs return exceptions, and the degradation service's individual POD anomaly ratio is calculated to be higher than 60%, and the global POD anomaly ratio is also higher than 60% (higher than 50%), then it is not suitable to perform automatic degradation processing on only the exception requests (service requests where the business API returns exception results). It is more suitable to perform degradation processing on all service requests to distribute the pressure on the business system and protect the business system.

[0118] In some embodiments of this application, multiple global anomaly weight ranges can be set. Different global anomaly weight ranges correspond to different global degradation strategies. If the minimum value in one global anomaly weight range is greater than any value in another global anomaly weight range, then the global degradation strategy corresponding to the one global anomaly weight range will perform degradation strategies for service requests of more data types than the global degradation strategy corresponding to the other global anomaly weight range. The specific strategy can be determined according to the actual situation and is not limited here.

[0119] In this embodiment, the method determines whether to execute a preset global degradation strategy for the target service request based on whether the global POD anomaly ratio (the average ratio of the proportion of each POD calling the business API that is abnormal within the previous global time window before the current global time window) is within a preset global anomaly ratio range. If the preset global degradation strategy is not executed, the target business API is called to execute the target service request based on the load balancing principle, provided that the target single POD anomaly ratio is within the target single POD anomaly ratio range. If the returned business result indicates an anomaly, the target predetermined degradation strategy corresponding to the target single POD anomaly ratio range is determined as the single-request degradation strategy, and the single-request degradation strategy is executed for the target service request, based on the target single POD anomaly ratio range it falls within. In this way, the degradation service calculates the degree of business service anomaly in real time. Moderate or mild anomalies are automatically degraded to single-request scenarios, while severe anomalies are automatically degraded globally, solving the problems of insufficient coverage of business anomalies and oversensitivity leading to accidental triggering of global degradation in related technologies.

[0120] In some embodiments of this application, combined with Figure 2 ,like Figure 6As shown, prior to S102 above, the degradation service control method provided in this application embodiment may also include S110 to S112 below, and S102 above can be specifically implemented by S102b below.

[0121] S110. Determine the target global degradation strategy to be executed in the current global time window.

[0122] S111. Determine the target data type to which the target service request belongs.

[0123] Different global degradation strategies target different data types of service requests that require degradation processing.

[0124] S102b: If it is determined that the global degradation policy for the target does not perform degradation processing on service requests of the target data type, the target business API is called to execute the target service request based on the load balancing principle.

[0125] S112. If it is determined that the global degradation strategy of the target applies to the service request of the target data type, the pre-stored degradation data corresponding to the target service request shall be determined as the target business data.

[0126] In this embodiment, multiple global degradation strategies are set according to the actual situation of the business system. Different global degradation strategies target different data types of service requests. Therefore, based on the target global degradation strategy executed in the current global time window and the target data type of the target service request, it is determined whether the target global degradation strategy should perform degradation processing on the target service request of the target data type. If the target global degradation strategy does not perform degradation processing on the target service request of the target data type, the target business API is called to execute the target service request based on the load balancing principle. If it is determined that the target global degradation strategy should perform degradation processing on the target service request of the target data type, the pre-stored degradation data corresponding to the target service request is determined as the target business data. In this way, degradation levels are divided according to the data type of the service request, and the minimum loss degradation data is automatically adapted. This achieves the goal of providing data with minimal impact on user experience based on abnormal business service conditions.

[0127] In some embodiments of this application, combined with Figure 6 ,like Figure 7 As shown, the above S110 can be specifically implemented through the following S110a and S110c.

[0128] S110a. Determine the global POD anomaly ratio corresponding to the downgraded service.

[0129] The global POD anomaly ratio is the average ratio of the percentage of each POD that called the business API and experienced anomalies within the previous global time window before the current global time window.

[0130] S110b: If the global POD anomaly ratio is within the target global anomaly ratio range of at least one global anomaly ratio range, determine the target preset degradation strategy corresponding to the target global anomaly ratio range.

[0131] S110c, Determine the preset degradation strategy of the target as the global degradation strategy of the target.

[0132] Different global anomaly proportion ranges correspond to different preset degradation strategies.

[0133] In some embodiments of this application, operations and maintenance personnel can configure different global POD anomaly ratio ranges corresponding to different global degradation strategies. The higher the global POD anomaly ratio, the more destructive the global degradation strategy needs to be set, so as to achieve the purpose of the higher global anomaly ratio, the more the degradation service will share the business API traffic pressure.

[0134] In this embodiment, based on the target global anomaly ratio range where the global POD anomaly ratio falls, the target preset degradation strategy corresponding to the target global anomaly ratio range is determined as the target global degradation strategy. This allows for the adaptation of a suitable global degradation strategy based on the global POD anomaly ratio (current business system pressure). Real-time calculation of the business system's service status accurately adapts the degradation method, scope, and minimum lossy data, significantly improving the timeliness and accuracy of automatic degradation. This increases the availability of business APIs from 99.94% to 99.99%, effectively ensuring normal business operations.

[0135] In this embodiment, based on the actual pressure of the current business system, a global degradation strategy or a single-request degradation strategy is adapted. By adapting a suitable single-request degradation strategy according to the single POD anomaly ratio range, the impact on user experience can be reduced. Similarly, by adapting a suitable global degradation strategy according to the global POD anomaly ratio range, the impact on user experience can also be reduced, minimizing user impact. Furthermore, the service degradation control method provided in this embodiment can cover the entire lifecycle of the business system's anomalies. Compared to related technologies that implement overall degradation after exceeding an anomaly threshold, this effectively ensures a normal user experience and achieves user satisfaction goals.

[0136] The embodiments of this application include a global degradation strategy and a single request degradation strategy. In addition to handling global request exceptions, it can also handle occasional request exceptions, thereby enabling coverage of the entire lifecycle of business system exceptions.

[0137] In some embodiments of this application, different global anomaly weight ranges can be set according to actual needs to correspond to different preset degradation strategies. This allows for the matching of the most suitable preset degradation strategy based on the actual situation of the business system (global anomaly weight), thereby alleviating the pressure on the business system while returning business data with the least impact on user experience.

[0138] In some embodiments of this application, when the target global anomaly ratio range is within a first global anomaly ratio range, the target preset degradation strategy (hereinafter referred to as the first preset degradation strategy) is to perform degradation processing on service requests of the first data type to obtain the corresponding pre-stored degradation data, and not to perform degradation processing on service requests other than the first data type, so as to call the business API to execute the service request based on the load balancing principle; and / or,

[0139] When the target's global anomaly ratio falls within the second global anomaly ratio range, the target's preset degradation strategy (hereinafter referred to as the second preset degradation strategy) is to perform degradation processing on service requests of either the first or second data type to obtain the corresponding pre-stored degradation data, and not to perform degradation processing on service requests other than the first and second data types, instead using load balancing principles to call the business API to execute the service requests; and / or,

[0140] When the target's global anomaly ratio falls within the third global anomaly ratio range, the target's preset degradation strategy (hereinafter referred to as the third preset degradation strategy) is to perform degradation processing on service requests of one of the first, second, and third data types to obtain the corresponding pre-stored degradation data; and not to perform degradation processing on service requests other than the first, second, and third data types, instead using the business API to execute the service request based on load balancing principles; and / or,

[0141] When the target global anomaly weight range is the fourth global anomaly weight range, the target preset degradation strategy (hereinafter referred to as the fourth preset degradation strategy) is to perform degradation processing on service requests of any data type to obtain the corresponding pre-stored degradation data; wherein, each value in the first global anomaly weight range is less than the minimum value in the second global anomaly weight range, each value in the second global anomaly weight range is less than the minimum value in the third global anomaly weight range, and each value in the third global anomaly weight range is less than the minimum value in the fourth global anomaly weight range; the importance of the data corresponding to the first data type is less than the importance of the data corresponding to the second data type, the importance of the data corresponding to the second data type is less than the importance of the data corresponding to the third data type, and the importance of the data corresponding to the third data type is less than the importance of the data corresponding to data types other than the first, second, and third data types.

[0142] In this embodiment, the relationship between the first data type, the second data type, the third data type, and the fourth data type and the first, second, and third types is not limited, and can be determined according to the actual situation.

[0143] For example, based on the importance of the data in relation to its impact on users, the data types of service requests are categorized into four types: static data, personalized recommendation data, user profile data, and user-customized data. The first data type is static data, the second is personalized recommendation data, the third is user profile data, and the fourth is user-customized data. The first preset degradation strategy is defined as follows: when the target service request's data type is static data, the pre-stored degradation data corresponding to the target service request is returned to the terminal device as the target business data; when the target service request's data type is one of personalized recommendation data, user profile data, or user-customized data, the business API is called to execute the target service request based on load balancing principles. The second preset degradation strategy is defined as follows: when the target service request's data type is static data or personalized recommendation data, the pre-stored degradation data corresponding to the target service request is returned to the terminal device as the target business data; when the target service request's data type is user profile data or user-customized data, the business API is called to execute the target service request based on load balancing principles. The load balancing principle calls the business API to execute the target service request. The third preset degradation strategy is as follows: if the data type of the target service request is static data, personalized recommendation data, or user profile data, the pre-stored degradation data corresponding to the target service request is returned to the terminal device as the target business data. If the data type of the target service request is user-customized data, the load balancing principle calls the business API to execute the target service request. The third preset degradation strategy is as follows: if the data type of the target service request is static data, personalized recommendation data, user profile data, or user-customized data, the pre-stored degradation data corresponding to the target service request is returned to the terminal device as the target business data.

[0144] In some embodiments of this application, the data types of service requests can be divided according to the actual situation. Then, according to the actual business system requirements, different preset degradation strategies can be divided for service requests of different data types. The specific strategy can be determined according to the actual situation and is not limited here.

[0145] In some embodiments of this application, combined with Figure 7 ,like Figure 8 As shown, before S110c, S110 may also include S110d.

[0146] S110d: Determine whether the degradation level of the target's preset degradation strategy is higher than or equal to the degradation level of the first global degradation strategy executed in the previous global time window.

[0147] If it is determined that the downgrade level of the target preset downgrade strategy is higher than or equal to the downgrade level of the first global downgrade strategy, the above S110c is executed.

[0148] In this embodiment, after determining the target preset global degradation strategy corresponding to the current global time window based on the global POD anomaly ratio, it is determined whether the degradation level of the target preset global degradation strategy is higher than or equal to the degradation level of the first global degradation strategy executed in the previous global time window. If it is determined that the degradation level of the target preset degradation strategy is higher than or equal to the degradation level of the first global degradation strategy, it is determined that the degradation level of the global degradation strategy needs to be increased relative to the previous global time window. This is because the pressure on the business system has not been well alleviated. At this time, by increasing the degradation level of the global degradation strategy, the effect of better protecting the business system can be achieved. Therefore, the target preset global degradation strategy can be directly determined as the target global degradation strategy. By executing the target global degradation strategy, the pressure on the business system can be effectively alleviated, and the business system can be better protected.

[0149] In some embodiments of this application, after implementing a global degradation strategy on business requests, the total number of service requests distributed to the business service decreases, reducing the pressure on the business service. Consequently, the proportion of exceptions occurring when calling the corresponding business API also decreases. Therefore, the calculated global POD exception ratio also decreases. However, determining the global degradation strategy solely based on the global POD exception ratio might lead to the conclusion that the business system pressure has decreased, necessitating a reduction in the global degradation strategy's degradation level. In this case, the reason for the decrease in the global POD exception ratio might be due to the distribution of business service pressure through the global degradation strategy, rather than a genuine reduction in business service pressure. If the global degradation strategy's degradation level is immediately reduced without a real reduction in business service pressure, the global POD exception ratio will rise again in the next global time window, requiring a re-increase in the global degradation strategy's degradation level. Thus, the business service pressure remains unreduced, and the frequent adjustments to the global degradation strategy's degradation level can potentially cause stability and security issues for the business system.

[0150] In some embodiments of this application, combined with Figure 8 ,like Figure 9 As shown, after S110d, if it is determined that the downgrade level of the target preset downgrade strategy is lower than the downgrade level of the first global downgrade strategy, S110 may further include S110e to S110g.

[0151] S110e, Determine whether the target quantity is equal to the quantity threshold.

[0152] The target number is the number of time windows in which the first global degradation strategy is executed consecutively before the current global time window.

[0153] The quantity threshold can be determined based on the actual situation, and is not limited here.

[0154] If the target quantity is equal to the quantity threshold, execute S110f as follows; if the target quantity is less than the quantity threshold, execute S110g as follows.

[0155] S110f: Determine the second global degradation strategy as the target global degradation strategy.

[0156] The second global degradation strategy has a degradation level one level lower than the first global degradation strategy.

[0157] S110g: Determine the first global degradation strategy as the target global degradation strategy.

[0158] In this case, for each level increase in the global degradation strategy, at least one more data type is added to the service requests that are being downgraded, and the importance of the data corresponding to each added data type is greater than the importance of the data corresponding to the non-added data types.

[0159] In some embodiments of this application, after determining the target global degradation strategy corresponding to the current global time window based on the global POD anomaly ratio, it is determined whether the degradation level of the target preset global degradation strategy is higher than or equal to the degradation level of the first global degradation strategy executed in the previous global time window. If it is determined that the degradation level of the target preset degradation strategy is lower than the degradation level of the first global degradation strategy, it is determined whether the number of time windows (target number) in which the first global degradation strategy was continuously executed before the current global time window is equal to a quantity threshold. If the target number is equal to the quantity threshold, the second global degradation strategy is determined as the target global degradation strategy (i.e., the degradation level is reduced by one level based on the first global degradation strategy). If the target number is less than the quantity threshold, the first global degradation strategy is determined as the target global degradation strategy (i.e., the degradation strategy corresponding to the previous global time window is maintained). In this way, after a number threshold of global time windows (when the pressure on the business system is likely to be alleviated), the degradation level of the degradation strategy is reduced, and each time it is reduced by one degradation level, i.e., it is reduced step by step. This can effectively ensure the security of the business system and avoid affecting the stability of the business system.

[0160] In some embodiments of this application, the quantity threshold and the number of downgrade levels each time can be determined according to the actual situation, and are not limited here.

[0161] In some embodiments of this application, combined with Figure 8 ,like Figure 9 As shown, before the above-mentioned S110f, the above-mentioned S110 may also include the following S110h.

[0162] S110h: Determine whether the degradation level of the global degradation strategy determined based on the global POD anomaly ratio in each of the target number of global time windows before the current global time window is lower than the degradation level of the global degradation strategy executed in the corresponding previous global time window.

[0163] Specifically, if in each of the target number of global time windows preceding the current global time window, the degradation level of the global degradation strategy determined based on the global POD anomaly ratio is lower than the degradation level of the global degradation strategy executed in the corresponding previous global time window, then S110f is executed; if in at least one of the target number of global time windows preceding the current global time window, the degradation level of the global degradation strategy determined based on the global POD anomaly ratio is higher than or equal to the degradation level of the global degradation strategy executed in the corresponding previous global time window, then S110g is executed.

[0164] In some embodiments of this application, after determining the target global degradation strategy corresponding to the current global time window based on the global POD anomaly ratio, it is determined whether the degradation level of the target preset global degradation strategy is higher than or equal to the degradation level of the first global degradation strategy executed in the previous global time window. If it is determined that the degradation level of the target preset degradation strategy is lower than the degradation level of the first global degradation strategy, it is determined whether the number of time windows (target number) in which the first global degradation strategy was continuously executed before the current global time window is equal to a quantity threshold. If the target number is equal to the quantity threshold, it is further determined whether the target number before the current global time window is equal to the target number. Within each of the target number of global time windows, if the degradation level of the global degradation strategy determined based on the global POD anomaly ratio is lower than the degradation level of the global degradation strategy executed in the previous global time window, then the second global degradation strategy is determined as the target global degradation strategy (i.e., a reduction of one degradation level from the first global degradation strategy). Thus, after a threshold number of global time windows (when the pressure on the business system is likely alleviated), and each global time window determines that the degradation level can be reduced, the degradation level of the degradation strategy is further reduced, one degradation level at a time, i.e., progressively lowering it. This effectively ensures the security of the business system while avoiding impacting its stability.

[0165] For example, such as Figure 10As shown, after calculating the global POD anomaly ratio in each global time window, the global degradation adjustment service matches a global degradation strategy for the corresponding global time window and determines the degradation level of the matched global degradation strategy (hereinafter referred to as the current degradation level). The current degradation level is then compared with the degradation level of the global degradation strategy executed in the previous global time window (hereinafter referred to as the previous degradation level), and the degradation level of the global degradation strategy is adjusted accordingly. The detailed logic is as follows:

[0166] 1> If the current downgrade level is higher than the previous downgrade level, then directly determine the downgrade level of the global downgrade policy corresponding to the current global time window to be raised to the current downgrade level (e.g., Figure 10 The process of determining the global degradation strategy corresponding to the global time window -2 to 3 is as follows: when it is necessary to upgrade the degradation level, it can be directly upgraded to the matching global degradation level (including adjusting the level to upgrade the degradation level).

[0167] 2> If the current downgrade level is equal to the previous downgrade level, there is no need to adjust the downgrade level of the global downgrade strategy; the global downgrade strategy corresponding to the previous global time window will continue to be executed.

[0168] 3. If the current downgrade level is lower than the previous downgrade level, it indicates that the proportion of global POD anomalies has decreased. It is necessary to determine whether the business is improving based on the number of observation windows (it is necessary to continuously assess whether the business is improving for a threshold number of global time windows). Figure 10 Taking a threshold of 5 as an example, meaning the number of observation windows is set to 5, if the number of observation windows is still less than the current downgrade level, then the current downgrade level will be lowered by one level (e.g., ...). Figure 10 (The process of determining the global degradation strategy corresponding to the global time window from -4 to 18). It is particularly important to note that the recovery process cannot skip levels; it can only recover level by level to ensure the safety of the recovery process.

[0169] In some embodiments of this application, when there is target cache data that matches the URL of the target service request, the pre-stored downgraded data is the target cache data, and different cache data match different URLs; when there is no cache data that matches the URL of the target service request, the pre-stored downgraded data is the backup data corresponding to the target service request.

[0170] The minimum data can be empty or it can be business data that meets the minimum requirements of the service request. The specific data can be determined according to the actual situation and is not limited here.

[0171] In this embodiment of the application, after calling the business API to execute a service request and obtain the business result (business data result), if the business result indicates that it is normal, the URL of the service request and the corresponding business result can be saved so that they can be used as pre-stored degradation data to provide normal business data for service requests that implement degradation strategies.

[0172] In some embodiments of this application, the URL of the service request and the corresponding business result can be stored directly, or the URL of the service request can be generalized, and the MD5 of the generalized URL can be calculated as a unique identifier and stored together with the corresponding business result.

[0173] For example, as shown in Table 3 below, the generalization process can be to generalize the user's customerId in the service request URL to a fixed value of 5989126, and to remove the last 8 digits of the deviceId and generalize it to the device model number. The specific generalization process can be determined according to the actual situation and is not limited here. Generalizing the service request URL is done to reduce the amount of stored data and improve the query hit rate.

[0174] Table 3

[0175]

[0176] In some embodiments of this application, only the URL requested by the storage service and the corresponding business result may be stored, or information such as the data type of the storage service may be stored. The specific details can be determined according to the actual situation and are not limited here.

[0177] For example, as shown in Table 4 below, the relevant information saved for a business result may include the following types: index identifier, document unique identifier, user request URL, business API return result (HTTP body), data type corresponding to the business API return result, business API return response header (HTTP header), header name, header value, and the last update time corresponding to the business result.

[0178] Table 4

[0179]

[0180] In some embodiments of this application, if target cache data matching the URL of the target service request exists, the stored target cache data can be directly obtained from the degraded service control system, and then the target cache data can be returned to the terminal device as target service data. Alternatively, the Content Delivery Network (CDN) redirect URL corresponding to the target cache data can be obtained, and then the CDN redirect URL can be returned to the terminal device. The terminal device can access the CDN and obtain the data based on the CDN redirect URL. The specific implementation can be determined according to the actual situation and is not limited here.

[0181] Terminal devices access the CDN based on the CDN redirect URL. If the target cache data is stored in the CDN, it is returned to the terminal device as the target business data. If the target cache data is not stored in the CDN, the CDN forwards the terminal device's request to the degradation service control system through the "degradation service origin interface" to obtain the target cache data from the degradation service control system, returns the target cache data to the terminal device as the target business data, and stores the target cache data locally in the CDN.

[0182] In some embodiments of this application, if target cached data matching the URL of the target service request exists, the target cached data is determined as pre-stored degradation data; if no cached data matching the URL of the target service request exists, the target service data can be obtained first through a retry strategy. If the target service data is successfully obtained, it is returned to the terminal device; if the target service data is still not successfully obtained (the service result is abnormal), the backup data corresponding to the target service request is determined as pre-stored degradation data. The specific details can be determined according to the actual situation and are not limited here.

[0183] In this embodiment, the business results of periodically stored service requests are used as pre-stored degradation data. This data serves as the degradation data corresponding to service requests when the degradation strategy is executed, thus alleviating business pressure and achieving the expected traffic diversion. Simultaneously, pre-stored business results as degradation data avoids secondary pressure from degraded scenarios caused by calling business services. This effectively protects the business system while eliminating the need to deploy separate degradation services for numerous businesses, saving service resources.

[0184] like Figure 11As shown in the illustration, this application also provides a degraded service control device 1100, which can be one or more servers. The degraded service control device 1100 includes a processor 1101, a memory 1102, and a computer program stored in the memory 1102 and executable on the processor 1101. When executed by the processor 1101, the computer program performs the various processes described in the degraded service control method, achieving the same technical effect. To avoid repetition, further details are omitted here.

[0185] like Figure 12 As shown in the illustration, this application also provides a degradation service control system, including: degradation service 121, stream processing platform 122, acquisition service 123, data storage service 124, global degradation adjustment service 125, and degradation strategy background service 126; wherein,

[0186] The degradation service 121 is configured to: receive a target service request sent by a terminal device through a gateway, the target service request corresponding to a target business service carrying the target business API; the degradation service 121 includes multiple PODs, and the degradation service 121 manages the business API of at least one business service, including the target business service, through the multiple PODs.

[0187] Based on the global POD anomaly ratio corresponding to the downgraded service 121, determine the target global downgrade strategy to be executed in the current global time window, and determine the target data type of the target service request; the global POD anomaly ratio is the average ratio of the proportion of each POD calling the business API to be abnormal in the previous global time window before the current global time window, and different global downgrade strategies target different data types of service requests for downgrade processing;

[0188] If it is determined that the global degradation policy for this target data type does not perform degradation processing on service requests, the target business API is invoked to execute the target service request based on the principle of load balancing. If the business result returned by the target business API for this target service request is abnormal, a single request degradation policy is executed for this target service request to obtain the target business data corresponding to the target service request. If the business result returned by the target business API for this target service request is normal, the business result is determined as the target business data.

[0189] If it is determined that the global degradation strategy for this target applies to service requests of this target data type, the pre-stored degradation data corresponding to this target service request will be identified as the target business data.

[0190] The gateway returns the target service data and the target data type to the target terminal.

[0191] The stream processing platform 122 is configured to receive the target business data and the target data type returned by the degradation service 121 through the gateway;

[0192] The collection service 123 is configured to consume messages from the stream processing platform 122 and save the target business data and the target data type to the data storage service 124.

[0193] The background service 126 for the degradation strategy is configured to: configure a global degradation strategy and / or a single request degradation strategy based on the data type, or configure a global degradation strategy and / or a single request degradation strategy based on the operation of the maintenance personnel.

[0194] The configured global degradation strategy and / or single request degradation strategy are pushed to the degradation service 121 through the stream processing platform 122;

[0195] Global degradation adjustment service 125 is configured to periodically obtain the real-time global POD anomaly ratio corresponding to this degradation service 121;

[0196] Based on the real-time global POD anomaly ratio, update the correspondence between the global anomaly ratio range and the preset degradation strategy to update the degradation level of the global degradation strategy, and send the updated global degradation level to the degradation strategy backend service 126.

[0197] The background service 126 of the degradation strategy is also configured to: update the degradation level of the updated global degradation strategy, and push the updated global degradation level of the global degradation strategy to the degradation service 121 through the stream processing platform 122.

[0198] The degradation service control system provided in this application embodiment can realize the various processes executed by the degradation service control method described above, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0199] For example, such as Figure 13 The diagram shows the architecture of the degradation service control system provided in this application embodiment and the flowchart of the corresponding degradation service control method (the area indicated by the dashed box in the figure is the degradation service control system). The above-mentioned stream processing platform 122 is the Kafka platform, and the data storage service 124 is the real-time search engine (ElasticSearch, ES, also known as a data warehouse).

[0200] Figure 13Steps 3.0 to 3.4 of the degradation strategy backend service support configuring degradation strategies based on data type, flexibly customizing the degradation level corresponding to each type of business data according to the degree of impairment to user experience. Specifically, this includes two methods: First, the global degradation adjustment service periodically obtains the anomaly ratio of all PODs in the degradation service, calculates the corresponding global POD anomaly ratio (and / or single POD anomaly ratio), adapts the latest global degradation level (and / or single request degradation level), updates the currently effective global degradation level (and / or single request degradation level) of the degradation strategy backend service, and pushes the latest degradation strategy to the degradation service via Kafka. Second, operations personnel configure the global degradation strategy (and / or single request degradation level) according to the anomaly ratio of the business API through the degradation strategy backend service. The degradation strategy backend service then pushes the latest degradation strategy to the degradation service via Kafka.

[0201] The global degradation adjustment service obtains the IP addresses of all PODs in the degradation service through the "POD query service", accesses all PODs in the degradation service within a fixed single POD time window to obtain the single POD anomaly ratio corresponding to each POD, and / or accesses all PODs in the degradation service within a fixed global time window to obtain the global POD anomaly ratio.

[0202] For example, the global degradation adjustment service calculates the global POD anomaly ratio in each time window, matches it with the global degradation strategy, and adjusts the global degradation level accordingly. By calling the update strategy interface of the degradation strategy backend service, the global degradation level in the backend database is updated. Simultaneously, the degradation strategy backend service sends a change message to Kafka. All PODs consuming Kafka messages in the degradation service are updated to the latest global degradation level, and all subsequent service requests are processed according to the latest degradation level.

[0203] Operations personnel configure global automatic degradation policies through the degradation policy backend service. The higher the proportion of abnormal states across all PODs, the more severe the degradation policy needs to be, aiming to achieve the goal of distributing more business API traffic pressure to the degradation service as the overall proportion of global anomalies increases. Similar to single-time automatic degradation policies, the degradation policy backend service uses two methods: "periodic full synchronization" and "real-time incremental synchronization," synchronizing the global automatic degradation policy to the degradation service through the Kafka platform.

[0204] Operations personnel configure automatic degradation policies for single requests through the degradation policy backend service. The higher the proportion of anomalies in a single POD, the more stringent and lossy the degradation policy needs to be set, aiming to increase the perceived anomaly rate and distribute more business API traffic pressure across a single POD. The degradation policy backend service uses two methods to send degradation configurations to the Kafka platform: "periodic synchronization of full degradation policies" and "real-time synchronization of incrementally changing degradation policies." The degradation service receives full degradation policies from Kafka upon startup and incrementally changing degradation policies from Kafka after startup.

[0205] For example, such as Figure 14 As shown, when the global POD anomaly rate is within 50%, a "completely lossless degradation strategy" is adopted, relying on automatic degradation of a single request to obtain as much lossless or minimally damaged data as possible; when it is between 50% and 100%, a "heavily lossy degradation strategy" is adopted, with all requests following the principle of "prioritizing the protection of business systems" and all data types being automatically degraded.

[0206] For example, such as Figure 15 As shown, if the POD (Programmable Item) anomaly rate is within 10%, a "retry + mild lossy degradation strategy" is adopted. If a single request to retry the business API still fails, personalized recommendation data can be downgraded to non-personalized data. If the rate is between 10% and 25%, a "retry + moderate lossy degradation strategy" is adopted. In addition to personalized recommendation data, user profile data can be downgraded to data from any sampled user profile group. If the rate is between 25% and 50%, a "retry + severe lossy degradation strategy" is adopted. In addition to personalized recommendation data and user profile data, user-customized data can be downgraded to anonymous user business data. If the rate is between 50% and 100%, a "no retry + severe lossy degradation strategy" is adopted. Following the principle of "prioritizing the protection of the business system," lossless data from the business API will no longer be retried, and all data types will be automatically downgraded for a single request.

[0207] The degradation service receives service requests from terminal devices. If the data type matches the global degradation level, it returns the degradation data; otherwise, it calls the business API to obtain the data. If the data retrieval fails, it adapts a single request degradation strategy (including whether to retry and the degradation level) based on the single POD exception ratio. After completing the automatic degradation processing of the single request, it returns the degradation data.

[0208] After the degraded service calls the business API to obtain the business result, it adds a collection identifier of JHK-D-Collect-Data=1 to the Response Header. The gateway identifies this identifier and sends an asynchronous Kafka message to the collection service. The message body includes the user's request URL, data type, business data result, and the business response header. The collection service performs generalization processing on the user's request URL, calculates the MD5 hash of the generalized URL as a unique identifier, and saves the degraded data to Elasticsearch.

[0209] The query interface for the degradation service is responsible for receiving service requests from terminal devices and performing degradation processing by matching global degradation policies and single-request degradation policies.

[0210] Figure 13 Steps 1.0 to 1.4 describe the data flow process between multiple modules of the degraded service control system for service requests that can obtain normal business results through the business system. Specific logic may include the terminal device routing the user-triggered service request through the gateway to the degraded service. Once the degraded service is adapted to the point where global degrade is not possible, it calls the business system's business API to obtain the business result and data type. Before returning data through the gateway, the gateway sends an asynchronous message to the Kafka platform. The collection service consumes messages from Kafka and saves the business result and data type to Elasticsearch (ES) as pre-stored degraded data for subsequent abnormal service requests.

[0211] Figure 13 Steps 2.0 to 2.8 describe how service requests that cannot obtain normal business results from the business system return pre-stored degradation data based on a global degradation strategy or a single request degradation strategy. Specific logic examples can be found by referring to... Figure 16 and Figure 18 ,in, Figure 16 The diagram shown is a flowchart of the logical processing of the degraded service - query interface (corresponding to...). Figure 13 Steps 2.0 to 2.1 include the following steps S401 to S413.

[0212] S401, Receive target service request.

[0213] The degradation service receives the target service request sent by the terminal device through the gateway.

[0214] S402. Obtain the current global degradation strategy and the target data type of the target service request.

[0215] Determine the current global degradation strategy based on the proportion of abnormal PODs in the target global system.

[0216] S403. Determine whether the target service request can be processed under global degradation.

[0217] Different global degradation strategies perform degradation processing on service requests of different data types. If the current global degradation strategy performs degradation processing on service requests of the target data type, it is determined that the target service request can perform global degradation processing, and the following S404 is executed. If the current global degradation strategy does not perform degradation processing on service requests of the target data type, it is determined that the target service request cannot perform global degradation processing, and the following S405 is executed.

[0218] S404. Return the CDN redirect URL to the terminal device.

[0219] After receiving the CDN redirect URL, the terminal device requests the target service data corresponding to the target service from the CDN based on the CDN redirect URL.

[0220] S405. Call the target business API to execute the target service request.

[0221] S406. Determine whether normal business results have been obtained.

[0222] If the target business API is called to execute the target service request and a normal business result is obtained, execute S407 below; if the target business API is called to execute the target service request and an abnormal business result is obtained, execute S408 below.

[0223] S407. Return the normal business results to the terminal device.

[0224] S408. Obtain the percentage of exceptions for a single target POD corresponding to the target business API.

[0225] S409. Match the single request degradation strategy corresponding to the proportion of abnormalities in the target single POD.

[0226] S410. Determine whether the target service request can be processed using single-request degradation.

[0227] Different single-request degradation strategies also perform degradation processing on service requests of different data types. If the current single-request degradation strategy is determined to perform degradation processing on service requests of the target data type based on the proportion of exceptions of the target single POD, and it is determined that the target service request can perform single-request degradation processing, then execute S411 below; if the current single-request degradation strategy is determined not to perform degradation processing on service requests of the target data type based on the proportion of exceptions of the target single POD, and it is determined that the target service request cannot perform single-request degradation processing, then execute S412 below.

[0228] S411. Return the CDN redirect URL to the terminal device.

[0229] After receiving the CDN redirect URL, the terminal device requests the target service data corresponding to the target service from the CDN based on the CDN redirect URL.

[0230] S412. Determine whether the number of times the retry strategy is executed is equal to the number of times threshold is applied.

[0231] When the number of times the retry policy is executed is less than the threshold, the above S405 is executed, that is, the target service request is executed again by calling the target business API to obtain the business result, thereby achieving the purpose of retrying to call the business API to execute the service request; when the number of times the retry policy is executed equals the threshold, the following S413 is executed.

[0232] S413. Return the backup data corresponding to the target service request to the terminal device.

[0233] Among them, the backup data is the fixed default data configured, which is equivalent to the specific settings data returned to the terminal when the business API is rate-limited or allowed, and is used to send data when downgrading is not possible.

[0234] For example, the safety net data can be empty.

[0235] It should be noted that S413 above can also be replaced by returning the CDN redirect URL to the terminal device, so that after receiving the CDN redirect URL, the terminal device can request the target service data corresponding to the target service from the CDN based on the CDN redirect URL.

[0236] Figure 17 The logical flowchart for matching global degradation policies and single-request degradation policies to degraded services corresponds to the above. Figure 16The degradation service receives the target service request, then obtains the global POD anomaly ratio, and matches it against the current global degradation strategy to determine whether the current global degradation strategy applies degradation processing to the data type of the target service request. If the degradation service determines that the current global degradation strategy applies degradation processing to the data type of the target service request, it determines that degradation is possible and sends pre-stored degradation data to the terminal device, which receives the pre-stored degradation data. If the degradation service determines that the current global degradation strategy does not apply degradation processing to the data type of the target service request, it determines that degradation is not possible, calls the business API to execute the target service request, and if the business API returns a normal business result, the call to the business API to execute the target service request is successful, and the business result is returned to the terminal device. If the result indicates an anomaly and the call to the business API to execute the target service request fails, a single-request degradation strategy will be applied. If the target service request matches the "retry strategy plus mild lossy degradation strategy (or moderate lossy degradation strategy or severe lossy degradation strategy)", and the retry strategy succeeds, the business result will be returned to the terminal device. If the retry strategy fails, the pre-stored degradation data will be returned to the terminal device, and the terminal device will obtain the business result or the pre-stored degradation data. If the target service request matches the "no retry strategy plus severe lossy degradation strategy", the pre-stored degradation data will be returned to the terminal device, and the terminal device will obtain the pre-stored degradation data.

[0237] In this embodiment, a global degradation strategy is adapted to the global POD anomaly ratio. If the data type of the target service request matches the global degradation strategy, degradation data is issued; otherwise, the business API is called again, thus achieving degradation control for all terminal requests in severe anomaly scenarios. For requests that fail to call the business API, a single request degradation strategy is adapted to the single POD anomaly ratio. A low anomaly ratio indicates high business availability, and a "retry + light, medium, or severe lossy degradation strategy" is adopted. Conversely, a high anomaly ratio indicates low business availability, and a "no retry + severe lossy degradation" approach is adopted. By calculating the anomaly ratios at two levels—global POD and single POD—in real time, and adapting degradation thresholds layer by layer, the degradation method, degradation scope, and minimum lossy data are determined, achieving the goal of full-cycle business anomaly coverage.

[0238] Figure 18 The diagram shown is a flowchart of the logical processing of the degraded service - origin interface (corresponding to...). Figure 13 Steps 2.2 to 2.8 in the process include the following S501 to S509.

[0239] S501: Receive requests from the gateway to obtain pre-stored degradation data corresponding to the target service request from the CDN.

[0240] After receiving the CDN redirect URL, the terminal device requests the target service data corresponding to the target service request from the CDN based on the CDN redirect URL. If the CDN does not store the target service data corresponding to the target service request, it sends a request to the degradation service through the origin interface to obtain the message of the pre-stored degradation data corresponding to the target service request.

[0241] It should be noted that if the CDN query shows that the target service data corresponding to the target service request is stored in the CDN, the target service data will be returned to the terminal device.

[0242] S502. Determine whether ES includes pre-stored downgrade data.

[0243] Query Elasticsearch (ES) to determine if ES includes pre-stored degradation data (corresponding to the target service request). Generate a generic URL md5 by generalizing the URL of the target service request. Query ES based on the generic URL md5. If degradation data matching the generic URL md5 exists in ES, it is determined that ES includes pre-stored degradation data, and the following step S503 is executed; otherwise, if no degradation data matching the generic URL md5 exists in ES, it is determined that ES does not include pre-stored degradation data, and the following step S505 is executed.

[0244] S503, retrieve pre-stored degradation data from ES.

[0245] S504. Return the pre-stored downgraded data to the CDN.

[0246] After receiving the pre-stored degradation data, the CDN returns the pre-stored degradation data as the target service data to the terminal device.

[0247] CDN can also generate CDN cache files based on pre-stored degradation data and set the validity period of the CDN cache files. In this case, the validity period of the CDN cache files is usually not set to 0.

[0248] S505, Call the business API to execute the target service request.

[0249] S506. Determine whether the correct business result has been obtained.

[0250] If the business results are normal, execute S507 below; if the business results are normal, execute S508 below.

[0251] S507. Save the correct business results to ES and return the correct business results to CDN.

[0252] After receiving the correct service result, the CDN returns the correct service result as the target service data to the terminal device.

[0253] CDN can also generate CDN cache files based on correct business results and set the validity period of the CDN cache files. In this case, the validity period of the CDN cache files is usually not set to 0.

[0254] S508. Obtain the backup data corresponding to the target service request.

[0255] S509. Return the backup data to the CDN.

[0256] After receiving the backup data, the CDN returns the backup data to the terminal device as the target business data.

[0257] Among them, CDN does not generate CDN cache files based on the guaranteed data.

[0258] This invention also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the aforementioned degraded service control method and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0259] The computer-readable storage medium can be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0260] The present invention provides a computer program product, comprising: when the computer program product is run on a computer, causing the computer to implement the above-described degradation service control method.

[0261] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0262] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the above exemplary discussion is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the principles and practical applications, thereby enabling those skilled in the art to better utilize the described embodiments and various different variations of embodiments suitable for specific use considerations.

Claims

1. A method for controlling service degradation, characterized in that, A degradation service control system applied to include degradation services, wherein the degradation services include multiple Points of Degradation (PODs), and the degradation services manage the business APIs of at least one business service, including a target business service, through the multiple PODs; including: Receive a target service request sent by a terminal device; based on the principle of load balancing, call the target business API to execute the target service request, wherein the target service request corresponds to the target business service that carries the target business API; If the business result returned by the target business API in response to the target service request indicates an anomaly, the anomaly ratio of the target single POD corresponding to the target business API is determined. The anomaly ratio of the target single POD is used to indicate the proportion of the target POD calling the business API that resulted in an anomaly within the previous single POD time window before the current single POD time window. The target POD is the POD among the plurality of PODs that calls the target business API to execute the target service request. When the target single POD anomaly ratio is within the target single POD anomaly ratio range, the target predetermined degradation strategy corresponding to the target single POD anomaly ratio range is determined as the single request degradation strategy. Different single POD anomaly ratio ranges correspond to different predetermined degradation strategies. A single request degradation strategy is executed for the target service request to obtain the target business data corresponding to the target service request; Send the target service data to the terminal device; Wherein, if the abnormal proportion range of the target single POD is within the first abnormal proportion range, the predetermined degradation strategy is to first execute a retry strategy. If the retry strategy is successful, the returned data corresponding to the retry strategy is used as the target business data. If the retry strategy fails, a first degradation strategy is executed. The first degradation strategy is to determine the pre-stored degradation data corresponding to the target service request as the target business data when the data type of the target service request is a first type. If the data type of the target service request is a type other than the first type, the retry strategy is executed again. The retry strategy is to call the business API corresponding to the target POD to execute the target service request based on the load balancing principle. And / or, When the target single POD anomaly ratio range is within the second anomaly ratio range, the target predetermined degradation strategy is to first execute the retry strategy. If the retry strategy is successful, the returned data corresponding to the retry strategy is used as the target service data. If the retry strategy fails, the second degradation strategy is executed. The second degradation strategy is to determine the pre-stored degradation data corresponding to the target service request as the target service data when the data type of the target service request is one of the first type and the second type. If the data type of the target service request is one other than the first type and the second type, the retry strategy is executed again. And / or, When the target single POD anomaly ratio range is within the third anomaly ratio range, the target predetermined degradation strategy is to first execute the retry strategy. If the retry strategy is successful, the returned data corresponding to the retry strategy is used as the target service data. If the retry strategy fails, the third degradation strategy is executed. The third degradation strategy is to determine the pre-stored degradation data corresponding to the target service request as the target service data. The data type of the target service request is one of the first type, the second type, and the third type. And / or, When the target single POD anomaly ratio range is the fourth anomaly ratio range, the target predetermined degradation strategy is the third degradation strategy; Wherein, each value in the first abnormal proportion range is less than the minimum value in the second abnormal proportion range, each value in the second abnormal proportion range is less than the minimum value in the third abnormal proportion range, and each value in the third abnormal proportion range is less than the minimum value in the fourth abnormal proportion range. The importance of the data corresponding to the first type is less than that of the data corresponding to the second type, and the importance of the data corresponding to the second type is less than that of the data corresponding to the third type.

2. The method according to claim 1, characterized in that, Before invoking the target business API to execute the target service request based on the load balancing principle, the method further includes: Determine the global POD anomaly ratio corresponding to the downgraded service. The global POD anomaly ratio is the average ratio of the proportion of each POD calling the business API that is abnormal within the previous global time window before the current global time window. Determine whether the global POD anomaly ratio is within a preset global anomaly ratio range; The process of calling the target business API to execute the target service request based on the load balancing principle includes: If the global POD anomaly ratio is not within the preset global anomaly ratio range, the target service request is executed by calling the target business API based on the load balancing principle. The method further includes: If the global POD anomaly ratio is within the preset global anomaly ratio range, a preset global degradation strategy is executed for the target service request to obtain pre-stored degradation data corresponding to the target service request.

3. The method according to claim 1, characterized in that, Before invoking the target business API to execute the target service request based on the load balancing principle, the method further includes: Determine the target global degradation strategy to be executed in the current global time window, and determine the target data type of the target service request; different global degradation strategies target different data types of service requests for degradation processing; The process of calling the target business API to execute the target service request based on the load balancing principle includes: If it is determined that the target global degradation policy does not perform degradation processing on service requests of the target data type, the target service request is executed by calling the target business API based on the load balancing principle. The method further includes: If it is determined that the target global degradation strategy applies degradation processing to service requests of the target data type, the pre-stored degradation data corresponding to the target service request is determined as the target business data.

4. The method according to claim 3, characterized in that, The determination of the target global degradation strategy to be executed in the current global time window includes: Determine the global POD anomaly ratio corresponding to the downgraded service. The global POD anomaly ratio is the average ratio of the proportion of each POD calling the business API that is abnormal within the previous global time window before the current global time window. When the global POD anomaly ratio is within the target global anomaly ratio range of at least one global anomaly ratio range, the target preset degradation strategy corresponding to the target global anomaly ratio range is determined as the target global degradation strategy, and different global anomaly ratio ranges correspond to different preset degradation strategies.

5. The method according to claim 4, characterized in that, When the target global anomaly ratio range is the first global anomaly ratio range, the target preset degradation strategy is to perform degradation processing on service requests of the first data type to obtain the corresponding pre-stored degradation data, and not to perform degradation processing on service requests other than the first data type in order to call the business API to execute the service request based on the load balancing principle. And / or, When the target global anomaly ratio range is within the second global anomaly ratio range, the target preset degradation strategy is to perform degradation processing on service requests of one of the first and second data types to obtain the corresponding pre-stored degradation data, and not perform degradation processing on service requests other than the first and second data types, so as to call the business API to execute the service request based on the load balancing principle; and / or, When the target global anomaly ratio range is the third global anomaly ratio range, the target preset degradation strategy is to perform degradation processing on service requests of one of the first data type, the second data type, and the third data type to obtain the corresponding pre-stored degradation data, and not to perform degradation processing on service requests other than the first data type, the second data type, and the third data type, so as to call the business API to execute the service request based on the load balancing principle. And / or, When the target global anomaly ratio range is the fourth global anomaly ratio range, the target preset degradation strategy is to perform degradation processing on service requests of any data type to obtain the corresponding pre-stored degradation data; Wherein, each value in the first global anomaly proportion range is less than the minimum value in the second global anomaly proportion range, each value in the second global anomaly proportion range is less than the minimum value in the third global anomaly proportion range, and each value in the third global anomaly proportion range is less than the minimum value in the fourth global anomaly proportion range. The importance of the data corresponding to the first data type is less than the importance of the data corresponding to the second data type, the importance of the data corresponding to the second data type is less than the importance of the data corresponding to the third data type, and the importance of the data corresponding to the third data type is less than the importance of the data corresponding to data types other than the first data type, the second data type, and the third data type.

6. The method according to claim 5, characterized in that, Before determining the target preset degradation strategy corresponding to the target global anomaly ratio range as the target global degradation strategy, the method further includes: Determine whether the degradation level of the target preset degradation strategy is higher than or equal to the degradation level of the first global degradation strategy executed in the previous global time window; The step of determining the target preset degradation strategy corresponding to the target global anomaly ratio range as the target global degradation strategy includes: If it is determined that the degradation level of the target preset degradation strategy is higher than or equal to the degradation level of the first global degradation strategy, the target preset degradation strategy corresponding to the target global anomaly ratio range is determined as the target global degradation strategy. The method further includes: If it is determined that the downgrade level of the target preset downgrade strategy is lower than the downgrade level of the first global downgrade strategy, it is determined whether the target number is equal to the number threshold, wherein the target number is the number of time windows in which the first global downgrade strategy is executed continuously before the current global time window; When the target number is equal to the target number threshold, the second global degradation strategy is determined as the target global degradation strategy; the degradation level of the second global degradation strategy is one level lower than the degradation level of the first global degradation strategy. If the target number is less than the number threshold, the first global degradation strategy is determined as the target global degradation strategy; In this case, for each level increase in the global degradation strategy, at least one more data type is added to the service requests that are being downgraded, and the importance of the data corresponding to each added data type is greater than the importance of the data corresponding to the non-added data types.

7. The method according to claim 6, characterized in that, The step of determining the second global degradation strategy as the target global degradation strategy when the target quantity equals the quantity threshold includes: If the target number is equal to the target number threshold, and in each of the target number of global time windows before the current global time window, the degradation level of the global degradation strategy determined according to the global POD anomaly ratio is lower than the degradation level of the global degradation strategy executed in the corresponding previous global time window, then the second global degradation strategy is determined as the target global degradation strategy. The method further includes: If the target number is equal to the target number threshold, and in at least one of the target number of global time windows preceding the current global time window, the degradation level of the global degradation strategy determined based on the global POD anomaly ratio is higher than or equal to the degradation level of the global degradation strategy executed in the corresponding previous global time window, then the first global degradation strategy is determined as the target global degradation strategy.

8. A degraded service control system, characterized in that, include: Degradation service, stream processing platform, acquisition service, data storage service, global degradation adjustment service, degradation strategy backend service; The degradation service is configured to: receive a target service request sent by a terminal device through a gateway, the target service request corresponding to a target business service carrying the target business API; the degradation service includes multiple PODs, and the degradation service manages the business API of at least one business service, including the target business service, through the multiple PODs; Based on the global POD anomaly ratio corresponding to the downgraded service, determine the target global downgrade strategy to be executed in the current global time window, and determine the target data type to which the target service request belongs; The global POD anomaly ratio is the average ratio of the proportion of each POD calling the business API that is abnormal within the previous global time window before the current global time window. Different global degradation strategies target different data types of service requests for degradation processing. If it is determined that the target global degradation policy does not perform degradation processing on service requests of the target data type, the target service request is executed by calling the target business API based on the principle of load balancing. If the business result returned by the target business API in response to the target service request indicates an anomaly, the anomaly ratio of the target single POD corresponding to the target business API is determined. The anomaly ratio of the target single POD is used to indicate the proportion of the target POD calling the business API that resulted in an anomaly within the previous single POD time window before the current single POD time window. The target POD is the POD among the plurality of PODs that calls the target business API to execute the target service request. When the target single POD anomaly ratio is within the target single POD anomaly ratio range, the target predetermined degradation strategy corresponding to the target single POD anomaly ratio range is determined as the single request degradation strategy. Different single POD anomaly ratio ranges correspond to different predetermined degradation strategies. A single request degradation strategy is executed for the target service request to obtain the target business data corresponding to the target service request; If the business result returned by the target business API in response to the target service request is normal, the business result shall be identified as the target business data. If it is determined that the target global degradation strategy applies degradation processing to service requests of the target data type, the pre-stored degradation data corresponding to the target service request is determined as the target business data; The gateway returns the target service data and the target data type to the target terminal. The stream processing platform is configured to receive the target business data and the target data type returned by the degradation service through the gateway; The acquisition service is configured to: consume messages from the stream processing platform and save the target business data and the target data type to the data storage service; The degradation strategy backend service is configured to: configure a global degradation strategy and / or a single request degradation strategy based on the data type, or configure a global degradation strategy and / or a single request degradation strategy based on the operation of the operation and maintenance personnel. The configured global degradation strategy and / or single request degradation strategy are pushed to the degradation service through the stream processing platform. The global degradation adjustment service is configured to periodically acquire the real-time global POD anomaly ratio corresponding to the degradation service; Based on the real-time global POD anomaly ratio, update the correspondence between the global anomaly ratio range and the preset degradation strategy to update the degradation level of the global degradation strategy, and send the updated global degradation level of the global degradation strategy to the degradation strategy backend service. The degradation policy backend service is further configured to: update the degradation level of the updated global degradation policy, and push the updated global degradation level to the degradation service through the stream processing platform; Wherein, if the abnormal proportion range of the target single POD is within the first abnormal proportion range, the predetermined degradation strategy is to first execute a retry strategy. If the retry strategy is successful, the returned data corresponding to the retry strategy is used as the target business data. If the retry strategy fails, a first degradation strategy is executed. The first degradation strategy is to determine the pre-stored degradation data corresponding to the target service request as the target business data when the data type of the target service request is a first type. If the data type of the target service request is a type other than the first type, the retry strategy is executed again. The retry strategy is to call the business API corresponding to the target POD to execute the target service request based on the load balancing principle. And / or, When the target single POD anomaly ratio range is within the second anomaly ratio range, the target predetermined degradation strategy is to first execute the retry strategy. If the retry strategy is successful, the returned data corresponding to the retry strategy is used as the target service data. If the retry strategy fails, the second degradation strategy is executed. The second degradation strategy is to determine the pre-stored degradation data corresponding to the target service request as the target service data when the data type of the target service request is one of the first type and the second type. If the data type of the target service request is one other than the first type and the second type, the retry strategy is executed again. And / or, When the target single POD anomaly ratio range is within the third anomaly ratio range, the target predetermined degradation strategy is to first execute the retry strategy. If the retry strategy is successful, the returned data corresponding to the retry strategy is used as the target service data. If the retry strategy fails, the third degradation strategy is executed. The third degradation strategy is to determine the pre-stored degradation data corresponding to the target service request as the target service data. The data type of the target service request is one of the first type, the second type, and the third type. And / or, When the target single POD anomaly ratio range is the fourth anomaly ratio range, the target predetermined degradation strategy is the third degradation strategy; Wherein, each value in the first abnormal proportion range is less than the minimum value in the second abnormal proportion range, each value in the second abnormal proportion range is less than the minimum value in the third abnormal proportion range, and each value in the third abnormal proportion range is less than the minimum value in the fourth abnormal proportion range. The importance of the data corresponding to the first type is less than that of the data corresponding to the second type, and the importance of the data corresponding to the second type is less than that of the data corresponding to the third type.

Images