Domain name disaster recovery switching method and device, electronic equipment, storage medium and program product

Abstract

The invention provides a domain name disaster recovery switching method and device, electronic equipment, a storage medium and a program product, and relates to the technical field of computers. According to the method, the gradual and controllable gray release of the domain name switching process is realized through the domain name disaster recovery change-over switch, and the change risk is greatly reduced. And under the condition that the switch is turned on, the main domain name is preferentially used to send the configuration request to the configuration center, so that the configuration file can be quickly acquired under the normal condition, and the efficient operation of the system is ensured. And when the request of the main domain name fails, the main domain name is immediately switched to the standby domain name for retry, and the retry mechanism that the main domain name is preferential and the standby domain name is automatically taken out is adopted, so that the configuration acquisition success rate and the system disaster recovery capability are remarkably improved, and the service continuity and the user experience are ensured.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a domain name disaster recovery switching method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] In internet application architecture, the configuration center, as a core infrastructure, bears the critical responsibility of unified management and dynamic distribution of application configuration information. Clients (referring to applications such as mobile apps, desktop software, and microservices) frequently need to retrieve the latest configuration parameters from the configuration center during startup and operation. The stability and availability of the configuration center directly affect the normal operation of all clients that depend on its services.

[0003] Throughout the application's lifecycle, situations inevitably arise where the configuration center domain name needs to be changed. Traditional domain name switching methods typically employ a direct replacement strategy, the core process of which can be summarized as follows: First, deploy the configuration center service in the new environment and complete the registration, DNS resolution configuration, and SSL (Secure Sockets Layer) certificate deployment for the new domain name. Then, the development team modifies the access address of the configuration center from the old domain name to the new domain name in the client code. Finally, the updated client version is fully deployed through an app store or publishing system, thus completing the domain name switch.

[0004] However, in this approach, the domain name switching takes effect instantly after the new client version is released. If the new infrastructure hosting the new domain has potential issues not discovered during the testing phase, such as incomplete DNS (Domain Name System) resolution, incorrect network firewall policy configuration, improper load balancer configuration, or insufficient capacity of the new environment, a large number of clients will simultaneously be unable to obtain configurations, triggering a service avalanche and severely impacting user experience and business continuity. Summary of the Invention

[0005] The purpose of this application is to provide a domain name disaster recovery switching method, apparatus, electronic device, storage medium, and program product to improve the problem of domain name switching methods affecting user experience and business continuity in the prior art.

[0006] In a first aspect, embodiments of this application provide a domain name disaster recovery switching method, applied to a client, the method comprising: Determine the on / off status of the domain name disaster recovery switch; When the open / closed state is open, a first configuration request is sent to the configuration center using the main domain name; If the first configuration request fails, a second configuration request is sent to the configuration center using an alternative domain name. Both the first and second configuration requests are used to request configuration files from the configuration center.

[0007] In the above implementation process, a domain name disaster recovery switch enables a gradual and controllable canary release of the domain name switching process, significantly reducing the risk of changes. When the switch is on, the primary domain name is used first to send configuration requests to the configuration center, ensuring that configuration files can be quickly obtained under normal circumstances and guaranteeing the efficient operation of the system. When the primary domain name request fails, it immediately switches to the backup domain name for retry. This retry mechanism, which prioritizes the primary domain name and automatically uses the backup domain name as a fallback, significantly improves the success rate of configuration acquisition and the system's disaster recovery capabilities, ensuring service continuity and user experience.

[0008] Optionally, determining the on / off state of the domain name disaster recovery switch includes: Obtain the activation ratio value of the domain name disaster recovery switch; The on / off state of the domain name disaster recovery switch is determined based on the activation ratio value and the client information.

[0009] In the above implementation process, by enabling the setting of the ratio value, the scope of affected clients can be precisely controlled, realizing a gradual canary release and greatly reducing the risk of large-scale switching. At the same time, by combining client information for decision-making, the switching strategy can be flexibly adjusted according to different client information, avoiding the large-scale risks that may be brought about by global switching, and significantly improving the reliability of the release process and user experience.

[0010] Optionally, determining the on / off state of the domain name disaster recovery switch based on the activation ratio value and the client information includes: Generate a random number, the random number being a value between 0 and 1; If the random number is less than or equal to the activation ratio value, then the domain name disaster recovery switch is determined to be in the "on" state, and the activation ratio value is a value between 0 and 1.

[0011] In the above implementation process, a random number decision mechanism provides an extremely lightweight and stateless canary release solution for domain name disaster recovery switching. It is simple and efficient, and can quickly and randomly distribute new features to user groups in a precise proportion without relying on client-side unique identifiers or complex calculations. This stateless random distribution method effectively avoids the overhead of server-side storage and management, while also reflecting the performance of the new domain name in different user scenarios, providing a reliable basis for decision-making on whether to carry out a full switch.

[0012] Optionally, determining the on / off state of the domain name disaster recovery switch based on the activation ratio value and the client information includes: A hash value is generated based on the device identifier to which the client belongs, and the hash value is a value between 0 and 1. If the hash value is less than or equal to the activation ratio value, then the domain name disaster recovery switch is determined to be in the "on" state, and the activation ratio value is a value between 0 and 1.

[0013] In the above implementation process, a deterministic hash algorithm based on device identifiers is used to implement switch control, providing highly consistent and predictable canary release capabilities for domain name disaster recovery switching. This ensures that the switch status of the same device remains consistent across different sessions, completely avoiding user-perceived function switching jitter and greatly improving the stability of the user experience. At the same time, this mechanism provides the operation and maintenance team with precise traffic control capabilities, enabling precise grouping and long-term observation at the device level. This makes the canary release process fully controllable and the results predictable, and provides a stable and reliable basis for user grouping for problem investigation and effect analysis.

[0014] Optionally, the activation ratio value can be a custom configuration, or it can be configured by the server based on the request failure rate of the primary domain name. By setting the activation ratio value to a custom configuration or dynamically configuring it by the server based on the request failure rate of the primary domain name, the flexibility and intelligence of domain name disaster recovery switching are greatly improved. Custom configuration allows developers to flexibly adjust the switching strategy according to actual needs and test results, meeting business requirements in different scenarios. Dynamically configuring the activation ratio value based on the request failure rate of the primary domain name enables intelligent decision-making, automatically adjusting the switching ratio according to actual operating conditions, ensuring timely switching to the backup domain name when the primary domain name is unstable. This effectively reduces the risk of service interruption, improves system availability and stability, avoids unnecessary switching operations, and optimizes resource utilization efficiency.

[0015] Optionally, sending the first configuration request to the configuration center using the main domain name includes: The first configuration request is sent to the configuration center via the system network request library using the main domain name. If the first configuration request fails, the first configuration request is sent again to the configuration center using the main domain name and a custom network request library.

[0016] In the above implementation, by prioritizing the use of the system network request library to initiate configuration requests for the main domain name, and switching to the custom network request library for retrying after failure, the versatility of the system network library and the flexibility and fault tolerance of the custom network library are fully utilized. This two-layer request mechanism not only improves the success rate of requests but also enhances the system's fault tolerance, ensuring stable acquisition of configuration information even in complex network environments.

[0017] Optionally, sending a second configuration request to the configuration center using an alternative domain name includes: A second configuration request is sent to the configuration center using the alternative domain name through the custom network request library.

[0018] In the above implementation, by using only a custom network request library to send configuration requests for the backup domain name, the adaptability and fault tolerance of the custom network library in complex network environments are fully utilized. Since the backup domain name is usually only activated when the primary domain name request fails, its request environment may be more complex or unstable. Therefore, using a custom network library can better handle these situations and improve the success rate of backup domain name requests.

[0019] Optionally, after sending the second configuration request to the configuration center using the alternative domain name, the method further includes: If the second configuration request fails, the error message is recorded and the data points are reported to the server.

[0020] In the above implementation process, after a failed request for the backup domain name, error information is recorded and the data is reported to the server, enabling real-time monitoring and feedback of anomalies during disaster recovery failover. This not only helps developers quickly locate the root cause of the problem but also allows for timely adjustments to strategies to address potential failures. Furthermore, by collecting detailed error data, the system can accumulate operational experience, optimize subsequent disaster recovery strategies, and further improve the system's stability and reliability.

[0021] Optionally, the method further includes: When the open / closed state is closed, a third configuration request is sent using the initial domain name of the configuration center.

[0022] In the above implementation process, even when the domain name disaster recovery switch is off, the initial domain name of the configuration center is still used to send configuration requests, achieving seamless compatibility with the original system. This design ensures that the system can operate normally when no switch is needed or the disaster recovery mechanism is not enabled, and that the introduction of switch logic will not affect existing functions. At the same time, it provides a fallback mechanism for the system; when the disaster recovery switch function encounters problems or is unsuitable, the client can continue to use the initial domain name to obtain configuration information, thereby ensuring service stability and continuity and reducing the potential risks brought about by the switch operation.

[0023] Secondly, embodiments of this application provide a domain name disaster recovery switching device, the device comprising: The switch status determination module is used to determine the open / closed status of the domain name disaster recovery switching switch; The first request sending module is used to send a first configuration request to the configuration center using the main domain name when the open / closed state is open. The second request sending module is used to send a second configuration request to the configuration center using an alternate domain name if the first configuration request fails. Both the first configuration request and the second configuration request are used to request a configuration file from the configuration center.

[0024] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the steps of the method provided in the first aspect above are performed.

[0025] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the steps of the method provided in the first aspect above.

[0026] Fifthly, embodiments of this application provide a computer program product, including computer program instructions, which, when read and executed by a processor, perform the steps of the method provided in the first aspect above.

[0027] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing embodiments of this application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0028] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 A flowchart illustrating a domain name disaster recovery switching method provided in this application embodiment; Figure 2 A structural block diagram of a domain name disaster recovery switching device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device for performing a domain name disaster recovery switching method, provided in an embodiment of this application. Detailed Implementation

[0030] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0031] It should be noted that the terms "system" and "network" in the embodiments of this invention can be used interchangeably. "Multiple" refers to two or more; therefore, in the embodiments of this invention, "multiple" can also be understood as "at least two". "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / ", unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0032] It should also be noted that all actions involving the acquisition of signals, information, or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where the application is located, and with the authorization granted by the owner of the relevant device.

[0033] This application provides a domain name disaster recovery switching method. This method achieves a gradual and controllable canary release of the domain name switching process through a domain name disaster recovery switching switch, significantly reducing the risk of changes. When the switch is on, the primary domain name is prioritized to send configuration requests to the configuration center, ensuring that configuration files can be quickly obtained under normal circumstances and guaranteeing efficient system operation. When the primary domain name request fails, it immediately switches to the backup domain name for retry. This retry mechanism, which prioritizes the primary domain name and automatically uses the backup domain name as a fallback, significantly improves the success rate of configuration acquisition and system disaster recovery capabilities, ensuring service continuity and user experience.

[0034] Please refer to Figure 1 , Figure 1 A flowchart of a domain name disaster recovery switching method provided in this application embodiment is included, the method comprising the following steps: Step S110: Determine the on / off state of the domain name disaster recovery switch.

[0035] In this solution, to facilitate monitoring of new feature deployments, a domain name disaster recovery switch is configured on the server side. This switch is a dynamic configuration mechanism that allows for the enabling or disabling of certain functions by modifying the configuration without redeploying the application. Specifically, in this solution, it controls whether the domain name disaster recovery switch logic is enabled. The domain name disaster recovery switch is used to control the openness of the domain name disaster recovery switch function. For example, some clients can use the domain name disaster recovery switch if the switch is enabled, while others cannot use it if the switch is disabled. This switch allows for a gradual and controlled canary release of the domain name disaster recovery switch function, reducing the risk of domain name changes.

[0036] Domain name disaster recovery switch is typically stored in the server's configuration center or feature switch system. Clients can request the switch's on / off status from the server during startup or periodic checks. To prevent connection failures, clients can persist the on / off status of the switch locally for each successful connection. Subsequent requests for the switch's on / off status can first retrieve it from local storage; if not found locally, it can then be retrieved from the server. Alternatively, clients can request the switch's on / off status from the server each time; if the request fails, the locally cached status will be used.

[0037] In some implementations, the on / off state of the switch may include on and off.

[0038] Step S120: When the open / closed state is open, send the first configuration request to the configuration center using the main domain name.

[0039] Clients will only attempt to initiate requests using the new domain name if the domain disaster recovery switch is enabled. The new domain name can include the primary domain and a backup domain, which can be pre-configured in the client. The primary domain is the domain used first, while the backup domain serves as an alternative when the primary domain becomes inaccessible, ensuring service continuity. The backup domain is typically a pre-configured backup address independent of the primary domain, usually deployed across different network infrastructures, cloud service providers, or regions to ensure it does not experience the same type of failure as the primary domain.

[0040] Understandably, the client stores at least two domains, one of which can be identified as the primary domain, and the other as backup domains. The client can first initiate a first configuration request using the primary domain. This first configuration request can be understood as a URL constructed based on the primary domain, followed by an HTTP / HTTPS request initiated using the URL.

[0041] Step S130: If the first configuration request fails, a second configuration request is sent to the configuration center using the backup domain name.

[0042] After receiving the first configuration request, the server can resolve the main domain name. If the resolution fails, a connection cannot be established. At this time, the server can return a response message indicating that the request failed to the client. After receiving the response message, the client knows that the request has failed and can then initiate a second configuration request using the backup domain name. That is, the second configuration request is a request initiated based on the backup domain name.

[0043] Both the first configuration request and the second configuration request are used to request configuration files from the configuration center. A configuration file is a text file containing various settings, parameters, and instructions. The client reads this configuration file during startup or runtime and executes tasks based on its contents.

[0044] Of course, if the server successfully resolves the primary domain name of the first configuration request and successfully establishes a connection with the client, it can retrieve the configuration file from the configuration center and send it to the client. If the first configuration request fails and the client initiates a second configuration request, the server continues to resolve the alternative domain name of the second configuration request. If the resolution is successful, the server retrieves the latest configuration file from the configuration center and returns it to the client. If the resolution fails again, the server returns a response message indicating that the request failed to the client.

[0045] If the client receives another failed response, it can either re-initiate the configuration request using the backup domain, or log the error and select the old configuration cached within the application to continue running, waiting for the next retry. One or more backup domains can be configured. When multiple backup domains are available, their usage order can be determined by weight or priority. With multiple backup domains, the client can prioritize using the backup domain with the highest priority or weight. If the request fails, it will select the backup domain with the next highest priority or weight to try again, until the maximum number of attempts is reached or all backup domains are used. If the request still fails, an error log can be logged, and the old configuration cached within the application can be selected to continue running, waiting for the next retry.

[0046] Understandably, in this solution, the client can determine whether the request has failed by recognizing the response information returned by the server. If the response information includes network error, timeout, and / or 5xx status code, the request is considered to have failed.

[0047] In the above implementation process, a domain name disaster recovery switch enables a gradual and controllable canary release of the domain name switching process, significantly reducing the risk of changes. When the switch is on, the primary domain name is used first to send configuration requests to the configuration center, ensuring that configuration files can be quickly obtained under normal circumstances and guaranteeing the efficient operation of the system. When the primary domain name request fails, it immediately switches to the backup domain name for retry. This retry mechanism, which prioritizes the primary domain name and automatically uses the backup domain name as a fallback, significantly improves the success rate of configuration acquisition and the system's disaster recovery capabilities, ensuring service continuity and user experience.

[0048] Based on the above embodiments, in the above implementation method of determining the open / closed state of the domain name disaster recovery switch, the server can directly return to the client whether the switch is open or closed, so that the client can directly determine the open / closed state of the switch.

[0049] In some implementations, the switch also supports gradual rollout, allowing some clients to enable the domain name disaster recovery switching scheme. In this case, an activation ratio can be set for the switch. The client can first obtain the activation ratio of the domain name disaster recovery switching switch, and then determine the on / off state of the domain name disaster recovery switching switch based on the activation ratio and the client's information.

[0050] The enable / disable ratio is a value between 0 and 1, indicating what percentage of clients can enable the domain name disaster recovery switchover function. For example, an enable / disable ratio of 0.3 means that 30% of clients will enable the function, while the remaining 70% will not. In this implementation, the on / off state stored in the configuration center or function switch system is no longer a simple "on / off" Boolean value, but a precise ratio. Alternatively, the enable / disable ratio can also be a value between 0 and 100, representing a percentage; for example, an enable / disable ratio of 30 means that the enable / disable ratio is 30%.

[0051] Initially, the client can send a request to the server to obtain the on / off status of the switch. Upon receiving the request, the server can retrieve the on / off ratio value of the switch from the configuration center or the function switch system and send it to the client. If the network request fails or a parsing error occurs, the client can use a safe default value, such as a default value of 0.2 or 0 for the on / off ratio, which means the new function is not enabled. This ensures that the system maintains the most conservative and stable state when the configuration center is unavailable.

[0052] After obtaining the enable / disable ratio value, the client can determine the enable / disable state by combining its own information. That is, it can determine whether the client is within the enable / disable ratio value. If it is, it is determined to be in the enable state; otherwise, it is considered to be in the disable state.

[0053] In the above implementation process, by enabling the setting of the ratio value, the scope of affected clients can be precisely controlled, realizing a gradual canary release and greatly reducing the risk of large-scale switching. At the same time, by combining client information for decision-making, the switching strategy can be flexibly adjusted according to different client information, avoiding the large-scale risks that may be brought about by global switching, and significantly improving the reliability of the release process and user experience.

[0054] The above-mentioned methods for determining the on / off state of the domain name disaster recovery switch by combining the activation ratio value and client information can include the following: Method 1: The client information includes a random number generated by the client. The client can first generate a random number, which is a value between 0 and 1. If the random number is less than or equal to the activation ratio value, the domain name disaster recovery switch is determined to be on; otherwise, it is off. The activation ratio value is a value between 0 and 1.

[0055] When a client needs to determine the switch status, it can call the random number generator in its programming language to generate a floating-point number or integer between 0 and 1, without specifying the exact value.

[0056] The client compares the generated random number with the opening ratio value. If the random number is less than or equal to the opening ratio value, the opening / closing state is determined to be open; otherwise, it is closed.

[0057] For example, if the opening ratio is 0.3 and the random number is 0.45, then the opening / closing state is determined to be closed.

[0058] In this implementation, since the random number generated by the client is random each time, the same client may get different on / off states each time it executes.

[0059] In the above implementation process, a random number decision mechanism provides an extremely lightweight and stateless canary release solution for domain name disaster recovery switching. It is simple and efficient, and can quickly and randomly distribute new features to user groups in a precise proportion without relying on client-side unique identifiers or complex calculations. This stateless random distribution method effectively avoids the overhead of server-side storage and management, while also reflecting the performance of the new domain name in different user scenarios, providing a reliable basis for decision-making on whether to carry out a full switch.

[0060] Method 2: The client information includes the device identifier to which the client belongs. The client can first generate a hash value based on the device identifier. The hash value is a number between 0 and 1. If the hash value is less than or equal to the activation ratio, the domain name disaster recovery switch is determined to be on; otherwise, it is off.

[0061] The client can first read the unique identifier of its device, such as the device ID. This device ID is a stable and unique string assigned to the device by the operating system. After obtaining the device identifier, the client can apply a hash function to hash the device identifier to obtain an initial hash value. Then, divide this initial hash value by 100 to obtain a hash value between 0 and 1. This hash value is then compared with the enable ratio value. Alternatively, the initial hash value can be modulo 100 to obtain an integer between 0 and 99, which is then compared with the enable ratio value (if the enable ratio value is between 0 and 100).

[0062] For example, if the final hash value is 0.15 and the open ratio is 0.3, then the open / closed state is determined to be open.

[0063] In the above implementation process, a deterministic hash algorithm based on device identifiers is used to implement switch control, providing highly consistent and predictable canary release capabilities for domain name disaster recovery switching. This ensures that the switch status of the same device remains consistent across different sessions, completely avoiding user-perceived function switching jitter and greatly improving the stability of the user experience. At the same time, this mechanism provides the operation and maintenance team with precise traffic control capabilities, enabling precise grouping and long-term observation at the device level. This makes the canary release process fully controllable and the results predictable, and provides a stable and reliable basis for user grouping for problem investigation and effect analysis.

[0064] In the above implementation of client-side determination of switch open / closed state, the server can also make the decision. For example, when the client requests to obtain the switch state, it can simultaneously send its own generated random number or device identifier. The server can compare the random number or hash value with the open / closed ratio value in the same way as above, and then return the switch state to the client as open or closed based on the comparison result. In this way, the client does not need to calculate it itself, but the server judges it and directly tells the client the result, which can reduce the client's resource consumption.

[0065] If no on / off ratio is set, the server can pre-configure the mapping between the client's device identifier and the on / off state. When the client requests the on / off state, it simultaneously sends its own device identifier to the server. The server looks up the mapping based on the device identifier to obtain the on / off state and sends it to the client. In this way, the mapping can also control which clients can enable the domain name disaster recovery switching logic, while other clients still use the old domain name to access the site.

[0066] When establishing the mapping between device identifiers and on / off states, developers can filter clients that can use the disaster recovery switchover solution based on dimensions such as device type, user level, and region. These clients can then be bound to the on / off state, indicating that these clients can use the disaster recovery switchover solution to access the configuration center.

[0067] Based on the above embodiments, the activation ratio of the domain name disaster recovery switch can be a custom configuration, or the activation ratio can be configured by the server based on the request failure rate of the main domain name.

[0068] Custom configurations can be understood as fixed values ​​manually set and entered by operations and maintenance personnel or developers based on factors such as business needs, release plans, or risk assessments. For example, relevant personnel can directly set the enabled percentage value through the configuration center's management backend, API, or command-line tools.

[0069] Of course, custom configurations can be manually changed. For example, operations personnel can initially set the enable ratio to 0.1 in the configuration center backend. This means that approximately 10% of clients will start using the new domain name, while the remaining 90% will still use the old domain name. After observing for a day and finding no problems, the operations personnel can manually adjust the ratio to 0.5. After confirming stability again, the ratio is set to 1 to complete the switchover for all clients.

[0070] With dynamic configuration of the enabled ratio, the server can periodically calculate the percentage of failed requests among the client's requests to the main domain within a specified time window to obtain the request failure rate.

[0071] In some implementations, the client can report all request tracking data (including request domain name, success / failure status, time consumption, and error code) to the server's monitoring system. The monitoring system can aggregate this data in real time and calculate the failure rate of the main domain name within the current time window (e.g., the last 5 minutes). The monitoring system can preset one or more failure rate thresholds and corresponding adjustment rules. The system can periodically check the calculated failure rate, compare it with the thresholds, and then automatically execute the adjustment rules.

[0072] Adjustment rules can be as follows: Rule 1: If the failure rate is greater than the first failure rate threshold, then reduce the activation ratio; Rule 2: If the failure rate is less than the second failure rate threshold (the first failure rate threshold is greater than the second failure rate threshold), then increase the activation ratio.

[0073] The monitoring system can then rewrite the adjusted activation ratio value into the configuration center, and the server or client will use the latest activation ratio value to determine the on / off status of the switch.

[0074] In some implementations, the initial activation ratio of the domain name disaster recovery switch can be customized and manually controlled. Once the customized activation ratio reaches a set value (e.g., 0.2), an automatic adjustment mechanism can be enabled. This means the server dynamically adjusts the ratio based on the request failure rate (the threshold can be 0.2). This allows the system to automatically advance while ensuring stability. Of course, manual intervention is still maintained, allowing for the overriding of automatic configuration at any time or intervention in complex scenarios.

[0075] In the above implementation process, by setting the enable ratio to a custom configuration or dynamically configuring it on the server side based on the primary domain's request failure rate, the flexibility and intelligence of domain disaster recovery switching are greatly improved. Custom configuration allows developers to flexibly adjust the switching strategy according to actual needs and test results, meeting business requirements in different scenarios. Dynamically configuring the enable ratio based on the primary domain's request failure rate enables intelligent decision-making, automatically adjusting the switching ratio according to actual operating conditions. This ensures timely switching to the backup domain when the primary domain is unstable, effectively reducing service interruption risks, improving system availability and stability, while avoiding unnecessary switching operations and optimizing resource utilization efficiency.

[0076] Based on the above embodiments, in the method of sending the first configuration request to the configuration center using the main domain name, the first configuration request can be sent to the configuration center through the system network request library using the main domain name first. If the first configuration request fails, the first configuration request can be sent to the configuration center again using the main domain name through the custom network request library.

[0077] The system network request library is a fundamental library provided by the operating system for network communication. It serves as the standard interface for device network capabilities, such as CFNetwork in iOS, HttpURLConnection or OkHttp in Android, etc. The system network request library is characterized by its lightweight, stability, low power consumption, and deep integration with the system, but its strategies are relatively conservative and its customization capabilities are limited.

[0078] The client can use the main domain name to construct a standard HTTP / HTTPS request URL and a first configuration request. A short timeout (e.g., 3 seconds) can be set for this request, and the system library's default retry, caching, and protocol handling strategies can be used. The client can then call the system network request library's API to initiate the first configuration request. Upon receiving the first configuration request, the server resolves the main domain name to an IP address, establishes a TCP connection, performs an SSL handshake, etc. If the server fails to resolve the domain name, fails to establish a TCP connection, or fails to establish a secure connection, it will return a request failure response or an HTTP error code to the client. If the client receives a request failure response, a 4xx or 5xx error code, or does not receive a response within the timeout period, the client can determine that the request has failed and can resend the first configuration request using a custom network request library.

[0079] Custom network request libraries can be developed or deeply customized and encapsulated by the client team. They are usually built on top of the system network request library, but with added enhanced logic and fault tolerance mechanisms. Their advantages include powerful functionality, flexible strategies, and the ability to handle complex network problems; however, they are complex to implement and consume relatively high resources.

[0080] Similarly, the client constructs a standard HTTP / HTTPS request URL using the same main domain, which is also the first configuration request. A short timeout (e.g., 3 seconds) can be set for this request, after which the client can invoke the API of its custom network request library to initiate the first configuration request. The server receives the first configuration request and performs the same processing.

[0081] When calling a custom network request library, a series of enhanced features will be enabled, such as: HTTPDNS: bypassing the operating system's Local DNS and directly accessing the DNS server via the HTTP protocol, effectively avoiding DNS hijacking and slow resolution issues; Direct IP Connection: if the server IP is known in advance, it can bypass domain name resolution and connect directly; Better Timeout and Retry Strategies: a different timeout period may be set, and intelligent retries may be performed for specific error codes; Protocol Upgrade: it may prioritize using more advanced transport protocols such as QUIC.

[0082] In the above implementation, by prioritizing the use of the system network request library to initiate configuration requests for the main domain name, and switching to the custom network request library for retrying after failure, the versatility of the system network library and the flexibility and fault tolerance of the custom network library are fully utilized. This two-layer request mechanism not only improves the success rate of requests but also enhances the system's fault tolerance, ensuring stable acquisition of configuration information even in complex network environments.

[0083] Based on the above embodiments, if the client sends the first configuration request to the configuration center again through the custom network request library using the main domain name and the request still fails, the client can send the second configuration request to the configuration center again through the custom network request library using the backup domain name.

[0084] If the client fails to resend the first configuration request to the configuration center using the primary domain via a custom network request library, it indicates that the primary domain is unavailable. At this point, a backup domain can be enabled. For example, the client can load the backup domain from its local configuration or memory, then replace the primary domain with the backup domain and reconstruct the request URL, i.e., the second configuration request. The client then calls the API of the custom network request library to send the second configuration request. This is because the primary domain is unavailable, entering an emergency disaster recovery state, requiring the use of tools with the strongest fault tolerance capabilities.

[0085] The client can set a longer timeout for this request (e.g., 10 seconds), as this is the last line of defense and requires more time to attempt to retrieve the configuration, allowing for a longer wait. If the alternative domain request succeeds, the client will successfully obtain the configuration file and parse it to update the local cache. If the alternative domain request also fails, it indicates that all remote configuration retrieval methods have failed. In this case, the client can use the local cache, such as loading the previous valid configuration from the client's local persistent storage, to ensure that the client's basic functions are allowed, and / or, log errors, and / or, may disable some non-core functions to prevent more serious problems caused by running under incorrect configuration, and / or, continue to retry (during retry, requests can be initiated again using the alternative domain through a self-developed network request library, or through the system network request library using the alternative domain).

[0086] Understandably, when initiating a second configuration request using an alternative domain name, the client can first initiate a second configuration request using the alternative domain name through the system network request library. If the request fails, then the client can initiate a second configuration request using the alternative domain name through a custom network request library. Of course, if there are multiple alternative domain names, the client can select each alternative domain name to initiate the request in order of weight or priority.

[0087] By using only a custom network request library to send configuration requests for the alternate domain name, the adaptability and fault tolerance of the custom network library in complex network environments are fully utilized. Since the alternate domain name is usually only activated when the primary domain name request fails, its request environment may be more complex or unstable. Therefore, using a custom network library can better handle these situations and improve the success rate of the alternate domain name request.

[0088] In some implementations, if the second configuration request fails, the client can also record error information and report the data points to the server.

[0089] Error messages can be detailed descriptions of the reasons for request failure, used for subsequent analysis. For example, after determining that a request has failed, the client can construct a structured error message object in memory, including the following key fields: error type and error code, timestamp, request context, device and environment information, etc.

[0090] Error messages can be used to construct event tracking data. Event tracking data is structured data used to monitor and analyze the system's operational status. It is not just error messages; it can also include event types and business context. For example, if the client uses error messages as the core content and packages them into a more complete event tracking event, it will also include the following information: unique event type identifier, session ID, whether disaster recovery failover was triggered, and error message.

[0091] If the client determines that the network is still available, it immediately attempts to send the event tracking data to the server's log collection server. If the network is unavailable, the event tracking data packet is persistently stored in a local file or database and added to the reporting queue. Once the network is restored, the client retryes sending the data.

[0092] The log collection server can receive event tracking data reported by clients and write it to a distributed log system or big data platform. The server can then consume these logs for aggregation and analysis. Monitoring rules can be set, such as triggering an alarm when the number of events reporting event tracking data exceeds 100 within 5 minutes. Once the alarm threshold is reached, the operations team can be notified via SMS, application, or other channels.

[0093] In some implementations, the server can also monitor the configuration files in the configuration center. For example, the server can check the storage status of the configuration files and issue an alert when an anomaly is detected. The server can periodically attempt to establish a connection with the configuration center and perform simple query or read operations to verify whether the storage read and write functions are normal, and record the time taken for storage operations. If the time exceeds a threshold, it is considered an anomaly. When an anomaly is detected, an alarm message can be automatically generated and output to the operations and maintenance personnel to remind them to intervene in a timely manner.

[0094] In the above implementation process, after a failed request for the backup domain name, error information is recorded and the data is reported to the server, enabling real-time monitoring and feedback of anomalies during disaster recovery failover. This not only helps developers quickly locate the root cause of the problem but also allows for timely adjustments to strategies to address potential failures. Furthermore, by collecting detailed error data, the system can accumulate operational experience, optimize subsequent disaster recovery strategies, and further improve the system's stability and reliability.

[0095] Based on the above embodiments, when the domain name disaster recovery switch is in the off state, a third configuration request can be sent using the initial domain name of the configuration center.

[0096] The initial domain name can refer to the configuration center domain name hard-coded in the client code and initially used. It is the baseline domain name for stable system operation. When no new disaster recovery features are enabled, the client uses this domain name by default. The initial domain name is usually the old domain name, while the primary domain name and backup domain name are the new domain names. When the domain name disaster recovery switch is in the off state, the client directly sends a configuration request to the initial domain name. This ensures that when the switch is off, the system behavior is completely consistent with that before the disaster recovery solution was introduced, providing a safety fallback bottom line. Furthermore, the switch can isolate the old and new logic, preventing the complexity of new features from affecting the core stability process of the system.

[0097] When a client sends a third-party configuration request using the initial domain name, it can initiate the request through the system network request library. For the timeout policy, the default timeout time of the system network request library can be used or a relatively short timeout setting can be set.

[0098] If the third configuration request still fails, the client will not try the alternative domain name, but will execute the normal error handling process, such as using the old configuration cached locally, logging the error, waiting for the next timed trigger or manual retry by the user.

[0099] In addition, in the above embodiments, if the open / closed state is open, and the client fails to send the second configuration request again through the custom network request library using the backup domain name, it can also fall back to the initial domain name, that is, use the initial domain name to send the third configuration request to try again.

[0100] In the above implementation process, even when the domain name disaster recovery switch is off, the initial domain name of the configuration center is still used to send configuration requests, achieving seamless compatibility with the original system. This design ensures that the system can operate normally when no switch is needed or the disaster recovery mechanism is not enabled, and that the introduction of switch logic will not affect existing functions. At the same time, it provides a fallback mechanism for the system; when the disaster recovery switch function encounters problems or is unsuitable, the client can continue to use the initial domain name to obtain configuration information, thereby ensuring service stability and continuity and reducing the potential risks brought about by the switch operation.

[0101] Please refer to Figure 2 , Figure 2This is a structural block diagram of a domain name disaster recovery switching device 200 provided in an embodiment of this application. The device 200 may be a module, program segment, or code on an electronic device. It should be understood that the device 200 corresponds to the above method embodiment and is capable of performing the various steps involved in the method embodiment. The specific functions of the device 200 can be found in the description above. To avoid repetition, detailed descriptions are appropriately omitted here.

[0102] Optionally, the device 200 includes: The switch status determination module 210 is used to determine the open / closed status of the domain name disaster recovery switching switch; The first request sending module 220 is used to send a first configuration request to the configuration center using the main domain name when the open / closed state is open. The second request sending module 230 is used to send a second configuration request to the configuration center using an alternate domain name if the first configuration request fails, wherein both the first configuration request and the second configuration request are used to request a configuration file from the configuration center.

[0103] Optionally, the switch state determination module 210 is used to obtain the opening ratio value of the domain name disaster recovery switching switch; and determine the opening / closing state of the domain name disaster recovery switching switch based on the opening ratio value and the client information.

[0104] Optionally, the switch state determination module 210 is used to generate a random number, the random number being a value between 0 and 1; if the random number is less than or equal to the opening ratio value, then the domain name disaster recovery switching switch is determined to be in the open state, the opening ratio value being a value between 0 and 1.

[0105] Optionally, the switch state determination module 210 is used to generate a hash value based on the device identifier to which the client belongs, wherein the hash value is a value between 0 and 1; if the hash value is less than or equal to the opening ratio value, then the domain name disaster recovery switching switch is determined to be in the open state, wherein the opening ratio value is a value between 0 and 1.

[0106] Optionally, the enable ratio value can be a custom configuration, or the enable ratio value can be configured by the server based on the request failure rate of the main domain name.

[0107] Optionally, the first request sending module 220 is used to send a first configuration request to the configuration center through the system network request library using the main domain name; if the first configuration request fails, the first configuration request is sent to the configuration center again using the main domain name through the custom network request library.

[0108] Optionally, the second request sending module 230 is used to send a second configuration request to the configuration center through the custom network request library using an alternate domain name.

[0109] Optionally, the device 200 further includes: The information reporting module is used to record error information and report the data points to the server if the second configuration request fails.

[0110] Optionally, the device 200 further includes: The third request sending module is used to send a third configuration request using the initial domain name of the configuration center when the open / closed state is closed.

[0111] It should be noted that those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0112] Please refer to Figure 3 , Figure 3 This application provides a schematic diagram of the structure of an electronic device for performing a domain name disaster recovery switching method. The electronic device may include: at least one processor 310, such as a CPU; at least one communication interface 320; at least one memory 330; and at least one communication bus 340. The communication bus 340 is used to establish communication between these components. In this embodiment, the communication interface 320 is used for signaling or data communication with other node devices. The memory 330 may be a high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 330 may also be at least one storage device located remotely from the aforementioned processor. The memory 330 stores computer-readable instructions, which, when executed by the processor 310, cause the electronic device to perform the aforementioned method process.

[0113] Understandable. Figure 3 The structure shown is for illustrative purposes only; the electronic device may also include components that are more advanced than those shown. Figure 3 The more or fewer components shown, or having the same Figure 3 The different configurations shown. Figure 3 The components shown can be implemented using hardware, software, or a combination thereof.

[0114] This application provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it performs the method process executed by the electronic device in the above method embodiments.

[0115] This embodiment discloses a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer can perform the methods provided in the above-described method embodiments, such as including: Determine the on / off status of the domain name disaster recovery switch; When the open / closed state is open, a first configuration request is sent to the configuration center using the main domain name; If the first configuration request fails, a second configuration request is sent to the configuration center using an alternative domain name. Both the first and second configuration requests are used to request configuration files from the configuration center.

[0116] In summary, this application provides a domain name disaster recovery switching method, apparatus, electronic device, storage medium, and program product. This method achieves a gradual and controllable canary release of the domain name switching process through a domain name disaster recovery switching switch, significantly reducing the risk of changes. When the switch is on, the primary domain name is prioritized to send configuration requests to the configuration center, ensuring rapid acquisition of configuration files under normal circumstances and guaranteeing efficient system operation. When the primary domain name request fails, it immediately switches to the backup domain name for retry. This retry mechanism, which prioritizes the primary domain name and automatically uses the backup domain name as a fallback, significantly improves the success rate of configuration acquisition and system disaster recovery capabilities, ensuring service continuity and user experience.

[0117] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0118] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0119] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0120] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0121] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A domain name disaster recovery switching method, characterized in that, Applied to a client, the method includes: Determine the on / off status of the domain name disaster recovery switch; When the open / closed state is open, a first configuration request is sent to the configuration center using the main domain name; If the first configuration request fails, a second configuration request is sent to the configuration center using an alternative domain name. Both the first and second configuration requests are used to request configuration files from the configuration center.

2. The method according to claim 1, characterized in that, Determining the on / off state of the domain name disaster recovery switch includes: Obtain the activation ratio value of the domain name disaster recovery switch; The on / off state of the domain name disaster recovery switch is determined based on the activation ratio value and the client information.

3. The method according to claim 2, characterized in that, Determining the on / off state of the domain name disaster recovery switch based on the activation ratio value and the client information includes: Generate a random number, the random number being a value between 0 and 1; If the random number is less than or equal to the activation ratio value, then the domain name disaster recovery switch is determined to be in the "on" state, and the activation ratio value is a value between 0 and 1.

4. The method according to claim 2, characterized in that, Determining the on / off state of the domain name disaster recovery switch based on the activation ratio value and the client information includes: A hash value is generated based on the device identifier to which the client belongs, and the hash value is a value between 0 and 1. If the hash value is less than or equal to the activation ratio value, then the domain name disaster recovery switch is determined to be in the "on" state, and the activation ratio value is a value between 0 and 1.

5. The method according to claim 2, characterized in that, The enable ratio value is a custom configuration, or the enable ratio value is configured by the server based on the request failure rate of the main domain name.

6. The method according to claim 1, characterized in that, The step of sending a first configuration request to the configuration center using the main domain name includes: The first configuration request is sent to the configuration center via the system network request library using the main domain name. If the first configuration request fails, the first configuration request is sent again to the configuration center using the main domain name and a custom network request library.

7. The method according to claim 6, characterized in that, Sending a second configuration request to the configuration center using an alternative domain name includes: A second configuration request is sent to the configuration center using the alternative domain name through the custom network request library.

8. The method according to claim 1, characterized in that, After sending the second configuration request to the configuration center using the backup domain name, the process further includes: If the second configuration request fails, the error message is recorded and the data points are reported to the server.

9. The method according to claim 1, characterized in that, The method further includes: When the open / closed state is closed, a third configuration request is sent using the initial domain name of the configuration center.

10. A domain name disaster recovery switching device, characterized in that, The device includes: The switch status determination module is used to determine the open / closed status of the domain name disaster recovery switching switch; The first request sending module is used to send a first configuration request to the configuration center using the main domain name when the open / closed state is open. The second request sending module is used to send a second configuration request to the configuration center using an alternate domain name if the first configuration request fails. Both the first configuration request and the second configuration request are used to request a configuration file from the configuration center.

11. An electronic device, characterized in that, It includes a processor and a memory, the memory storing computer-readable instructions that, when executed by the processor, perform the method as described in any one of claims 1-9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it performs the method as described in any one of claims 1-9.

13. A computer program product, characterized in that, It includes computer program instructions, which, when read and executed by a processor, perform the method as described in any one of claims 1-9.

Images