Front-end resource disaster recovery method, electronic equipment, storage medium and program product

Abstract

The invention discloses a front-end resource disaster recovery method, electronic equipment, a storage medium and a program product, and relates to the technical field of Internet, comprising the steps of uniformly gathering disaster recovery decision logic from a client to a server, solving the inherent problems of'black box ', difficulty in operation and maintenance and poor consistency of a client scheme, and improving the disaster recovery efficiency. A foundation is laid for constructing an observable and manageable disaster recovery infrastructure; the'health state information 'is combined with the'network address scheduling strategy', so that the failover occurs before the user request is processed; the resource link in the hypertext markup language document is available, so that the performance loss and the experience lagging caused by waiting for overtime loading of the front-end script are eliminated; the uniform resource locators of all the static resources are uniformly replaced in one-time server rendering, so that all the static resources in the page are ensured to be from the same content distribution network address, and page errors caused by mismatching of resource versions are avoided.

Description

A front-end resource disaster recovery method, electronic device, storage medium, and program product Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a front-end resource disaster recovery method, electronic device, storage medium and program product. Background Technology

[0002] With the widespread adoption of micro-frontend architecture in large-scale enterprise applications and the increasing demands for application availability from users, hosting static resources on content delivery networks (CDNs) has become an industry standard practice. Against this backdrop, ensuring the high availability of micro-applications and their static resources, especially how to quickly recover when CDNs fail, has become a key technical challenge. Traditional disaster recovery solutions mainly rely on passive remediation measures on the client side, specifically including: 1. Script tag error event-based rollback mechanisms: In the main application's Hypertext Markup Language (HTML), error listening logic is written for each script or link tag. When a resource loading failure is detected, an attempt is made to switch to a backup CDN address or origin server; 2. Local backup solutions based on service worker threads: Cache critical static resources on the browser side using service worker threads. When the network or CDN is unavailable, an older version of the application is loaded from the local cache.

[0003] However, these traditional client-side disaster recovery solutions have the following significant drawbacks: 1. Poor user experience and severe performance degradation: Error-based rollback mechanisms typically use a serial loading method, meaning they must wait for the main content delivery network address to fail (after a full network timeout, usually several seconds) before starting the loading of the backup address. This results in users having to endure long wait times, deteriorating core page loading performance metrics, and leading to a very poor user experience. 2. Complex implementation and fragile code: Repeated error handling logic needs to be manually written for each resource tag requiring disaster recovery, resulting in bloated and difficult-to-maintain main application code. Furthermore, improper implementation can easily generate zombie requests or race conditions, causing unpredictable errors. 3. Coarse-grained control and inability to guarantee consistency: Disaster recovery decisions are scattered across various resource tags on the client side, making unified scheduling from a global perspective impossible. Different resources, or even different resources on the same page, may roll back to different content delivery networks, which can easily lead to resource version mismatches and application errors in micro-frontend scenarios. 4. Poor observability and difficult maintenance: The disaster recovery process occurs on the browsers of a massive number of users, making it difficult to comprehensively collect and monitor key metrics such as success, failure, and latency. 5. Rigid strategies and lack of intelligence: Existing solutions rely on a simple "failure-switch" logic, failing to make intelligent and optimal routing decisions based on real-time health status of content delivery network nodes, user geographic location, network conditions, and other information. Summary of the Invention

[0004] This application provides a front-end resource disaster recovery method, electronic device, storage medium, and program product to at least solve at least one of the following problems in related technologies: user-perceived latency, large performance loss, difficulty in guaranteeing global consistency, weak operational observability, and rigid disaster recovery strategies.

[0005] This application provides a front-end resource disaster recovery method, which includes: in response to receiving a user request from a client, obtaining multiple pre-configured content delivery network addresses and network address scheduling policies, and simultaneously obtaining multiple pre-maintained health status information, wherein each health status information corresponds one-to-one with a content delivery network address; based on the multiple health status information and in combination with the network address scheduling policy, dynamically determining a target content delivery network address from the multiple content delivery network addresses; injecting the target content delivery network address into the view context data of the user request to obtain the target view context corresponding to the user request; performing server-side rendering of the page template requested by the user according to the target view context to generate a target hypertext markup language document, wherein the Uniform Resource Locators (URLs) of multiple static resources referenced by the target hypertext markup language document are all uniformly pointed to the target content delivery network address; and returning the target hypertext markup language document to the client to respond to the user request.

[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program and implementing a front-end resource disaster recovery method including at least the following steps: in response to receiving a user request from a client, obtaining multiple pre-configured content delivery network addresses and a network address scheduling policy, and simultaneously obtaining multiple pre-maintained health status information, wherein the multiple health status information corresponds one-to-one with the multiple content delivery network addresses; based on the multiple health status information and in combination with the network address scheduling policy, dynamically determining a target content delivery network address from the multiple content delivery network addresses; injecting the target content delivery network address into the view context data of the user request to obtain the target view context corresponding to the user request; performing server-side rendering of the page template requested by the user according to the target view context to generate a target hypertext markup language document, wherein the Uniform Resource Locators (URLs) of multiple static resources referenced by the target hypertext markup language document are all uniformly pointed to the target content delivery network address; and returning the target hypertext markup language document to the client to respond to the user request. This application also provides a computer-readable storage medium storing a computer program, wherein when executed by a processor, the computer program implements at least the following steps: In response to receiving a user request from a client, obtaining multiple pre-configured content delivery network addresses and a network address scheduling policy, and simultaneously obtaining multiple pre-maintained health status information, wherein each health status information corresponds one-to-one with a content delivery network address; based on the multiple health status information and in conjunction with the network address scheduling policy, dynamically determining a target content delivery network address from the multiple content delivery network addresses; injecting the target content delivery network address into the view context data of the user request to obtain the target view context corresponding to the user request; performing server-side rendering of the page template requested by the user according to the target view context to generate a target hypertext markup language document, wherein the Uniform Resource Locators (URLs) of multiple static resources referenced by the target hypertext markup language document are all uniformly pointed to the target content delivery network address; and returning the target hypertext markup language document to the client in response to the user request.

[0007] This application also provides a computer program product, including a computer program that, when executed by a processor, implements a front-end resource disaster recovery method comprising at least the following steps: In response to receiving a user request from a client, obtaining multiple pre-configured content delivery network addresses and a network address scheduling policy, and simultaneously obtaining multiple pre-maintained health status information, wherein each health status information corresponds one-to-one with a content delivery network address; based on the multiple health status information and in conjunction with the network address scheduling policy, dynamically determining a target content delivery network address from the multiple content delivery network addresses; injecting the target content delivery network address into the view context data of the user request to obtain the target view context corresponding to the user request; performing server-side rendering of the page template requested by the user according to the target view context to generate a target hypertext markup language document, wherein the Uniform Resource Locators (URLs) of multiple static resources referenced by the target hypertext markup language document are all uniformly pointed to the target content delivery network address; and returning the target hypertext markup language document to the client in response to the user request.

[0008] This application consolidates disaster recovery decision-making logic from the client to the server, resolving the inherent "black box" nature, difficulty in maintenance, and poor consistency issues of client-side solutions. This lays the foundation for building an observable and manageable disaster recovery infrastructure. By combining "health status information" with "network address scheduling strategies," failover occurs before user requests are processed. Resource links in the Hypertext Markup Language document are inherently available, eliminating performance overhead and lag caused by waiting for front-end scripts to load. By uniformly replacing the Uniform Resource Locator (URL) of all static resources in a single server-side rendering, it ensures that all static resources on the page originate from the same Content Delivery Network (CDN) address, avoiding page errors caused by resource version mismatches. Attached Figure Description

[0009] 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.

[0010] Figure 1 is a flowchart of the front-end resource disaster recovery method in the first embodiment; Figure 2 is an internal structure diagram of the electronic device in the second embodiment. Detailed Implementation

[0011] The technical solutions of 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 of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0012] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0013] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0014] In the first embodiment, as shown in Figure 1, a front-end resource disaster recovery method is provided. The front-end resource disaster recovery method includes: in response to receiving a user request from a client, obtaining multiple pre-configured content delivery network addresses and network address scheduling policies, and simultaneously obtaining multiple pre-maintained health status information, wherein the multiple health status information corresponds one-to-one with the multiple content delivery network addresses; based on the multiple health status information and combined with the network address scheduling policy, dynamically determining the target content delivery network address from the multiple content delivery network addresses; injecting the target content delivery network address into the view context data of the user request to obtain the target view context corresponding to the user request; performing server-side rendering of the page template requested by the user according to the target view context to generate a target hypertext markup language document, wherein the Uniform Resource Locators of multiple static resources referenced by the target hypertext markup language document are all uniformly pointed to the target content delivery network address; and returning the target hypertext markup language document to the client to respond to the user request.

[0015] Specifically, by centralizing disaster recovery decision-making logic from the client to the server, the inherent "black box" nature, difficulty in maintenance, and poor consistency of client-side solutions are resolved, laying the foundation for building an observable and manageable disaster recovery infrastructure. The combination of "health status information" and "network address scheduling strategy" ensures that failover occurs before user requests are processed. Resource links within the Hypertext Markup Language document are inherently available, eliminating performance overhead and lag caused by waiting for front-end script loading timeouts. By uniformly replacing the Uniform Resource Locator (URL) of all static resources in a single server-side rendering, it ensures that all static resources on the page originate from the same content delivery network address, avoiding page errors caused by resource version mismatches.

[0016] Furthermore, before obtaining multiple pre-maintained health status information, the front-end resource disaster recovery method also includes: periodically sending health check requests to multiple content delivery network addresses via a scheduled task, obtaining response results for multiple health check requests, wherein the response results of multiple health check requests correspond one-to-one with multiple content delivery network addresses; maintaining health status information for the corresponding content delivery network address based on the response result of any health check request, wherein the health status information includes at least an availability identifier and request response latency; maintaining health status information for the corresponding content delivery network address based on the response result of any health check request includes: processing any received health check request... The response to the request is parsed to obtain the response status code, response body content, and request timing information, including at least the request sending time and response receiving time. The response status code is compared with the expected status code to obtain a first comparison result, and the response body content is compared with the expected content to obtain a second comparison result. Based on the first and second comparison results, the value of the availability identifier is determined. The request-response delay is calculated based on the request sending time and response receiving time. The value of the availability identifier and the request-response delay are used as the health status information of the corresponding content distribution network address, and are updated and persisted in the server's memory storage.

[0017] Specifically, "periodic health checks" ensure that failover occurs before user requests are processed. Through parsing, comparison, and calculation, the original server responses to client requests are transformed into structured, reliable "availability indicators" and "request response latency" data, providing high-quality, measurable input for subsequent intelligent decision-making. It checks not only network reachability (status codes) but also content correctness, enabling the discovery of deep-seated faults in content delivery network nodes that "can connect but return incorrect content," thus avoiding being deceived by "falsely healthy" nodes.

[0018] Further, based on the first comparison result and the second comparison result, the value of the availability identifier is determined, including: in response to the first comparison result indicating that the response status code is consistent with the expected status code, and the second comparison result indicating that the response body content is consistent with the expected content, the value of the availability identifier is determined to be a first preset value; in response to the first comparison result indicating that the response status code is inconsistent with the expected status code, and / or the second comparison result indicating that the response body content is inconsistent with the expected content, the value of the availability identifier is determined to be a second preset value; wherein, the first preset value indicates that the corresponding content distribution network address is in an available state, and the second preset value indicates that the corresponding content distribution network address is in an unavailable state.

[0019] Specifically, by using strict logical conditions (both status codes and content must be correct), a clear and unambiguous judgment standard is provided for "available" and "unavailable", which realizes the automation of fault identification and reduces misjudgment and missed judgment. This standardized judgment enables the system to respond to the availability of nodes in an instant and consistently, just like a "digital circuit", which is a prerequisite for realizing subsequent automated switching and scheduling.

[0020] Furthermore, based on multiple health status information and combined with network address scheduling strategies, a target content delivery network address is dynamically determined from multiple content delivery network addresses. This includes: determining the current status of the corresponding content delivery network address based on any health status information, wherein the current status is healthy, sub-healthy, or faulty; selecting multiple candidate content delivery network addresses from the multiple content delivery network addresses based on their current status, wherein the current status of the multiple candidate content delivery network addresses is healthy or sub-healthy; and determining the target content delivery network address from the multiple candidate content delivery network addresses according to the network address scheduling strategy.

[0021] Specifically, by introducing the "sub-healthy" state, the system's perception of nodes is upgraded from "usable / unusable" to "usable / usable but slow / unusable". This provides a basis for implementing more refined traffic scheduling strategies (such as prioritizing healthy nodes and downgrading to sub-healthy nodes). Keeping "sub-healthy" nodes in the candidate pool means that when resources are scarce or the performance of some nodes declines, the system still has additional resources to allocate, enhancing the overall resilience and availability of the system.

[0022] Further, based on any health status information, the current status of the corresponding content delivery network address is determined, including: in response to the availability identifier being a first preset value and the request response latency being lower than a first latency threshold, the current status of the corresponding content delivery network address is determined to be a healthy state; in response to the availability identifier being a first preset value and the request response latency being greater than or equal to the first latency threshold and less than a second latency threshold, the current status of the corresponding content delivery network address is determined to be a sub-healthy state; in response to the availability identifier being a second preset value, or the request response latency being greater than the second latency threshold, the current status of the corresponding content delivery network address is determined to be a faulty state.

[0023] Specifically, by introducing a "first latency threshold" and a "second latency threshold," the abstract concept of "sub-health" is transformed into configurable and measurable parameters, allowing operations personnel to precisely adjust the system's behavior based on business needs (such as sensitivity to latency). Even if a node is "available" at the application layer, it will be judged as "faulty" and isolated as long as its latency exceeds the "second latency threshold," which prevents extremely low-performance nodes from dragging down the user experience of the entire system.

[0024] Furthermore, the network address scheduling strategy is a primary / backup priority strategy. Based on this strategy, the target content distribution network address is determined from multiple candidate content distribution network addresses. This includes: searching for a candidate content distribution network address defined as the primary address; in response to finding a primary address and its current state being healthy, designating it as the target address; in response to not finding a primary address, or its current state being sub-healthy or faulty, searching for multiple backup addresses defined as backup addresses from the candidate addresses; and determining the target address from these backup addresses based on a predefined backup address priority order and the current states of the backup addresses.

[0025] Specifically, the "primary first, backup second" switching logic was clearly defined to ensure that the system can always recover according to the preset and optimal path when a failure occurs, avoiding confusion and uncertainty in the switching process. The entire switching process is completed automatically by the system without manual intervention, achieving business recovery at the second or even millisecond level, which greatly improves the system's availability index.

[0026] Furthermore, based on a predefined priority order of backup addresses and the current status of multiple backup content distribution network addresses, a target content distribution network address is determined from the multiple backup content distribution network addresses. This includes: selecting multiple healthy content distribution network addresses from the multiple backup content distribution network addresses that are currently in a healthy state to form a set of healthy content distribution network addresses; in response to the healthy content distribution network address set being non-empty, determining the healthy content distribution network address with the highest backup address priority among the multiple healthy content distribution network addresses as the target content distribution network address; and in response to the healthy content distribution network address set being empty, determining the backup content distribution network address with the highest backup address priority among the multiple backup content distribution network addresses as the target content distribution network address.

[0027] Specifically, a degradation strategy is defined: "prioritize healthy nodes, and if no healthy node is available, use the best sub-healthy node." This ensures that even in the most extreme case (when all backup nodes are underperforming), the system can still select a "relatively optimal" node to provide service, maximizing business continuity rather than directly returning an error. This strategy makes an intelligent trade-off between "node performance (health status)" and "configuration priority." It prioritizes service quality (selecting healthy nodes), and when that cannot be guaranteed, it reverts to the configuration order (selecting the highest-priority sub-healthy node), demonstrating the system's decision-making wisdom in complex failure scenarios.

[0028] In a specific embodiment, the predefined priority order of backup addresses includes ascending order of request response latency of multiple backup content distribution network addresses, and the priority is negatively correlated with the order of arrangement.

[0029] Furthermore, the network address scheduling strategy is a weighted allocation strategy. According to the network address scheduling strategy, the target content distribution network address is determined from multiple candidate content distribution network addresses, including: obtaining the traffic weight pre-allocated to each candidate content distribution network address, wherein the traffic weight allocated to the candidate content distribution network address whose current state is healthy is greater than the traffic weight allocated to the candidate content distribution network address whose current state is sub-healthy; and performing a weighted random selection on the multiple candidate content distribution network addresses according to the traffic weight pre-allocated to each candidate content distribution network address, and determining the result of the random selection as the target content distribution network address.

[0030] Specifically, by dynamically linking the real-time health status of nodes with weight allocation, intelligent traffic scheduling based on quality of service is achieved. It prioritizes directing traffic to healthier nodes with better performance to ensure overall performance and user experience, while also maintaining system resource utilization and resilience in the event of failures by probabilistically retaining traffic from sub-healthy nodes, thus achieving a highly efficient balance between load balancing and disaster recovery capabilities.

[0031] It should be understood that although the steps in the flowchart of Figure 1 are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in Figure 1 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 performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0032] In a second embodiment, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it performs the following steps: in response to receiving a user request from a client, it obtains a plurality of pre-configured content delivery network addresses and a network address scheduling policy, and simultaneously obtains a plurality of pre-maintained health status information, wherein each of the multiple health status information corresponds one-to-one with a plurality of content delivery network addresses; based on the multiple health status information and in conjunction with the network address scheduling policy, it dynamically determines a target content delivery network address from the plurality of content delivery network addresses; it injects the target content delivery network address into the view context data of the user request to obtain the target view context corresponding to the user request; it performs server-side rendering of the page template requested by the user according to the target view context to generate a target hypertext markup language document, wherein the Uniform Resource Locators (URLs) of multiple static resources referenced by the target hypertext markup language document are all uniformly pointed to the target content delivery network address; and it returns the target hypertext markup language document to the client to respond to the user request.

[0033] When the program instructions are read and executed by one or more processors, they can also perform operations corresponding to the steps in the above method embodiments, as described above, and will not be repeated here. Referring to Figure 2, which exemplarily illustrates the architecture of an electronic device, it may specifically include a processor 210, a video display adapter 211, a disk drive 212, an input / output interface 213, a network interface 214, and a memory 220. The processor 210, video display adapter 211, disk drive 212, input / output interface 213, network interface 214, and memory 220 can communicate with each other via a communication bus 230.

[0034] The processor 210 can be implemented using a general-purpose central processing unit (CPU), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solution provided in this application.

[0035] The memory 220 can be implemented as a read-only memory (ROM), random access memory (RAM), static storage device, dynamic storage device, etc. The memory 220 can store the operating system 221 for controlling the operation of the electronic device 200, and the basic input / output system (BIOS) 222 for controlling the low-level operations of the electronic device 200. Additionally, it can store a web browser 223, data storage management 224, and an icon / font processing system 225, etc. The icon / font processing system 225 can be the application program that specifically implements the aforementioned steps in this embodiment. In summary, when implementing the technical solution provided in this application through software or firmware, the relevant program code is stored in the memory 220 and executed by the processor 210.

[0036] Input / output interface 213 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components in the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touch screens, microphones, various sensors, etc., and output devices may include displays, speakers, vibrators, indicator lights, etc.

[0037] Network interface 214 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0038] Bus 230 includes a pathway for transmitting information between various components of the device, such as processor 210, video display adapter 211, disk drive 212, input / output interface 213, network interface 214, and memory 220.

[0039] In addition, the electronic device 200 can also obtain information on specific acquisition conditions from a virtual resource object acquisition condition information database (not shown in the figure) for condition judgment, etc.

[0040] It should be noted that although the above-described electronic device 200 only shows a processor 210, a video display adapter 211, a disk drive 212, an input / output interface 213, a network interface 214, a memory 220, and a bus 230, in specific implementations, the electronic device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the solution of this application, and does not necessarily include all the components shown in the figures.

[0041] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause an electronic device (which may be a personal computer, cloud server, or network device, etc.) to execute the methods of various embodiments or some parts of the embodiments of this application.

[0042] In a third embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When executed by a processor, the computer program performs the following steps: in response to receiving a user request from a client, obtaining multiple pre-configured content delivery network addresses and a network address scheduling policy, and simultaneously obtaining multiple pre-maintained health status information, wherein each health status information corresponds one-to-one with a content delivery network address; based on the multiple health status information and in conjunction with the network address scheduling policy, dynamically determining a target content delivery network address from the multiple content delivery network addresses; injecting the target content delivery network address into the view context data of the user request to obtain the target view context corresponding to the user request; performing server-side rendering of the page template requested by the user according to the target view context to generate a target hypertext markup language document, wherein the Uniform Resource Locators (URLs) of multiple static resources referenced by the target hypertext markup language document are all uniformly pointed to the target content delivery network address; and returning the target hypertext markup language document to the client in response to the user request.

[0043] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0044] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0045] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application.

[0046] In a fourth embodiment, a computer program product 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 receiving a user request from a client, it obtains a plurality of pre-configured content delivery network addresses and a network address scheduling policy, and simultaneously obtains a plurality of pre-maintained health status information, wherein the plurality of health status information corresponds one-to-one with the plurality of content delivery network addresses; based on the plurality of health status information and in combination with the network address scheduling policy, it dynamically determines a target content delivery network address from the plurality of content delivery network addresses; it injects the target content delivery network address into the view context data of the user request to obtain the target view context corresponding to the user request; it performs server-side rendering of the page template requested by the user according to the target view context to generate a target hypertext markup language document, wherein the Uniform Resource Locators of the plurality of static resources referenced by the target hypertext markup language document are all uniformly pointed to the target content delivery network address; and it returns the target hypertext markup language document to the client to respond to the user request.

[0047] In a fourth embodiment, a computer program product is provided, including a non-volatile computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it performs the following steps: in response to receiving a user request from a client, it obtains a plurality of pre-configured content delivery network addresses and a network address scheduling policy, and simultaneously obtains a plurality of pre-maintained health status information, wherein the plurality of health status information corresponds one-to-one with the plurality of content delivery network addresses; based on the plurality of health status information and in combination with the network address scheduling policy, it dynamically determines a target content delivery network address from the plurality of content delivery network addresses; it injects the target content delivery network address into the view context data of the user request to obtain the target view context corresponding to the user request; it performs server-side rendering of the page template requested by the user according to the target view context to generate a target hypertext markup language document, wherein the Uniform Resource Locators of the plurality of static resources referenced by the target hypertext markup language document are all uniformly pointed to the target content delivery network address; and it returns the target hypertext markup language document to the client to respond to the user request. Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer program product, and when the computer program is executed, it can include the processes of the embodiments of the methods described above.

[0048] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0049] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application.

Claims

1. A front-end resource disaster recovery method, applied to the server side, characterized in that, The method includes: in response to receiving a user request from a client, obtaining multiple pre-configured content delivery network addresses and network address scheduling policies, and simultaneously obtaining multiple pre-maintained health status information, wherein the multiple health status information corresponds one-to-one with the multiple content delivery network addresses; based on the multiple health status information and in conjunction with the network address scheduling policies, dynamically determining a target content delivery network address from the multiple content delivery network addresses; injecting the target content delivery network address into the view context data of the user request to obtain the target view context corresponding to the user request; performing server-side rendering of the page template requested by the user according to the target view context to generate a target hypertext markup language document, wherein the Uniform Resource Locators (URLs) of multiple static resources referenced by the target hypertext markup language document are all uniformly pointed to the target content delivery network address; and returning the target hypertext markup language document to the client to respond to the user request.

2. The method according to claim 1, characterized in that, Before acquiring the multiple pre-maintained health status information, the method further includes: periodically sending health check requests to the multiple content delivery network addresses via a scheduled task, obtaining response results of the multiple health check requests, wherein the response results of the multiple health check requests correspond one-to-one with the multiple content delivery network addresses; maintaining health status information of the corresponding content delivery network address based on the response result of any health check request, wherein the health status information includes at least an availability identifier and a request response delay; the step of maintaining the health status information of the corresponding content delivery network address based on the response result of any health check request includes: decrypting the response result of any received health check request. The system analyzes and obtains the response status code, response body content, and request timing information, wherein the request timing information includes at least the request sending time and the response receiving time. It compares the response status code with the expected status code to obtain a first comparison result, and simultaneously compares the response body content with the expected content to obtain a second comparison result. Based on the first and second comparison results, it determines the value of the availability identifier. Based on the request sending time and the response receiving time, it calculates the request response delay. The value of the availability identifier and the request response delay are used as health status information for the corresponding content delivery network address, and are updated and persisted in the server's memory storage.

3. The method according to claim 2, characterized in that, The step of determining the value of the availability identifier based on the first comparison result and the second comparison result includes: in response to the first comparison result indicating that the response status code is consistent with the expected status code, and the second comparison result indicating that the response body content is consistent with the expected content, determining that the value of the availability identifier is a first preset value; in response to the first comparison result indicating that the response status code is inconsistent with the expected status code, and / or the second comparison result indicating that the response body content is inconsistent with the expected content, determining that the value of the availability identifier is a second preset value; wherein, the first preset value indicates that the corresponding content delivery network address is in an available state, and the second preset value indicates that the corresponding content delivery network address is in an unavailable state.

4. The method according to claim 3, characterized in that, The step of dynamically determining the target content distribution network address from the multiple content distribution network addresses based on the multiple health status information and in conjunction with the network address scheduling strategy includes: determining the current status of the corresponding content distribution network address according to any health status information, wherein the current status is a healthy state, a sub-healthy state, or a faulty state; filtering multiple candidate content distribution network addresses from the multiple content distribution network addresses according to the current status of the multiple content distribution network addresses, wherein the current status of the multiple candidate content distribution network addresses is the healthy state or the sub-healthy state; and determining the target content distribution network address from the multiple candidate content distribution network addresses according to the network address scheduling strategy.

5. The method according to claim 4, characterized in that, The step of determining the current state of a corresponding content delivery network address based on any health status information includes: determining the current state of the corresponding content delivery network address as the healthy state in response to the availability identifier being the first preset value and the request response delay being lower than a first delay threshold; determining the current state of the corresponding content delivery network address as the sub-healthy state in response to the availability identifier being the first preset value and the request response delay being greater than or equal to the first delay threshold and less than a second delay threshold; and determining the current state of the corresponding content delivery network address as the fault state in response to the availability identifier being the second preset value or the request response delay being greater than the second delay threshold.

6. The method according to claim 4, characterized in that, The network address scheduling policy is a primary / backup priority policy. Determining the target content distribution network address from the plurality of candidate content distribution network addresses according to the network address scheduling policy includes: searching for a candidate content distribution network address defined as the primary content distribution network address from the plurality of candidate content distribution network addresses; in response to finding the primary content distribution network address and the current state of the primary content distribution network address being the healthy state, determining the primary content distribution network address as the target content distribution network address; in response to not finding the primary content distribution network address, or the current state of the primary content distribution network address being the sub-healthy state or the fault state, searching for a plurality of backup content distribution network addresses defined as backup content distribution network addresses from the plurality of candidate content distribution network addresses; and determining the target content distribution network address from the plurality of backup content distribution network addresses according to a predefined backup address priority order and the current state of the plurality of backup content distribution network addresses.

7. The method according to claim 6, characterized in that, The step of determining the target content distribution network address from the multiple backup content distribution network addresses based on a predefined priority order of backup addresses and the current status of the multiple backup content distribution network addresses includes: filtering out multiple healthy content distribution network addresses whose current status is the healthy state from the multiple backup content distribution network addresses to form a healthy content distribution network address set; in response to the healthy content distribution network address set not being empty, determining the healthy content distribution network address with the highest backup address priority among the multiple healthy content distribution network addresses as the target content distribution network address; in response to the healthy content distribution network address set being empty, determining the backup content distribution network address with the highest backup address priority among the multiple backup content distribution network addresses as the target content distribution network address.

8. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the front-end resource disaster recovery method as described in any one of claims 1 to 7 when executing the computer program.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the front-end resource disaster recovery method as described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the front-end resource disaster recovery method as described in any one of claims 1 to 7.

Images