A method and apparatus for disaster recovery management of front-end resources

Abstract

This application relates to the field of content distribution technology, providing a disaster recovery management method and apparatus for front-end resources to improve the availability and stability of web applications. The method not only packages front-end resources pointing to CDN nodes but also packages pre-downloaded front-end resources and deploys them under different routing paths. Based on access status information from at least one of the CDN nodes and OSS (Service OSS), it determines whether a resource access request should use a first or second routing path, and sends the resources under the corresponding routing path to the terminal device. The resources under the first routing path point to CDN nodes, thereby utilizing CDN to accelerate resource transmission and reduce server load. The resources under the second routing path have already been downloaded, ensuring that resources can still be obtained even when CDN access is abnormal, thus improving the stability and availability of web applications.

Description

Technical Field

[0001] This application relates to the field of content-separated network technology, and in particular to a disaster recovery management method and apparatus for front-end resources. Background Technology

[0002] In the evolution of modern web architecture, Content Delivery Network (CDN) services have become a key strategy for improving user experience and service efficiency. However, the potential vulnerabilities of CDN services (such as network fluctuations or service interruptions) may pose obstacles to front-end resource loading, thereby affecting the stability of web applications and user experience.

[0003] Therefore, it is particularly important to build an efficient and comprehensive front-end resource fault tolerance mechanism. Summary of the Invention

[0004] This application provides a disaster recovery management method and apparatus for front-end resources to improve the stability of front-end resource access in modern Web architecture.

[0005] In a first aspect, embodiments of this application provide a disaster recovery management method for front-end resources, including:

[0006] Receive resource access requests sent by terminal devices; the resource access requests are used to obtain the front-end static resources required to display the business page;

[0007] Based on the access status information sent by the terminal device, the routing path of the resource access request is determined; the access status information is used to indicate whether at least one of the Content Delivery Network (CDN) and Object Storage Service (OSS) is reachable.

[0008] If the access status information is reachable, then the front-end static resources pointing to the CDN node under the first routing path are sent to the terminal device;

[0009] If the access status information is unreachable, the downloaded front-end static resources under the second routing path will be sent to the terminal device.

[0010] Secondly, embodiments of this application provide a disaster recovery management method for front-end resources, the method comprising:

[0011] Send a resource access request to the server; the resource access request is used to obtain the front-end static resources required to display the business page;

[0012] Access status information is sent to the server so that the server can determine the routing path of the resource access request based on the access status information; the access status information is used to indicate whether at least one of the content delivery network CDN and object storage service OSS is reachable;

[0013] The server receives front-end static resources pointing to a CDN node under a first routing path, or receives downloaded front-end static resources under a second routing path; wherein the first routing path corresponds to reachable access status information, and the second routing path corresponds to unreachable access status information.

[0014] Thirdly, embodiments of this application provide a disaster recovery management device for front-end resources, comprising:

[0015] The receiving module is used to receive resource access requests sent by the terminal device; the resource access requests are used to request front-end static resources required to display the business page;

[0016] The determination module is used to determine the routing path of the resource access request based on the access status information sent by the terminal device; the access status information is used to indicate whether at least one of the content delivery network CDN and object storage service OSS is reachable.

[0017] The sending module is configured to send the front-end static resources pointing to the CDN node under the first routing path to the terminal device if the access status information is reachable; and to send the downloaded front-end static resources under the second routing path to the terminal device if the access status information is unreachable.

[0018] Optionally, the sending module is specifically used for:

[0019] Send a first HTML file under a first routing path to the terminal device, so that the terminal device can obtain the front-end static resource from the CDN node according to the first resource tag in the first HTML file; wherein, the first resource tag of the front-end static resource in the first HTML file points to the CDN node in the form of a Uniform Resource Locator (URL).

[0020] Optionally, the sending module is specifically used for:

[0021] Send a second HTML file under a second routing path to the terminal device, so that the terminal device can obtain the front-end static resource from the second routing path according to the second resource tag in the second HTML file; wherein, the second resource tag of the front-end static resource in the second HTML file points to the local directory in the form of an address.

[0022] Optionally, determine the specific use of the module for:

[0023] Receive access status information sent by the terminal device according to a set period;

[0024] If the access status information changes, a Lua script is executed to switch the routing path of the resource access request in the current period.

[0025] Fourthly, embodiments of this application provide a disaster recovery management device for front-end resources, comprising:

[0026] A sending module is configured to send a resource access request to a server; and to send access status information to the server so that the server determines the routing path of the resource access request based on the access status information; wherein the resource access request is used to request front-end static resources required to display a business page, and the access status information is used to indicate whether at least one of a content delivery network (CDN) and an object storage service (OSS) is reachable;

[0027] The receiving module is used to receive front-end static resources pointing to CDN nodes under a first routing path sent by the server, or to receive downloaded front-end static resources under a second routing path sent by the server; wherein the first routing path corresponds to the access status information as reachable, and the second routing path corresponds to the access status information as unreachable.

[0028] Optionally, the sending module is specifically used for:

[0029] Access the CDN nodes and OSS according to the set period;

[0030] If both access attempts fail, an unreachable access status message is sent to the server.

[0031] If at least one access is successful, reachable access status information is sent to the server.

[0032] Optionally, the sending module is specifically used for:

[0033] Count the number of failed accesses;

[0034] If the number of visits exceeds a preset threshold, an unreachable access status message is sent to the server.

[0035] Fifthly, embodiments of this application provide an electronic device, including a processor, a memory, and a communication interface, wherein the communication interface, the memory, and the processor are connected via a bus;

[0036] The communication interface is used for sending and receiving data;

[0037] The memory is used to store computer instructions;

[0038] The processor is configured to read computer instructions from the memory and execute the steps of the method described in either the first or second aspect.

[0039] In a sixth aspect, embodiments of this application provide a computer-readable storage medium including a computer program that, when run on an electronic device, causes the electronic device to perform the steps of the method described in any one of the first and second aspects above.

[0040] In a seventh aspect, embodiments of this application provide a computer program product, the computer program product including a computer program stored in a computer-readable storage medium; when a processor of an electronic device reads the computer program from the computer-readable storage medium, the processor executes the computer program, causing the electronic device to perform the steps of the method described in any one of the first and second aspects above.

[0041] The beneficial effects of the disaster recovery management method and device for front-end resources provided in this application are as follows:

[0042] By packaging front-end resources pointing to CDN nodes and pre-downloaded front-end resources, and deploying them under different routing paths, the system can determine whether a resource access request should use a first or second routing path based on access status information obtained from at least one of the CDN nodes and OSS (Service OSS), and then send the resources under the corresponding routing path to the terminal device. The resources under the first routing path point to the CDN node, thus leveraging the CDN to accelerate resource transmission and reduce server load. The resources under the second routing path have already been downloaded, ensuring that resources can still be obtained even when CDN access is abnormal, thereby improving the stability and availability of the web application.

[0043] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the 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

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

[0045] Figure 1 An exemplary diagram illustrating an application scenario provided in an embodiment of this application is shown;

[0046] Figure 2 A flowchart illustrating a disaster recovery management method for front-end resources provided in an embodiment of this application;

[0047] Figure 3 This is a schematic diagram of server configuration provided in an embodiment of this application;

[0048] Figure 4 This is a schematic diagram of a Lua script for switching routing paths provided in an embodiment of this application;

[0049] Figure 5 This application provides a schematic diagram of the routing process combining nginx and Lua in its embodiments;

[0050] Figure 6 A flowchart illustrating a disaster recovery management method for front-end resources provided in an embodiment of this application;

[0051] Figure 7 This is a code logic diagram of the health detection module provided in an embodiment of this application;

[0052] Figure 8 This is a schematic diagram of the detection process of the health detection module provided in an embodiment of this application;

[0053] Figure 9 A system architecture diagram for disaster recovery management of front-end resources provided in the embodiments of this application;

[0054] Figure 10 A structural diagram of a disaster recovery management device for front-end resources provided in an embodiment of this application;

[0055] Figure 11 A structural diagram of another front-end resource disaster recovery management device provided in an embodiment of this application;

[0056] Figure 12 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0058] Based on the exemplary embodiments shown in this application, all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of this application. Furthermore, although the disclosures in this application are presented by way of one or more exemplary examples, it should be understood that each aspect of these disclosures can constitute a complete technical solution on its own.

[0059] It should be understood that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate, for example, to allow implementation in orders other than those given in the embodiments illustrated or described in this application.

[0060] Furthermore, the terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclusively include, for example, a product or device that includes a series of components is not necessarily limited to those that are explicitly listed, but may include other components that are not explicitly listed or that are inherent to such product or device.

[0061] To clearly describe the embodiments of this application, the terms used in the embodiments of this application will be explained below.

[0062] CDN: A distributed network architecture used to distribute front-end resources to servers in multiple geographical locations, mainly to accelerate the transmission of front-end resources and reduce server load.

[0063] OSS (Object Storage Service): Used to store and manage unstructured data, such as front-end static resources, documents, backup files, etc.

[0064] Nginx: A high-performance open-source HTTP server and reverse proxy server, which can also be used as a load balancer, mail proxy server and caching server.

[0065] Lua: A lightweight, efficient scripting language often used in Nginx configuration files for controlling logic or generating dynamic content.

[0066] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0067] Figure 1An exemplary application scenario diagram provided by an embodiment of this application is shown, which includes a terminal device 110, a server 120, a CDN node 130, and an origin server 140.

[0068] In this embodiment, the terminal device 110 includes, but is not limited to, mobile phones, tablets, laptops, desktop computers, e-book readers, smart voice interaction devices, smart home appliances, in-vehicle terminals, wearable devices, etc. Clients on the terminal device 110 (such as browsers, mini-programs, etc.) can send requests to the server 120 to obtain front-end resources for the opened page. The server 120 dynamically switches resource paths based on the access status of the CDN node 130. It can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing content distribution services. When the access status of the CDN node 130 is reachable and the front-end resource requested by the terminal device 110 is not cached, it requests the resource from the origin server 140 and returns it to the terminal device 110.

[0069] It should be noted that, Figure 1 The examples shown are merely illustrative; in reality, the number of terminal devices, servers, and CDN nodes is unlimited and is not specifically limited in this embodiment.

[0070] It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of this application, and the implementation of this application is not limited in any way.

[0071] In the embodiments of this application, in order to deal with the situation where CDN nodes and OSS resources are unreachable, during the front-end construction stage of business development, the front-end static resources required for displaying the business interface are packaged into two different HTML files, denoted as Product V1 and Product V2, thereby realizing dual backup of resources.

[0072] Product V1 uses the nmp toolchain to point front-end static resources to CDN nodes using Uniform Resource Locators (URLs), thereby leveraging CDN nodes to accelerate resource transmission speed and reduce server load. Product V2 uses the nmp toolchain to pre-download front-end static resources to the local directory, ensuring that web applications can still access front-end page resources normally when CDN services are interrupted and OSS resource access is abnormal.

[0073] In the embodiments of this application, the front-end static resources in the packaged product V1 are based on HTML tags pointing to CDN nodes, thereby preserving the original resource access structure.

[0074] Specifically, the V1 output's HTML file contains three HTML tags: a `link` tag, a first `script` tag, and a second `script` tag. The `link` tag points to the CSS resource on the CDN node, the first `script` tag points to the Vue.js resource on the CDN node, and the second `script` tag points to the Index.js resource on the CDN node. By using the `href` attribute of the `link` tag and the `src` attribute of the `script` tag, these three resources—CSS, Vue.js, and Index.js—can be linked to the CDN node.

[0075] Taking vue.js resources as an example, its URL in the output V1 is: https: / / cdn.xxx.com / vue / @2.6.11 / vue.js.

[0076] In the embodiments of this application, the front-end static resources in the packaged product V2 no longer point to CDN nodes, but are directly downloaded.

[0077] Taking the vue.js resource as an example, its address in the output V2 is: directory / static / js / vue / @2.6.11 / vue.js.

[0078] In one example, two packages of front-end static resources can be packaged into different directories using two different commands.

[0079] Taking the Vue 2 front-end framework as an example, when executing the `nmp run build:prod` command, product 1 will be packaged into the `dist` directory by default. When executing the `nmp run build:backup` command, product 2 will be packaged into the `backup` directory.

[0080] In another example, two packages of front-end static resources can be packaged into different directories using a single command.

[0081] Taking the Vue2 front-end framework as an example, when executing the `nmp run build:all` command, it will first package product 1 to the `dist` directory, and then package product 2 to the `backup` directory.

[0082] It should be noted that the packaging command varies depending on the front-end framework and can be flexibly adjusted according to the actual development situation.

[0083] In the embodiments of this application, the packaged product V1 and product V2 will be deployed to two directories on the server, respectively.

[0084] Assume that product V1 is stored in the resource1 directory of the server, with the routing path / path / to / resource1, and product V2 is stored in the resource2 directory of the server, with the routing path / path / to / resource2.

[0085] In the embodiments of this application, by pre-downloading and packaging the front-end static resources into product V2, a dual backup of the front-end static resources is achieved, which fundamentally enhances the reliability of resource acquisition. Even when CDN service is interrupted and OSS resources are unavailable, the orderly supply of front-end static resources can be ensured. At the same time, by retaining product V1 of the original resource access structure, CDN nodes are used to accelerate resource transmission speed and reduce server load.

[0086] Based on the aforementioned products V1 and V2, disaster recovery management of front-end resources can be achieved when the business interface is opened.

[0087] See Figure 2 This is a disaster recovery management method flow for front-end resources provided in an embodiment of this application. The flow is executed by the server and mainly includes the following steps:

[0088] S201: Receive resource access request sent by terminal device.

[0089] Specifically, in response to the user's operation of opening the business interface, the terminal device sends a resource access request to the server to obtain the front-end static resources required to display the business page.

[0090] S202: Based on the access status information sent by the terminal device, determine the routing path of the resource access request. If the access status information is reachable, determine the routing path of the resource access request as the first routing path and execute S203. If the access status information is unreachable, determine the routing path of the resource access request as the second routing path and execute S204.

[0091] This application embodiment introduces a health detection module and deploys it on the terminal device. In this way, the terminal device can access CDN nodes and OSS according to a set period, and send access status information to the server to indicate whether at least one of CDN and OSS is reachable based on the access results. This enables the server to execute Lua scripts to switch the routing path of resource access requests in the current period when the access status information changes, thereby ensuring the reliability of resource access.

[0092] Specifically, if both CDN and OSS fail to access within the current period, the terminal device sends an unreachable access status message to the server. The server then executes a Lua script based on the access status message to switch the routing path of the resource access request within the current period to the second routing path. If at least one of CDN and OSS is successfully accessed within the current period, the terminal device sends a reachable access status message to the server. The server then executes a Lua script based on the access status message to switch the routing path of the resource access request within the current period to the first routing path.

[0093] like Figure 3 As shown, taking Nginx as an example, every time the server receives a notification of access status information sent by the terminal device, it executes a Lua script to switch the routing path, thereby ensuring fast and normal access to resources.

[0094] The Lua script code includes the following: Figure 4 As shown. In Lua scripts, under normal access conditions, the first route path for front-end static resources points to the directory resource1 where product V1 is located. When access is abnormal, the first route path for front-end static resources points to the directory resource2 where product V2 is located.

[0095] S203: Send the front-end static resources pointing to the CDN node under the first routing path to the terminal device.

[0096] The first routing path is the routing path where product V1 is located.

[0097] When the access status information is "reachable," it indicates that OSS has cached the front-end static resources or that the CDN service is working properly. Since the first HTML file, V1, which points to the CDN node, has been deployed in the resource1 directory, the server will send the first HTML file under the first route path corresponding to the resource1 directory to the terminal device. Because the first resource tag of the front-end static resource in the first HTML file points to the CDN node in the form of a URL (e.g., https: / / cdn.xxx.com / vue / @2.6.11 / vue.js), when the terminal device opens the business interface, it will send a resource request to the CDN node based on the first resource tag in the first HTML file. If OSS has cached the resource, the CDN node directly returns the front-end static resource to the terminal device. If OSS has not cached the resource, the CDN node requests the front-end static resource from the origin server and returns it to the terminal device for display.

[0098] S204: Send the downloaded front-end static resources under the second routing path to the terminal device.

[0099] The second routing path is the routing path where product V2 is located.

[0100] When the access status is unreachable, since the front-end static resources have already been downloaded and packaged into the second HTML file (V2), and deployed in the resource2 directory, the server will send the second HTML file under the second route path corresponding to the resource2 directory to the terminal device. Because the second resource tag of the front-end static resources in the second HTML file points to the local directory in the form of an address (e.g., resource2 / static / js / vue / @2.6.11 / vue.js), when the terminal device opens the business interface, the server will send the downloaded front-end static resources under the second route path to the terminal device for display based on the resource access request.

[0101] See Figure 5 This diagram illustrates the routing process combining Nginx and Lua. Leveraging Nginx's flexible configuration capabilities and Lua's programming flexibility, a dynamic routing and load balancing system is built. When the health check module issues a notification that resource access status is abnormal, the Lua script responds quickly, dynamically adjusting the request routing path according to Nginx's load balancing strategy, seamlessly switching user traffic to resources in the directory containing artifact V2. When the health check module issues a notification that resource access status has returned to normal, user traffic is switched back to resources in the directory containing artifact V1. By integrating Lua scripts to achieve intelligent dynamic resource directory switching, this routing mechanism can respond quickly, redirecting user requests to locally backed-up resources. This achieves automatic repair of resource loading issues without interrupting user access, enabling disaster recovery management of front-end resources and ensuring the continuity of the web application and a seamless user experience.

[0102] In the embodiments of this application, when a CDN service interruption or OSS resource unreachability is detected, an automatic routing switching mechanism that is imperceptible to the front-end user is implemented through resource backup and Lua scripts. This seamlessly redirects resource access requests from the faulty resource path to the healthy resource path, ensuring the continuity and smoothness of the user experience, while reducing the risk of service interruption due to resource failure.

[0103] See Figure 6 This is a disaster recovery management method for front-end resources provided in this application embodiment. The process is executed by a terminal device and mainly includes the following steps:

[0104] S601: Send a resource access request to the server.

[0105] Among them, resource access requests are used to obtain the front-end static resources required to display the business page.

[0106] S602: Send access status information to the server so that the server can determine the routing path for the resource access request based on the access status information.

[0107] The access status information is used to indicate whether at least one of the CDN and OSS is reachable.

[0108] In the embodiments of this application, in order to achieve real-time monitoring of resource access status, an automated health check module is deployed on the terminal device side. This module can periodically perform polling access to CDN and OSS resources to assess the availability status of resources in real time.

[0109] Specifically, the terminal device accesses the CDN node and OSS at a set period (e.g., once per second) to perform CDN and OSS resource reachability checks. If both the CDN node and OSS access fail, the terminal device sends an unreachable access status message to the server. At this time, the server determines the routing path for the resource access request as the first routing path. If at least one of the CDN node and OSS accesses successfully, the terminal device sends a reachable access status message to the server. At this time, the server determines the routing path for the resource access request as the second routing path.

[0110] To avoid the impact of unexpected factors on the access status, in one example, the terminal device can also count the number of access failures and send an unreachable access status message to the server when the count exceeds a preset threshold.

[0111] For example, if a terminal device detects that three consecutive access failures have occurred to the front-end static resources in the CDN node and OSS, it immediately sends an exception notification indicating that the access status is unreachable to the Nginx server via an HTTP POST request. Conversely, if the terminal device detects that the access to the CDN node or OSS is successful, it immediately sends a normal notification indicating that the access status has been restored to reachable status to the Nginx server via an HTTP POST request.

[0112] like Figure 7 The diagram shows the code logic of the health detection module, which implements a more comprehensive and flexible automatic disaster recovery strategy. The health detection module adopts an efficient monitoring mechanism to evaluate the reachability of CDN and OSS resources in real time. Once access anomalies are detected in both, and there are more than 3 consecutive access anomalies, an alarm will be triggered immediately, and this emergency situation will be notified to the Nginx server. At the same time, when access returns to normal, the Nginx server will also be notified, so that the terminal device can access resources normally through the CDN.

[0113] S603: Receive front-end static resources pointing to CDN nodes under the first routing path sent by the server, or receive front-end static resources that have been downloaded under the second routing path sent by the server.

[0114] The access status information for the first routing path is reachable, while the access status information for the second routing path is unreachable.

[0115] See Figure 8 This diagram illustrates the health check module's detection process. Every second, a reachability check is performed on CDN and OSS. If reachable, a normal notification is sent to the Nginx server; if unreachable, an exception notification is sent. This allows the Nginx server to flexibly select the routing path for resource requests based on the notification, improving the reliability and stability of resource access.

[0116] See Figure 9 This diagram illustrates the system architecture for disaster recovery management of front-end resources provided in this application embodiment. It constructs a highly efficient and comprehensive automatic fault-tolerance mechanism through three core technologies: redundant resource storage, real-time health monitoring, and dynamic routing path switching. Specifically, the redundant resource storage component, during the front-end project construction process, not only packages the front-end static resources into resource tags and links them to CDN nodes as artifact V1 via URLs, but also pre-downloads and packages the front-end static resources into artifact V2, which are then deployed to different directories on the Nginx server. The health monitoring module performs reachability checks on CDN and OSS resources at set intervals and sends the results to the Nginx server. The dynamic routing path switching mechanism involves the Nginx server executing Lua scripts based on detection results. This enables dynamic path switching between the directories containing product V1 and product V2 for resource access requests. This ensures that when CDN and OSS resources are abnormal, the resource path is switched to the local directory without the user's awareness. This not only solves the extreme case of simultaneous unavailability of CDN and OSS resources, but also greatly improves the continuity and stability of the user experience while ensuring the high availability of web applications. It builds an unbreakable protection network for modern web systems, and this method does not rely on manual intervention, effectively reducing operation and maintenance costs.

[0117] The disaster recovery management method for front-end resources provided in this application fundamentally enhances the fault tolerance and self-recovery capabilities of the Web system through three core technologies: redundant resource storage, real-time health monitoring, and dynamic routing path switching. It can monitor access status in real time and respond to resource requests instantly. Thanks to the front-end-unaware dynamic routing path switching technology, users do not need to experience any interruption or delay when facing CDN and OSS resource failures. Service requests can be quickly and transparently transferred to backup resources, effectively preventing the impact of single point of failure on the overall service. This ensures the high availability and stability of the Web system in complex environments such as high load and high concurrency, providing a solid guarantee for the continuous operation of business, thereby greatly improving the smoothness and satisfaction of user experience.

[0118] Based on the same technical concept, this application embodiment also provides a disaster recovery management device for front-end resources. This disaster recovery management device can implement the steps of the above-mentioned disaster recovery management method for front-end resources on the server side and achieve the same technical effect.

[0119] See Figure 10 The disaster recovery management device includes a receiving module 1001, a determining module 1002, and a sending module 1003, wherein:

[0120] The receiving module 1001 is used to receive resource access requests sent by the terminal device; the resource access requests are used to request front-end static resources required to display the business page;

[0121] The determining module 1002 is used to determine the routing path of the resource access request based on the access status information sent by the terminal device; the access status information is used to indicate whether at least one of the content delivery network CDN and object storage service OSS is reachable.

[0122] The sending module 1003 is configured to send the front-end static resources pointing to the CDN node under the first routing path to the terminal device if the access status information is reachable; and to send the downloaded front-end static resources under the second routing path to the terminal device if the access status information is unreachable.

[0123] Optionally, the sending module 1003 is specifically used for:

[0124] Send a first HTML file under a first routing path to the terminal device, so that the terminal device can obtain the front-end static resource from the CDN node according to the first resource tag in the first HTML file; wherein, the first resource tag of the front-end static resource in the first HTML file points to the CDN node in the form of a Uniform Resource Locator (URL).

[0125] Optionally, the sending module 1003 is specifically used for:

[0126] Send a second HTML file under a second routing path to the terminal device, so that the terminal device can obtain the front-end static resource from the second routing path according to the second resource tag in the second file; wherein, the second resource tag of the front-end static resource in the second HTML file points to the local directory in the form of an address.

[0127] Optionally, module 1002 is specifically used for:

[0128] Receive access status information sent by the terminal device according to a set period;

[0129] If the access status information changes, a Lua script is executed to switch the routing path of the resource access request in the current period.

[0130] Based on the same technical concept, this application embodiment also provides a disaster recovery management device for front-end resources. This disaster recovery management device can implement the steps of the above-mentioned disaster recovery management method for front-end resources on the terminal device side and achieve the same technical effect.

[0131] See Figure 11 The disaster recovery management device includes a sending module 1101 and a receiving module 1102, wherein:

[0132] The sending module 1101 is configured to send a resource access request to the server; and to send access status information to the server so that the server determines the routing path of the resource access request based on the access status information; wherein the resource access request is used to request front-end static resources required to display a business page, and the access status information is used to indicate whether at least one of the content delivery network CDN and object storage service OSS is reachable;

[0133] The receiving module 1102 is used to receive front-end static resources pointing to CDN nodes under a first routing path sent by the server, or to receive front-end static resources that have been downloaded under a second routing path sent by the server; wherein the first routing path corresponds to the access status information as reachable, and the second routing path corresponds to the access status information as unreachable.

[0134] Optionally, the sending module 1101 is specifically used for:

[0135] Access the CDN nodes and OSS according to the set period;

[0136] If both access attempts fail, an unreachable access status message is sent to the server.

[0137] If at least one access is successful, reachable access status information is sent to the server.

[0138] Optionally, the sending module 1101 is specifically used for:

[0139] Count the number of failed accesses;

[0140] If the number of visits exceeds a preset threshold, an unreachable access status message is sent to the server.

[0141] For ease of description, the above sections are divided into modules (or units) according to their functions and described separately. Of course, in implementing this application, the functions of each module (or unit) can be implemented in one or more software or hardware components.

[0142] Having introduced the disaster recovery management method and apparatus for front-end resources according to exemplary embodiments of this application, we will now introduce an electronic device according to another exemplary embodiment of this application.

[0143] Those skilled in the art will understand that various aspects of this application can be implemented as a system, method, or program product. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

[0144] Based on the same inventive concept as the above-described method embodiments, the electronic device provided in this application can be a server or a terminal device. In this embodiment, the structure of the electronic device can be as follows: Figure 12 As shown, it includes a memory 1201, a communication interface 1203, and one or more processors 1202.

[0145] The memory 1201 is used to store computer programs executed by the processor 1202. The memory 1201 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and programs required to run instant messaging functions, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0146] Memory 1201 may be volatile memory, such as random-access memory (RAM); memory 1201 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 1201 may be any other medium capable of carrying or storing a desired computer program having the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 1201 may be a combination of the above-described memories.

[0147] The processor 1202 may include one or more central processing units (CPUs) or digital processing units, etc. The processor 1202 is used to implement the aforementioned disaster recovery management method for front-end resources when calling computer programs stored in the memory 1201.

[0148] Communication interface 1203 is used for communication with other network devices.

[0149] This application embodiment does not limit the specific connection medium between the memory 1201, the communication interface 1203, and the processor 1202. This application embodiment... Figure 12 The memory 1201 and the processor 1202 are connected via a bus 1204, and the bus 1204 is in Figure 12 The diagram uses thick lines to describe the connections between other components; these are for illustrative purposes only and should not be considered limiting. The 1204 bus can be divided into address bus, data bus, control bus, etc. For ease of description, Figure 12 It is described using only a thick line, but does not indicate that there is only one bus or one type of bus.

[0150] The memory 1201 stores a computer storage medium, which stores computer-executable instructions. These instructions are used to implement the front-end resource disaster recovery management method of this application embodiment. The processor 1202 is used to execute the aforementioned front-end resource disaster recovery management method, such as... Figure 2 , Figure 6 As shown.

[0151] In some possible implementations, various aspects of the front-end resource disaster recovery management method provided in this application can also be implemented in the form of a program product, which includes a computer program. When the program product is run on an electronic device, the computer program is used to cause the electronic device to perform the steps in the front-end resource disaster recovery management method according to the various exemplary embodiments of this application described above. For example, the electronic device can perform actions such as... Figure 2 , Figure 6 The steps are shown in the figure.

[0152] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0153] The program product of the embodiments of this application may employ a portable compact disc read-only memory (CD-ROM) and include a computer program, and may run on an electronic device. However, the program product of this application is not limited thereto. In this document, the readable storage medium may be any tangible medium that contains or stores a program that may be used by or in conjunction with a command execution system, apparatus, or device.

[0154] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a readable computer program. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with a command execution system, apparatus, or device.

[0155] Computer programs contained on readable media may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0156] Computer programs for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The computer program can execute entirely on the user's electronic device, partially on the user's electronic device, as a standalone software package, partially on the user's electronic device and partially on a remote electronic device, or entirely on a remote electronic device or server. In cases involving remote electronic devices, the remote electronic device can be connected to the user's electronic device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external electronic device (e.g., via the Internet using an Internet service provider).

[0157] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0158] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0159] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0160] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0161] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0162] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0163] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A disaster recovery management method for front-end resources, characterized in that, The method includes: Receive resource access requests sent by terminal devices; the resource access requests are used to obtain the front-end static resources required to display the business page; Based on the access status information sent by the terminal device, the routing path of the resource access request is determined; the access status information is used to indicate whether at least one of the Content Delivery Network (CDN) and Object Storage Service (OSS) is reachable. If the access status information is reachable, then the front-end static resources pointing to the CDN node under the first routing path are sent to the terminal device; If the access status information is unreachable, the downloaded front-end static resources under the second routing path will be sent to the terminal device.

2. The method as described in claim 1, characterized in that, Sending the front-end static resources pointing to the CDN node under the first routing path to the terminal device includes: Send a first HTML file under a first routing path to the terminal device, so that the terminal device can obtain the front-end static resource from the CDN node according to the first resource tag in the first HTML file; wherein, the first resource tag of the front-end static resource in the first HTML file points to the CDN node in the form of a Uniform Resource Locator (URL).

3. The method as described in claim 1, characterized in that, Sending the downloaded front-end static resources under the second routing path to the terminal device includes: Send a second HTML file under a second routing path to the terminal device, so that the terminal device can obtain the front-end static resource from the second routing path according to the second resource tag in the second HTML file; wherein, the second resource tag of the front-end static resource in the second HTML file points to the local directory in the form of an address.

4. The method according to any one of claims 1-3, characterized in that, Determining the routing path of the resource access request based on the access status information sent by the terminal device includes: Receive access status information sent by the terminal device according to a set period; If the access status information changes, a Lua script is executed to switch the routing path of the resource access request in the current period.

5. A disaster recovery management method for front-end resources, characterized in that, The method includes: Send a resource access request to the server; the resource access request is used to obtain the front-end static resources required to display the business page; Access status information is sent to the server so that the server can determine the routing path of the resource access request based on the access status information; the access status information is used to indicate whether at least one of the content delivery network CDN and object storage service OSS is reachable; The server receives front-end static resources pointing to a CDN node under a first routing path, or receives downloaded front-end static resources under a second routing path; wherein the first routing path corresponds to reachable access status information, and the second routing path corresponds to unreachable access status information.

6. The method as described in claim 5, characterized in that, Sending access status information to the server includes: Access the CDN nodes and OSS according to the set period; If both access attempts fail, an unreachable access status message is sent to the server. If at least one access is successful, reachable access status information is sent to the server.

7. The method as described in claim 6, characterized in that, Sending unreachable access status information to the server includes: Count the number of failed accesses; If the number of visits exceeds a preset threshold, an unreachable access status message is sent to the server.

8. A disaster recovery management device for front-end resources, characterized in that, include: The receiving module is used to receive resource access requests sent by the terminal device; The resource access request is used to request the front-end static resources required to display the business page; The determination module is used to determine the routing path of the resource access request based on the access status information sent by the terminal device; The access status information is used to indicate whether at least one of the Content Delivery Network (CDN) and Object Storage Service (OSS) is reachable; The sending module is used to send the front-end static resources pointing to the CDN node under the first routing path to the terminal device if the access status information is reachable; Furthermore, if the access status information is unreachable, the downloaded front-end static resources under the second routing path are sent to the terminal device.

9. A disaster recovery management device for front-end resources, characterized in that, include: The sending module is used to send resource access requests to the server; In addition, access status information is sent to the server so that the server can determine the routing path of the resource access request based on the access status information; wherein the resource access request is used to request front-end static resources required to display the business page, and the access status information is used to indicate whether at least one of the content delivery network CDN and object storage service OSS is reachable; The receiving module is used to receive front-end static resources pointing to CDN nodes under a first routing path sent by the server, or to receive downloaded front-end static resources under a second routing path sent by the server; wherein the first routing path corresponds to the access status information as reachable, and the second routing path corresponds to the access status information as unreachable.

10. An electronic device, characterized in that, It includes a processor, a memory, and a communication interface, wherein the communication interface, the memory, and the processor are connected via a bus; The communication interface is used for sending and receiving data; The memory is used to store computer instructions; The processor is configured to read computer instructions from the memory and execute the steps of the method according to any one of claims 1 to 7.

Images