CN119583438A

CN119583438A - A disaster recovery management method and device for front-end resources

Info

Publication number: CN119583438A
Application number: CN202411712359.1A
Authority: CN
Inventors: 邱雪; 王舵; 霍跃斌
Original assignee: Tianyi Safety Technology Co Ltd
Current assignee: Tianyi Safety Technology Co Ltd
Priority date: 2024-11-27
Filing date: 2024-11-27
Publication date: 2025-03-07

Abstract

The application relates to the technical field of content distribution, and provides a disaster recovery management method and device for front-end resources, which are used for improving the usability and stability of Web applications. The method not only packages the front-end resources pointing to the CDN node, but also packages the front-end resources downloaded in advance and deploys the front-end resources under different routing paths, so that according to the access state information for detecting the resource reachability of at least one of the CDN node and the OSS, whether the resource access request uses the first routing path or the second routing path is determined, and the resources under the corresponding routing paths are sent to the terminal equipment. The resources under the first routing path point to CDN nodes, so that the CDN is utilized to accelerate the transmission of the resources and reduce the load of a server, and the resources under the second routing path are downloaded, so that the resources can be obtained when the CDN access is abnormal, and the stability and the usability of the Web application are improved.

Description

Disaster recovery management method and device for front-end resources

Technical Field

The application relates to the technical field of content separation networks, in particular to a disaster recovery management method and device for front-end resources.

Background

In the evolution of modern Web architecture, content delivery network (Content Delivery Network, CDN) services have become a key strategy to improve user experience and service efficiency. However, the potential vulnerability of the CDN service (such as network fluctuations or service interruption) may form a barrier to front-end resource loading, thereby affecting the stability and user experience of the Web application.

Therefore, it is important to construct an efficient and comprehensive fault-tolerant mechanism for front-end resources.

Disclosure of Invention

The embodiment of the application provides a disaster recovery management method and device for front-end resources, which are used for improving the stability of front-end resource access in a modern Web architecture.

In a first aspect, an embodiment of the present application provides a disaster recovery management method for a front-end resource, including:

receiving a resource access request sent by terminal equipment, wherein the resource access request is used for acquiring front-end static resources required by displaying a service page;

determining a routing path of the resource access request according to the access state information sent by the terminal equipment, wherein the access state information is used for indicating whether at least one of a content delivery network CDN and an object storage service OSS is reachable or not;

if the access state information is reachable, front-end static resources which point to CDN nodes under a first route path are sent to the terminal equipment;

and if the access state information is not reachable, the downloaded front-end static resource under the second routing path is sent to the terminal equipment.

In a second aspect, an embodiment of the present application provides a disaster recovery management method for a front-end resource, where the method includes:

The method comprises the steps of sending a resource access request to a server, wherein the resource access request is used for obtaining front-end static resources required by displaying a service page;

Sending access state information to the server so that the server determines a routing path of the resource access request according to the access state information, wherein the access state information is used for indicating whether at least one of a content delivery network CDN and an object storage service OSS is reachable or not;

And receiving front-end static resources which are sent by the server and point to CDN nodes under a first routing path or receiving front-end static resources which are sent by the server and downloaded under a second routing path, wherein the first routing path corresponds to the access state information and is reachable, and the second routing path corresponds to the access state information and is unreachable.

In a third aspect, an embodiment of the present application provides a disaster recovery management device for front-end resources, including:

The system comprises a receiving module, a receiving module and a processing module, wherein the receiving module is used for receiving a resource access request sent by a terminal device, wherein the resource access request is used for requesting front-end static resources required by displaying a service page;

The system comprises a terminal device, a determining module, a routing module and a control module, wherein the terminal device is used for sending access status information to the terminal device;

and the sending module is used for sending the front-end static resource which points to the CDN node under the first route path to the terminal equipment if the access state information is reachable, and sending the downloaded front-end static resource under the second route path to the terminal equipment if the access state information is not reachable.

Optionally, the sending module is specifically configured to:

And sending a first hml file under a first routing path to the terminal equipment so that the terminal equipment obtains the front-end static resource from the CDN node according to a first resource tag in the first html file, wherein the first resource tag of the front-end static resource in the first hml file points to the CDN node in the form of a Uniform Resource Locator (URL).

Optionally, the sending module is specifically configured to:

And sending a second hml file under a second routing path to the terminal equipment so that the terminal equipment acquires the front-end static resource from the second routing path according to a second resource tag in the second file, wherein the second resource tag of the front-end static resource in the second hml file points to a local directory in an address form.

Optionally, the determining module is specifically configured to:

receiving access state information sent by the terminal equipment according to a set period;

And if the access state information is changed, executing the Lua script to switch the routing path of the resource access request in the current period.

In a fourth aspect, an embodiment of the present application provides a disaster recovery management device for front-end resources, including:

The system comprises a server, a sending module, a server, a sending module and a receiving module, wherein the server is used for sending a resource access request to the server, and sending access state information to the server so that the server can determine a routing path of the resource access request according to the access state information, the resource access request is used for requesting front-end static resources required by a service page to be displayed, and the access state information is used for indicating whether at least one of a content delivery network CDN and an object storage service OSS is reachable or not;

The receiving module is used for receiving front-end static resources which are sent by the server and point to CDN nodes under a first routing path or receiving front-end static resources which are sent by the server and downloaded under a second routing path, wherein the first routing path corresponds to the access state information and is reachable, and the second routing path corresponds to the access state information and is unreachable.

Optionally, the sending module is specifically configured to:

accessing the CDN node and the OSS according to a set period;

if both the access items fail, sending unreachable access state information to the server;

and if at least one access is successful, sending reachable access state information to the server.

Optionally, the sending module is specifically configured to:

Counting the number of access failures;

and if the times are greater than a preset threshold, sending unreachable access state information to the server.

In a fifth aspect, an embodiment of the present application provides an electronic device, including a processor, a memory, and a communication interface, where the communication interface, the memory, and the processor are connected by a bus;

the communication interface is used for receiving and transmitting data;

The memory is used for storing computer instructions;

The processor is configured to read the computer instructions in the memory and perform the steps of the method according to any one of the first and second aspects.

In a sixth aspect, an embodiment of the present application provides a computer readable storage medium comprising a computer program for causing an electronic device to perform the steps of the method according to any one of the first and second aspects, when the computer program is run on the electronic device.

In a seventh aspect, an embodiment of the present application provides a computer program product comprising a computer program stored in a computer readable storage medium, which when read from the computer readable storage medium by a processor of an electronic device, causes the electronic device to perform the steps of the method according to any one of the first and second aspects.

The disaster recovery management method and device for the front-end resources provided by the application have the beneficial effects that:

The method comprises the steps of packaging front-end resources pointing to CDN nodes, packaging the front-end resources downloaded in advance, and deploying the front-end resources under different routing paths, so that whether a first routing path or a second routing path is used by a resource access request is determined through access state information for detecting the resource reachability of at least one of the CDN nodes and the OSS, and the resources under the corresponding routing paths are sent to terminal equipment. The resources under the first routing path point to CDN nodes, so that the CDN is utilized to accelerate the transmission of the resources and reduce the load of a server, and the resources under the second routing path are downloaded, so that the resources can be obtained when the CDN access is abnormal, and the stability and the usability of the Web application are improved.

Additional features and advantages of the application will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the application. The objectives and other advantages of the application will be realized and attained by the structure particularly pointed out in the written description and claims thereof as well as the appended drawings.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions of the prior art, the drawings that are needed in the embodiments or the description of the prior art will be briefly described below, it will be obvious that the drawings in the following description are some embodiments of the present application, and that other drawings can be obtained according to these drawings without inventive effort to a person skilled in the art.

Fig. 1 schematically illustrates an application scenario provided by an embodiment of the present application;

FIG. 2 is a flowchart of a disaster recovery management method for front-end resources according to an embodiment of the present application;

FIG. 3 is a schematic diagram of a server configuration according to an embodiment of the present application;

Fig. 4 is a schematic diagram of a Lua script for switching a routing path according to an embodiment of the present application;

FIG. 5 is a schematic diagram of a routing process of a combination of nginx and Lua according to an embodiment of the application;

FIG. 6 is a flowchart of a disaster recovery management method for front-end resources according to an embodiment of the present application;

FIG. 7 is a code logic diagram of a health detection module according to an embodiment of the present application;

fig. 8 is a schematic diagram of a detection process of the health detection module according to an embodiment of the present application;

FIG. 9 is a system architecture diagram of disaster recovery management for front-end resources according to an embodiment of the present application;

FIG. 10 is a block diagram of a disaster recovery management device for front-end resources according to an embodiment of the present application;

FIG. 11 is a block diagram of another disaster recovery management device for front-end resources according to an embodiment of the present application;

fig. 12 is a block diagram of an electronic device according to an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be described in further detail below with reference to the accompanying drawings, and it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

All other embodiments, which can be made by a person skilled in the art without inventive effort, based on the exemplary embodiments shown in the present application are intended to fall within the scope of the present application. Furthermore, while the present disclosure has been described in terms of an exemplary embodiment or embodiments, it should be understood that each aspect of the disclosure may be separately implemented as a complete solution.

It should be understood that the terms first, second, and the like in the description and in the claims and in the above-described figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate, such as where appropriate, for example, implementations other than those illustrated or described in connection with the embodiments of the application.

Furthermore, the terms "comprise" and "have," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a product or apparatus that comprises a list of elements is not necessarily limited to those elements expressly listed, but may include other elements not expressly listed or inherent to such product or apparatus.

In order to clearly describe the embodiments of the present application, the terms in the embodiments of the present application are explained below.

The CDN is a distributed network architecture and is used for distributing front-end resources to servers in a plurality of geographic positions, and is mainly used for accelerating the transmission of the front-end resources and relieving the load of the servers.

OSS (Object Storage Service, object store service) for storing and managing unstructured data, such as front-end static resources, documents, backup files, etc.

Nginx, high-performance open source HTTP server and reverse proxy server, and can also be used as load balancer, mail proxy server and cache server.

Lua is a lightweight and efficient script programming language, which is commonly used in Nginx configuration files for controlling logic or generating dynamic contents.

The preferred embodiments of the present application will be described below with reference to the accompanying drawings of the specification, it being understood that the preferred embodiments described herein are for illustration and explanation only, and not for limitation of the present application, and embodiments of the present application and features of the embodiments may be combined with each other without conflict.

Fig. 1 schematically illustrates an application scenario provided by an embodiment of the present application, where the application scenario includes a terminal device 110, a server 120, a CDN node 130, and a source station 140.

In the embodiment of the present application, the terminal device 110 includes, but is not limited to, a mobile phone, a tablet computer, a notebook computer, a desktop computer, an electronic book reader, an intelligent voice interaction device, an intelligent home appliance, a vehicle-mounted terminal, a wearable device, and the like, and a client (such as a browser, an applet, and the like) on the terminal device 110 can send a request to the server 120 to obtain a front-end resource of an open page. The server 120 performs dynamic resource path switching according to the access state of the CDN node 130, and may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server that provides a content distribution service. 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, the resource is requested from the source station 140 and returned to the terminal device 110.

It should be noted that, the number of terminal devices, servers and CDN nodes shown in fig. 1 is merely illustrative, and in fact, the number of terminal devices, servers and CDN nodes is not limited, and the embodiment of the present application is not particularly limited.

It should be noted that the above application scenario is only shown for the convenience of understanding the spirit and principle of the present application, and the embodiments of the present application are not limited in any way.

In the embodiment of the application, in order to cope with the situation that CDN nodes and OSS resources are not reachable, front-end static resources required by service interface display are respectively packed into two different html files, and recorded as a product V1 and a product V2 in the front-end construction stage of service development, so that double backup of the resources is realized.

The product V1 points the front-end static resources to CDN nodes in a uniform resource locator (Uniform Resource Locator, URL) mode through nmp tool chains, so that the CDN nodes are utilized to accelerate the resource transmission speed and reduce the server load, and the product V2 downloads the front-end static resources into a local directory in advance through nmp tool chains, so that when CDN service is interrupted and OSS resource access is abnormal, the Web application can normally access the front-end page resources.

In the embodiment of the application, the front-end static resource in the packaged product V1 is pointed to the CDN node based on the html tag, so that the original resource access structure is reserved.

Specifically, the html file of the product V1 includes 3 html tags, which are link tags, a first script tag, and a second script tag, respectively. The link labels point to css resources of the CDN node, the first script labels point to vue.js resources of the CDN node, and the second script labels point to index.js resources of the CDN node. 3 resources, namely css resource, vue.js resource and index.js resource, can be pointed to CDN nodes through href of link label and src of script label.

Taking the vue.js resource as an example, the URL in the product V1 is https:// cdn.xxx.com/vue/@2.6.11/vue.js.

In the embodiment of the application, the front-end static resources in the packaged product V2 are not pointed to CDN nodes any more, but are downloaded directly.

Still taking the example of the vue.js resource, its address in the product V2 is directory/static/js/vue/@ 2.6.11/vue.js.

In one example, two packages of front-end static resources may be packaged into different directories using two different commands, respectively.

Taking vue front end framework as an example, when executing nmp run build:prod command, product 1 is packed under the dist directory by default, and when executing nmp run build:backup command, product 2 is packed under the backup directory.

In another example, two packages of front-end static resources may be packaged separately into different directories using one command.

Taking vue front end framework as an example, when nmp run bulid: all command is executed, product 1 will now be packaged in the dist directory and product 2 will be packaged in the backup directory.

It should be noted that, the packaged command varies with the front end frame, and can be flexibly adjusted according to the actual development situation.

In the embodiment of the application, the packaged products V1 and V2 are deployed under two directories of the server respectively.

Assuming that the product V1 is stored in the resource1 directory of the server, the routing path is/path/to/resource 1, and the product V2 is stored in the resource2 directory of the server, and the routing path is/path/to/resource 2.

In the embodiment of the application, the front-end static resources are downloaded and packaged into the product V2 in advance, so that the dual backup of the front-end static resources is realized, the reliability of resource acquisition is fundamentally enhanced, the orderly supply of the front-end static resources can be ensured even when CDN service is interrupted and OSS resources are not reachable, and meanwhile, the product V1 of the original resource access structure is reserved, so that the transmission speed of the resources is accelerated and the load of a server is reduced by utilizing CDN nodes.

Based on the product V1 and the product V2, disaster recovery management of front-end resources can be realized when a service interface is opened.

Referring to fig. 2, a flow of a disaster recovery management method for front-end resources according to an embodiment of the present application is executed by a server, and mainly includes the following steps:

S201, receiving a resource access request sent by a terminal device.

Specifically, the terminal device responds to the operation of opening the service interface by the user and sends a resource access request for acquiring front-end static resources required by displaying the service page to the server.

S202, determining a routing path of a resource access request according to access state information sent by a terminal device, if the access state information is reachable, determining the routing path of the resource access request as a first routing path, executing S203, if the access state information is not reachable, determining the routing path of the resource access request as a second routing path, and executing S204.

The embodiment of the application introduces the health detection module and is deployed in the terminal equipment, so that the terminal equipment can access the CDN node and the OSS according to a set period, and according to an access result, the access state information for indicating whether at least one of the CDN and the OSS is reachable is sent to the server, so that when the access state information is changed, the server executes the Lua script to switch the routing path of the resource access request in the current period, thereby ensuring the reliability of resource access.

Specifically, if access to both the CDN and the OSS in the current period fails, the terminal device sends unreachable access state information to the server, the server executes the Lua script according to the access state information, the route path of the resource access request in the current period is switched to a first route path, and if at least one of the CDN and the OSS in the current period is successfully accessed, the terminal device sends reachable access state information to the server, the server executes the Lua script according to the access state information, and the route path of the resource access request in the current period is switched to a second route path.

As shown in fig. 3, taking the server as nmginx as an example, the server executes once Lua script to switch the route path every time the server receives the notification of the access status information sent by the terminal device, thereby ensuring quick and normal access of the resource.

Wherein, the partial code of the Lua script is shown in FIG. 4. In the Lua script, under the condition of normal access, a first routing path of the front-end static resource points to a directory resource1 where a product V1 is located, and under the condition of abnormal access, the first routing path of the front-end static resource points to a directory resource2 where a product V2 is located.

And S203, transmitting the front-end static resource which points to the CDN node under the first route path to the terminal equipment.

The first routing path is a routing path where the product V1 is located.

When the access status information is reachable, it indicates that the OSS has cached a front-end static resource or that the CDN service is normal, and because the first html file, i.e., the product V1 directed to the CDN node, has been deployed under the resource1 directory. Therefore, the server sends the first html file under the first route 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 (such as https:// cdn.xxx.com/vue/@ 2.6.11/vue.js) in the form of a URL, when the terminal device opens the service interface, the terminal device sends a resource request to the CDN node according to the first resource tag in the first html file, when the OSS caches the resource, the CDN node directly returns the front-end static resource to the terminal device, and when the OSS does not cache the resource, the CDN node requests the front-end static resource to the source station and returns the front-end static resource to the terminal device for display.

S204, the downloaded front-end static resource under the second route path is sent to the terminal equipment.

The second routing path is the routing path where the product V2 is located.

When the access status information is unreachable, the server sends the second html file under the second routing path corresponding to the resource2 directory to the terminal device because the front-end static resource is downloaded and packaged into the second html file of the product V2 and deployed under the resource2 directory. Because the second resource label of the front-end static resource in the second hml file points to the local directory (such as resource2/static/js/vue/@2.6.11/vue. Js) in an address form, when the terminal equipment opens the service interface, the server sends the downloaded front-end static resource under the second routing path to the terminal equipment for display according to the resource access request.

Referring to fig. 5, a system for dynamic routing and load balancing is constructed by combining the flexible configuration capability of nginix and the programming flexibility of Lua script, which are schematic diagrams of the routing process combining ngix and Lua. When the health check module sends a notice that the resource access state information is abnormal, the Lua script responds rapidly, dynamically adjusts the routing path of the request according to the load balancing strategy of Nginx, seamlessly switches the user traffic to the resource in the catalog where the product V2 is used, and when the health check module sends a notice that the resource access state information is recovered to be normal, switches the user traffic to the resource in the catalog where the product V1 is used. The intelligent dynamic switching of the resource catalogue is realized through integrating the Lua script, the route switching mechanism can respond rapidly, the user request is redirected to the locally backed-up resource, the problem of resource loading is automatically repaired under the condition that the user access is not interrupted, disaster recovery management of front-end resources is realized, and the continuity of Web application and seamless experience of the user access are ensured.

In the embodiment of the application, when the CDN service interruption or the unreachable OSS resource is detected, an automatic route switching mechanism which is not perceived by a front-end user is realized through the resource backup and the Lua script, the resource access request is seamlessly redirected from a fault resource path to a healthy resource path, the continuity and fluency of user experience are ensured, and meanwhile, the service interruption risk caused by the resource fault is reduced.

Referring to fig. 6, a flow of a disaster recovery management method for front-end resources provided by an embodiment of the present application is executed by a terminal device, and mainly includes the following steps:

And S601, sending a resource access request to a server.

The resource access request is used for acquiring front-end static resources required by the display service page.

And S602, sending access state information to the server so that the server determines a routing path of the resource access request according to the access state information.

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

In the embodiment of the application, in order to realize the real-time monitoring of the resource access state, a set of automatic health check modules are deployed at the terminal equipment side, and the modules can periodically execute the polling access to CDN and OSS resources so as to evaluate the available state of the resources in real time.

Specifically, the terminal device accesses the CDN node and the OSS according to a set period (for example, access is performed once per second) so as to detect the reachability of resources of the CDN and the OSS, if both the CDN node and the OSS are failed in access, the terminal device sends unreachable access state information to the server, at this time, the server determines a routing path of the resource access request as a first routing path, and if at least one of the CDN node and the OSS is successfully accessed, the terminal device sends reachable access state information to the server, at this time, the server determines the routing path of the resource access request as a second routing path.

In order to avoid the influence of unexpected factors on the access state, in an example, the terminal device may further count the number of access failures, and send unreachable access state information to the server when the counted number is greater than a preset threshold.

For example, when the terminal device detects that the front-end static resources in the CDN node and the OSS fail to be accessed for 3 consecutive times, an exception notification that the access state information is unreachable is immediately sent to the nginnx server through an HTTP POST request. And when the terminal equipment detects that the CDN node or the OSS is successfully accessed, immediately sending a normal notification that the access state information is restored to be reachable to the Nginx server through an HTTP POST request.

As shown in fig. 7, a more comprehensive and flexible automatic disaster strategy is implemented for the code logic of the health detection module, the health detection module adopts an efficient monitoring mechanism to evaluate the reachability of CDN and OSS resources in real time, and once it is found that access anomalies exist in both CDN and OSS resources, an alarm is immediately triggered and notified to the nmginx server once the access anomalies are found for more than 3 times, and meanwhile, when the access is restored to normal, the terminal device can access the resources through CDN.

And S603, receiving front-end static resources which are sent by the server and point to CDN nodes under the first routing path, or receiving the downloaded front-end static resources under the second routing path.

The access state information corresponding to the first routing path is reachable, and the access state information corresponding to the second routing path is unreachable.

Referring to fig. 8, a schematic diagram of a detection process of the health detection module is shown, the reachability detection of the CDN good OSS is performed once every 1 second, if the reachability detection is performed, a normal notification is sent to the nglnx server, and if the reachability detection is not performed, an abnormal notification is sent to the nglnx server, so that the nglnx server flexibly selects a routing path of a resource request according to the notification, and reliability and stability of resource access are improved.

Referring to fig. 9, a system architecture diagram for disaster recovery management of front-end resources according to an embodiment of the present application constructs a set of efficient and comprehensive automatic fault-tolerant mechanism through three core technologies including redundant storage of resources, real-time health monitoring and dynamic switching of routing paths. In the front-end project construction process, the resource redundancy storage part packages the front-end static resources into products V1 of which the resource labels point to CDN nodes in the form of URLs, downloads and packages the front-end static resources into products V2 in advance, and deploys the products under different catalogues of the Nginx server respectively. The health detection module part carries out reachability rotation detection of CDN and OSS resources according to a set period and sends detection results to the Nginx server. The routing path dynamic switching part is that the Nginx server executes the Lua script according to the detection result, so that the dynamic path switching of the resource access request in the catalogue where the products V1 and V2 are located is realized, when the CDN and OSS resources are ensured to be abnormal, the resource path is switched to the local catalogue under the condition that the user side does not feel abnormal, the extreme condition that the CDN and the OSS resources are unreachable at the same time is solved, the high availability of the Web application is ensured, the continuity and the stability of the user experience are greatly improved, and a set of undestroyed protective net is constructed for the modern Web system.

The disaster recovery management method for the front-end resources provided by the embodiment of the application fundamentally enhances the fault tolerance capability and the self-recovery capability of the Web system through three core technologies of resource redundancy storage, real-time health monitoring and dynamic switching of routing paths, can monitor access states and respond to resource requests in real time, is beneficial to the dynamic routing path switching technology of which the front end does not feel, and can quickly and transparently transfer service requests to standby resources without any interruption or delay when facing CDN and OSS resource faults, thereby effectively preventing the influence of single-point faults on overall services, ensuring the high availability and stability of the Web system under complex environments such as high load, high concurrency and the like, and providing solid guarantee for continuous operation of services, and greatly improving the smoothness and satisfaction of user experience.

Based on the same technical conception, the embodiment of the application also provides a disaster recovery management device for front-end resources, which can realize the steps of the disaster recovery management method for the front-end resources on the server side and can achieve the same technical effects.

Referring to fig. 10, the disaster recovery management device includes a receiving module 1001, a determining module 1002, and a transmitting module 1003, wherein:

A receiving module 1001, configured to receive a resource access request sent by a terminal device, where the resource access request is used to request a front-end static resource required by displaying a service page;

A determining module 1002, configured to determine a routing path of the resource access request according to access status information sent by the terminal device, where 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;

And a sending module 1003, configured to send the front-end static resource pointed to the CDN node under the first routing path to the terminal device if the access status information is reachable, and send the front-end static resource downloaded under the second routing path to the terminal device if the access status information is not reachable.

Optionally, the sending module 1003 is specifically configured to:

Optionally, the determining module 1002 is specifically configured to:

Based on the same technical conception, the embodiment of the application also provides a disaster recovery management device for front-end resources, which can realize the steps of the disaster recovery management method for the front-end resources on the terminal equipment side and can achieve the same technical effects.

Referring to fig. 11, the disaster recovery management device includes a sending module 1101 and a receiving module 1102, wherein:

A sending module 1101, configured to send a resource access request to a server, and send access status information to the server, so that the server determines a routing path of the resource access request according to the access status information, where the resource access request is used for requesting a front-end static resource required for displaying a service page, and the access status information is used for indicating whether at least one of a content delivery network CDN and an object storage service OSS is reachable;

and a receiving module 1102, configured to receive a front-end static resource that is sent by the server and points to a CDN node under a first routing path, or receive a front-end static resource that is sent by the server and downloaded under a second routing path, where the first routing path corresponds to the access state information and is reachable, and the second routing path corresponds to the access state information and is unreachable.

Optionally, the sending module 1101 is specifically configured to:

accessing the CDN node and the OSS according to a set period;

Optionally, the sending module 1101 is specifically configured to:

Counting the number of access failures;

For convenience of description, the above parts are described as being functionally divided into modules (or units) respectively. Of course, the functions of each module (or unit) may be implemented in the same piece or pieces of software or hardware when implementing the present application.

Having introduced the disaster recovery management method and apparatus for front-end resources according to an exemplary embodiment of the present application, next, an electronic device according to another exemplary embodiment of the present application is described.

Those skilled in the art will appreciate that the various aspects of the application may be implemented as a system, method, or program product. Accordingly, aspects of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, micro-code, etc.) or an embodiment combining hardware and software aspects that may be referred to herein collectively as a "circuit," module "or" system.

The electronic device provided in the embodiment of the present application may be a server or a terminal device, based on the same inventive concept as the above embodiment of the method. In this embodiment, the structure of the electronic device may include a memory 1201, a communication interface 1203, and one or more processors 1202 as shown in fig. 12.

A memory 1201 for storing a computer program for execution by the processor 1202. The memory 1201 may mainly include a storage program area in which an operating system, programs required for running an instant messaging function, and the like are stored, and a storage data area in which various instant messaging information, an operation instruction set, and the like are stored.

The memory 1201 may be a volatile memory (RAM) such as a random-access memory (RAM), the memory 1201 may be a nonvolatile memory (non-volatile memory) such as a read-only memory (rom), a flash memory (flash memory), a hard disk (HARD DISK DRIVE, HDD) or a Solid State Disk (SSD), or the memory 1201 may be any other medium that can be used to carry or store a desired computer program in the form of instructions or data structures and that can be accessed by a computer, but is not limited thereto. The memory 1201 may be a combination of the above memories.

The processor 1202 may include one or more central processing units (central processing unit, CPUs) or digital processing units, or the like. A processor 1202 for implementing the disaster recovery management method for the front-end resource when calling the computer program stored in the memory 1201.

The communication interface 1203 is used to communicate with other network devices.

The specific connection medium between the memory 1201, the communication interface 1203, and the processor 1202 is not limited in the embodiment of the present application. The embodiment of the present application is illustrated in fig. 12 by a bus 1204 between the memory 1201 and the processor 1202, and the bus 1204 is illustrated in fig. 12 by a bold line, and the connection between other components is merely illustrative, and not limited thereto. Bus 1204 may be classified as an address bus, a data bus, a control bus, etc. For ease of description, only one thick line is depicted in fig. 12, but only one bus or one type of bus is not depicted.

The memory 1201 stores a computer storage medium in which computer executable instructions are stored for implementing the disaster recovery management method for front-end resources according to the embodiment of the present application. The processor 1202 is configured to execute the disaster recovery management method for front-end resources as shown in fig. 2 and 6.

In some possible embodiments, aspects of the disaster recovery management method for front-end resources provided by the present application may also be implemented in the form of a program product, which includes a computer program for causing an electronic device to perform the steps in the disaster recovery management method for front-end resources according to the various exemplary embodiments of the present application described above when the program product is run on the electronic device, for example, the electronic device may perform the steps as shown in fig. 2 and fig. 6.

The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of a readable storage medium include an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

The program product of embodiments of the present application may take the form of a portable compact disc read only memory (CD-ROM) and comprise a computer program and may be run on an electronic device. However, the program product of the present application is not limited thereto, and in this document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with a command execution system, apparatus, or device.

The readable signal medium may comprise a data signal propagated in baseband or as part of a carrier wave in which a readable computer program is embodied. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with a command execution system, apparatus, or device.

A computer program embodied on a readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer programs for performing the operations of the present application may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer program may execute entirely on the consumer electronic device, partly on the consumer electronic device, as a stand-alone software package, partly on the consumer electronic device and partly on a remote electronic device or entirely on the remote electronic device or server. In the case of remote electronic devices, the remote electronic device may be connected to the consumer electronic device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external electronic device (e.g., connected through the internet using an internet service provider).

It should be noted that although several units or sub-units of the apparatus are mentioned in the above detailed description, such a division is merely exemplary and not mandatory. Indeed, the features and functions of two or more of the elements described above may be embodied in one element in accordance with embodiments of the present application. Conversely, the features and functions of one unit described above may be further divided into a plurality of units to be embodied.

Furthermore, although the operations of the methods of the present application are depicted in the drawings in a particular order, this is not required or suggested that these operations must be performed in this particular order or that all of the illustrated operations must be performed in order to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step to perform, and/or one step decomposed into multiple steps to perform.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may 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, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may 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, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

It will be apparent to those skilled in the art that various modifications and variations can be made to the present application without departing from the spirit or scope of the application. Thus, it is intended that the present application also include such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.

Claims

1. The disaster recovery management method for the front-end resource is characterized by comprising the following steps:

2. The method of claim 1, wherein the sending the front-end static resource directed to the CDN node under the first routing path to the terminal device comprises:

3. The method of claim 1, wherein the sending the downloaded front-end static resource under the second routing path to the terminal device comprises:

4. A method according to any of claims 1-3, wherein said determining a routing path for said resource access request based on access status information sent by said terminal device comprises:

5. The disaster recovery management method for the front-end resource is characterized by comprising the following steps:

6. The method of claim 5, wherein the sending access status information to the server comprises:

accessing the CDN node and the OSS according to a set period;

7. The method of claim 6, wherein the sending the unreachable access state information to the server comprises:

Counting the number of access failures;

8. A disaster recovery management device for front-end resources, comprising:

9. A disaster recovery management device for front-end resources, comprising:

10. An electronic device, comprising a processor, a memory, and a communication interface, wherein the communication interface, the memory, and the processor are connected by a bus;

the communication interface is used for receiving and transmitting data;

The memory is used for storing computer instructions;

The processor is configured to read the computer instructions in the memory and execute the steps of the method according to any one of claims 1 to 7.