CN110209556B

CN110209556B - Disaster tolerance testing method, payment method, device, medium and service equipment

Info

Publication number: CN110209556B
Application number: CN201810301547.3A
Authority: CN
Inventors: 陈玉英
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2018-04-04
Filing date: 2018-04-04
Publication date: 2021-11-23
Anticipated expiration: 2038-04-04
Also published as: CN110209556A

Abstract

The embodiment of the invention discloses a disaster tolerance testing method, a payment method, a device, a medium and service equipment, wherein the method comprises the following steps: acquiring associated data of the first equipment cluster, wherein the associated data comprises IP data, service data and database information; isolating the first equipment cluster according to the associated data and generating a target test case; triggering the second device cluster to execute the target test case to obtain a disaster tolerance test result, and automatically and intelligently realizing the disaster tolerance test of the disaster tolerance system to ensure the disaster tolerance performance of the disaster tolerance system in the service processing service process, wherein the test efficiency is higher and the practicability is high.

Description

Disaster tolerance testing method, payment method, device, medium and service equipment

Technical Field

The present invention relates to the field of computer technologies, and in particular, to a disaster recovery testing method, a disaster recovery testing apparatus, a payment method, a payment apparatus, a computer storage medium, and a service device.

Background

With the development of computer technology and the enrichment of business types in various fields (such as e-commerce field, financial transaction field, etc.), the real-time performance of business processing is required to be higher and higher, for example: when shopping through the internet, real-time payment is usually required, which requires that the service system can provide real-time payment business processing service, which has high requirements on the processing performance of the service system. In practical applications, in order to solve the performance problem and ensure the real-time performance of the service processing, a service system usually adopts a disaster recovery system with a disaster recovery function; the disaster recovery system is a system composed of two (or more) IT (Information Technology) systems with the same function, the two (or more) IT systems are called as mutually equivalent systems, the two (or more) IT systems can perform working state monitoring and function switching, when one of the two (or more) IT systems fails due to some factors (such as artificial, fire, earthquake, etc.), the service of the failed IT system can be switched to the other one of the equivalent IT systems, and the peer IT systems perform the service of the failed IT system, so as to provide uninterrupted service processing service. Therefore, how to ensure the disaster recovery performance of the disaster recovery system in the process of providing the service processing service, that is, how to perform the disaster recovery test on the disaster recovery system to ensure the disaster recovery performance of the disaster recovery system, is a problem to be solved urgently.

Disclosure of Invention

Embodiments of the present invention provide a disaster tolerance testing method, a payment method, an apparatus, a medium, and a service device, which can automatically and intelligently perform a disaster tolerance test on a disaster tolerance system to ensure disaster tolerance performance of the disaster tolerance system in a service processing service process, and have high testing efficiency and high practicability.

In one aspect, an embodiment of the present invention provides a disaster recovery testing method, which is applied to a disaster recovery system, where the disaster recovery system at least includes a first device cluster and a second device cluster that is equivalent to the first device cluster, and the method includes:

acquiring associated data of the first equipment cluster, wherein the associated data comprises IP data, service data and database information;

isolating the first equipment cluster according to the associated data and generating a target test case;

and triggering the second equipment cluster to execute the target test case to obtain a disaster tolerance test result.

In one aspect, an embodiment of the present invention provides a payment method, which is applied to a disaster recovery system, where the disaster recovery system at least includes a first device cluster and a second device cluster corresponding to the first device cluster; the disaster recovery system adopts the disaster recovery test method of the first aspect to test and pass the test; the payment method comprises the following steps:

receiving a payment request, wherein the payment request carries an identifier of the first equipment cluster;

if the first equipment cluster fails, forwarding the payment request to the second equipment cluster;

triggering the second device cluster to respond to the payment request.

In one aspect, an embodiment of the present invention provides a disaster recovery testing apparatus, where the apparatus includes:

the acquisition module is used for acquiring associated data of the first equipment cluster, wherein the associated data comprises IP data, service data and database information;

the isolation module is used for isolating the first equipment cluster according to the associated data and generating a target test case;

and the triggering module is used for triggering the second equipment cluster to execute the target test case to obtain a disaster tolerance test result.

In one aspect, an embodiment of the present invention provides a payment apparatus, which is applied to a disaster recovery system, where the disaster recovery system at least includes a first device cluster and a second device cluster corresponding to the first device cluster; the disaster recovery system is characterized in that the disaster recovery system adopts the disaster recovery test method to test and pass the test; the payment device includes:

a receiving module, configured to receive a payment request, where the payment request carries an identifier of the first device cluster;

a forwarding module, configured to forward the payment request to the second device cluster if the first device cluster fails;

and the triggering module is used for triggering the second equipment cluster to respond to the payment request.

In one aspect, an embodiment of the present invention provides a computer storage medium, where one or more first instructions are stored in the computer storage medium, where the one or more first instructions are suitable for being loaded by a processor and executing a disaster tolerance testing method, where the disaster tolerance testing method is applied to a disaster tolerance system, where the disaster tolerance system at least includes a first device cluster and a second device cluster that is equivalent to the first device cluster; the disaster recovery testing method comprises the following steps:

triggering the second equipment cluster to execute the target test case to obtain a disaster tolerance test result;

or, the computer storage medium stores one or more second instructions, the one or more second instructions are suitable for being loaded by the processor and executing a payment method, the payment method is applied to a disaster recovery system, and the disaster recovery system at least comprises a first device cluster and a second device cluster which is equivalent to the first device cluster; the disaster recovery system passes the disaster recovery test; the payment method comprises the following steps:

triggering the second device cluster to respond to the payment request.

In one aspect, an embodiment of the present invention provides a service device, where the service device includes:

a processor adapted to implement one or more instructions; and the number of the first and second groups,

the disaster recovery system comprises a computer storage medium, a processor and a disaster recovery system, wherein the computer storage medium stores one or more first instructions, the one or more first instructions are suitable for being loaded by the processor and executing a disaster recovery test method, the disaster recovery test method is applied to a disaster recovery system, and the disaster recovery system at least comprises a first equipment cluster and a second equipment cluster which is equivalent to the first equipment cluster; the disaster recovery testing method comprises the following steps:

triggering the second device cluster to respond to the payment request.

The disaster recovery system of the embodiment of the invention at least comprises a first equipment cluster and a second equipment cluster which is equivalent to the first equipment cluster, and can automatically generate a target test case according to the associated data of the first equipment cluster, isolate the first equipment cluster and execute the target test case by the second equipment cluster to obtain a disaster recovery test result.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

Fig. 1 is a schematic diagram of a disaster recovery system according to the present invention;

FIG. 2 is a schematic flow chart of a disaster recovery testing method according to the present invention;

FIG. 3 is a schematic flow chart of a disaster recovery testing method according to the present invention;

FIG. 4 is a schematic flow chart of a disaster recovery testing method according to the present invention;

FIG. 5 is a schematic diagram of an architecture of a payment application scenario provided by the present invention;

FIG. 6 is a schematic flow chart of a payment method provided by the present invention;

fig. 7 is a schematic structural diagram of a disaster recovery testing device according to the present invention;

FIG. 8 is a schematic structural diagram of a payment device provided by the present invention;

fig. 9 is a schematic structural diagram of a service device provided in the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

Related art of the embodiment of the present invention refers to a disaster recovery system, which is a system composed of two (or more) IT systems with the same function, where the two (or more) IT systems are referred to as mutually peer-to-peer systems, and the two (or more) IT systems can perform monitoring of working status and switching of functions, and when one of the two (or more) IT systems fails due to some factors (such as man power, fire, earthquake, etc.), the service of the failed IT system can be switched to the other peer-to-peer IT system, and the peer-to-peer IT system executes the service of the failed IT system, so as to provide uninterrupted service processing service. At present, a disaster recovery system generally includes a plurality of device clusters (hereinafter referred to as set), that is, the disaster recovery system is generally a set-based disaster recovery system, and the set-based disaster recovery system can effectively improve disaster recovery performance.

The set is to divide a single independent disaster recovery system into a system composed of a plurality of sets, each set can be deployed independently on hardware and software, and each set is logically independent and has independent functions. Wherein each set comprises one or more electronic devices which together implement the functionality of an IT system, the set providing service handling services via the one or more electronic devices comprised by the set.

Please refer to the disaster recovery system shown in fig. 1, the disaster recovery system is divided into 12 sets, respectively set1 and set2 … … set 12. Each set has independent traffic processing capability, such as: set1 in fig. 1 is used to provide service processing service for the user group whose account number belongs to [0, 1000], and set2 is used to provide service processing service for the user group whose account number belongs to [1001, 2000 ]; and so on.

In order to provide service processing services for users with a larger scope, sets in the disaster recovery system may be set in different regional scopes, for example, sets 1 to 6 in fig. 1 may be deployed in the regional scope where a city (such as shenzhen) is located, and sets 7 to 12 may be deployed in the regional scope where B city (such as shanghai) is located. Then, the sets located in the same region are mutually called as the same-city sets, for example: set1 and any one of sets 2-set6 are mutually called as same-city sets; the following steps are repeated: set7 and any one of sets 8-set12 are mutually called as co-city sets. Accordingly, the various sets located in different regional domains are referred to as cross-city sets, for example: set1 and any one of sets 7-set12 are referred to as cross-city sets; the following steps are repeated: set7 and any of sets 1-set6 are referred to interchangeably as cross-city sets.

In order to implement disaster tolerance, one or more sets corresponding to each set are configured for each set, and two sets corresponding to each other have the same service processing function, for example: if set2 is set1 peer-to-peer set, set2 has set1 service processing function in addition to its own independent service processing function, if set1 fails to work normally due to failure or other reasons, set1 service can be switched to set2, and set2 is used to execute set1 service; if set1 is also the peer set of set2, i.e. set1 and set2 are peer sets, then set1 has its own independent traffic processing function and also has the traffic processing function of set 2; if set2 fails to work normally due to failure or other reasons, the set2 service can be switched to set1, and set1 is used as the service for executing set 2. The peer sets may be divided into city-like peer sets and cross-city peer sets according to regional scope partitioning. Referring to FIG. 1, assuming that both set2 and set11 are peer sets of set1, since set1 and set2 belong to the same regional scope, set2 is referred to as the co-city peer set of set 1; since set11 and set1 belong to different regional scopes, set11 is referred to as set 1's cross-city peer set. When set1 fails, in order to improve disaster recovery efficiency, the traffic of set1 can be quickly switched to the set of the same city peer (i.e. set2), and the switching process is called as the same city switching. In some cases, such as a network breakdown of the area domain where set1 is located, all sets within the area domain are inoperable; at this time, when set1 and its same city peer set (i.e. set2) fail at the same time, in order to provide uninterrupted traffic processing service for users, it is necessary to switch the traffic of set1 to the cross-city peer set (i.e. set11) of set1, and certainly, synchronously, it is also necessary to switch the traffic of set2 to the cross-city peer set of set2, and this switching process is called cross-city switching. Further, after the set1 recovers the failure, it is necessary to switch set1 traffic from peer set (co-city peer set2 or cross-city peer set11) back to set1 to avoid the continuous processing burden on peer set, and this switching process is called back-switching.

As can be seen from the above, the superiority and inferiority of the disaster recovery performance of a disaster recovery system are determined by three indexes, which are: the same city switching performance, the cross city switching performance and the back switching performance; therefore, the test for the disaster recovery performance of a disaster recovery system also includes three test contents, which are respectively: the same city switching test, the cross city switching test and the back switching test. Wherein, the process of the same city switching test roughly comprises the following steps: firstly simulating that a certain set (assumed to be set1) generates a fault (such as adding set1 IP data to a firewall to disconnect the network connection of set1 or turning off the working power supply of set1), and meanwhile assuming that set2 of the same city peer of set1 can work normally; acquiring the associated data of the fault set1 to generate a target test case; finally triggering the same-city peer set2 to execute the target test case to obtain a disaster tolerance test result; if the disaster recovery test result is passed, it indicates that when set1 fails, the set2 of the same city peer can normally execute set1 service, and the disaster recovery system has the same city disaster recovery function; on the contrary, if the result of the disaster tolerance test is failed, it indicates that when set1 fails, set2 of the same city peer cannot replace set1 to perform service processing, and the disaster tolerance system does not have the function of disaster tolerance of the same city.

Wherein, the process of switching the test across cities roughly comprises: first, simulating that a certain set (assumed to be set1) generates a fault (for example, adding set1 IP data to a firewall to disconnect the network connection of set1 or turning off the working power supply of set1), and simultaneously assuming that set1 and set2 of the same city peer fail and cross-city peer set11 can work normally; acquiring the associated data of the fault set1 to generate a target test case; finally, triggering the cross-city peer set11 to execute the target test case to obtain a disaster tolerance test result; if the disaster recovery test result is passed, it indicates that when set1 fails, set11 of the cross-city peer can normally execute set1 service, and the disaster recovery system has a cross-city disaster recovery function; on the contrary, if the disaster recovery test result is failed, it indicates that set1 has a fault, set11 of the cross-city peer cannot replace set1 to execute service processing, and the disaster recovery system does not have the function of cross-city disaster recovery.

Wherein, the process of the back cut test roughly comprises: simulating a set1 recovery fault (for example, deleting the IP data of set1 from the firewall to recover the network connection of set1 or turning on the working power supply of set 1); acquiring the associated data of set1 to generate a target test case; finally, executing the target test case on set1 to obtain a back-cut test result; if the result of the back-switching test is passed, the result shows that after the fault of the set1 is recovered, the service of the set1 can be successfully back-switched to the set1 and can be successfully executed, and the disaster recovery system has a back-switching function; on the contrary, if the disaster tolerance test result is failed, it indicates that after the fault of set1 is recovered, the service of set1 cannot be successfully switched back to set1 or cannot be successfully executed, and the disaster tolerance system does not have a back-switching function.

According to the test process, a target test case is needed to be used in the process of carrying out disaster recovery test on the disaster recovery system, and the target test case is generated by the associated data of the fault set. In the embodiment of the invention, a set of general service automation cases can be compiled in advance, the request parameters of the service automation cases are quantized, and when the target test case is generated, the target test case can be generated only by using the related data of the related fault set as the variables of the request parameters to be transmitted into the automation case, so that the service automation cases can be prevented from being compiled aiming at each set, the compiling task quantity of the service automation cases is reduced, the tests on each set in the disaster recovery system can be realized through one set of service automation cases, the test efficiency is high, and the practicability is strong. The set-associated data may include IP (Internet Protocol, Protocol for interconnection between networks) data, service data, and database information, and may also include an identifier of the set. The identifier of a set may refer to the number, name, or MAC (Media Access Control) address of the set.

The IP data may refer to a set of IP addresses of each electronic device in a set, or may be IP addresses of electronic devices in the set that exchange data with an external set. Traffic data may refer to data related to the provision of traffic handling services by a set, and may include, but is not limited to: business service order data, the account number of the served user group belongs to the range, and the like. One set corresponds to one database, for example: set1 corresponds to database one and set2 corresponds to database two. The database information may include the name of the database and/or the address of the database, etc., and the database of the set may be used to store the expected results of the set of test cases.

The associated data for each set in the disaster recovery system may be stored in the form of a configuration file. Taking set1 and set2 as examples, which are mutually equivalent, the associated data of set1 includes the identifier of set1, the IP data 123.456.7.8, the service data of the user group whose account number belongs to [0, 1000], the database name k1, and the database address F1. The stored associated data of set2 includes the identification of set, IP data 123.456.7.9, service data of the user group whose account number belongs to [1001, 2000], database name k2, and database address F2. The association data table may represent the following table one:

table one: associated data table

In addition to recording the associated data (table one) of each set, the configuration file in the embodiment of the present invention also stores the peer relationship of each set, which may be specifically referred to as the following table two:

table two: peer relationship table

set identifier	To which the region range belongs	Same city peer set	Cross-city peer set
				set1	A city	set2	set11
set2	A city	set1	set12
				…	…	…	…

It should be understood that the configuration file may store the associated data and the peer relationship of each set in the disaster recovery system by using the table files shown in the first table and the second table, and in practical applications, the configuration file may also be represented by other manners, such as a text file, and the like.

In the embodiment of the present invention, during the disaster recovery test, the identifier of the fault set may be determined according to the test requirement, where the test requirement includes a fault list, and the fault list includes the identifier of the fault set, for example: if one wants to test the disaster tolerance capability of the system when the set1 fails, the failure set is set1, and the identifier of set1 is added to the failure list; similarly, if one wants to test the disaster tolerance of the system in the event of a set7 failure, then the failure set is set7 and the identity of set7 is added to the failure list. The associated data of the fault set can be searched through the table I, and then a test case is automatically generated according to the associated data; the peer set with the fault set can be searched through the second table, the fault set is isolated, the peer set is triggered to execute the test case, and then the test result can be obtained.

In the following embodiments of the present invention, a first device cluster may be any one of the device clusters in the disaster recovery system, and the first device cluster is abbreviated as set1, a second same-city device cluster that is equivalent to the first device cluster is abbreviated as set1, and a second cross-city device cluster that is equivalent to the second device cluster is abbreviated as set 1.

Based on the above description about the architecture of the disaster recovery system, an embodiment of the present invention provides a disaster recovery testing method, please refer to fig. 2, which can be applied to the disaster recovery system shown in fig. 1, where the disaster recovery system at least includes set1 and a set-equivalent second device cluster (i.e. set2 of the same city and set2 of cross-city), and the disaster recovery testing method includes:

s101, obtaining associated data of the first equipment cluster, wherein the associated data comprises IP data, service data and database information.

The associated data of set1 can be obtained from the configuration file, and in a specific implementation, the associated data of set1 can be read from the table one. In the embodiment of the invention, the service device for disaster recovery testing can provide a human-computer interaction interface, and a user (such as a tester) can set testing requirements in the human-computer interaction interface, wherein the testing requirements comprise setting a fault list of a disaster recovery system, the fault list comprises identifications of sets generating faults, and the set fault list comprises the identifications of sets 1; then, a disaster tolerance test instruction is initiated, and the disaster tolerance test instruction carries a fault list; then, in step S101, the set1 associated data is acquired according to the set1 identifier included in the fault list in the disaster tolerance test instruction.

S102, isolating the first equipment cluster according to the associated data, and generating a target test case.

The purpose of isolating set1 is to: set1 is disabled to avoid interfering with the disaster recovery testing process. In a specific implementation, the isolation of set1 can be realized by disconnecting the network connection of set1 or disconnecting the working power supply of set 1. Further, the target test case can be generated by inputting the relevant data of the set1 as a variable into the general business automation case.

S103, triggering the second equipment cluster to execute the target test case to obtain a disaster tolerance test result.

The second device cluster, divided by area scope, may be set2, which is set1, and may also be set11, which is set1, which is a cross-city peer. If the second device cluster is set2, the disaster recovery test is the same-city switching test; if the second device cluster is set11, the disaster recovery test is a cross-city switching test. After the target test case is generated, triggering the second device cluster to execute the target test case to obtain a disaster recovery test result, where the triggering may include: firstly, sending a configuration notification carrying a set1 identifier to a second device cluster, wherein the configuration notification is used for making the second device cluster definitely have a fault at set1 and indicating that the second device cluster executes set1 service instead; and then sending the target test case to a second equipment cluster, and controlling the second equipment cluster to execute the target test case to obtain a disaster tolerance test result. Optionally, in order to improve compatibility of the disaster recovery system, a configuration notification may be sent to all normal sets except set1 in the disaster recovery system, so that all other normal sets can be made to definitely indicate that set1 has a fault, when a service request sent to set1 is forwarded to other normal sets due to an accident (such as a call error), other normal sets may also perform a quick response for executing the service, thereby improving compatibility of the disaster recovery system.

Further, if the disaster tolerance test result is that the second device cluster can normally execute the service of the first device cluster, the disaster tolerance system has a disaster tolerance function; if the disaster tolerance test result is failed, it indicates that the second device cluster cannot normally execute the service of the first device cluster, and the disaster tolerance system does not have the disaster tolerance function. In specific implementation, an expected result of the disaster recovery test corresponding to each set is stored in a database of each set, and the expected result includes log data and result data obtained when the service of the failed set is replaced by the peer set as execution when each set fails; for example: the test requirement indicates that the set1 is subjected to a disaster recovery test, indicating that the disaster recovery capability of the system when the set1 fails needs to be tested, then a first expected result that the disaster recovery system should achieve when the set1 fails can be preset, the first expected result including log data and result data obtained when the set1 traffic is replaced as execution by peer-to-peer sets, and the first expected result is stored in a database corresponding to the set 1. In the disaster recovery test process, a peer second device cluster (set2 or set11), taking set2 as an example, will obtain corresponding log data and result data after a set2 executes a target test case; storing the log data and result data obtained by set2 into a database corresponding to set2, then in step S103, first determining whether set2 successfully executes the target test case, where successful execution refers to complete execution of the target test case, and no interrupt or error prompt is popped up during execution, and conversely, where unsuccessful execution refers to incomplete execution of the target test case, and an interrupt or error prompt is popped up during execution; and if the target test case fails to be executed on the set2, the disaster tolerance test result is failed. If the set2 successfully executes the target test case, querying whether corresponding log data and result data are stored in a database corresponding to the set 2; and if the corresponding log data and result data are not inquired in the database of the set2, the disaster tolerance test result is failed. If the corresponding log data and result data are inquired, comparing the inquired log data and result data with an expected result stored in a set1 database, and if the comparison is consistent, determining that the disaster tolerance test result is passed; if the comparison is not consistent, the disaster tolerance test result is determined to be failed.

An embodiment of the present invention provides another disaster tolerance testing method, which is applied to a disaster tolerance system, where the disaster tolerance system at least includes a first device cluster and a second device cluster that is equivalent to the first device cluster, and please refer to fig. 3, where the disaster tolerance testing method includes:

s201, receiving a fault list, wherein the fault list comprises an identifier of a first device cluster.

The service device for performing the disaster recovery test can provide a human-computer interaction interface, and a user (such as a tester) can set test requirements in the human-computer interaction interface, including setting a fault list of the disaster recovery system, wherein the fault list includes identifiers of all sets generating faults, and the set fault list includes an identifier of set 1; then, a disaster tolerance test instruction is initiated, and the disaster tolerance test instruction carries a fault list; then in step S201 a fault list is received from which the identity of set1 is obtained.

S202, obtaining the associated data of the first equipment cluster, wherein the associated data comprises IP data, service data and database information. The associated data of set1 can be obtained from the configuration file, and in a specific implementation, the associated data of set1 can be read from the table one.

S203, isolating the first equipment cluster according to the associated data, and generating a target test case. In a specific implementation, the step S203 may include the following steps S11-S13:

s11, adding the IP data of the first device cluster to the firewall to disconnect the network connection of the first device cluster.

The purpose of isolating set1 is to: stopping the set1 to avoid interference to the disaster recovery test process; in the embodiment of the invention, the IP data of the set1 is added to the firewall, such as the IP list of the firewall, so that the isolation of the set1 can be realized in a mode of disconnecting the network connection of the set 1. The isolation process does not need manual participation, and the automation degree is high.

And s12, acquiring a preset service automation use case.

s13, the associated data of the first device cluster is used as a request parameter to be transmitted to the business automation case to generate the target test case.

In the embodiment of the invention, a set of general service automation cases can be compiled in advance, the request parameters of the service automation cases are quantized, and when the target test case is generated, the target test case can be generated only by using the related data of the related fault set as the variables of the request parameters to be transmitted into the automation case, so that the service automation cases can be prevented from being compiled aiming at each set, the compiling task quantity of the service automation cases is reduced, the tests on each set in the disaster recovery system can be realized through one set of service automation cases, the test efficiency is high, and the practicability is strong. In steps s12-s13, the associated data of set1 is transmitted as a request parameter to a preset service automation case, so that a target test case can be generated, wherein the target test case is used for performing disaster recovery testing under the condition that set1 has a fault (namely is isolated).

And S204, judging whether the cross-city switching test or the same-city switching test is required according to the fault list.

From table two above, co-city peer set2 and cross-city peer set11 are known as set 1. Then, if the fault list does not include the identifier of set2, indicating that set1 co-city peer set2 can work normally, it is determined that a co-city handover test needs to be performed on set1, and step S205 is performed; if the fault list comprises an identifier of set2 and no identifier of set11 in addition to an identifier of set 1; indicating that set1 and its set2 together fail to work normally, but set11 of set1 across cities can work normally, it is determined that a cross-city switch test needs to be performed on set1, and step S206 is performed. Of course, it can be understood that if set1, set2 and set11 are included in the fault list at the same time, which indicates that set1 and all peer-to-peer sets thereof all generate faults at the same time, it may output that the result of the disaster tolerance test fails, that is, when set1 generates a fault, the disaster tolerance system cannot perform disaster tolerance switching, and the disaster tolerance capability of the disaster tolerance system cannot cope with the situation that set1 generates a fault.

S205, triggering a second same-city equipment cluster to execute the target test case to obtain a disaster tolerance test result; thereafter, the process proceeds to step S207.

When the same-city handover test needs to be carried out on set1, firstly, a configuration notice carrying a set1 identifier is sent to set2, wherein the configuration notice is used for making set2 clearly indicate that set1 has a fault and is used for indicating that set2 executes a set1 service instead; then sending the target test case to set2, and controlling set2 to execute the target test case; and finally, obtaining a disaster tolerance test result according to the execution result of the target test case on set 2. Further, if the result of the disaster recovery test is passed, it indicates that when set1 fails, set2 of the same-city peer can normally execute set1 service, and the disaster recovery system has the same-city disaster recovery function; on the contrary, if the result of the disaster tolerance test is failed, it indicates that when set1 fails, set2 of the same city peer cannot replace set1 to perform service processing, and the disaster tolerance system does not have the function of disaster tolerance of the same city.

And S206, triggering the second cross-city equipment cluster to execute the target test case to obtain a disaster recovery test result.

When a cross-city handover test needs to be carried out on set1, firstly, a configuration notification carrying a set1 identifier is sent to set11, wherein the configuration notification is used for making set11 clearly indicate that set1 has a fault and is used for indicating that set11 executes a set1 service instead; then sending the target test case to set11, and controlling set11 to execute the target test case; and finally, obtaining a disaster tolerance test result according to the execution result of the target test case on set 11. Further, if the result of the disaster recovery test is passed, it indicates that when set1 fails, set11 of the cross-city peer can normally execute set1 service, and the disaster recovery system has a cross-city disaster recovery function; on the contrary, if the disaster recovery test result is failed, it indicates that set1 has a fault, set11 of the cross-city peer cannot replace set1 to execute service processing, and the disaster recovery system does not have the function of cross-city disaster recovery.

The obtaining of the disaster tolerance test result according to the execution result of the target test case on the peer-to-peer second device cluster (set2 or set11) may include the following steps s21-s 22:

s21, if the target test case is executed by the second device cluster for a predetermined number of times and at least one execution is successful, the disaster tolerance test result is that the test passes.

s22, if the target test case is executed by the second device cluster for the predetermined number of times and the predetermined number of times are all executed failed, the disaster recovery test result is that the test fails.

The preset number of times may be set according to actual conditions, for example, the preset number of times may be 1 time, 2 times, 5 times, and the like. The successful execution refers to: and completely executing the target test case, popping up no interrupt or error prompt in the executing process, and matching the log data and the result data which are searched in the database corresponding to the second equipment cluster and correspond to the log data and the result data (generated by executing the target test case) with the expected result stored in the database corresponding to the first equipment cluster. The execution failure may be: the target test case is not completely executed, or an interruption or error prompt is popped in the execution process, or corresponding log data and result data are not searched in a database corresponding to the second equipment cluster; or the log data and the result data stored in the database corresponding to the second device cluster do not match the expected result stored in the database corresponding to the first device cluster.

Further, after the step s22, the following steps s23-s24 are included:

s23, in the process that the target test case is executed for the preset number of times, if the partial number of times is not successfully executed, obtaining a failure reason, where the failure reason includes: testing for environmental or non-environmental reasons;

s24, if the failure reason is not the environmental reason, outputting improvement prompt information, and the improvement prompt information is used for improving the disaster recovery test system.

In steps s23-s24, in the process of executing the target test case for the preset number of times, if there is a part of times that is not successfully executed, for example: the target test case is executed 5 times, wherein 3 times of the target test case are not executed successfully, and only 2 times of the target test case are executed successfully, which indicates that the failure reasons need to be checked, wherein the failure reasons include test environment reasons or non-environment reasons. The test environment cause refers to external interference, for example: the disaster tolerance tests on a plurality of disaster tolerance systems can mutually influence each other; or, if the failure cause is detected as the test environment cause, the accuracy of the disaster tolerance test result can be ensured by adjusting the preset times; and if the failure reason is detected to be non-environmental reason, it indicates that the performance of the disaster tolerance test system itself has problems, for example: the disaster tolerance test system has the problems of low stability, low compatibility and the like, and at the moment, improvement prompt information is output and used for prompting a tester or a worker to improve the disaster tolerance test system so as to improve the performance of the disaster tolerance test system and ensure the accuracy of the disaster tolerance test process.

And S207, receiving a back-cut test instruction, wherein the back-cut test instruction carries an indication message for indicating the first equipment cluster to recover from the fault.

And S208, canceling the isolation of the first equipment cluster.

And S209, triggering the first equipment cluster to execute the target test case to obtain a back-cut test result.

Steps S207 to S209 describe a procedure of performing a switchback test on the disaster recovery system, which is used to verify whether the disaster recovery system has a switchback function. Specifically, a user (such as a tester) may modify the test requirements in a human-computer interaction interface provided by the service device, including modifying a fault list of the disaster recovery system, and removing the identities of all sets for recovering from the fault list, where the identity of set1 in this example is removed from the fault list, that is, the identity of set1 is not included in the fault list. And then, a switchback test instruction is initiated, wherein the switchback test instruction carries an indication message that the set1 has recovered the fault, the indication message can be a fault list, and since the set1 is not included in the fault list, the fault list is analyzed to know that the set1 has recovered the fault, so that the isolation of the set1 can be cancelled. Specifically, if the first device cluster is isolated by disconnecting the network during the disaster recovery test, set1 may be reconnected to the network to cancel the isolation of the first device cluster, for example, the IP data of set1 may be removed from the IP list of the firewall, so that set1 may work normally. If set1 is isolated by disconnecting the working power supply in the disaster recovery test process, set1 can be connected with the working power supply again to cancel the isolation of the set 1. Then, trigger set1 executes the target test case to obtain the back-cut test result, where the trigger may include: firstly, sending a recovery fault notification carrying a set1 identifier to a peer second device cluster (set2 or set11), wherein the recovery fault notification is used for enabling the peer second device cluster to explicitly recover the set1 fault and indicating the second device cluster to stop executing set1 service; and then the target test case is sent to set1, and set1 is controlled to execute the target test case to obtain a back-cut test result. Further, if the back-switch test result is that the back-switch test result is passed, which indicates that the set1 has recovered the fault, the service of the set1 can be successfully switched back to the set1 and successfully executed, and the disaster recovery system has a back-switch function; if the result of the back-switch test is failed, which indicates that after the set1 recovers the fault, the service of the set1 cannot be successfully switched back to the set1 or cannot be successfully executed, and the disaster recovery system does not have the back-switch function.

In the embodiment of the invention, when the fault list comprises the identifier of the first equipment cluster, the service equipment can automatically acquire the associated data of the first equipment cluster, automatically isolate the first equipment cluster according to the associated data, and automatically generate the target test case, if the fault list does not comprise the identifier of the second city-sharing equipment cluster, the second city-sharing equipment cluster is triggered to execute the target test case to obtain the disaster tolerance test result, so as to realize the same-city switching test (namely the same-city disaster tolerance test), and the disaster tolerance test process embodies whether the second city-sharing equipment cluster can normally execute the service processing after the first equipment cluster can not normally work and the service is switched to the second city-sharing equipment cluster, so that whether the disaster tolerance system has better same-city disaster tolerance performance or not is reflected; if the fault list includes the identifier of the second city-crossing device cluster, triggering the second city-crossing device cluster to execute the target test case to obtain a disaster tolerance test result, so as to implement a cross-city switching test (i.e., a cross-city disaster tolerance test), wherein the disaster tolerance test process embodies whether the second city-crossing device cluster can normally execute service processing after the first device cluster and the second city-crossing device cluster can not normally work and the service is switched to the second city-crossing device cluster, thereby reflecting whether the disaster tolerance system has better cross-city disaster tolerance performance.

After the disaster recovery test, the isolation of the first device cluster may be cancelled, and the first device cluster is triggered to execute the target test case to obtain the switchback test result, where this switchback test process embodies whether the service of the first device cluster can be successfully switched back to the device cluster and can be successfully executed when the first device cluster recovers the fault. The disaster tolerance test process and the back-cut test process can automatically and intelligently realize the test of the disaster tolerance system without manual participation, and the test efficiency is higher and the practicability is high.

The embodiment of the invention provides another disaster tolerance testing method which is applied to a disaster tolerance system, wherein the disaster tolerance system at least comprises set1, a third device cluster (set 3 for short), a fifth device cluster (set 5 for short), a second device cluster (same-city-peer set2 and cross-city-peer set11) which is equivalent to set1, a fourth device cluster (same-city-peer set4 and cross-city-peer set9) which is equivalent to set3, and a sixth device cluster (same-city-peer set6 and cross-city-peer set8) which is equivalent to set 5. Referring to fig. 4, the disaster recovery testing method includes:

s301, receiving a fault list, wherein the fault list comprises identifications of a plurality of device clusters.

In the embodiment of the present invention, a service device for performing a disaster recovery test may provide a human-computer interaction interface, and a user (e.g., a tester) may set a test requirement in the human-computer interaction interface, including setting a fault list of a disaster recovery system, specifically, may add identifiers of multiple faulty device clusters to the fault list, for example, may add identifiers of one or more groups of mutually equivalent device clusters in the same city to the fault list, and/or may add identifiers of multiple device clusters without a peer relationship to the fault list; the fault list comprises identifications of all sets generating faults, and the fault list comprises identifications of set1, set2, set3 and set 5; and then, initiating a disaster tolerance test instruction, wherein the disaster tolerance test instruction carries a fault list.

S302, isolating each equipment cluster of the fault list.

Each equipment cluster can be isolated by disconnecting the working power supply of each equipment cluster in the fault list or disconnecting the network connection; for example: the IP data of set1, the IP data of set2, the IP data of set3 and the identity of set5 may all be added to the IP list of the firewall to isolate set1, set2, set3 and set 5.

And S303, sending a configuration notification to all normal equipment clusters, wherein the configuration notification carries the identifier of each fault equipment cluster in the fault list.

In order to improve the compatibility of the disaster recovery system, a configuration notification can be sent to all normal sets in the disaster recovery system except all fault sets in the fault list, so that all other normal sets can clearly indicate which sets in the fault list have faults, and when a service request sent to the peer set of the fault set is forwarded to other normal sets due to accidents (such as calling errors), other normal sets can also perform quick response for executing the service, thereby improving the compatibility of the disaster recovery system.

S304, analyzing the equipment cluster needing the cross-city switching test according to the fault list, and determining the cluster equipment needing the same-city switching test.

The fault list comprises an identifier of set1 and an identifier of set2, and set1 and set2 are mutually same-city peer sets, which indicates that neither the same-city peer sets of set1 and set1 can work normally, and it is determined that the service of set1 needs to be switched to cross-city peer set11, and similarly, the service of set2 needs to be switched to cross-city peer set12, so that a cross-city switching test needs to be performed. The process proceeds to step S305 to step S307.

The fault list also includes the identifiers of set3 and set5, but the fault list does not include the identifier of set4 of the same city peer of set3, so that when set3 fails, the service of set3 can be switched to the set4 of the same city peer, and the same city switching test is determined to be needed. Similarly, the identity of set6 of the same city peer of set5 is not included in the fault list, so set5 requires the same city handover test to be performed. Proceeding to execute steps S308 to S310, in the embodiment of the present invention, after the execution of steps S305 to S307 is completed, steps S308 to S310 may be executed, or after the execution of steps S308 to S310 is completed, steps S305 to S307 may be executed.

S305, determining that the first equipment cluster and the second equipment cluster need to be subjected to cross-city switching test.

S306, generating a first test case according to the associated data of the first equipment cluster, and generating a test case according to the associated data of the second equipment cluster.

S307, triggering the cross-city peer device cluster of the first device cluster to execute the first test case to obtain a first disaster recovery test result, and triggering the cross-city peer device cluster of the second device cluster to execute the second test case to obtain a second disaster recovery test result.

The cross-city switching test of steps S305 to S307 may be performed in a serial manner, specifically: acquiring the associated data of set1 to generate a first test case, and triggering set11 to execute the first test case to obtain a first disaster recovery test result; and then acquiring the associated data of the set2 to generate a second test case, and triggering the set12 to execute the second test case to obtain a second disaster recovery test result. The serial mode is adopted to reduce the test error rate and simplify the disaster tolerance test process.

And S308, determining that the third equipment cluster and the fifth equipment cluster need to be subjected to the same city switching test.

S309, generating a third test case according to the associated data of the third equipment cluster, and generating a fourth test case according to the associated data of the fifth equipment cluster.

And S310, triggering the same-city peer-to-peer device cluster (set4) of the third device cluster to execute and generate a third test case to obtain a third disaster recovery test result, and triggering the same-city peer-to-peer device cluster (set6) of the fifth device cluster to execute and generate a fourth test case to obtain a fourth disaster recovery test result.

The city switching test of steps S309-S310 may be performed in a serial manner, specifically: acquiring the associated data of set3 to generate a third test case, and triggering set4 to execute the third test case to obtain a third disaster recovery test result; and then acquiring the associated data of the set5 to generate a fourth test case, and triggering the set6 to execute the fourth test case to obtain a fourth disaster recovery test result. The serial mode is adopted to reduce the test error rate and simplify the disaster tolerance test process.

S311, receiving a switchback test instruction, where the switchback test instruction carries an identifier of the fault-recovered device cluster, and the switchback test instruction may include an identifier of the first device cluster, an identifier of the second device cluster, an identifier of the third device cluster, and an identifier of the fifth device cluster.

And S312, canceling the isolation of each equipment cluster for recovering the fault. Namely, the isolation of the first device cluster, the second device cluster, the third device cluster and the fifth device cluster is cancelled.

And S313, triggering the device cluster with the recovery fault to execute the corresponding test case to obtain the back-cut test result.

The switchback test of steps S312-S313 may be performed in a serial manner, specifically, triggering set1 to execute the first test case to obtain the first switchback test result. After the set1 finishes executing the first test case, triggering the set2 to execute a second test case to obtain a second backswitching test result; and so on until all device clusters complete the switchback test. The serial mode is adopted to reduce the test error rate and simplify the disaster tolerance test process.

In the embodiment of the invention, when a plurality of equipment clusters need to carry out the cross-city switching test and/or the same-city switching test, the cross-city switching test and/or the same-city switching test can be realized in a serial mode, so that the error rate of the raw test can be reduced, and the disaster recovery test process can be simplified. When a plurality of equipment clusters need to be subjected to switchback test, the switchback test is realized in a serial mode, so that the error rate of the live test can be reduced, and the disaster tolerance test process is simplified.

When the disaster recovery system passes the test by the disaster recovery test method shown in fig. 2, fig. 3, and fig. 4, it is described that the disaster recovery system has disaster recovery performance, and the disaster recovery system can be used in a scenario where a batch of transactions need to be processed, for example, in a financial application scenario, specifically including a scenario of payment application or stock fund transaction; the method can also be applied to multimedia application scenes, specifically including video playing scenes and the like; the disaster recovery system can also be applied to entertainment application scenes, specifically including game application scenes and the like, and can also be applied to other scenes, and fig. 5 illustrates an example in which the disaster recovery system is applied to a payment application scene.

Referring to fig. 5, the payment scenario includes a terminal 10 initiating a payment request, and a disaster recovery system providing a background payment service for the payment request, where the disaster recovery system at least includes set1 and its peer set (set2 or set11), and a specific manner of the disaster recovery system for providing a payment service includes:

s401, the terminal 10 sends a payment request to the first device cluster.

In the embodiment of the invention, under the scene that online consumption (such as online shopping and communication recharging) or offline consumption (such as taxi taking and lodging) of a user needs online payment, a terminal can send a payment request to set1 through a payment-related application on the terminal, wherein the payment request comprises information such as identification of set1, a payment password or payment amount. Here, the payment-related application may refer to an instant messaging application of a portable payment function, such as WeChat, QQ, and the like, may be a payment application app dedicated to payment, and may be a browser that can generate a payment page.

For example, as shown in fig. 6, as a specific flowchart of the payment method implemented in the payment application scenario of fig. 5, when a user places an order to purchase a commodity on the internet, order information, such as an order number 123, a payment amount 123, and a payment method for the user to select is generated on an order page, the payment method may include a WeChat payment method, a QQ payment method, and a Payment treasure payment method, if the user selects WeChat payment, a terminal displays a payment page, a name of a merchant (i.e., a platform for providing the commodity) for payment is displayed on the payment page, the payment amount is paid, a payment option is confirmed, if the user clicks the payment option to confirm, the user inputs a payment password, and the terminal executes step S601 to send a payment request to set 1.

S402, if set1 fails, the payment request is forwarded to peer set (set2 or set 11).

With reference to fig. 6, if set1 fails, the service device may send a configuration notification of the failure of set1 to each normal set, and perform step S602 to automatically forward the payment request sent to set1 to peer set (set2 or set 11). In particular, if set2 does not fail at the same time, it is preferable to forward the payment request to set2 to guarantee the response rate; if set2 fails simultaneously with set1, the payment request is forwarded to set11 for processing.

S403, the second device cluster sends a payment response message to the terminal 10.

The peer set (set2 or set11) receives the configuration notification that the set1 has a fault, determines that the set1 has a fault, and timely responds to the payment request, for example, the user is authenticated according to the payment password, if the authentication is passed, whether the payment amount meets the condition is judged, if the condition is met, the peer set (set2 or set11) executes the payment operation and sends a message that the payment is successful to the terminal 10, and if the authentication is not passed or the payment amount does not meet the condition, the peer set sends a message that the payment is failed to the terminal 10. Here, the condition that the payment amount satisfies may mean that the payment amount is less than a preset amount and/or the payment amount is less than the remaining amount of the account.

For example, taking fig. 6 as an example, the maximum payment amount of the user is 1000, when the peer set (set2 or set11) receives a payment request of the user, the identity of the user is verified according to the payment password, when the verification is successful, the obtained payment amount is 123, it is determined that the payment amount is smaller than the maximum payment amount, the payment operation is performed, the step S603 is performed, a message that the payment is successful is returned to the terminal 10, and the terminal 10 displays that the payment is successful on the display interface.

In the embodiment of the invention, after the disaster recovery test of the disaster recovery system is passed, when the first equipment cluster fails, the first equipment cluster forwards the received payment request to the second equipment cluster, and the second equipment cluster responds to the payment request, so that the occurrence of an event that the equipment cluster fails to cause payment failure can be avoided, and a real-time service requirement is provided for a user.

Based on the description of the disaster tolerance test method, an embodiment of the present invention provides a disaster tolerance test device, please refer to fig. 7, where the disaster tolerance test device is applied to a disaster tolerance test system, the disaster tolerance system includes a first device cluster and a second device cluster that is equivalent to the first device cluster, and the disaster tolerance test device includes:

an obtaining module 701, configured to obtain associated data of the first device cluster, where the associated data includes IP data, service data, and database information.

An isolating module 702, configured to isolate the first device cluster according to the associated data, and generate a target test case.

A triggering module 703, configured to trigger the second device cluster to execute the target test case to obtain a disaster tolerance test result.

Optionally, the obtaining module 701 is specifically configured to receive a disaster tolerance test instruction, where the disaster tolerance test instruction carries a fault list of the disaster tolerance system, and the fault list includes an identifier of the first device cluster.

Optionally, the switchback module 704 is configured to receive a switchback test instruction, where the switchback test instruction carries an indication message used for indicating that the first device cluster recovers from the fault; canceling isolation of the first device cluster; and triggering the first equipment cluster to execute the target test case to obtain a back-cut test result.

Optionally, the isolation module 702 is specifically configured to add the IP data of the first device cluster to a firewall to disconnect the network connection of the first device cluster; acquiring a preset service automation case; and transmitting the associated data of the first equipment cluster as a request parameter to the business automation case to generate the target test case.

Optionally, the triggering module 703 is specifically configured to send a failure configuration notification to the second device cluster, where the failure configuration notification carries the identifier of the first device cluster; sending the target test case to the second equipment cluster, and controlling the second equipment cluster to execute the target test case; and obtaining a disaster tolerance test result according to the execution result of the target test case on the second equipment cluster.

Optionally, the triggering module 703 is specifically configured to, if the target test case is executed by the second device cluster for a preset number of times and at least one execution is successful, determine that the disaster tolerance test result is that the test passes; and if the target test case is executed by the second equipment cluster for the preset times, and the preset times are all failed to be executed, the disaster tolerance test result is that the test fails.

Wherein, the execution success means that the execution result matches the expected result.

Optionally, the obtaining module 701 is further configured to, in the process that the target test case is executed for the preset number of times, if part of the number of times is not successfully executed, obtain a failure reason, where the failure reason includes: testing for environmental or non-environmental reasons.

Optionally, the output module 705 is configured to output an improvement prompt message if the failure reason is a non-environmental reason, where the improvement prompt message is used to improve the disaster recovery testing system.

The second device cluster refers to a second city-sharing device cluster which is in the same area range as the first device cluster, or a second cross-city device cluster which is in a different area range from the first device cluster. If the fault list does not include the identifier of the second city-shared device cluster, the second device cluster is the second city-shared device cluster; and if the fault list further comprises the identifier of the second city-shared device cluster, the second device cluster is the second cross-city device cluster.

In the embodiment of the invention, the test device can automatically isolate the failed equipment cluster according to the associated data of the equipment cluster, automatically generate the target test case, and execute the target test case by the equipment cluster which is equivalent to the failed equipment cluster to obtain the disaster tolerance test result, thereby automatically realizing the test of the disaster tolerance system and leading the test process to be more automatic and intelligent.

Based on the description of the disaster tolerance test method and the payment method, an embodiment of the present invention provides a payment apparatus, please refer to fig. 8, where the payment apparatus is applied to a disaster tolerance test system, the disaster tolerance system includes a first device cluster and a second device cluster that is equivalent to the first device cluster, and the disaster tolerance system adopts the disaster tolerance test method described in fig. 2, fig. 3, and fig. 4 to perform a test and passes the test; the payment device includes:

a receiving module 801, configured to receive a payment request, where the payment request carries an identifier of the first device cluster.

A forwarding module 802, configured to forward the payment request to the second device cluster if the first device cluster fails.

A triggering module 803, configured to trigger the second device cluster to respond to the payment request.

In the embodiment of the invention, after the disaster recovery test of the disaster recovery system is passed and when the first equipment cluster fails, the payment device in the disaster recovery system can forward the payment request received by the first equipment cluster to the second equipment cluster, and the second equipment cluster responds to the payment request, so that the occurrence of an event that the equipment cluster fails to cause payment failure can be avoided, and a real-time service requirement is provided for a user.

Based on the description of the disaster tolerance testing device and the payment device, the embodiment of the invention provides a service device, which is applied to a disaster tolerance system, wherein the disaster tolerance system at least comprises a first device cluster and a second device cluster which is equivalent to the first device cluster; referring to fig. 9, the service apparatus includes: a processor 901, an input interface 902, an output interface 903, and a computer storage medium 904.

The computer storage media 904 may represent storage devices, including volatile computer storage media (volatile memory), such as random-access computer storage media (RAM); the computer storage medium may also include non-volatile computer storage media (non-volatile memory), such as flash memory, Hard Disk Drive (HDD), or solid-state drive (SSD); computer storage media 904 may also include combinations of the above-described types of computer storage media.

The input interface 902 may be used to input data to be processed to the processor 901. In one embodiment, the input interface 902 may include a plurality of independent interfaces, such as an ethernet interface, an LCD (Liquid Crystal Display) interface, and the like, which are respectively responsible for communication of data input by different peripheral devices to the processor 901.

The output interface 903 may be used to output data to other peripheral devices connected to the terminal, and may output a processing result of the processor 901. Output interface 903 may also include a plurality of separate interfaces, such as an ethernet interface, a camera interface, etc., responsible for the communication of data output by processor 901 to various peripheral devices.

In one embodiment, the Output interface 903 and the Input interface 902 may be General Purpose Input Output (GPIO) interfaces.

The processor 901 is operable to read and execute computer instructions. In one embodiment, the processor 701 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof. The PLD may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), a General Array Logic (GAL), or any combination thereof.

The computer storage media 904 is also used to store one or more program instructions; the program instructions include first instructions and/or second instructions. In an embodiment, the processor 901 may be capable of executing a disaster tolerance test procedure on a disaster tolerance system to provide a disaster tolerance test service when invoking the first instruction, and specifically, the processor 901 invokes the first instruction to perform the following steps:

Optionally, the processor 901 may call the first instruction to perform the following steps:

and receiving a disaster tolerance test instruction, wherein the disaster tolerance test instruction carries a fault list of the disaster tolerance system, and the fault list comprises an identifier of the first equipment cluster.

receiving a back-cut test instruction, wherein the back-cut test instruction carries an indication message for indicating the first equipment cluster to recover from the fault;

canceling isolation of the first device cluster;

and triggering the first equipment cluster to execute the target test case to obtain a back-cut test result.

adding the IP data of the first device cluster to a firewall to disconnect the network connection of the first device cluster;

acquiring a preset service automation case;

and transmitting the associated data of the first equipment cluster as a request parameter to the business automation case to generate the target test case.

sending a fault configuration notification to the second equipment cluster, wherein the fault configuration notification carries the identifier of the first equipment cluster;

sending the target test case to the second equipment cluster, and controlling the second equipment cluster to execute the target test case;

and obtaining a disaster tolerance test result according to the execution result of the target test case on the second equipment cluster.

if the target test case is executed by the second equipment cluster for a preset number of times and at least one execution is successful, the disaster tolerance test result is that the test is passed;

and if the target test case is executed by the second equipment cluster for the preset times, and the preset times are all failed to be executed, the disaster tolerance test result is that the test fails.

the second device cluster is a second city-sharing device cluster which is in the same area range as the first device cluster, or a second city-crossing device cluster which is in a different area range from the first device cluster;

if the fault list does not include the identifier of the second city-shared device cluster, the second device cluster is the second city-shared device cluster;

and if the fault list further comprises the identifier of the second city-shared device cluster, the second device cluster is the second cross-city device cluster.

In another embodiment, the processor 901 may be capable of executing a regulation and control process of the disaster recovery system to provide a payment processing service when invoking the second instruction, specifically, the processor 901 invokes the second instruction to perform the following steps:

triggering the second device cluster to respond to the payment request.

It should also be noted that the functions corresponding to the service device of the present invention may be implemented by hardware design, software design, or a combination of hardware and software, which is not limited herein.

Embodiments of the present invention also provide a computer program product, which includes a computer storage medium storing a computer program, and when the computer program product runs on a computer, the computer executes part or all of the steps of any one of the methods for processing web page data as described in the above method embodiments. In one embodiment, the computer program product may be a software installation package.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium and can include the processes of the embodiments of the methods described above when the computer program is executed. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like.

The above disclosure is intended to be illustrative of only some embodiments of the invention, and is not intended to limit the scope of the invention.

Claims

1. A disaster tolerance test method is applied to a disaster tolerance system, wherein the disaster tolerance system at least comprises a first equipment cluster and a second equipment cluster which is equivalent to the first equipment cluster; the disaster recovery testing method is characterized by comprising the following steps:

acquiring associated data of the first equipment cluster, wherein the associated data comprises IP data, service data and database information; the first equipment cluster and the second equipment cluster are used for processing different services;

acquiring a preset service automation case;

transmitting the associated data of the first equipment cluster as a request parameter to the business automation case to generate a target test case; the target test case is used for judging whether the second equipment cluster can process the service of the first equipment cluster when processing the service of the second equipment cluster;

2. The method of claim 1, wherein after triggering the second device cluster to execute the target test case to obtain the disaster recovery test result, the method further comprises:

canceling isolation of the first device cluster;

3. The method of claim 1, wherein the triggering the second device cluster to execute the target test case to obtain a disaster recovery test result comprises:

sending a fault configuration notification to the second equipment cluster, wherein the fault configuration notification carries an identifier of the first equipment cluster;

4. The method of claim 3, wherein obtaining the disaster recovery test result according to the execution result of the target test case on the second device cluster comprises:

if the target test case is executed by the second equipment cluster for the preset times, and the preset times are all failed to be executed, the disaster tolerance test result is that the test fails;

5. A payment method is applied to a disaster recovery system, wherein the disaster recovery system at least comprises a first device cluster and a second device cluster which is equivalent to the first device cluster; the disaster recovery system adopts the disaster recovery test method of any one of claims 1 to 4 to test and pass the test; the payment method comprises the following steps:

triggering the second device cluster to respond to the payment request.

6. A disaster tolerance testing device is applied to a disaster tolerance system, wherein the disaster tolerance system at least comprises a first equipment cluster and a second equipment cluster which is equivalent to the first equipment cluster; it is characterized in that the disaster recovery testing device comprises:

the acquisition module is used for acquiring the associated data of the first equipment cluster, wherein the associated data comprises IP data, service data and database information; the first equipment cluster and the second equipment cluster are used for processing different services;

the isolation module is used for adding the IP data of the first equipment cluster to a firewall so as to disconnect the network connection of the first equipment cluster; acquiring a preset service automation case; transmitting the associated data of the first equipment cluster as a request parameter to the business automation case to generate a target test case; the target test case is used for judging whether the second equipment cluster can process the service of the first equipment cluster when processing the service of the second equipment cluster;

7. A payment device is applied to a disaster recovery system, wherein the disaster recovery system at least comprises a first equipment cluster and a second equipment cluster which is equivalent to the first equipment cluster; the disaster recovery system is characterized in that the disaster recovery system adopts the disaster recovery test method of any one of claims 1 to 4 to test and pass the test; the payment device includes:

8. A computer storage medium having one or more first instructions stored thereon, the one or more first instructions adapted to be loaded by a processor and to perform the disaster recovery testing method of any one of claims 1 to 4; alternatively, the computer storage medium stores one or more second instructions adapted to be loaded by a processor and to perform the payment method of claim 5.

9. A service device, comprising:

a computer storage medium storing one or more first instructions adapted to be loaded by a processor and to perform the disaster recovery testing method of any one of claims 1-4; alternatively, the computer storage medium stores one or more second instructions adapted to be loaded by a processor and to perform the payment method of claim 5.