CN115766484A

CN115766484A - Service degradation method, device, equipment, computer readable medium and program product

Info

Publication number: CN115766484A
Application number: CN202211175549.5A
Authority: CN
Inventors: 张云飞
Original assignee: Jingdong Technology Information Technology Co Ltd
Current assignee: Jingdong Technology Information Technology Co Ltd
Priority date: 2022-09-26
Filing date: 2022-09-26
Publication date: 2023-03-07
Also published as: WO2024066374A1

Abstract

Embodiments of the present disclosure disclose a traffic degradation method, apparatus, device, computer readable medium, and program product. One embodiment of the method comprises: receiving each interface calling data corresponding to the target service; determining service configuration information corresponding to the target service, wherein the service configuration information comprises degradation configuration information, and the degradation configuration information comprises degradation threshold information and degradation interface information; determining whether to perform degradation processing on the target service according to the degradation threshold information included in the interface calling data and the service configuration information; and in response to the determination of performing degradation processing on the target service, performing service degradation processing on the request of the target service according to the degradation interface information included in the service configuration information. The service degradation of the embodiment is related, and the user-defined degradation strategy is supported from the service perspective, so that the embodiment can adapt to complex and changeable service scenes.

Description

Service degradation method, device, equipment, computer readable medium and program product

Technical Field

Embodiments of the present disclosure relate to the field of computer technologies, and in particular, to a method, an apparatus, a device, a computer-readable medium, and a program product for service degradation.

Background

In a distributed system environment, a business typically relies on multiple base services. As the complexity of the service increases, the dependency relationship between services also becomes more complex, and the service avalanche effect also follows. Degradation of the fuse component occurs in order to improve the stability of the application service. Currently, when a service is degraded, the generally adopted method is as follows: whether to downgrade is determined based on a request and a response.

However, the inventor finds that when the service is degraded in the above manner, the following technical problems often exist: the method for judging whether degradation is caused based on one-time request and response can judge whether degradation is caused when an interface is called, so that degradation is caused in an actual service scene, and the interface cannot be called when a front node of the interface is blocked, so that the state of a subsequent fuse cannot be maintained, and the applicability in a complex service scene is poor.

The above information disclosed in this background section is only for enhancement of understanding of the background of the inventive concept and, therefore, it may contain information that does not form the prior art that is already known to a person of ordinary skill in the art.

Disclosure of Invention

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

Some embodiments of the present disclosure propose traffic degradation methods, apparatuses, electronic devices, computer readable media and computer program products to solve one or more of the technical problems mentioned in the background section above.

In a first aspect, some embodiments of the present disclosure provide a method for traffic degradation, the method including: receiving each interface calling data corresponding to the target service; determining service configuration information corresponding to the target service, wherein the service configuration information comprises degradation configuration information, and the degradation configuration information comprises degradation threshold information and degradation interface information; determining whether to perform degradation processing on the target service according to the degradation threshold information included in the interface calling data and the service configuration information; and in response to the determination of performing degradation processing on the target service, performing service degradation processing on the request of the target service according to the degradation interface information included in the service configuration information.

Optionally, the degradation threshold information includes a degradation proportion threshold; and the determining whether to perform degradation processing on the target service includes: determining the number of failed calls according to the call data of each interface and preset failed call conditions; and determining to perform degradation processing on the target service in response to determining that the ratio of the number of the failed calls to the number of the call data of each interface is greater than or equal to the degradation ratio threshold.

Optionally, the degradation threshold information includes a degradation quantity threshold and a degradation proportion threshold; and the step of determining whether to perform degradation processing on the target service comprises: determining the number of failed calls according to the call data of each interface and preset failed call conditions; and determining to perform degradation processing on the target service in response to determining that the number of the failed calls is greater than or equal to the threshold of the degradation number and the ratio of the number of the failed calls to the number of the call data of each interface is greater than or equal to the threshold of the degradation ratio.

Optionally, the receiving of the call data of each interface corresponding to the target service includes: and receiving each interface calling data corresponding to the target service in a preset period time.

Optionally, the service configuration information further includes retry configuration information; and after the service degradation processing is performed on the request of the target service, the method further includes: determining whether the retry configuration information represents retrying the target service; in response to determining that the retry configuration information represents retrying the target service, adding the request to a failed request queue; and retrying the interface corresponding to the request according to the failure request queue and a preset time interval to obtain an interface retrying result set, wherein the interface retrying result in the interface retrying result set represents whether the interface is retryed successfully or not.

Optionally, the service configuration information further includes recovery configuration information, where the recovery configuration information includes recovery threshold information and recovery interface information; and the method further comprises: determining whether to perform recovery processing on the target service according to the interface retry result set and the recovery threshold information; and responding to the determination of the recovery processing of the target service, and performing service recovery processing on the target service according to the recovery interface information.

Optionally, the service configuration information further includes recovery configuration information, where the recovery configuration information includes recovery threshold information and recovery interface information; and the method further comprises: and in response to the fact that the retry configuration information represents that the target service is not retried, performing service recovery processing on the target service according to the recovery interface information.

Optionally, the recovery threshold information includes a recovery ratio threshold; and the determining whether to perform recovery processing on the target service according to the interface retry result set and the recovery threshold information includes: determining the number of interface retry results which characterize the interface retry success and are included in the interface retry result set as the retry success number; and determining to perform recovery processing on the target service in response to determining that the ratio of the retry success quantity to the quantity of each interface retry result included in the interface retry result set is greater than or equal to the recovery ratio threshold.

Optionally, the recovery threshold information includes a recovery ratio threshold and a recovery number threshold; and the determining whether to perform recovery processing on the target service according to the interface retry result set and the recovery threshold information includes: determining the number of interface retry results which are included in the interface retry result set and are used for representing the successful interface retry as the number of retry success; and in response to determining that the retry success number is greater than or equal to the recovery number threshold, and a ratio of the retry success number to the number of each interface retry result included in the interface retry result set is greater than or equal to the recovery ratio threshold, determining to perform recovery processing on the target service.

Optionally, the degradation configuration information further includes an extension service identifier, and the interface call data in each interface call data corresponds to the extension service identifier; and the determining the number of failed calls according to the call data of each interface and the preset failed call condition comprises: determining each interface calling data meeting the preset failed calling condition in each interface calling data as interface calling failure data to obtain an interface calling failure data set; determining each interface calling failure data meeting a preset expansion service identification condition in the interface calling failure data set as a target interface calling failure data set, wherein the preset expansion service identification condition is that an expansion service identification corresponding to the interface calling failure data is the same as an expansion service identification included in the degradation configuration information; and determining the quantity of the target interface call failure data included in the target interface call failure data set as the quantity of the failed calls.

Optionally, the method further comprises: and issuing the service degradation event information corresponding to the target service.

Optionally, the issuing the service degradation event information corresponding to the target service includes: and sending the service degradation event information to alarm terminal equipment.

Optionally, the issuing the service degradation event information corresponding to the target service includes: and sending the service degradation event information to a related data storage end so as to visually display the service degradation event information stored in the data storage end.

In a second aspect, some embodiments of the present disclosure provide a traffic degradation apparatus, the apparatus comprising: a receiving unit configured to receive each interface call data corresponding to the target service; a first determining unit, configured to determine service configuration information corresponding to the target service, where the service configuration information includes degradation configuration information, and the degradation configuration information includes degradation threshold information and degradation interface information; a second determining unit, configured to determine whether to perform degradation processing on the target service according to the degradation threshold information included in the interface call data and the service configuration information; and the degradation unit is configured to respond to the determination of performing degradation processing on the target service, and perform service degradation processing on the request of the target service according to the degradation interface information included in the service configuration information.

Optionally, the degradation threshold information includes a degradation ratio threshold.

Optionally, the second determination unit is further configured to: determining the number of failed calls according to the call data of each interface and preset failed call conditions; and determining to perform degradation processing on the target service in response to determining that the ratio of the number of the failed calls to the number of the call data of each interface is greater than or equal to the degradation ratio threshold.

Optionally, the degradation threshold information includes a degradation quantity threshold and a degradation proportion threshold.

Optionally, the second determination unit is further configured to: determining the number of failed calls according to the call data of each interface and preset failed call conditions; and determining to perform degradation processing on the target service in response to the fact that the number of the failed calls is larger than or equal to the threshold of the degradation number and the ratio of the number of the failed calls to the number of the call data of each interface is larger than or equal to the threshold of the degradation proportion.

Optionally, the receiving unit is further configured to: and receiving each interface calling data corresponding to the target service in a preset period time.

Optionally, the service configuration information further includes retry configuration information.

Optionally, the apparatus further comprises: a retry determination unit, an addition unit, and a retry unit. Wherein the retry determining unit is configured to determine whether the retry configuration information characterizes a retry of the target service. The adding unit is configured to add the request to a failed request queue in response to determining that the retry configuration information characterizes a retry of the target traffic. The retry unit is configured to perform retry processing on an interface corresponding to the request according to the failure request queue and a preset time interval to obtain an interface retry result set, where an interface retry result in the interface retry result set indicates whether the interface retries successfully.

Optionally, the service configuration information further includes recovery configuration information, and the recovery configuration information includes recovery threshold information and recovery interface information.

Optionally, the apparatus further comprises: a restoration determining unit and a first restoring unit. Wherein the recovery determining unit is configured to determine whether to perform recovery processing on the target service according to the interface retry result set and the recovery threshold information. The first recovery unit is configured to perform service recovery processing on the target service according to the recovery interface information in response to determining to perform recovery processing on the target service.

Optionally, the apparatus further comprises: and a second recovery unit configured to perform service recovery processing on the target service according to the recovery interface information in response to determining that the retry configuration information indicates that the target service is not retried.

Optionally, the recovery threshold information includes a recovery ratio threshold.

Optionally, the recovery determination unit is further configured to: determining the number of interface retry results which are included in the interface retry result set and are used for representing the successful interface retry as the number of retry success; and determining to perform recovery processing on the target service in response to determining that the ratio of the retry success number to the number of the interface retry results included in the interface retry result set is greater than or equal to the recovery ratio threshold.

Optionally, the recovery threshold information includes a recovery ratio threshold and a recovery number threshold.

Optionally, the recovery determination unit is further configured to: determining the number of interface retry results which are included in the interface retry result set and are used for representing the successful interface retry as the number of retry success; and in response to determining that the retry success quantity is greater than or equal to the recovery quantity threshold, and the ratio of the retry success quantity to the quantity of each interface retry result included in the interface retry result set is greater than or equal to the recovery ratio threshold, determining to perform recovery processing on the target service.

Optionally, the degradation configuration information further includes an extended service identifier, and the interface call data in each interface call data corresponds to the extended service identifier.

Optionally, the second determining unit includes: the device comprises a first data determining unit, a second data determining unit and a number-of-failed-call determining unit. The first data determining unit is configured to determine each interface calling data meeting the preset failed calling condition in the interface calling data as interface calling failure data, and obtain an interface calling failure data set. And the second data determining unit is configured to determine, as a target interface call failure data set, each interface call failure data meeting a preset extension service identification condition in the interface call failure data set, where the preset extension service identification condition is that an extension service identification corresponding to the interface call failure data is the same as an extension service identification included in the degradation configuration information. The number-of-failed-calls determining unit is configured to determine the number of pieces of target interface call failure data included in the target interface call failure data set as the number of failed calls.

Optionally, the service degradation apparatus further includes: and the issuing unit is configured to issue the service degradation event information corresponding to the target service.

Optionally, the publication unit is further configured to: and sending the service degradation event information to alarm terminal equipment.

Optionally, the publication unit is further configured to: and sending the service degradation event information to a related data storage end for visually displaying each service degradation event information stored by the data storage end.

In a third aspect, some embodiments of the present disclosure provide an electronic device, comprising: one or more processors; a storage device having one or more programs stored thereon, which when executed by one or more processors, cause the one or more processors to implement the method described in any of the implementations of the first aspect.

In a fourth aspect, some embodiments of the present disclosure provide a computer readable medium on which a computer program is stored, wherein the program, when executed by a processor, implements the method described in any of the implementations of the first aspect.

In a fifth aspect, some embodiments of the present disclosure provide a computer program product comprising a computer program that, when executed by a processor, implements the method described in any of the implementations of the first aspect above.

The above embodiments of the present disclosure have the following advantages: by the service degradation method of some embodiments of the present disclosure, a user-defined degradation strategy is supported from a service perspective, so that the method can adapt to complex and variable service scenarios. In particular, the reasons for poor applicability in complex business scenarios are: the method for judging whether the interface is degraded or not based on one-time request and response can judge whether the interface is degraded or not when the interface is called, so that the degradation is caused in an actual service scene, and the interface cannot be called when a front node of the interface is blocked, so that the state of a subsequent fuse cannot be maintained, and the applicability in a complex service scene is poor. Based on this, the service degradation method according to some embodiments of the present disclosure first receives each interface call data corresponding to the target service. Therefore, the received interface calling data can represent the data of the interface calling the target service for multiple times, so as to judge whether the target service is degraded or not. Then, the service configuration information corresponding to the target service is determined. The service configuration information includes degradation configuration information, and the degradation configuration information includes degradation threshold information and degradation interface information. Thus, the determined service configuration information may represent relevant information configured for the target service, and the degradation configuration information included in the service configuration information may represent degradation logic relevant information configured for the target service. And then, determining whether to carry out degradation processing on the target service according to the degradation threshold information included in the interface calling data and the service configuration information. Therefore, whether the target service is subjected to degradation processing can be determined through calling data of each interface of the target service for multiple times and the user-defined degradation threshold information of the target service. And finally, responding to the determination of the degradation processing of the target service, and performing service degradation processing on the request of the target service according to the degradation interface information included in the service configuration information. Therefore, when the target service is determined to be degraded, the target service can be degraded through the user-defined configured degradation interface information of the target service. And because the received interface calling data are data for calling the interface of the target service for multiple times, a mode of judging whether to degrade based on one request and response is avoided. And because the degraded configuration information in the determined service configuration information is previously self-defined, the degraded configuration information can be adjusted according to the change of the service scene. Therefore, the user-defined degradation strategy is supported from the service perspective, and the method can adapt to complex and changeable service scenes.

Drawings

The above and other features, advantages, and aspects of embodiments of the present disclosure will become more apparent by referring to the following detailed description when taken in conjunction with the accompanying drawings. Throughout the drawings, the same or similar reference numbers refer to the same or similar elements. It should be understood that the drawings are schematic and that elements and components are not necessarily drawn to scale.

FIG. 1 is an architectural diagram of an exemplary system in which some embodiments of the present disclosure may be applied;

FIG. 2 is a timing diagram of one application scenario of a traffic downgrading method, according to some embodiments of the present disclosure;

FIG. 3 is a flow diagram of some embodiments of a traffic downgrading method according to the present disclosure;

FIG. 4 is a flow diagram of further embodiments of a traffic downgrading method, according to the present disclosure;

FIG. 5 is a flow diagram of still further embodiments of a traffic downgrading method according to the present disclosure;

FIG. 6 is a schematic block diagram of some embodiments of traffic downgrading apparatus, according to the present disclosure;

FIG. 7 is a schematic block diagram of an electronic device suitable for use in implementing some embodiments of the present disclosure.

Detailed Description

Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure are shown in the drawings, it is to be understood that the disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete. It should be understood that the drawings and the embodiments of the disclosure are for illustration purposes only and are not intended to limit the scope of the disclosure.

It should be noted that, for convenience of description, only the portions related to the related invention are shown in the drawings. The embodiments and features of the embodiments in the present disclosure may be combined with each other without conflict.

It should be noted that the terms "first", "second", and the like in the present disclosure are only used for distinguishing different devices, modules or units, and are not used for limiting the order or interdependence relationship of the functions performed by the devices, modules or units.

It is noted that references to "a", "an", and "the" modifications in this disclosure are intended to be illustrative rather than limiting, and that those skilled in the art will recognize that "one or more" may be used unless the context clearly dictates otherwise.

The names of messages or information exchanged between devices in the embodiments of the present disclosure are for illustrative purposes only, and are not intended to limit the scope of the messages or information.

The present disclosure will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.

Fig. 1 illustrates an exemplary system architecture 100 of a traffic-downgrading method or traffic-downgrading apparatus to which some embodiments of the present disclosure may be applied.

As shown in fig. 1, the system architecture 100 may include

terminal devices

101, 102, 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between the

terminal devices

101, 102, 103 and the server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

A user may use

terminal devices

101, 102, 103 to interact with a server 105 over a network 104 to receive or send messages or the like. The

terminal devices

101, 102, 103 may have various communication client applications installed thereon, such as a web browser application, a search-type application, an instant messaging tool, a mailbox client, social platform software, and the like.

The

terminal devices

101, 102, 103 may be hardware or software. When the

terminal devices

101, 102, 103 are hardware, they may be various electronic devices having a display screen and supporting information browsing, including but not limited to smart phones, tablet computers, e-book readers, laptop portable computers, desktop computers, and the like. When the

terminal apparatuses

101, 102, 103 are software, they can be installed in the electronic apparatuses listed above. It may be implemented, for example, as multiple software or software modules for providing distributed services, or as a single software or software module. And is not particularly limited herein.

The server 105 may be a server providing various services, such as a backend server providing support for information displayed on the

terminal devices

101, 102, 103. The background server can analyze and process the received data such as the request and feed back the processing result to the terminal equipment.

It should be noted that the service degradation method provided by the embodiment of the present disclosure may be executed by the server 105. Accordingly, traffic downgrading means may be provided in the server 105.

The server may be hardware or software. When the server is hardware, it may be implemented as a distributed server cluster composed of multiple servers, or may be implemented as a single server. When the server is software, it may be implemented as multiple software or software modules, for example, to provide distributed services, or as a single software or software module. And is not particularly limited herein.

It should be understood that the number of terminal devices, networks, and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Fig. 2 is a timing diagram of one application scenario of a traffic downgrading method, according to some embodiments of the present disclosure.

In the application scenario of fig. 2, the user terminal may send a request to the service system. The service system may be a server for responding to a request from a client. The business system may request an external service from the external dependency. The external dependency may be a server for providing services to the business system. The service system can send the interface calling data to the monitoring server. The monitoring server may be configured to perform a traffic degradation method. The time sequence process of an application scene of the service degradation method comprises the following steps:

step 201, the user side sends a request for a target service to the service system. Here, the request may be a page access request.

Step 202, the business system calls a service to an external dependency. Here, the calling service may refer to a calling interface.

Step 203, the external dependency sends the external dependency processing result to the service system. The external dependency processing result may be a processing result fed back by the external dependency for the received call request.

And step 204, the service system sends interface calling data generated according to the received external dependency processing result sent by the external dependency to the monitoring server. When the external dependency processing result comprises processing data, the service system can be characterized to successfully call the service to the external dependency, so that the service system can generate interface calling data for successfully calling the characterization interface. When the external dependency processing result is empty or the external dependency processing result comprises the identifier for representing the calling failure, the service system can be characterized to fail to call the service to the external dependency, so that the service system can generate interface calling data for representing the interface calling failure.

And step 205, the service system sends the processing result of the service system to the user side according to the received external dependency processing result sent by the external dependency. When the external dependency processing result includes processing data, the service system may generate a service system processing result corresponding to the request of the user terminal according to the processing data.

Step 206, the monitoring server determines the service configuration information corresponding to the target service. The service configuration information includes degradation configuration information, and the degradation configuration information includes degradation threshold information and degradation interface information.

Step 207, the monitoring server determines whether to perform degradation processing on the target service according to the received interface call data of the target service and degradation threshold information included in the service configuration information.

And step 208, the monitoring server responds to the determination of performing degradation processing on the target service, and performs service degradation processing on the request of the target service in the service system according to the degradation interface information included in the service configuration information.

It should be noted that the user side, the service system, the external dependency, and the monitoring server side may be hardware or software. When the user side, the service system, the external dependency and the monitoring server side are hardware, the distributed cluster formed by a plurality of servers or terminal devices may be implemented, or a single server or a single terminal device may be implemented. When the user terminal, the service system, the external dependency and the monitoring server terminal are implemented as software, they may be installed in the listed hardware devices. It may be implemented, for example, as multiple software or software modules to provide distributed services, or as a single software or software module. And is not particularly limited herein.

With continued reference to fig. 3, a flow 300 of some embodiments of a traffic downgrading method according to the present disclosure is shown. The service degradation method comprises the following steps:

step 301, receiving each interface call data corresponding to the target service.

In some embodiments, an executing entity (e.g., the server 105 shown in fig. 1 or the monitoring server shown in fig. 2) of the service downgrading method may receive respective interface call data of the corresponding target service. The target service may be any service. Here, a service may refer to a transaction implemented as an interface to provide a related service. The service may be uniquely represented by a service identification. The target service is corresponding to an interface. The data called by each interface corresponding to the target service may be data related to each calling result for calling the interface. For example, the interface call data may be data characterizing a successful call to the interface or a failure to call the interface. As an example, the interface call data may include an interface identification and an interface call result. The interface identification may uniquely identify the interface. The interface call result may characterize success or failure. The interface call data may also include a service identification. The interface call data may be sent by the request processing server of the target service. The request processing server can be understood as a service system of the above-mentioned target service. As an example, when the user sends a page request to the service system, the service system calls the interface. If the calling is successful, the interface calling result is represented successfully. And if the calling fails, the representation of the interface calling result fails. The service system may send the interface call data to the execution body, and may send the request result to the user side. In practice, the execution main body may receive a preset number of interface call data corresponding to the target service in a wired connection manner or a wireless connection manner. Here, the specific setting of the preset number is not limited.

It is noted that the wireless connection means may include, but is not limited to, a 3G/4G connection, a WiFi connection, a bluetooth connection, a WiMAX connection, a Zigbee connection, a UWB (ultra wideband) connection, and other wireless connection means now known or developed in the future.

In some optional implementation manners of some embodiments, the execution main body may receive, within a preset period of time, each interface call data corresponding to the target service. The preset period time period may be a preset periodic time period for monitoring an interface call state of the target service. For example, the monitoring period may be 5 minutes. The preset cycle time period of the last monitoring can be 08. The current preset cycle time period may be 08. Therefore, the interface calling state of the target service can be periodically monitored by receiving each interface calling data corresponding to the target service in a preset period time.

Step 302, determining service configuration information corresponding to the target service.

In some embodiments, the execution subject may determine service configuration information corresponding to the target service. The service configuration information may be configuration related information of a service. The service configuration information may include downgrade configuration information. The degradation configuration information may be information configured for a degradation process of the service. The degradation configuration information may include degradation threshold information and degradation interface information. The degradation threshold information may be threshold related information used to determine whether to degrade the traffic. The degradation threshold information may include an interface call failure number threshold. The threshold of the number of failed calls of the interface may be a threshold defining a maximum number of failed calls of the interface of the target service. The degraded interface information may be degraded interface-related information. The degraded interface information may include a degraded interface identification. The downgraded interface identification may be an identification of an interface after downgrading the target service.

In practice, the executing body may obtain, from a computing device storing each piece of service configuration information, service configuration information in which a corresponding service identifier is a service identifier of the target service. The computing device storing the respective service configuration information may be understood as a server of the configuration center.

In practice, the execution main body may further determine service configuration information corresponding to the target service from service configuration information pre-stored locally. The service configuration information pre-stored to the local may be understood as service configuration information stored to a local memory or a cache during initialization.

Step 303, determining whether to perform degradation processing on the target service according to the degradation threshold information included in each interface call data and the service configuration information.

In some embodiments, the execution subject may determine whether to perform degradation processing on the target service according to degradation threshold information included in the interface call data and the service configuration information. In practice, the execution main body may determine, as the number of failed calls, the number of pieces of interface call data representing call failures in the pieces of interface call data. Then, in response to determining that the number of failed calls is greater than or equal to the interface call failure number threshold included in the degradation threshold information, it may be determined to perform degradation processing on the target service.

Optionally, the degradation threshold information may include a degradation proportion threshold. The degradation rate threshold may be a threshold defining a maximum rate of failed calls.

In some optional implementation manners of some embodiments, the executing entity may determine whether to perform degradation processing on the target service by:

step one, determining the number of failed calls according to the call data of each interface and preset failed call conditions. The preset failed calling condition may be an interface calling data representation calling failure. In practice, the execution main body may determine, as the number of failed calls, the number of pieces of interface call data that satisfy the preset failed call condition in the pieces of interface call data.

And secondly, in response to the fact that the ratio of the number of the failed calls to the number of the call data of each interface is larger than or equal to the degradation ratio threshold, determining to perform degradation processing on the target service. Therefore, whether the target service needs to be degraded or not can be determined from the dimension of the failed calling proportion through the pre-customized configured degradation proportion threshold.

Optionally, the degradation threshold information may include a degradation amount threshold and a degradation ratio threshold.

and step one, determining the number of failed calls according to the call data of each interface and preset failed call conditions. In practice, the execution main body may determine, as the number of failed calls, the number of pieces of interface call data that satisfy the preset failed call condition in the pieces of interface call data.

And secondly, in response to the fact that the number of the failed calls is larger than or equal to the threshold value of the degradation number and the ratio of the number of the failed calls to the number of the call data of each interface is larger than or equal to the threshold value of the degradation proportion, determining to perform degradation processing on the target service. Therefore, whether the target service needs to be degraded or not can be determined by customizing the configured threshold values of the degradation proportion and the degradation quantity in advance and simultaneously determining the dimensionality of the threshold values of the failure call proportion and the degradation quantity.

Optionally, the degradation configuration information may further include an extended service identifier. The extended service identifier may be an identifier of a user-defined service, and may uniquely identify an interface method of the service. The custom service may correspond to an interface method of an interface of the target service. By expanding the service identifier, the service party can configure the calling state of the method to be monitored under the service interface in a user-defined manner. The interface calling data in the interface calling data corresponds to the extended service identifier.

In some optional implementation manners of some embodiments, the execution main body may determine the number of failed calls according to the respective interface call data and a preset failed call condition by:

first, determining each interface calling data meeting the preset failed calling condition in each interface calling data as interface calling failure data to obtain an interface calling failure data set.

And secondly, determining each interface calling failure data meeting the preset expansion service identification condition in the interface calling failure data set as a target interface calling failure data set. The preset extension service identifier condition may be that an extension service identifier corresponding to the interface call failure data is the same as the extension service identifier included in the degradation configuration information.

And thirdly, determining the quantity of the calling failure data of each target interface included in the calling failure data set of the target interface as the quantity of the calling failure. Therefore, by expanding the service identifier, the user-defined degradation strategy of the services with different granularities can be supported from the perspective of the service granularity, so that the method can adapt to complicated and changeable service scenes with different granularities.

And 304, in response to the determination of performing degradation processing on the target service, performing service degradation processing on the request of the target service according to the degradation interface information included in the service configuration information.

In some embodiments, the executing entity may perform, in response to determining to perform degradation processing on the target service, service degradation processing on the request of the target service according to degradation interface information included in the service configuration information. In practice, the execution subject may determine an interface corresponding to the degraded interface identifier included in the degraded interface information as an interface of the target service, so as to perform service degradation processing on the request of the target service.

Optionally, the execution subject may issue the service degradation event information corresponding to the target service. The service degradation event information may represent that the target service needs to be degraded or has undergone degradation processing. The service degradation event information may include, but is not limited to: interface identification before target service degradation, event type, degradation time and degradation event result. The event type may be a type of processing of an interface to the target service. For example, the traffic degradation event information may include an event type of "degrade". The degradation time can be the time for performing service degradation processing on the target service. The event outcome may be an outcome characterizing whether the degradation was successful. Here, the publishing process may be a process of transmitting the service degradation event information to the degradation event subscriber. The degradation event subscriber can be a subscriber who needs to acquire the service degradation event information. Here, the subscriber may be, but is not limited to: terminal equipment, server, this executive body. In practice, the execution main body may store the service degradation event information to a local preset directory, so as to issue the service degradation event information. The service degradation event information stored in the local preset directory can be read by other methods of the execution main body.

In practice, the executing agent may further perform, in response to receiving a degradation event result corresponding to the target service, release processing on the service degradation event information corresponding to the target service. The result of the degradation event can be sent by the server side responding to the request of the target service.

In some optional implementation manners of some embodiments, the execution subject may send the service degradation event information to an alarm terminal device. The warning terminal device may be a terminal device that needs to acquire a result of degrading the target service. For example, the alarm terminal device may be a terminal device of a business side administrator. In practice, the execution main body may send the service degradation event information to the alarm terminal device in a preset touch manner. The preset touch modes may include, but are not limited to: a short message sending mode, a mail sending mode, a telephone notification mode and an applet notification mode. Therefore, the service degradation event information can be sent to the alarm terminal equipment, so that a user of the alarm terminal equipment can obtain the degradation result of the target service.

In some optional implementation manners of some embodiments, the execution subject may send the service degradation event information to an associated data storage end, so as to visually display each service degradation event information stored in the data storage end. The data storage terminal may be a server storing data that can be used for data visualization. The execution subject for visually displaying the service degradation event information stored in the data storage terminal may be the execution subject or a visual terminal device. The visualization terminal device may be a background terminal device for performing visualization. Therefore, the service degradation event information can be sent to the associated data storage end for visual display.

The above embodiments of the present disclosure have the following advantages: by the service degradation method of some embodiments of the present disclosure, a user-defined degradation strategy is supported from a service perspective, so that the method can adapt to complex and variable service scenarios. In particular, the reasons for poor applicability in complex business scenarios are: the method for judging whether degradation is caused based on one-time request and response can judge whether degradation is caused when an interface is called, so that degradation is caused in an actual service scene, and the interface cannot be called when a front node of the interface is blocked, so that the state of a subsequent fuse cannot be maintained, and the applicability in a complex service scene is poor. Based on this, the service degradation method according to some embodiments of the present disclosure first receives each interface call data corresponding to the target service. Therefore, the received interface calling data can represent the data of the interface calling the target service for multiple times, so as to judge whether the target service is degraded or not. Then, the service configuration information corresponding to the target service is determined. The service configuration information includes degradation configuration information, and the degradation configuration information includes degradation threshold information and degradation interface information. Thus, the determined service configuration information may represent relevant information configured for the target service, and the degradation configuration information included in the service configuration information may represent degradation logic relevant information configured for the target service. And then, determining whether to carry out degradation processing on the target service according to the degradation threshold information included in the interface calling data and the service configuration information. Therefore, whether the target service is degraded or not can be determined through calling data of each interface of the target service for multiple times and the user-defined degradation threshold information of the target service. And finally, in response to the determination of performing degradation processing on the target service, performing service degradation processing on the request of the target service according to the degradation interface information included in the service configuration information. Therefore, when the target service is determined to be degraded, the target service can be degraded through the user-defined configured degradation interface information of the target service. And because the received interface calling data are the data for calling the interface of the target service for multiple times, a mode of judging whether to degrade based on one request and response is avoided. And because the degradation configuration information in the determined service configuration information is configured in advance by self, the degradation configuration information can be adjusted according to the change of the service scene. Therefore, the user-defined degradation strategy is supported from the service perspective, and the method can adapt to complex and changeable service scenes.

With further reference to FIG. 4, a flow 400 of further embodiments of a traffic downgrading method is illustrated. The process 400 of the service degradation method includes the following steps:

step 401, receiving each interface call data corresponding to the target service.

Step 402, determining service configuration information corresponding to the target service.

Step 403, determining whether to perform degradation processing on the target service according to the degradation threshold information included in each interface call data and the service configuration information.

Step 404, in response to determining to downgrade the target service:

step 4041, according to the degradation interface information included in the service configuration information, performs service degradation processing on the request of the target service.

In some embodiments, the specific implementation and technical effects of steps 401 to 4041 may refer to steps 301 to 304 in those embodiments corresponding to fig. 3, and are not described herein again.

Step 4042, determines whether the retry configuration information characterizes a retry target service.

In some embodiments, an executing entity of the traffic downgrading method (e.g., the server 105 shown in fig. 1 or the monitoring server shown in fig. 2) may determine whether the retry configuration information characterizes a retry of the target traffic. The service configuration information may further include retry configuration information. The retry configuration information may be information configured for retry logic after traffic degradation. The retry configuration information may characterize whether the interface of the traffic is retriable. The retry configuration information may include a retry identification. The retry identification may be an identification that characterizes whether an interface of the traffic is retriable. For example, the retry configuration information may be "Y" and the interface characterizing the traffic may retry. The retry configuration information may be "N" and the interface characterizing the traffic may not retry. The retry configuration information may also include an interface identification. In practice, the executing body may determine that the retry configuration information represents retrying the target service in response to determining that the retry identifier is an identifier that characterizes an interface retry of the service. Here, the interface retry may be to recall the interface for each request parameter of the request using the target service.

Step 4043, responsive to determining that the retry configuration information characterizes a retry target service, adds the request to a failed request queue.

In some embodiments, the execution agent may add the request to a failed request queue in response to determining that the retry configuration information characterizes a retry of the target service. The failed request queue may be a message queue for storing each failed request. In practice, the execution agent may add the request to the end of the failed request queue.

Step 4044, retry processing is performed on the interface corresponding to the request according to the failure request queue and the preset time interval, so as to obtain an interface retry result set.

In some embodiments, the execution main body may perform retry processing on the interface corresponding to the request according to the failure request queue and a preset time interval, so as to obtain an interface retry result set. The preset time interval may be a preset period duration for performing retry processing on the interface. For example, the preset time interval may be 1 minute. In practice, the execution body may perform retry processing on the interface corresponding to each request in the failed request queue every the preset time interval, so as to generate a retry result set of each interface corresponding to each request. Thereby, an interface retry result set of the interface corresponding to the request of the target service can be obtained. Specifically, when the retry process is successful, the identifier indicating that the retry of the interface is successful may be determined as the retry result of the interface. When the retry process fails, the identifier indicating the retry failure of the interface may be determined as the retry result of the interface. Therefore, the interface retry result in the interface retry result set can represent whether the interface retries successfully. Here, the retry process may be to call the interface again using each request parameter of the request.

As can be seen from fig. 4, compared with the description of some embodiments corresponding to fig. 3, the flow 400 of the traffic downgrading method in some embodiments corresponding to fig. 4 embodies a step of expanding the retry process after downgrading. Therefore, the solutions described in the embodiments can retry the interface of the target service regularly when the target service needs to retry after being degraded. Therefore, the method supports the user-defined retry strategy from the service perspective, and can adapt to complicated and changeable service scenes.

With further reference to FIG. 5, a flow 500 of still further embodiments of a traffic destaging method is illustrated. The process 500 of the service degradation method includes the following steps:

step 501, receiving each interface call data corresponding to the target service.

Step 502, determining service configuration information corresponding to the target service.

Step 503, determining whether to perform degradation processing on the target service according to the degradation threshold information included in each interface call data and the service configuration information.

Step 504, in response to determining to downgrade the target service:

step 5041, performing service degradation processing on the request of the target service according to the degradation interface information included in the service configuration information.

At step 5042, it is determined whether the retry configuration information characterizes a retry of the target service.

At step 5043, the request is added to the failed request queue in response to determining that the retry configuration information characterizes a retry target service.

And 5044, retrying the interface corresponding to the request according to the failure request queue and the preset time interval to obtain an interface retrying result set.

In some embodiments, specific implementation and technical effects of steps 501 to 5045 may refer to steps 401 to 4044 in those embodiments corresponding to fig. 4, and are not described herein again.

Step 5045, determining whether to perform recovery processing on the target service according to the interface retry result set and the recovery threshold information.

In some embodiments, an executing entity (e.g., the server 105 shown in fig. 1 or the monitoring server shown in fig. 2) of the service degradation method may determine whether to perform the recovery processing on the target service according to the interface retry result set and the recovery threshold information. The service configuration information may further include recovery configuration information. The recovery configuration information may be information configured for recovery processing after service degradation. The restoration configuration information includes restoration threshold information and restoration interface information. The restoration threshold information may be threshold related information used to determine whether to perform a restoration process on the degraded traffic. The recovery threshold information may include an interface retry success number threshold. The threshold of the number of successful retry of the interface may be a threshold defining a minimum number of successful retry of the interface of the target service. The recovered interface information may be recovered interface-related information. The restoration interface information may include a restoration interface identification. The recovered interface identifier may be an identifier of an interface after the target service is recovered. In practice, the execution body may determine, as the number of successful interface retries, the number of each interface retries characterizing successful interface retries in the interface retries result set. Then, in response to determining that the number of successful interface retries is greater than or equal to the threshold number of successful interface retries, determining to perform recovery processing on the target traffic.

Optionally, the recovery threshold information may include a recovery ratio threshold. The recovery ratio threshold may be a threshold defining a minimum ratio of successful retries.

In some optional implementations of some embodiments, the executing entity may determine whether to perform the recovery processing on the target service by:

in the first step, the number of interface retry results included in the interface retry result set and characterizing the success of interface retry is determined as the number of retry success.

And a second step of determining to perform recovery processing on the target service in response to determining that a ratio of the retry success number to the number of each interface retry result included in the interface retry result set is greater than or equal to the recovery ratio threshold. Therefore, whether the target service needs to be recovered or not can be determined from the dimension of the successful retry ratio by customizing the configured recovery ratio threshold in advance.

Optionally, the recovery threshold information may include a recovery ratio threshold and a recovery number threshold.

In some optional implementation manners of some embodiments, the executing entity may determine whether to perform recovery processing on the target service by:

And a second step of determining to perform recovery processing on the target service in response to determining that the retry success number is greater than or equal to the recovery number threshold and that a ratio of the retry success number to the number of the interface retry results included in the interface retry result set is greater than or equal to the recovery ratio threshold. Therefore, whether the target service needs to be recovered or not can be determined by customizing the configured recovery proportion threshold value and the recovery quantity threshold value in advance and simultaneously according to the dimensions of the successful calling proportion threshold value and the successful quantity threshold value.

And 5046, in response to the determination of performing the service restoration processing on the target service, performing service restoration processing on the target service according to the restoration interface information.

In some embodiments, the executing entity may perform, in response to determining to perform the service restoration processing on the target service, the service restoration processing on the target service according to the restoration interface information. In practice, the execution main body may determine an interface corresponding to the recovery interface identifier included in the recovery interface information as an interface of the target service, so as to perform service recovery processing on the target service.

Step 5047, in response to determining that the retry configuration information indicates that the target service is not retried, performing service restoration processing on the target service according to the restoration interface information.

In some embodiments, the executing body may perform, in response to determining that the retry configuration information indicates that the target service is not retried, service recovery processing on the target service according to the recovery interface information. Here, for a specific implementation of the service recovery processing performed on the target service, refer to step 5046.

It should be noted that step 5044 and step 5045 may be performed in parallel.

As can be seen from fig. 5, compared with the description of some embodiments corresponding to fig. 4, the flow 500 of the service downgrading method in some embodiments corresponding to fig. 5 embodies a step of extending the downgraded recovery process. Thus, the solutions described in the embodiments can recover the target service when the recovery condition is reached after the target service is degraded. Therefore, the method and the device realize the support of the user-defined recovery strategy from the service perspective, thereby being suitable for complicated and changeable service scenes.

With further reference to fig. 6, as an implementation of the methods shown in the above figures, the present disclosure provides some embodiments of a traffic downgrading apparatus, which correspond to those shown in fig. 3, and which can be applied in various electronic devices.

As shown in fig. 6, the traffic downgrading apparatus 600 of some embodiments includes: a receiving unit 601, a first determining unit 602, a second determining unit 603 and a downgrading unit 604. Wherein, the receiving unit 601 is configured to receive each interface call data of the corresponding target service; the first determining unit 602 is configured to determine service configuration information corresponding to the target service, where the service configuration information includes degradation configuration information, and the degradation configuration information includes degradation threshold information and degradation interface information; the second determining unit 603 is configured to determine whether to perform degradation processing on the target service according to the degradation threshold information included in the interface call data and the service configuration information; the downgrading unit 604 is configured to, in response to determining to downgrade the target service, perform service downgrading on the request of the target service according to downgrading interface information included in the service configuration information.

Optionally, the second determining unit 603 may be further configured to: determining the number of failed calls according to the call data of each interface and preset failed call conditions; and determining to perform degradation processing on the target service in response to determining that the ratio of the number of the failed calls to the number of the call data of each interface is greater than or equal to the degradation ratio threshold.

Optionally, the degradation threshold information includes a degradation amount threshold and a degradation proportion threshold.

Optionally, the second determining unit 603 may be further configured to: determining the number of failed calls according to the call data of each interface and preset failed call conditions; and determining to perform degradation processing on the target service in response to the fact that the number of the failed calls is larger than or equal to the threshold of the degradation number and the ratio of the number of the failed calls to the number of the call data of each interface is larger than or equal to the threshold of the degradation proportion.

Optionally, the receiving unit 601 may be further configured to: and receiving each interface calling data corresponding to the target service in a preset period time.

Optionally, the traffic degradation apparatus 600 may further include: a retry determination unit, an addition unit, and a retry unit (not shown in the figure). Wherein the retry determining unit is configured to determine whether the retry configuration information represents retrying the target service. The adding unit is configured to add the request to a failed request queue in response to determining that the retry configuration information characterizes retrying the target traffic. The retry unit is configured to perform retry processing on an interface corresponding to the request according to the failure request queue and a preset time interval to obtain an interface retry result set, where an interface retry result in the interface retry result set indicates whether the interface retries successfully.

Optionally, the traffic degradation apparatus 600 may further include: a restoration determining unit and a first restoring unit (not shown in the figure). Wherein the recovery determining unit is configured to determine whether to perform recovery processing on the target service according to the interface retry result set and the recovery threshold information. The first recovery unit is configured to perform service recovery processing on the target service according to the recovery interface information in response to determining to perform recovery processing on the target service.

Optionally, the traffic downgrading apparatus 600 may further include: and a second recovery unit (not shown in the figure) configured to, in response to determining that the retry configuration information indicates that the target service is not retried, perform service recovery processing on the target service according to the recovery interface information.

Optionally, the recovery determination unit may be further configured to: determining the number of interface retry results which are included in the interface retry result set and are used for representing the successful interface retry as the number of retry success; and determining to perform recovery processing on the target service in response to determining that the ratio of the retry success quantity to the quantity of each interface retry result included in the interface retry result set is greater than or equal to the recovery ratio threshold.

Optionally, the recovery determination unit may be further configured to: determining the number of interface retry results which characterize the interface retry success and are included in the interface retry result set as the retry success number; and in response to determining that the retry success quantity is greater than or equal to the recovery quantity threshold, and the ratio of the retry success quantity to the quantity of each interface retry result included in the interface retry result set is greater than or equal to the recovery ratio threshold, determining to perform recovery processing on the target service.

Alternatively, the second determining unit 603 may include: a first data determination unit, a second data determination unit, and a number of failed calls determination unit (not shown in the figure). The first data determining unit is configured to determine each interface calling data meeting the preset failed calling condition in the interface calling data as interface calling failure data, and obtain an interface calling failure data set. And the second data determining unit is configured to determine, as a target interface call failure data set, each interface call failure data meeting a preset extension service identification condition in the interface call failure data set, where the preset extension service identification condition is that an extension service identification corresponding to the interface call failure data is the same as an extension service identification included in the degradation configuration information. The number-of-failed-calls determining unit is configured to determine the number of pieces of target interface call failure data included in the target interface call failure data set as the number of failed calls.

Optionally, the traffic degradation apparatus 600 may further include: and an issuing unit (not shown in the figure) configured to issue the service degradation event information corresponding to the target service.

Optionally, the publication unit may be further configured to: and sending the service degradation event information to alarm terminal equipment.

Optionally, the publication unit may be further configured to: and sending the service degradation event information to a related data storage end so as to visually display the service degradation event information stored in the data storage end.

It will be understood that the elements described in the apparatus 600 correspond to various steps in the method described with reference to fig. 3. Thus, the operations, features and resulting advantages described above with respect to the method are also applicable to the apparatus 600 and the units included therein, and are not described herein again.

Referring now to fig. 7, a block diagram of an electronic device (e.g., the server 105 of fig. 1 or the monitoring server of fig. 2) 700 suitable for use in implementing some embodiments of the present disclosure is shown. The electronic device shown in fig. 7 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present disclosure.

As shown in fig. 7, electronic device 700 may include a processing means (e.g., central processing unit, graphics processor, etc.) 701 that may perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM) 702 or a program loaded from storage 708 into a Random Access Memory (RAM) 703. In the RAM703, various programs and data necessary for the operation of the electronic apparatus 700 are also stored. The processing device 701, the ROM 702, and the RAM703 are connected to each other by a bus 704. An input/output (I/O) interface 705 is also connected to bus 704.

Generally, the following devices may be connected to the I/O interface 705: input devices 706 including, for example, a touch screen, touch pad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, or the like; an output device 707 including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; storage 708 including, for example, magnetic tape, hard disk, etc.; and a communication device 709. The communication means 709 may allow the electronic device 700 to communicate wirelessly or by wire with other devices to exchange data. While fig. 7 illustrates an electronic device 700 having various means, it is to be understood that not all illustrated means are required to be implemented or provided. More or fewer devices may alternatively be implemented or provided. Each block shown in fig. 7 may represent one device or may represent multiple devices as desired.

In particular, according to some embodiments of the present disclosure, the processes described above with reference to the flow diagrams may be implemented as computer software programs. For example, some embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In some such embodiments, the computer program may be downloaded and installed from a network via communications means 709, or may be installed from storage 708, or may be installed from ROM 702. The computer program, when executed by the processing device 701, performs the above-described functions defined in the methods of some embodiments of the present disclosure.

It should be noted that the computer readable medium described in some embodiments of the present disclosure may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In some embodiments of the disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In some embodiments of the present disclosure, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, optical cables, RF (radio frequency), etc., or any suitable combination of the foregoing.

In some embodiments, the clients, servers may communicate using any currently known or future developed network Protocol, such as HTTP (HyperText Transfer Protocol), and may interconnect with any form or medium of digital data communication (e.g., a communications network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), the Internet (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future developed network.

The computer readable medium may be embodied in the electronic device; or may exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: receiving each interface calling data corresponding to the target service; determining service configuration information corresponding to the target service, wherein the service configuration information comprises degradation configuration information, and the degradation configuration information comprises degradation threshold information and degradation interface information; determining whether to perform degradation processing on the target service according to the degradation threshold information included in the interface calling data and the service configuration information; and in response to the determination of performing degradation processing on the target service, performing service degradation processing on the request of the target service according to the degradation interface information included in the service configuration information.

Computer program code for carrying out operations for embodiments of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, smalltalk, C + +, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units described in some embodiments of the present disclosure may be implemented by software, and may also be implemented by hardware. The described units may also be provided in a processor, which may be described as: a processor includes a receiving unit, a first determining unit, a second determining unit, and a degrading unit. The names of these units do not in some cases form a limitation on the unit itself, and for example, a receiving unit may also be described as a "unit that receives the respective interface call data of the corresponding target service".

The functions described herein above may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), systems on a chip (SOCs), complex Programmable Logic Devices (CPLDs), and the like.

Some embodiments of the present disclosure also provide a computer program product comprising a computer program that, when executed by a processor, implements any of the traffic degradation methods described above.

The foregoing description is only exemplary of the preferred embodiments of the disclosure and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the invention in the embodiments of the present disclosure is not limited to the specific combination of the above-mentioned features, but also encompasses other embodiments in which any combination of the above-mentioned features or their equivalents is made without departing from the inventive concept as defined above. For example, the above features and (but not limited to) the features with similar functions disclosed in the embodiments of the present disclosure are mutually replaced to form the technical solution.

Claims

1. A traffic degradation method comprises the following steps:

receiving each interface calling data corresponding to the target service;

determining service configuration information corresponding to the target service, wherein the service configuration information comprises degradation configuration information, and the degradation configuration information comprises degradation threshold information and degradation interface information;

determining whether to perform degradation processing on the target service according to the degradation threshold information included in the interface calling data and the service configuration information;

and responding to the determination of the degradation processing of the target service, and performing service degradation processing on the request of the target service according to the degradation interface information included in the service configuration information.

2. The method of claim 1, wherein the degradation threshold information comprises a degradation proportion threshold; and

the determining whether to perform degradation processing on the target service includes:

determining the number of failed calls according to the call data of each interface and preset failed call conditions;

and determining to perform degradation processing on the target service in response to determining that the ratio of the number of failed calls to the number of the interface call data is greater than or equal to the degradation ratio threshold.

3. The method of claim 1, wherein the degradation threshold information comprises a number of degradations threshold and a proportion of degradations threshold; and

and in response to the fact that the number of the failed calls is larger than or equal to the threshold of the degradation number and the ratio of the number of the failed calls to the number of the data of each interface call is larger than or equal to the threshold of the degradation proportion, determining to perform degradation processing on the target service.

4. The method of claim 1, wherein the receiving of the respective interface call data of the corresponding target service comprises:

and receiving each interface calling data corresponding to the target service in a preset period time.

5. The method of claim 1, wherein the traffic configuration information further comprises retry configuration information; and

after the service degradation processing is performed on the request for the target service, the method further includes:

determining whether the retry configuration information characterizes retrying the target service;

responsive to determining that the retry configuration information characterizes retrying the target traffic, adding the request to a failed request queue;

and retrying the interface corresponding to the request according to the failure request queue and a preset time interval to obtain an interface retrying result set, wherein the interface retrying result in the interface retrying result set represents whether the interface is retryed successfully or not.

6. The method of claim 5, wherein the traffic configuration information further comprises restoration configuration information, the restoration configuration information comprising restoration threshold information and restoration interface information; and

the method further comprises the following steps:

determining whether to recover the target service according to the interface retry result set and the recovery threshold information;

and responding to the determination of the recovery processing of the target service, and performing service recovery processing on the target service according to the recovery interface information.

7. The method of claim 5, wherein the traffic configuration information further comprises restoration configuration information, the restoration configuration information comprising restoration threshold information and restoration interface information; and

the method further comprises the following steps:

and in response to the fact that the retry configuration information represents that the target service is not retried, performing service recovery processing on the target service according to the recovery interface information.

8. The method of claim 6, wherein the restoration threshold information comprises a restoration ratio threshold; and

the determining whether to perform recovery processing on the target service according to the interface retry result set and the recovery threshold information includes:

determining the number of interface retry results which are included in the interface retry result set and are used for representing the successful retry of the interface as the number of successful retry;

and determining to perform recovery processing on the target service in response to determining that the ratio of the retry success number to the number of each interface retry result included in the interface retry result set is greater than or equal to the recovery ratio threshold.

9. The method of claim 6, wherein the recovery threshold information comprises a recovery ratio threshold and a recovery number threshold; and

and in response to that the retry success quantity is determined to be greater than or equal to the recovery quantity threshold value, and the ratio of the retry success quantity to the quantity of each interface retry result included in the interface retry result set is greater than or equal to the recovery ratio threshold value, determining to perform recovery processing on the target service.

10. The method according to one of claims 2 to 3, wherein the downgrade configuration information further includes an extended service identifier, and the interface call data in each interface call data corresponds to the extended service identifier; and

determining the number of failed calls according to the call data of each interface and preset failed call conditions, wherein the determining comprises the following steps:

determining each interface calling data meeting the preset failure calling condition in each interface calling data as interface calling failure data to obtain an interface calling failure data set;

determining each interface calling failure data meeting a preset expansion service identification condition in the interface calling failure data set as a target interface calling failure data set, wherein the preset expansion service identification condition is that an expansion service identification corresponding to the interface calling failure data is the same as an expansion service identification included in the degradation configuration information;

and determining the quantity of each target interface call failure data included in the target interface call failure data set as the quantity of failed calls.

11. The method according to one of claims 1-9, wherein the method further comprises:

and issuing the service degradation event information corresponding to the target service.

12. The method according to claim 11, wherein the publishing the service degradation event information corresponding to the target service includes:

and sending the service degradation event information to alarm terminal equipment.

13. The method according to claim 11, wherein the issuing the service degradation event information corresponding to the target service includes:

and sending the service degradation event information to a related data storage end for visually displaying each service degradation event information stored by the data storage end.

14. A traffic downgrading apparatus, comprising:

a receiving unit configured to receive each interface call data corresponding to the target service;

a first determining unit configured to determine service configuration information corresponding to the target service, wherein the service configuration information includes degradation configuration information, and the degradation configuration information includes degradation threshold information and degradation interface information;

a second determining unit, configured to determine whether to perform degradation processing on the target service according to the degradation threshold information included in the interface call data and the service configuration information;

and the degradation unit is configured to respond to the determination of performing degradation processing on the target service, and perform service degradation processing on the request of the target service according to the degradation interface information included in the service configuration information.

15. An electronic device, comprising:

one or more processors;

a storage device having one or more programs stored thereon,

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method recited in any of claims 1-13.

16. A computer-readable medium, on which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1-13.

17. A computer program product comprising a computer program which, when executed by a processor, implements the method according to any one of claims 1-13.