Multi-level disaster recovery high-availability web architecture

Abstract

This invention relates to a schematic diagram of a multi-level disaster recovery and high availability web architecture. This multi-level disaster recovery and high availability web architecture includes a dynamic domain name resolution and detection module, a CDN and CDN management module, an NLB module, a web server, and a backend application server. Through redundant design and fault-tolerant mechanisms at each level, the entire architecture can effectively cope with various failures from domain name resolution, CDN network, data center entry point to internal services, ensuring end-to-end high availability.

Description

Technical Field

[0001] This invention relates to the field of Internet WEB technology, specifically to a multi-level disaster recovery and high availability WEB architecture. Background Technology

[0002] With the rapid development of mobile internet and internet services, web services have become the core entry point for digital businesses. Their continuous availability directly affects user experience, business stability, and enterprise operational efficiency. High availability has become a key indicator for internet services.

[0003] Traditional high-availability architectures typically focus only on the redundancy design of backend components such as servers and databases, which has obvious limitations: they only focus on the local layer and do not cover the failure risks of upstream network links such as DNS and CDN; failover is relatively passive and relies heavily on request timeouts and failure retries, which affects user experience; a large number of redundant resources need to be configured to achieve disaster recovery, which is costly and has low resource utilization; and in complex distributed architectures, the visibility of operation and maintenance is insufficient, and the efficiency of fault location and recovery is low. Summary of the Invention

[0004] To solve or partially solve the above-mentioned technical problems, this invention provides a multi-level disaster recovery and high availability WEB architecture, which achieves intelligent disaster recovery across the entire chain from client access and network distribution to core services through overall architecture design and strategy optimization.

[0005] The multi-level disaster recovery and high availability web architecture includes:

[0006] The dynamic domain name resolution and detection module is embedded in the user client and is configured to preset a primary domain name and a backup domain name. It receives access requests initiated by the client, performs primary domain name resolution and access availability detection based on the access request. If the primary domain name resolution fails or the access fails, it performs backup domain name resolution and access availability detection based on the access request. After the detection is successful, the resolved access request is sent to the corresponding CDN.

[0007] The CDN and CDN management module is configured to preset the policies and switching conditions of the primary CDN provider and the backup CDN provider, realize CDN configuration synchronization by calling the API of each CDN provider, maintain the configuration information of the primary domain name, backup domain name and root domain in each CDN provider, and configure the primary origin address and backup origin address for CDN.

[0008] The NLB module, deployed in various physical data centers, is configured to receive origin traffic from the CDN, distribute the traffic evenly to the web server cluster within the same data center through preset monitoring rules, detect the running status of the backend web servers in real time, and automatically remove abnormal web server nodes.

[0009] The web server is deployed in a cluster and configured to handle HTTP / HTTPS protocol requests, provide static resource services, rate limit, and preset reverse proxy rules to forward access requests to backend application service instances in the same data center based on the path and domain name of the access request.

[0010] The backend application server is deployed in a multi-instance cluster and is configured to receive access requests forwarded by the web server, execute core business logic and data processing, and after completing the business response, send it back to the user through the original path.

[0011] In one implementation, the dynamic domain name resolution and detection module is further configured to use a globally anycast IP address and rely on the BGP routing protocol and the globally anycast mechanism to route access requests to the nearest DNS resolution service cluster that is in normal service status.

[0012] In one implementation, the primary domain name and the backup domain name belong to different root domains.

[0013] In one implementation, the CDN and management module are further configured to use a bandwidth billing model for the CDN of the primary CDN provider and a traffic billing model for the CDN of the backup CDN provider.

[0014] In one implementation, the multi-level disaster recovery and high availability web architecture further includes:

[0015] The management platform is configured to collect and display the running status information, performance indicators, and dependencies of CDN, NLB modules, web servers, and backend application servers.

[0016] In one implementation, the management platform is further configured to centrally configure and synchronously manage all CDN, origin servers, and link resources; the origin servers include web server clusters and application service instances.

[0017] In this embodiment of the invention, the entire architecture, through redundant design and fault switching mechanisms at each level, can effectively cope with various faults from domain name resolution, CDN network, data center entrance to internal services, ensuring end-to-end high availability.

[0018] The management module is configured to use a bandwidth-based billing model for the primary CDN provider's CDN and a traffic-based billing model for the backup CDN provider's CDN, enabling the architecture to achieve an optimized balance between cost and performance while ensuring high end-to-end availability. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram of a multi-level disaster recovery and high availability WEB architecture provided in an embodiment of the present invention. Detailed Implementation

[0021] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0022] Figure 1 This is a schematic diagram of a multi-level disaster recovery and high-availability web architecture provided in an embodiment of the present invention. Figure 1 As shown, the multi-level disaster recovery and high availability WEB architecture includes a dynamic domain name resolution and detection module 101, a CDN and CDN management module 102, an NLB module 103, a WEB server 104, and a backend application server 105.

[0023] The dynamic domain name resolution and detection module 101 is embedded in the user client and is configured to preset a primary domain name and a backup domain name, receive access requests initiated by the client, perform primary domain name resolution and access availability detection based on the access request, and if the primary domain name resolution fails or the access fails, perform backup domain name resolution and access availability detection based on the access request. After the detection is successful, the resolved access request is sent to the corresponding CDN.

[0024] When an access request is received from a user client, the primary domain name is resolved first, and the service address corresponding to the resolution result is tested for availability. If the primary domain name resolution is normal and the availability test passes, the resolved access request is routed to the CDN node corresponding to the primary domain name. If the primary domain name resolution fails, times out, or the availability test fails, the system automatically switches to the backup domain name, performs domain name resolution and availability test on the backup domain name, and then routes the resolved access request to the CDN node corresponding to the backup domain name after the backup domain name resolution is normal and the availability test passes. This achieves proactive failover from the moment the request is initiated, ensuring seamless high availability.

[0025] The primary domain name and the backup domain name preferably belong to different root domains to avoid the primary domain name and the backup domain name becoming unavailable at the same time due to DNS service failure, resolution anomaly or policy risk in the same root domain. This achieves DNS-level disaster recovery and isolation at the domain name system level, and improves the availability of the overall resolution service and the risk resistance of the architecture.

[0026] The dynamic domain name resolution and detection module 101 can also be configured to use a global anycast IP address and rely on the BGP routing protocol and global anycast mechanism to route access requests to the nearest resolution service cluster that is in normal service status.

[0027] A global anycast IP address provided by a network service provider or cloud vendor can be used as the unified entry point for the resolution service. Relying on the routing capabilities and global anycast mechanism of BGP (Border Gateway Protocol), after receiving an access request initiated by a user client, the access request is automatically routed to the resolution service cluster with the closest physical distance and normal service status, ensuring that the resolution request can be processed with the lowest latency and the highest stability.

[0028] The CDN management module is configured to preset the policies and switching conditions of the primary CDN provider and the backup CDN provider, realize CDN configuration synchronization by calling the API of each CDN provider, maintain the configuration information of the primary domain name, backup domain name and root domain in each CDN provider, and configure the primary origin address and backup origin address for CDN.

[0029] CDN distributes access requests for static resources to the nearest location, while access requests for dynamic resources or requests that require origin access are sent to the corresponding data center's NLB via the primary origin access address or the backup origin access address.

[0030] A strategy employing a primary CDN provider and a backup CDN provider, with the primary and backup CDN providers being from different cloud vendors or CDN service providers, is adopted to achieve cross-vendor level disaster recovery isolation and prevent overall service unavailability due to a single vendor failure. A bandwidth-based billing model is used for the primary CDN provider's CDN (i.e., the primary CDN), while a traffic-based billing model is used for the backup CDN provider's CDN (i.e., the backup CDN). This significantly reduces the overall CDN resource usage cost while ensuring cross-vendor disaster recovery capabilities.

[0031] For example, access requests will be automatically switched from the primary CDN to the backup CDN when any of the following conditions are met:

[0032] The primary CDN node responded with a timeout, connection failed, or service is unavailable.

[0033] The main CDN returns an abnormal return code, the link is interrupted, or the service quality is lower than the preset threshold.

[0034] By calling the management APIs provided by various CDN providers, unified configuration and automatic synchronization of parameters such as acceleration configuration, caching policies, and security policies between the primary and backup CDNs are achieved. The system maintains the domain name configuration, certificate configuration, and acceleration policy information of the primary domain name, backup domain name, and corresponding root domain across each CDN provider; and configures a primary origin address and a backup origin address for each CDN. When the primary origin address fails, it automatically switches to the backup origin address for origin access, ensuring high availability of the CDN origin link.

[0035] The NLB module 103 is deployed in each physical data center and is configured to receive origin traffic from CDN, distribute traffic evenly to the WEB server cluster in the same data center through preset monitoring rules, detect the running status of the backend WEB servers in real time, and automatically remove abnormal WEB server nodes.

[0036] The NLB module serves as the traffic entry point and distribution hub for the data center. Its core function is to handle CDN origin traffic and achieve high availability and high-performance distribution. Specifically, it receives origin traffic from the CDN and, through preset monitoring rules, evenly distributes the traffic to the web server cluster within the same data center, achieving traffic load balancing and preventing overload of any single web server. It also features a built-in health check mechanism that monitors the operational status of backend web servers in real time, automatically removing abnormal web server nodes to ensure that traffic is only distributed to normally functioning nodes, guaranteeing the reliability of traffic distribution.

[0037] The WEB server 104 is deployed in a clustered manner and is configured to handle HTTP / HTTPS protocol requests, provide static resource services, rate limiting, preset reverse proxy rules, and forward access requests to backend application service instances in the same data center according to the path and domain name of the access request.

[0038] The web server can be a high-performance Nginx web server. As an application layer gateway and reverse proxy, its core functions include processing HTTP(S) protocol requests, implementing request routing and forwarding, providing basic service capabilities such as static resource services, load balancing, and rate limiting, ensuring the stability and security of request processing. Furthermore, through preset reverse proxy rules, it forwards access requests to backend application service instances within the same data center based on the request path and domain name, achieving traffic loop closure and reducing request forwarding latency and architectural complexity.

[0039] The web servers are deployed in a cluster behind NLB, with a stateless design and support for horizontal scaling. Web server nodes can be dynamically added or removed according to traffic load to meet the usage needs of different traffic scenarios.

[0040] The backend application server 105 is deployed in a multi-instance cluster and is configured to receive access requests forwarded by the web server, execute core business logic and data processing, and after completing the business response, return it to the user terminal via the original path.

[0041] The backend application server carries core business logic and data processing. It can be developed based on microservice frameworks in languages ​​such as Java, Go, and Python to achieve modular and scalable design of the core business logic. Deployed as a multi-instance cluster within the same data center, it leverages a distributed architecture to achieve high availability, preventing core business unavailability due to single instance failure. The backend application server receives access requests forwarded by the web server, executes core business logic and data processing, and after completing the business response, feeds it back to the user through the original path, realizing business value output.

[0042] The multi-level disaster recovery and high availability WEB architecture may also include a management and control platform 106.

[0043] The management and control platform 106 is configured to collect and display the operating status information, performance indicators, and dependencies of CDN, NLB modules, WEB servers, and backend application servers.

[0044] The management platform provides global resource link visualization and real-time monitoring, helping operations personnel quickly locate fault points and understand architectural dependencies. By deploying lightweight agents in components such as CDN, NLB modules, web servers, and backend application servers, or by calling monitoring APIs from various cloud vendors, it automatically collects the operational status information, performance metrics, and dependencies of each component. A graph database stores the logical and physical relationships between "domain name-CDN-NLB-web server-backend application server," ensuring accurate recording and efficient querying of link relationships. The front-end interface dynamically renders the global link in the form of a topology graph, displaying the health status and traffic paths of each node in real time, providing operations personnel with an intuitive understanding of the architectural situation and enabling fault location within minutes.

[0045] The management and control platform 106 can also be configured to centrally configure and synchronize all CDN, origin servers, and link resources; the origin servers include WEB server clusters and application service instances.

[0046] Centralized configuration and synchronization management of all CDN, origin, and link resources enables unified control and automatic synchronization of resource configurations, avoids the risk of failure caused by inconsistent configurations across multiple platforms and nodes, reduces the complexity of operation and maintenance under distributed architecture, improves configuration distribution efficiency and system consistency, and enhances the maintainability and reliability of the overall architecture.

[0047] In this embodiment, the entire architecture, through redundancy design and fault switching mechanisms at each level, can effectively cope with various faults from domain name resolution, CDN network, data center entrance to internal services, ensuring high availability from end to end while achieving an optimized balance between cost and performance.

[0048] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A multi-level disaster recovery and high availability web architecture, characterized in that, include: The dynamic domain name resolution and detection module is embedded in the user client and is configured to preset a primary domain name and a backup domain name. It receives access requests initiated by the client, performs primary domain name resolution and access availability detection based on the access request. If the primary domain name resolution fails or the access fails, it performs backup domain name resolution and access availability detection based on the access request. After the detection is successful, the resolved access request is sent to the corresponding CDN. The CDN and CDN management module is configured to preset the policies and switching conditions of the primary CDN provider and the backup CDN provider, realize CDN configuration synchronization by calling the API of each CDN provider, maintain the configuration information of the primary domain name, backup domain name and root domain in each CDN provider, and configure the primary origin address and backup origin address for CDN. The NLB module, deployed in various physical data centers, is configured to receive origin traffic from the CDN, distribute the traffic evenly to the web server cluster within the same data center through preset monitoring rules, detect the running status of the backend web servers in real time, and automatically remove abnormal web server nodes. The web server is deployed in a cluster and configured to handle HTTP / HTTPS protocol requests, provide static resource services, rate limit, and preset reverse proxy rules to forward access requests to backend application service instances in the same data center based on the path and domain name of the access request. The backend application server is deployed in a multi-instance cluster and is configured to receive access requests forwarded by the web server, execute core business logic and data processing, and after completing the business response, send it back to the user through the original path.

2. The multi-level disaster recovery and high availability WEB architecture according to claim 1, characterized in that: The dynamic domain name resolution and detection module is also configured to use a globally anycast IP address, relying on the BGP routing protocol and the global anycast mechanism, to route access requests to the nearest resolution service cluster that is in normal service status.

3. The multi-level disaster recovery and high availability WEB architecture according to claim 1 or 2, characterized in that: The primary domain name and the backup domain name belong to different root domains.

4. The multi-level disaster recovery and high availability WEB architecture according to claim 1 or 2, characterized in that: The management module is also configured to use a bandwidth billing model for the CDN of the primary CDN provider and a traffic billing model for the CDN of the backup CDN provider.

5. The multi-level disaster recovery and high availability WEB architecture according to claim 1, characterized in that, Also includes: The management platform is configured to collect and display the running status information, performance indicators, and dependencies of CDN, NLB modules, web servers, and backend application servers.

6. The multi-level disaster recovery and high availability WEB architecture according to claim 5, characterized in that, The management and control platform is also configured to centrally configure and synchronize all CDN, origin servers, and link resources; the origin servers include web server clusters and application service instances.

Images