Disaster recovery method, device and equipment based on gateway scheduling and storage medium

Abstract

The invention discloses a disaster recovery method, device and equipment based on gateway scheduling and a storage medium, and the method comprises the steps: collecting multi-mode operation state data related to a target business service, the multi-mode operation state data comprising network layer state data, data layer copy state data and application layer business state data; performing correlation analysis on the multi-mode operation state data, and generating a disaster recovery decision instruction according to a correlation analysis result; according to the disaster recovery decision instruction, the service flow is scheduled to a target data center through a unified gateway; and based on a plurality of atomic tasks in the atomic task library, generating and executing a task arrangement process corresponding to the disaster recovery decision instruction according to the current disaster recovery scene. According to the method, the multi-modal operation state data is subjected to association analysis to generate the disaster recovery decision instruction to schedule the service flow, and the task arrangement process is generated and executed based on the atomic task library and the current disaster recovery scene, so that the disaster recovery switching accuracy, timeliness and automation degree are improved, and the service continuity is guaranteed.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, and in particular to a disaster recovery method, apparatus, device, and storage medium based on gateway scheduling. Background Technology

[0002] The financial industry has extremely stringent requirements for business continuity and data security. To address the risks of service interruptions caused by natural disasters, equipment failures, or human error, a "two-site, three-center" disaster recovery architecture has become the mainstream construction model in the industry. This architecture typically includes a production center, a local disaster recovery center, and an off-site disaster recovery center, designed to ensure that critical business operations continue to operate even if a failure occurs at any single site or even within the same city.

[0003] To achieve this goal, existing technical solutions generally rely on a combination of multiple fundamental technologies. At the data level, asynchronous or synchronous data replication technologies are primarily used to replicate production data to various disaster recovery centers in real time or near real time. At the disaster recovery management level, dedicated disaster recovery management software is deployed to monitor the data replication status and the health of each center, and can trigger automated failover processes when a fault is detected. At the application high availability level, load balancing technology is often used to distribute business traffic and avoid single points of failure.

[0004] However, existing technical solutions still have significant limitations in practical applications, resulting in insufficient accuracy, timeliness, and overall automation in disaster recovery switching, making it difficult to fully meet the continuity requirements of financial businesses. Specifically: First, the perception dimension is singular; existing monitoring focuses primarily on isolated indicators such as network connectivity or database master-slave replication status, making it difficult to accurately distinguish between transient fluctuations and permanent failures, easily leading to misjudgments or omissions. Second, the decision-making mechanism is rigid; switching decisions are often based on simple timeout thresholds or lost heartbeats, which may lead to unnecessary switching (such as transient network problems) or switching too late (such as when the application can no longer provide normal service but the database connection still exists), and it is impossible to execute optimal "data rescue" actions before the site completely fails. Third, the execution process is highly coupled and lacks flexibility; disaster recovery actions such as traffic switching, DNS updates, and service startup / shutdown are usually written as fixed hard-coded scripts or loose manual processes, making the switching process complex, time-consuming, and difficult to dynamically generate and execute the optimal task execution sequence according to different failure scenarios (such as network partitioning, data center power outages, and database crashes), resulting in low emergency response efficiency.

[0005] Therefore, there is an urgent need for a disaster recovery method based on gateway scheduling that can improve the accuracy, timeliness, and automation of disaster recovery switching, thereby ensuring business continuity. Summary of the Invention

[0006] The main objective of this invention is to provide a disaster recovery method, apparatus, device, and storage medium based on gateway scheduling, aiming to solve the technical problems of low accuracy, timeliness, and automation of disaster recovery switching in existing technologies, which in turn affect business continuity.

[0007] To achieve the above objectives, the present invention provides a disaster recovery method based on gateway scheduling, the method comprising the following steps: Collect multimodal operational status data related to the target business service, including network layer status data, data layer replication status data, and application layer business status data; The multimodal operating status data is subjected to correlation analysis, and disaster recovery decision instructions are generated based on the correlation analysis results; According to the disaster recovery decision instructions, business traffic is routed to the target data center through a unified gateway; Based on multiple atomic tasks in the atomic task library, a task orchestration process corresponding to the disaster recovery decision instruction is generated and executed according to the current disaster recovery scenario.

[0008] Optionally, the step of performing correlation analysis on the multimodal operating status data and generating disaster recovery decision instructions based on the correlation analysis results includes: The network layer status data, the data layer replication status data, and the application layer service status data are correlated and analyzed to obtain correlation analysis results. When the correlation analysis results indicate a network anomaly, based on the data layer replication status data and the application layer business status data, it is determined whether to trigger traffic switching between data centers. Based on the judgment result, a disaster recovery decision instruction is generated, which includes the target data center identifier.

[0009] Optionally, the step of determining whether to trigger traffic switching between data centers based on the data layer replication status data and the application layer service status data when the correlation analysis result indicates a network anomaly includes: When the correlation analysis result indicates a network anomaly, obtain the data replication delay in the data layer replication status data and the core business transaction success rate in the application layer business status data; If the data replication delay is lower than the first preset threshold and the core business transaction success rate is higher than the second preset threshold, then it is determined that traffic switching between data centers will not be triggered. If the data replication delay is higher than the first preset threshold, or the core business transaction success rate is lower than the second preset threshold, then it is determined that a traffic switch between data centers will be triggered.

[0010] Optionally, the step of routing service traffic to the target data center through a unified gateway according to the disaster recovery decision instruction includes: Identify the request characteristics of business traffic, and determine a traffic scheduling strategy that matches the request characteristics based on the target data center identifier in the disaster recovery decision instruction and the request characteristics. According to the traffic scheduling strategy, the service traffic is routed to the corresponding service node in the target data center through a unified gateway.

[0011] Optionally, before the step of routing the service traffic to the corresponding service node in the target data center through the unified gateway according to the traffic scheduling strategy, the method further includes: Perform multi-dimensional health checks on each service node in the target data center to obtain health check results. The health checks include node connectivity, application service port status, and business interface response status. Based on the health check results, dynamically update the weight status of the corresponding service node in the domain name resolution records associated with the target business service; Based on the updated domain name resolution records, the business traffic arriving at the unified gateway is resolved to service nodes that meet the health status requirements.

[0012] Optionally, the step of generating and executing a task orchestration process corresponding to the disaster recovery decision instruction based on multiple atomic tasks in the atomic task library according to the current disaster recovery scenario includes: Determine the real-time health status score for each atomic task in the atomic task library; Based on the real-time health status score, select atomic tasks from the atomic task library that meet the preset conditions of the real-time health status score; Based on the scenario type of the current disaster recovery scenario, select the corresponding task combination logic from the orchestration rule base; Based on the task combination logic and the selected atomic tasks, a task orchestration process corresponding to the disaster recovery decision instruction is generated and executed.

[0013] Optionally, the step of collecting multimodal operational status data related to the target business service includes: Network layer status data reflecting communication quality is collected from monitoring agents deployed in multiple data centers. This network layer status data includes network latency, packet loss rate, and bandwidth utilization. Data layer replication status data reflecting the data synchronization status is collected from the data replication link connecting the production center and the disaster recovery center. The data layer replication status data includes data replication latency and data consistency point information. By calling the application programming interface of the target business service, application layer business status data reflecting the status of business functions is collected. The application layer business status data includes the core business transaction success rate and the response status of key APIs. The network layer state data, the data layer replication state data, and the application layer service state data are used as multimodal operational state data.

[0014] Furthermore, to achieve the above objectives, the present invention also proposes a disaster recovery device based on gateway scheduling, the device comprising: The data acquisition module is used to collect multimodal operational status data related to the target business service. The multimodal operational status data includes network layer status data, data layer replication status data, and application layer business status data. The decision generation module is used to perform correlation analysis on the multimodal operating status data and generate disaster recovery decision instructions based on the correlation analysis results. The traffic scheduling module is used to schedule business traffic to the target data center through the unified gateway according to the disaster recovery decision instructions; The task execution module is used to generate and execute a task orchestration process corresponding to the disaster recovery decision instruction based on multiple atomic tasks in the atomic task library and the current disaster recovery scenario.

[0015] Furthermore, to achieve the above objectives, the present invention also proposes a gateway scheduling-based disaster recovery device, the device comprising: a memory, a processor, and a gateway scheduling-based disaster recovery program stored in the memory and executable on the processor, the gateway scheduling-based disaster recovery program being configured to implement the steps of the gateway scheduling-based disaster recovery method described above.

[0016] Furthermore, to achieve the above objectives, the present invention also proposes a storage medium storing a gateway-based disaster recovery program, wherein the gateway-based disaster recovery program, when executed by a processor, implements the steps of the gateway-based disaster recovery method described above.

[0017] This invention discloses a method for collecting multimodal operational status data related to a target business service. This multimodal operational status data includes network layer status data, data layer replication status data, and application layer business status data. The method involves performing correlation analysis on the multimodal operational status data and generating disaster recovery decision instructions based on the analysis results. According to these instructions, business traffic is routed to the target data center via a unified gateway. Based on multiple atomic tasks in an atomic task library, a task orchestration process corresponding to the disaster recovery decision instructions is generated and executed according to the current disaster recovery scenario. Because this invention generates disaster recovery decision instructions through correlation analysis of multimodal operational status data, routes business traffic to the target data center via a unified gateway based on these instructions, and dynamically generates and executes a task orchestration process based on the atomic task library and the current disaster recovery scenario, compared to existing technologies, this invention improves the accuracy, timeliness, and automation of disaster recovery switching, thereby ensuring business continuity. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating the first embodiment of the disaster recovery method based on gateway scheduling of the present invention. Figure 2 This is a schematic diagram of the multimodal network concern process in the disaster recovery method based on gateway scheduling of the present invention; Figure 3 This is a schematic diagram of atomic task orchestration in the disaster recovery method based on gateway scheduling of the present invention; Figure 4 This is a schematic diagram of the disaster recovery process of the customer service system in the disaster recovery method based on gateway scheduling of the present invention; Figure 5 This is a flowchart illustrating the second embodiment of the disaster recovery method based on gateway scheduling of the present invention. Figure 6 This is a flowchart illustrating the third embodiment of the disaster recovery method based on gateway scheduling of the present invention. Figure 7 This is a schematic diagram illustrating the generative atomic task recommendation in the gateway scheduling-based disaster recovery method of the present invention; Figure 8 This is a structural block diagram of the first embodiment of the disaster recovery device based on gateway scheduling of the present invention; Figure 9 This is a schematic diagram of the disaster recovery device based on gateway scheduling in the hardware operating environment involved in the embodiments of the present invention.

[0019] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0021] This invention provides a disaster recovery method based on gateway scheduling, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the disaster recovery method based on gateway scheduling of the present invention.

[0022] In this embodiment, the disaster recovery method based on gateway scheduling includes steps S10 to S40: Step S10: Collect multimodal operational status data related to the target service. The multimodal operational status data includes network layer status data, data layer replication status data, and application layer service status data.

[0023] It should be noted that the executing entity in this embodiment can be a computer server device with data processing, network communication, and program execution functions applied in disaster recovery scenarios, such as a server, tablet computer, or personal computer, or an electronic device capable of performing the above functions (such as a disaster recovery device based on gateway scheduling). The following uses a system containing a disaster recovery device based on gateway scheduling (hereinafter referred to as the system) as an example to illustrate this embodiment and the following embodiments.

[0024] It should be noted that the target business service can refer to the object and goal of the entire disaster recovery protection action. The target business service can be one or more specific, core business application systems that need to be protected by the disaster recovery mechanism, such as payment transaction services, credit approval systems, customer account inquiry services, and real-time risk control engines. If these services are interrupted, it will directly lead to business shutdowns, transaction failures, or impaired customer experience, and they are the priority targets for disaster recovery solutions.

[0025] It should be understood that collecting multimodal operational status data can overcome the inherent shortcomings of traditional disaster recovery monitoring, such as its single dimension and one-sided perspective, enabling a comprehensive, three-dimensional, and accurate perception of the system's health status. Collecting multimodal operational status data is the cornerstone for achieving intelligent, precise, and automated disaster recovery.

[0026] In practical implementation, network layer status data reflecting communication quality can be collected from monitoring agents deployed in multiple data centers. This network layer status data includes network latency, packet loss rate, and bandwidth utilization. Data layer replication status data reflecting data synchronization status can be collected from the data replication link connecting the production center and the disaster recovery center. This data layer replication status data includes data replication latency and data consistency point information. Application layer business status data reflecting the business function status can be collected by calling the application programming interface of the target business service. This application layer business status data includes core business transaction success rate and key API response status. The network layer status data, the data layer replication status data, and the application layer business status data are used as multimodal operational status data.

[0027] Understandably, multiple data centers can refer to clusters of computing facilities distributed across different geographical locations and interconnected via a network to achieve disaster recovery goals. For example, in a "two-site, three-center" disaster recovery architecture, there is one production center, one local disaster recovery center, and one off-site disaster recovery center.

[0028] It should be understood that a monitoring agent can refer to a software program or service deployed on servers, network devices, or application containers within each data center (including production centers and disaster recovery centers). It can act as a data collector, passively receiving or actively capturing network layer status data from components such as the operating system, network stack, database, and application middleware of its node, according to preset frequencies and metrics.

[0029] It should be noted that a production center can refer to the main data center that carries out the daily operation of core businesses and directly processes user transactions and requests. A disaster recovery center can refer to a backup data center built to cope with possible failures of the production center, used to take over business in the event of a disaster. Depending on the geographical location and recovery objectives, it can be divided into: local disaster recovery centers and off-site disaster recovery centers.

[0030] Local disaster recovery centers are located close to the production center (usually within tens of kilometers), have low network latency, and are primarily used to handle data center-level failures, enabling synchronous or near-synchronous data replication. Off-site disaster recovery centers are located far from the production center and are used to handle city-level regional disasters (such as earthquakes and floods), typically employing asynchronous data replication.

[0031] It should be understood that a data replication link can refer to a dedicated logical or physical channel established between a production center and one or more disaster recovery centers for the continuous transmission of data changes. This link is responsible for replicating data from the production center (including database transaction logs, file block changes, storage volume snapshots, etc.) to the disaster recovery center in real-time or near real-time, and is a core technology channel ensuring data recoverability. Data replication links can be implemented based on technologies such as database master-slave replication, remote storage array replication, or application-layer logical replication.

[0032] It's important to clarify that data replication latency refers to the time difference between a data change occurring in the production center and its complete application (replay) in the disaster recovery center. For example, in MySQL master-slave replication, this latency is represented by Seconds_Behind_Master, a key quantitative indicator for measuring the "freshness" of disaster recovery data and the recovery point objective (RPO). Data consistency point information refers to logical identifiers used to uniquely identify the order and position of committed transactions in the database. For example, GTID in MySQL and LSN in PostgreSQL. By comparing the point information of the production center and the disaster recovery center, we can accurately calculate how many transactions or bytes the disaster recovery center is lagging behind in the data sequence, thus providing a more accurate measure of consistency status than simple time latency.

[0033] It's important to note that the core business transaction success rate refers to the percentage of critical end-to-end transactions (such as "user payment" and "order creation") successfully completed by the system within a preset time period. It directly reflects the health of the application system from the perspective of end-users and business value. Even if the underlying infrastructure (servers, databases) appears normal, frequent business transaction failures indicate serious system problems. The critical API response status refers to obtaining the response results by simulating or calling the application's core service interfaces (APIs). Monitoring includes, but is not limited to, whether the HTTP status code is successful (e.g., 200), whether the response time is within the threshold, and whether the returned message content meets expectations. This is a proactive probe of the application layer from the perspective of service availability and functional correctness, which is more in-depth than simply checking whether the application process exists (port liveness).

[0034] Step S20: Perform correlation analysis on the multimodal operating status data, and generate disaster recovery decision instructions based on the correlation analysis results.

[0035] It should be understood that the aforementioned correlation analysis can be a process of fusing, comparing, and logically reasoning across multiple levels and dimensions, in order to extract accurate judgments about the overall health status of the system and the nature of failures from isolated monitoring indicators. Disaster recovery decision commands are operational commands that are understandable and executable by the system, derived from the results of the correlation analysis.

[0036] In a specific implementation, the network layer status data, the data layer replication status data, and the application layer service status data can be correlated and analyzed to obtain correlation analysis results. When the correlation analysis results indicate a network anomaly, based on the data layer replication status data and the application layer service status data, it is determined whether to trigger traffic switching between data centers. A disaster recovery decision instruction is generated based on the determination result, and the disaster recovery decision instruction includes the target data center identifier.

[0037] It should be understood that a target data center can refer to a data center that will handle subsequent related business traffic. A target data center identifier can be a code or parameter that uniquely identifies the target data center within the system.

[0038] It should be noted that when the network layer status data in the correlation analysis results indicates a network anomaly, the correlation query will examine the data replication latency in the data layer replication status data and the core business transaction success rate in the application layer business status data. If the data replication latency is lower than the first preset threshold and the core business transaction success rate is higher than the second preset threshold, it will be determined as a brief network jitter, and no traffic switching between data centers will be triggered. If the data replication latency is higher than the first preset threshold or the core business transaction success rate is lower than the second preset threshold, it will be determined as triggering a traffic switching between data centers, and then a disaster recovery decision instruction to switch to the target data center will be generated.

[0039] Furthermore, the step of determining whether to trigger traffic switching between data centers based on the data layer replication status data and the application layer service status data when the correlation analysis result indicates a network anomaly includes: when the correlation analysis result indicates a network anomaly, obtaining the data replication latency in the data layer replication status data and the core business transaction success rate in the application layer service status data; if the data replication latency is lower than a first preset threshold and the core business transaction success rate is higher than a second preset threshold, then it is determined that traffic switching between data centers will not be triggered; if the data replication latency is higher than the first preset threshold, or the core business transaction success rate is lower than the second preset threshold, then it is determined that traffic switching between data centers will be triggered.

[0040] It should be added that when the application layer business status data in the correlation analysis results indicates that the database connection has failed or the success rate of core business transactions has dropped sharply, the network layer status data is queried to confirm the liveness status of the server host machine, and the data layer replication status data is queried to confirm whether the storage layer replication is continuing. If the host machine is alive and the storage layer replication is continuing, a disaster recovery decision instruction to attempt to restart the database service is generated. If the restart fails or the conditions are not met, a disaster recovery decision instruction to switch business traffic to the target data center is generated.

[0041] It should be added that when the correlation analysis results predict that the performance of the primary data center will suffer a serious decline or become unavailable, an active disaster recovery decision instruction is generated. This instruction first triggers the "stop writing and catch up with data" process, that is, suspending new write transactions in the primary data center and accelerating data replication in the backup data center to catch up with the data. After the data layer replication status data shows that the data latency is lower than the third preset threshold, the final decision instruction (i.e., the disaster recovery decision instruction) to switch business traffic to the target data center is generated.

[0042] It should be understood that a primary data center can refer to the data center that handles core production business traffic during normal business operations. It is usually the main entry point for business traffic and the core of data writing, and is in an active service state. A backup data center can refer to a backup site that is built in advance to cope with possible failures or disasters of the primary data center. During normal operation, it is usually in a standby or partially active state.

[0043] It should be noted that by correlating (or fusing) multimodal operational status data from the network layer, data layer, and application layer for correlation analysis, it is possible to more accurately identify real faults and transient anomalies, enabling intelligent arbitration and thus improving the accuracy and timeliness of disaster recovery decisions. For example, when a network timeout occurs but data replication latency is low and business transactions are normal, it can be determined as a transient jitter, thus avoiding a switchover and significantly reducing false and blind switchovers.

[0044] For example, refer to Figure 2 , Figure 2This diagram illustrates the multimodal network status process in the gateway-based disaster recovery method of this invention. The system uses a multimodal perception module to collect network layer status data, data layer replication status data, and application layer business status data in parallel, thus constructing a multidimensional, real-time panoramic view of the system's operational status. This data is then input into the core fusion analysis and decision-making module. In this module, the data fusion and correlation analysis stage first correlates and enriches the context of the multimodal operational status data, providing a decision-making basis for the downstream prediction and dynamic strategy selection stages. Based on the analysis results, this stage assesses potential risks and impacts, selects the optimal strategy from a preset strategy library, and submits it to the intelligent arbitration stage for final confirmation and adjudication, generating a disaster recovery decision instruction. This instruction is issued by the instruction switching module, driving the underlying multimodal execution module to work collaboratively. This module specifically implements three core atomic operations: write stop and data catch-up, aiming to pause master data writing and accelerate slave node data synchronization to ensure a consistency base; consistency enhancement and state synchronization, further strengthening the consistency of cross-node data states; and precise traffic switching, where the unified gateway accurately and smoothly schedules business traffic to the target data center according to the disaster recovery decision instruction.

[0045] Step S30: According to the disaster recovery decision instruction, the service traffic is scheduled to the target data center through the unified gateway.

[0046] It should be understood that the unified gateway is a centralized traffic entry and management component, serving as the traffic hub and intelligent traffic police for the entire system's traffic scheduling.

[0047] Understandably, in existing technologies, traffic may be scattered across different entry points or directly determined by the client, making it difficult to achieve a fast, unified global switchover during a disaster. A unified gateway, as a single, centralized traffic control point, can ensure that all traffic is processed according to its rules, thereby reliably and forcefully directing traffic from the fault center to the backup center.

[0048] In a specific implementation, step S30 may include steps S301 to S302: Step S301: Identify the request characteristics of the service traffic, and determine a traffic scheduling strategy that matches the request characteristics based on the target data center identifier in the disaster recovery decision instruction and the request characteristics.

[0049] Step S302: According to the traffic scheduling strategy, the service traffic is routed to the corresponding service node in the target data center through the unified gateway.

[0050] It should be noted that business traffic refers to the data stream of business requests from users or clients that needs to be processed and responded to by the system. This typically manifests as network request packets sent via protocols such as HTTP / HTTPS, containing the intent and parameters to access a specific financial application or service.

[0051] Understandably, the request characteristics of business traffic can refer to information extracted from business traffic that can be used to determine its business attributes and scheduling requirements. This can include, but is not limited to, HTTP methods (such as GET, POST / PUT), custom header information (information pre-defined in the request header to identify specific scheduling strategies), request content / parameters, and the request source or target service.

[0052] It should be noted that traffic scheduling strategy can refer to a set of rules, predefined or dynamically generated, used to determine which (or which group of) data centers and their internal service instances to route business traffic to, based on disaster recovery decision instructions and request characteristics. Traffic scheduling strategies include at least one of the following: a scheduling strategy that separates read and write requests based on the HTTP method or custom header information of the request; an affinity scheduling strategy that schedules related requests to the same data center based on the identifier of the accessed data; a unitized scheduling strategy that uses hash calculation based on the user identifier in the request to determine the fixed route data center; and a scheduling strategy that routes business traffic only to the corresponding service nodes within a healthy and load-controlled target data center.

[0053] For example, in a specific implementation, the step of identifying the request characteristics of the service traffic and determining a traffic scheduling strategy matching the request characteristics based on the target data center identifier in the disaster recovery decision instruction and the request characteristics may include: identifying the HTTP method or custom header information in the service traffic; if a write operation request is identified, scheduling the write operation request to the primary data center or the same data center as the request source; if a read operation request is identified, scheduling the read operation request to a data center with lower load or latency.

[0054] Step S40: Based on multiple atomic tasks in the atomic task library, generate and execute a task orchestration process corresponding to the disaster recovery decision instruction according to the current disaster recovery scenario.

[0055] It should be understood that an atomic task refers to the smallest independently executable unit of operation during disaster recovery failover or restoration. These tasks are typically standardized, repeatable operational or configuration operations. By breaking down complex disaster recovery processes into atomic tasks, standardization, automated orchestration, and granular management of operations can be achieved. An atomic task repository is a database or knowledge base that stores, manages, and maintains all defined atomic tasks and their related attributes.

[0056] It should be noted that the current disaster recovery scenario refers to the specific fault or disaster type and severity identified based on multimodal operational status data, requiring the initiation of a disaster recovery response. Examples of current disaster recovery scenarios include: network partitioning, database downtime, data center power outages / failures, and application service anomalies. Different scenarios correspond to different impact ranges, recovery goals, and optimal handling processes, serving as key inputs for triggering and guiding subsequent task orchestration.

[0057] It's important to clarify that network partitioning manifests as a surge in network latency and severe packet loss, but data replication latency may remain manageable. Database outages manifest as database connection failures, but the server operating system may still be operational. Data center power outages / failures manifest as widespread unavailability of services across all layers within a data center. Application service anomalies manifest as critical API response failures and a decline in core business transaction success rates, but the underlying infrastructure remains normal.

[0058] It should be noted that the task orchestration process can refer to the specific execution plan formed by the system automatically selecting, combining and sorting a series of atomic tasks from the atomic task library in response to the current disaster recovery scenario and disaster recovery decision instructions.

[0059] In the specific implementation, the scenario type of the current disaster recovery scenario can be obtained; according to the scenario type, the corresponding task combination logic can be matched from the orchestration rule library; based on the task combination logic, a set of atomic tasks can be selected from the atomic task library; and based on the selected atomic tasks and the task combination logic, the task orchestration process can be generated and executed.

[0060] It should be noted that different disaster recovery operations can be achieved by arranging the order of atomic tasks and modifying their parameters; atomic tasks can also be selected for process arrangement via a visual interface using push, pull, and drag methods (supporting serial and parallel execution processes).

[0061] It should be added that, in order to improve resource utilization and accurate disaster recovery response, before the step of collecting multimodal operational status data related to the target business service, the following may be included: configuring disaster recovery operation modes for multiple data centers carrying the target business service. The disaster recovery operation modes include: a disaster mode for taking over services when the primary data center fails, and an extended mode for sharing business load among multiple data centers.

[0062] For example, refer to Figure 3 , Figure 3This diagram illustrates the atomic task orchestration in the gateway-based disaster recovery method of this invention. The atomic task list (i.e., the atomic task library) is categorized and managed according to different business systems such as customer service, debt collection, and channel systems, and supports quick location via a search box. When a specific business system (e.g., the customer service system) is selected, its corresponding specific atomic tasks are expanded, including but not limited to posting channel announcements, posting customer service announcements, gateway switching traffic (financial network / fortress zone), DNS resolution switching (customer service database), customer service database primary / backup switching, and application configuration switching. These specific, highly granular operations constitute the atomic units of the task orchestration process. Different business systems are bound and associated with a set of predefined, executable atomic tasks. Based on the disaster recovery scenario involved in the customer service system, the system can automatically select a series of tasks, such as posting channel announcements, posting customer service announcements, and gateway switching traffic, from its associated set of atomic tasks, and combine and sort them according to preset logic, ultimately forming a complete, automatically executable task orchestration process.

[0063] For example, refer to Figure 4 , Figure 4 This diagram illustrates the disaster recovery process of a customer service system in the gateway-based disaster recovery method of this invention. The diagram shows a flowchart illustrating a disaster recovery scenario where the customer service system switches to Langfang extended mode. First, the atomic tasks of posting channel announcements and posting customer service announcements are executed in parallel, corresponding to the business notification step before the switchover. Then, the process converges and sequentially executes traffic scheduling operations, specifically the two subdivided atomic tasks of gateway traffic switching (financial network) and gateway traffic switching (fortress zone), which use a unified gateway to accurately route different types of network traffic. Next, the process enters the data layer consistency assurance stage, sequentially executing DNS resolution switching (customer service database) and customer service database master-slave switching. This ensures that the data access entry point and the underlying data storage are switched synchronously to maintain service continuity and meet data consistency requirements. Finally, application configuration switching is performed to complete the adaptation of the operating environment, and the entire process ends. This flowchart intuitively demonstrates how multiple independent atomic tasks are orchestrated into an automated, sequential, and parallel execution sequence according to the logical dependencies and business requirements of a specific disaster recovery scenario.

[0064] This embodiment discloses the collection of multimodal operational status data related to the target business service. This multimodal operational status data includes network layer status data, data layer replication status data, and application layer business status data. Correlation analysis is performed on the multimodal operational status data, and disaster recovery decision instructions are generated based on the analysis results. According to the disaster recovery decision instructions, business traffic is scheduled to the target data center through a unified gateway. Based on multiple atomic tasks in the atomic task library, a task orchestration process corresponding to the disaster recovery decision instructions is generated and executed according to the current disaster recovery scenario. Because this embodiment generates disaster recovery decision instructions through correlation analysis of multimodal operational status data, then schedules business traffic to the target data center through a unified gateway according to the disaster recovery decision instructions, and finally dynamically generates and executes a task orchestration process based on the atomic task library and the current disaster recovery scenario, compared to existing technologies, this embodiment improves the accuracy, timeliness, and automation of disaster recovery switching, thereby ensuring business continuity.

[0065] refer to Figure 5 , Figure 5 This is a flowchart illustrating the second embodiment of the disaster recovery method based on gateway scheduling of the present invention.

[0066] Based on the first embodiment described above, in this embodiment, before step S302, steps S3011 to S3013 are further included: Step S3011: Perform multi-dimensional health checks on each service node in the target data center to obtain health check results. The health checks include node connectivity, application service port status, and business interface response status.

[0067] Step S3012: Based on the health check results, dynamically update the weight status of the corresponding service node in the domain name resolution record associated with the target business service.

[0068] Step S3013: Based on the updated domain name resolution records, resolve the service traffic arriving at the unified gateway to service nodes that meet the health status requirements.

[0069] It should be understood that a service node can refer to an entity within a data center (whether a production center or a disaster recovery center) that actually deploys and runs instances of the target business service. Each service node carries a portion of the processing capacity of the business service and has an independent network identifier (such as an IP address).

[0070] Understandably, node connectivity refers to the smoothness of the underlying network from the monitoring point (such as a unified gateway or health check server) to the server where the target service node resides. Application service port status refers to whether the specific application process on the target service node is running and listening on the preset port. Business interface response status refers to checking whether the specific business API interface provided by the service node returns the expected and correct business response by calling it.

[0071] It should be explained that a domain name resolution record can refer to a mapping relationship stored in the DNS system, which resolves a domain name to one or more IP addresses.

[0072] It's important to note that the weight status of a service node can refer to a numerical priority or traffic proportion assigned to each service node during traffic scheduling (load balancing). Service nodes with higher weights will receive more request traffic in load balancing algorithms (such as weighted round-robin). A weight of 0 typically means that the service node does not participate in traffic allocation (it is offline).

[0073] It should be understood that health status requirements can refer to predefined standards or thresholds for determining whether a service node is eligible to receive traffic.

[0074] It should be noted that by performing multi-dimensional health checks on each service node within the target data center, it is possible to detect service node failures or performance degradation in real time and immediately demote or remove them from the service pool. This prevents user requests from being distributed to unavailable nodes, thereby ensuring business continuity and user experience, and improving business high availability.

[0075] Furthermore, based on the health check results, the weight status of the corresponding service nodes in the domain name resolution records associated with the target business service is dynamically updated. This can guide more traffic to healthy, high-performance nodes, achieve intelligent load balancing, optimize resource utilization, and improve the overall system throughput and response speed.

[0076] In a specific implementation, the step of dynamically updating the weight status of the corresponding service node in the domain name resolution record associated with the target business service based on the health check results may include: performing a static health check based on network connectivity and a dynamic health check based on application service response on each service node in the target data center; determining the comprehensive availability status of each service node based on the results of the static health check and the dynamic health check; and adjusting the weight status of the corresponding service node in the domain name resolution record according to the comprehensive availability status.

[0077] Understandably, static health checks refer to availability assessments based on preset configurations or status flags, without involving actively sending business requests for probing. Dynamic health checks, on the other hand, refer to checks that proactively send probing requests and analyze responses to assess the actual operational status of service nodes in real time.

[0078] It should be noted that the comprehensive availability status can refer to the comprehensive conclusion about whether the service node is ultimately available and its availability level after the results of static health checks and dynamic health checks are integrated and weighted.

[0079] This embodiment discloses a method for performing multi-dimensional health checks on each service node within a target data center to obtain health check results. The health checks include node connectivity, application service port status, and business interface response status. Based on the health check results, the weight status of the corresponding service node in the domain name resolution records associated with the target business service is dynamically updated. Based on the updated domain name resolution records, the business traffic arriving at the unified gateway is resolved to service nodes that meet the health status requirements. Because this embodiment performs multi-dimensional health checks on each service node within the target data center and updates the weight status of the corresponding service node in the domain name resolution records associated with the target business service based on the health check results, compared to existing technologies, this embodiment not only improves business high availability but also optimizes resource utilization, increasing the overall system throughput and response speed.

[0080] refer to Figure 6 , Figure 6 This is a flowchart illustrating the third embodiment of the disaster recovery method based on gateway scheduling of the present invention.

[0081] Based on the above embodiments, in this embodiment, step S40 includes steps S401 to S404: Step S401: Determine the real-time health status score of each atomic task in the atomic task library.

[0082] Step S402: Select atomic tasks from the atomic task library that meet the preset conditions based on the real-time health status score.

[0083] Step S403: Select the corresponding task combination logic from the orchestration rule base according to the scenario type of the current disaster recovery scenario.

[0084] Step S404: Based on the task combination logic and the selected atomic tasks, generate a task orchestration process corresponding to the disaster recovery decision instruction, and execute the task orchestration process.

[0085] Understandably, a real-time health status score can refer to a numerical value used to quantitatively evaluate whether an atomic task is currently in a normally executable state. Preset conditions can refer to a filtering threshold that the system pre-sets for the real-time health status score.

[0086] It should be noted that current disaster recovery scenarios include, but are not limited to, network partitioning, data center power outages, and database crashes. An orchestration rule base can refer to a structured database or knowledge base that stores disaster recovery knowledge and best practices. It serves as the brain of the system for intelligent orchestration, providing the mapping logic from scenarios to specific operation sequences.

[0087] It should be understood that task composition logic can refer to a set of specific task execution order and parallel relationship rules retrieved or inferred from the orchestration rule base based on the current disaster recovery scenario type.

[0088] In a specific implementation, the step of determining the real-time health status score of each atomic task in the atomic task library may include: collecting status data of each atomic task under multiple feature dimensions, wherein the feature dimensions include basic health status attribute features, component health check attribute features, system resource attribute features, application-specific indicator features, and key configuration parameter features; quantifying and scoring the status data under each feature dimension based on preset scoring rules; and determining the real-time health status score of each atomic task based on the quantified scores of each feature dimension and the weight values ​​of each feature dimension.

[0089] It should be noted that the status data for basic health status attributes may include check time, version status, version number, and version name. The status data for component health check attributes may include database connections, caching services, and external service dependencies. The status data for system resource attributes may include CPU utilization, used memory, maximum memory, remaining disk space, total disk space, number of threads, and system load. The status data for application-specific metrics may include total number of requests, number of errors, average response time, number of active sessions, and queue size. The status data for key configuration parameter attributes may include health check interval, timeout settings, retry mechanism, threshold configuration, and scenario weighting values.

[0090] For example, refer to Figure 7 , Figure 7This diagram illustrates the generative atomic task recommendation method in the gateway scheduling-based disaster recovery approach of this invention. The diagram shows state data based on basic health status attributes, component health check attributes, system resource attributes, application-specific indicators, and key configuration parameters. The state data under each feature dimension is quantified and scored. Then, the feature vector scores corresponding to the state data under each feature dimension are aggregated to obtain the real-time health status score of each atomic task. Finally, the most suitable task ID (i.e., the atomic task ID with preset conditions) is recommended based on the real-time health status score of each atomic task.

[0091] This embodiment discloses determining the real-time health status score of each atomic task in the atomic task library; selecting atomic tasks from the atomic task library whose real-time health status scores meet preset conditions based on the real-time health status scores; selecting corresponding task combination logic from the orchestration rule library according to the scenario type of the current disaster recovery scenario; generating a task orchestration process corresponding to the disaster recovery decision instruction based on the task combination logic and the selected atomic tasks, and executing the task orchestration process. Because this embodiment filters atomic tasks through real-time health status scores and selects corresponding task combination logic according to the scenario type of the current disaster recovery scenario, compared with existing technologies, this embodiment not only improves the reliability of disaster recovery decision-making and execution but also enhances the adaptability and accuracy of disaster recovery response.

[0092] Furthermore, this embodiment of the invention also proposes a storage medium storing a gateway-based disaster recovery program, which, when executed by a processor, implements the steps of the gateway-based disaster recovery method described above.

[0093] Reference Figure 8 , Figure 8 This is a structural block diagram of the first embodiment of the disaster recovery device based on gateway scheduling of the present invention.

[0094] like Figure 8 As shown, the disaster recovery device based on gateway scheduling proposed in this embodiment of the invention includes: a data acquisition module 501, a decision generation module 502, a traffic scheduling module 503, and a task execution module 504.

[0095] The data acquisition module 501 is used to collect multimodal operational status data related to the target business service. The multimodal operational status data includes network layer status data, data layer replication status data, and application layer business status data.

[0096] The decision generation module 502 is used to perform correlation analysis on the multimodal operating status data and generate disaster recovery decision instructions based on the correlation analysis results.

[0097] The traffic scheduling module 503 is used to schedule business traffic to the target data center through a unified gateway according to the disaster recovery decision instruction.

[0098] The task execution module 504 is used to generate and execute a task orchestration process corresponding to the disaster recovery decision instruction based on multiple atomic tasks in the atomic task library and according to the current disaster recovery scenario.

[0099] The data acquisition module 501 is further configured to acquire network layer status data reflecting communication quality from monitoring agents deployed in multiple data centers, including network latency, packet loss rate, and bandwidth utilization; acquire data layer replication status data reflecting data synchronization status from the data replication link connecting the production center and the disaster recovery center, including data replication latency and data consistency point information; acquire application layer business status data reflecting business function status by calling the application programming interface of the target business service, including core business transaction success rate and key API response status; and use the network layer status data, the data layer replication status data, and the application layer business status data as multimodal operational status data.

[0100] The decision generation module 502 is further configured to perform correlation analysis on the network layer status data, the data layer replication status data, and the application layer service status data to obtain correlation analysis results; when the correlation analysis results indicate network anomalies, it determines whether to trigger traffic switching between data centers based on the data layer replication status data and the application layer service status data; and generates a disaster recovery decision instruction based on the determination result, wherein the disaster recovery decision instruction includes a target data center identifier.

[0101] The decision generation module 502 is further configured to, when the correlation analysis result indicates a network anomaly, obtain the data replication latency in the data layer replication status data and the core business transaction success rate in the application layer business status data; if the data replication latency is lower than a first preset threshold and the core business transaction success rate is higher than a second preset threshold, then it is determined that traffic switching between data centers will not be triggered; if the data replication latency is higher than the first preset threshold, or the core business transaction success rate is lower than the second preset threshold, then it is determined that traffic switching between data centers will be triggered.

[0102] The traffic scheduling module 503 is further configured to identify the request characteristics of the service traffic, determine a traffic scheduling strategy matching the request characteristics based on the target data center identifier in the disaster recovery decision instruction and the request characteristics, and route the service traffic to the corresponding service node in the target data center through a unified gateway according to the traffic scheduling strategy.

[0103] This device embodiment discloses the collection of multimodal operational status data related to a target business service. This multimodal operational status data includes network layer status data, data layer replication status data, and application layer business status data. The device performs correlation analysis on the multimodal operational status data and generates disaster recovery decision instructions based on the analysis results. According to the disaster recovery decision instructions, business traffic is scheduled to the target data center through a unified gateway. Based on multiple atomic tasks in an atomic task library, a task orchestration process corresponding to the disaster recovery decision instructions is generated and executed according to the current disaster recovery scenario. Because this device embodiment generates disaster recovery decision instructions through correlation analysis of multimodal operational status data, then schedules business traffic to the target data center through a unified gateway according to the disaster recovery decision instructions, and finally dynamically generates and executes a task orchestration process based on the atomic task library and the current disaster recovery scenario, compared to existing technologies, this device embodiment improves the accuracy, timeliness, and automation of disaster recovery switching, thereby ensuring business continuity.

[0104] Based on the first embodiment of the gateway scheduling-based disaster recovery device of the present invention, a second embodiment of the gateway scheduling-based disaster recovery device of the present invention is proposed.

[0105] In this embodiment, the traffic scheduling module 503 is further configured to perform multi-dimensional health checks on each service node within the target data center to obtain health check results. The health checks include node connectivity, application service port status, and business interface response status. Based on the health check results, the module dynamically updates the weight status of the corresponding service node in the domain name resolution records associated with the target business service. Based on the updated domain name resolution records, the module resolves the business traffic arriving at the unified gateway to service nodes that meet the health status requirements.

[0106] Other embodiments or specific implementations of the disaster recovery device based on gateway scheduling of the present invention can be referred to the above-described method embodiments, and will not be repeated here.

[0107] This application provides a gateway scheduling-based disaster recovery device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the gateway scheduling-based disaster recovery method in the above embodiment 1.

[0108] The following is for reference. Figure 9This document illustrates a structural diagram of a gateway-based disaster recovery device suitable for implementing embodiments of this application. The gateway-based disaster recovery device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 9 The disaster recovery device based on gateway scheduling shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0109] like Figure 9 As shown, a gateway-based disaster recovery device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the gateway-based disaster recovery device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the gateway-based disaster recovery device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows gateway-based disaster recovery devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0110] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0111] The gateway-based disaster recovery device provided in this application, employing the gateway-based disaster recovery method described in the above embodiments, can solve the technical problems of low accuracy, timeliness, and automation in disaster recovery switching in existing technologies, thereby affecting business continuity. Compared with the prior art, the beneficial effects of the gateway-based disaster recovery device provided in this application are the same as those of the gateway-based disaster recovery method provided in the above embodiments, and other technical features of this gateway-based disaster recovery device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0112] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0113] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0114] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0115] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0116] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory / random access memory, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0117] The above are merely preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the protection scope of the present invention.

Claims

1. A disaster recovery method based on gateway scheduling, characterized in that, The method includes: Collect multimodal operational status data related to the target business service, including network layer status data, data layer replication status data, and application layer business status data; The multimodal operating status data is subjected to correlation analysis, and disaster recovery decision instructions are generated based on the correlation analysis results; According to the disaster recovery decision instructions, business traffic is routed to the target data center through a unified gateway; Based on multiple atomic tasks in the atomic task library, a task orchestration process corresponding to the disaster recovery decision instruction is generated and executed according to the current disaster recovery scenario.

2. The disaster recovery method based on gateway scheduling as described in claim 1, characterized in that, The step of performing correlation analysis on the multimodal operating status data and generating disaster recovery decision instructions based on the correlation analysis results includes: The network layer status data, the data layer replication status data, and the application layer service status data are correlated and analyzed to obtain correlation analysis results. When the correlation analysis results indicate a network anomaly, based on the data layer replication status data and the application layer business status data, it is determined whether to trigger traffic switching between data centers. Based on the judgment result, a disaster recovery decision instruction is generated, which includes the target data center identifier.

3. The disaster recovery method based on gateway scheduling as described in claim 2, characterized in that, The step of determining whether to trigger traffic switching between data centers based on the data layer replication status data and the application layer service status data when the correlation analysis result indicates a network anomaly includes: When the correlation analysis result indicates a network anomaly, obtain the data replication delay in the data layer replication status data and the core business transaction success rate in the application layer business status data; If the data replication delay is lower than the first preset threshold and the core business transaction success rate is higher than the second preset threshold, then it is determined that traffic switching between data centers will not be triggered. If the data replication delay is higher than the first preset threshold, or the core business transaction success rate is lower than the second preset threshold, then it is determined that a traffic switch between data centers will be triggered.

4. The disaster recovery method based on gateway scheduling as described in claim 1, characterized in that, The step of routing service traffic to the target data center through a unified gateway according to the disaster recovery decision instruction includes: Identify the request characteristics of business traffic, and determine a traffic scheduling strategy that matches the request characteristics based on the target data center identifier in the disaster recovery decision instruction and the request characteristics. According to the traffic scheduling strategy, the service traffic is routed to the corresponding service node in the target data center through a unified gateway.

5. The disaster recovery method based on gateway scheduling as described in claim 4, characterized in that, Before the step of routing the service traffic to the corresponding service node in the target data center through the unified gateway according to the traffic scheduling strategy, the method further includes: Perform multi-dimensional health checks on each service node in the target data center to obtain health check results. The health checks include node connectivity, application service port status, and business interface response status. Based on the health check results, dynamically update the weight status of the corresponding service node in the domain name resolution records associated with the target business service; Based on the updated domain name resolution records, the business traffic arriving at the unified gateway is resolved to service nodes that meet the health status requirements.

6. The disaster recovery method based on gateway scheduling as described in claim 1, characterized in that, The steps of generating and executing a task orchestration process corresponding to the disaster recovery decision instruction based on multiple atomic tasks in the atomic task library according to the current disaster recovery scenario include: Determine the real-time health status score for each atomic task in the atomic task library; Based on the real-time health status score, select atomic tasks from the atomic task library that meet the preset conditions of the real-time health status score; Based on the scenario type of the current disaster recovery scenario, select the corresponding task combination logic from the orchestration rule base; Based on the task combination logic and the selected atomic tasks, a task orchestration process corresponding to the disaster recovery decision instruction is generated and executed.

7. The disaster recovery method based on gateway scheduling as described in any one of claims 1-6, characterized in that, The steps for collecting multimodal operational status data related to the target business service include: Network layer status data reflecting communication quality is collected from monitoring agents deployed in multiple data centers. This network layer status data includes network latency, packet loss rate, and bandwidth utilization. Data layer replication status data reflecting the data synchronization status is collected from the data replication link connecting the production center and the disaster recovery center. The data layer replication status data includes data replication latency and data consistency point information. By calling the application programming interface of the target business service, application layer business status data reflecting the status of business functions is collected. The application layer business status data includes the core business transaction success rate and the response status of key APIs. The network layer state data, the data layer replication state data, and the application layer service state data are used as multimodal operational state data.

8. A disaster recovery device based on gateway scheduling, characterized in that, The device includes: The data acquisition module is used to collect multimodal operational status data related to the target business service. The multimodal operational status data includes network layer status data, data layer replication status data, and application layer business status data. The decision generation module is used to perform correlation analysis on the multimodal operating status data and generate disaster recovery decision instructions based on the correlation analysis results. The traffic scheduling module is used to schedule business traffic to the target data center through the unified gateway according to the disaster recovery decision instructions; The task execution module is used to generate and execute a task orchestration process corresponding to the disaster recovery decision instruction based on multiple atomic tasks in the atomic task library and the current disaster recovery scenario.

9. A disaster recovery device based on gateway scheduling, characterized in that, The device includes: a memory, a processor, and a gateway-based disaster recovery program stored in the memory and executable on the processor, the gateway-based disaster recovery program being configured to implement the steps of the gateway-based disaster recovery method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a gateway-based disaster recovery program, which, when executed by a processor, implements the steps of the gateway-based disaster recovery method as described in any one of claims 1 to 7.

Images