Disaster recovery switching method, device and equipment of domain name and readable storage medium

Abstract

This application provides a method, apparatus, device, and readable storage medium for domain name disaster recovery switching, relating to the field of computer technology. The method includes: in response to detecting a primary domain name access failure during a business request, detecting whether a multi-cloud domain name replacement rule effective on the server exists; in response to the existence of a multi-cloud domain name replacement rule, determining a target backup domain name and performing a switch based on the multi-cloud domain name replacement rule; in response to the absence of a domain name replacement rule, detecting the current network status and determining the fault type of the primary domain name access failure based on a preset anomaly judgment rule; matching the corresponding switching strategy and domain name source according to the fault type; determining the target backup domain name and performing a switch based on the switching strategy and domain name source; performing periodic probes on the primary domain name, and when the number of consecutive successful probes on the primary domain name reaches a preset threshold, switching the business request back to the primary domain name, thereby achieving the technical effect of ensuring high availability and continuity of business requests.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and readable storage medium for disaster recovery switching of domain names. Background Technology

[0002] In existing technologies, domain name disaster recovery solutions built to ensure business continuity generally have two major limitations: First, anomaly detection is passive and relies on manual investigation. Clients cannot automatically identify specific fault types, leading to difficulties in fault delineation and long processing times. Second, disaster recovery switching is manual and lacks automatic decision-making and real-time switching mechanisms based on fault characteristics, resulting in delayed business recovery response and making it difficult to meet the urgent needs of modern digital applications for high availability and rapid recovery.

[0003] Therefore, in view of the shortcomings of related technical solutions, the present invention provides a method for disaster recovery switching of domain names. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, device, and readable storage medium for domain name disaster recovery switching to address the aforementioned technical problems.

[0005] On the one hand, a disaster recovery switching method for domain names is provided. The method includes: in response to detecting a failure to access the primary domain name during a business request, detecting whether there is a multi-cloud domain name replacement rule effective by the server; in response to the existence of a multi-cloud domain name replacement rule, determining a target backup domain name and performing a switch based on the multi-cloud domain name replacement rule; in response to the absence of a domain name replacement rule, detecting the current network status and determining the fault type of the primary domain name access failure based on a preset anomaly judgment rule; matching the corresponding switching strategy and domain name source according to the fault type, wherein the domain name source includes: a backup domain name pool, a direct connection address list, or a basic primary domain name; determining a target backup domain name and performing a switch based on the switching strategy and domain name source, verifying and reporting the business access status after the switch; after switching to the backup domain name, performing periodic probes on the primary domain name, and when the number of consecutive successful probes on the primary domain name reaches a preset threshold, switching the business request back to the primary domain name.

[0006] Optionally, the method further includes: sending the client's current geographic location and request time to the server according to the polling cycle; receiving a list of backup domain names returned by the server, wherein the list of backup domain names includes at least one of domain name address, weight priority, and validity period; updating the local backup domain name pool according to the list of backup domain names, and performing connectivity tests on newly added domain names, and adding newly added domain names that pass the connectivity test to the backup domain name pool.

[0007] Optionally, before sending the client's current location information and request time to the server according to the polling cycle, the method further includes: monitoring at least one preset update triggering condition, wherein the update triggering condition includes: application startup event, timed polling event, application foreground / background switching event, or update request exception event; in response to detecting that any update triggering condition is met, sending the client's current location information and request time to the server.

[0008] Optionally, in response to the absence of a domain name replacement rule, the current network status is detected, and the fault type of the main domain name access failure is determined based on a preset anomaly judgment rule, including: in response to the current network status being normal, detecting whether an immediate anomaly flag is received; in response to the detection of an immediate anomaly flag, determining the fault type of the main domain name based on the immediate anomaly flag; in response to the absence of an immediate anomaly flag, updating the timeout statistics, wherein the timeout statistics include the number of consecutive timeouts and / or the timeout rate within the sliding time window; in response to the timeout statistics meeting the preset timeout judgment condition, determining the fault type of the main domain name as a timeout fault.

[0009] Optionally, based on the switching strategy and domain name source, a target backup domain name is determined and the switching is performed. The business access status after the switching is verified and reported, including: selecting a backup domain name from the domain name source according to the switching strategy and re-initiating the business request; in response to the failure of the current business request, obtaining the next backup domain name for retrying until the current business request succeeds or the number of retries reaches the maximum threshold; in response to the success of the current business request, determining the successful domain name as the target backup domain name; in response to the number of retries reaching the maximum threshold, performing a business degradation operation.

[0010] Optionally, based on the switching strategy, a backup domain name can be selected from the domain name source, including: if the domain name source is a backup domain name pool, the next available domain name is determined as the backup domain name according to the weight priority order in the backup domain name pool; if the domain name source is a direct connection address list, the next available address is determined according to the order of the addresses in the direct connection address list, and the address is used as the target address for the business request; if the domain name source is the base primary domain name, the base primary domain name is used as the backup domain name.

[0011] Optionally, periodic liveness detection is performed on the main domain, and when the number of consecutive successful liveness detections on the main domain reaches a preset threshold, business requests are switched back to the main domain. This includes: initiating a lightweight network request to the main domain and marking it with a liveness detection flag, and receiving the response result from the main domain; determining the liveness detection result based on the response result, where the liveness detection result includes success or failure; accumulating the number of consecutive successful liveness detections on the main domain; and when the number of consecutive successful liveness detections reaches the preset switchback threshold, determining that the main domain has been restored to availability, and switching subsequent business requests back to the main domain.

[0012] On the other hand, a domain name disaster recovery switching device is provided. The device includes: a first processing module, used to detect whether there is a multi-cloud domain name replacement rule effective by the server when a failure to access the main domain name is detected during a business request; a second processing module, used to determine the target backup domain name and perform the switch according to the multi-cloud domain name replacement rule when there is a multi-cloud domain name replacement rule; a third processing module, used to detect the current network status and determine the fault type of the failure to access the main domain name based on a preset anomaly judgment rule when there is no domain name replacement rule; a fourth processing module, used to match the corresponding switching strategy and domain name source according to the fault type, wherein the domain name source includes: backup domain name pool, direct connection address list or basic main domain name; a fifth processing module, used to determine the target backup domain name and perform the switch according to the switching strategy and domain name source, and verify and report the business access status after the switch; and a sixth processing module, used to perform periodic probes on the main domain name after switching to the backup domain name, and switch the business request back to the main domain name when the number of consecutive successful probes on the main domain name reaches a preset threshold.

[0013] On another front, a computer device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, it performs the following steps: in response to detecting a primary domain name access failure during a business request, it detects whether a multi-cloud domain name replacement rule effective from the server exists; in response to the existence of a multi-cloud domain name replacement rule, it determines a target backup domain name and performs a switch based on the multi-cloud domain name replacement rule; in response to the absence of a domain name replacement rule, it detects the current network status and determines the fault type of the primary domain name access failure based on a preset anomaly judgment rule; according to the fault type, it matches the corresponding switching strategy and domain name source, wherein the domain name source includes: a backup domain name pool, a direct connection address list, or a basic primary domain name; according to the switching strategy and domain name source, it determines a target backup domain name and performs a switch, verifies and reports the business access status after the switch; after switching to the backup domain name, it performs periodic probes on the primary domain name, and when the number of consecutive successful probes on the primary domain name reaches a preset threshold, it switches the business request back to the primary domain name.

[0014] On another front, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, it performs the following steps: in response to detecting a failure to access the primary domain name during a business request, it checks whether a multi-cloud domain name replacement rule effective on the server exists; in response to the existence of a multi-cloud domain name replacement rule, it determines a target backup domain name and performs a switch based on the multi-cloud domain name replacement rule; in response to the absence of a domain name replacement rule, it checks the current network status and determines the fault type of the primary domain name access failure based on a preset anomaly judgment rule; according to the fault type, it matches the corresponding switching strategy and domain name source, wherein the domain name source includes: a backup domain name pool, a direct connection address list, or a basic primary domain name; according to the switching strategy and domain name source, it determines a target backup domain name and performs a switch, and verifies and reports the business access status after the switch. After switching to the backup domain, periodic activation testing is performed on the primary domain, and when the number of consecutive successful activation tests on the primary domain reaches a preset threshold, business requests are switched back to the primary domain.

[0015] The disaster recovery switching method, apparatus, device, and readable storage medium for the aforementioned domain name include: In response to detecting a primary domain name access failure during a business request, detecting whether a multi-cloud domain name replacement rule effective on the server exists; in response to the existence of a multi-cloud domain name replacement rule, determining a target backup domain name and performing a switch based on the rule; in response to the absence of a domain name replacement rule, detecting the current network status and determining the fault type of the primary domain name access failure based on a preset anomaly judgment rule; matching the corresponding switching strategy and domain name source according to the fault type, wherein the domain name source includes: a backup domain name pool, a direct connection address list, or a basic primary domain name; determining the target backup domain name and performing a switch based on the switching strategy and domain name source, verifying and reporting the business access status after the switch; after switching to the backup domain name, performing periodic liveness detection on the primary domain name, and when the number of consecutive successful liveness detections on the primary domain name reaches a preset threshold, switching the business request back to the primary domain name; thus, not only is the high availability and continuity of business requests guaranteed, but also closed-loop management of fault perception, strategy matching, switch execution, status verification, and periodic liveness detection and switchback is achieved, improving the overall disaster recovery capability and user experience of the system. Attached Figure Description

[0016] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a domain name disaster recovery switching method provided for related technologies; Figure 2A flowchart illustrating a domain name disaster recovery switching method provided in this application embodiment; Figure 3 A flowchart illustrating another domain name disaster recovery switching method provided in this application embodiment; Figure 4 A schematic diagram of a system module for disaster recovery switching of a domain name, provided for an embodiment of this application; Figure 5 A schematic diagram of a disaster recovery switching process architecture for a domain name provided in an embodiment of this application; Figure 6 A structural block diagram of a domain name disaster recovery switching device provided in an embodiment of this application; Figure 7 This is an internal structural diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] It should be understood that, in the description of this application, unless the context explicitly requires it, words such as "including" or "comprising" throughout the specification should be interpreted as including rather than exclusive or exhaustive; that is, meaning "including but not limited to".

[0020] It should also be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0021] It should be noted that the terms "S1," "S2," etc., are used only for descriptive purposes and do not specifically refer to the order or sequence, nor are they intended to limit this application. They are merely for the convenience of describing the method of this application and should not be construed as indicating the sequential order of the steps. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0022] In related technologies, such as Figure 1As shown, a disaster recovery switching method for a domain name is provided. Assuming it is used in a ride-hailing platform client, the process for handling a failure due to an expired main domain certificate is as follows: When a driver accesses the main domain, the connection fails due to an expired SSL (Secure Sockets Layer) certificate. The client only displays a "network error" message without identifying the specific cause of the error. After receiving feedback from the driver, the operations and maintenance personnel use log analysis and domain name detection tools to locate the cause of the failure (certificate expiration). This process takes an average of 30-40 minutes. The operations and maintenance personnel then enable and configure a multi-cloud backup domain name through the cloud control platform. Native or AJX uses the latest multi-cloud backup domain name for business requests.

[0023] AJX is a cross-platform development framework that supports "code once, reuse across multiple platforms." Its components are rendered as native elements for the corresponding platform (iOS / Android) at runtime, ensuring a consistent user experience. The `Application` object is a native application developed for the iOS or Android system. It provides basic runtime capabilities (such as system permission calls and hardware interaction), while specific business functions are implemented by the cross-platform framework. The cloud control module is a management platform for remotely configuring LookupServer parameters, with configurable items including service on / off status and domain name polling interval.

[0024] In one embodiment, such as Figure 2 As shown, a method for disaster recovery switching of a domain name is provided, including the following steps: S101: In response to the detection of a failure to access the main domain name during a business request, check whether there is a multi-cloud domain name replacement rule that is effective on the server side.

[0025] Here, the main domain name is the business service domain name that the client accesses by default. It is usually the default entry point that is built into the package or configured for the first time.

[0026] Here, the multi-cloud domain name replacement rule is a configuration rule issued by the server (such as the cloud control platform) to switch domain names between different cloud service providers (such as Alibaba Cloud and Tencent Cloud). It includes information such as the target domain name, effective time, and applicable scenarios.

[0027] Among them, a business request is a data request initiated by the client to the server in order to complete a related function. When the client is a ride-hailing operation client, the business request includes, but is not limited to, network requests corresponding to operations such as order acceptance, navigation, settlement, location reporting, and message synchronization. It is initiated through the specified business interface path and carries the corresponding business parameters.

[0028] The executing entity is the client, such as a driver app on a mobile device.

[0029] The server side refers to the backend system cluster that provides domain name configuration management, business logic processing and data storage support for clients. It includes, but is not limited to, cloud control platform, Lookup service, business gateway, database, log system and multi-cloud service module. The modules work together to realize domain name policy distribution, business request response, anomaly monitoring and disaster recovery decision-making functions.

[0030] S102: In response to the existence of multi-cloud domain name replacement rules, determine the target backup domain name according to the multi-cloud domain name replacement rules and perform the switch.

[0031] Specifically, the client prioritizes accessing from the primary domain name, while simultaneously detecting in real time whether there are domain name replacement rules issued by multi-cloud services (including configurations such as target domain name, effective period, and applicable scenarios); if a valid replacement rule exists, the multi-cloud domain name switch is executed directly (skipping the disaster recovery strategy judgment) to ensure that the business accesses according to the preset multi-cloud deployment logic.

[0032] Specifically, in response to the existence of multi-cloud domain name replacement rules, clients must strictly adhere to the rigid policy of "after a multi-cloud request fails, only wait for the next Lookup service data delivery, and are not allowed to switch to the primary domain name or disaster recovery domain name," to avoid inconsistencies in server-side data synchronization due to domain name switching (e.g., if data sharding has been completed in the multi-cloud environment, switching to another domain name will cause data read / write misalignment). LookupServer is a configuration retrieval service whose core function is to return available domain names and address resources for the current city and current time, including its own backup domain name, business domain name, and long-chain address.

[0033] Specifically, in normal scenarios: when a business request (e.g., request a) fails to use the multi-cloud backup domain, first determine whether the Lookup service has refreshed the domain data: if not, directly end the switching process without performing any disaster recovery or primary domain switching; if it has been refreshed, handle it according to the following rules: Boundary Case 1 (new multi-cloud domain after refresh): immediately re-initiate request a using the newly issued multi-cloud backup domain by Lookup, without waiting for the next business trigger, shortening the request recovery time in multi-cloud scenarios; Boundary Case 2 (no multi-cloud domain after refresh): immediately switch to the business primary domain to initiate request a. At this time, since the multi-cloud rules have expired, restore the basic access logic of "primary domain priority".

[0034] Specifically, the abnormal reporting requirements are as follows: all failed requests for multi-cloud backup domain names must be reported to the server in real time (including the failure time, domain name, status code, and reason for failure) so that the server can investigate synchronization problems in the multi-cloud environment and avoid repeatedly issuing invalid domain names.

[0035] S103: In response to the absence of a domain name replacement rule, detect the current network status and determine the fault type of the main domain name access failure based on the preset anomaly judgment rule.

[0036] The types of failures can include DNS resolution problems, server connection problems, SSL / TLS security errors, and resource access problems.

[0037] S104: Match the corresponding switching strategy and domain name source according to the fault type, where the domain name source includes: backup domain name pool, direct connection address list or base domain name.

[0038] Here, the backup domain pool is a list of currently available domains obtained by the client through polling the Lookup service, including multi-cloud backup domains, automatic disaster recovery domains, etc., sorted by weight.

[0039] Here, the direct connection address list is the list of IP (Internet Protocol) addresses configured on the client. It is used to directly access the server via IP when DNS (Domain Name System) resolution fails, thus achieving "domain-IP" dual backup.

[0040] Here, the primary domain name is the system default domain name (such as serverHost) used as a last resort, which is activated when all alternative domain names are unavailable.

[0041] S105: Based on the switching strategy and domain name source, determine the target backup domain name and execute the switching, and verify and report the business access status after the switching.

[0042] Specifically, all switching actions (triggering reasons, domain names before and after the switch, success rate) are reported to the server in real time, providing data support for the Lookup service to optimize the domain name pool configuration and adjust the polling strategy, forming a closed loop of "switching-monitoring-reporting-optimization".

[0043] S106: After switching to the backup domain, perform periodic activation testing on the primary domain, and when the number of consecutive successful activation tests on the primary domain reaches a preset threshold, switch business requests back to the primary domain.

[0044] Here, periodic liveness detection refers to the client periodically sending lightweight requests (such as HTTP HEAD) to the main domain after the main domain is abnormally switched to, in order to detect whether it has been restored to availability.

[0045] Specifically, the basic configuration for active domain registration can include the registration period, the rollback threshold, and the registration interface. The registration period is 1 minute by default and can be dynamically adjusted via cloud control (configuration range 30 seconds to 5 minutes). The rollback threshold requires the main domain to successfully register 5 consecutive times (the number can be configured via cloud control, ranging from 3 to 10 times) before a rollback can be triggered. The registration interface caches the "business request interface path at the moment of abnormal main domain registration switchover" (e.g., / api / user / login) on the client side. This path is used to initiate requests during registration, ensuring that the registration scenario matches the actual business scenario.

[0046] It should be noted that this application not only ensures the high availability and continuity of business requests, but also realizes closed-loop management of fault detection, policy matching, switchover execution, status verification and periodic liveness detection and switchback, thereby improving the overall disaster recovery capability of the system and the user experience.

[0047] In some specific implementations, the method further includes: Based on the polling cycle, send the client's current location information and the request time to the server; Receive a list of alternative domain names returned by the server, wherein the list of alternative domain names includes at least one of the following: domain name address, weight priority, and validity period; Update the local backup domain pool based on the backup domain list, and perform connectivity tests on newly added domains. Add newly added domains that pass the connectivity test to the backup domain pool.

[0048] Here, the polling period is the time interval between client requests to the server (Lookup service) for configuration.

[0049] Specifically, the polling period can be dynamically adjusted according to the network environment. For example, the client can initiate a request based on the local configuration (e.g., 30 seconds / time). If the previous polling fails, it will be automatically shortened (e.g., 10 seconds / time). After success, the polling period will be restored to the original time, ensuring the timeliness of the domain name and the balance of network resources.

[0050] The geographic information can be the city or region identifier where the client is currently located, obtained through GPS positioning or network IP resolution, and used to match regionally optimized domain name resources.

[0051] The request time point can be the precise timestamp (accurate to the minute) when the client initiates the request, used to adapt to the server's time-based domain name scheduling strategy.

[0052] Here, the backup domain list is a structured collection of domains returned by the server, which may include attributes such as domain address, weight, priority, and validity period, and is used to guide the client in switching domains.

[0053] Updates can include adding and deleting domains, specifically removing invalid domains and adding new available domains.

[0054] Here, connectivity testing is a lightweight network connection test (such as a TCP handshake) initiated by the client on the newly added domain name to verify its actual reachability. Only domain names that pass the test are added to the backup domain name pool.

[0055] Specifically, the client performs connectivity pre-testing on newly added domain names (only initiating a lightweight TCP handshake verification). If the test fails, it is marked as "to be retried" and not included in the immediate availability pool to avoid invalid domain names occupying switching resources.

[0056] In one embodiment, the server can also report a summary of Lookup service status codes and the last successful request time. Specifically, the summary of Lookup service status codes is obtained through the client's local cache (the last 10 request records), which is used by the server to investigate Lookup service anomalies (such as frequent 5xx returns in a certain region, requiring adjustment of the domain name configuration for that region); the last successful request time is obtained through the client's local records, which is used by the server to determine whether the client has not obtained valid data for a long time and to trigger the emergency domain name issuance.

[0057] This ensures the timeliness, regional relevance, and availability of the backup domain name pool, enabling the backup addresses relied upon for disaster recovery switching to adapt to network environment and business changes in real time, thereby improving the success rate and reliability of the switching.

[0058] In some specific implementations, before sending the client's current geographic location and request time to the server according to the polling cycle, the method further includes: Monitor at least one preset update trigger condition, wherein the update trigger condition includes: application startup event, timed polling event, application foreground / background switching event, or update request exception event; In response to the detection that any update trigger condition is met, the server sends the client's current location information and the request time to the server.

[0059] Here, update triggering conditions refer to various automated scenarios in which the client actively sends a request to the server (Lookup service) to obtain the latest list of alternative domain names.

[0060] Here, the application startup event refers to the event in which the client application process is fully initialized and started, including the initial installation startup, the process being restarted after being terminated by the system, or a manual cold start by the user.

[0061] Specifically, application startup events include: after the client is first installed and started, the application process is restarted, or the system is restarted, a Lookup service request is immediately initiated without waiting for a timed period, ensuring that the latest backup domain name pool can be obtained during the startup phase, avoiding initial access relying on the old domain name.

[0062] Specifically, the timed polling events include: the basic polling interval is configured to be 10 minutes by default; the client reads the "Lookup polling interval" parameter issued by the cloud control platform in real time through the interface (supports dynamic adjustment from 1 to 30 minutes) and initiates a request according to the configured cycle; if the cloud control configuration is updated, the client will synchronize the new interval before the next polling without restarting the application.

[0063] Specifically, the application foreground / background switching event includes: when the client switches from the background to the foreground, it first determines the difference between the current time and the time of the last Lookup request: if the difference is greater than the "foreground / background switching trigger threshold" configured by the cloud control (default 5 minutes, which can be dynamically adjusted), a Lookup request is immediately initiated; if the difference is less than the threshold, the current trigger is skipped to avoid invalid requests in frequent switching scenarios.

[0064] Here, an update request exception event refers to an event where the client's previous request to the Lookup service failed or returned invalid data.

[0065] Specifically, update request exception events include: when the Lookup service returns abnormal data (such as an empty domain list or signature verification failure) or request exception (such as two consecutive failed requests), the next Lookup request is immediately triggered (without waiting period), and the Lookup request domain is switched until valid data is obtained, ensuring that the domain pool recovers and updates quickly in abnormal scenarios.

[0066] This ensures that clients can proactively update backup information when network environment changes or business status transitions occur, enhancing the real-time nature and robustness of disaster recovery infrastructure data and preventing handover failures due to outdated information.

[0067] In some specific implementations, in response to the absence of a domain name replacement rule, the current network status is detected, and the fault type of the main domain name access failure is determined based on preset anomaly judgment rules, including: In response to the current network status being normal, check whether an immediate anomaly flag has been received. In response to the detection of an immediate anomaly flag, the fault type of the main domain is determined based on the immediate anomaly flag. In response to the absence of an immediate anomaly flag, update the timeout statistics, which include the number of consecutive timeouts and / or the timeout rate within the sliding time window; If the timeout statistics meet the preset timeout criteria, the fault type of the main domain name is determined to be a timeout fault.

[0068] Here, the instant error identifier is a specific error code that the client's native layer can directly determine and return immediately after the request is initiated, without the need for cumulative statistics.

[0069] Specifically, when the Native layer detects the following anomalies, it will immediately trigger a domain name switch without waiting for the statistical threshold. These include: when a DNS resolution failure code is returned (e.g., iOS: -1003, Android: 203), the fault type is determined to be a DNS resolution problem; when a TCP connection times out (default 5 seconds) or the connection is refused (ECONNREFUSED), the fault type is determined to be a server connection problem; when certificate verification fails or the protocol version is incompatible (e.g., TLSv1.0 is disabled), the fault type is determined to be an SSL / TLS security error; when a 404 (resource not found) or 503 (service unavailable) status code is returned, the fault type is determined to be a resource access problem.

[0070] For example, the Native layer returns the corresponding code according to the rules, ensuring that the application layer can determine the exception type based on a unified standard. The mapping relationship of exception identifiers can include: the exception type is no exception, the unified exception code is 0, the iOS implementation maintains the original logic, the Android implementation replaces the original random code and returns 0; the exception type is DNS resolution failure, the unified exception code is 101, the iOS implementation catches the DNS resolution error and returns 101, the Android implementation listens for the DNS resolution exception callback and returns 101; the exception type is connection timeout, the unified exception code is 102, the iOS implementation returns 102 in the timeout callback, the Android implementation returns 102 in the timeout exception handling logic, and so on.

[0071] Here, timeout statistics are cumulative metrics maintained by the client to determine network quality fluctuations or slow (incomplete) server response.

[0072] Here, the timeout rate within the sliding time window is the proportion of all business requests that time out within a recent fixed-duration time window (e.g., 30 seconds).

[0073] Specifically, if the number of consecutive timeouts reaches the cloud control configuration threshold (default 10 times, must be consecutive requests, if there is one non-timeout request during the period, the count will be reset), it is determined to be a timeout fault; if the timeout rate within a 30-second sliding window exceeds the cloud control configuration threshold (default 30%, timeout rate = number of timeout requests within the window / total number of requests), it is determined to be a timeout fault.

[0074] Specifically, a "sliding log" is used to store request records (including request timestamps and whether they have timed out). Each time a new request record is added, a binary search is used to quickly locate and delete expired records outside the window (more than 30 seconds) to avoid memory leaks. The window statistics dimension is "all normal AJX business requests", excluding Lookup service requests, to ensure that the statistical results only reflect the access status of core business.

[0075] Specifically, once a timeout fault is identified, the "continuous timeout count counter" and "sliding window request record" are immediately reset to prevent subsequent requests from being interfered with by historical data.

[0076] In this way, different types of domain name access failures can be accurately distinguished.

[0077] In some specific implementations, based on the switching strategy and domain name source, a target backup domain name is determined and the switching is performed. The service access status after the switching is verified and reported, including: According to the switching strategy, a backup domain name is selected from the domain name sources, and the business request is re-initiated; In response to the failure of the current business request, obtain the next backup domain name for retry until the current business request succeeds or the number of retries reaches the maximum threshold. In response to the success of the current business request, the successful domain name is identified as the target backup domain name; In response to the maximum number of retries being reached, a service degradation operation is performed.

[0078] Here, the switching strategy is a set of rules that guides the client on how to select an alternative domain from the domain source.

[0079] Here, service degradation is a safety fallback measure implemented to ensure a basic user experience or prevent business crashes after all domain name switching attempts have failed. Examples include returning a pre-set, user-friendly error message, using locally cached data, or guiding users to check their network.

[0080] Specifically, if the problem persists after the switch, the system will retry in the order of the backup domain pool (up to 3 times). If the retry fails, a downgrade strategy will be triggered (such as returning a friendly message or using cached data as a fallback).

[0081] Specifically, report "domain anomaly events" (including the abnormal domain name, anomaly type, occurrence time, and request path) to the server; mark the current abnormal domain name as "unavailable" in the local ajxBackHost domain name list on the client and record the duration of the disabling (default 5 minutes); select the next domain name to re-initiate the business request according to the weight order of "available domain names" in the ajxBackHost list; if all backup domain names are unavailable, trigger serverHost fallback (same as the Lookup failure fallback logic).

[0082] This enhances the practical feasibility of disaster recovery switching, ensuring that system behavior remains controllable and predictable even in complex fault scenarios.

[0083] In some specific implementations, an alternative domain name is selected from the domain name sources according to the switching strategy, including: If the domain name originates from the backup domain name pool, the next available domain name is determined as the backup domain name based on the weight and priority order in the backup domain name pool. In response to the domain name originating from a list of directly connected addresses, the next available address is determined based on the order of the addresses in the list, and this address is used as the target address for the business request. In response to the domain originating from the primary domain, the primary domain is used as a backup domain.

[0084] When selecting domain names, the client follows a sequence from high to low weight.

[0085] The order of addresses in the direct-connection address list can be either configured priority or a simple list order.

[0086] Specifically, when the client starts for the first time, it prioritizes using the Lookup base domain name built into the installation package to initiate a request. After the first request is successful, all subsequent polling requests are switched to the Lookup backup domain name (including multiple backup addresses, sorted by weight) issued by the Lookup service, forming a request domain name iteration logic of "initial package domain name → issued backup domain name". When the currently used Lookup domain name request fails (including timeout, connection rejection, status code not 2xx, etc.), the Lookup domain name switch is immediately triggered, and the next available domain name is selected according to the weight order of the backup domain name list to re-initiate the request. The switching interval is ≤1 second to avoid the Lookup service being interrupted due to a single domain name failure.

[0087] Specifically, in a conventional disaster recovery scenario, domain names are retrieved from the backup domain name pool according to their weight and priority. When a problem with DNS resolution is suspected or confirmed, the domain name resolution is bypassed, and the IP connection is used directly to ensure the link is reachable. When all current structured backup solutions fail, the system returns to the most original and reliable basic entry point to retrieve the basic primary domain name.

[0088] Specifically, using the primary domain name as a backup domain name can include: Domain name status reset: The client automatically marks the status of "Lookup tenant's own domain name" and "Lookup package's own domain name" as "available" (regardless of whether they were previously marked as invalid), restores the basic request channel, and ensures that there is a usable domain name to try for the next Lookup request; AJX request domain name fallback: If all Lookup backup domain names fail and AJX request backup domain names are also unavailable, the client immediately forces the AJX request domain name to be reset to the preset serverHost (system primary domain name), and marks the serverHost status as "available" to ensure that core business requests are not interrupted, forming a three-level guarantee of "Lookup anomaly → AJX degradation → primary domain name fallback".

[0089] This allows address resources from various sources to be used efficiently and systematically, enabling diverse and flexible switching strategies and adapting to different levels and types of disaster recovery needs.

[0090] In some specific implementations, periodic activation probes are performed on the main domain, and when the number of consecutive successful activation probes on the main domain reaches a preset threshold, business requests are switched back to the main domain, including: Send a lightweight network request to the main domain and mark it with a probe flag, then receive the response from the main domain; Based on the response results, the detection result is determined, which includes success or failure; The cumulative number of consecutive successful activation attempts for the main domain; When the number of consecutive successful activation attempts reaches the preset switchback threshold, the system determines that the main domain has been restored to availability and switches subsequent business requests back to the main domain.

[0091] Here, a lightweight network request is a request designed to minimize network resource consumption and is specifically used to probe service availability.

[0092] Here, the liveness detection flag is a status flag maintained internally by the client to indicate whether a liveness detection request is currently being made to the main domain, in order to prevent duplicate liveness detection requests from being initiated within a single liveness detection cycle.

[0093] Specifically, after the primary domain name is switched to the backup domain name, the client starts a scheduled task to initiate a liveness detection request according to the liveness detection cycle. The request uses HTTPHEAD (only the response header is obtained, and the response body is not transmitted to reduce network resource consumption). If HttpCode200 is returned, it is determined that the liveness detection is successful. When the number of consecutive successful liveness detections reaches the configured threshold, the status of the primary domain name in the "primary domain name mapping table in the package" is immediately updated to "available", and the back-switch logic is triggered (the next business request will use the primary domain name first).

[0094] Specifically, the client maintains a "main domain liveness detection status identifier" locally. If a liveness detection request is already being executed, subsequent liveness detection requests triggered by the interface will be skipped to avoid duplicate liveness detection consuming network resources.

[0095] This effectively avoids frequent and unstable switching caused by the temporary recovery or fluctuation of the main domain, ensuring the stability and security of business traffic when switching back to the main domain, and achieving smooth and reliable traffic scheduling between the main and backup domains.

[0096] In one embodiment, Figure 3 This is another schematic diagram of a process in an embodiment of this application, such as... Figure 3 As shown, the process in this application includes: the Lookup service periodically polls the Native backup domain name pool, the Native backup domain name pool synchronously updates the AJX backup domain name pool, and queries the Native backup domain name pool or AJX backup domain name pool under fault trigger or normal conditions. By judging the backup domain name pool, it is determined whether there is multi-cloud. If there is, the domain name is switched according to the multi-cloud. If not, the request status code is judged to see if there is an exception such as a DNS resolution hit. If there is, the domain name is switched and the request is retried.

[0097] In one embodiment, Figure 4 This is a schematic diagram of the system modules in an embodiment of this application, such as... Figure 4 As shown, the system modules in this application include: a Lookup service module, a data storage module, and a domain name switching module.

[0098] Specifically, the data storage module includes: a lookup backup domain name module, a multi-cloud domain name switching configuration module, an automatic disaster recovery activation configuration module, and an automatic disaster recovery domain name switching configuration module.

[0099] Specifically, the domain name switching module includes multi-cloud switching and automatic disaster recovery switching. Multi-cloud switching includes multi-cloud domain name configuration-triggered switching; automatic disaster recovery switching includes automatic disaster recovery domain name switching configuration + business network access status-triggered switching and primary domain name activation detection.

[0100] In one embodiment, Figure 5 This is a schematic diagram of the process architecture in the embodiments of this application, such as... Figure 5 As shown, the process architecture in this application includes: Native, AJX, lookup service, and business service.

[0101] Specifically, the process includes: starting the AJX engine, loading JS, synchronizing native function domains and interfaces, registering interface access status listeners, caching native function domains and interfaces, AJX accessing the lookup service, the lookup service returning domain data to AJX, AJX storing the domain, and switching the domain.

[0102] Specifically, upper-layer AJX business access includes: specifying the domain name and interface in AJX and initiating a request; initiating a request, supporting direct access to business services via domain name and IP address, business service interface response, native data feedback, request status feedback to AJX, AJX business display, domain name switching in case of an exception, synchronization of native function domain name and interface after domain name switching, and AJX exception reporting to the business service.

[0103] Specifically, the underlying native business access includes: native initiating a request, supporting domain names, direct IP connection to access business services, business service interface response, native request status being sent back to AJX, domain name switching when AJX is abnormal, and synchronization of native function domain names and interfaces after domain name switching.

[0104] It should be understood that, although Figures 1-5 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order in which these steps are executed, and they can be performed in other orders. Furthermore, Figures 1-5 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0105] In one embodiment, such as Figure 6 As shown, a domain name disaster recovery switching device is provided. The device includes: a first processing module 601, used to detect whether there is a multi-cloud domain name replacement rule effective by the server when a primary domain name access failure is detected during a business request; a second processing module 602, used to determine a target backup domain name and perform switching according to the multi-cloud domain name replacement rule when there is a multi-cloud domain name replacement rule; a third processing module 603, used to detect the current network status and determine the fault type of the primary domain name access failure based on a preset anomaly judgment rule when there is no domain name replacement rule; a fourth processing module 604, used to match the corresponding switching strategy and domain name source according to the fault type, wherein the domain name source includes: backup domain name pool, direct connection address list or basic primary domain name; a fifth processing module 605, used to determine the target backup domain name and perform switching according to the switching strategy and domain name source, and verify and report the business access status after switching; and a sixth processing module 606, used to perform periodic probes on the primary domain name after switching to the backup domain name, and switch the business request back to the primary domain name when the number of consecutive successful probes on the primary domain name reaches a preset threshold.

[0106] In a preferred embodiment of this application, the apparatus further includes an update module, which is specifically configured to: send the current location information of the client and the request time node to the server according to the polling cycle; receive a list of backup domain names returned by the server, wherein the list of backup domain names includes at least one of domain name address, weight priority and validity period; update the local backup domain name pool according to the list of backup domain names, and perform connectivity tests on newly added domain names, and add newly added domain names that pass the connectivity test to the backup domain name pool.

[0107] In a preferred embodiment of this application, the update module is further configured to: monitor at least one preset update triggering condition, wherein the update triggering condition includes: application startup event, timed polling event, application foreground / background switching event, or update request exception event; and in response to detecting that any update triggering condition is met, send the client's current location information and request time node to the server.

[0108] In a preferred embodiment of this application, the third processing module 603 is specifically configured to: detect whether an immediate anomaly flag is received in response to the current network status being normal; determine the fault type of the main domain name based on the immediate anomaly flag if an immediate anomaly flag is detected; update the timeout statistics information if no immediate anomaly flag is detected, wherein the timeout statistics information includes the number of consecutive timeouts and / or the timeout rate within the sliding time window; and determine the fault type of the main domain name as a timeout fault if the timeout statistics information meets the preset timeout judgment conditions.

[0109] As a preferred implementation, in this embodiment of the application, the fifth processing module 605 is specifically used to: select an alternative domain name from the domain name sources according to the switching strategy, and re-initiate the business request; in response to the failure of the current business request, obtain the next alternative domain name for retrying until the current business request succeeds or the number of retries reaches the maximum threshold; in response to the success of the current business request, determine the successful domain name as the target alternative domain name; in response to the number of retries reaching the maximum threshold, perform a business downgrade operation.

[0110] As a preferred implementation, in this embodiment of the application, the fifth processing module 605 is further configured to: in response to the domain name source being a backup domain name pool, determine the next available domain name as a backup domain name according to the weight priority order in the backup domain name pool; in response to the domain name source being a direct connection address list, determine the next available address according to the order of the addresses in the direct connection address list, and use the address as the target address of the business request; in response to the domain name source being a base primary domain name, use the base primary domain name as a backup domain name.

[0111] As a preferred implementation, in this embodiment of the application, the sixth processing module 606 is specifically used to: initiate a lightweight network request to the main domain and mark it with a probe identifier, and receive the response result from the main domain; determine the probe result based on the response result, wherein the probe result includes success or failure; accumulate the number of consecutive successful probes to the main domain; and when the number of consecutive successful probes reaches a preset switchback threshold, determine that the main domain has been restored to availability and switch subsequent business requests back to the main domain.

[0112] For specific limitations regarding the domain name disaster recovery switching device, please refer to the limitations on the domain name disaster recovery switching method above, which will not be repeated here. Each module in the aforementioned domain name disaster recovery switching device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0113] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 7 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a domain name disaster recovery switching method. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0114] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0115] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in the embodiments of the disaster recovery switching method for any of the above domain names when running.

[0116] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0117] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in the embodiments of the disaster recovery switching method for any of the above-described domain names.

[0118] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the disaster recovery switching method embodiments of any of the above domain names.

[0119] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0120] The foregoing has provided a detailed description of a domain name disaster recovery switching method, apparatus, device, and readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for disaster recovery switching of a domain name, characterized in that, The method includes: In response to a failure to access the main domain name detected during a business request, check whether there is a multi-cloud domain name replacement rule that takes effect on the server side; In response to the existence of the multi-cloud domain name replacement rule, a target backup domain name is determined according to the multi-cloud domain name replacement rule and a switch is performed; In response to the absence of the domain name replacement rule, the current network status is detected, and the fault type of the failure to access the main domain name is determined based on the preset anomaly judgment rule; Based on the fault type, match the corresponding switching strategy and domain name source, wherein the domain name source includes: backup domain name pool, direct connection address list or base domain name; Based on the switching strategy and the source of the domain name, the target backup domain name is determined and the switching is performed. The service access status after the switching is verified and reported. After switching to the backup domain, periodic activation testing is performed on the primary domain, and when the number of consecutive successful activation tests on the primary domain reaches a preset threshold, the business requests are switched back to the primary domain.

2. The domain name disaster recovery switching method according to claim 1, characterized in that, The method further includes: Based on the polling cycle, send the client's current location information and the request time to the server; Receive the list of alternative domain names returned by the server, wherein the list of alternative domain names includes at least one of domain name address, weight priority and validity period; The local backup domain name pool is updated according to the backup domain name list, and connectivity tests are performed on newly added domain names. Newly added domain names that pass the connectivity test are added to the backup domain name pool.

3. The domain name disaster recovery switching method according to claim 2, characterized in that, Before sending the client's current location and request time to the server according to the polling cycle, the method further includes: Monitor at least one preset update triggering condition, wherein the update triggering condition includes: application startup event, timed polling event, application foreground / background switching event, or update request abnormal event; In response to detecting that any of the update trigger conditions are met, the server sends the client's current location information and the request time point to the server.

4. The domain name disaster recovery switching method according to claim 1, characterized in that, In response to the absence of the domain name replacement rule, the current network status is detected, and the fault type of the main domain name access failure is determined based on a preset anomaly determination rule, including: In response to the current network status being normal, detect whether an immediate anomaly flag has been received; In response to the detection of the immediate anomaly identifier, the fault type of the main domain name is determined based on the immediate anomaly identifier; In response to the absence of the immediate anomaly flag, the timeout statistics are updated, wherein the timeout statistics include the number of consecutive timeouts and / or the timeout rate within the sliding time window; In response to the timeout statistics meeting the preset timeout determination conditions, the fault type of the main domain name is determined to be a timeout fault.

5. The domain name disaster recovery switching method according to claim 1, characterized in that, The step of determining the target backup domain name and performing the switch based on the switching strategy and the domain name source, and verifying and reporting the service access status after the switch, includes: According to the switching strategy, an alternative domain name is selected from the domain name sources, and the business request is re-initiated; In response to the failure of the current business request, obtain the next backup domain name for retry until the current business request succeeds or the number of retries reaches the maximum threshold. Upon successful completion of the current business request, the successful domain name is designated as the target backup domain name; In response to the number of retries reaching the maximum threshold, a service degradation operation is performed.

6. The domain name disaster recovery switching method according to claim 5, characterized in that, The step of selecting an alternate domain name from the domain name sources according to the switching strategy includes: In response to the fact that the domain name originates from the backup domain name pool, the next available domain name is determined as the backup domain name according to the weight priority order in the backup domain name pool; In response to the fact that the domain name originates from the list of directly connected addresses, the next available address is determined according to the order of the addresses in the list of directly connected addresses, and the address is used as the target address of the service request; In response to the fact that the domain name originates from the base primary domain name, the base primary domain name is used as the backup domain name.

7. The domain name disaster recovery switching method according to claim 1, characterized in that, The step of periodically probing the main domain and, when the number of consecutive successful probing attempts on the main domain reaches a preset threshold, switching the service request back to the main domain includes: Initiate a lightweight network request to the main domain and mark it with a probe flag, and receive the response result from the main domain; Based on the response result, a detection result is determined, wherein the detection result includes success or failure; The cumulative number of consecutive successful activation attempts for the main domain name; When the number of consecutive successful activations reaches a preset switchback threshold, the main domain name is determined to be available again, and subsequent business requests are switched back to the main domain name.

8. A domain name disaster recovery switching device, characterized in that, The device includes: The first processing module is used to detect whether there is a multi-cloud domain name replacement rule that takes effect on the server side when the main domain name access failure is detected during the business request process. The second processing module is used to, in response to the existence of the multi-cloud domain name replacement rule, determine the target backup domain name according to the multi-cloud domain name replacement rule and perform the switch; The third processing module is used to detect the current network status in response to the absence of the domain name replacement rule, and determine the fault type of the failure to access the main domain name based on the preset anomaly judgment rule; The fourth processing module is used to match the corresponding switching strategy and domain name source according to the fault type, wherein the domain name source includes: backup domain name pool, direct connection address list or basic main domain name; The fifth processing module is used to determine the target backup domain name and perform the switch according to the switching strategy and the domain name source, and to verify and report the service access status after the switch. The sixth processing module is used to perform periodic activation testing on the main domain after switching to the backup domain, and to switch the business request back to the main domain when the number of consecutive successful activation tests on the main domain reaches a preset threshold.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images