Service failure identification method, device, equipment and storage medium

Abstract

The present invention discloses a method, device, equipment and storage medium for identifying service failures. The method sets a plurality of fault identification conditions into fault verification rules for corresponding services in advance, and then determines the corresponding fault verification rules according to the target service that is specifically called. Then, the relevant indicator data to be verified corresponding to the target service is obtained according to the corresponding fault verification rules, and the relevant indicator data is verified accordingly to determine whether the target service fails. If the target service fails, the target service is deleted from the preset service request access list to suspend the target service. The present invention can realize the detection of service failures without accessing a third-party component Nginx, which is not only easy to expand, but also increases the fault identification conditions, so that the fault identification is more refined according to the business scenario, and the accuracy of fault identification is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of financial technology (Fintech), and in particular to a method, device, equipment and computer-readable storage medium for identifying service failures. Background Art

[0002] With the development of computer technology, more and more technologies are applied in the financial field. The traditional financial industry is gradually transforming into Fintech. Internet technology is no exception. However, due to the security and real-time requirements of the financial industry, higher requirements are also placed on Internet technology. Generally, the server Nginx is used to realize the identification of service failures. For example, through the relevant configuration in Nginx, multi-active access to IP addresses of different IDC (Internet Data Center) computer rooms can be realized, or when Nginx detects that the number of service request failures reaches max_fails (maximum number of failures), it returns a specified error code, or when the waiting time after the failure exceeds fail_timeout (failure waiting time), it is determined that the service has failed and recovered. However, the above service fault identification method requires access to third-party components, which is not only inconvenient for expansion, but also has a single service fault identification method and cannot meet the needs of replication business scenarios. Summary of the invention

[0003] The main purpose of the present invention is to propose a service fault identification method, device, equipment and computer-readable storage medium, aiming to solve the technical problems that the existing service fault identification method is not easy to expand and the fault identification method is single.

[0004] To achieve the above object, the present invention provides a method for identifying a service failure, the method comprising the following steps:

[0005] Upon receiving a service report result instruction triggered based on a service call request, obtaining a fault verification rule corresponding to a target service in the service report result instruction;

[0006] According to the fault verification rule, obtain the relevant indicator data to be verified corresponding to the target service, compare the relevant indicator data with the verification standard in the fault verification rule, and determine whether the target service has a service failure according to the comparison result;

[0007] If a service failure occurs in the target service, the target service is marked as a failure according to a preset failure rule strategy.

[0008] Optionally, if a service failure occurs in the target service, marking the target service as a failure according to a preset failure rule policy, and deleting the target service from the service access list, further comprises:

[0009] Deleting the target service from the preset service request access list, adding the target service carrying the fault mark to the preset fault list, and calling a general verification module or a custom verification module to perform service detection on the fault service in the fault list according to a preset detection cycle;

[0010] According to the service detection result, determine whether there is an available service to be restored in the fault list;

[0011] If the restored available service exists in the fault list, the fault mark corresponding to the available service is cleared, and the available service after the fault mark is cleared is added to the service request access list.

[0012] Optionally, the step of deleting the target service from the preset service request access list, adding the target service carrying the fault mark to the preset fault list, and calling a general verification module or a custom verification module to perform service detection on the fault service in the fault list according to a preset detection cycle specifically includes:

[0013] Add the target service carrying the fault mark to the fault list, and determine whether the custom verification module exists in the verification library;

[0014] If the custom verification module exists, calling the custom verification module to perform service detection on the faulty services in the fault list according to the detection cycle;

[0015] If the custom verification module does not exist, the general verification module is called according to the detection cycle to perform service detection on the faulty services in the fault list.

[0016] Optionally, the relevant indicator data is a service request time and a number of request failures, and the steps of obtaining the relevant indicator data to be verified corresponding to the target service according to the fault verification rule, comparing the relevant indicator data with a verification standard in the fault verification rule, and judging whether a service failure occurs in the target service according to the comparison result specifically include:

[0017] If the fault verification rule is whether the number of request failures of the target service reaches a first preset threshold within a preset time interval, then obtaining the service request time and the number of request failures corresponding to the target service to be verified;

[0018] According to the service request time and the number of request failures, it is determined whether the number of request failures of the target service reaches the first preset threshold within a preset time interval, so as to determine whether a service failure occurs in the target service.

[0019] Optionally, the relevant indicator data is the number of consecutive request failures, and the steps of obtaining the relevant indicator data to be verified corresponding to the target service according to the fault verification rule, comparing the relevant indicator data with the verification standard in the fault verification rule, and judging whether a service failure occurs in the target service according to the comparison result specifically include:

[0020] If the fault checking rule is whether the number of consecutive request failures for the target service reaches a second preset threshold, the number of consecutive request failures for the target service is counted, and when it is detected that the target service request is successful, the number of consecutive request failures is reset to zero;

[0021] According to the number of consecutive request failures, it is determined whether the number of consecutive request failures of the target service reaches the second preset threshold, so as to determine whether a service failure occurs in the target service.

[0022] Optionally, the relevant indicator data is the number of accesses and the number of successes, and the steps of obtaining the relevant indicator data to be verified corresponding to the target service according to the fault verification rule, comparing the relevant indicator data with the verification standard in the fault verification rule, and judging whether a service failure occurs in the target service according to the comparison result specifically include:

[0023] If the fault checking rule is whether the access success rate of the target service in the preset time interval is less than a third preset threshold, then obtaining the number of accesses and the number of successes of the target service in each preset time interval;

[0024] The access success rate of the target service in each preset time interval is calculated according to the number of accesses and the number of successes, and it is determined whether there is an access success rate less than the third preset threshold value to determine whether a service failure occurs in the target service.

[0025] Optionally, the relevant indicator data is an average access time consumption, and the steps of obtaining the relevant indicator data to be verified corresponding to the target service according to the fault verification rule, comparing the relevant indicator data with the verification standard in the fault verification rule, and judging whether a service failure occurs in the target service according to the comparison result specifically include:

[0026] If the fault checking rule is whether the average access time of the target service in the preset time interval is greater than a fourth preset threshold, then obtaining the average access time of the target service in each preset time interval;

[0027] It is determined whether there is an average access time that reaches the fourth preset threshold, so as to determine whether a service failure occurs in the target service.

[0028] Optionally, before the step of obtaining a fault verification rule corresponding to a target service in the service reporting result instruction when receiving the service reporting result instruction triggered by the service calling request, the step further includes:

[0029] When receiving the service call request, determining the target service in the service request access list according to the preset weights corresponding to the various services;

[0030] The service call request is processed based on the target service, and a corresponding service report result instruction is generated.

[0031] Optionally, when the service call request is received, the step of determining the target service in the service request access list according to preset weights corresponding to various services specifically includes:

[0032] Group each service and the corresponding service IP, and obtain the valid IDC in each group according to the group identifier, wherein the IDC includes the service IP and the preset access weight;

[0033] If the access weights of the services in the group are equal, the target service is randomly determined from the valid IDCs in the group;

[0034] If the access weights of the services in the group are not equal, the total access weight of the group is calculated, and an access array is defined according to the number of valid IDCs, wherein the access array is used to store the access weights of the valid IDCs in the group;

[0035] Based on an integer value less than the total access weight, the access array is traversed, and based on the integer value generated by the traversal and the weight of the current traversal, the target service is determined in the effective IDC within the group.

[0036] In addition, to achieve the above object, the present invention further provides a device for identifying a service failure, the device for identifying a service failure comprising:

[0037] A verification rule acquisition module, configured to, upon receiving a service report result instruction triggered based on a service call request, obtain a fault verification rule corresponding to a target service in the service report result instruction;

[0038] A service fault judgment module is used to obtain the relevant indicator data to be verified corresponding to the target service according to the fault verification rule, compare the relevant indicator data with the verification standard in the fault verification rule, and judge whether the target service has a service fault according to the comparison result;

[0039] The fault service marking module is used to mark the target service as faulty according to a preset fault rule strategy if a service fault occurs in the target service.

[0040] Optionally, the service failure identification device further includes:

[0041] A fault service detection module, used to delete the target service from the preset service request access list, add the target service carrying the fault mark to the preset fault list, and call the general verification module or the custom verification module to perform service detection on the fault service in the fault list according to the preset detection cycle;

[0042] An available service determination module is used to determine whether there is an available service that can be restored in the fault list according to the service detection result;

[0043] The fault service recovery module is used to clear the fault mark corresponding to the available service if the recovered available service exists in the fault list, and add the available service after the fault mark is cleared to the service request access list.

[0044] Optionally, the relevant indicator data is the service request time and the number of request failures, and the service fault judgment module is further used to:

[0045] If the fault verification rule is whether the number of request failures of the target service reaches a first preset threshold within a preset time interval, then obtaining the service request time and the number of request failures corresponding to the target service to be verified;

[0046] According to the service request time and the number of request failures, it is determined whether the number of request failures of the target service reaches the first preset threshold within a preset time interval, so as to determine whether a service failure occurs in the target service.

[0047] Optionally, the relevant indicator data is the number of consecutive request failures, and the service fault judgment module is further used to:

[0048] If the fault checking rule is whether the number of consecutive request failures for the target service reaches a second preset threshold, the number of consecutive request failures for the target service is counted, and when it is detected that the target service request is successful, the number of consecutive request failures is reset to zero;

[0049] According to the number of consecutive request failures, it is determined whether the number of consecutive request failures of the target service reaches the second preset threshold, so as to determine whether a service failure occurs in the target service.

[0050] Optionally, the relevant indicator data is the number of accesses and the number of successes, and the service fault judgment module is further used to:

[0051] If the fault checking rule is whether the access success rate of the target service in the preset time interval is less than a third preset threshold, then obtaining the number of accesses and the number of successes of the target service in each preset time interval;

[0052] The access success rate of the target service in each preset time interval is calculated according to the number of accesses and the number of successes, and it is determined whether there is an access success rate less than the third preset threshold value to determine whether a service failure occurs in the target service.

[0053] Optionally, the relevant indicator data is an average access time consumption, and the service fault judgment module is further used to:

[0054] If the fault checking rule is whether the average access time of the target service in the preset time interval is greater than a fourth preset threshold, then obtaining the average access time of the target service in each preset time interval;

[0055] It is determined whether there is an average access time that reaches the fourth preset threshold, so as to determine whether a service failure occurs in the target service.

[0056] In addition, to achieve the above-mentioned purpose, the present invention also provides a service failure identification device, which includes: a memory, a processor, and a service failure identification program stored in the memory and executable on the processor, and the service failure identification program, when executed by the processor, implements the steps of the service failure identification method described above.

[0057] In addition, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which a service fault identification program is stored, and when the service fault identification program is executed by a processor, the steps of the service fault identification method as described above are implemented.

[0058] The present invention provides a method for identifying service faults, by presetting a plurality of fault identification conditions into fault verification rules for corresponding services, and then determining the corresponding fault verification rules according to the specifically called target service. Then, the relevant indicator data corresponding to the target service to be verified is obtained according to the corresponding fault verification rules, and the relevant indicator data is verified accordingly to determine whether the target service has a fault. If the target service has a fault, the target service is deleted from the preset service request access list to suspend the target service. The present invention can realize the detection of service faults without accessing a third-party component Nginx, which is not only easy to expand, but also increases the fault identification conditions, so that the fault identification is more refined according to the business scenario, and the accuracy of fault identification is improved, which solves the technical problems that the existing service fault identification method is not easy to expand and the fault identification method is single. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 It is a schematic diagram of the device structure of the hardware operating environment involved in the embodiment of the present invention;

[0060] Figure 2 This is a flow chart of a first embodiment of a method for identifying a service failure according to the present invention.

[0061] The realization of the purpose, functional features and advantages of the present invention will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0062] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

[0063] like Figure 1 As shown, Figure 1 It is a schematic diagram of the device structure of the hardware operating environment involved in the embodiment of the present invention.

[0064] The service failure identification device in the embodiment of the present invention may be a PC or a server device, on which a Java virtual machine runs.

[0065] like Figure 1 As shown, the service fault identification device may include: a processor 1001, such as a CPU, a network interface 1004, a user interface 1003, a memory 1005, and a communication bus 1002. Among them, the communication bus 1002 is used to realize the connection and communication between these components. The user interface 1003 may include a display screen (Display), an input unit such as a keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory, or a stable memory (non-volatile memory), such as a disk memory. The memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0066] Those skilled in the art will understand that Figure 1 The device structure shown in the figure does not constitute a limitation of the device, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.

[0067] like Figure 1 As shown, the memory 1005 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a service failure identification program.

[0068] exist Figure 1In the device shown, the network interface 1004 is mainly used to connect to the background server and communicate data with the background server; the user interface 1003 is mainly used to connect to the client (user end) and communicate data with the client; and the processor 1001 can be used to call the service fault identification program stored in the memory 1005 and perform the operations in the following service fault identification method.

[0069] Based on the above hardware structure, an embodiment of a method for identifying a service failure of the present invention is proposed.

[0070] Reference Figure 2 , Figure 2 This is a flow chart of a first embodiment of a method for identifying a service failure of the present invention. The method for identifying a service failure includes:

[0071] Step S10, when receiving a service reporting result instruction triggered by a service call request, obtaining a fault verification rule corresponding to a target service in the service reporting result instruction;

[0072] Generally, the server Nginx is used to implement multi-active requests, where multi-active requests are: when connecting with external organizations, the other party's application may be deployed in multiple IDC computer rooms, and the application needs to perform multi-active access to each IDC computer room according to the health indicators of each IDC computer room. For example, a company's A application needs to access the B application of two IDC computer rooms of an external organization, which correspond to two external network IP addresses IP1 and IP2 respectively. In order to share the system pressure of the external organization, when both IDC computer rooms are healthy, weighted random access is performed; when a computer room fails, only the corresponding service of the healthy IDC computer room is requested. Then, through the relevant configuration in Nginx, multi-active access to IP addresses of different IDC (Internet Data Center) computer rooms can be achieved. For example, when Nginx detects that the number of service request failures reaches max_fails (maximum number of failures), a specified error code is returned, or when the waiting time after the failure exceeds fail_timeout (failure waiting time), it is determined that the service has failed and recovered. It can be seen that when clustered Nginx is deployed in the system, corresponding IDC deployments need to be performed separately when there are multiple IDC computer rooms in the system; when multiple partners are connected, the Nginx configuration of each IDC computer room needs to be adjusted each time, which is not convenient for expansion. In addition, Nginx has a single fault switching method and does not meet the needs of complex business scenarios. For example: Nginx does not support indicators such as the increase in the average application time or the access success rate being lower than the tolerance index for a period of time when the fault judgment method requires it. The Nginx fault recovery judgment method is simple. When max_fails is too large, a large number of failed requests will be generated, causing traffic loss. Therefore, the existing service fault identification method needs to connect to third-party components, which is not only inconvenient for expansion, but also has a single service fault identification method and cannot meet the needs of replication business scenarios.

[0073] In order to solve the above problems, the present invention sets a variety of fault identification conditions as fault verification rules for corresponding services in advance, and then determines the corresponding fault verification rules according to the target service specifically called. Then, according to the corresponding fault verification rules, the relevant indicator data corresponding to the target service to be verified is obtained, and the relevant indicator data is verified accordingly to determine whether the target service has a fault. If the target service has a fault, the target service is deleted from the preset service request access list to suspend the target service. The present invention implements multi-active at the application level, and does not need to access a third-party component in front of the application layer to implement multi-active, that is, there is no need to consider the single point problem of the third-party component. At the same time, the multi-IDC multi-active solution is encapsulated into an SDK, and the business application only needs to obtain the available multi-active IDCIP through a unified interface API, and does not need to pay attention to the fault handling and recovery inside the multi-active SDK, which is low-intrusive to the business system. In addition, fault identification is more refined according to business scenarios: it can support the number of consecutive failures, the number of failures within a certain time interval, the specified minimum sample capacity average time consumption is greater than X milliseconds for how many minutes, or the specified minimum sample capacity success rate is less than Y percent for how many minutes. The above four fault identification methods can be freely combined according to business groups to support more segmented business scenarios. Specifically, when a service reporting result instruction triggered by a service call request is received, the service identifier corresponding to the target service in the service reporting result instruction, such as name, number or type, is obtained, the service identifier is matched with the fault library, and the fault verification rule corresponding to the target service is determined, so as to perform fault detection on the target service through the fault verification rule.

[0074] Furthermore, before step S10, the method further includes:

[0075] When receiving the service call request, determining the target service in the service request access list according to the preset weights corresponding to the various services;

[0076] The service call request is processed based on the target service, and a corresponding service report result instruction is generated.

[0077] Wherein, when the service call request is received, the step of determining the target service in the service request access list according to the preset weights corresponding to the various services specifically includes:

[0078] Group each service and the corresponding service IP, and obtain the valid IDC in each group according to the group identifier, wherein the IDC includes the service IP and the preset access weight;

[0079] If the access weights of the services in the group are equal, the target service is randomly determined from the valid IDCs in the group;

[0080] If the access weights of the services in the group are not equal, the total access weight of the group is calculated, and an access array is defined according to the number of valid IDCs, wherein the access array is used to store the access weights of the valid IDCs in the group;

[0081] Based on an integer value less than the total access weight, the access array is traversed, and based on the integer value generated by the traversal and the weight of the current traversal, the target service is determined in the effective IDC within the group.

[0082] In this embodiment, according to the weights configured by IDCIP, IDCIP is allocated by weight random algorithm for multi-active request. Grouping is performed according to specific services and corresponding IPs, such as loan service IP1 is group 1, loan service IP2 is group 2, repayment service IP1 is group 3, repayment service IP2 is group 4, etc. The specific steps of the multi-active (within group) weight random algorithm are as follows:

[0083] 1. Get the valid IDC in the group according to the group key. Each IDC contains information such as IP and access weight;

[0084] 2. Define an array of the same size for storing the access weights of each IDC according to the number of valid egress IP addresses in the group and assign values ​​to it, calculate the total access weight, and check whether the weight values ​​in the array are all equal;

[0085] 3. The access weights of each IDC are the same, and the multi-active access exit IP is randomly generated directly from the valid IDC list;

[0086] 4. The access weights of each IDC are not all the same. An integer value smaller than the total access weight is randomly generated, and the array storing the weights is traversed. Each time the traversal is performed, the weight of the traversal is subtracted from the generated integer value. When the integer value is less than 0, the subscript of the traversal is the subscript of the valid multi-active list corresponding to the multi-active access exit IP.

[0087] The target service corresponding to the service call request is determined through the above steps, the target service is used to process the request, and a corresponding service reporting result instruction is generated based on the processing result of the target service.

[0088] Step S20, according to the fault verification rule, obtaining relevant indicator data to be verified corresponding to the target service, comparing the relevant indicator data with the verification standard in the fault verification rule, and judging whether a service fault occurs to the target service according to the comparison result;

[0089] In this embodiment, different fault verification rules are set in advance according to different business scenario services, and then the corresponding fault verification rules are determined according to the target service. The indicator data to be verified is determined according to the fault verification rules, and the relevant indicator data corresponding to the target service is obtained. The relevant indicator data is compared with the standard value in the fault verification rules, and then it is determined whether the target service has a service failure based on the comparison result. The service fault verification rules include:

[0090] 1. Determine whether the overall service is faulty based on the number of failed requests within a certain interval;

[0091] 2. Determine whether the overall service is faulty based on the number of consecutive failures;

[0092] 3. The access success rate according to the specified sample capacity is less than X percent for Y minutes (X and Y can be configured according to the business tolerance);

[0093] 4. The average access time based on the specified sample capacity is greater than Z milliseconds and lasts for K minutes (Z and K can be configured according to business tolerance).

[0094] In a specific embodiment, the user may configure the above fault verification rules individually or in combination according to actual service verification needs.

[0095] Step S30: If a service failure occurs in the target service, the target service is marked as a failure according to a preset failure rule strategy.

[0096] In this embodiment, when it is determined that the relevant indicator data of the target service does not reach the standard value in the fault verification rule, that is, due to network jitter or an abnormality in a module of the partner, the service request time is increased, the service request success rate is reduced, or the service request access fails, etc., the target service is marked as an IDC fault according to the preset fault rule strategy, and the target service is temporarily excluded from the service request access list of the multi-active request to suspend the external service of the target service. Among them, the preset fault rule is to mark the target service according to the fault type, or to mark the target service according to the fault time, etc.

[0097] The present invention provides a method for identifying service faults, by obtaining the fault verification rules corresponding to the target service in the service reporting result instruction when receiving a service reporting result instruction triggered by a service call request; according to the fault verification rules, obtaining the relevant indicator data to be verified corresponding to the target service, comparing the relevant indicator data with the verification standard in the fault verification rules, and judging whether the target service has a service fault according to the comparison results; if the target service has a service fault, marking the target service as a fault according to a preset fault rule strategy. In the above manner, the present invention sets a variety of fault identification conditions into fault verification rules for corresponding services in advance, and then determines the corresponding fault verification rules according to the specifically called target service. Then, according to the corresponding fault verification rules, the relevant indicator data corresponding to the target service to be verified is obtained, and the relevant indicator data is verified accordingly to determine whether the target service has a fault. If the target service has a fault, the target service is deleted from the preset service request access list to suspend the target service. The present invention does not need to access the third-party component Nginx to realize the detection of service faults, which is not only convenient for expansion, but also increases the fault identification conditions, so that fault identification is more refined according to the business scenario, and the accuracy of fault identification is improved, which solves the technical problems that the existing service fault identification method is not easy to expand and the fault identification method is single.

[0098] Furthermore, based on the first embodiment of the method for identifying a service failure of the present invention, a second embodiment of the method for identifying a service failure of the present invention is proposed.

[0099] In this embodiment, after step S30, the following steps are further included:

[0100] Deleting the target service from the preset service request access list, adding the target service carrying the fault mark to the preset fault list, and calling a general verification module or a custom verification module to perform service detection on the fault service in the fault list according to a preset detection cycle;

[0101] According to the service detection result, determine whether there is an available service to be restored in the fault list;

[0102] If the restored available service exists in the fault list, the fault mark corresponding to the available service is cleared, and the available service after the fault mark is cleared is added to the service request access list.

[0103] The steps of deleting the target service from the preset service request access list, adding the target service carrying the fault mark to the preset fault list, and calling a general verification module or a custom verification module to perform service detection on the fault service in the fault list according to a preset detection cycle specifically include:

[0104] Add the target service carrying the fault mark to the fault list, and determine whether the custom verification module exists in the verification library;

[0105] If the custom verification module exists, calling the custom verification module to perform service detection on the faulty services in the fault list according to the detection cycle;

[0106] If the custom verification module does not exist, the general verification module is called according to the detection cycle to perform service detection on the faulty services in the fault list.

[0107] At present, the nginx fault recovery judgment method is simple. When max_fails is too large, a large number of failed requests will be generated, resulting in abnormal recovery verification and traffic loss. In this embodiment, in order to solve the above problem, in the IDC where the target service is marked as a fault, a transaction request is initiated to the IDC where the fault occurs through a fixed frequency, a custom verification module or a default verification module, and whether the faulty IDC service has recovered to normal is judged according to the transaction result. The IDC that has recovered to normal is put back into the multi-active service request list, and the request traffic is connected. For example: A IDC is marked as a faulty service by the fault identification service, and the fault recovery detection service regularly detects the fault list. If the service does not have a custom verification module, that is, the custom fault detection service is not implemented, the telnetIP port method is used by default, that is, the current Nginx fault judgment method is used to determine whether the faulty service has recovered. If the service has a custom verification module, that is, the service implements a custom detection service, then the custom detection service result is used to determine whether the faulty IDC has recovered. Among them, the custom verification module is a fault verification module customized by the user according to actual transaction needs. Therefore, in this embodiment, various fault recovery verification methods are used, that is, not only the default telnet ip port is supported to check whether the service port is normal, but also the business system can customize the fault recovery service, so as to specifically verify whether the data of a certain business interface is normal. When the business interface data is abnormal due to downstream abnormality but the application module is normal, the fault can also be identified as unrecovered. Among them, the specific service recovery verification process is as follows:

[0108] 1. The multi-active SDK encapsulates the weighted random algorithm and provides a unified multi-active access export interface (weighted random within the service group). The business party calls it. The API interface is as follows:

[0109] Return Type Interface Name Interface Description String getServer(String groupKey) Get the specified group multi-active access exit address

[0110] 2. The business party reports the result after the call is completed. The API interface is as follows:

[0111] Return Type Interface Name Interface Description Void notifyRequestResult(RequestResult result) Service result reporting

[0112] 3. If the business call fails, the business party decides whether to retry. When retrying to obtain the service exit address, it can decide whether to filter the service exit address of the previous request failure according to the business scenario. The API interface is as follows:

[0113]

[0114] Among them, the fault detection service automatically initiates a detection transaction to detect whether the fault is recovered after the faulty machine reaches the waiting time. The fault service recovery detection provides a unified abstract interface as follows:

[0115] Return Type Method Name Method Description Boolean callDetectServer Fault recovery detection service interface

[0116] If the fault service recovery detection request is initiated by the SDK component, two detection methods are provided.

[0117] 1. The SDK component provides a default telnet ip:port method to detect whether the IDC service is available (implemented internally in the SDK)

[0118] 2. The SDK component defines an abstract interface for fault recovery detection, and the business side is responsible for the specific implementation

[0119] For example: the business party defines a service specifically for fault recovery detection by implementing the callDetectServer interface. The service itself can be a bypass transaction (query transaction) / empty transaction without business logic, etc. The Boolean value (true-available, false-unavailable) returned by the transaction interface is used to determine whether the current IDC is available. Among them, the faulty service does not participate in the multi-active access request during the retry time window waiting for the fault recovery. After the faulty service is restored, the IDC corresponding to the faulty service is added to the multi-active access request list and the IDC access weight is adjusted to the initial weight.

[0120] Furthermore, based on the second embodiment of the method for identifying a service failure of the present invention, a third embodiment of the method for identifying a service failure of the present invention is proposed.

[0121] In this embodiment, the relevant indicator data is the service request time and the number of request failures, and the step S20 specifically includes:

[0122] If the fault verification rule is whether the number of request failures of the target service reaches a first preset threshold within a preset time interval, then obtaining the service request time and the number of request failures corresponding to the target service to be verified;

[0123] According to the service request time and the number of request failures, it is determined whether the number of request failures of the target service reaches the first preset threshold within a preset time interval, so as to determine whether a service failure occurs in the target service.

[0124] In this embodiment, in order to verify whether the number of request failures of the target service reaches the first preset threshold within the preset time interval, a double-ended queue data structure is used, the queue length is the maximum length value of each service group max_fails, the failed requests are stored in the queue, and the time of each request is recorded. The time interval between the head and tail nodes and the current queue size are used for judgment. When it is within the configured time interval, that is, the first preset threshold, it is similar to a sliding window. When the sliding window is full, that is, the queue is full, it is determined that the target service has failed.

[0125] Furthermore, the relevant indicator data is the number of consecutive request failures, and the step S20 specifically includes:

[0126] If the fault checking rule is whether the number of consecutive request failures for the target service reaches a second preset threshold, the number of consecutive request failures for the target service is counted, and when it is detected that the target service request is successful, the number of consecutive request failures is reset to zero;

[0127] According to the number of consecutive request failures, it is determined whether the number of consecutive request failures of the target service reaches the second preset threshold, so as to determine whether a service failure occurs in the target service.

[0128] In this embodiment, the failed call situation of each machine is recorded to count the number of consecutive request failures of the target service. When a request fails, the cumulative value (series_fails) is increased by 1, and the cumulative value (series_fails) of a successful request is cleared and the accumulation starts again. When the number of consecutive request failures reaches the second preset threshold, it means that the target service fails.

[0129] Furthermore, the relevant indicator data is the number of visits and the number of successes, and the step S20 specifically includes:

[0130] If the fault checking rule is whether the access success rate of the target service in the preset time interval is less than a third preset threshold, then obtaining the number of accesses and the number of successes of the target service in each preset time interval;

[0131] The access success rate of the target service in each preset time interval is calculated according to the number of accesses and the number of successes, and it is determined whether there is an access success rate less than the third preset threshold value to determine whether a service failure occurs in the target service.

[0132] Furthermore, the relevant indicator data is the average access time, and the step S20 specifically includes:

[0133] If the fault checking rule is whether the average access time of the target service in the preset time interval is greater than a fourth preset threshold, then obtaining the average access time of the target service in each preset time interval;

[0134] It is determined whether there is an average access time that reaches the fourth preset threshold, so as to determine whether a service failure occurs in the target service.

[0135] In this embodiment, the time slice is pre-sliced ​​according to the preset time interval (such as 1 minute), and the relevant indicator data of the target service in each 1 minute are counted, and the statistical value is calculated according to the statistical indicator in each minute, wherein the statistical indicators include the number of visits, the number of successes, and the total time consumption, and the statistical values ​​include the average time consumption and the access success rate. If there is an access success rate less than the third preset threshold, that is, it means that within a certain time interval, the access success rate of the target service is lower than the standard value, or there is an average access time consumption that reaches the fourth preset threshold, that is, it means that within a certain time interval, the average access time consumption of the target service exceeds the standard value, then it is determined that the target service has a fault.

[0136] The present invention also provides a device for identifying a service failure, the device for identifying a service failure comprising:

[0137] A verification rule acquisition module, configured to, upon receiving a service report result instruction triggered based on a service call request, obtain a fault verification rule corresponding to a target service in the service report result instruction;

[0138] A service fault judgment module is used to obtain the relevant indicator data to be verified corresponding to the target service according to the fault verification rule, compare the relevant indicator data with the verification standard in the fault verification rule, and judge whether the target service has a service fault according to the comparison result;

[0139] The fault service marking module is used to mark the target service as faulty according to a preset fault rule strategy if a service fault occurs in the target service.

[0140] Furthermore, the service failure identification device also includes:

[0141] A fault service detection module, used to delete the target service from the preset service request access list, add the target service carrying the fault mark to the preset fault list, and call the general verification module or the custom verification module to perform service detection on the fault service in the fault list according to the preset detection cycle;

[0142] An available service determination module is used to determine whether there is an available service that can be restored in the fault list according to the service detection result;

[0143] The fault service recovery module is used to clear the fault mark corresponding to the available service if the recovered available service exists in the fault list, and add the available service after the fault mark is cleared to the service request access list.

[0144] Furthermore, the fault service detection module is also used for:

[0145] Add the target service carrying the fault mark to the fault list, and determine whether the custom verification module exists in the verification library;

[0146] If the custom verification module exists, calling the custom verification module to perform service detection on the faulty services in the fault list according to the detection cycle;

[0147] If the custom verification module does not exist, the general verification module is called according to the detection cycle to perform service detection on the faulty services in the fault list.

[0148] Furthermore, the relevant indicator data is the service request time and the number of request failures, and the service fault judgment module is also used to:

[0149] If the fault verification rule is whether the number of request failures of the target service reaches a first preset threshold within a preset time interval, then obtaining the service request time and the number of request failures corresponding to the target service to be verified;

[0150] According to the service request time and the number of request failures, it is determined whether the number of request failures of the target service reaches the first preset threshold within a preset time interval, so as to determine whether a service failure occurs in the target service.

[0151] Furthermore, the relevant indicator data is the number of consecutive request failures, and the service fault judgment module is also used to:

[0152] If the fault checking rule is whether the number of consecutive request failures for the target service reaches a second preset threshold, the number of consecutive request failures for the target service is counted, and when it is detected that the target service request is successful, the number of consecutive request failures is reset to zero;

[0153] According to the number of consecutive request failures, it is determined whether the number of consecutive request failures of the target service reaches the second preset threshold, so as to determine whether a service failure occurs in the target service.

[0154] Furthermore, the relevant indicator data is the number of accesses and the number of successes, and the service fault judgment module is also used to:

[0155] If the fault checking rule is whether the access success rate of the target service in the preset time interval is less than a third preset threshold, then obtaining the number of accesses and the number of successes of the target service in each preset time interval;

[0156] The access success rate of the target service in each preset time interval is calculated according to the number of accesses and the number of successes, and it is determined whether there is an access success rate less than the third preset threshold value to determine whether a service failure occurs in the target service.

[0157] Furthermore, the relevant indicator data is the average access time, and the service fault judgment module is also used to:

[0158] If the fault checking rule is whether the average access time of the target service in the preset time interval is greater than a fourth preset threshold, then obtaining the average access time of the target service in each preset time interval;

[0159] It is determined whether there is an average access time that reaches the fourth preset threshold, so as to determine whether a service failure occurs in the target service.

[0160] Furthermore, the service failure identification device further includes a service call processing module, and the service call processing module is further used to:

[0161] When receiving the service call request, determining the target service in the service request access list according to the preset weights corresponding to the various services;

[0162] The service call request is processed based on the target service, and a corresponding service report result instruction is generated.

[0163] The methods executed by the above-mentioned program modules can refer to the various embodiments of the method for identifying service failures of the present invention, and will not be described in detail here.

[0164] The present invention also provides a computer-readable storage medium.

[0165] The computer-readable storage medium of the present invention stores a service failure identification program, and when the service failure identification program is executed by a processor, the steps of the service failure identification method described above are implemented.

[0166] Among them, the method implemented when the service fault identification program running on the processor is executed can refer to the various embodiments of the service fault identification method of the present invention, and will not be repeated here.

[0167] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or system including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or system. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or system including the element.

[0168] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0169] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in each embodiment of the present invention.

[0170] The above are only preferred embodiments of the present invention, and are not intended to limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made using the contents of the present invention specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A method for identifying a service failure, characterized in that: The service failure identification method comprises the following steps: Upon receiving a service report result instruction triggered based on a service call request, obtaining a fault verification rule corresponding to a target service in the service report result instruction; According to the fault verification rule, obtain the relevant indicator data to be verified corresponding to the target service, compare the relevant indicator data with the verification standard in the fault verification rule, and determine whether the target service has a service failure according to the comparison result; If a service failure occurs in the target service, the target service is marked as a failure according to a preset failure rule strategy; Before the step of obtaining the fault verification rule corresponding to the target service in the service reporting result instruction when receiving the service reporting result instruction triggered by the service calling request, the method further includes: When receiving the service call request, determining the target service in a preset service request access list according to preset weights corresponding to the respective services; Processing the service call request based on the target service and generating a corresponding service report result instruction; Wherein, when the service call request is received, the step of determining the target service in the preset service request access list according to the preset weights corresponding to the services specifically includes: Group each service and the corresponding service IP, and obtain the valid IDC in each group according to the group identifier, wherein the IDC includes the service IP and the preset access weight; If the access weights of the services in the group are equal, the target service is randomly determined from the valid IDCs in the group; If the access weights of the services in the group are not equal, the total access weight of the group is calculated, and an access array is defined according to the number of valid IDCs, wherein the access array is used to store the access weights of the valid IDCs in the group; Based on an integer value less than the total access weight, the access array is traversed, and based on the integer value generated by the traversal and the weight of the current traversal, the target service is determined in the effective IDC within the group.

2. The method for identifying a service failure according to claim 1, wherein: If a service failure occurs in the target service, after marking the target service as a failure according to a preset failure rule strategy, the method further includes: Deleting the target service from the preset service request access list, adding the target service carrying the fault mark to the preset fault list, and calling a general verification module or a custom verification module to perform service detection on the fault service in the fault list according to a preset detection cycle; According to the service detection result, determine whether there is an available service to be restored in the fault list; If the restored available service exists in the fault list, the fault mark corresponding to the available service is cleared, and the available service after the fault mark is cleared is added to the preset service request access list.

3. The method for identifying a service failure according to claim 2, wherein: The step of deleting the target service from the preset service request access list, adding the target service carrying the fault mark to the preset fault list, and calling the general verification module or the custom verification module to perform service detection on the fault service in the fault list according to the preset detection cycle specifically includes: Add the target service carrying the fault mark to the fault list, and determine whether the custom verification module exists in the verification library; If the custom verification module exists, calling the custom verification module to perform service detection on the faulty services in the fault list according to the detection cycle; If the custom verification module does not exist, the general verification module is called according to the detection cycle to perform service detection on the faulty services in the fault list.

4. The method for identifying a service failure according to claim 1, characterized in that: The relevant indicator data is the service request time and the number of request failures. The steps of obtaining the relevant indicator data to be verified corresponding to the target service according to the fault verification rule, comparing the relevant indicator data with the verification standard in the fault verification rule, and judging whether a service failure occurs in the target service according to the comparison result specifically include: If the fault verification rule is whether the number of request failures of the target service reaches a first preset threshold within a preset time interval, then obtaining the service request time and the number of request failures corresponding to the target service to be verified; According to the service request time and the number of request failures, it is determined whether the number of request failures of the target service reaches the first preset threshold within a preset time interval, so as to determine whether a service failure occurs in the target service.

5. The method for identifying a service failure according to claim 1, wherein: The relevant indicator data is the number of consecutive request failures. The steps of obtaining the relevant indicator data to be verified corresponding to the target service according to the fault verification rule, comparing the relevant indicator data with the verification standard in the fault verification rule, and judging whether a service failure occurs in the target service according to the comparison result specifically include: If the fault checking rule is whether the number of consecutive request failures for the target service reaches a second preset threshold, the number of consecutive request failures for the target service is counted, and when it is detected that the target service request is successful, the number of consecutive request failures is reset to zero; According to the number of consecutive request failures, it is determined whether the number of consecutive request failures of the target service reaches the second preset threshold, so as to determine whether a service failure occurs in the target service.

6. The method for identifying a service failure according to claim 1, characterized in that: The relevant indicator data is the number of accesses and the number of successes. The steps of obtaining the relevant indicator data to be verified corresponding to the target service according to the fault verification rule, comparing the relevant indicator data with the verification standard in the fault verification rule, and judging whether a service failure occurs in the target service according to the comparison result specifically include: If the fault checking rule is whether the access success rate of the target service in the preset time interval is less than a third preset threshold, then obtaining the number of accesses and the number of successes of the target service in each preset time interval; The access success rate of the target service in each preset time interval is calculated according to the number of accesses and the number of successes, and it is determined whether there is an access success rate less than the third preset threshold value to determine whether a service failure occurs in the target service.

7. The method for identifying a service failure according to claim 1, characterized in that: The relevant indicator data is an average access time. The steps of obtaining the relevant indicator data to be verified corresponding to the target service according to the fault verification rule, comparing the relevant indicator data with the verification standard in the fault verification rule, and judging whether a service failure occurs in the target service according to the comparison result specifically include: If the fault checking rule is whether the average access time of the target service in the preset time interval is greater than a fourth preset threshold, then obtaining the average access time of the target service in each preset time interval; It is determined whether there is an average access time that reaches the fourth preset threshold, so as to determine whether a service failure occurs in the target service.

8. A device for identifying a service failure, characterized in that: The service failure identification device comprises: A verification rule acquisition module, configured to, upon receiving a service report result instruction triggered based on a service call request, obtain a fault verification rule corresponding to a target service in the service report result instruction; A service fault judgment module is used to obtain the relevant indicator data to be verified corresponding to the target service according to the fault verification rule, compare the relevant indicator data with the verification standard in the fault verification rule, and judge whether the target service has a service fault according to the comparison result; A fault service marking module is used to mark the target service as faulty according to a preset fault rule strategy if a service fault occurs in the target service; A service call processing module, configured to, upon receiving the service call request, determine the target service in a preset service request access list according to preset weights corresponding to the various services; process the service call request based on the target service, and generate a corresponding service report result instruction; The service call processing module is also used to group each service and the corresponding service IP, and obtain the valid IDC in each group according to the group identifier, and the IDC includes the service IP and a preset access weight; if the access weights of the services in the group are equal, the target service is randomly determined in the valid IDC in the group; if the access weights of the services in the group are not equal, the total access weight of the group is calculated, and an access array is defined according to the number of valid IDCs, wherein the access array is used to store the access weights of the valid IDCs in the group; based on an integer value less than the total access weight, the access array is traversed, and the target service is determined in the valid IDC in the group based on the integer value generated by the traversal and the weight of the current traversal.

9. The service failure identification device according to claim 8, characterized in that: The service failure identification device also includes: A fault service detection module, used to delete the target service from the preset service request access list, add the target service carrying the fault mark to the preset fault list, and call a general verification module or a custom verification module to perform service detection on the fault service in the fault list according to a preset detection cycle; An available service determination module is used to determine whether there is an available service that can be restored in the fault list according to the service detection result; The fault service recovery module is used to clear the fault mark corresponding to the available service if the recovered available service exists in the fault list, and add the available service after the fault mark is cleared to the preset service request access list.

10. The service failure identification device according to claim 8, characterized in that: The relevant indicator data are service request time and request failure times. The service fault judgment module is also used to: If the fault verification rule is whether the number of request failures of the target service reaches a first preset threshold within a preset time interval, then obtaining the service request time and the number of request failures corresponding to the target service to be verified; According to the service request time and the number of request failures, it is determined whether the number of request failures of the target service reaches the first preset threshold within a preset time interval, so as to determine whether a service failure occurs in the target service.

11. The service failure identification device according to claim 8, characterized in that: The relevant indicator data is the number of consecutive request failures, and the service fault judgment module is also used to: If the fault checking rule is whether the number of consecutive request failures for the target service reaches a second preset threshold, the number of consecutive request failures for the target service is counted, and when it is detected that the target service request is successful, the number of consecutive request failures is reset to zero; According to the number of consecutive request failures, it is determined whether the number of consecutive request failures of the target service reaches the second preset threshold, so as to determine whether a service failure occurs in the target service.

12. The service failure identification device according to claim 8, characterized in that: The relevant indicator data is the number of accesses and the number of successes. The service fault judgment module is also used to: If the fault checking rule is whether the access success rate of the target service in the preset time interval is less than a third preset threshold, then obtaining the number of accesses and the number of successes of the target service in each preset time interval; The access success rate of the target service in each preset time interval is calculated according to the number of accesses and the number of successes, and it is determined whether there is an access success rate less than the third preset threshold value to determine whether a service failure occurs in the target service.

13. The service failure identification device according to claim 8, characterized in that: The relevant indicator data is the average access time, and the service fault judgment module is also used for: If the fault checking rule is whether the average access time of the target service in the preset time interval is greater than a fourth preset threshold, then obtaining the average access time of the target service in each preset time interval; It is determined whether there is an average access time that reaches the fourth preset threshold, so as to determine whether a service failure occurs in the target service.

14. A device for identifying service failures, characterized in that: The service failure identification device includes: a memory, a processor, and a service failure identification program stored in the memory and executable on the processor. When the service failure identification program is executed by the processor, the steps of the service failure identification method as described in any one of claims 1 to 7 are implemented.

15. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a service failure identification program, and when the service failure identification program is executed by a processor, the steps of the service failure identification method according to any one of claims 1 to 7 are implemented.

Images