Method and apparatus for processing resource requests

Abstract

The present application provides a method and apparatus for processing resource requests. The method includes: obtaining a process registration request initiated by the main thread of a client, and calling the registration layer of a target process to perform process registration; obtaining a target domain name list from the main thread, calling the domain name policy layer of the target process to mark the target domain name list, and storing the marked target domain name list in the 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; when a resource request is initiated by the main thread, intercepting the resource request by the disaster recovery layer of the target process called, and determining whether the resource request result of the resource request is a request failure according to the target domain name list in the data layer; if the resource request result is a request failure, re-initiate the resource request according to a target disaster recovery policy; obtaining the resource request result of a successful request and returning it to the main thread. This way can ensure that the execution order of synchronously loading resources is not disrupted and improve the disaster recovery effect.

Description

Technical Field

[0001] This application relates to the field of financial technology (Fintech), and particularly to a method and device for processing resource requests. Background Art

[0002] With the development of computer technology, more and more technologies are applied in the financial field. The traditional financial industry is gradually transforming into financial technology (Fintech), and Internet websites are no exception. However, due to the security and real-time requirements of the financial industry, higher requirements are also put forward for technologies. A content delivery network (CDN) is a set of network server systems, which can largely solve the problem of website access congestion, improve the response time and speed of websites, and important resources at the front end are usually stored on the CDN. Therefore, it is necessary to ensure the stability of the CDN during use. Once a problem occurs with the CDN, remedial measures need to be taken in a timely manner.

[0003] Currently, mainly multiple backup CDNs are configured. When it is detected that a certain CDN has a problem, a new CDN is directly used for replacement.

[0004] However, this method is prone to causing disorder in the execution order when dealing with multiple resource requests. When a certain resource request has no response and the CDN domain name is replaced with a new one, subsequent resource requests will still continue to execute. As a result, the actual execution order of subsequent resource requests is advanced, while the execution order of the original resource request is postponed, causing disorder in the execution order of resource requests. Summary of the Invention

[0005] This application provides a method and device for processing resource requests to solve the problem of poor remedial effect when a problem occurs with the current CDN.

[0006] In a first aspect, this application provides a method for processing resource requests, which is applied to a client. The method includes:

[0007] Obtain a process registration request initiated by the main thread of the client, and call the registration layer of the target process to perform process registration;

[0008] Obtain a target domain name list from the main thread of the client, call the domain name policy layer of the target process of the client to mark the target domain name list, and store the marked target domain name list in the data layer of the target process. The target domain name list includes at least one domain name and a mark indicating whether the domain name is available;

[0009] When a resource request is initiated in the main thread, the disaster recovery layer of the target process is called to intercept the resource request, and it is determined whether the resource request result of the resource request is a request failure according to the target domain name list in the data layer;

[0010] If the resource request result is a request failure, a resource request is re-initiated according to the target disaster recovery policy;

[0011] Obtain the resource request result with a successful request and return it to the main thread.

[0012] In a possible design, the re-initiation of the resource request according to the target disaster recovery policy includes:

[0013] Determine whether the target domain name in the resource request is available;

[0014] If the target domain name is not available, obtain an available domain name from the target domain name list and replace the target domain name with the available domain name;

[0015] Re-initiate a resource request to the available domain name.

[0016] In a possible design, the re-initiation of the resource request according to the target disaster recovery policy includes:

[0017] Call the communication layer of the target process to transmit a preset network protocol field to the main thread, and the preset network protocol field is used for the main thread to obtain current network data;

[0018] Determine at least one of the network connection status, download speed, and request response duration according to the network data;

[0019] Determine whether there is a network problem currently according to at least one of the network connection status, download speed, and request response duration;

[0020] If there is a network problem currently, re-initiate a resource request to the target domain name in the resource request.

[0021] In a possible design, the re-initiation of the resource request according to the target disaster recovery policy includes:

[0022] When re-initiating a resource request to the available domain name, if the request fails, obtain the error code when the request fails, and the error code is used to indicate whether there is a failure in the client or the server;

[0023] If the client has a failure, re-initiate a resource request to the target domain name;

[0024] If the server has a failure, re-initiate a resource request to the target domain name after replacement.

[0025] In a possible design, the re-initiation of the resource request according to the target disaster recovery policy includes:

[0026] Monitor the current network status of the client, where the network status includes connected to the network and not connected to the network;

[0027] If the network status is not connected to the network, obtain the request result matching the resource request from the cache as the request result of successful request. The cache stores the request results returned each time the client initiates a resource request.

[0028] In a possible design, the obtaining of the target domain name list includes:

[0029] Obtain the preset default domain name list as the target domain name list. The default domain name list includes at least one domain name and a domain name flag, and the domain name flag is used to indicate whether the domain name is available;

[0030] Or,

[0031] Obtain the dynamic domain name list as the target domain name list. The dynamic domain name list is sorted according to the domain name data of each available domain name, and the domain name data includes at least one of the availability rate of the domain name, the response speed of the domain name, and the continuous stability rate of the domain name.

[0032] In a possible design, the method further includes:

[0033] Obtain the events to be executed by the main thread, and determine the execution order of each event to be executed. At least the update event of the domain name list is included in the events to be executed;

[0034] When the main thread executes the time according to the execution order, perform timing. Determine whether there is an execution of the update event after the timing duration exceeds the preset duration;

[0035] If the update event is not executed, notify the main thread to jump and execute the update event according to the execution order. When the update event is executed, it is used to update the available domain names in the dynamic domain name list according to the domain name data of each available domain name.

[0036] In a possible design, the re-initiation of the resource request according to the target request policy includes:

[0037] Determine whether a registration completion notification is received. The registration completion notification is used to indicate that the target process in the client has completed registration. The target process is used to re-initiate a resource request according to the target disaster recovery policy when the resource request initiated by the client fails;

[0038] If the registration completion notification time is not received, intercept the resource request of the client through the target thread in the client;

[0039] Use the temporary disaster tolerance policy pre-configured for the target thread as the target request policy, and re-initiate the resource request according to the temporary disaster tolerance policy.

[0040] In a possible design, the re-initiating the resource request according to the temporary disaster tolerance policy includes:

[0041] Obtain the type of the resource currently requested and the pre-configured standby domain name;

[0042] Determine the replacement method of the target domain name in the resource request according to the type of the resource;

[0043] According to the replacement method, replace the target domain name with the pre-configured standby domain name to re-initiate the resource request.

[0044] In a second aspect, the present application provides a project data processing device, including:

[0045] A process registration module, configured to obtain a process registration request initiated by the main thread of the client, and call the registration layer of the target process to perform process registration;

[0046] A domain name list processing module, configured to obtain a target domain name list from the main thread of the client, call the domain name policy layer of the target process of the client to mark the target domain name list, and store the marked target domain name list in the 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;

[0047] A resource interception module, configured to, when the main thread initiates a resource request, call the disaster tolerance layer of the target process to intercept the resource request, and determine whether the resource request result of the resource request is a request failure according to the target domain name list in the data layer;

[0048] A policy determination module, configured to, if the resource request result is a request failure, re-initiate the resource request according to the target disaster tolerance policy;

[0049] A result return module, configured to obtain the resource request result of a successful request and return it to the main thread

[0050] The present application provides a method and device for processing resource requests. When the client initiates a resource request, the resource request initiated by the client is directly intercepted, and then it is determined whether there is a resource request failure. If there is a resource request failure, the resource request is re-initiated according to the target disaster recovery strategy until a request result of a successful request is obtained, and then returned to the client. In this way, when a target resource request cannot be responded to in the first time, since subsequent resource requests will also be intercepted, subsequent resource requests will not be responded to in advance. Until the target resource request obtains the corresponding request result, the subsequent resource requests will continue to be executed. In this way, the order of resource requests during execution can be avoided to be disordered, and the disaster recovery effect is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] 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 present application.

[0052] Figure 1 A schematic diagram of a resource request scenario provided in an embodiment of the present application;

[0053] Figure 2 A flowchart of a method for processing resource requests provided in an embodiment of the present application;

[0054] Figure 3 A schematic diagram of the internal architecture of a client provided in an embodiment of the present application;

[0055] Figure 4 A schematic diagram of selecting a domain name list provided in an embodiment of the present application;

[0056] Figure 5 A schematic diagram of the execution order scheduling provided in an embodiment of the present application;

[0057] Figure 6A A schematic diagram of the structure of the resource hijacking center provided in the embodiment of the present application;

[0058] Figure 6B Execute logic diagram for ajax interceptor;

[0059] Figure 7 Execute the diagram for the request after overriding the Open and Send methods;

[0060] Figure 8 A schematic diagram of a temporary disaster recovery strategy provided in an embodiment of the present application;

[0061] Figure 9 A schematic diagram of the structure of a resource request processing device provided in an embodiment of the present application;

[0062] Figure 10Schematic diagram of the computer device provided by the embodiment of the present application.

[0063] Through the above-mentioned drawings, specific embodiments of the present application have been shown, and more detailed descriptions will be provided hereinafter. These drawings and written descriptions are not intended to limit the scope of the concept of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. Detailed implementation manners

[0064] To make the objectives, 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. Obviously, the described embodiments are only a part rather than all of the embodiments of the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts, including but not limited to combinations of multiple embodiments, fall within the scope of protection of the present application.

[0065] The terms "first", "second", "third", "fourth", etc. (if any) in the specification, claims and drawings of the present application are used to distinguish similar objects and do not necessarily need to be used to describe a specific order or sequence. It should be understood that such used data can be interchanged under appropriate circumstances so that the embodiments of the present application described herein can be implemented in an order different from those illustrated or described herein. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device comprising a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these process, method, product or device.

[0066] First, the nouns involved in the present application are explained:

[0067] Content Delivery Network (CDN), a CDN server is a set of network server systems, which includes many specific functional modules. It includes four main functional modules: distributed storage, load balancing, network request redirection, and content management. Content management and network traffic management are the two most important functions in the CDN server. Using a CDN server to access the network will reconstruct a new network architecture in the Internet and enable special network sending functions to the user's network. This can largely solve the problem of network access congestion and improve the response time and speed of the website.

[0068] Hyper Text Markup Language (HTML) is a markup language. It includes a series of tags. Through these tags, the formats of documents on the network can be unified, and the scattered Internet resources can be connected into a logical whole. HTML text is descriptive text composed of HTML commands, and HTML commands can describe text, graphics, animations, sounds, tables, links, etc.

[0069] Cascading Style Sheets (CSS) is a computer language used to present the styles of HTML files.

[0070] JavaScript (abbreviated as JS) is a script and a programming language. It is an interpreted scripting language. It can implement complex functions on web pages, such as content updates, interactive maps, 2D / 3D animations, scrolling videos, etc.

[0071] Packaging tool: Packaging is to do some preprocessing work, compress and integrate various files, including some targeted optimizations, perform static analysis according to the dependencies between modules, and then generate corresponding static resources for these modules according to the specified rules.

[0072] Static resources: Fixed pages on the front end, which contain HTML, CSS, JS, pictures, etc. They are pages that can be directly displayed without querying the database or requiring program processing.

[0073] The basic idea of the Document Object Model (DOM) is to parse a structured document (such as HTML) into a series of nodes, and then form a tree structure (DOM Tree) from these nodes. All nodes and the final tree structure have standardized external interfaces to achieve the purpose of operating on the document using a programming language (such as adding or deleting content). DOM does not belong to JavaScript, but operating on DOM is the most common task of JavaScript, and JavaScript is also the most commonly used language for DOM operations.

[0074] script tag: Used to define client-side scripts (such as JavaScript). The script element can contain both script statements and can also point to an external script file through the "src" attribute. JavaScript is usually used for image operations, form validation, and dynamic content changes.

[0075] Promise: An object that represents the eventual completion or failure of an asynchronous operation. In concurrent programming, since some computations (or network requests) have not finished, an object is needed to proxy the unknown result, and this object that proxies the unknown result is called a Promise.

[0076] Currently, in the field of computer technology, in order to improve the response speed of websites and reduce response time, content delivery network (CDN) servers are usually used. At the same time, important resources at the front end of the website are generally stored on CDN servers. Therefore, the stability of CDN servers is crucial for the front end. Once a problem occurs with the CDN server, users will be unable to access the website page. For this reason, corresponding disaster recovery solutions are usually configured to deal with the instability of CDN servers. Specifically, by configuring multiple alternative CDN server domain names, and then monitoring each CDN server. When a problem occurs with a certain CDN server, the domain name is directly replaced with the domain name of a CDN server that can be accessed. Additionally, if the accessed resource is an image, the resource link of the document object model (DOM) node of the image needs to be replaced with a new resource link. However, this disaster recovery method only exists in the case where resources are asynchronously requested. In actual applications, there will be one or more JavaScript tags on the page. During the execution of the browser, since JavaScript tags are synchronously loaded, but the execution of JavaScript has a strict execution order. During the synchronous loading of multiple JavaScript tags, if a problem occurs with the CDN server where some JavaScript tags load resources, these JavaScript tags cannot perform domain name replacement and loading in a timely manner, while the other JavaScript tags can be loaded normally. Thus, after synchronous loading, these JavaScript tags need to load and request the resources again, which leads to a disorder in the execution order. Moreover, the traditional CDN disaster recovery solution mainly uses the method of configuring the number of retries for retries and directly switching the domain name after retries as the disaster recovery strategy. However, this fixed disaster recovery strategy is not smart and flexible. And the traditional solution can only operate at the code level. In the face of weak network and no-network environments, even replacing the domain name cannot achieve the goal. Therefore, under the limitations of weak network and no-network, the traditional solution cannot perform disaster recovery. Finally, the way to obtain domain name configuration in the traditional solution is to use a timer to continuously request the interface at a certain time, that is, polling to request the interface. However, the drawback of this solution is that once the main thread is executing complex tasks, it is very uneconomical to occupy the execution time of the main thread for low-priority configuration, affecting the interactive performance of the page.

[0077] In view of the above problems, the present application provides a disaster recovery solution for a CDN server. By implanting a tool (such as script code) in the browser, when a request is made to a website, the browser will parse the HTML. During the parsing process, the tool provided by the present application is initialized. After the execution is completed, all resource requests of the page will be monitored and intercepted, so as to be able to intercept, replace, or re-request the resources of the CDN, and finally achieve the disaster recovery effect.

[0078] Next, the technical solution of the present application will be described in detail through specific embodiments. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments.

[0079] Exemplarily, Figure 1 is a schematic diagram of the scenario of resource requests provided by an embodiment of the present application. As Figure 1 shown, the terminal device 11 may include computer devices, laptop computers, tablet computers, etc. Users usually access websites through the client (such as a browser) in the terminal device 11. Taking the client as a browser as an example, important resources on the front end of the website are usually stored on the server 12 (taking the CDN server as an example). When one of the CDN servers has a problem, the user cannot enter the browser page. Therefore, multiple CDN servers need to be set up. When one of the CDN servers has a problem, another CDN server is selected as a replacement to ensure the availability of resources.

[0080] Embodiment 1

[0081] Figure 2 is a schematic flowchart of the processing method for resource requests provided by an embodiment of the present application. The execution subject of this method can be the client. Among them, the carrier of the client can be the above-mentioned terminal device. Exemplarily, the client can be a browser. As Figure 2 shown, this method may specifically include the following steps:

[0082] Step S201, obtain a process registration request initiated by the main thread of the client, and call the registration layer of the target process to perform process registration.

[0083] In this embodiment, taking the client as a browser as an example, the client may include a main thread and a service work process (i.e., the target process) that communicates with the main thread. Exemplarily, Figure 3 is a schematic diagram of the internal architecture of the client provided by an embodiment of the present application. As Figure 3As shown, a communication layer is configured in the main thread, which is mainly responsible for communicating with the service work process and determining the completion of mutual information reception. At the same time, a communication layer is also configured in the service work process to interact and communicate with the main thread. During the execution of the main thread, the service work process registration center will be executed. During the execution of the service work process registration center, the communication layer of the main thread will be called. The communication layer of the main thread will initiate a registration request based on the address of the service work process. After receiving the registration request, the registration layer of the service work process will execute the created installation event and create a buffer (the buffer is mainly used to match the cache of resources so that the cache can be obtained for resource loading when the subsequent client is in a weak network or no-network state). After the execution of the registration layer of the service work process is completed, it waits for the browser to establish the environment until the service work process registration is completed, which will trigger the activation event created inside the communication layer of the main thread.

[0084] Among them, the activation event will call the interface of the domain name registration center to obtain the latest domain name list. If the latest recommended list of the domain name registration center has not been pulled completely, the domain name registration center will provide a default list to the communication layer of the main thread. The communication layer of the main thread will trigger the communication dedicated line of the service work process and send the domain name list to the service work process. The communication layer of the service work process will receive the domain name list according to the agreed protocol. After receiving the domain name list, it will trigger the domain name policy layer on the left side of the figure. The domain name policy layer will perform secondary processing on the domain name list, mark each domain name with whether it fails, and then call the data layer to store it. The domain name policy layer is mainly used to judge whether the current domain name is available. Each time the domain name list is updated, the stock list will be initialized so as to obtain the latest and optimal domain names for disaster tolerance.

[0085] Among them, after the domain name policy layer finishes processing, it will use the communication layer of the service work process to notify the registration completion notification event of the communication layer of the main thread. The registration completion notification event of the communication layer of the main thread will trigger the operation of unloading the resource hijacking center. It should be noted that in this embodiment, when the page first enters the browser, the service work process has not been started and it cannot intercept all resource requests of the page. Therefore, it is necessary to use the resource hijacking center to achieve interception. After the service work process starts, the resource hijacking center will be unloaded.

[0086] Among them, by deploying a communication solution between the main thread and the Service Work process, each module can complete CDN disaster recovery without affecting the main process. Moreover, when the page is first entered, the Service Work process has not been started yet and cannot take over all requests of the page in time, which may cause the disaster recovery to fail when the user first enters the page and the initial loading fails. By deploying a communication solution between the main thread and the Service Work process, before the Service Work takes over the page requests, a temporary disaster recovery solution can be implemented through the resource hijacking center and the resource loading center in the main thread.

[0087] Step S202: Obtain a list of target domain names from the main thread of the client, call the domain name policy layer of the target process of the client to mark the list of target domain names, and store the marked list of target domain names in the data layer of the target process. The list of target domain names includes at least one domain name and a mark for indicating whether the domain name is available.

[0088] In this embodiment, the list of target domain names is the latest domain name list mentioned above. Among them, if the domain name registration center has completed the pull, the latest domain name list can be the latest recommended list obtained by the domain name registration center through pulling. If the domain name registration center has not completed the pull, the latest domain name list is the default list. The default list can be a pre-configured static domain name list, while the latest recommended list pulled by the domain name registration center is a dynamic domain name list, and its content will be updated in real time according to the domain name data (such as availability rate, response speed, stability) of each domain name. Exemplarily, when the stability of a certain domain name decreases, its recommended value in the dynamic domain name list will decrease. Among them, when re-determining the available domain names, the available domain names are selected according to the high and low recommended values to replace the target domain names.

[0089] Step S203: When a resource request is initiated in the main thread, the disaster recovery 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 list of target domain names in the data layer.

[0090] In this embodiment, there will be one or more script tags in the browser page. When the browser loads these script tags, a resource request will be sent to the CDN server to obtain the resources corresponding to the script tags stored on the CDN server.

[0091] Among them, the execution of Javascript has a strict execution order. For example, taking the synchronous loading of script tag A, script tag B and script tag C as an example, if a problem is found in the CDN server when loading script tag B, the corresponding resource cannot be obtained when loading script tag B, while script tag A and script tag C are successfully loaded and the corresponding resources are obtained. If the CDN server is changed again to load script tag B, this will cause the execution order to be disordered (that is, script tag A, script tag B, script tag C become asynchronous loading). To address this problem, in this embodiment, the resource request initiated by the browser will be intercepted, and the request result returned by the CDN server will also be intercepted.

[0092] In this embodiment, a Service Work process (such as a proxy) can be implanted in the disaster recovery layer of the target process of the client, and the resource request initiated by the client and the request result returned by the CDN server can be intercepted by the proxy. The proxy can proxy all resource interaction requests of the page.

[0093] For example, if a problem occurs on the CDN server when loading script tag B, at this time, since all resource requests (including the resource request of script tag A, the resource request of script tag B and the resource request of script tag C) are intercepted by the Service Work process, the resource request does not actually reach the CDN server. In this way, the browser cannot obtain the result of the resource request and can only wait until it receives the result of the resource request before loading subsequent script tags.

[0094] In this embodiment, the target domain name list includes several domain names, and each domain name can be marked to indicate whether it is available. For example, when a domain name is unavailable, it is marked as unavailable, and when a domain name is available, it is marked as available.

[0095] In this embodiment, the intercepted resource request may include the CDN server domain name. Exemplarily, after the Service Work process implanted in the client intercepts the resource request, it can parse the resource request to obtain the CDN server domain name it requests (for example, the CDN server domain name of the resource request is server F1). In addition, the Service Work process can obtain the target domain name list in real time. The target domain name list can mark which CDN server domain names have problems and which CDN server domain names do not have problems currently. Through the target domain name list, it can be determined whether the CDN server domain name of the resource request has problems. If there are problems, it can directly determine that the resource request result is a request failure.

[0096] Exemplarily, after the Service Work process intercepts the resource request, it can also directly initiate a resource request to the CDN server domain name of the resource request. If the CDN server domain name has problems, an error condition will be fed back to the Service Work process. Thus, it can also be determined that the resource request result is a request failure. Among them, the fed-back error condition will be intercepted by the Service Work process and will not be returned to the client, thereby avoiding the client loading other script tags and initiating other resource requests after receiving the resource request result of request failure, resulting in disorder of the execution order of the script tags.

[0097] Step S204, if the resource request result is a request failure, then re-initiate the resource request according to the target disaster recovery policy.

[0098] In this embodiment, in different situations, there are corresponding different target disaster recovery policies. For example, the corresponding target disaster recovery policy can be determined according to the resource request result to re-initiate the resource request, or the corresponding target disaster recovery policy can be determined according to the network request of the client itself. Exemplarily, if the resource request result indicates that the current CDN server fails, the corresponding target disaster recovery policy is to replace it with a new CDN server, and then initiate a resource request to the new CDN server to obtain a resource request result of successful request. Among them, a relationship correspondence table can be established, which includes which target disaster recovery policy is selected to re-initiate the resource request in different situations.

[0099] Step S205, obtain the resource request result of successful request and return it to the main thread.

[0100] In this embodiment, the disaster recovery layer in the Service Work process includes an agent. The Service Work process is equivalent to an intermediate node between the CDN server and the client. After the client initiates a resource request, the agent intercepts the resource request. If the CDN server for the resource request is normal, the agent forwards the resource request to the CDN server. Based on the resource request, the CDN server returns a successful resource request result to the agent, which then forwards it to the client. If the CDN server for the resource request has a problem, the agent can re-initiate the resource request to a new CDN server. The new CDN server returns a successful resource request result to the agent, which then forwards it to the main thread of the client.

[0101] In the embodiment of the present application, when the client initiates a resource request, the resource request initiated by the client is directly intercepted, and then it is determined whether there is a situation where the resource request fails. If there is a situation where the resource request fails, the resource request is re-initiated according to the target disaster recovery policy until a successful request result is obtained, and then it is returned to the client. This method can ensure that the execution order of synchronously loading resources is not disrupted and improve the disaster recovery effect.

[0102] Embodiment 2

[0103] Based on the above embodiment, there are various situations where the resource request result is a failure. In this embodiment, taking the situation where the resource request result is a failure due to a problem with the CDN server as an example, after the Service Work process intercepts the resource request, the resource request can be re-initiated through the following steps: determine whether the target domain name in the resource request is available; if the target domain name is not available, obtain an available domain name from the target domain name list and replace the target domain name with the available domain name; re-initiate the resource request to the available domain name.

[0104] In this embodiment, the domain name is used to access the CDN server, and different domain names access different CDN servers. For example, domain name Y1 corresponds to accessing CDN server F1, and domain name Y2 corresponds to accessing CDN server F2. Exemplarily, taking the target domain name in the resource request as Y1 as an example, if CDN server F1 has a problem, then the target domain name Y1 is not available.

[0105] In this embodiment, the target domain name list can be a pre-configured default domain name list or a dynamic domain name list that is updated in real time based on the problem situation of the CDN server. Exemplarily, it can be determined whether the target domain name in the resource request is available based on the target domain name list. Specifically, if the target domain name in the resource request is not in the target domain name list, it can be determined that the target domain name is not available.

[0106] Exemplarily, the available domain names in the target domain name list can be sorted according to priority. For example, if the response speed of the available domain name K1 is fast, its ranking is relatively high; if the response speed of the available domain name K2 is slow, its ranking is relatively low. In this embodiment, exemplarily, the available domain name with a higher ranking can be selected to replace the target domain name, and the corresponding CDN server can be requested for resources through the replaced target domain name.

[0107] In this embodiment, continue to refer to Figure 3 , the disaster recovery layer of the service work process will create a proxy. The main function of the proxy is to intercept resource requests and CDN server responses. At the same time, after the proxy intercepts the resource request initiated by the main thread, it will proxy the sending of the resource request. Specifically, the processing logic of the proxy is as follows:

[0108] S11. When the main thread initiates a resource request, the proxy in the disaster recovery layer of the target process will intercept the resource request and proxy the sending of the resource request. Before sending, it will first call the domain name list in the data layer of the service work process to determine whether the target domain name in the current resource request is a CDN domain name, and then perform abnormal domain name analysis to determine whether the target domain name is marked as unavailable in the domain name list. If it is not marked, the interface of the target domain name will be requested continuously. If it is once marked as unavailable, the domain name list will be traversed to obtain the first domain name that is not marked as unavailable, and the execution layer will be called to splice the original domain name to obtain the latest available domain name.

[0109] S12. After obtaining the latest available domain name, the proxy will perform domain name replacement, that is, replace the original unavailable target domain name with the available domain name, and then resend the resource request. At the same time, if the request sending fails, the proxy will also intercept the failed request result, from which the failed error status code and the response header can be obtained and reported to the server for data analysis, and the availability status of the domain name list will be marked and stored in the data layer. After that, the proxy will call the scheduling layer to execute the disaster recovery plan. Through the created proxy combined with the logical processing of the data layer and the execution layer, the problem that all resource requests cannot be responded to for disaster recovery in the first time can be solved.

[0110] In the embodiment of the present application, by performing domain name replacement, the unavailable domain name in the resource request is replaced with the available domain name in the target domain name list, and then the resource request is re-initiated through the available domain name, which can realize the disaster recovery of the CDN server, ensure that users can also enter the page stably when a certain CDN server has problems, and improve the stability of the front end.

[0111] Embodiment III

[0112] Based on the above description, in this embodiment, when the proxy fails to proxy the client to initiate a request to the CDN server, the proxy can also intercept the failed request result, from which the failed error status code and the response header can be obtained and reported to the server for data analysis. After that, the proxy will call the scheduling layer to execute the disaster recovery plan. Specifically, the disaster recovery plan can be as follows: call the communication layer of the target process to transmit the preset network protocol fields to the main thread, and the preset network protocol fields are used for the main thread to obtain the current network data; determine at least one of the network connection status, download speed, and request response duration according to the network data; determine whether there is a network problem currently according to at least one of the network connection status, download speed, and request response duration; if there is a network problem currently, then initiate a resource request to the target domain name in the resource request again.

[0113] In this embodiment, the client needs to use the network to initiate a resource request to the CDN server. Exemplarily, the network data can be used to indicate the current network connection status of the client. If the current network connection status does not meet the conditions (such as being disconnected from the network or having a weak network connection signal), it means that the CDN server may not actually have a problem, and the reason for the failed resource request may be the network status of the client. At this time, even if a new domain name is replaced to initiate a resource request to other CDN servers, there will still be a situation of request failure. Therefore, the disaster recovery plan at this time is to directly initiate a resource request to the target domain name.

[0114] Exemplarily, combined with Figure 3 The disaster recovery plan of this embodiment will be described in detail. Specifically, when the resource request result is a request failure and the disaster recovery plan is triggered, the scheduling layer of the service work process will be executed. The scheduling layer will analyze the error code and error status when the previous resource request failed. The specific process is as follows:

[0115] S21. The network layer of the service work process will use the communication layer to obtain the network data of the main thread. The communication layer of the service work process will pass the agreed network protocol fields to the communication layer of the main thread, and the communication layer of the main thread will call the method to obtain the network status.

[0116] S22. During the execution of the method for the main thread to obtain the network status, the online variable and connection object on the window opened in the browser and the network loading data on the performance will be obtained, and then this information will be passed to the service work process through the communication layer of the main thread.

[0117] S23. After the network layer of the service work gets the data, the following calculation and analysis will be performed on the result:

[0118] S231. Analyze whether the current network status is in a state of having a network connection and the network is 4G / 5G / wireless (2G and 3G networks are in a weak network state).

[0119] S232. Obtain the downlink on the connection object for calculation and analysis: downlink * 1024 / 8 = download speed (unit: kb / s, that is, how many bytes are transferred per second). If the download speed is less than 200 kb / s, the client (taking the browser as an example) is considered to have a poor network status (that is, there is a network problem).

[0120] S233. Obtain the ttfb metric based on the network loading data on performance. The ttfb metric is the duration for the browser page to receive the response from the CDN server, which can be used to judge the response performance of the CDN server and the network. If ttfb is greater than 500 ms, it is considered that the metric is not good.

[0121] S234. The scheduling layer of the service work process will obtain the analysis result of the network data from the network layer and judge whether it is a network problem through the network layer. If it is a network problem, directly retry the strategy instead of directly switching the domain name. Because if the resource acquisition fails due to network fluctuations, it is not a problem of the CDN service. Even if the CDN domain name is switched, the optimal effect cannot be achieved, and it will instead misdiagnose the current domain name.

[0122] In the embodiment of the present application, by detecting whether there is a problem with the network of the client and determining whether to select to switch the domain name based on the network status of the client, the accurate selection of the disaster tolerance solution can be realized, unnecessary or incorrect disaster tolerance solutions can be avoided, and the efficiency of disaster tolerance can be improved.

[0123] Further, on the basis of the above embodiment, in some other embodiments, if the error code when the request fails is obtained and analyzed and it is found that there is no problem with the network of the client, then continue to execute the following disaster tolerance solution: obtain the error code according to the request result of the resource request. The error code is used to characterize whether there is a fault in the client or the server; if the client has a fault, re-initiate a resource request to the target domain name; if the server has a fault, re-initiate a resource request to the target domain name after replacement.

[0124] In this embodiment, the scheduling layer classifies the error codes when resource requests fail. Based on the category attribution of the error codes, it determines whether the current error status is a client error or a CDN server error. Once it is determined that the current error is a CDN server error, the domain name is directly switched, and a new CDN server is replaced to initiate the resource request. If the current error is due to the client, the retry policy is continued to avoid wasting more CDN server resources due to client reasons.

[0125] In the embodiment of the present application, by using the error codes returned in the request result, it is detected whether there is an error in the client or the CDN server, so as to determine whether to select to switch the domain name, which can achieve the precise selection of the disaster recovery solution, avoid executing some unnecessary or incorrect disaster recovery solutions, and improve the efficiency of disaster recovery.

[0126] Embodiment Four

[0127] Based on the above description, in this embodiment, when a resource request fails, the following disaster recovery strategy can also be adopted: monitor the current network status of the client, where the network status includes connected to the network and not connected to the network; if the network status is not connected to the network, obtain the request result matching the resource request from the cache as the request result of a successful request. The cache stores the request results returned each time the client initiates a resource request.

[0128] In the traditional CDN disaster recovery solution, when the client network changes, it can only wait for the network to recover and cannot effectively solve the problems faced by the front end, resulting in users being unable to enter the page. In this embodiment, since each resource request initiated by the client is intercepted and sent by the proxy, the resources returned from the CDN server will also be directly returned to the proxy and then forwarded to the client by the proxy. Thus, the proxy can cache the resources returned from the CDN server. When the client is not connected to the network and cannot establish a connection with the CDN server, the CDN disaster recovery solution of this embodiment can be executed to return the resources in the cache that match the resource request to the client.

[0129] Exemplarily, continue to combine Figure 3 to elaborate on the disaster recovery solution of this embodiment. When the main thread executes in the early stage, it will provide a set of callback methods for the online and offline events of the browser, and at the same time add a conversion event. When the client network status (such as network switching, network speed change, download speed change, etc.) changes, the provided callback events and conversion events will be triggered. In the callback events and conversion events, the network change will be provided to the network layer of the servicework process through the communication layer. The logic of the specific disaster recovery solution follows the following rules:

[0130] S31. When the registration layer of the service work process is installed, it will create a buffer.

[0131] S32. Each time a resource request passes through the proxy of the disaster recovery layer of the service work process, the content returned by the resource will be stored in the buffer created by the registration layer through the response interception in the proxy;

[0132] S33. Offline event trigger: If the network layer monitors an event, it means that the current network suddenly goes offline. Then the network layer will modify the network status of the data layer. Once the proxy of the disaster recovery layer receives an intercepted request, it will first call whether the network status of the data layer can initiate a resource request. Once the status is unavailable, it will match the cached resources through the buffer. If the cached resources are matched, the cached resources will be directly used to return to the client. If the cached resources cannot be matched, the resource request will continue to be executed;

[0133] S34. Online event trigger: If the network layer monitors an online event, it means that the network has recovered. Then the network layer will modify the network status of the data layer and change the network status to an available state. The proxy of the disaster recovery layer will directly request network resources without performing the cache matching logic in step S33;

[0134] S35. The conversion event is triggered: If the network layer monitors the network status, the following calculation rules will be used to determine whether the network status of the data layer is available: (1) The network delay rtt > 2 seconds; (2) The download speed is less than 200 kb / s; If one of the above conditions is met, it is unavailable, and the network status of the data layer will be modified.

[0135] In the embodiment of the present application, by monitoring the change of the network status of the client, when the client is not connected to the network, the resource request of the client can be responded based on the resources cached in the buffer, which can solve the problem that the page cannot be displayed when the client is in a weak network or no network state, and solves the limitation that the traditional CDN disaster recovery solution can only wait for the network to recover.

[0136] Embodiment Five

[0137] Based on the above embodiments, in this embodiment, the target domain name list can be a preset default domain name list or a dynamic domain name list. Among them, the default domain name list includes at least one domain name and a domain name flag, and the domain name flag is used to indicate whether the domain name is available. The dynamic domain name list is obtained by sorting the domain name data of each available domain name, and the domain name data includes at least one of the availability rate of the domain name, the response speed of the domain name, and the continuous stability rate of the domain name.

[0138] The traditional CDN disaster recovery solution is to pre-configure multiple domain names. After disaster recovery is triggered, the pre-configured domain names are used for replacement. Since the front end cannot perceive the CDN server, it is impossible to know which specific CDN server has problems and the optimal domain name selection effect cannot be achieved. In this embodiment, referring to Figure 3 , the domain name registration center of the main thread stores a set of default domain name lists. When a user enters the page, the domain name registration center of the main thread updates the domain name list in the domain name calculation center in a polling manner. The domain name calculation center provides a calculation method for the optimal domain name (for example, determining the optimal domain name based on the availability rate of the domain name, the response speed of the domain name, and the continuous stability rate of the domain name), and can obtain the domain name that the current user can access fastest, and then store it locally as the dynamic domain name list.

[0139] In this embodiment, when the disaster recovery solution is triggered, if it is found that the target domain name in the resource request is unavailable, it is possible to first check whether there is a dynamic domain name list locally. If there is a dynamic domain name list stored locally, the optimal domain name (for example, the domain name ranked at the top of the dynamic domain name list) can be selected from it to replace the target domain name. If there is no dynamic domain name list locally (the dynamic domain name list needs time to calculate and update dynamically), an available domain name is searched from the default domain name list to replace the target domain name.

[0140] Exemplarily, Figure 4 is a schematic diagram of domain name list selection provided by the embodiment of the present application. As Figure 4 shown, it includes the following steps: Step S401, initialize the domain name of the request configuration center. Step S402, when the resource request fails, obtain the dynamic domain name list. Step S403, when the dynamic domain name list has not been returned yet, obtain the default domain name list. Step S404, return the obtained default domain name list. Step S405, return the response and store the calculated dynamic domain name list. Step S406, when the resource request fails again, continue to obtain the dynamic domain name list. Step S407, directly return the stored dynamic domain name list.

[0141] Among them, when the first resource request fails, a request to obtain the dynamic domain name list is first sent to the domain name calculation center. If the domain name calculation center does not return a response, the default domain name list is obtained from the default domain name list storage center. When the next resource request fails, the domain name calculation center has returned the calculated dynamic domain name list and stored it in the domain name registration center. At this time, the dynamic domain name list can be directly obtained from the domain name registration center.

[0142] In this embodiment, two interfaces are provided when packaging the client. One interface is used to call the default configuration domain name list, which is used when the browser first loads. If there is a problem with the CDN server, there is no need to request the domain name calculation center to calculate the dynamic domain name list and then perform CDN disaster recovery. The other interface is the interface for the domain name calculation center to obtain the available domain name list. After initialization, it will dynamically select the time to update the domain name list through a series of calculation rules, and select whether to use the default domain name list or pull the dynamic domain name list calculated by the domain name calculation center. Among them, the default domain name list is all the domain names that can be requested, and the dynamic domain name list is the optimal domain name that meets the current user's needs obtained by the domain name calculation center through the optimal intelligent sorting of the availability rate, response rate, etc. of the available domain names in the current region.

[0143] In the embodiment of the present application, by setting a static default domain name list and a dynamic domain name list, when the CDN server has a problem and needs to replace the domain name, multiple ways to select the domain name list can be provided, so as to achieve the optimal selection of domain name replacement and improve the resource request efficiency.

[0144] Exemplarily, when the domain name calculation center calculates the dynamic domain name list, it can calculate according to the domain name requirements, sort after obtaining the final data of each domain name, and finally obtain the dynamic domain name list. Among them, the factors affecting the domain name sorting are mainly the following: 1. Availability rate, 2. Response speed, 3. Continuous stability rate. A recommended value is obtained according to the weight of each factor, and then sorted by the recommended value. Exemplarily, 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:

[0145] Recommended value = (Number of successful resource requests within three minutes in the current area / Total number of resource requests within three minutes in the current area) * Availability rate weight k + (Longest response time in the area - Current response time in the area) / (Longest response time in the area - Shortest response time in the area) * Response speed weight s + (Number of successful requests within one month in the area / Total number of requests within one month in the area) * Continuous stability rate weight w.

[0146] In the above formula, the availability rate weight k, the response speed weight s, and the continuous stability rate weight w can be manually configured according to different regions, different projects, and different situations.

[0147] Since the most important thing for the dynamic domain name list is to ensure high availability, and performance is secondary, so in the case of not manually adjusting the weights, the values of the availability rate weight k / response speed weight s / continuous stability rate weight w are 0.7 / 0.1 / 0.2 respectively. The higher the availability within a short period of time, the more it can represent that the current service is available. On this basis, select a domain name with higher performance. Exemplarily, assume that in a certain region, the data of three domain names are as follows.

[0148] Domain Name A Domain Name B Domain Name C Number of Successful Requests within Three Minutes 90 70 50 Total Number of Requests within Three Minutes 100 100 100 Current Response Time (ms) 200 100 30 Longest Response Time within the Region (ms) 500 500 500 Shortest Response Time within the Region (ms) 50 50 50 Number of Successful Requests within One Month 800 850 900 Total Number of Requests within One Month 1000 1000 1000

[0149] The recommended value of Domain Name A is:

[0150] 90 / 100*0.7+(500-200) / (500-50)*0.1+800 / 1000*0.2 = 0.8566666667

[0151] The recommended value of Domain Name B is:

[0152] 70 / 100*0.7+(500-100) / (500-50)*0.1+850 / 1000*0.2 = 0.5788888889

[0153] The recommended value of Domain Name C is:

[0154] 50 / 100*0.7+(500-30) / (500-50)*0.1+900 / 1000*0.2 = 0.6344444444

[0155] The sorted order of the final domain name recommendation list is: Domain Name A > Domain Name C > Domain Name B.

[0156] Furthermore, on the basis of the above-mentioned Embodiment 5, in some other embodiments, the domain names in the dynamic domain name list can be updated in real time. Specifically, the to-be-executed events of the client can be obtained, the execution order of each to-be-executed event can be determined, and the to-be-executed events at least include the update event of the domain name list; when the client executes the time according to the execution order, timing is performed to determine whether there is an update event after the timing duration exceeds the preset duration; if there is no execution of the update event, then jump to execute the update event according to the execution order, and the update event is used to update the available domain names in the dynamic domain name list according to the domain name data of each available domain name when it is executed.

[0157] In the traditional solution, the way to obtain the domain name configuration is to continuously request the interface through a timer set for a certain time, that is, to poll the interface. This way will occupy a large amount of the execution time of the main thread when complex tasks are executed in the main thread, resulting in a decline in the interactive performance of the page. In this embodiment, when performing the update of the dynamic domain name list, the domain name registration center will, based on the scheduling method of priority and set timeout time, combine the event loop of the browser to judge the time when the dynamic domain name list can be updated, so as to achieve the effect of optimal task scheduling. Among them, the hierarchical structure and function division of the domain name registration center are as follows: Processing layer: Execute some key logics to ensure the normal and good operation of the page process. Data layer: Store the data required for each link. Communication layer: Provide internal and external communication methods. Interface layer: Provide interfaces for external calls.

[0158] Exemplarily, an actuator can be abstracted to perform the dynamic domain name list update independently. A set of recursive logic is implemented inside the actuator. When the browser receives input events, click events, swipe events, actuator execution events, page rendering, etc., the execution priority will be determined according to the event loop rules and event scheduling. Figure 5 It is a schematic diagram of the execution order scheduling provided by the embodiment of the present application. As Figure 5 shown, under normal circumstances, the events to be executed by the main thread include input events, click events, swipe events, actuators, and page rendering events. In this embodiment, through a scheduling method based on priority and set timeout, combined with the event loop of the browser, the execution order of each event is scheduled to determine the time when the dynamic domain name list update can be executed, and finally the optimal task scheduling effect is achieved. The specific process of event task scheduling is as follows:

[0159] S51. During the deployment stage of the service work process, an id will be generated for the actuator that needs to run in the current stage, the id will be bound to the actuator, and the actuator will be implanted into the callback object.

[0160] S52. Set a 5-minute timer for the actuator with the current id as the timeout handling strategy. Once the timer times out, it means that within this period, the actuator has not been triggered to update the dynamic domain name list. In order to ensure the accuracy of the data, the timeout strategy is set. If it does not time out, S53 is executed; if it times out, S54 is executed.

[0161] S53. Determine whether there are execution events in the current main thread. Execution events include, but are not limited to, interactions such as input, click, and swipe, as well as whether the browser is sending requests and whether it is rendering. When other events of page drawing are completed, the callback object, that is, the actuator, will be executed. The execution logic of the actuator is as follows:

[0162] S531. Determine whether the id of the current actuator has been unbound. If it has not been unbound, continue to run; if it has been unbound, it means it has been executed and will not continue to execute.

[0163] S532. Call the domain name calculation center, which will perform domain name calculation and sorting of recommendation algorithms according to relevant factors to obtain the optimal domain name recommendation list.

[0164] S533. Transmit the optimal domain name recommendation list to the data layer for storage, and then send it to the service work process for domain name update.

[0165] S534. Unbind the id of the current actuator from the actuator.

[0166] S535. Finally, the executor will call a 5-second timer. After 5 seconds, the above steps will be repeated, starting from S51, and the next scheduling will continue.

[0167] S54. After the timeout, it will obtain the executor id that needs to run currently, and then manually call the executor of the current id to trigger the execution logic of the executor (i.e., go to S53).

[0168] In the embodiment of the present application, through the scheduling method based on priority and set timeout, combined with the event loop of the browser, the execution order of the events to be executed is scheduled to determine the update time of the dynamic domain name list, which can achieve the effect of optimal task scheduling, avoid continuously requesting the interface and occupying the execution time of the main thread, and improve the page interaction performance.

[0169] Embodiment Six

[0170] In this embodiment, the Service Work process needs to be registered in the client (such as a browser). Before the registration is completed, it cannot temporarily intercept resource requests. Therefore, a resource hijacking center needs to be set up to intercept resource requests through the resource hijacking center before the ServiceWork process completes registration, and then execute the pre-configured temporary disaster tolerance policy. The specific steps are as follows: determine whether a registration completion notification is received. The registration completion notification is used to indicate that the target process has completed registration. The target process is used to re-initiate a resource request according to the target disaster tolerance policy when the resource request initiated by the client fails; if the registration completion notification time is not received, intercept the resource request of the client through the resource interception center in the main thread; use the temporary disaster tolerance policy pre-configured for the main thread as the target request policy, and re-initiate a resource request according to the temporary disaster tolerance policy.

[0171] Continue to refer to the above Figure 3 , the main role of the resource hijacking center is in the stage before the service work process is successfully registered. Once the service work process is successfully registered, the resource hijacking center will be uninstalled. Among them, the registration timing of the resource hijacking center is the same as that of the process registration center of the main thread. After the main thread executes the process registration center, it will also call the resource hijacking center and the domain name registration center (the call to the domain name registration center can be seen above). The main role of the registration process of the resource hijacking center is to be able to sense the request failure situation of all resources on the page, and perform temporary disaster tolerance processing on the resources through the request failure situation.

[0172] Currently, resource failures are mainly captured through browser error listening events. However, this method can only capture the scenarios of mainstream resource loading (using JSONP), and will ignore a small number of resources loaded using the AJAX method. Further, in some embodiments, in order to be able to monitor the loading failures of all resources, a hijacking layer is set up in the resource hijacking center.

[0173] Specifically, Figure 6A is a schematic structural diagram of the resource hijacking center provided by the embodiments of the present application. As Figure 6A shown, the hijacking layer is divided into a first part and a second part. The first part is the JSONP (JSON with Padding) part, and the second part is the Asynchronous Javascript And XML And HTML (AJAX) part.

[0174] JSONP part: Use an event listener to create a capture event for the window object. When the resource loaded by the browser using the tag fails, the capture event will be triggered, and the capture event will call the public service of JSONP. In this embodiment, the listening methods for the failures of all resource types are extracted into a public service. During the process of listening and capturing error reports, since all error reporting methods on the page are listened to, such as syntax errors, type errors, range errors, reference errors, etc., this embodiment needs to find the tag type of the DOM node through the data returned by the browser event, and then call the data filtering method of the processing layer to match, screen, and eliminate error reports that do not belong to the resource loading error type.

[0175] AJAX part: In the process of traditional services using AJAX requests, a set of call methods are encapsulated and intercepted through a method similar to the transaction mechanism. In order to achieve a non-invasive hijacking method and unable to achieve the effects of listening and disaster tolerance by modifying the call chain in the source code, so in this embodiment, an interceptor is set for the XMLHttpRequest object of AJAX. The functions of the interceptor are as follows: ① Intercept the request for the CDN resource with server exception in advance and replace it with a requestable domain name; ② Identify resource exceptions and collect error codes and request IDs for exception analysis after hijacking fails. Among them, the XMLHttpRequest object is a built-in browser object that allows using JavaScript to send Hyper Text Transfer Protocol (HTTP) requests. Exemplarily, Figure 6B is a schematic diagram of the execution logic of the AJAX interceptor. As Figure 6BAs shown, when the client initiates a resource request and the domain name corresponding to the request is the CDN server F1, the ajax interceptor intercepts the resource request and analyzes the domain name. If it is determined that there is a problem with the CDN server F1, it directly initiates a resource request to the next CDN server F2, intercepts the resources returned by the CDN server F2, and then transmits them to the client.

[0176] In this embodiment, the open method and the send method of XMLHttpRequest (i.e., the open and send function methods of the XMLHttpRequest object) are rewritten. The rewritten open method is marked as newOpen, and the send method is marked as newSend. Then, the original open / send request method is executed by changing the runtime context of the function without contaminating the original method. Exemplarily, Figure 7 It is a schematic diagram of the request execution logic after rewriting the open method and the send method, as Figure 7As shown, when the page resource receives a request, it can obtain parameters such as the request address from newOpen. Assume that the current request domain name is the CDN service provider F1; newOpen will call the data filtering method of the resource hijacking center processing layer to ensure that the current request is a static resource request rather than other front-end and back-end interaction requests. And the request parameters are passed to the processing layer, and the processing layer will judge whether it is a request that can be proxied through three levels: ① The address suffix of the Uniform Resource Locator (URL), using regular expressions to match the suffix of the target static resource; ② Judge whether the request method of the current request is the get method; ③ Call the interface of the domain name registration center to obtain all domain name lists, judge the domain name of the current URL, and judge whether it is the domain name corresponding to the CDN server. The data filtering method will return a boolean value. If the boolean value is equal to true, it means that proxying can be performed. On the contrary, if the boolean value is equal to false, the request will be made directly without interception. After data filtering, newOpen will continue to call the communication interface of the domain name registration center of the processing layer to obtain the current domain name list, and judge whether the current domain name (CDN server F1) is marked as unavailable in the domain name list. If it is not marked, continue to request the interface of the CDN service provider F1. If it is once marked, it means that there is a problem with the CDN service of the current CDN server F1. Then traverse the domain name list to obtain the first available domain name that is not marked (such as CDN server F2), splice the original domain name, call the open function method of the XMLHttpRequest object, and pass in the modified domain name and parameters; after newOpen is called, it will trigger the rewritten newSend method. In the newSend method, a status preparation change event will be added to the constructor XMLHttpRequest. Once the status of the request changes, the added status preparation change event will be called for exception recognition: judge whether the status of the request is completed. When it is completed, check whether the network status code is normal. When the status code is greater than or equal to 400, it is an abnormal state. When the status code is in an abnormal state, the interceptor will call the interface of the domain name registration center of the processing layer to mark the current abnormal domain name (marked as unavailable). At this time, since the service work process is not ready yet, once an abnormality is confirmed, the method of the disaster recovery call layer will be called for a temporary solution for resource disaster recovery. The call layer will pass the data to the resource loading center to execute the temporary disaster recovery strategy.

[0177] Further, on the basis of the sixth embodiment above, in some other embodiments, when the resource loading center executes the temporary disaster tolerance policy, it may specifically include the following steps: obtaining the type of the currently requested resource and the pre-set backup domain name; determining the replacement method of the target domain name in the resource request according to the type of the resource; and replacing the target domain name with the pre-set backup domain name according to the replacement method to re-initiate the resource request.

[0178] In this embodiment, continue to refer to Figure 3 , when the resource loading center is called, first judge the current resource type, and different types of resources (such as javascript resources, image resources, and Cascading Style Sheets (CSS)) will be processed separately.

[0179] Among them, according to different types of resources, the corresponding replacement methods are different. Exemplarily, taking the current resource as a CSS resource as an example, at this time, the backup domain name can be obtained from the domain name registration center, and then the attributes of the old DOM node of the CSS resource are obtained. At the same time, a new DOM node is created, the backup domain name is replaced, and 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 continued to be executed to re-initiate the resource request.

[0180] Specifically, the corresponding processing measures when the resource is of the css type: by traversing the method of obtaining the dom node in the browser, obtaining all css resource tags, traversing all the dom nodes obtained through the above tags, and positioning to the specified dom node by comparing the error resource link, and then creating a new dom node, transferring the attributes on the old dom node to the new dom node, placing the new dom node behind the old dom node (target.appendChild), and removing the old dom node.

[0181] Exemplarily, if the current resource is a JavaScript resource, the backup domain name can be obtained from the domain name registration center at this time, and then the attributes of the old DOM node of the JavaScript resource are obtained. Based on the attributes of the old DOM node and the backup domain name, disaster recovery processing of the JavaScript resource is implemented. Specifically, according to whether the JavaScript resource is loaded asynchronously or synchronously, it can be further divided into two cases: In the first case, when the JavaScript resource is loaded asynchronously, a new DOM node of the JavaScript resource is created, the attributes of the old DOM node of the current JavaScript resource are transplanted to the created new DOM node, and the new domain name (i.e., the pre-configured backup domain name) is replaced, and then inserted into the page. At the same time, the original error-reporting DOM node is deleted, and then the page is continued to execute to re-initiate a resource request. In the second case: the attributes of the old DOM node of the JavaScript resource are obtained, and then based on the new domain name (i.e., the pre-configured backup domain name) and the original attributes, a new script tag is assembled, and the generated new script tag code is synchronously written into the html text. At the same time, the original error-reporting DOM node is deleted, and then the page is continued to execute to re-initiate a resource request.

[0182] Specifically, the processing measures corresponding to the case where the resource is of the js type: 1. If the current resource is a js resource, the DOM node of the current resource is obtained, and the DOM nodes of all the script tags on the page where the current execution reaches are obtained. And all the DOM nodes are traversed. The error-reporting URL is compared with the src of each DOM node through the error event. If the comparison is successful, it means that the DOM node is the js resource loaded by the script tag in the page. Based on the premise of successful comparison, after obtaining the current DOM node, it is judged whether the asynchronous attribute (async) of the current DOM node exists. If it exists, step a is executed; if it does not exist, step b is executed (if the async attribute exists, it means that the current js script is loaded asynchronously, and the execution timing of the script with the asynchronous attribute (async) is uncertain. The js script has strict requirements on the execution order. The loading of synchronous resources (without the asynchronous attribute) may have dependencies before and after, and the failure of the previous resource will affect the execution of the subsequent resource. Therefore, we need to process scripts with different loading orders differently.).

[0183] Step a: Create a new DOM node by asynchronously creating a script node (document.createElement) (Step explanation: The execution order of the nodes inserted in this way cannot be controlled because they are originally asynchronously loaded and their order is not fixed. Therefore, even if the original order is not maintained, it will have no impact). Transplant the attributes of the currently error-reporting DOM node to the newly created node, replace the new domain name, insert the new domain name into the page, and at the same time use the remove method to delete the old DOM node.

[0184] Step b: Obtain the original node attributes and links, replace the original resource link, add the original attributes, and finally assemble the script tag code. Synchronously write the generated script tag code into the html text (here, document.write is used: The code implanted in this synchronous way is different from the above asynchronous creation (createElement) of the script method. It will block the execution of the following scripts. After the current resource is loaded and executed, the subsequent code will continue to be executed. The main reason for not using this method all the time is that if it is executed in this way, it will cause the subsequent process to be blocked. At times when blocking is not required, this method does not have to be used). Use the remove method to delete the old DOM node.

[0185] Exemplarily, if the current resource is an image resource, at this time, a backup domain name can be obtained from the domain name registration center, and then through the error position, the DOM node of the currently error-reporting image resource can be determined, and the src of the DOM node can be replaced with the new domain name (i.e., the backup domain name), and then the page can be continued to execute to re-initiate a resource request.

[0186] Specifically, the corresponding handling measures when the resource is of the image type: Replace the src of the current resource with the new backup domain name, set the resource attributes (setAttribute), and update the random attributes to make the image reload.

[0187] Exemplarily, Figure 8 is a schematic flow diagram of the temporary disaster tolerance strategy provided by the embodiment of the present application, as Figure 8As shown in the figure, it includes the following steps: Step S800, determine the current resource type. Step S810, the current resource is a Cascading Style Sheet. Step S811, obtain an alternative domain name from the domain name registration center. Step S812, obtain the attributes of the old node. Step S813, create a new Text Object Model node and replace the domain name. Step S814, insert the Text Object Model node into the page. Step S815, remove the old node. Step S820, the current resource is a script resource. Step S821, obtain an alternative domain name from the domain name registration center. Step S822, obtain the attributes of the old node. Step S823, determine whether it is a synchronous resource / has an asynchronous attribute flag. Step S824, copy the attributes of the old node, match the new domain name, and create a new node in an asynchronous way of creating a script node and insert it into the page. Step S825, concatenate the attributes of the old node and the new domain name into a string, and create a new node in a synchronous way of creating a script node and insert it into the page. Step S826, remove the old node. Step S830, the current resource is an image resource. Step S831, obtain an alternative domain name from the domain name registration center. Step S832, obtain an alternative domain name from the domain name registration center. Step S833, obtain the current Document Object Model node where the error occurs through the error position. Step S834, replace the src of the node where the error occurs with the new domain name.

[0188] In summary, by deploying the Service Work process in advance in this application, the problem of data disorder caused by the communication between the service work process and the main thread can be solved, and the data synchronization problem between the resource hijacking center and the domain name registration center in the previous asynchronous interaction based on the main thread and the service work process can be solved. At the same time, through the resource hijacking center in the main thread, the disaster recovery legacy problem caused before the service work takes over the page can be solved, and the problem that the service work process cannot perform disaster recovery on CDN resources before initialization can be solved. Finally, through the domain name registration center in the main thread, the domain name recommendation logic can be optimized, so that the optimal domain name can be obtained in the resource hijacking center and the disaster recovery center in the first time for disaster recovery processing. Using an intelligent domain name update strategy, the problem of the time difference between dynamic domain names and static domain names and the performance problem caused by frequent updates of dynamic domain names can be solved.

[0189] The following is an embodiment of the device of this application, which can be used to execute the embodiment of the method of this application. For the details not disclosed in the embodiment of the device of this application, please refer to the embodiment of the method of this application.

[0190] Figure 9 It is a schematic structural diagram of a processing device for resource requests provided by an embodiment of this application. This processing device can be located on the client (such as on a web browser), as Figure 9As shown in the figure, the processing device 900 for resource requests 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 return module 950. The process registration module 910 is used to obtain a process registration request initiated by the main thread of the client and call the registration layer of the target process to perform process registration. The domain name list processing module 920 is used to obtain the target domain name list from the main thread of the client, call the domain name policy layer of the target process of the client to mark the target domain name list, and store the marked target domain name list in the data layer of the target process. The target domain name list includes at least one domain name and a mark for indicating whether the domain name is available. The resource interception module 930 is used to, when a resource request is initiated by the main thread, call the disaster tolerance layer of the target process to intercept the resource request, and determine whether the resource request result of the resource request is a request failure according to the target domain name list in the data layer. The policy determination module 940 is used to, if the resource request result is a request failure, re-initiate the resource request according to the target disaster tolerance policy. The result return module 950 is used to obtain the resource request result with a successful request and return it to the main thread.

[0191] Optionally, the policy determination module may specifically be used to: determine whether the target domain name in the resource request is available; if the target domain name is not available, obtain an available domain name from the target domain name list, and replace the target domain name with the available domain name; re-initiate the resource request to the available domain name.

[0192] Optionally, the policy determination module may specifically be used to: call the communication layer of the target process to transmit a preset network protocol field to the main thread, and the preset network protocol field is used for the main thread to obtain the current network data; determine at least one of the network connection status, download speed, and request response duration according to the network data; determine whether there is a network problem currently according to at least one of the network connection status, download speed, and request response duration; if there is a network problem currently, re-initiate the resource request to the target domain name in the resource request.

[0193] Optionally, the policy determination module may specifically be used to: when re-initiating the resource request to the available domain name, if the request fails, obtain the error code when the request fails, and the error code is used to characterize whether there is a failure in the client or the server; if there is a failure in the client, re-initiate the resource request to the target domain name; if there is a failure in the server, re-initiate the resource request to the target domain name after replacement.

[0194] Optionally, the policy determination module may specifically be used to: monitor the current network status of the client, and the network status includes connected to the network and not connected to the network; if the network status is not connected to the network, obtain the request result matching the resource request from the cache as the request result with a successful request, and the cache stores the request results returned each time the client initiates a resource request.

[0195] Optionally, the policy determination module may specifically be configured to: obtain a preset default domain name list as the target domain name list, where the default domain name list includes at least one domain name and a domain name flag, and the domain name flag is used to indicate whether the domain name is available; or, obtain a dynamic domain name list as the target domain name list, where the dynamic domain name list is obtained by sorting the domain name data of each available domain name, and the domain name data includes at least one of the availability rate of the domain name, the response speed of the domain name, and the continuous stability rate of the domain name.

[0196] Optionally, it further includes a domain name update module, configured to obtain the events to be executed by the main thread, determine the execution order of each event to be executed, where at least one of the events to be executed includes an update event of the domain name list; start timing when the main thread executes the events according to the execution order, and determine whether there is an update event to be executed after the timing duration exceeds a preset duration; if there is no update event to be executed, notify the main thread to jump and execute the update event according to the execution order, and the update event, when executed, is used to update the available domain names in the dynamic domain name list according to the domain name data of each available domain name.

[0197] Optionally, the policy determination module may specifically be configured to: determine whether a registration completion notification is received, where the registration completion notification is used to indicate that the target process has completed registration, and the target process is used to re-initiate a resource request according to the target disaster recovery policy when the resource request initiated by the main thread fails; if the registration completion notification is not received, intercept the resource request of the client through the resource interception center in the main thread; use the temporary disaster recovery policy pre-configured for the main thread as the target request policy, and re-initiate the resource request according to the temporary disaster recovery policy.

[0198] Optionally, the policy determination module may specifically be configured to: obtain the type of the resource of the current request and the pre-configured backup domain name; determine the replacement method of the target domain name in the resource request according to the type of the resource; and replace the target domain name with the pre-configured backup domain name according to the replacement method to re-initiate the resource request.

[0199] The device provided in the embodiments of the present application can be used to execute the methods in the above embodiments, and its implementation principles and technical effects are similar, and will not be described in detail here.

[0200] It should be noted that the division of each module of the above device is only a division of logical functions. In actual implementation, it can be fully or partially integrated into a physical entity, or physically separated. And these modules can all be implemented in the form of software called by a processing element; they can also all be implemented in the form of hardware; or some modules can be implemented in the form of software called by a processing element, and some modules can be implemented in the form of hardware. For example, the request determination module can be a separately established processing element, or can be integrated in a certain chip of the above device. In addition, it can also be stored in the memory of the above device in the form of program code, and the function of the above request determination module can be called and executed by a certain processing element of the above device. The implementation of other modules is similar. In addition, all or part of these modules can be integrated together or can be independently implemented. Here, the processing element can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each of the above modules can be completed by the integrated logic circuit in the processor element or the instruction in the form of software.

[0201] Figure 10 This is a schematic structural diagram of the computer device provided by the embodiment of the present application. As Figure 10 shown, the computer device 1000 includes: at least one processor 1001, a memory 1002, a bus 1003, and a communication interface 1004. Among them: The processor 1001, the communication interface 1004, and the memory 1002 communicate with each other through the bus 1003. The communication interface 1004 is used to communicate with other devices. The communication interface 1004 includes a communication interface for data transmission and a display interface or an operation interface for human-computer interaction, etc. The processor 1001 is used to execute computer instructions, and specifically can execute the relevant steps in the method described in the above embodiments. The processor may be a central processing unit or a specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention. One or more processors included in the electronic device can be of the same type of processor, such as one or more CPUs; or they can be of different types of processors, such as one or more CPUs and one or more ASICs. The memory is used to store computer instructions. The memory may include a high-speed RAM memory, and may also include a non-volatile memory, such as at least one disk memory.

[0202] This embodiment also provides a readable storage medium. Computer instructions are stored in the readable storage medium. When at least one processor of the computer device executes the computer instructions, the computer device executes the resource request processing method provided by the above various implementation manners.

[0203] This embodiment also provides a program product, which includes computer instructions stored in a readable storage medium. At least one processor of the computer device can read the computer instructions from the readable storage medium, and the execution of the computer instructions by at least one processor enables the computer device to implement the resource request processing method provided by the above various embodiments.

[0204] In this application, "at least one" means one or more, and "a plurality" means two or more. "And / or" describes the association relationship of associated objects and indicates that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone, where A and B can be singular or plural. The character " / " generally represents an "or" relationship between the associated objects before and after; in a formula, the character " / " represents a "division" relationship between the associated objects before and after. "At least one (item)" or its similar expression refers to any combination of these items, including any combination of single item (s) or multiple items (s). For example, at least one (item) of a, b, or c can represent: a, b, c, a - b, a - c, b - c, or a - b - c, where a, b, c can be single or multiple.

[0205] It can be understood that the various numerical numbers involved in the embodiments of this application are only for the convenience of description and are not used to limit the scope of the embodiments of this application. In the embodiments of this application, the magnitudes of the serial numbers of the above processes do not mean the sequence of execution, and the execution sequence of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of this application.

[0206] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of this application, rather than to limit them; although this application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for processing resource requests, characterized in that, applied to a client, the method includes: Obtain a process registration request initiated by the main thread of the client, and call the registration layer of the target process to perform process registration; Obtain a target domain name list from the main thread of the client, call the domain name policy layer of the target process of the client to mark the target domain name list, and store the marked target domain name list in the data layer of the target process. The target domain name list includes at least one domain name and a mark for indicating whether the domain name is available; When the main thread initiates a resource request, call the disaster tolerance layer of the target process to intercept the resource request, and determine whether the resource request result of the resource request is a request failure according to the target domain name list in the data layer; If the resource request result is a request failure, re-initiate the resource request according to the target disaster tolerance policy; Obtain the resource request result with a successful request and return it to the main thread.

2. The method according to claim 1, characterized in that, The re-initiation of the resource request according to the target disaster tolerance policy includes: Determine whether the target domain name in the resource request is available; If the target domain name is not available, obtain an available domain name from the target domain name list, and replace the target domain name with the available domain name; Re-initiate the resource request to the available domain name.

3. The method according to claim 1, characterized in that, The re-initiation of the resource request according to the target disaster tolerance policy includes: Call the communication layer of the target process to transmit a preset network protocol field to the main thread, and the preset network protocol field is used for the main thread to obtain current network data; According to the network data, determine at least one of the network connection status, download speed, and request response duration; According to at least one of the network connection status, download speed, and request response duration, determine whether there is a network problem currently; If there is a network problem currently, re-initiate the resource request to the target domain name in the resource request.

4. The method according to claim 2, characterized in that, The re-initiation of the resource request according to the target disaster tolerance policy includes: When re-initiating the resource request to the available domain name, if the request fails, obtain the error code when the request fails, and the error code is used to characterize whether there is a failure in the client or the server; If the client has a failure, re-initiate the resource request to the target domain name; If the server has a failure, re-initiate the resource request to the target domain name after replacement.

5. The method according to claim 1, characterized in that, The re-initiation of the resource request according to the target disaster tolerance policy includes: Monitor the current network status of the client, and the network status includes connected to the network and not connected to the network; If the network status is not connected to the network, obtain the request result matching the resource request from the cache as the request result with a successful request, and the cache stores the request result returned each time the client initiates a resource request.

6. The method according to claim 2, characterized in that, Obtain a list of target domain names, including: Obtain a preset default domain name list from the main thread as the target domain name list. The default domain name list includes at least one domain name and a domain name flag, and the domain name flag is used to indicate whether the domain name is available; Or, Obtain a dynamic domain name list from the main thread as the target domain name list. The dynamic domain name list is sorted according to the domain name data of each available domain name, and the domain name data includes at least one of the availability rate of the domain name, the response speed of the domain name, and the continuous stability rate of the domain name.

7. The method according to claim 6, wherein, the method further includes: Obtain the events to be executed by the main thread, and determine the execution order of each event to be executed. At least one of the events to be executed includes an update event of the domain name list; When the main thread executes the time according to the execution order, perform timing, and determine whether the update event is executed after the timing duration exceeds a preset duration; If the update event is not executed, notify the main thread to jump and execute the update event according to the execution order. When the update event is executed, it is used to update the available domain names in the dynamic domain name list according to the domain name data of each available domain name.

8. The method according to any one of claims 1-7, wherein, The re-initiation of the resource request according to the target disaster tolerance policy includes: Determine whether a registration completion notification is received. The registration completion notification is used to indicate that the target process has completed registration. The target process is used to re-initiate a resource request according to the target disaster tolerance policy when the resource request initiated by the main thread fails; If the registration completion notification time is not received, intercept the resource request of the client through the resource interception center in the main thread; Use the temporary disaster tolerance policy pre-configured for the main thread as the target disaster tolerance policy, and re-initiate a resource request according to the temporary disaster tolerance policy.

9. The method according to claim 8, wherein, The re-initiation of the resource request according to the temporary disaster tolerance policy includes: Obtain the type of the resource currently requested and the pre-configured backup domain name; According to the type of the resource, determine the replacement method of the target domain name in the resource request; According to the replacement method, replace the target domain name with the pre-configured backup domain name to re-initiate a resource request.

10. A processing device for resource requests, wherein, it includes: A process registration module, configured to obtain a process registration request initiated by the main thread of the client, and call the registration layer of the target process to perform process registration; A domain name list processing module, configured to obtain a target domain name list from the main thread of the client, call the domain name policy layer of the target process of the client to mark the target domain name list, and store the marked target domain name list in the data layer of the target process. The target domain name list includes at least one domain name and a mark for indicating whether the domain name is available; A resource interception module, which is used to call the disaster tolerance layer of the target process to intercept the resource request when the main thread initiates a resource request, and determine whether the resource request result of the resource request is a request failure according to the target domain name list of the data layer; A policy determination module, which is used to re-initiate a resource request according to the target disaster tolerance policy if the resource request result is a request failure; A result return module, which is used to obtain the resource request result with a successful request and return it to the main thread.

Images