Disaster recovery processing method and apparatus, and electronic device

Abstract

The application provides a disaster recovery processing method and device and electronic equipment, and relates to the technical field of big data. The method comprises the following steps: acquiring configuration information of at least one proxy API in a service bus, wherein the configuration information comprises a main center API and a backup center API corresponding to the proxy API; determining whether the main center is in a fault state based on communication data between the service bus and the main center; and switching a routing target API of the at least one proxy API to the backup center API corresponding to the at least one proxy API in the case that the main center is in the fault state. Thus, the main center API and the backup center API corresponding to the proxy API are configured in the service bus, the routing target API of the proxy API is switched to the backup center API when the main center fails, the RTO of the fault switching is shortened, and the service provided externally can be ensured to be uninterrupted.

Description

Technical Field

[0001] This application relates to the field of big data technology, and in particular to a disaster recovery method, apparatus and electronic equipment. Background Technology

[0002] Currently, in disaster recovery scenarios, a primary center and a backup center can be set up. The primary center and the backup center can provide the same services. The primary center provides the services, while the backup center can provide services when the primary center fails.

[0003] In related technologies, the switch between the primary and backup centers adopts the configuration DNS (Domain Name System) mode. When the primary center fails, the DNS resolution is directed to the backup center. However, modifying the DNS resolution takes a long time, resulting in a long RTO (Recovery Time Object) for failover and excessive service interruption time. Summary of the Invention

[0004] The first aspect of this application proposes a disaster recovery method applied to a service bus, comprising: obtaining configuration information of at least one proxy API in the service bus, the configuration information including a primary center API and a backup center API corresponding to the proxy API; determining whether the primary center is in a fault state based on communication data between the service bus and the primary center; and, if the primary center is in a fault state, switching the routing target API of at least one of the proxy APIs to the backup center API corresponding to at least one of the proxy APIs.

[0005] In some embodiments, determining whether the main center is in a fault state based on the communication data between the service bus and the main center includes: receiving an event reported by the main center; and determining that the main center is in a fault state if the event is a fault event of the main center.

[0006] In some embodiments, determining whether the main center is in a fault state based on the communication data between the service bus and the main center includes: determining that the main center is in a fault state when the main center meets at least one of the following conditions: the API service address of the main center is not connected to the network; the API error rate of the main center is higher than a first error rate threshold; the health check result of the main center is abnormal.

[0007] In some embodiments, the method further includes: when the main center switches from a fault state to a normal state, switching the routing target API of at least one of the proxy APIs to the main center API corresponding to at least one of the proxy APIs.

[0008] In some embodiments, the method further includes: when the main center is in a normal state, determining whether at least one of the main center APIs in the main center is in a fault state; when there is a first main center API in the main center that is in a fault state, obtaining a first proxy API corresponding to the first main center API; and switching the routing target API of the first proxy API to the backup center API corresponding to the first proxy API.

[0009] In some embodiments, determining whether at least one of the main center APIs in the main center is in a fault state includes: receiving an event reported by the main center; and determining that the first main center API is in a fault state if the event is a first main center API fault event.

[0010] In some embodiments, determining whether at least one of the main center APIs in the main center is in a fault state includes: determining that the main center API is in a fault state when the main center API meets at least one of the following conditions: the response status code of the main center API does not match a specified status code; the response duration of the main center API is greater than a preset duration threshold; the response header of the main center API does not match a specified response header; the response body of the main center API does not match a specified response body; the service address of the main center API is not network accessible; the error rate of the main center API is higher than a second error rate threshold.

[0011] In some embodiments, the method further includes: when the first main center API switches from a fault state to a normal state, switching the routing target API of the first proxy API to the main center API corresponding to the first proxy API.

[0012] In some embodiments, before determining whether the main center is in a fault state, the method further includes: determining whether the current state is a drill mode; if the state is a drill mode, obtaining the current drill switching method; and switching at least one routing target API of the proxy API according to the drill switching method.

[0013] In some embodiments, the drill switching method includes at least one of the following: switching the routing target API of all proxy APIs to the backup center API corresponding to the proxy API; switching the routing target API of all proxy APIs to the main center API corresponding to the proxy API; switching the routing target API of at least one of the proxy APIs to the backup center API corresponding to the second proxy API; and switching the routing target API of the second proxy API to the main center API corresponding to the second proxy API.

[0014] In some embodiments, the method further includes: receiving a proxy API call request from a client, wherein the proxy API call request includes an identifier of a third proxy API to be called; determining a routing target API of the third proxy API; sending a call request to the routing target API to obtain a call result of the routing target API; and returning the call result to the client.

[0015] A second aspect of this application provides a disaster recovery processing device applied to a service bus, comprising: a first acquisition module, configured to acquire configuration information of at least one proxy API in the service bus, the configuration information including a primary center API and a backup center API corresponding to the proxy API; a first determination module, configured to determine whether the primary center is in a fault state based on communication data between the service bus and the primary center; and a first switching module, configured to switch the routing target API of at least one of the proxy APIs to the backup center API corresponding to at least one of the proxy APIs when the primary center is in a fault state.

[0016] In some embodiments, the first determining module is specifically configured to receive an event reported by the main center; and, in the case that the event is a main center failure event, determine that the main center is in a failure state.

[0017] In some embodiments, the first determining module is specifically configured to determine that the main center is in a fault state when the main center meets at least one of the following conditions: the API service address of the main center is not connected to the network; the API error rate of the main center is higher than a first error rate threshold; or the health detection result of the main center is abnormal.

[0018] In some embodiments, the apparatus further includes: a second switching module, configured to switch the routing target API of at least one of the proxy APIs to the main center API corresponding to at least one of the proxy APIs when the main center switches from a fault state to a normal state.

[0019] In some embodiments, the apparatus further includes: a second determining module, a second acquiring module, and a third switching module; the second determining module is configured to determine whether at least one of the main center APIs in the main center is in a fault state when the main center is in a normal state; the second acquiring module is configured to acquire a first proxy API corresponding to the first main center API when there is a first main center API in a fault state in the main center; the third switching module is configured to switch the routing target API of the first proxy API to the backup center API corresponding to the first proxy API.

[0020] In some embodiments, the second determining module is specifically configured to receive an event reported by the main center; and, if the event is a first main center API failure event, determine that the first main center API is in a failure state.

[0021] In some embodiments, the second determining module is specifically used to determine that the main center API is in a fault state when the main center API meets at least one of the following conditions: the response status code of the main center API does not match a specified status code; the response duration of the main center API is greater than a preset duration threshold; the response header of the main center API does not match a specified response header; the response body of the main center API does not match a specified response body; the service address network of the main center API is unreachable; the error rate of the main center API is higher than a second error rate threshold.

[0022] In some embodiments, the apparatus further includes a fourth switching module, configured to switch the routing target API of the first proxy API to the main center API corresponding to the first proxy API when the first main center API switches from a fault state to a normal state.

[0023] In some embodiments, before determining whether the main center is in a fault state, the device further includes: a third determining module and a fifth switching module; the third determining module is used to determine whether the current state is a drill mode; if the drill mode is in the case, to obtain the current drill switching method; the fifth switching module is used to perform switching processing on at least one routing target API of the proxy API according to the drill switching method.

[0024] In some embodiments, the drill switching method includes at least one of the following: switching the routing target API of all proxy APIs to the backup center API corresponding to the proxy API; switching the routing target API of all proxy APIs to the main center API corresponding to the proxy API; switching the routing target API of at least one of the proxy APIs to the backup center API corresponding to the second proxy API; and switching the routing target API of the second proxy API to the main center API corresponding to the second proxy API.

[0025] In some embodiments, the apparatus further includes: a receiving module, a fourth determining module, a processing module, and a returning module; the receiving module is configured to receive a proxy API call request from a client, wherein the proxy API call request includes an identifier of a third proxy API to be called; the fourth determining module is configured to determine the routing target API of the third proxy API; the processing module is configured to send a call request to the routing target API to obtain the call result of the routing target API; and the returning module is configured to return the call result to the client.

[0026] A third aspect of this application provides a disaster recovery system, the system comprising: a service bus, a primary center and a backup center connected to the service bus; at least one proxy API is provided on the service bus; a primary center API corresponding to the proxy API is provided on the primary center; a backup center API corresponding to the proxy API is provided on the backup center; the service bus is used to execute the disaster recovery method as described in the first aspect.

[0027] A fourth aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the disaster recovery processing method as described in the first aspect.

[0028] The fifth aspect of this application proposes a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the disaster recovery processing method as described in the first aspect.

[0029] The technical solutions provided in this application have the following beneficial effects:

[0030] By acquiring the configuration information of at least one proxy API in the service bus, including the primary center API and backup center API corresponding to the proxy API, and based on the communication data between the service bus and the primary center, it is determined whether the primary center is in a fault state. If the primary center is in a fault state, the routing target API of at least one proxy API is switched to the backup center API corresponding to the at least one proxy API. Therefore, configuring the primary center API and backup center API corresponding to the proxy API in the service bus, and switching the routing target API of the proxy API to the backup center API when the primary center fails, not only shortens the failover RTO but also ensures uninterrupted service provision. Attached Figure Description

[0031] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0032] Figure 1 A schematic flowchart illustrating a disaster recovery method provided in an embodiment of this application;

[0033] Figure 2 This is a schematic diagram of the switchover process in the event of a main data center failure.

[0034] Figure 3 A flowchart illustrating another disaster recovery method provided in this application embodiment;

[0035] Figure 4 A flowchart illustrating the process of determining whether at least one main center API in the main center is in a faulty state;

[0036] Figure 5 A flowchart illustrating another disaster recovery method provided in this application embodiment;

[0037] Figure 6 A flowchart illustrating another disaster recovery method provided in this application embodiment;

[0038] Figure 7 A flowchart illustrating the process of determining whether the main center is in a faulty state;

[0039] Figure 8 This is a schematic diagram of a disaster recovery processing device according to an embodiment of this application;

[0040] Figure 9 A disaster recovery system provided in the embodiments of this application;

[0041] Figure 10 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0042] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0043] To address the aforementioned issues, embodiments of this application provide a disaster recovery method, apparatus, and electronic device.

[0044] The following is combined with Figure 1 This application provides a detailed description of the disaster recovery methods provided.

[0045] Figure 1 This is a flowchart illustrating a disaster recovery method provided in an embodiment of this application.

[0046] The execution subject of this application embodiment is the disaster recovery processing device provided in this application. The disaster recovery processing device can be an electronic device, or can be configured in an electronic device to perform disaster recovery processing functions. In this application embodiment, the execution subject is a service bus as an example for description.

[0047] like Figure 1 As shown, this disaster recovery method includes the following steps:

[0048] Step 101: Obtain the configuration information of at least one proxy API in the service bus. The configuration information includes the main center API and the backup center API corresponding to the proxy API.

[0049] The number of proxy APIs can be one or more; there is no specific limit here.

[0050] In some embodiments, the configuration information is pre-configured by the service bus. The number of primary center APIs can be one or more; the number of backup center APIs can be one or more, and no specific limitation is made here.

[0051] The proxy API and the main center API have a one-to-one correspondence; the proxy API and the backup center API also have a one-to-one correspondence.

[0052] Step 102: Based on the communication data between the service bus and the main center, determine whether the main center is in a fault state.

[0053] In some embodiments, in one implementation, the service bus can determine whether the main center is in a fault state based on the information reported by the main center; in another implementation, the service bus can monitor the main center and determine whether the main center is in a fault state based on the monitoring results.

[0054] Step 103: In the event that the primary center is in a faulty state, switch the routing target API of at least one proxy API to the backup center API corresponding to at least one proxy API.

[0055] The disaster recovery method in this application embodiment obtains configuration information of at least one proxy API in the service bus, including the primary center API and backup center API corresponding to the proxy API; determines whether the primary center is in a fault state based on communication data between the service bus and the primary center; and switches the routing target API of at least one proxy API to the backup center API corresponding to the at least one proxy API when the primary center is in a fault state. Therefore, by configuring the primary center API and backup center API corresponding to the proxy API in the service bus, and switching the routing target API of the proxy API to the backup center API when the primary center fails, not only is the failover timeout (RTO) shortened, but the uninterrupted service provided to the outside world is also ensured.

[0056] In one embodiment of the above embodiments, the process of the service bus executing step 102 may be, for example, receiving an event reported by the main center; and determining that the main center is in a fault state if the event is a main center fault event.

[0057] In some embodiments, when the service bus determines that the main center is in a fault state based on events reported by the main center, the service bus marks the main center as faulty.

[0058] Therefore, based on the events reported by the main center, main center faults can be detected in a timely manner, and the faulty main centers can be marked.

[0059] In another implementation, the process of the service bus executing step 102 may, for example, determine that the main center is in a fault state if the main center meets at least one of the following conditions: the API service address network of the main center is not accessible; the API error rate of the main center is higher than a first error rate threshold; or the health check result of the main center is abnormal.

[0060] In some embodiments, the API error rate refers to the probability that a probe request sent to the main center returns an error. The first error rate threshold can be set according to actual needs, and is not specifically limited here. For example, if the first error rate threshold is 5%, the main center is determined to be in a fault state when the API error rate of the main center is higher than 5%.

[0061] In some embodiments, a health detection interface is configured to monitor the main center. When the health detection results of the main center are abnormal, it is determined that the main center is in a faulty state.

[0062] In some embodiments, the service bus monitors the main center, and if it finds that the main center meets at least one of the above conditions, it determines that the main center is in a fault state and marks the main center as a fault state.

[0063] Therefore, based on the monitoring results of the main center by the service bus, the main center faults can be detected in a timely manner, and the faulty main centers can be marked.

[0064] In some embodiments, the service bus can also switch the routing target API of at least one proxy API to the main center API corresponding to at least one proxy API when the main center switches from a fault state to a normal state.

[0065] Therefore, when the main center fails and recovers, the routing target API of the proxy API can be switched to the main center API.

[0066] In some embodiments, the service bus receives a proxy API call request from a client, wherein the proxy API call request includes an identifier of a third proxy API to be called; determines the routing target API of the third proxy API; sends a call request to the routing target API to obtain the call result of the routing target API; and returns the call result to the client.

[0067] Therefore, when the service bus receives a proxy API call request, it can route it to the main center API or the backup center API that is not faulty, thus avoiding service failure.

[0068] For example, Figure 2 A diagram illustrating the failover process in the event of a master center failure. Figure 2 In the process, the service bus (API gateway cluster) includes: Gateway Node 1, Gateway Node 2, and Gateway Node 3. During the request gateway phase, the service bus (API gateway cluster) receives proxy API call requests from clients. The proxy API call requests can be Hypertext Transfer Protocol (HTTP) requests initiated by the client to the proxy API. During routing, the service bus determines whether the primary center is faulty. When the primary center is normal, the service bus forwards the proxy API call requests to the primary center. When the primary center is faulty, the service bus forwards the proxy API call requests to the backup center, allowing the backup center to provide services, thus completing the failover.

[0069] After the service bus completes the failover, if it is necessary to restore the API service to the main center, the failover can be performed manually or automatically, that is, the routing target API of the proxy API is switched to the main center API corresponding to at least one proxy API.

[0070] Figure 3 This is a flowchart illustrating another disaster recovery method provided in an embodiment of this application.

[0071] like Figure 3 As shown, the disaster recovery method may include the following steps:

[0072] Step 301: Obtain the configuration information of at least one proxy API in the service bus. The configuration information includes the main center API and the backup center API corresponding to the proxy API.

[0073] Step 302: Based on the communication data between the service bus and the main center, determine whether the main center is in a fault state.

[0074] Step 303: In the event that the primary center is in a faulty state, switch the routing target API of at least one proxy API to the backup center API corresponding to at least one proxy API.

[0075] It should be noted that the detailed process of steps 301-303 can be found in the relevant content of other embodiments, and will not be repeated here.

[0076] Step 304: If the main center is in a normal state, determine whether at least one main center API in the main center is in a fault state.

[0077] The main center may include one main center API or multiple main center APIs; no specific limitation is made here.

[0078] In some embodiments, as a possible implementation, the process of the service bus performing step 304 may be, for example, receiving an event reported by the main center; and, in the case that the event is a first main center API failure event, determining that the first main center API is in a failure state.

[0079] In some embodiments, when the service bus determines that the first main center API is in a fault state based on events reported by the main center, it marks the first main center API as faulty.

[0080] Therefore, based on the events reported by the main center, the failure of the first main center API can be detected in a timely manner, and the failure of the first main center API can be marked.

[0081] As another possible implementation, the process of the service bus executing step 304 can be, for example, determining that the main central API is in a fault state when the main central API meets at least one of the following conditions: the response status code of the main central API does not match the specified status code; the response duration of the main central API is greater than a preset duration threshold; the response header of the main central API does not match the specified response header; the response body of the main central API does not match the specified response body; the service address network of the main central API is not accessible; the error rate of the main central API is higher than a second error rate threshold.

[0082] In some embodiments, the error rate of the main center API refers to the probability that sending a probe request to the main center API returns an error. The second error rate threshold can be set according to actual needs, and is not specifically limited here. For example, the second error rate threshold is 5%. When the error rate of the main center API is higher than 5%, it is determined that the main center API is in a faulty state.

[0083] The preset duration threshold can be set according to actual needs, and no specific limitation is made here.

[0084] In some embodiments, the service bus monitors the main center API, and if it finds that the main center API meets at least one of the above conditions, it determines that the main center API is in a fault state and marks the main center API as faulty.

[0085] Therefore, based on the monitoring results of the main center API by the service bus, faults in the main center API can be detected in a timely manner, and faulty main center APIs can be marked.

[0086] For example, Figure 4 A flowchart illustrating the process of determining whether at least one main center API in the main center is in a fault state. Figure 4 In this process, the service bus receives proxy API call requests from clients and forwards them to the main center. The main center may include main center API1 (first main center API), main center API2, and main center API3. When a main center API is functioning normally, it returns a response. When a main center API is malfunctioning, it returns a report. The main center API is determined to be in a faulty state if at least one of the following conditions is met in the report: the response status code of the main center API does not match the specified status code; the response duration of the main center API exceeds a preset duration threshold; the response header of the main center API does not match the specified response header; the response body of the main center API does not match the specified response body; the service address of the main center API is not accessible via network; or the error rate of the main center API is higher than a second error rate threshold.

[0087] Step 305: If there is a first main center API in a faulty state in the main center, obtain the first proxy API corresponding to the first main center API.

[0088] The relationship between the main center API and the proxy API is one-to-one, that is, the first main center API corresponds to the first proxy API.

[0089] Step 306: Switch the routing target API of the first proxy API to the backup center API corresponding to the first proxy API.

[0090] In some embodiments, the routing target API of the first proxy API is switched from the first primary center API to the backup center API corresponding to the first proxy API.

[0091] In some embodiments, the service center may also switch the routing target API of the first proxy API to the main center API corresponding to the first proxy API when the first main center API switches from a fault state to a normal state.

[0092] The disaster recovery method of this application embodiment obtains the configuration information of at least one proxy API in the service bus, including the primary center API and backup center API corresponding to the proxy API; determines whether the primary center is in a fault state based on the communication data between the service bus and the primary center; if the primary center is in a fault state, switches the routing target API of at least one proxy API to the backup center API corresponding to at least one proxy API; if the primary center is in a normal state, determines whether at least one primary center API in the primary center is in a fault state; if there is a first primary center API in the primary center that is in a fault state, obtains the first proxy API corresponding to the first primary center API; and switches the routing target API of the first proxy API to the backup center API corresponding to the first proxy API. Therefore, by configuring the primary center API and backup center API corresponding to the proxy API in the service bus, and switching the routing target API of the proxy API to the backup center API when the primary center fails, not only is the RTO of fault switching shortened, but the uninterrupted service provided to the outside world is also ensured.

[0093] Figure 5 This is a flowchart illustrating another disaster recovery method provided in an embodiment of this application.

[0094] like Figure 5 As shown, the disaster recovery method may include the following steps:

[0095] Step 501: Obtain the configuration information of at least one proxy API in the service bus. The configuration information includes the main center API and the backup center API corresponding to the proxy API.

[0096] It should be noted that the detailed process of step 501 can be found in other embodiments, and will not be repeated here.

[0097] Step 502: Determine whether the current mode is drill mode.

[0098] In some embodiments, the service bus determines whether to enable the drill mode, and if in drill mode, performs step 503.

[0099] Step 503: In the case of being in drill mode, obtain the current drill switching method.

[0100] In some embodiments, the drill switching method includes at least one of the following: switching the routing target API of all proxy APIs to the backup center API corresponding to the proxy API; switching the routing target API of all proxy APIs to the main center API corresponding to the proxy API; switching the routing target API of the second proxy API in at least one proxy API to the backup center API corresponding to the second proxy API; and switching the routing target API of the second proxy API to the main center API corresponding to the second proxy API.

[0101] Step 504: According to the drill switching method, switch the routing target API of at least one proxy API.

[0102] In some embodiments, switching the routing target API of at least one proxy API may include at least one of the following processes: switching the routing target API to the backup center API corresponding to the proxy API; switching the routing target API to the main center API corresponding to the proxy API; switching the routing target API of a second proxy API to the backup center API corresponding to the second proxy API; and switching the routing target API of a second proxy API to the main center API corresponding to the second proxy API.

[0103] Step 505: Based on the communication data between the service bus and the main center, determine whether the main center is in a fault state.

[0104] Step 506: In the event that the primary center is in a faulty state, switch the routing target API of at least one proxy API to the backup center API corresponding to at least one proxy API.

[0105] It should be noted that the detailed process of steps 505-506 can be found in other embodiments, and will not be repeated here.

[0106] The disaster recovery method in this application embodiment obtains configuration information of at least one proxy API in the service bus, including the primary center API and backup center API corresponding to the proxy API; determines whether it is currently in exercise mode; if in exercise mode, obtains the current exercise switching method; performs switching processing on the routing target API of at least one proxy API according to the exercise switching method; determines whether the primary center is in a fault state based on the communication data between the service bus and the primary center; and if the primary center is in a fault state, switches the routing target API of at least one proxy API to the backup center API corresponding to at least one proxy API. Therefore, by configuring the primary center API and backup center API corresponding to the proxy API in the service bus, and switching the routing target API of the proxy API to the backup center API when the primary center fails, not only is the RTO of fault switching shortened, but the uninterrupted service provided to the outside world is also ensured.

[0107] For example, Figure 6 A flowchart illustrating another disaster recovery method provided in this application embodiment is shown below. Figure 6 In the process, after configuring the primary and backup APIs corresponding to the proxy API (configuring the API service addresses provided by the primary and backup centers), the service bus receives the proxy API call request from the client and forwards it to the primary API. The service bus then determines whether it is in drill mode (simulating a primary center failure, or following the primary / backup switchover process to ensure the primary center is not in a failure state). That is, if the service bus determines that the proxy API has started drill mode during routing, it will manually or automatically forward the proxy API call request to the backup API. When in drill mode, it obtains the current drill switching method and switches the routing target API of at least one proxy API according to the drill switching method. After the drill switching is completed, if it is necessary to switch the routing target API to the primary API, it can be done manually.

[0108] When the service bus is not in drill mode, it determines whether the primary center is in a fault state. If the primary center is not in a fault state, the routing target API of at least one proxy API is the primary center API, which can include: primary center API1, primary center API2, and primary center API3. If the primary center is in a fault state, it determines whether to automatically switch over, i.e., automatically switch the target API to the backup center API corresponding to at least one proxy API, which can include: backup center API1, backup center API2, and backup center API3. If automatic switching is not performed, the target API can be manually switched to the backup center API corresponding to at least one proxy API. At this time, the fault switchover is completed.

[0109] After the failover is completed, a failback can be performed as needed. This can be done manually or automatically based on the health check results from the main center, switching the target API to the main center API.

[0110] Figure 7 A flowchart illustrating the process of determining whether the main center is in a faulty state is provided. Figure 7 The service bus can proactively detect the main center, i.e., proactively monitor the main center, and determine whether the main center is in a fault state based on the monitoring results. If at least one of the following situations occurs in the monitoring results, the result that the main center is in a fault state will be returned: the API service address of the main center is not accessible; the API error rate of the main center is higher than the first error rate threshold; the health check result of the main center is abnormal.

[0111] The conditions that must be met for the main center to be in a faulty state are not limited to the three conditions listed above.

[0112] The service bus can also determine whether the master center is in a fault state based on the information reported by the master center. That is, if the event reported by the master center in the reporting information is a master center fault event, it determines that the master center is in a fault state, returns the result that the master center is in a fault state, and marks this master center as a fault state.

[0113] Corresponding to the disaster recovery methods provided in the above embodiments, one embodiment of this application also provides a disaster recovery device. Since the disaster recovery device provided in this embodiment corresponds to the disaster recovery methods provided in the above embodiments, the implementation methods of the disaster recovery methods are also applicable to the disaster recovery device provided in this embodiment, and will not be described in detail here.

[0114] like Figure 8 As shown, the disaster recovery processing device 800 may include: a first acquisition module 810, a first determination module 820, and a first switching module 830.

[0115] The first acquisition module 810 is used to acquire configuration information of at least one proxy API in the service bus, the configuration information including the main center API and the backup center API corresponding to the proxy API; the first determination module 820 is used to determine whether the main center is in a fault state based on the communication data between the service bus and the main center; the first switching module 830 is used to switch the routing target API of at least one proxy API to at least one backup center API corresponding to the proxy API when the main center is in a fault state.

[0116] In some embodiments, the first determining module 820 is specifically configured to receive an event reported by the main center; and, in the case that the event is a main center failure event, determine that the main center is in a failure state.

[0117] In some embodiments, the first determining module 820 is specifically configured to determine that the main center is in a fault state when the main center meets at least one of the following conditions: the API service address of the main center is not connected to the network; the API error rate of the main center is higher than a first error rate threshold; or the health detection result of the main center is abnormal.

[0118] In some embodiments, the apparatus further includes: a second switching module, configured to switch the routing target API of at least one of the proxy APIs to the main center API corresponding to at least one of the proxy APIs when the main center switches from a fault state to a normal state.

[0119] In some embodiments, the apparatus further includes: a second determining module, a second acquiring module, and a third switching module; the second determining module is configured to determine whether at least one of the main center APIs in the main center is in a fault state when the main center is in a normal state; the second acquiring module is configured to acquire a first proxy API corresponding to the first main center API when there is a first main center API in a fault state in the main center; the third switching module is configured to switch the routing target API of the first proxy API to the backup center API corresponding to the first proxy API.

[0120] In some embodiments, the second determining module is specifically configured to receive an event reported by the main center; and, if the event is a first main center API failure event, determine that the first main center API is in a failure state.

[0121] In some embodiments, the second determining module is specifically used to determine that the main center API is in a fault state when the main center API meets at least one of the following conditions: the response status code of the main center API does not match a specified status code; the response duration of the main center API is greater than a preset duration threshold; the response header of the main center API does not match a specified response header; the response body of the main center API does not match a specified response body; the service address network of the main center API is unreachable; the error rate of the main center API is higher than a second error rate threshold.

[0122] In some embodiments, the apparatus further includes a fourth switching module, configured to switch the routing target API of the first proxy API to the main center API corresponding to the first proxy API when the first main center API switches from a fault state to a normal state.

[0123] In some embodiments, before determining whether the main center is in a fault state, the device further includes: a third determining module and a fifth switching module; the third determining module is used to determine whether the current state is a drill mode; if the drill mode is in the case, to obtain the current drill switching method; the fifth switching module is used to perform switching processing on at least one routing target API of the proxy API according to the drill switching method.

[0124] In some embodiments, the drill switching method includes at least one of the following: switching the routing target API of all proxy APIs to the backup center API corresponding to the proxy API; switching the routing target API of all proxy APIs to the main center API corresponding to the proxy API; switching the routing target API of at least one of the proxy APIs to the backup center API corresponding to the second proxy API; and switching the routing target API of the second proxy API to the main center API corresponding to the second proxy API.

[0125] In some embodiments, the apparatus further includes: a receiving module, a fourth determining module, a processing module, and a returning module; the receiving module is configured to receive a proxy API call request from a client, wherein the proxy API call request includes an identifier of a third proxy API to be called; the fourth determining module is configured to determine the routing target API of the third proxy API; the processing module is configured to send a call request to the routing target API to obtain the call result of the routing target API; and the returning module is configured to return the call result to the client.

[0126] The disaster recovery processing apparatus of this application embodiment obtains configuration information of at least one proxy API in the service bus, including the primary center API and backup center API corresponding to the proxy API; determines whether the primary center is in a fault state based on communication data between the service bus and the primary center; and switches the routing target API of at least one proxy API to the backup center API corresponding to the at least one proxy API when the primary center is in a fault state. Therefore, by configuring the primary center API and backup center API corresponding to the proxy API in the service bus, and switching the routing target API of the proxy API to the backup center API when the primary center fails, not only is the failover timeout (RTO) shortened, but the uninterrupted service provided to the outside world is also ensured.

[0127] To implement the above embodiments, this application provides a disaster recovery system 900, comprising: a service bus 901, a primary center 902 and a backup center 903 connected to the service bus; at least one proxy API is provided on the service bus 901; a primary center API 9021 corresponding to the proxy API is provided on the primary center 902; a backup center API 9031 corresponding to the proxy API is provided on the backup center 903; the service bus 901 is used to perform, for example... Figures 1 to 7 The disaster recovery method described above.

[0128] The disaster recovery system of this application embodiment obtains the configuration information of at least one proxy API in the service bus, including the primary center API and backup center API corresponding to the proxy API; determines whether the primary center is in a fault state based on the communication data between the service bus and the primary center; and switches the routing target API of at least one proxy API to the backup center API corresponding to the at least one proxy API when the primary center is in a fault state. Therefore, by configuring the primary center API and backup center API corresponding to the proxy API in the service bus, and switching the routing target API of the proxy API to the backup center API when the primary center fails, not only is the failover timeout (RTO) shortened, but the uninterrupted service provided to the outside world is also ensured.

[0129] To achieve the above embodiments, this application also proposes an electronic device. Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device includes:

[0130] The memory 1001, the processor 1002, and the computer program stored on the memory 1001 and capable of running on the processor 1002.

[0131] When the processor 1002 executes the program, it implements the disaster recovery processing method provided in the above embodiments.

[0132] Furthermore, electronic devices also include:

[0133] Communication interface 1003 is used for communication between memory 1001 and processor 1002.

[0134] The memory 1001 is used to store computer programs that can run on the processor 1002.

[0135] The memory 1001 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0136] The processor 1002 is used to implement the disaster recovery processing method described in the above embodiments when executing the program.

[0137] If the memory 1001, processor 1002, and communication interface 1003 are implemented independently, then the communication interface 1003, memory 1001, and processor 1002 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 10 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0138] Optionally, in a specific implementation, if the memory 1001, processor 1002, and communication interface 1003 are integrated on a single chip, then the memory 1001, processor 1002, and communication interface 1003 can communicate with each other through an internal interface.

[0139] The processor 1002 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0140] To implement the above embodiments, this application also proposes a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the disaster recovery processing method provided in the above embodiments.

[0141] To implement the above embodiments, this application also proposes a computer program product that, when executed by an instruction processor, implements the disaster recovery processing method provided in the above embodiments.

[0142] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0143] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0144] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0145] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0146] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0147] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0148] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0149] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A disaster recovery method, characterized in that, Applied to a service bus, the method includes: Obtain configuration information for at least one proxy API in the service bus. The configuration information includes the primary center API and the backup center API corresponding to the proxy API, wherein the correspondence between the proxy API and the primary center API is one-to-one, and the correspondence between the proxy API and the backup center API is also one-to-one. Based on the communication data between the service bus and the main center, it is determined whether the main center is in a fault state, including: receiving events reported by the main center; In the case of a main center failure event, it is determined that the main center is in a failure state. The main center is determined to be in a fault state if it meets at least one of the following conditions: The API service address of the main center is not accessible via network. The API error rate of the main center is higher than the first error rate threshold. The health monitoring results from the main center were abnormal; In the event that the primary center is in a faulty state, the routing target API of at least one of the proxy APIs will be switched to at least one backup center API corresponding to the proxy API.

2. The method according to claim 1, characterized in that, The method further includes: When the main center switches from a fault state to a normal state, the routing target API of at least one of the proxy APIs is switched to the main center API corresponding to at least one of the proxy APIs.

3. The method according to claim 1, characterized in that, The method further includes: If the main center is in a normal state, determine whether at least one of the main center APIs in the main center is in a fault state; When a first main center API is in a faulty state in the main center, obtain the first proxy API corresponding to the first main center API; Switch the routing target API of the first proxy API to the backup center API corresponding to the first proxy API.

4. The method according to claim 3, characterized in that, Determining whether at least one of the main center APIs in the main center is in a fault state includes: Receive events reported by the main center; In the case where the event is a failure event of the first main central API, it is determined that the first main central API is in a failure state.

5. The method according to claim 3, characterized in that, Determining whether at least one of the main center APIs in the main center is in a fault state includes: The main center API is determined to be in a fault state if it meets at least one of the following conditions: The response status code of the main center API does not match the specified status code; The response time of the main center API is greater than a preset time threshold; The response headers of the main center API do not match the specified response headers; The response body of the main central API does not match the specified response body; The service address of the main center API is not accessible via network. The error rate of the main central API is higher than the second error rate threshold.

6. The method according to claim 3, characterized in that, The method further includes: When the first main center API switches from a fault state to a normal state, the routing target API of the first proxy API is switched to the main center API corresponding to the first proxy API.

7. The method according to claim 1, characterized in that, Before determining whether the main center is in a faulty state, the method further includes: Determine if we are currently in drill mode; When in the aforementioned training mode, obtain the current training switching method; According to the training switching method, the routing target API of at least one of the proxy APIs is switched.

8. The method according to claim 7, characterized in that, The exercise switching method includes at least one of the following: Switch the routing target API of all proxy APIs to the backup center API corresponding to the proxy API; Switch the routing target API of all proxy APIs to the main center API corresponding to the proxy API; Switch the routing target API of at least one of the proxy APIs to the backup center API corresponding to the second proxy API; Switch the routing target API of the second proxy API to the main center API corresponding to the second proxy API.

9. The method according to claim 1, characterized in that, The method further includes: Receive a proxy API call request from a client, wherein the proxy API call request includes an identifier of the third proxy API to be called; Determine the routing target API for the third proxy API; Send a call request to the target routing API to obtain the call result of the target routing API; The result of the call is returned to the client.

10. A disaster recovery processing device, characterized in that, Applied to a service bus, the device includes: The acquisition module is used to acquire configuration information of at least one proxy API in the service bus. The configuration information includes the main center API and the backup center API corresponding to the proxy API, wherein the correspondence between the proxy API and the main center API is one-to-one, and the correspondence between the proxy API and the backup center API is one-to-one. The determination module is used to determine whether the main center is in a fault state based on the communication data between the service bus and the main center; A switching module is used to switch the routing target API of at least one of the proxy APIs to at least one backup center API corresponding to the proxy API when the main center is in a faulty state. The determining module is used to receive events reported by the main center. In the case of a main center failure event, it is determined that the main center is in a failure state. The main center is determined to be in a fault state if it meets at least one of the following conditions: The API service address of the main center is not accessible via network. The API error rate of the main center is higher than the first error rate threshold. The health check results from the main center were abnormal.

11. A disaster recovery system, characterized in that, The system includes: A service bus, a primary center and a backup center connected to the service bus; at least one proxy API is provided on the service bus. The main center is equipped with a main center API corresponding to the proxy API; the backup center is equipped with a backup center API corresponding to the proxy API. The service bus is used to execute the disaster recovery processing method as described in any one of claims 1 to 9.

12. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the disaster recovery processing method as described in any one of claims 1-9.

13. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the disaster recovery processing method as described in any one of claims 1-9.

Images