CN107508700B

CN107508700B - Disaster recovery method, device, equipment and storage medium

Info

Publication number: CN107508700B
Application number: CN201710696126.0A
Authority: CN
Inventors: 桑威林
Original assignee: Beijing Xiaomi Mobile Software Co Ltd
Current assignee: Beijing Xiaomi Mobile Software Co Ltd
Priority date: 2017-08-15
Filing date: 2017-08-15
Publication date: 2021-01-15
Anticipated expiration: 2037-08-15
Also published as: CN107508700A

Abstract

The present disclosure provides a disaster recovery method, apparatus, device and storage medium, where the method is applied to a request end, the request end is connected with a main response end and a standby response end respectively, and the main response end and the standby response end provide the same data service, and the method includes: when the main response end is determined to be abnormal in operation, a disaster recovery strategy for switching the main response end into a standby response end is obtained; determining a standby response end according to the disaster recovery strategy, and acquiring first configuration information required by a request end when requesting to the standby response end; updating second configuration information of the request terminal through the first configuration information; and controlling the main response end to be switched into the standby response end and accessing. The method and the device not only realize the consistency of the configuration information of the request end and the standby response end, but also improve the efficiency of determining the standby response end and updating the configuration because the disaster tolerance strategy and the first configuration information can be actively obtained, thereby improving the disaster tolerance efficiency and reducing the dependency of an access party and the response end.

Description

Disaster recovery method, device, equipment and storage medium

Technical Field

The present application relates to the field of communications technologies, and in particular, to a disaster recovery method, apparatus, device, and storage medium.

Background

In a computer information system, in order to ensure the safety and stability of information services, two or more sets of service processing systems with the same function need to be established, and functional disaster tolerance can be realized between the two or more sets of service processing systems, that is, when one service processing system has a problem, the other service processing system can provide services to the outside, so that the safety and stability of the external services can be ensured. Disaster recovery is an important component of a high-availability technology of a system, and the influence of an external environment or an emergency on the system needs to be considered in advance to avoid that the system cannot provide service or data is lost when a disaster occurs. So-called disasters can be events that fail to provide normal services, such as machine hardware failures, network failures, program crashes, and overloading due to an emergency.

For convenience of understanding, a party sending an access request may be referred to as a requester, and a party responding to the request may be referred to as a responder. In the disaster recovery process, the request end and the response end having the access relation need to use completely consistent configuration information. The completely consistent configuration information is that the request end has configuration information adapted to the response end, and the response end has configuration information adapted to the request end, so that both sides can normally operate regardless of which party is changed.

Therefore, when a response end with a disaster is switched to a standby response end, the request end and the standby response end face the problem of whether the configuration information is consistent, if the configuration information of the request end and the configuration information of the standby response end are not consistent, the standby response end is unavailable, and the standby response end cannot be switched to the standby response end, so that the disaster recovery failure is caused.

Disclosure of Invention

To overcome the problems in the related art, the present disclosure provides a disaster recovery method, apparatus, device, and storage medium.

According to a first aspect of the embodiments of the present disclosure, a disaster recovery method is provided, where the method is applied to a request end, the request end is connected to a main response end and a standby response end, and the main response end and the standby response end provide the same data service, and the method includes:

when the main response end is determined to be abnormal in operation, a disaster recovery strategy for switching the main response end into a standby response end is obtained;

determining a standby response end according to the disaster recovery strategy, and acquiring first configuration information required by a request end when requesting to the standby response end;

updating second configuration information of the request terminal through the first configuration information;

and controlling the main response end to be switched into the standby response end and accessing.

Optionally, the obtaining of the disaster recovery policy for switching the main response end to the standby response end includes:

acquiring a disaster recovery strategy for switching a main response end into a standby response end from a cache area or a first server end;

the obtaining of the first configuration information required by the request end when requesting from the standby response end includes:

acquiring first configuration information required by a request end when the request is made to the standby response end from a cache region or the first server end; the first server side stores the latest disaster recovery strategy and the first configuration information.

Optionally, the method further includes: and updating the disaster recovery strategy and the first configuration information in the cache region.

Optionally, the updating the disaster recovery policy and the first configuration information in the cache region includes:

acquiring a disaster recovery strategy and first configuration information from the first service terminal at preset time intervals, and updating the disaster recovery strategy and the first configuration information in the cache region; and/or the presence of a gas in the gas,

receiving a disaster tolerance strategy and first configuration information sent by a second server, and updating the disaster tolerance strategy and the first configuration information in a cache region;

the second server side updates the disaster recovery strategy and the first configuration information in real time according to the running condition and the add-delete condition of the main response side/the standby response side, and notifies the request side and the first server side when updating the disaster recovery strategy and the first configuration information.

Optionally, the obtaining, from the cache region or the first server, the disaster recovery policy for switching the main response end to the standby response end includes:

acquiring the updating time of a disaster recovery strategy used for switching a main response end into a standby response end in a cache region;

if the disaster recovery strategy is determined to be in the cache life period according to the updating time, the disaster recovery strategy is obtained from a cache region;

and if the disaster recovery strategy is determined not to be in the cache life period according to the updating time, acquiring the disaster recovery strategy from the first service terminal.

Optionally, the disaster recovery policy includes routing information, a request path corresponding to an access request is recorded in the routing information, and the access request is a request sent from a request end to a main response end.

Optionally, the disaster recovery policy further includes identification information for identifying the routing information;

the controlling the main response end to be switched into the standby response end and to access comprises the following steps:

sending the access request carrying the identification information to the standby response end, wherein the identification information is used for prompting the standby response end to: routing information used by the requesting end.

Optionally, the request end is a service intermediate node, the service intermediate node is a service node that needs to invoke a next-level service node in order to respond to an access request sent by a previous-level request end, and the identification information is further used to indicate version information of the routing information, where the method further includes:

receiving an access request sent by a superior request end, wherein the received access request carries identification information of routing information in the superior request end;

if the version of the routing information of the upper-level request end is lower than that of the routing information of the request end according to the received identification information and the identification information of the request end, the routing information of the request end is fed back to the upper-level request end;

and if the version of the routing information of the upper-level request end is higher than that of the routing information of the request end according to the received identification information and the identification information of the request end, acquiring the routing information of the request end from the first service end.

According to a second aspect of the embodiments of the present disclosure, a disaster recovery device is provided, where the disaster recovery device is applied to a request end, the request end is connected to a main response end and a standby response end, and the main response end and the standby response end provide the same data service, and the disaster recovery device includes:

the system comprises a strategy acquisition module, a strategy selection module and a strategy selection module, wherein the strategy acquisition module is configured to acquire a disaster recovery strategy for switching a main response end into a standby response end when the main response end is determined to be abnormal in operation;

the information acquisition module is configured to determine a standby response end according to the disaster recovery strategy and acquire first configuration information required by a request end when the request is made to the standby response end;

the configuration updating module is configured to update the second configuration information of the request terminal through the first configuration information;

and the switching module is configured to control the main response end to be switched into the standby response end and access the standby response end.

Optionally, the policy obtaining module is specifically configured to: acquiring a disaster recovery strategy for switching a main response end into a standby response end from a cache area or a first server end;

the information acquisition module is specifically configured to: determining a standby response end according to the disaster recovery strategy, and acquiring first configuration information required by a request end when the request is made to the standby response end from a cache region or the first server end; the first server side stores the latest disaster recovery strategy and the first configuration information.

Optionally, the apparatus further includes an information updating module configured to: and updating the disaster recovery strategy and the first configuration information in the cache region.

Optionally, the information updating module at least includes one of the following sub-modules:

the first information updating submodule is configured to acquire the disaster recovery strategy and the first configuration information from the first service terminal at preset time intervals, and update the disaster recovery strategy and the first configuration information in the cache region;

the second information updating submodule is configured to receive the disaster recovery strategy and the first configuration information sent by the second server and update the disaster recovery strategy and the first configuration information in the cache region;

Optionally, the policy obtaining module includes:

the time acquisition submodule is configured to acquire the update time of the disaster recovery strategy used for switching the main response terminal into the standby response terminal in the cache region;

the first strategy obtaining sub-module is configured to obtain the disaster recovery strategy from a cache region if the disaster recovery strategy is determined to be in the cache life period according to the updating time;

and the second strategy acquisition submodule is configured to acquire the disaster recovery strategy from the first service terminal if the disaster recovery strategy is determined not to be in the cache life period according to the updating time.

the switching module is specifically configured to: sending the access request carrying the identification information to the standby response end, wherein the identification information is used for prompting the standby response end to: routing information used by the requesting end.

Optionally, the request end is a service intermediate node, the service intermediate node is a service node that needs to invoke a next-level service node in order to respond to an access request sent by a previous-level request end, and the identification information is further used to indicate version information of the routing information, where the apparatus further includes:

the information receiving module is configured to receive an access request sent by a superior request end, wherein the received access request carries identification information of the routing information in the superior request end;

the information feedback module is configured to feed back the routing information of the request end to the upper-level request end if the version of the routing information of the upper-level request end is lower than the version of the routing information of the request end according to the received identification information and the identification information of the request end;

the policy obtaining module is further configured to obtain the routing information of the request end from the first server end if it is determined that the version of the routing information of the upper-level request end is higher than the version of the routing information of the request end according to the received identification information and the identification information of the request end.

According to a third aspect of the embodiments of the present disclosure, a service device is provided, where the service device is connected to a main service device and a standby service device, and the main service device and the standby service device provide the same data service, including:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to:

when the main response end is determined to be abnormal in operation, a disaster recovery strategy for switching the main service equipment into the standby service equipment is obtained;

determining a standby service device according to the disaster tolerance strategy, and acquiring first configuration information required by a request terminal when requesting the standby service device;

and controlling the main service equipment to be switched into the standby service equipment and accessing.

According to a fourth aspect of embodiments of the present disclosure, there is provided a computer-readable storage medium, on which a computer program is stored, which when executed by a processor, implements the steps of any of the methods described above.

The technical scheme provided by the embodiment of the disclosure can have the following beneficial effects:

in the embodiment of the disclosure, when determining that the main response end is abnormal in operation, the request end may actively acquire a disaster recovery policy for switching the main response end to the backup response end, determine the backup response end according to the disaster recovery policy, acquire first configuration information required by the request end when requesting from the backup response end, and update second configuration information of the request end through the first configuration information, thereby implementing that the configuration information of the request end is consistent with that of the backup response end, and then control the main response end to be switched to the backup response end and perform access, thereby implementing successful disaster recovery. And the dependency of the access terminal and the response terminal is reduced.

In the embodiment of the disclosure, the disaster recovery policy and the first configuration information are directly acquired from the cache region, so that the acquisition efficiency can be improved.

In the embodiment of the disclosure, since the latest disaster recovery policy and the latest first configuration information are stored in the first server, the disaster recovery policy and the latest configuration information can be directly obtained from the first server, and the failure of disaster recovery due to untimely cache update is avoided.

According to the embodiment of the disclosure, under the condition that the cache information is available, the disaster recovery strategy and the configuration information are directly obtained from the cache information, so that the obtaining efficiency can be improved; and under the condition that the cache information is unavailable, acquiring the disaster recovery strategy and the first configuration information from the first service terminal, and ensuring that the latest disaster recovery strategy and the first configuration information can be acquired in time.

The embodiment of the disclosure updates the disaster recovery policy and the first configuration information in the cache region, thereby ensuring that the disaster recovery policy and the first configuration information stored in the cache region are the latest or relatively newer information.

In this embodiment, because the disaster recovery policy further includes identification information for identifying the routing information, and the access request carrying the identification information is sent to the standby response end, it is possible to implement that the request end and the response end use the consistent routing information for routing, which is convenient for the standby response end to quickly and accurately execute corresponding service processing, and improve processing efficiency.

When the version of the routing information of the upper-level request end is lower than that of the routing information of the request end, the routing information of the request end can be fed back to the upper-level request end, so that the upper-level request end can update the routing information quickly, the request sent by the upper-level request end to the response end with abnormal operation is avoided, and the processing efficiency is improved. In addition, when the version of the routing information of the upper-level request end is determined to be higher than that of the routing information of the request end, the latest routing information of the request end can be obtained from the first service end, the request end can quickly update the routing information, and the request end is prevented from calling the lower-level response end with abnormal operation.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure.

Fig. 1A is an architectural diagram of a server-side system shown in accordance with an exemplary embodiment of the present disclosure.

Fig. 1B is an architectural schematic diagram of a distributed system shown in accordance with an exemplary embodiment of the present disclosure.

Fig. 2A is a flow chart illustrating a disaster recovery method according to an exemplary embodiment of the present disclosure.

Fig. 2B is a flow chart illustrating an information updating method according to an example embodiment of the present disclosure.

Fig. 2C is a schematic diagram illustrating a server-side relationship according to an example embodiment of the present disclosure.

Fig. 2D is a flowchart illustrating a disaster recovery policy acquisition method according to an exemplary embodiment of the present disclosure.

Fig. 2E is a flow chart illustrating an information processing method according to an example embodiment of the present disclosure.

Fig. 3A is an architectural diagram of another distributed system illustrated by the present disclosure, according to an exemplary embodiment.

Fig. 3B is an architectural diagram of another distributed system illustrated by the present disclosure, according to an exemplary embodiment.

Fig. 4 is a block diagram of a disaster recovery device shown in accordance with an exemplary embodiment of the present disclosure.

Fig. 5 is a block diagram of another disaster recovery device shown in accordance with an exemplary embodiment of the present disclosure.

Fig. 6 is a block diagram of another disaster recovery device shown in accordance with an exemplary embodiment of the present disclosure.

Fig. 7 is a block diagram of another disaster recovery device shown in accordance with an exemplary embodiment of the present disclosure.

Fig. 8 is a block diagram of another disaster recovery device shown in accordance with an exemplary embodiment of the present disclosure.

Fig. 9 is a block diagram illustrating an apparatus for disaster recovery according to an exemplary embodiment of the present disclosure.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.

The terminology used in the present disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used in this disclosure and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present disclosure. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

In a computer information system, in order to ensure the security and stability of information services, two or more sets of service processing systems with the same function are generally required to be established, and functional disaster recovery can be realized between the two or more sets of service processing systems. However, when a response end with a disaster is switched to a standby response end, the request end and the standby response end face the problem of whether the configuration information is consistent, and if the configuration information of the request end and the standby response end is not consistent, the standby response end is unavailable and cannot be switched to the standby response end, so that the disaster recovery fails.

In order to achieve successful disaster tolerance, the embodiments of the present disclosure provide a disaster tolerance method, which may be applied in a server-side system, particularly in a distributed system. Fig. 1A is an architectural diagram of a server-side system shown in accordance with an exemplary embodiment of the present disclosure. In this schematic diagram, a party of the server system that sends the access request is referred to as a request side, and a party of the server system that responds to the request is referred to as a response side. The response end is provided with a main response end and a standby response end, and the main response end and the standby response end provide the same data service.

When the system is a distributed system, the service nodes in the system may be the requesting side in some cases and the responding side in some cases. As shown in fig. 1B, fig. 1B is an architectural schematic diagram of a distributed system shown in accordance with an exemplary embodiment of the present disclosure. In the distributed system, after a client sends a service request to a service node in a service cluster through a service access layer, the service node can call the service node in the next-level service cluster associated with the service node, so as to respond to the service request. The service nodes may be requestors/responders based on the different roles each service node currently assumes. When the service node is a party sending an access request, the service node may be referred to as a requester, and when the service node is a party responding to the access request, the service node may be referred to as a responder. For example, when the service access layer sends an access request to a service node in the service cluster, the service access layer may serve as a request side, and a service node accessed by the service access layer may serve as a response side (e.g., a service node in service cluster a or a service node in service cluster B). When a service node (which may be referred to as a service intermediate node, such as a service node in service cluster a or a service node in service cluster B) sends an access request to a next service node, the service intermediate node may serve as a request end, and the next service node accessed by the service intermediate node may serve as a response end (such as a service node in service cluster C or a service node in service cluster D). It is to be understood that the architecture diagram shown in FIG. 1A or FIG. 1B is for illustration only and should not be construed as limiting the present teachings.

As shown in fig. 2A, fig. 2A is a flowchart of a disaster recovery method according to an exemplary embodiment, which may be applied to the request end shown in fig. 1A or fig. 1B, and includes the following steps 201 and 204:

in step 201, when it is determined that the main response end is abnormal in operation, a disaster recovery policy for switching the main response end to the standby response end is obtained.

In step 202, a standby response end is determined according to the disaster recovery policy, and first configuration information required by a request end when requesting to the standby response end is obtained.

In step 203, the second configuration information of the requesting end is updated through the first configuration information.

In step 204, the main responder is controlled to be switched to the standby responder and to access the standby responder.

In this embodiment, when determining that the main response end is abnormal in operation, the request end may actively acquire a disaster recovery policy for switching the main response end to the backup response end, determine the backup response end according to the disaster recovery policy, acquire first configuration information required by the request end when requesting from the backup response end, and update second configuration information of the request end through the first configuration information, thereby implementing that the configuration information of the request end and the backup response end are consistent, and then control the main response end to be switched to the backup response end and perform access, thereby implementing successful disaster recovery. And the dependency of the access terminal and the response terminal is reduced.

The main response end can be determined to be abnormal in operation when a preset abnormal judgment condition is met. For example, if the request end does not receive response information within a preset time period after sending an access request to the main response end, it is determined that the main response end operates abnormally; for another example, if the number of times that the request end sends the access request to the main response end exceeds the preset threshold and normal response information is not received, it is determined that the main response end operates abnormally, and the like. It can be understood that the determination may also be performed by using an anomaly determination method in the related art, which is not described herein again.

When the main response end is determined to be abnormal in operation, a disaster recovery strategy for switching the main response end into the standby response end can be obtained, the standby response end is determined according to the disaster recovery strategy, and first configuration information required by the request end when the request is made to the standby response end is obtained.

The disaster recovery policy may be a policy for instructing or assisting to instruct a response terminal with abnormal operation to switch to a response terminal with normal operation. The configuration information can be a configuration file required by the local terminal to normally access or respond to the change of the called party (accessed party) or the calling party (accessed party) so as to realize the change of one party and still enable the other party to operate. For example, the configuration information may be a public key corresponding to accessing other services, a database node, a database name, and the like. Taking the service access layer as an example, the configuration information may be a request address registered to the third party; log save path, etc. Taking a service node in a service cluster as an example, the configuration information may be public keys (public keys) of other applications; IP and dynamic password of the database; log save path, etc.

In the request end, the configuration information corresponding to different response ends may be different, and when the main response end is switched to the standby response end, first configuration information required by the request end when the main response end requests the standby response end needs to be acquired, so that second configuration information of the request end is updated through the first configuration information. The second configuration information may be configuration information required by the request side when the request side requests the main response side. For example, the log saving path is changed according to the switching of the response side.

In an optional implementation manner, the disaster recovery policy includes routing information, a request path corresponding to an access request is recorded in the routing information, and the access request is a request sent from a request end to a main response end. The request path can direct which responding terminal can be called/accessed by the local terminal aiming at a certain access request. Therefore, the configuration information can realize uniform configuration according to the routing information.

In addition, the disaster recovery policy may further include other policy information, for example, the load of the corresponding standby response end is obtained according to the request path, and one of the standby response ends is selected as the standby response end for access according to the load, so as to realize selection of the standby response end. It can be understood that other policy information can be flexibly configured according to requirements so as to find a suitable standby responding end.

As can be seen, since the routing information records the request path corresponding to the access request, when the primary response end operates abnormally, the request end can quickly select the standby response end that operates normally according to the request path to execute corresponding service processing, thereby implementing disaster recovery.

The disaster recovery policy and the first configuration information are acquired in several ways, which are exemplified below.

The first mode is as follows: in order to quickly acquire the disaster recovery policy and the first configuration information, the disaster recovery policy and the first configuration information may be cached in a cache region, and when it is determined that the main response end operates abnormally, the disaster recovery policy for switching the main response end to the standby response end may be acquired from the cache region. When the backup response terminal is determined according to the disaster recovery strategy, first configuration information required by the request terminal when the request is made to the backup response terminal can be obtained from the cache region.

Therefore, the disaster recovery strategy and the first configuration information are directly obtained from the cache region, and the obtaining efficiency can be improved.

Further, in order to avoid occupying too much cache space, only the disaster recovery policy and the configuration information associated with the local terminal may be stored in the cache region, thereby saving the cache space.

In an alternative implementation, as some service nodes may operate abnormally over time, or some policies may add or delete service nodes (e.g., capacity expansion or capacity reduction), so that the disaster tolerance policy and the configuration information are changed. In order to ensure that the disaster recovery policy and the configuration information stored in the cache area are the latest or relatively newer information, the disaster recovery policy and the configuration information in the cache area may also be updated, and in particular, the disaster recovery policy and the first configuration information in the cache area may be updated.

Therefore, by updating the information in the cache region, it is possible to avoid the disaster recovery policy or the first configuration information from being changed due to the reasons of capacity expansion, capacity reduction, device abnormality, and the like.

In an example, the disaster recovery policy and the first configuration information sent by the second server may be received, and the disaster recovery policy and the first configuration information in the cache area may be updated.

The second server can update the disaster recovery strategy and the first configuration information in real time according to the operation condition and the add-delete condition of the main response terminal/the backup response terminal, and notify the request terminal when updating the disaster recovery strategy and the first configuration information, so as to ensure that the disaster recovery strategy and the configuration information stored in the cache region are the latest or relatively newer information.

It can be seen that, in this embodiment, the second server notifies the request end when the change information is found, so that the request end updates the disaster recovery policy and the first configuration information in the cache region.

In another example, the disaster recovery policy and the first configuration information may be obtained from the first service end at preset intervals, and the disaster recovery policy and the first configuration information in the cache region may be updated.

The first service end stores the latest disaster recovery policy and the latest first configuration information, and the first service end can provide an inquiry function, so that the request end can inquire the disaster recovery policy and the first configuration information from the first service end.

It can be seen that, in this embodiment, the disaster recovery policy and the first configuration information are periodically updated in a manner of periodic acquisition, so that a situation that the disaster recovery fails due to the fact that the request end still utilizes the original disaster recovery policy or the first configuration information to perform disaster recovery because the disaster recovery policy or the first configuration information is changed due to capacity expansion, capacity reduction, and device abnormality is avoided. Meanwhile, the situation that disaster recovery fails due to the fact that the second server side cannot notify timely when a disaster occurs can be avoided.

As one of the combination cases, the disaster recovery policy and the first configuration information may be obtained from the first service end at preset time intervals, and the disaster recovery policy and the first configuration information in the cache area may be updated; and receiving the disaster recovery strategy and the first configuration information sent by the second server, and updating the disaster recovery strategy and the first configuration information in the cache region. By combining the two, the latest disaster recovery strategies and the configuration information can be cached in the cache region.

The second server side can notify the relevant core service node only when the disaster tolerance strategy and the configuration information of the core service node are updated, so that resource waste caused by whole network notification is avoided, and the disaster tolerance strategy and the configuration information of the core service can be ensured to be updated in time.

Fig. 2B is a flowchart of an information updating method according to an exemplary embodiment of the present disclosure, and this embodiment exemplarily illustrates how to update the disaster recovery policy and the first configuration information in the cache region by using the above method provided by the embodiment of the present disclosure, as shown in fig. 2B, the method includes the following steps 301-302:

in step 301, a disaster recovery policy and first configuration information are obtained from the first service end at preset time intervals, and the disaster recovery policy and the first configuration information in the cache area are updated.

In step 302, the disaster recovery policy and the first configuration information sent by the second server are received, and the disaster recovery policy and the first configuration information in the cache area are updated.

It is understood that step 301 and step 302 do not have a sequential execution order, and may specifically depend on the preset time and the sending time of the second server, which is not limited herein.

Next, a first service end and a second service end are introduced.

In one example, the first service end and the second service end may be the same service cluster. The service cluster updates the disaster recovery strategy and the first configuration information in real time according to the running condition and the add-delete condition of the main response terminal/the standby response terminal, can provide an inquiry function and a notification function, and notifies the request terminal when the disaster recovery strategy and the first configuration information are updated.

In another example, to ensure high availability and stability of the system, the first service end and the second service end may be different service clusters. Referring to fig. 2C, fig. 2C is a schematic diagram illustrating a server relationship according to an exemplary embodiment of the disclosure. In the schematic diagram, the first service end and the second service end are different service clusters. In one example, the first server may be a storage service cluster formed by one server or a plurality of servers, and the second server may be an arbitration service cluster formed by one server or a plurality of servers.

In this embodiment, the second service end may update the disaster recovery policy and the configuration information (e.g., configuration information required by the request end and configuration information required by the response end) in real time according to the operation condition and the add/delete condition (e.g., capacity expansion and capacity reduction) of the service node (e.g., the main response end, the standby response end, and the request end), and notify the relevant service node and the first service end when the disaster recovery policy and the configuration information are updated. In addition, the second server can also provide a management access function, and update the disaster recovery strategy and the configuration information according to the operation instruction of the administrator, so that the administrator can update the disaster recovery strategy and the configuration information; the second server may also provide a function of managing the first server, for example, the first server needs to add nodes and reduce nodes, and the second server may perform management. The second server may also perform other functions in the related art, which is not described herein again. The first server can store the disaster recovery strategy and the configuration information maintained in the second server, that is, the disaster recovery strategy and the configuration information of the whole set of system can be obtained and stored from the second server, and reliable storage is provided, so that the disaster recovery service group can call/inquire, and the consistency of data in the distributed environment is ensured.

Therefore, the first server and the second server execute different business processes, and the safety of information can be ensured.

Regarding updating the disaster recovery policy and the first configuration information in real time according to the operation condition and the add/delete condition of the main response end/the backup response end, in an example, an independent monitoring device may be disposed in each service cluster of the system, and configured to monitor the operation condition of a service node (the main response end, the backup response end, or the request end) in the service cluster, notify the second service end of the operation condition, and update the disaster recovery policy and the configuration information in real time according to the operation condition and the add/delete condition of the service node through the second service end. In another example, each service node may also report the current operation condition (e.g., load information, etc.) to the second server, so that the second server updates the disaster recovery policy, the configuration information, and the like in real time according to the operation condition and the add-delete condition of the service node.

The second mode is as follows: in practical applications, the request end may have a situation that the disaster recovery policy and the configuration information are not updated in time, for example, although the second server end notifies the request end, the request end may not receive the notification in time, which causes the request end to not update the disaster recovery policy and the configuration information in time, thereby causing a disaster recovery failure. In view of this, when it is determined that the main response end operates abnormally, the disaster recovery policy for switching the main response end to the standby response end may be acquired from the first service end. When the backup response end is determined according to the disaster recovery strategy, first configuration information required by the request end when the backup response end requests can be obtained from the first service end.

Therefore, as the latest disaster recovery strategy and the first configuration information are stored in the first service end, the disaster recovery strategy and the first configuration information are directly obtained from the first service end, the latest information can be obtained, and the disaster recovery failure caused by untimely cache updating is avoided.

The third mode is as follows: in order to ensure both the acquisition efficiency and the acquisition of the latest information, the embodiment may combine the first manner and the second manner. Fig. 2D is a flowchart of a disaster recovery policy obtaining method according to an exemplary embodiment, where this embodiment uses the method provided in the embodiment of the present disclosure to exemplarily explain how to obtain a disaster recovery policy, as shown in fig. 2D, the method includes the following steps 401 and 403:

in step 401, the update time of the disaster recovery policy for switching the primary response side to the standby response side in the cache area is obtained.

In step 402, if it is determined that the disaster recovery policy is within the cache validity period according to the update time, the disaster recovery policy is obtained from the cache region.

In step 403, if it is determined that the disaster recovery policy is not within the cache lifetime according to the update time, the disaster recovery policy is obtained from the first service end.

According to the embodiment of the disclosure, when the main response end is determined to be abnormal in operation, the updating time of the disaster recovery strategy in the cache region can be obtained first, and whether the disaster recovery strategy is within the cache validity period or not can be determined according to the updating time.

In one example, since the update time of the disaster recovery policy and the first configuration information in the cache area is generally the same, only the update time of the disaster recovery policy may be obtained. And if the difference value between the current time and the updating time is less than the preset threshold value, judging that the disaster recovery strategy and the first configuration information are in the cache validity period, otherwise, judging that the disaster recovery strategy and the first configuration information are not in the cache validity period. If the disaster recovery strategy and the first configuration information are determined to be in the cache validity period according to the updating time, the disaster recovery strategy and the first configuration information are obtained from the cache region; and if the disaster recovery strategy and the configuration information are determined not to be in the cache life period according to the updating time, acquiring the disaster recovery strategy and the first configuration information from a preset first service end.

Therefore, under the condition that the cache information is available, the disaster recovery strategy and the configuration information are directly obtained from the cache information, and the obtaining efficiency can be improved; and under the condition that the cache information is unavailable, acquiring the disaster recovery strategy and the first configuration information from the first service terminal, and ensuring that the latest disaster recovery strategy and the first configuration information can be acquired in time.

In another example, if the update time of the disaster recovery policy and the first configuration information in the cache region are different, a first update time of the disaster recovery policy for switching the primary response side to the standby response side and a second update time of the first configuration information in the cache region may be obtained, and if it is determined that the disaster recovery policy and the first configuration information are both within the cache lifetime according to the first update time and the second update time, the disaster recovery policy and the first configuration information are obtained from the cache region; if the disaster recovery policy or the first configuration information is determined not to be within the cache validity period according to the first update time and the second update time, the disaster recovery policy or the first configuration information may be acquired from the first service end.

It can be understood that, only a few ways of obtaining the disaster recovery policy and the first configuration information are listed above, and details are not repeated for other ways. After the first configuration information is obtained, the second configuration information of the request end can be updated through the first configuration information, and the main response end is controlled to be switched into the standby response end and accessed.

In practical application, if the disaster recovery policy includes the routing information, the routing information of the request end and the response end needs to be guaranteed to be consistent, and then the corresponding access request can be correctly processed. In view of this, in an optional implementation, the disaster recovery policy further includes identification information for identifying the routing information; the controlling the main response end to be switched into the standby response end and to access comprises the following steps:

The identification information may be a name and a version number of the routing information, or may be any combination of numbers, character strings, symbols, and the like, as long as the identification information uniquely identifies the routing information. In the standby response end, if the standby response end does not need to call the next-stage response end again for service processing, the standby response end executes service processing corresponding to the access request. If the standby response end needs to call the next-level response end to perform service processing, the standby response end can determine routing information consistent with the routing information of the request end in the standby response end according to the identification information, and call the next-level response end to perform corresponding service processing based on the routing information of the standby response end and the access request.

The request end or the response end can cache respective routing information, identification information and configuration information, based on which, the local end routing information corresponding to the upper level routing information can be determined according to the upper level identification information, and then the local end routing information is utilized to search the next level service node.

Therefore, the disaster recovery strategy also comprises identification information used for identifying the routing information, and the access request carrying the identification information is sent to the standby response end, so that the request end and the standby response end can use the consistent routing information for routing, the standby response end can conveniently and quickly execute corresponding service processing, and the processing efficiency is improved.

In an alternative implementation manner, as shown in fig. 2E, fig. 2E is a flowchart of an information processing method shown in this disclosure according to an exemplary embodiment, where the request end is a service intermediate node, the service intermediate node is a service node that needs to invoke a next service node in order to respond to an access request sent by a previous request end, and the identification information is further used to represent version information of the routing information. On the basis of the foregoing embodiment, the method describes a process of performing judgment and corresponding processing according to the identification information in the access request and the identification information of the local terminal when receiving the access request sent by the upper-level request terminal, and includes the following steps 501 and 503:

in step 501, an access request sent by a previous-level request end is received, where the received access request carries identification information of routing information in the previous-level request end.

In step 502, if it is determined that the version of the routing information of the upper level request end is lower than the version of the routing information of the request end according to the received identification information and the identification information of the request end, the routing information of the request end is fed back to the upper level request end.

In step 503, if it is determined that the version of the routing information of the upper level request end is higher than the version of the routing information of the request end according to the received identification information and the identification information of the request end, the routing information of the request end is obtained from the first server end.

As one implementation manner, the identification information may be a version number, and if the received version number is lower than the version number of the request end (the request end, for distinguishing the previous request end, this request end is abbreviated), it is determined that the version of the routing information of the previous request end is lower than the version of the routing information of the request end; and if the received version number is higher than the version number of the request end, determining that the version of the routing information of the upper-level request end is higher than the version of the routing information of the request end.

Further, if it is determined that the version of the routing information of the upper level request end is higher than the version of the routing information of the request end and it is determined that there is no configuration information that is suitable for the upper level request end locally according to the received identification information and the identification information of the request end, the configuration information required by the request end corresponding to the upper level request end can be obtained from the first service end, and the request end is configured and updated by using the obtained configuration information.

Correspondingly, in the response end, the access request sent by the request end is received, and the received access request carries the identification information of the routing information in the request end. And if the version of the routing information of the request end is lower than that of the routing information of the response end according to the received identification information and the identification information of the response end, feeding the routing information of the response end back to the request end. If the version of the routing information of the request end is determined to be higher than the version of the routing information of the response end according to the received identification information and the identification information of the response end, and it is determined that the configuration information of the adaptive request end does not exist locally, the configuration information required by the response end corresponding to the request end can be obtained from the first server end, and the obtained configuration information is used for updating the configuration of the response end.

In addition, the layout modes of the main response end and the standby response end can be configured according to requirements, and the two modes are listed for illustration in the disclosure.

In an optional implementation manner, the service nodes may be divided into different service clusters according to service categories, each service node in each service cluster only provides a fixed category of service, and in order to avoid disaster tolerance of a server, each service node in the same service cluster may be provided with processing logic having the same service type, so that when one of the service nodes fails, a request response is performed through a standby service node. As shown in fig. 3A, fig. 3A is an architectural diagram of another distributed system shown in accordance with an example embodiment of the present disclosure. In this architecture, there may be four service clusters A, B, C, D, and all service nodes laid out in each service cluster may provide the same type of processing logic. For example, servera1.1 to servera1.3 may implement the same processing logic, and when one of the serving nodes is the current serving node, the other may be one of the alternative serving nodes.

In another optional implementation manner, in order to improve the robustness of the distributed system, more than two service clusters may be divided according to service categories, where each service cluster includes more than two service nodes; each service node is provided with service processing logic of all service types in the system, and the service processing logic can be used for responding to the service request of the service cluster. As shown in fig. 3B, fig. 3B is an architectural diagram of another distributed system illustrated by the present disclosure, according to an exemplary embodiment. In fig. 3B, four service clusters A, B, C, D are provided, each service cluster includes more than two service nodes, each service node has service processing logic of all service classes in the distributed system, that is, all service nodes in all service clusters can be functionally equivalent, and then the service nodes with equivalent functions are divided, and a part of service nodes are used for providing class a services to form a service cluster a; a part of service nodes are used for providing class B service to form a service cluster B; a part of service nodes are used for providing C-type services to form a service cluster C; and a part of service nodes are used for providing D-type services to form a service cluster D. And under the condition that all the service clusters operate normally, the service request of each service type is responded by the service cluster fixedly corresponding to the service type. Under the condition that a certain service cluster runs abnormally, the service cluster responding to the service request of the corresponding service class can be dynamically adjusted.

It can be understood that the present disclosure is not limited to the layout manners of the two service nodes and the service categories, and other layout manners in the related art may be adopted, and the disaster recovery policy may be determined based on the layout manners of the service nodes and the service categories, which are not described herein again.

The various technical features in the above embodiments can be arbitrarily combined, so long as there is no conflict or contradiction between the combinations of the features, but the combination is limited by the space and is not described one by one, and therefore, any combination of the various technical features in the above embodiments also belongs to the scope disclosed in the present specification.

Corresponding to the embodiment of the disaster recovery method, the disclosure also provides embodiments of a disaster recovery device, and an apparatus and a computer-readable storage medium applied thereto.

As shown in fig. 4, fig. 4 is a block diagram of a disaster recovery device shown in this disclosure according to an exemplary embodiment, where the disaster recovery device is applied to a request end, the request end is respectively connected to a main response end and a standby response end, and the main response end and the standby response end provide the same data service, and the disaster recovery device includes:

the policy obtaining module 41 is configured to, when it is determined that the main response end is abnormal in operation, obtain a disaster recovery policy for switching the main response end to the standby response end.

The information obtaining module 42 is configured to determine a standby response end according to the disaster recovery policy, and obtain first configuration information required by a request end when requesting from the standby response end.

A configuration updating module 43 configured to update the second configuration information of the requesting end through the first configuration information.

And a switching module 44 configured to control the main responder to be switched to the standby responder and perform access.

As can be seen from the above embodiments, when determining that the main response end is abnormal in operation, the request end may actively acquire a disaster recovery policy for switching the main response end to the backup response end, determine the backup response end according to the disaster recovery policy, acquire first configuration information required by the request end when requesting from the backup response end, and update second configuration information of the request end through the first configuration information, thereby achieving consistency of the configuration information of the request end and the backup response end, and then control the main response end to switch to the backup response end and perform access, thereby achieving successful disaster recovery. And the dependency of the access terminal and the response terminal is reduced.

In an optional implementation manner, the policy obtaining module 41 is specifically configured to: and acquiring a disaster recovery strategy for switching the main response terminal into the standby response terminal from the cache region or the first server terminal.

The information obtaining module 42 is specifically configured to: determining a standby response end according to the disaster recovery strategy, and acquiring first configuration information required by a request end when the request is made to the standby response end from a cache region or the first server end; the first server side stores the latest disaster recovery strategy and the first configuration information.

As can be seen from the above embodiments, the disaster recovery policy and the first configuration information can be directly obtained from the cache region, thereby improving the obtaining efficiency. In addition, since the latest disaster recovery strategy and the first configuration information are stored in the first service end, the disaster recovery strategy and the first configuration information can be directly obtained from the first service end, so that the latest information is obtained, and the disaster recovery failure caused by untimely cache updating is avoided.

As shown in fig. 5, fig. 5 is a block diagram of another disaster recovery apparatus shown in the present disclosure according to an exemplary embodiment, on the basis of the foregoing embodiment shown in fig. 4, the apparatus further includes an information updating module 45 configured to: and updating the disaster recovery strategy and the first configuration information in the cache region.

As can be seen from the foregoing embodiments, the disaster recovery policy and the first configuration information in the cache region are updated, so that the disaster recovery policy and the first configuration information stored in the cache region are ensured to be the latest or relatively newer information.

As shown in fig. 6, fig. 6 is a block diagram of another disaster recovery device shown in the present disclosure according to an exemplary embodiment, on the basis of the foregoing embodiment shown in fig. 5, the information updating module 45 includes at least one of the following sub-modules, and for clarity of illustration, the sub-modules that the information updating module 45 may include are shown in fig. 6:

the first information updating sub-module 451 is configured to obtain the disaster recovery policy and the first configuration information from the first service end at preset time intervals, and update the disaster recovery policy and the first configuration information in the cache region.

The second information updating sub-module 452 is configured to receive the disaster recovery policy and the first configuration information sent by the second server, and update the disaster recovery policy and the first configuration information in the cache region.

As shown in fig. 7, fig. 7 is a block diagram of another disaster recovery device shown in the present disclosure according to an exemplary embodiment, where on the basis of the foregoing embodiment shown in fig. 4, the policy obtaining module 41 includes:

the time obtaining sub-module 411 is configured to obtain an update time of the disaster recovery policy for switching the primary response end to the standby response end in the buffer.

A first policy obtaining sub-module 412 configured to obtain the disaster recovery policy from the cache region if it is determined that the disaster recovery policy is within the cache validity period according to the update time.

And a second policy obtaining sub-module 413, configured to obtain the disaster recovery policy from the first service end if it is determined that the disaster recovery policy is not within the cache validity period according to the update time.

As can be seen from the above embodiments, in the case that the cache information is available, the disaster recovery policy and the configuration information are directly obtained from the cache information, so that the obtaining efficiency can be improved; and under the condition that the cache information is unavailable, acquiring the disaster recovery strategy and the first configuration information from the first service terminal, and ensuring that the latest disaster recovery strategy and the first configuration information can be acquired in time.

In an optional implementation manner, the disaster recovery policy includes routing information, a request path corresponding to an access request is recorded in the routing information, and the access request is a request sent from a request end to a main response end.

In an optional implementation manner, the disaster recovery policy further includes identification information for identifying the routing information; the switching module 44 is specifically configured to: sending the access request carrying the identification information to the standby response end, wherein the identification information is used for prompting the standby response end to: routing information used by the requesting end.

As can be seen from the above embodiments, since the disaster recovery policy further includes identification information for identifying the routing information, and the access request carrying the identification information is sent to the standby response end, it is possible to implement that the request end and the response end use consistent routing information for routing, which is convenient for the standby response end to quickly and accurately execute corresponding service processing, and improve processing efficiency.

As shown in fig. 8, fig. 8 is a block diagram of another disaster recovery apparatus according to an exemplary embodiment shown in the present disclosure, in this embodiment, based on the foregoing embodiment shown in fig. 4, where the requesting end is a serving intermediate node, the serving intermediate node is a serving node that needs to invoke a next-level serving node in order to respond to an access request sent by a previous-level requesting end, and the identification information is further used to represent version information of routing information, and the apparatus further includes:

an information receiving module 46, configured to receive an access request sent by a previous-level request end, where the received access request carries identification information of routing information in the previous-level request end;

an information feedback module 47, configured to feed back the request end routing information to the upper level request end if it is determined that the version of the routing information of the upper level request end is lower than the version of the routing information of the request end according to the received identification information and the identification information of the request end;

the policy obtaining module 41 is further configured to obtain the routing information of the request end from the first server end if it is determined that the version of the routing information of the upper-level request end is higher than the version of the routing information of the request end according to the received identification information and the identification information of the request end.

It can be seen from the above embodiments that, when the version of the routing information of the previous-stage request end is lower than the version of the routing information of the present request end, the routing information of the present request end can be fed back to the previous-stage request end, so that the previous-stage request end can quickly update the routing information, and the previous-stage request end is prevented from sending a request to a response end with abnormal operation, thereby improving the processing efficiency. In addition, when the version of the routing information of the upper-level request end is determined to be higher than that of the routing information of the request end, the latest routing information of the request end can be obtained from the first service end, the request end can quickly update the routing information, and the request end is prevented from calling the lower-level response end with abnormal operation.

Correspondingly, the present disclosure further provides a service device, where the service device is connected to a main service device and a standby service device, and the main service device and the standby service device provide the same data service, including: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to:

and when the main response end is determined to be abnormal in operation, acquiring a disaster recovery strategy for switching the main service equipment into the standby service equipment.

And determining the standby service equipment according to the disaster recovery strategy, and acquiring first configuration information required by a request terminal when the request is made to the standby service equipment.

And updating second configuration information of the request terminal through the first configuration information.

Accordingly, the present disclosure also provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, performs the steps of any of the methods described above.

The present disclosure may take the form of a computer program product embodied on one or more storage media including, but not limited to, disk storage, CD-ROM, optical storage, and the like, having program code embodied therein. Computer-usable storage media include permanent and non-permanent, removable and non-removable media, and information storage may be implemented by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of the storage medium of the computer include, but are not limited to: phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, may be used to store information that may be accessed by a computing device.

The specific details of the implementation process of the functions and actions of each module in the device are referred to the implementation process of the corresponding step in the method, and are not described herein again.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, wherein the modules described as separate parts may or may not be physically separate, and the parts displayed as modules may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the disclosed solution. One of ordinary skill in the art can understand and implement it without inventive effort.

As shown in fig. 9, fig. 9 is a block diagram illustrating an apparatus for disaster recovery according to an exemplary embodiment.

For example, the apparatus 900 may be provided as a server device. Referring to fig. 9, the apparatus 900 includes a processing component 922, which further includes one or more processors, and memory resources, represented by memory 932, for storing instructions, such as applications, that are executable by the processing component 922. The application programs stored in memory 932 may include one or more modules that each correspond to a set of instructions. Further, the processing component 922 is configured to execute instructions to perform the disaster recovery method described above.

The disaster recovery device 900 can also include a power component 926 configured to perform power management of the device 900, a wired or wireless network interface 950 configured to connect the device 900 to a network, and an input output (I/O) interface 958. The apparatus 900 may operate based on an operating system stored in the memory 932.

Wherein the instructions in the memory 932, when executed by the processing component 922, enable the apparatus 900 to perform a disaster recovery method comprising:

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It will be understood that the present disclosure is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

The above description is only exemplary of the present disclosure and should not be taken as limiting the disclosure, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present disclosure should be included in the scope of the present disclosure.

Claims

1. A disaster recovery method is characterized in that the method is applied to a request end, the request end is respectively connected with a main response end and a standby response end, and the main response end and the standby response end provide the same data service, and the method comprises the following steps:

controlling the main response end to be switched into a standby response end and accessing;

the disaster recovery strategy comprises routing information and identification information, wherein a request path corresponding to an access request is recorded in the routing information, and the access request is a request sent from a request end to a main response end;

the identification information is used for representing the version information of the routing information;

the request end is a service intermediate node, the service intermediate node is a service node which needs to call a next-level service node in order to respond to an access request sent by a previous-level request end, and the method further comprises the following steps:

2. The method according to claim 1, wherein the obtaining the disaster recovery policy for switching the primary responder to the standby responder comprises:

3. The method of claim 2, further comprising: and updating the disaster recovery strategy and the first configuration information in the cache region.

4. The method of claim 3, wherein the updating the disaster recovery policy and the first configuration information in the cache comprises:

5. The method according to claim 2, wherein the obtaining the disaster recovery policy for switching the primary responder to the standby responder from the cache region or the first server comprises:

6. The method of claim 1, wherein the controlling the master responder to switch to a standby responder and perform access comprises:

7. A disaster recovery device is characterized in that the device is applied to a request end, the request end is respectively connected with a main response end and a standby response end, and the main response end and the standby response end provide the same data service, and the device comprises:

the switching module is configured to control the main response end to be switched into the standby response end and access the standby response end;

the request end is a service intermediate node, the service intermediate node is a service node which needs to call a next-level service node in order to respond to an access request sent by a previous-level request end, and the device further comprises:

8. The apparatus of claim 7, wherein the policy acquisition module is specifically configured to: acquiring a disaster recovery strategy for switching a main response end into a standby response end from a cache area or a first server end;

9. The apparatus of claim 8, further comprising an information update module configured to: and updating the disaster recovery strategy and the first configuration information in the cache region.

10. The apparatus of claim 9, wherein the information update module comprises at least one of the following sub-modules:

11. The apparatus of claim 8, wherein the policy obtaining module comprises:

12. The apparatus of claim 7, wherein the switching module is specifically configured to: sending the access request carrying the identification information to the standby response end, wherein the identification information is used for prompting the standby response end to: routing information used by the requesting end.

13. A service device, wherein the service device is connected to a main service device and a standby service device, respectively, and the main service device and the standby service device provide the same data service, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to:

when the main service equipment is determined to be abnormal in operation, a disaster recovery strategy for switching the main service equipment into the standby service equipment is obtained;

determining a standby service device according to the disaster tolerance strategy, and acquiring first configuration information required by the service device when the request is made to the standby service device;

updating second configuration information of the service equipment through the first configuration information;

controlling the main service equipment to be switched into standby service equipment and accessing;

the disaster recovery strategy comprises routing information and identification information, wherein a request path corresponding to an access request is recorded in the routing information, and the access request is a request sent to a main service device by a service device;

the service equipment is a service intermediate node, and the service intermediate node is a service node which needs to call a next-level service node in order to respond to an access request sent by the previous-level service equipment; receiving an access request sent by a superior service device, wherein the received access request carries identification information of routing information in the superior service device;

if the version of the routing information of the upper-level service equipment is lower than the version of the routing information of the service equipment according to the received identification information and the identification information of the service equipment, feeding the routing information of the service equipment back to the upper-level service equipment;

and if the version of the routing information of the upper-level service equipment is higher than the version of the routing information of the service equipment according to the received identification information and the identification information of the service equipment, acquiring the routing information of the service equipment from the first service terminal.

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