CN115988052A

CN115988052A - Resource request processing method and device

Info

Publication number: CN115988052A
Application number: CN202211557177.2A
Authority: CN
Inventors: 唐薇薇
Original assignee: WeBank Co Ltd
Current assignee: WeBank Co Ltd
Priority date: 2022-12-06
Filing date: 2022-12-06
Publication date: 2023-04-18

Abstract

The application provides a method and a device for processing a resource request, wherein the method comprises the following steps: acquiring a main thread of a client to initiate a process registration request, and calling a registration layer of a target process to perform process registration; acquiring a target domain name list from a main thread, calling a domain name strategy layer of a target process to mark the target domain name list, and storing the marked target domain name list to a data layer of the target process, wherein the target domain name list comprises at least one domain name and a mark for indicating whether the domain name is available; when a main thread initiates a resource request, a disaster recovery layer of a called target process intercepts the resource request, and determines whether a resource request result of the resource request is a request failure according to a target domain name list of a data layer; if the resource request result is that the request fails, re-initiating the resource request according to the target disaster tolerance strategy; the resource request result with successful request is obtained and returned to the main thread, and the execution sequence of the synchronous loading resource can be ensured not to be disturbed by the method, and the disaster tolerance effect is improved.

Description

Resource request processing method and device

Technical Field

The present application relates to the field of financial technology (Fintech), and in particular, to a method and an apparatus for processing a resource request.

Background

With the development of computer technology, more and more technologies are applied in the financial field, the traditional financial industry is gradually changing to financial technology (Fintech), and internet websites are no exception, but due to the requirements of the financial industry on safety and real-time performance, higher requirements are also put forward on the technologies. A Content Delivery Network (CDN) is a set of Network server systems, which can solve the problem of blocking of access to a website to a great extent, improve response time and response speed of the website, and store important resources at a front end on the CDN, so that stability of the CDN in a use process needs to be ensured, and remedial measures need to be taken in time once the CDN has a problem.

Currently, a plurality of spare CDNs are mainly configured, and when a problem is detected in a CDN, another new CDN is directly used for replacement.

However, when the method deals with multiple resource requests, execution sequence is easily disturbed, and when a certain resource request does not respond and a new CDN domain name is replaced, the subsequent resource requests will still continue to be executed, which results in the actual execution sequence of the subsequent resource requests being earlier and the execution sequence of the original resource request being later, which causes the disturbance of the execution sequence of the resource requests.

Disclosure of Invention

The application provides a resource request processing method and device, and aims to solve the problem that when a problem occurs in the existing CDN, the remediation effect is poor.

In a first aspect, the present application provides a method for processing a resource request, which is applied to a client, and the method includes:

acquiring a main thread of the client to initiate a process registration request, and calling a registration layer of a target process to perform process registration;

acquiring a target domain name list from a main thread of the client, calling a domain name strategy layer of a target process of the client to mark the target domain name list, and storing the marked target domain name list to a data layer of the target process, wherein the target domain name list comprises at least one domain name and a mark for indicating whether the domain name is available;

when the main thread initiates a resource request, calling a disaster tolerance layer of the target process to intercept the resource request, and determining whether a resource request result of the resource request is a request failure according to a target domain name list of the data layer;

if the resource request result is that the request fails, re-initiating the resource request according to the target disaster tolerance strategy;

and obtaining a resource request result with a successful request, and returning the resource request result to the main thread.

In one possible design, the reinitiating the resource request according to the target disaster recovery policy includes:

determining whether a target domain name in the resource request is available;

if the target domain name is unavailable, acquiring an available domain name from the target domain name list, and replacing the target domain name with the available domain name;

and initiating the resource request to the available domain name again.

calling a communication layer of the target process to transmit a preset network protocol field to the main thread, wherein the preset network protocol field is used for the main thread to acquire current network data;

determining at least one of a network connection state, a downloading speed and a request response time according to the network data;

determining whether a network problem exists at present according to at least one of the network connection state, the downloading speed and the request response time length;

and if the network problem exists currently, initiating the resource request to the target domain name in the resource request again.

when a resource request is initiated to the available domain name again, if the request fails, an error code when the request fails is obtained, wherein the error code is used for representing whether the client or the server has a fault;

if the client has a fault, initiating a resource request to the target domain name again;

and if the server has a fault, restarting the resource request to the target domain name after replacement.

monitoring the current network state of the client, wherein the network state comprises a connected network and an unconnected network;

and if the network state is not connected with the network, acquiring a request result matched with the resource request from a cache as a request result of successful request, wherein the cache stores the request result returned by the client when the client initiates the resource request each time.

In one possible design, the obtaining the target domain name list includes:

acquiring a preset default domain name list as a target domain name list, wherein the default domain name list comprises at least one domain name and a domain name mark, and the domain name mark is used for representing whether the domain name is available or not;

or the like, or, alternatively,

and acquiring a dynamic domain name list as the target domain name list, wherein the dynamic domain name list is obtained by sequencing according to domain name data of each available domain name, and the domain name data comprises at least one of the availability of the domain name, the response speed of the domain name and the continuous stability rate of the domain name.

In one possible design, the method further includes:

acquiring events to be executed of the main thread, and determining the execution sequence of each event to be executed, wherein the events to be executed at least comprise the update events of the domain name list;

timing is carried out when the main thread executes the time according to the execution sequence, and whether the updating event is executed or not is determined after the timing time exceeds the preset time;

and if the update event is not executed, the main thread is informed to jump to execute the update event according to the execution sequence, and the update event is used for updating the available domain names in the dynamic domain name list according to the domain name data of each available domain name when executed.

In one possible design, the reinitiating the resource request according to the target request policy includes:

determining whether a registration completion notification is received, wherein the registration completion notification is used for representing that a target process in the client completes registration, and the target process is used for re-initiating a resource request according to a target disaster tolerance strategy when the resource request initiated by the client fails;

if the registration completion notification time is not received, intercepting a resource request of the client through a target thread in the client;

and taking a temporary disaster recovery strategy configured for the target thread in advance as the target request strategy, and re-initiating the resource request according to the temporary disaster recovery strategy.

In one possible design, the reinitiating the resource request according to the temporary disaster recovery policy includes:

acquiring the type of the currently requested resource and a domain name for the preset device;

determining a substitution mode of a target domain name in the resource request according to the type of the resource;

and replacing the target domain name with the preset standby domain name according to the replacement mode so as to reinitiate the resource request.

In a second aspect, the present application provides a project data processing apparatus comprising:

the process registration module is used for acquiring a process registration request initiated by a main thread of the client and calling a registration layer of a target process to perform process registration;

the domain name list processing module is used for acquiring a target domain name list from a main thread of the client, calling a domain name strategy layer of a target process of the client to mark the target domain name list, and storing the marked target domain name list to a data layer of the target process, wherein the target domain name list comprises at least one domain name and a mark for indicating whether the domain name is available;

the resource interception module is used for calling the disaster recovery layer of the target process to intercept the resource request when the main thread initiates the resource request, and determining whether the resource request result of the resource request is a request failure according to the target domain name list of the data layer;

the strategy determining module is used for reinitiating the resource request according to the target disaster tolerance strategy if the resource request result is that the request fails;

a result returning module for obtaining the resource request result successfully requested and returning to the main thread

The application provides a method and a device for processing resource requests, wherein when a client initiates a resource request, the resource request initiated by the client is directly intercepted, whether the resource request fails or not is determined, if the resource request fails, the resource request is reinitiated according to a target disaster tolerance strategy until a request result of the successful request is obtained and then returned to the client.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application.

Fig. 1 is a schematic view of a scenario of a resource request according to an embodiment of the present application;

fig. 2 is a schematic flowchart of a method for processing a resource request according to an embodiment of the present application;

fig. 3 is a schematic diagram of an internal architecture of a client according to an embodiment of the present application;

fig. 4 is a schematic diagram illustrating selection of a domain name list provided in an embodiment of the present application;

FIG. 5 is a schematic diagram illustrating execution sequence scheduling according to an embodiment of the present application;

fig. 6A is a schematic structural diagram of a resource hijacking center according to an embodiment of the present application;

FIG. 6B is a schematic diagram of the ajax interceptor execution logic;

FIG. 7 is a schematic diagram of the request execution logic after the overwrite open method and the sending method;

fig. 8 is a schematic flow chart of a temporary disaster recovery policy provided in an embodiment of the present application;

fig. 9 is a schematic structural diagram of a device for processing a resource request according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of a computer device according to an embodiment of the present application.

With the above figures, there are shown specific embodiments of the present application, which will be described in more detail below. The drawings and written description are not intended to limit the scope of the inventive concepts in any manner, but rather to illustrate the concepts of the application by those skilled in the art with reference to specific embodiments.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all the embodiments. All other embodiments, including but not limited to combinations of embodiments, which can be derived by a person skilled in the art from the embodiments disclosed herein without making any inventive step are within the scope of the present application.

The terms "first," "second," "third," "fourth," and the like in the description and in the claims of the present application and in the drawings described above, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are, for example, capable of operation in sequences other than those illustrated or otherwise described herein. Moreover, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

The terms referred to in this application are explained first:

a Content Delivery Network (CDN), a CDN server is a set of Network server systems that includes many specific functional modules. The system comprises 4 main functional modules of distributed storage, load balancing, network request redirection and content management, and the content management and the network traffic management are two most important functions in a CDN server. Accessing the network using a CDN server would re-frame a new network architecture in the internet and enable special network delivery functions to the user's network. By the method, the problem of network access blockage can be solved to a great extent, and the response time and speed of the website are improved.

Hyper Text Markup Language (html) is a Markup Language. The document format on the network can be unified through the labels, and scattered Internet resources are connected into a logic whole. HTML text is descriptive text consisting of HTML commands that can specify words, graphics, animations, sounds, tables, links, etc.

Cascading Style Sheets (CSS) is a computer language used to represent styles in HTML files.

Javascript (js) is a script, a programming language, and is an interpreted scripting language. It can realize complex functions on web pages, content updating, interactive maps, 2D/3D animations, scrolling played videos, and the like.

A packaging tool: packaging is the work of preprocessing, compressing and integrating various files, including property-specific optimization, performing static analysis according to the dependency relationship among modules, and then generating corresponding static resources by the modules according to specified rules.

Static resources: the fixed page at the front end contains HTML, CSS, JS, pictures and the like, and the page can be directly displayed without searching a database and processing programs.

The basic idea of Document Object Model (DOM) is to parse a structured Document (e.g., HTML) into a series of nodes, and then compose a Tree structure (DOM Tree) from these nodes. All nodes and the final tree structure have standard external interfaces so as to achieve the purpose of operating documents by using a programming language (such as adding and deleting contents). DOM does not belong to JavaScript, but operating DOM is the most common task of JavaScript, which is also the language most commonly used for DOM operation.

script tag: for defining client side scripts (such as JavaScript), the script element can contain script statements and can point to an external script file through the "src" attribute. JavaScript is commonly used for image manipulation, form verification, and dynamic content modification.

And (3) Promise: is an object that represents the eventual completion or failure of an asynchronous operation. Since in concurrent programming, an object is needed to proxy unknown results because some computations (or network requests) have not yet finished, the object that proxies the unknown results is called Promise.

At present, in the field of computer technology, in order to improve the response speed of a website and reduce the response time, a Content Delivery Network (CDN) server is generally used, and meanwhile, important resources at the front end of the website are generally stored in the CDN server, so that the stability of the CDN server is very important for the front end, and once the CDN server has a problem, a user cannot enter a website page. Therefore, a corresponding disaster tolerance scheme is usually configured to cope with instability of the CDN servers, specifically, a plurality of standby CDN server domain names are configured, then each CDN server is monitored, when it is monitored that a problem occurs in a certain CDN server, domain name replacement is directly performed, and a domain name of an accessible CDN server is replaced, and if an image resource is accessed, a resource link of a Document Object Model (DOM) node of the image needs to be replaced with a new resource link. However, this disaster recovery mode only exists in the case that the resource is an asynchronous request, in the practical application, one or more Javascript tags may exist in the page, and in the process of executing the browser, because the Javascript tags are loaded synchronously, but the execution of the Javascript has a strict execution sequence, and in the process of loading the plurality of Javascript tags synchronously, if it is monitored that a problem occurs in the server where part of the Javascript tags load the resource, this part of the Javascript tags cannot perform domain name replacement loading in the first time by the CDN, and the rest of the Javascript tags can be loaded normally, so after synchronous loading, this part of the Javascript tags needs to load the requested resource again, which results in disorder of the execution sequence. In addition, in the traditional CDN disaster recovery scheme, retry is mainly performed by using a configuration retry number in the disaster recovery process, and a mode of directly switching a domain name after retry is used as a disaster recovery policy, but the fixed disaster recovery policy is not clever and flexible. And the traditional scheme can only operate on a code level, and can not achieve the purpose even if the domain name is replaced in the weak network and non-network environment, so under the limitation of the weak network and the non-network, the traditional scheme can not tolerate disasters. Finally, the way of obtaining the domain name configuration in the conventional scheme is to use a timer to continuously request the interface by setting a certain time, namely, to poll the request interface, but the disadvantage of the scheme is that once the main thread executes a complex task, the execution time of the main thread is occupied for the configuration of low priority, and the interaction performance of the page is influenced, which is very unpractical.

In order to solve the above problems, the present application provides a disaster recovery scheme for a CDN server, where a tool (e.g., a script code) is implanted in a browser, and when a request is made to a website, the browser parses HTML, in a process of performing parsing, initializes the present application to provide a standby tool, and after the completion of the parsing, monitors and intercepts all resource requests of a page, so that a purpose of intercepting, replacing, or requesting again resources of the CDN can be achieved, and a disaster recovery effect is finally achieved.

The technical solution of the present application will be described in detail below with reference to specific examples. It should be noted that the following specific embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

For example, fig. 1 is a schematic view of a scene of a resource request provided in the embodiment of the present application, as shown in fig. 1, a terminal device 11 may include a computer device, a notebook computer, a tablet computer, and the like, a user may generally access a website through a client (e.g., a browser) in the terminal device 11, taking the client as the browser as an example, and important resources at a front end of the website are generally stored in a server 12 (e.g., a CDN server as an example), when one of the CDN servers has a problem, the user may not enter a browser page, and therefore a plurality of CDN servers need to be set, and when one of the CDN servers has a problem, another CDN server is selected as a substitute, so as to ensure availability of the resources.

Example one

Fig. 2 is a flowchart illustrating a method for processing a resource request according to an embodiment of the present application, where an execution subject of the method may be a client, and a carrier of the client may be the terminal device described above. Illustratively, the client may be a browser. As shown in fig. 2, the method may specifically include the following steps:

step S201, acquiring a process registration request initiated by a main thread of a client, and calling a registration layer of a target process to perform process registration.

In this embodiment, taking a client as an example of a browser, the client may include a main thread and a service work process (i.e., a target process) communicating with the main thread, and exemplarily, fig. 3 is a schematic diagram of an internal architecture of the client provided in the embodiment of the present application, as shown in fig. 3, the main thread is configured with a communication layer, and is mainly used for communicating with the service work process and determining that mutual reception of information is completed. Meanwhile, a communication layer is also configured in the service work process and used for interacting and communicating with the main thread. The main thread executes a service work process registration center in the execution process, a communication layer of the main thread is called in the execution process of the service work process registration center, and the communication layer of the main thread initiates a registration request according to the address of the service work process. After receiving the registration request, the service work process executes the created installation event by the registration layer, creates a buffer (the buffer is mainly used for matching with the buffer of the resource so as to obtain the buffer for resource loading when the subsequent client side has a weak network or no network state), and after the execution of the registration layer of the service work process is completed, waits for the browser to establish an environment until the registration of the service work process is completed, and triggers the activation event created inside the communication layer of the main thread.

The activation event calls an interface of a domain name registration center to obtain a latest domain name list, if the latest recommendation list of the domain name registration center is not pulled, the domain name registration center provides a default list to a communication layer of a main thread, the communication layer of the main thread triggers a communication special line of a service work process and sends the domain name list to the service work process, the communication layer of the service work process receives a protocol which is well agreed and triggers a domain name strategy layer on the left side of a graph after receiving the domain name list, the domain name strategy layer carries out secondary processing on the domain name list, marks whether each domain name fails or not, and then calls a data layer to store the domain name list. The domain name strategy layer is mainly used for judging whether the current domain name is available, and initializing the stock list every time the domain name list is updated so as to obtain the latest and optimal domain name for disaster recovery.

After the domain name policy layer finishes processing, a communication layer using a service work process notifies a registration completion notification event of the communication layer of the main thread, and the registration completion notification event of the communication layer of the main thread triggers an operation of unloading of the resource hijack center. It should be noted that, in this embodiment, when a page enters a browser for the first time, a service work process is not started yet, and cannot intercept all resource requests of the page, so that the interception needs to be implemented by a resource hijack center, and after the service work process is started, the resource hijack center is unloaded.

The method comprises the steps that a communication scheme of a main thread and a Service Work process is deployed, all modules can finish CDN disaster tolerance without influencing a main flow, the Service Work process is not started when a page enters for the first time, all requests of the page cannot be taken over in time, and therefore a user cannot carry out disaster tolerance when the page initially enters and is loaded unsuccessfully.

Step S202, a target domain name list is obtained from a main thread of the client, a domain name strategy layer of a target process of the client is called to mark the target domain name list, the marked target domain name list is stored to a data layer of the target process, and the target domain name list comprises at least one domain name and a mark for indicating whether the domain name is available.

In this embodiment, the target domain name list is the above-mentioned latest domain name list, where if the domain name registry pulls the latest recommended list, the latest domain name list may be the latest recommended list pulled by the domain name registry, and if the domain name registry does not pull the latest recommended list, the latest domain name list is the default list. The default list may be a preconfigured static domain name list, and the latest recommended list pulled by the domain name registry is a dynamic domain name list, and the content of the dynamic domain name list is updated in real time according to domain name data (such as availability, response speed, and stability) of each domain name. Illustratively, when the stability of a domain name decreases, the recommended value of the domain name in the dynamic domain name list decreases. When the available domain name is re-determined, the available domain name is selected to replace the target domain name according to the recommended value.

Step S203, when the main thread initiates a resource request, the disaster tolerance layer of the called target process intercepts the resource request, and determines whether the resource request result of the resource request is a request failure according to the target domain name list of the data layer.

In this embodiment, one or more script tags may exist in a browser page, and when the browser loads the script tags, a resource request is sent to the CDN server to obtain a resource corresponding to the script tag stored on the CDN server.

For example, taking synchronous loading of the script tag a, the script tag B, and the script tag C as an example, if a problem occurs in the CDN server when the script tag B is loaded, the corresponding resource cannot be obtained when the script tag B is loaded, and the corresponding resource is successfully obtained when the script tag a and the script tag C are loaded, and if the script tag B is loaded by replacing the server again, the execution sequence of the CDN may be disturbed (that is, the script tag a, the script tag B, and the script tag C are loaded asynchronously). For this problem, in this embodiment, the resource request initiated by the browser is intercepted, and the request result returned by the CDN server is also intercepted.

In this embodiment, a Service Work process (e.g., an agent) may be implanted in the disaster tolerance layer of the target process of the client, and the agent intercepts the resource request initiated by the client and the request result returned by the CDN server. The broker may broker all resource interaction requests for the page.

Illustratively, if a problem occurs in the CDN server when the script tag B is loaded, at this time, since all the resource requests (that is, the resource request including the script tag a, the resource request including the script tag B, and the resource request including the script tag C) are intercepted by the Service Work process, the resource request does not actually reach the CDN server, and thus the browser cannot know the resource request result, and can only wait until the resource request result is received and then perform subsequent script tag loading.

In this embodiment, the target domain name list includes a plurality of domain names, and each domain name can indicate whether it is available or not by a flag, for example, when a domain name is not available, the flag is set as unavailable, and when a domain name is available, the flag is set as available.

In this embodiment, the intercepted resource request may include a domain name of the CDN server. For example, after intercepting a resource request, a Service Work process implanted in a client may analyze the resource request to obtain a requested CDN server domain name (for example, the CDN server domain name of the resource request is server F1), and in addition, the Service Work process may obtain a target domain name list in real time, where which CDN server domain names have a problem and which CDN server domain names have no problem may be marked in the target domain name list. Through the target domain name list, whether the domain name of the CDN server of the resource request has a problem or not can be determined, and if the domain name of the CDN server of the resource request has the problem, the resource request result can be directly determined to be a request failure.

For example, after intercepting the resource request, the Service Work process may also directly initiate a resource request to the CDN server domain name of the resource request, and if the CDN server domain name is in a problem, an error condition may be fed back to the Service Work process, so that it may also be determined that the resource request result is a request failure. The feedback error condition is intercepted by the Service Work process and cannot be returned to the client, so that the problem that the execution sequence of the script tags is disordered due to the fact that the client loads other script tags and continues to initiate other resource requests after receiving the resource request result with a failed request is avoided.

Step S204, if the resource request result is that the request fails, the resource request is reinitiated according to the target disaster tolerance strategy.

In this embodiment, under different conditions, different target disaster recovery policies are associated, for example, the target disaster recovery policy corresponding to the resource request may be determined according to a result of the resource request to reinitiate the resource request, or the target disaster recovery policy corresponding to the client may be determined according to a network request of the client. For example, if the resource request result indicates that the current CDN server fails, the corresponding target disaster recovery policy is to replace the new CDN server, and then a resource request is initiated to the new CDN server to obtain a resource request result that the request is successful. Wherein, a relationship correspondence table can be established, which comprises which target disaster tolerance strategy is selected to reinitiate the resource request under different conditions.

Step S205, obtain the resource request result successfully requested, and return to the main thread.

In this embodiment, a disaster tolerance layer in a Service Work process includes an agent, the Service Work process is equivalent to an intermediate node between a CDN server and a client, after a resource request is initiated by the client, the agent intercepts the resource request, and if there is no problem with the CDN server of the resource request, the agent forwards the resource request to the CDN server, and the CDN server returns a resource request result that the request is successful to the agent based on the resource request, and forwards the resource request result to the client by the agent; if the CDN server of the resource request has a problem, the agent may initiate the resource request to the new CDN server again, and the new CDN server returns a resource request result that the request is successful to the agent, which forwards the resource request result to the main thread of the client.

According to the method, when the client side initiates the resource request, the resource request initiated by the client side is directly intercepted, whether the resource request fails or not is determined, if the resource request fails, the resource request is reinitiated according to the target disaster tolerance strategy until the request result of the successful request is obtained and then returned to the client side, and therefore the execution sequence of the synchronous loading of the resources can be guaranteed not to be disordered, and the disaster tolerance effect is improved.

Example two

On the basis of the above embodiments, the resource request result is a case of a request failure, which can be divided into a plurality of cases. In this embodiment, taking a case that a resource request result is a request failure due to a problem occurring in the CDN server as an example, after a Service Work process intercepts a resource request, the resource request may be reinitiated through the following steps: determining whether a target domain name in the resource request is available; if the target domain name is unavailable, acquiring an available domain name from a target domain name list, and replacing the target domain name with the available domain name; and re-initiating the resource request to the available domain name.

In this embodiment, the domain name is used for accessing the CDN server, and the CDN servers accessed by different domain names are different, for example, the domain name Y1 corresponds to the CDN server F1, and the domain name Y2 corresponds to the CDN server F2. Illustratively, taking the target domain name in the resource request as Y1 as an example, if the CDN server F1 has a problem, the target domain name Y1 is not available.

In this embodiment, the target domain name list may be a default domain name list configured in advance, or may be a dynamic domain name list updated in real time based on a problem situation of the CDN server. For example, whether the target domain name in the resource request is available may be determined based on the target domain name list, and in particular, if the target domain name in the resource request is not in the target domain name list, the target domain name may be determined to be unavailable.

For example, the available domain names in the target domain name list may be sorted according to priority, for example, if the response speed of the available domain name K1 is fast, the available domain name K1 is ranked earlier, and if the response speed of the available domain name K2 is slow, the available domain name K2 is ranked later. In this embodiment, for example, the available domain name ranked in the top may be selected to replace the target domain name, and the resource may be requested from the corresponding CDN server by replacing the target domain name after replacement.

In this embodiment, with continued reference to fig. 3, a disaster tolerance layer of a service work process creates an agent, the agent mainly functions to intercept a resource request and a response of a CDN server, and the agent acts to send the resource request after intercepting the resource request initiated by a main thread. Specifically, the processing logic of the agent is as follows:

s11, when a main thread initiates a resource request, an agent of a disaster tolerance layer in a target process intercepts the resource request and acts for sending the resource request, a domain name list in a data layer of a service work process is called before sending, whether a target domain name in the current resource request is a CDN domain name or not is judged, then abnormal domain name analysis is carried out, and whether the target domain name is marked as an unavailable state in the domain name list or not is judged. If the domain name is not marked, the interface of the target domain name is continuously requested, if the domain name is marked as the unavailable state, the domain name list is traversed, the first domain name which is not marked as the unavailable state is obtained, the execution layer is called to splice the original domain name, and the latest available domain name is obtained.

S12, after the latest available domain name is obtained, the agent carries out domain name replacement, namely the available domain name replaces the original unavailable target domain name, and then the resource request is sent again. Meanwhile, if the request is failed to be sent, the agent also intercepts the failed request result, can acquire a failure error state code and report a response header to the server for data analysis, marks the available state of the domain name list and stores the state into a data layer, and then calls the scheduling layer to execute a disaster tolerance scheme. By combining the logic processing of the data layer and the execution layer, the problem that all resource requests cannot respond to disaster tolerance at the first time can be solved.

According to the embodiment of the application, domain name replacement is carried out, the domain name which is unavailable in the resource request is replaced by the available domain name in the target domain name list, then the resource request is reinitiated through the available domain name, disaster tolerance of the CDN server can be achieved, it is guaranteed that a user can stably enter a page when a certain CDN server has a problem, and the stability of the front end is improved.

EXAMPLE III

Based on the above description, in this embodiment, when the agent proxy client fails to initiate a request to the CDN server, the agent may also intercept a failed request result, obtain a failure error status code and report a response header to the server for data analysis, and then invoke the scheduling layer to execute a disaster recovery scheme. Wherein, the specific disaster recovery scheme may be: calling a communication layer of a target process to transmit a preset network protocol field to a main thread, wherein the preset network protocol field is used for the main thread to acquire current network data; determining at least one of a network connection state, a downloading speed and a request response time according to the network data; determining whether a network problem exists at present according to at least one of a network connection state, a downloading speed and a request response time length; and if the network problem exists currently, the resource request is initiated to the target domain name in the resource request again.

In this embodiment, the client needs to initiate a resource request to the CDN server through the network. For example, the network data may be used to indicate a current network connection state of the client, and if the current network connection state does not meet a condition (e.g., a disconnection from the network is intercepted, and a network connection signal is weak), it indicates that the CDN server may not actually have a problem, and a resource request failure may be caused by the network state of the client, and at this time, even if a domain name that is newly updated initiates a resource request to another CDN server, a request failure still exists, so that the disaster tolerance scheme at this time is to directly initiate a resource request to a target domain name.

For example, the disaster recovery scheme of this embodiment is described in detail with reference to fig. 3, specifically, when the resource request result is that the request fails, after the disaster recovery scheme is triggered, a scheduling layer of a service work process is executed, and the scheduling layer takes the error code and the error state when the resource request fails last time to analyze, where the specific flow is as follows:

s21, a network layer of the service work process acquires network data of the main thread by using a communication layer, the communication layer of the service work process transmits an agreed network protocol field to the communication layer of the main thread, and the communication layer of the main thread calls a method for acquiring a network state.

S22, in the execution process of the method for acquiring the network state by the main thread, online (online) variables and connection (connection) objects on a window opened in a browser and network loading data on performance (performance) are acquired, and then the information is transmitted to a service work process through a communication layer of the main thread.

S23, when the network layer of the service work obtains the data, the following calculation and analysis are carried out on the result:

s231, analyzing whether the current network state is in a network connection state and the network is 4G/5G/wireless (2G and 3G networks are in a weak network state).

S232, taking down link (downlink) on the connection object to perform calculation analysis: downlink 1024/8= download speed (in kb/s, i.e. how many bytes are transferred per second), if the download speed is less than 200kb/s, the client (for example, a browser) is considered to be in a poor network state (i.e. there is a network problem).

And S233, obtaining a ttfb index according to the network loading data on the performance, wherein the ttfb index is the time length of the page of the browser for receiving the response of the CDN server and can be used for judging the response performance of the CDN server and the network, and if the ttfb index is more than 500ms, the index is considered to be not good.

S234, the scheduling layer of the service work process goes to the network layer to obtain the analysis result of the network data, whether the network problem is found or not is judged through the network layer, and if the network problem is found, the strategy is directly retried instead of directly switching the domain name. If the resource acquisition fails due to network fluctuation, the problem is not the problem of CDN service, and even if the CDN domain name is switched, the optimal effect cannot be achieved, but instead, the current domain name is diagnosed incorrectly.

According to the embodiment of the application, whether the domain name is selected to be switched is determined based on the network state of the client by detecting whether the network of the client has a problem, so that the accurate selection of the disaster recovery scheme can be realized, unnecessary or wrong disaster recovery schemes are prevented from being executed, and the disaster recovery efficiency is improved.

Further, on the basis of the above embodiments, in other embodiments, if the error code at the time of the request failure is obtained and analyzed to find that there is no problem in the network of the client, the following disaster recovery schemes are continuously executed: acquiring an error code according to a request result of the resource request, wherein the error code is used for representing whether the client or the server has a fault; if the client has a fault, initiating a resource request to the target domain name again; and if the server has a fault, restarting the resource request to the target domain name after replacement.

In this embodiment, the scheduling layer classifies error codes when the resource request fails, determines whether the current error state is a client error or a CDN server error according to the category attribution of the error codes, and directly performs domain name switching once it is determined that the current error is a CDN server error, and renews a new CDN server to initiate the resource request. And if the current error is the reason of the client, continuously executing a retry strategy, and avoiding more waste of CDN server resources caused by the reason of the client.

According to the embodiment of the application, whether the error exists in the client or the CDN server is detected through the error code returned in the request result, so that whether the domain name is selected to be switched or not is determined, the accurate selection of the disaster tolerance scheme can be realized, the execution of some unnecessary or wrong disaster tolerance schemes is avoided, and the disaster tolerance efficiency is improved.

Example four

On the basis of the above description, in this embodiment, when a resource request fails, the following disaster recovery policy may also be adopted: monitoring the current network state of the client, wherein the network state comprises a connected network and an unconnected network; and if the network state is not connected with the network, acquiring a request result matched with the resource request from the cache as a request result of successful request, wherein the request result returned by the client when initiating the resource request every time is stored in the cache.

In a traditional CDN disaster recovery scheme, after a client network changes, the client network can only wait for network recovery, and cannot effectively solve the problem that the front end faces, so that a user cannot enter a page. In this embodiment, each time the client initiates a resource request, the resource request is intercepted and sent by the proxy, so that the resource returned from the CDN server is also directly returned to the proxy, and then forwarded to the client by the proxy, so that the proxy can cache the resource returned by the CDN server. When the client is not connected to the network and cannot establish connection with the CDN server, the CDN disaster recovery scheme of this embodiment may be executed, and the resource in the cache that is adapted to the resource request is returned to the client.

For example, continuing to describe in detail the disaster recovery scheme of this embodiment with reference to fig. 3, when the main thread is executed in an early stage, a set of callback method is provided for an online event and an offline event of the browser, and a conversion event is added at the same time, when a network state (network switch, network speed change, download speed change, and the like) of the client changes, the provided callback event and conversion event are triggered, and in the callback event and the conversion event, the network change is provided to the network layer of the service work process by using the communication layer. The logic of a specific disaster recovery scheme follows the following rules:

s31, a register layer of the service work process creates a buffer during installation.

S32, when each resource request passes through the agent of the disaster tolerance layer of the service work process, the content returned by the resource is stored in a buffer created by the registration layer through response interception in the agent;

s33, triggering an offline event: if the network layer monitors an event, the network layer indicates that the current network is suddenly off-line, the network layer modifies the network state of the data layer, once an agent of the disaster-tolerant layer receives an intercepted request, the agent firstly calls whether the network state of the data layer can initiate a resource request, once the state is unavailable, the cached resource is matched through a cache, if the cached resource is matched, the cached resource is directly used and returned to the client, and if the cached resource is not matched, the resource request is continuously executed;

s34, triggering an online event: if the network layer monitors the online event and represents the recovery of the network, the network layer modifies the network state of the data layer and changes the network state into an available state. The agent of the disaster tolerance layer directly requests the network resource without performing the cache matching logic in step S33;

s35, triggering a conversion event: if the network layer monitors the network state, the following calculation rules are carried out to judge whether the network state of the data layer is available: (1) network delay rtt >2 seconds; (2) the download speed is less than 200kb/s; if one of the conditions is satisfied and the condition is unavailable, the network state of the data layer is modified.

According to the method and the device, the network state change of the client is monitored, when the client is not connected with the network, the resource request of the client can be responded based on the resources cached in the cache, so that the problem that the page cannot be displayed when the client is in a weak network or non-network state is solved, and the limitation that the traditional CDN disaster recovery scheme can only wait for network recovery is solved.

EXAMPLE five

On the basis of the foregoing embodiment, in this embodiment, the target domain name list may be a preset default domain name list or a dynamic domain name list, where the default domain name list includes at least one domain name and a domain name tag, the domain name tag is used to represent whether the domain name is available, the dynamic domain name list is obtained by sorting according to domain name data of each available domain name, and the domain name data includes at least one of an availability of the domain name, a response speed of the domain name, and a persistent stability rate of the domain name.

In the traditional CDN disaster recovery scheme, a plurality of domain names are preconfigured, and after disaster recovery is triggered, the preconfigured domain names are used for replacement, which way leads to a failure in knowing which CDN server is in problem specifically because the front end cannot perceive the CDN server, and the optimal selection effect of the domain names cannot be achieved. In this embodiment, referring to fig. 3, the domain name registration center of the main thread stores a set of default domain name lists, when the user enters the page, the domain name registration center of the main thread updates the domain name lists by going to the domain name calculation center in a polling manner, and the domain name calculation center provides a set of optimal domain name calculation manners (for example, determining an optimal domain name according to the availability of the domain name, the response speed of the domain name, and the persistent stability rate of the domain name), so that the domain name that can be accessed by the current user most quickly can be obtained and then stored locally to serve as the dynamic domain name list.

In this embodiment, when triggering the disaster tolerance scheme, if the target domain name in the resource request is found to be unavailable, it may first be found whether there is a dynamic domain name list locally, and if the dynamic domain name list is locally stored, an optimal domain name (for example, a domain name ranked the most top in the dynamic domain name list) may be selected from the dynamic domain name list to replace the target domain name. If no dynamic domain name list exists locally (the dynamic domain name list needs time to calculate and is dynamically updated), the available domain name is searched from the default domain name list to replace the target domain name.

Exemplarily, fig. 4 is a schematic diagram for selecting a domain name list provided in the embodiment of the present application, as shown in fig. 4, the method includes the following steps: step S401, an initialization request configures a central domain name. Step S402, when the resource request fails, a dynamic domain name list is obtained. Step S403, when the dynamic domain name list is not returned, acquiring a default domain name list. Step S404, the obtained default domain name list is returned. And step S405, returning a response, and storing the calculated dynamic domain name list. Step S406, when the resource request fails again, the dynamic domain name list is continuously obtained. Step S407, directly returning the stored dynamic domain name list.

When the first resource request fails, a dynamic domain name list acquisition request is firstly initiated to the domain name calculation center, and if no response is returned by the domain name calculation center, a default domain name list is acquired from the default domain name list storage center. When the next resource request fails, the domain name calculation center already returns the calculated dynamic domain name list and stores the dynamic domain name list in the domain name registration center, and at this time, the dynamic domain name list can be directly obtained from the domain name registration center.

In this embodiment, two interfaces are provided when the client is packaged, and one interface is used for calling a default configuration domain name list, so that when the browser first screen is displayed, if the CDN server has a problem, it is not necessary to request the domain name calculation center to calculate the dynamic domain name list and then perform CDN disaster recovery. The other interface is an interface for acquiring an available domain name list by the domain name calculation center, and after initialization, the time for updating the domain name list is dynamically selected through a series of calculation rules, and the default domain name list or the dynamic domain name list calculated by the domain name calculation center is selected to be used. The default domain name list is all domain names which can be requested, and the dynamic domain name list is the optimal domain name which is obtained by calculating the optimal intelligent ordering of the availability rate, the response rate and the like of the available domain names in the current region by the domain name calculation center and accords with the current user.

According to the method and the device, the static default domain name list and the dynamic domain name list are set, when the domain name needs to be replaced when the CDN server has a problem, various selection modes of the domain name list can be provided, so that the optimal selection of domain name replacement is achieved, and the resource request efficiency is improved.

Illustratively, when the domain name calculation center calculates the dynamic domain name list, the domain name calculation center may perform calculation according to domain name requirements, and sort the domain names after obtaining the final data of each domain name, so as to obtain the dynamic domain name list finally. The factors influencing domain name sorting mainly include the following: 1. availability, 2, response speed, 3, continuous stability rate. And obtaining a recommended value according to the weight influenced by each factor, and sequencing through the recommended values. Illustratively, the basic data of the recommended value is calculated according to the request data in the current area of the user, and the formula is as follows:

the recommended value = the number of successful requests for resources within three minutes in the current region/the total number of requests for resources within three minutes in the current region × (available rate weight k + (longest response duration in region-current response duration in region)/(longest response duration in region-shortest response duration in region) × (response speed weight s + (number of successful requests within one month in region/total number of requests within one month in region) ×) the weight of sustained and stable rate weight w.

In the above formula, the available rate weight k, the response speed weight s, and the persistent stability rate weight w may be manually configured according to different regions, different items, and different situations.

Since the dynamic domain name list is mainly to ensure high availability and secondly performance, the values of the available rate weight k/response speed weight s/persistent rate weight w are 0.7/0.1/0.2, respectively, without manually adjusting the weights. The higher the availability in a short time, the more representative the current service is available, and the domain name with higher selectivity is selected on the basis. Illustratively, assume that under a certain region, the data for three domain names is as follows.

	Domain name A	Domain name B	Domain name C
				Number of success requests in three minutes	90	70	50
Total number of requests in three minutes	100	100	100
				Current response time duration (ms)	200	100	30
The longest response time (ms) in the region	500	500	500
				Shortest response time (ms) in zone	50	50	50
Number of successful requests within one month	800	850	900
				Total number of requests in one month	1000	1000	1000

The recommended value of domain name a is:

90/100*0.7+(500-200)/(500-50)*0.1+800/1000*0.2＝0.8566666667

the recommended value of domain name B is:

70/100*0.7+(500-100)/(500-50)*0.1+850/1000*0.2＝0.5788888889

the recommended value of domain name C is:

50/100*0.7+(500-30)/(500-50)*0.1+900/1000*0.2＝0.6344444444

the final obtained domain name recommendation list is ordered as: domain name a > domain name C > domain name B.

Further, on the basis of the fifth embodiment, in other embodiments, the domain name in the dynamic domain name list may be updated in real time, specifically, events to be executed of the client may be obtained, an execution sequence of each event to be executed is determined, and the events to be executed at least include an update event of the domain name list; timing when the client executes the time according to the execution sequence, and determining whether an update event is executed or not after the timing time exceeds the preset time; and if the update event is not executed, skipping to execute the update event according to the execution sequence, wherein the update event is used for updating the available domain names in the dynamic domain name list according to the domain name data of each available domain name when being executed.

In the conventional scheme, a mode of acquiring domain name configuration is to use a timer to continuously request an interface, namely a polling request interface, by setting a certain time, when a main thread executes a complex task, the mode can greatly occupy the execution time of the main thread, which results in the reduction of the interaction performance of a page. In this embodiment, when performing dynamic domain name list updating, the domain name registry determines, based on the priority and the scheduling mode of setting timeout time, the time for performing dynamic domain name list updating according to the event cycle of the browser, so as to achieve the effect of optimal task scheduling. The hierarchical structure and the function of the domain name registration center are divided as follows: and (3) treatment layer: and the execution of some key logics ensures the normal and good operation of the page flow. And (3) a data layer: and storing data required by each link. A communication layer: an internal and external communication method is provided. Interface layer: an interface for providing external calls.

For example, an executor can be abstracted to perform dynamic domain name list updating alone, a set of recursive logic is implemented inside the executor, and when the browser receives an input event, a click event, a slide event, the executor performs an event, page rendering and other operations, the priority of the execution is performed according to an event cycle rule and an event schedule. Fig. 5 is a schematic diagram illustrating scheduling of an execution sequence according to an embodiment of the present application, where as shown in fig. 5, under a normal condition, events to be executed by a main thread include an input event, a click event, a slide event, an actuator, and a page rendering event, and in this embodiment, the execution sequence of each event is scheduled by a scheduling manner based on priority and a set timeout time and in combination with an event cycle of a browser, so as to determine a time at which a dynamic domain name list update can be executed, and finally achieve an optimal task scheduling effect. The specific process of event task scheduling is as follows:

s51, generating an id for the actuator needing to be operated at the current stage in the service work process deployment stage, binding the id and the actuator, and implanting the actuator into the callback object.

S52, setting a 5-minute timer as an overtime processing strategy for the actuator of the current id, wherein once the timer is overtime, the fact that the actuator is not triggered to update the dynamic domain name list in the period of time means that the timer is overtime, in order to guarantee the accuracy of data, an overtime strategy is set, if the timer is not overtime, S53 is executed, and if the timer is overtime, S54 is executed.

S53, judging whether the current main thread has an execution event, wherein the execution event comprises but is not limited to interaction such as input, clicking, sliding and the like, and also comprises whether a browser sends a request, whether rendering is performed and the like. When the other events of page drawing are completed, the callback object, namely the executor, is executed. The execution logic of the executor is as follows:

and S531, judging whether the id of the current executor is unbound, if not, continuing to run downwards, and if so, representing that the execution is performed and not continuing to execute.

S532, calling a domain name calculation center, and carrying out domain name calculation and recommendation algorithm sequencing by the domain name calculation center according to relevant factors to obtain an optimal domain name recommendation list.

And S533, transmitting the optimal domain name recommendation list to a data layer for storage, and then transmitting the optimal domain name recommendation list to a service work process for domain name updating.

And S534, unbinding the id of the current actuator from the actuator.

S535, the final executor invokes a 5-second timer, and repeats the above steps after 5 seconds, starting from S51, and continues the next scheduling.

And S54, acquiring the id of the actuator needing to be operated at present after timeout, and then manually calling the actuator with the current id to trigger the execution logic of the actuator (namely, turning to S53).

According to the method and the device for scheduling the events, the execution sequence of the events to be executed is scheduled by combining the event cycle of the browser through a scheduling mode based on the priority and the set timeout time, the updating time of the dynamic domain name list is determined, the optimal task scheduling effect can be achieved, the continuous request interfaces are avoided, the execution time of a main thread is occupied, and the page interaction performance is improved.

EXAMPLE six

In this embodiment, a Service Work process needs to be registered in a client (e.g., a browser), and cannot intercept a resource request temporarily before registration is completed. The method specifically comprises the following steps: determining whether a registration completion notification is received, wherein the registration completion notification is used for representing that a target process completes registration, and the target process is used for re-initiating a resource request according to a target disaster tolerance strategy when the resource request initiated by a client fails; if the registration completion notification time is not received, intercepting a resource request of the client through a resource interception center in the main thread; and taking a temporary disaster recovery strategy configured in advance for the main thread as a target request strategy, and re-initiating the resource request according to the temporary disaster recovery strategy.

With continued reference to fig. 3, the resource hijack center mainly acts on a stage before the service work process is successfully registered, and once the service work process is successfully registered, the resource hijack center is uninstalled. The resource hijack center is registered at the same time as the process registration center of the main thread, and the main thread can call the resource hijack center and the domain name registration center after executing the process registration center (see above for the call of the domain name registration center). The main function of the registration process of the resource hijack center is to sense the request failure condition of all resources of a page, and to perform temporary disaster recovery processing on the resources according to the request failure condition.

At present, resource failure is mainly captured by a browser fault listening event, but the method can only capture a scheme of loading a mainstream (using jsonp loading) resource, but ignores a few resources loaded by using an ajax mode. Further, in some embodiment modes, in order to monitor the loading failure condition of all resources, the resource hijacking center is provided with a hijacking layer.

Specifically, fig. 6A is a schematic structural diagram of the resource hijacking center provided in the embodiment of the present application, and as shown in fig. 6A, the hijacking layer is divided into a first part And a second part, the first part is a JSON with Padding (JSON with Padding) part, and the second part is an Asynchronous JavaScript And XML (Asynchronous JavaScript And XML And HTML, ajax) part.

jsonp moiety: and (3) creating a capture event of the window object by using the event listener, triggering the capture event once the browser fails to use the resource loaded by the tag, and calling the public service of jsonnp by using the capture event. In the embodiment, failed monitoring methods of all resource types are extracted to be a public service, and in the process of monitoring and capturing error reports, because all error report methods of a page are monitored, such as syntax errors, type errors, range errors, reference errors and the like, the embodiment needs to find the tag type of the DOM node through data returned by a browser event, and then calls a data filtering method of a processing layer to perform matching screening and removing on the error reports which do not belong to the resource loading error type.

Part ajax: in the process that the traditional business uses the ajax request, a set of calling modes are packaged, interception processing is carried out in a mode similar to a transaction mechanism, and in order to realize a non-intrusive hijacking mode, the effects of monitoring and disaster recovery cannot be achieved by modifying a calling chain in a source code, so that an interceptor is set for an XMLHttpRequest object of the ajax. The role of the interceptor is several: (1) intercepting the request of the abnormal CDN resources of the server in advance, and replacing the request with a domain name capable of requesting; (2) and identifying resource abnormality, and collecting error codes and request id for abnormality analysis after hijacking fails. Among them, the XMLHttpRequest object is a built-in browser object that allows hypertext Transfer Protocol (HTTP) requests to be sent using JavaScript. Exemplarily, fig. 6B is a schematic diagram of an ajax interceptor executing logic, as shown in fig. 6B, when a client initiates a resource request, and a domain name of the request corresponds to the CDN server F1, the ajax interceptor intercepts the resource request and analyzes the domain name, and if it is determined that the CDN server F1 has a problem, directly initiates a resource request to a next CDN server F2, intercepts a resource returned by the CDN server F2, and transmits the resource to the client.

In this embodiment, an opening method and a sending method of an XMLHttpRequest (that is, an open function method and a send function method of an XMLHttpRequest object) are rewritten, the rewritten opening method is marked as newOpen, the sending method is marked as newSend, and then an original method for opening/sending a request is executed by changing a context of a function runtime, so that the original method is not polluted. Fig. 7 is a schematic diagram of a request execution logic after the method for opening by rewriting and the method for sending are exemplarily shown, as shown in fig. 7, when a page resource receives a request, parameters such as a request address can be obtained from newOpen, and it is assumed that a current request domain name is a CDN service provider F1; newOpen calls a data filtering method of a resource hijacking center processing layer to ensure that the current request is a static resource request and not a request of other front-end and back-end interaction. And the request parameters are transmitted to a processing layer, and the processing layer can judge whether the request is a proxiable request through three layers: (1) an address suffix of a Uniform Resource Locator (URL), matching a suffix of a target static Resource using a regular pattern; (2) judging whether the request method of the current request is an acquisition (get) method; (3) and calling an interface of a domain name registration center, acquiring all domain name lists, judging the domain name of the current URL, and judging whether the domain name is the domain name corresponding to the CDN server. The data filtering method returns a Boolean value, if the Boolean value is equal to true, the agent can be carried out, otherwise, if the Boolean value is equal to false, the agent directly requests, and does not carry out interception processing. After data filtering, newOpen will continue to call the communication interface of the domain name registration center of the processing layer, obtain the current domain name list, and determine whether the current domain name (CDN server F1) is marked as an unavailable state in the domain name list. If the domain name is not marked, continuing to request an interface of a CDN service provider F1, if the domain name is marked, representing that the CDN service of the current CDN server F1 has a problem, traversing a domain name list, acquiring a first unmarked available domain name (such as a CDN server F2), splicing the original domain name, calling an open function method of an XMLHttpRequest object, and introducing the modified domain name and parameters; after the newOpen call is completed, a rewritten newSend method is triggered, a state preparation change event is added to the constructor XMLHttpRequest in the newSend method, and the added state preparation change event is called to perform exception identification once the requested state changes: judging whether the request state is completed, detecting whether the network state code is normal when the request state is completed, and judging that the network state code is abnormal when the state code is greater than or equal to 400. When the state code is in an abnormal state, the interceptor marks the current abnormal domain name (marked as unavailable) to a calling interface of a domain name registration center of a calling processing layer. At this time, because the service work process is not ready, once the exception is confirmed, the method of the disaster recovery calling layer is called to carry out the temporary scheme of the resource disaster recovery, and the calling layer transmits the data to the resource loading center to execute the temporary disaster recovery strategy.

Further, on the basis of the sixth embodiment, in another embodiment, when the resource loading center executes the temporary disaster recovery policy, the method may specifically include the following steps: acquiring the type of a current requested resource and a domain name for a preset device; determining a substitution mode of a target domain name in the resource request according to the type of the resource; and replacing the target domain name with a preset standby domain name according to the replacement mode so as to reinitiate the resource request.

In this embodiment, with reference to fig. 3, when the resource loading center is called, the current resource type is determined first, and different types of resources (e.g., javascript resources, picture resources, and Cascading Style Sheets (CSSs)) are classified.

According to different types of resources, corresponding replacement modes are different, exemplarily, taking the current resource as a CSS resource as an example, at this time, a standby domain name can be acquired from a domain name registry, then, an attribute of an old DOM node of the CSS resource is acquired, a new DOM node is created at the same time, the standby domain name is replaced, then, the new DOM node is inserted into the page and the old DOM node of the CSS resource is removed, and then, the page is continuously executed to reinitiate the resource request.

Specifically, when the resource is of a css type, the corresponding processing measures are as follows: the method includes the steps of obtaining a dom node through a traversing browser, taking all cs resource labels, traversing all dom nodes taken through the labels, locating a specified dom node through comparing error resource links, then creating a new dom node, transferring attributes on the old dom node to the new dom node, placing the new dom node behind the old dom node (target. Apppendchild), and removing the old dom node.

For example, if the current resource is a javascript resource, the standby domain name may be obtained from the domain name registry, and then the attribute of the old DOM node of the javascript resource may be obtained. And realizing disaster tolerance processing of the javascript resource based on the attribute of the old DOM node and the standby domain name. Specifically, according to whether the javascript resource is asynchronously loaded or synchronously loaded, two situations can be specifically distinguished: in the first case, when the javascript resource is asynchronously loaded, a new DOM node of the javascript resource is created, the attribute of the old DOM node of the javascript resource is transplanted to the created new DOM node, a new domain name (namely a preset domain name) is replaced, and then the new DOM node is inserted into the page, and meanwhile, the original error-reported DOM node is deleted, and then the page is continuously executed to reinitiate the resource request. In the second case: and acquiring the attribute of the old DOM node of the javascript resource, splicing a new script tag based on a new domain name (namely a domain name for preset equipment) and the original attribute, synchronously writing the generated new script tag code into the html text, deleting the originally reported DOM node, and continuously executing the page to reinitiate the resource request.

Specifically, when the resource is of the js type, the corresponding processing measures are as follows: 1. and if the current resource is the js resource, acquiring the DOM node of the current resource and taking the DOM nodes of all the script tags of the currently executed page. And traverse all DOM nodes. And comparing the URL reported in error with the src of each DOM node through an error event, and if the comparison is successful, representing that the DOM node is a js resource loaded by a script tag in the page. Based on the premise of successful comparison, after the current DOM node is taken, whether an asynchronous attribute (async) of the attribute of the current DOM node exists or not is judged, if yes, the step a is executed, the step b is not executed, if the async attribute exists, the current js script is asynchronously loaded, if the script with the asynchronous attribute (async) is executed, the execution time of the script with the asynchronous attribute (async) is uncertain, the js script has strict requirements on the execution sequence, the loading of synchronous resources (no asynchronous attribute exists), which is possibly depended on back and forth, the failure of the former resource can influence the execution of the latter resource, and scripts with different loading sequences need to be processed differently)

Step a: a new DOM node is created by means of creating script nodes asynchronously (step explains: the execution sequence of the nodes inserted by means of this method cannot be controlled, and since the sequence is originally asynchronous loading and is not fixed, there is no influence even if the original sequence is not maintained). And (3) transplanting the attribute of the current error-reported DOM node to a newly created node, replacing a new domain name, inserting the new domain name into the page, and deleting the old DOM node by using a remove method.

Step b: the method comprises the steps of obtaining original node attributes and links, replacing original resource links, adding the original attributes, finally splicing script tag codes, and synchronously writing the generated script tag codes into html texts (document. Write is used here: the codes implanted by using the synchronous mode are different from the mode of asynchronously creating (createlementscript) scripts, the execution of the following scripts can be blocked, and the following codes can be continuously executed after the current resource is loaded and executed. And deleting the old dom node by using a remove method.

For example, if the current resource is a picture resource, the standby domain name may be obtained from the domain name registry at this time, then the error reporting position is used to determine the DOM node of the current error reporting picture resource, the src of the DOM node is replaced by a new domain name (i.e., the standby domain name), and then the page continues to be executed to reinitiate the resource request.

Specifically, when the resource is a picture type, the corresponding processing measures are as follows: and replacing the src of the current resource with a new standby domain name, setting a resource attribute (setAttribute), and updating the random attribute to reload the picture.

Exemplarily, fig. 8 is a schematic flow chart of a temporary disaster recovery policy provided in an embodiment of the present application, and as shown in fig. 8, the method includes the following steps: step S800, judging the current resource type. In step S810, the current resource is a cascading style sheet. Step S811, a standby domain name is acquired from the domain name registry. In step S812, the attribute of the old node is acquired. Step S813, a new text object model node is created, replacing the domain name. Step S814, insert the text object model node into the page. Step S815, the old node is removed. In step S820, the current resource is a script resource. In step S821, the standby domain name is acquired from the domain name registry. In step S822, the attribute of the old node is acquired. In step S823, it is determined whether the resource is a synchronous resource or has an asynchronous attribute flag. Step S824, copying the attribute of the old node, matching the new domain name, creating a new node by using an asynchronous script node creating mode, and inserting the new node into the page. Step S825, spell the old node attribute and the new domain name into a string, and create a new node by means of creating a script node synchronously, and insert the new node into the page. In step S826, the old node is removed. In step S830, the current resource is a picture resource. Step S831, acquires a standby domain name from the domain name registry. In step S832, the standby domain name is obtained from the domain name registry. And step S833, taking the current error-reported document object model node through the error-reported position. Step S834, replacing the src of the error-reported node with a new domain name.

In summary, the Service Work process is deployed in the early stage, so that the problem of data disorder caused by communication between the Service Work process and the main thread can be solved, and the problem of processing data synchronization between the resource hijack center and the domain name registration center based on asynchronous interaction of the main thread and the Service Work process in the early stage is solved. Meanwhile, the problem of disaster tolerance and leaving caused by the fact that the service work is not connected with the managed page can be solved through the resource hijack center in the main thread, the problem that the service work process cannot carry out disaster tolerance on the resources of the CDN before initialization is solved, and finally domain name recommendation logic can be optimized through the domain name registration center in the main thread, so that the optimal domain name can be taken to carry out disaster tolerance processing at the first time in the resource hijack center and the disaster tolerance center. And an intelligent domain name updating strategy is used for solving the time difference problem of the dynamic domain name and the static domain name and the performance problem caused by frequent updating of the dynamic domain name.

The following are embodiments of the apparatus of the present application that may be used to perform embodiments of the method of the present application. For details which are not disclosed in the embodiments of the apparatus of the present application, reference is made to the embodiments of the method of the present application.

Fig. 9 is a schematic structural diagram of a processing apparatus for a resource request according to an embodiment of the present application, where the processing apparatus may be located on a client (e.g., a web browser), and as shown in fig. 9, the processing apparatus 900 for a resource request includes a process registration module 910, a domain name list processing module 920, a resource interception module 930, a policy determination module 940, and a result returning module 950. The process registration module 910 is configured to obtain a process registration request initiated by a main thread of a client, and invoke a registration layer of a target process to perform process registration. The domain name list processing module 920 is configured to obtain a target domain name list from a main thread of the client, call a domain name policy layer of a target process of the client to mark the target domain name list, and store the marked target domain name list to a data layer of the target process, where the target domain name list includes at least one domain name and a mark for indicating whether the domain name is available. The resource intercepting module 930 is configured to intercept, when the main thread initiates a resource request, the resource request by the disaster tolerance layer of the called target process, and determine whether a resource request result of the resource request is a request failure according to the target domain name list of the data layer. The policy determining module 940 is configured to reinitiate the resource request according to the target disaster recovery policy if the resource request result is a request failure. The result returning module 950 is configured to obtain a resource request result that the request is successful, and return the resource request result to the main thread.

Optionally, the policy determining module may be specifically configured to: determining whether a target domain name in the resource request is available; if the target domain name is unavailable, acquiring the available domain name from the target domain name list, and replacing the target domain name with the available domain name; and re-initiating the resource request to the available domain name.

Optionally, the policy determining module may be specifically configured to: calling a communication layer of a target process to transmit a preset network protocol field to a main thread, wherein the preset network protocol field is used for the main thread to acquire current network data; determining at least one of a network connection state, a downloading speed and a request response time according to the network data; determining whether a network problem exists at present according to at least one of a network connection state, a downloading speed and a request response time length; and if the network problem exists at present, the resource request is initiated to the target domain name in the resource request again.

Optionally, the policy determining module may be specifically configured to: when a resource request is sent to the available domain name again, if the request fails, an error code when the request fails is obtained, wherein the error code is used for representing whether the client or the server has a fault; if the client has a fault, a resource request is initiated to the target domain name again; and if the server has a fault, re-initiating the resource request to the target domain name after replacement.

Optionally, the policy determining module may be specifically configured to: monitoring the current network state of the client, wherein the network state comprises a connected network and an unconnected network; and if the network state is not connected with the network, acquiring a request result matched with the resource request from the cache as a request result of successful request, wherein the request result returned by the client when the client initiates the resource request each time is stored in the cache.

Optionally, the policy determining module may be specifically configured to: acquiring a preset default domain name list as a target domain name list, wherein the default domain name list comprises at least one domain name and a domain name mark, and the domain name mark is used for representing whether the domain name is available or not; or, acquiring a dynamic domain name list as a target domain name list, wherein the dynamic domain name list is obtained by sequencing according to domain name data of each available domain name, and the domain name data comprises at least one of the availability of the domain name, the response speed of the domain name and the continuous stability rate of the domain name.

Optionally, the system further includes a domain name updating module, configured to obtain events to be executed of the main thread, and determine an execution order of each event to be executed, where the events to be executed at least include an update event of the domain name list; timing when the main thread executes the time according to the execution sequence, and determining whether an update event is executed or not after the timing time exceeds the preset time; and if the update event is not executed, the main thread is informed to jump to execute the update event according to the execution sequence, and the update event is used for updating the available domain names in the dynamic domain name list according to the domain name data of all the available domain names when being executed.

Optionally, the policy determining module may be specifically configured to: determining whether a registration completion notification is received, wherein the registration completion notification is used for representing that the target process completes registration, and the target process is used for re-initiating the resource request according to the target disaster tolerance strategy when the resource request initiated by the main thread fails; if the registration completion notification time is not received, intercepting a resource request of the client through a resource interception center in the main thread; and taking a temporary disaster recovery strategy configured for the main thread in advance as a target request strategy, and re-initiating a resource request according to the temporary disaster recovery strategy.

Optionally, the policy determining module may be specifically configured to: acquiring the type of the currently requested resource and a domain name for the preset device; determining a substitution mode of a target domain name in the resource request according to the type of the resource; and replacing the target domain name with a preset standby domain name according to the replacement mode so as to reinitiate the resource request.

The apparatus provided in the embodiment of the present application may be used to execute the method in the above embodiments, and the implementation principle and the technical effect are similar, which are not described herein again.

It should be noted that the division of each module of the above apparatus is only a logical division, and all or part of the actual implementation may be integrated into one physical entity or may be physically separated. And these modules can all be implemented in the form of software invoked by a processing element; or may be implemented entirely in hardware; and part of the modules can be realized in the form of calling software by the processing element, and part of the modules can be realized in the form of hardware. For example, the request determining module may be a processing element separately set up, or may be implemented by being integrated into a chip of the apparatus, or may be stored in a memory of the apparatus in the form of program code, and a processing element of the apparatus calls and executes the function of the request determining module. The other modules are implemented similarly. In addition, all or part of the modules can be integrated together or can be independently realized. The processing element here may be an integrated circuit with signal processing capabilities. In implementation, each step of the above method or each module above may be implemented by an integrated logic circuit of hardware in a processor element or an instruction in the form of software.

Fig. 10 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 10, the computer apparatus 1000 includes: at least one processor 1001, memory 1002, bus 1003, and communication interface 1004. Wherein: the processor 1001, the communication interface 1004, and the memory 1002 communicate with each other via the bus 1003. A communication interface 1004 for communicating with other devices. The communication interface 1004 includes a communication interface for data transmission, a display interface or an operation interface for human-computer interaction, and the like. The processor 1001 is configured to execute computer instructions, and may specifically execute relevant steps in the methods described in the foregoing embodiments. The processor may be a central processing unit, or an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits configured to implement an embodiment of the present invention. The electronic device comprises one or more processors, which can be the same type of processor, such as one or more CPUs; or may be different types of processors such as one or more CPUs and one or more ASICs. The memory is used for storing computer instructions. The memory may comprise high speed RAM memory and may also include non-volatile memory, such as at least one disk memory.

The present embodiment also provides a readable storage medium, in which computer instructions are stored, and when at least one processor of the computer device executes the computer instructions, the computer device executes the processing method of the resource request provided by the above various embodiments.

The present embodiments also provide a program product comprising computer instructions stored in a readable storage medium. The computer instructions can be read from a readable storage medium by at least one processor of the computer device, and the computer instructions executed by the at least one processor cause the computer device to implement the method for processing resource requests provided by the various embodiments described above.

In the present application, "at least one" means one or more, "a plurality" means two or more. "and/or" describes the association relationship of the associated objects, meaning that there may be three relationships, e.g., a and/or B, which may mean: a alone, A and B together, and B alone, wherein A and B may be singular or plural. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship; in the formula, the character "/" indicates that the preceding and succeeding related objects are in a relationship of "division". "at least one of the following" or similar expressions refer to any combination of these items, including any combination of the singular or plural items. For example, at least one (one) of a, b, or c, may represent: a, b, c, a-b, a-c, b-c, or a-b-c, wherein a, b, c may be single or multiple.

It is to be understood that the various numerical references referred to in the embodiments of the present application are merely for convenience of description and distinction and are not intended to limit the scope of the embodiments of the present application. In the embodiment of the present application, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiment of the present application.

Finally, it should be noted that: the above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for processing a resource request, applied to a client, includes:

2. The method of claim 1, wherein the reinitiating the resource request according to the target disaster recovery policy comprises:

determining whether a target domain name in the resource request is available;

and re-initiating the resource request to the available domain name.

3. The method of claim 1, wherein the reinitiating the resource request according to the target disaster recovery policy comprises:

and if the network problem exists at present, the resource request is initiated to the target domain name in the resource request again.

4. The method of claim 2, wherein the reinitiating the resource request according to the target disaster recovery policy comprises:

if the client has a fault, a resource request is initiated to the target domain name again;

and if the server has a fault, re-initiating a resource request to the target domain name after replacement.

5. The method according to claim 1, wherein said reinitiating the resource request according to the target disaster recovery policy comprises:

6. The method of claim 2, wherein obtaining a list of target domain names comprises:

acquiring a preset default domain name list from the main thread to serve as a target domain name list, wherein the default domain name list comprises at least one domain name and a domain name mark, and the domain name mark is used for representing whether the domain name is available or not;

or the like, or, alternatively,

and acquiring a dynamic domain name list as the target domain name list from the main thread, wherein the dynamic domain name list is obtained by sequencing according to domain name data of each available domain name, and the domain name data comprises at least one of the availability of the domain name, the response speed of the domain name and the continuous stability rate of the domain name.

7. The method of claim 6, further comprising:

and if the update event is not executed, the main thread is informed to jump to execute the update event according to the execution sequence, and the update event is used for updating the available domain names in the dynamic domain name list according to the domain name data of each available domain name when being executed.

8. The method of any of claims 1-7, wherein the reinitiating the resource request according to the target request policy comprises:

determining whether a registration completion notification is received, wherein the registration completion notification is used for representing that the target process completes registration, and the target process is used for re-initiating the resource request according to a target disaster recovery strategy when the resource request initiated by the main thread fails;

if the registration completion notification time is not received, intercepting a resource request of the client through a resource interception center in the main thread;

and taking a temporary disaster recovery strategy configured for the main thread in advance as the target request strategy, and re-initiating a resource request according to the temporary disaster recovery strategy.

9. The method according to claim 8, wherein said reinitiating the resource request according to the temporary disaster recovery policy comprises:

10. An apparatus for processing resource requests, comprising:

the process registration module is used for acquiring a process registration request initiated by a main thread of a client and calling a registration layer of a target process to perform process registration;

the strategy determining module is used for re-initiating the resource request according to the target disaster tolerance strategy if the resource request result is that the request fails;

and the result returning module is used for obtaining the resource request result with successful request and returning the resource request result to the main thread.