Retry method and system for remote resource request failure
By using monkey patching technology and retry request adapter in the micro front-end architecture, the resource loading failure caused by network instability is solved, and the high reliability of resource requests and user experience is improved.
Patent Information
- Application Number
- CN202411902181.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-23
- Publication Date
- 2025-04-25
AI Technical Summary
In the scenario of micro front-end architecture and dynamic resource requests, resource loading failure caused by network instability leads to white screen on the page, invisible or inability to interact with the interface.
Through monkey patching technology, a retry request adapter is introduced, and a logical retry processing module based on Promise is used to intelligently decide whether to retry, and control the number of retry times and intervals.
It effectively improves the robustness and user experience of resource requests, reduces the failure rate caused by network fluctuations or server abnormalities, and ensures the stability and reliability of the system.
Smart Images
Figure CN119884516A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer technology, and in particular to a technical direction of a fetch resource request in a micro-frontend scenario, or a dynamic resource loading request of a non-micro-frontend fetch request, and in particular to a retry method and system for a failed remote resource request. Background Art
[0002] In the micro-frontend architecture, HTML is the cornerstone of the page structure, and its successful loading is a prerequisite for the normal display of the page. However, when the network environment is unstable, the loading of HTML resources will fail, which will directly cause the entire page to display a white screen. This phenomenon is attributed to the browser's inability to build a DOM tree when it cannot parse valid HTML content, and thus cannot render any page elements. Non-micro-frontend scenarios are similar to micro-frontends. Traditional single-page applications will also face a white screen problem when HTML resources fail to load. The lack of HTML makes it impossible for the browser to build a DOM and thus cannot display any content.
[0003] JavaScript resources are usually responsible for dynamic interaction and interface rendering in micro frontends. When these resources fail to load due to network problems, although the basic structure of the page (built by HTML) still exists, the functions and interface components that rely on JavaScript will not work properly, resulting in some interfaces being invisible or unable to interact. Non-micro frontend scenarios are similar to micro frontends. Failure to load JavaScript resources will also cause some interface functions to fail, which is manifested as some interfaces being invisible or unable to respond to user operations. This is because many dynamic content and interaction logic rely on the execution of JavaScript.
[0004] The CSS style sheet is responsible for defining the visual presentation of the page. In the micro-frontend architecture, if the CSS resource fails to load, although the HTML and JavaScript of the page have been successfully loaded, the style of the page will be abnormal, such as chaotic layout, color loss, etc., affecting the user experience. At this time, although part of the interface is visible, its display effect is far from expected. The non-micro-frontend scenario is similar to the micro-frontend. The problem of loading CSS resources in non-micro-frontend applications will also cause interface display abnormalities. Although the structure and functions of the page are complete, the lack of style will seriously affect the user's visual experience.
[0005] In view of the above analysis, the core technical challenge currently faced is how to effectively deal with the problem of resource loading failure caused by network instability in the scenario of micro-frontend architecture and dynamic resource request.
[0006] To this end, the present invention proposes a retry method and system for remote resource request failure. Summary of the invention
[0007] In view of this, the present invention hopes to provide a retry method and system for remote resource request failures to solve or alleviate the technical problems existing in the prior art, that is, how to solve the problem of retrying in micro frontends or when dynamic resource requests fail, or how to implement silent retry of remote resources in a non-invasive manner through engineering means. The technical solution of the present invention is implemented as follows:
[0008] First, the retry method for failed remote resource requests:
[0009] 1. Overview:
[0010] The present invention aims to realize automatic retry of failure situations occurring in the resource request process through non-intrusive technical means. The monkey patching mechanism is used to dynamically intercept and modify the behavior of resource requests, rather than directly modifying the original code. By introducing a retry request adapter, this solution integrates a Promise-based logical retry processing module while maintaining the consistency of the external interface. This module can intelligently decide whether to retry, and how to control the number and interval of retries based on preset configurations and context information. When a resource request fails, the retry logic is automatically triggered until the request succeeds or the number of retries is exhausted. Regardless of the request result, the solution ensures that the response result is properly processed and the relevant resources are cleaned up, thereby ensuring the stability and reliability of the system. In this way, the robustness and user experience of resource requests are effectively improved, and the failure rate caused by network fluctuations or server abnormalities is reduced.
[0011] (II) Technical solution:
[0012] To achieve the above technical objectives, the technical solution of the present invention is as follows; wherein when a resource request instruction is received and the request is accompanied by or triggers a retry scheme activation instruction (for example, by setting a specific request header, parameter or configuration item), the following operation steps are started.
[0013] 2.1 Step S1, intercept resource request:
[0014] When a resource request is issued, the monkey patching mechanism is used to intercept the request, rather than traditionally calling a native resource loader (such as fetch) to intercept the request.
[0015] 2.1.1 Step S100, import the target module or function:
[0016] Import modules containing resource request functions (such as fetch) using the monkey patching mechanism. For example, in JavaScript, fetch is globally available, but is mainly used in some frameworks or libraries to be encapsulated in a specific module.
[0017] 2.1.2 Step S101, read the predefined replacement function:
[0018] The replacement function executes the logic of the original resource request function and adds interception logic based on it.
[0019] like:
[0020]
[0021] 2.1.3 Step S102, replace the original function:
[0022] Use the monkey patching mechanism to replace the original resource request function with a custom replacement function, including modifying the attributes of the module or object.
[0023] Exemplarily, in JavaScript, this is achieved by directly modifying the global object (window or global) or the object exported by the module;
[0024] Among them, since fetch is a global object in the browser, it is recommended to encapsulate the fetch call in the Promise chain or async / await syntax.
[0025] For situations where all fetch calls need to be intercepted, this can be done in the browser or in a network request interception library (such as node-http-proxy in Node.js).
[0026] 2.2 Step S2, initialize the retry request adapter:
[0027] The retry request adapter is initialized according to the preset configuration and / or context information; the retry request adapter internally includes a Promise-based logical retry processing module.
[0028] 2.2.1 Step S200, initializing the retry request adapter:
[0029] S2000, import necessary dependencies:
[0030] Import the Promise library (optional, as modern JavaScript environments have built-in Promise support);
[0031] Import or define primitive functions for initiating resource requests (such as fetch);
[0032] Import or define helper functions for handling errors and retry logic;
[0033] S2001, configuration initialization: initializing the configuration of the retry request adapter according to a preset configuration file, environment variables or context information; the configuration includes the number of retries, retry interval, request timeout settings and / or specific error handling strategies.
[0034] S2002, creating a retry request adapter instance: creating an instance of a retry request adapter using configuration information.
[0035] 2.2.2 Step S201, activating the logic retry processing module, the working steps include:
[0036] S2010, encapsulate the original request: the retry request adapter maintains a reference to the original request function; when a request needs to be initiated, the adapter calls the original request function and wraps it in a Promise;
[0037] S2011, initiate a request and monitor the result: use Promise's then and catch methods to monitor the result of the request; if the request is successful, the result is returned; if the request fails, the retry logic is entered.
[0038] S2012, retry logic: In the catch block, decide whether to initiate a retry based on the configured number of retries and retry interval; if there are still retries, wait for the specified retry interval before initiating the request again;
[0039] Each retry will update the retry counter; if the number of retries is exhausted or other stop conditions are reached (such as request timeout), an error is thrown or a failed Promise is returned;
[0040] S2013, process the retry results: for each retry result, the same then logic and catch logic are used for processing; if the retry is successful, the result is returned and the retry process ends; if the retry fails and the stop condition is met, the final error handling logic is executed.
[0041] 2.3 Step S3, execute resource request:
[0042] The retry request adapter uses its internal logic to retry the processing module to initiate a resource request. At this point, the request looks the same as the native request from the outside, but the retry logic is already included internally.
[0043] 2.3.1 Step S300, prepare request parameters:
[0044] Determine the request URL: Determine the requested URL based on the address of the required resource;
[0045] Set request options: According to the request type (such as GET, POST, etc.) and the data to be transferred, set the request options, including the request header and request body.
[0046] 2.3.2 Step S301, call the retry request adapter:
[0047] Create an adapter instance: If you have not yet created an instance of the retry request adapter, you need to create an instance based on the preset configuration or context information;
[0048] Initiate a request: Use the request method of the retry request adapter to initiate a resource request. At this time, the logic retry processing module inside the adapter will be responsible for handling the retry logic of the request.
[0049] 2.3.3 Step S302, processing request result:
[0050] Use the then method of Promise to listen for the response when the request is successful. When the response is successful, get and process the response data. Use the catch method of Promise to listen for errors when the request fails. When an error occurs, handle it according to the error type and the preset error handling strategy, including displaying error information and recording error logs.
[0051] 2.3.4 Step S303, execution of retry logic (processed internally by the adapter):
[0052] Inside the adapter, the logical retry processing module automatically handles the request retry according to the preset retry configuration (including the number of retries and the retry interval);
[0053] If the request fails and the retry conditions are met, the module will automatically wait for the specified retry interval and then initiate the request again;
[0054] At this point, the retry process is transparent to the outside world, that is, the outside world only needs to call the request method of the adapter without having to worry about the internal retry logic.
[0055] 2.3.5Logical retry module (javascript):
[0056]
[0057]
[0058] 2.4 Step S4, request result processing:
[0059] Wait for the response of the resource request. If the request is successful, the response result is returned directly and the end state is entered. If the request fails, decide whether to retry according to the preset retry strategy (such as the number of retries and / or the retry interval, etc.).
[0060] 2.4.1 Step S400, waiting for a response to a resource request:
[0061] If it is a synchronous request, the code will block in the waiting for response phase to wait for the response until the response is received or a timeout occurs; if it is an asynchronous request, a Promise or callback is used to wait for the response.
[0062] 2.4.2 Step S401, determine the request result:
[0063] For a successful request: check the response status code or the response content to determine whether the request is successful; if the request is successful, directly return the response result; at this time, enter step S5 to end the current request processing flow.
[0064] For request failure: check the response status code or capture the exception to determine whether the request fails; if the request fails, go to step S402.
[0065] 2.4.3 Step S402, retry judgment and processing:
[0066] According to the preset retry strategy (such as the number of retries, retry interval, etc.), determine whether the current request meets the retry conditions; if so, go to step S5.
[0067] 2.5 Step S5, retry logic execution:
[0068] If the decision is to retry, the Retry Request Adapter decrements the retry count counter and waits for a retry interval if necessary.
[0069] Then, step S3 and step S4 are repeatedly executed until the request succeeds or the number of retries is exhausted.
[0070] After exhaustion, the final response needs to be processed regardless of whether the request ultimately succeeds or fails (and no more retries are performed), so the response data, error handling, and / or cleanup of resources need to be returned to the caller.
[0071] 2.5.1 Step S500, update the retry count counter:
[0072] The retry request adapter decrements the retry count counter to keep track of the number of retries that have been made so far.
[0073] 2.5.2 Step S501, repeat steps S3 and S4:
[0074] After waiting for the retry interval to end, step S3 (executing resource request) and step S4 (processing request result) are repeated. This process forms a loop until the request succeeds or the number of retries is exhausted.
[0075] When the request succeeds, the response data is returned to the caller. When the number of retries is exhausted and the request still fails, it is processed according to the preset error handling strategy, including returning error information and recording error logs.
[0076] Regardless of whether the request succeeds or fails, necessary resource cleanup is required, including closing the network connection and releasing memory.
[0077] 2.5.3 Step S502, end the retry logic
[0078] When the request succeeds or the number of retries is exhausted, the execution of the retry logic ends and the final response result or error information is returned to the caller.
[0079] (III) Mechanism for solving technical problems:
[0080] The present invention dynamically intercepts resource requests by using monkey patching technology. At the moment when a resource request is about to be issued, the native resource loader (such as fetch) is not directly called, but processed through an intermediate layer - a retry request adapter. This adapter contains a Promise-based logical retry processing module, which is responsible for implementing the retry logic.
[0081] When a resource request fails, the logical retry processing module intelligently decides whether to retry based on the preset configuration and context information. These configurations include parameters such as the number of retries and the retry interval, which are used to control the behavior of the retry. If a retry is decided, the adapter decrements the retry counter, waits for a certain retry interval as needed, and then initiates the resource request again. This process is repeated until the request succeeds or the number of retries is exhausted. Throughout the process, the external code remains unchanged in calling the resource request, so non-invasive modifications are achieved. At the same time, since the retry logic is implemented inside the adapter, it will not have any impact on the business logic.
[0082] Ultimately, no matter what the request result is, the solution will ensure that the response result is properly processed and the relevant resources are cleaned up. In this way, the present invention effectively improves the robustness and user experience of resource requests and reduces the failure rate caused by network fluctuations, server abnormalities, or temporary unavailability of resources.
[0083] Second, the retry system for failed remote resource requests:
[0084] like Figure 5As shown, the system is used to implement the above-mentioned retry method and system for remote resource request failure, which includes:
[0085] (1) The user interface layer is responsible for interacting with the user: receiving user input and displaying system output.
[0086] (2) Business logic layer for implementing resource request and retry mechanisms, including:
[0087] (2.1) Resource request module responsible for initiating requests for remote resources: responsible for encapsulating the details of resource requests, such as using the fetch API or other network libraries to initiate HTTP requests; and providing interfaces for upper-level modules to call to obtain remote resources;
[0088] (2.2) The retry mechanism module is responsible for automatically retrying when a request fails: it monitors the results of resource requests and decides whether to initiate a retry based on preset strategies (such as the number of retries, intervals, etc.); and maintains the retry status, such as a retry counter.
[0089] After initiating the request, the resource request module passes the result (success or failure) to the retry mechanism module. The retry mechanism module decides whether to initiate a retry based on the request result and performs the retry operation through the resource request module.
[0090] (3) The data access layer is responsible for interacting with the database or other persistent storage to obtain or store data; it includes:
[0091] (3.1) Configuration management module responsible for managing system configuration information: including configuration of retry strategies; and providing interfaces for other modules to query configuration information;
[0092] (3.2) Error handling module responsible for handling error situations when request fails or system exceptions occur: It can work together with the retry mechanism module to decide under what circumstances to retry and under what circumstances to give up retrying and record errors.
[0093] Wherein, the resource request module (or retry mechanism module) queries the configuration information of the retry strategy from the configuration management module when necessary.
[0094] The resource request module notifies the error handling module when the request fails. The error handling module decides whether to record the error, notify the user, or take other measures based on the nature of the error and the status of the retry mechanism module.
[0095] (4) Infrastructure layer including network, server and storage device hardware resources.
[0096] Compared with the prior art, the present invention has the following beneficial effects:
[0097] 1. Improve the reliability of resource requests: Through the automatic retry mechanism, the present invention can effectively deal with problems such as network fluctuations, server anomalies or temporary unavailability of resources, thereby improving the reliability and success rate of resource requests. When a resource request fails, the user does not need to perform any operation, and the solution will automatically retry, thereby reducing the user's waiting time and operation burden and optimizing the user experience.
[0098] 2. Non-intrusive modification: The present invention uses monkey patching technology to dynamically intercept resource requests without directly modifying the original code, thus achieving non-intrusive integration, making the solution more flexible and able to easily adapt to different projects and scenarios.
[0099] 3. Reduce maintenance costs: Since the solution implements the retry logic inside the adapter, it will not have any impact on the business logic. This means that when the business logic changes, there is no need to make additional modifications and maintenance to the retry logic, thereby reducing maintenance costs. At the same time, it supports preset configuration and context information, allowing developers to flexibly adjust the retry strategy according to actual needs, such as the number of retries, retry interval, etc. This makes the solution more flexible and customizable. BRIEF DESCRIPTION OF THE DRAWINGS
[0100] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0101] Figure 1 It is a schematic diagram of the method flow of the present invention;
[0102] Figure 2 is a schematic diagram of the method flow of step S1 of the present invention;
[0103] Figure 3 is a schematic diagram of the method flow of step S3 of the present invention;
[0104] Figure 4 This is a schematic diagram of the method flow of step S4 of the present invention;
[0105] Figure 5 It is a schematic diagram of the system composition of the present invention. DETAILED DESCRIPTION
[0106] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are described in detail below in conjunction with the accompanying drawings. In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar improvements without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below;
[0107] It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.
[0108] Explanation of relevant terms:
[0109] (1) Resource request: a request initiated by a remote server to obtain data or resources;
[0110] (2) Monkey patching mechanism: a technical means of dynamically modifying the behavior of existing code, which can add or modify functions without changing the source code;
[0111] (3) Resource loader (fetch): The API provided by the browser to initiate network requests and obtain responses;
[0112] (4) Preset configuration: Parameters or options set in advance to control the behavior of the program;
[0113] (5) Preset context information: the environment or state information provided during execution, which is used to determine the specific behavior of the program;
[0114] (6) Adapter: An intermediate layer used to convert incompatible interfaces or functions so that they can work together;
[0115] (7) Promise: An asynchronous processing mechanism in JavaScript that represents a future completed or failed operation and its results;
[0116] (8) Logical retry processing module: a functional module responsible for implementing the retry logic, usually including controls such as the number of retries and intervals;
[0117] (9) Retry logic: the process of retrying a request according to certain rules when a request fails;
[0118] (10) Response result: data or status information returned by the server in response to the resource request;
[0119] (11) End state: the state when the program is completed or reaches a certain termination condition;
[0120] (12) Decrementing retry counter: A counter used to record and control the number of retries, which decrements after each retry.
[0121] Embodiment 1: Figures 1 to 4 As shown, this embodiment will disclose a retry method for failed remote resource requests in an online car-hailing platform; assume a micro-frontend architecture of a traditional online car-hailing platform, which includes multiple independently deployed and maintained micro-frontend applications. These applications need to exchange data through network requests, such as obtaining driver location, order information, etc. However, network requests sometimes fail for various reasons (such as network fluctuations, temporary unavailability of the server, etc.). In order to solve this phenomenon, the execution steps of the retry method include the following steps S1 to S5.
[0122] In this embodiment, regarding step S1: intercepting a resource request: before a resource request is issued, the request is intercepted to add a retry logic.
[0123] Specifically, step S100: import the target module or function. In our online car-hailing platform, network requests are initiated based on a specific HTTP request library (such as axios). We need to find this library and import it.
[0124] Specifically, step S101: define a replacement function, which will execute the logic of the original resource request function and add interception logic on this basis.
[0125] For example, this is achieved using the interceptor function of axios.
[0126] Specifically, step S102: replace the original function. Use the monkey patching mechanism to replace the original resource request function with a custom replacement function.
[0127] For example, in axios, an interceptor is set to "intercept" requests and responses, thereby adding retry logic without modifying the original function.
[0128] In this embodiment, regarding step S2: initializing the retry request adapter: initializing the retry request adapter according to a preset configuration, the adapter will be responsible for processing the retry logic of the request.
[0129] Specifically, step S200: import necessary dependencies and create an instance of the retry request adapter.
[0130] For example, the Promise library, the axios library, and auxiliary functions customized in the online car-hailing platform for handling errors and retry logic are imported.
[0131] Specifically, step S201: activating the logic retry processing module. In axios, the response and error processing functions of the interceptor are used to implement the retry logic.
[0132] Furthermore, the error type is checked in the error processing function, and a decision is made whether to initiate a retry based on a preset retry strategy (such as the number of retries, the retry interval, etc.).
[0133] In this embodiment, regarding step S3: executing resource request: using a retry request adapter to initiate a resource request and process the request result.
[0134] Specifically, step S300: prepare request parameters. Determine the URL and options of the request according to the address of the required resource and the request type (such as GET, POST, etc.).
[0135] Specifically, step S301: call the retry request adapter. Use the instance of axios to initiate a request and pass the prepared request parameters. At this time, if the request fails and meets the retry conditions, the interceptor of axios will automatically handle the retry logic.
[0136] Specifically, step S302: process the request result. Use the then and catch methods of Promise to monitor the request result. If the request is successful, the response data is returned; if the request fails and the number of retries has been exhausted, the final error handling logic is executed.
[0137] In this embodiment, regarding steps S4 and S5: request result processing and retry logic execution: decide whether to retry according to the request result, and process the logic in the retry process.
[0138] Specifically, in step S4: wait for a response to the resource request, and determine whether a retry is needed based on the response result.
[0139] Exemplarily, the request failure error is captured in the axios interceptor, and whether to initiate a retry is determined based on the error type and the preset retry strategy.
[0140] Specifically, in step S5: if a retry is decided, the retry counter is updated, and a certain retry interval is waited as needed. Then steps S3 and S4 are repeated until the request is successful or the retry times are exhausted. When the request is successful or the retry times are exhausted, the execution of the retry logic is terminated, and the final response result or error information is returned to the caller.
[0141] Embodiment 2: This embodiment further discloses an execution program of the retry method for failed remote resource requests in the online car-hailing platform as described in Embodiment 1, which is based on axios:
[0142]
[0143]
[0144]
[0145] In the above program, the automatic retry mechanism can reduce the number of request failures caused by network fluctuations, temporary server unavailability, etc., thereby improving the robustness of the system. Users do not need to manually refresh the page or re-initiate the request, the system will automatically try to restore the request, thereby improving the user experience.
[0146] By using the interceptor function of axios, we can add retry logic without modifying the original request function and implement a non-intrusive resource retry mechanism.
[0147] Among them, the retry strategy (such as the number of retries, retry interval, etc.) can be flexibly configured according to actual needs to meet the needs of different scenarios.
[0148] All the above embodiments only express the implementation methods of the relevant practical applications of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be based on the attached claims.
[0149] For those skilled in the art, it can be further appreciated that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.
[0150] At the same time, those skilled in the art can understand that all or part of the processes in all the above-mentioned embodiments can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).
Claims
1. A retry method for a failed remote resource request, characterized in that: When a resource request instruction is received, and the request is accompanied by or triggers a retry scheme activation instruction, the following steps are performed: S1, when a resource request is issued, the monkey patching mechanism is used to intercept the request; S2, initializing a retry request adapter according to a preset configuration and / or context information; the retry request adapter internally includes a Promise-based logic retry processing module; S3, the retry request adapter uses its internal logic retry processing module to initiate a resource request; S4, waiting for the response to the resource request. If the request is successful, the response result is directly returned and the end state is entered; if the request fails, whether to retry is determined according to the preset retry strategy; S5, if it is decided to retry, the retry request adapter will decrement the retry count counter; repeat S3 to S4 until the request is successful or the retry count is exhausted.
2. The retry method according to claim 1, characterized in that: In S1, when the monkey patching mechanism is activated, the following steps are performed: S100, importing a module including a resource request function; S101, the replacement function executes the logic of the original resource request function, and adds interception logic on this basis; S102, using a monkey patching mechanism to replace the original resource request function with a custom replacement function, including modifying the attributes of a module or an object.
3. The retry method according to claim 2, characterized in that: In S102, if fetch is a global object in the browser, the fetch call is encapsulated in a Promise chain or async / await syntax; In the case where all fetch calls need to be intercepted, S102 is implemented on the browser side or in a network request interception library.
4. The retry method according to claim 1, characterized in that: In S2, the initialization of the retry request adapter includes: S2000, import or define the Promise library, the original function for initiating resource requests, and the auxiliary functions for handling errors and retry logic; S2001, initializing the configuration of the retry request adapter according to a preset configuration file, environment variable or context information; the configuration includes the number of retries, retry interval, request timeout setting and / or a specific error handling strategy; S2002, create an instance of a retry request adapter using the configuration information.
5. The retry method according to claim 4, characterized in that: In S2, the working steps of the logic retry processing module include: S2010, the retry request adapter maintains a reference to the original request function internally; when a request needs to be initiated, the original request function is called and wrapped in a Promise; S2011, initiate a request and monitor the result; if the request is successful, the result is returned; if the request fails, enter the retry logic; S2012, retry logic: In the catch block, decide whether to initiate a retry based on the configured number of retries and retry interval; if there are still retries, wait for the specified retry interval before initiating the request again; S2013, the same then logic and catch logic are used to process the result of each retry; if the retry is successful, the result is returned and the retry process ends; if the retry fails and the stop condition is reached, the final error handling logic is executed.
6. The retry method according to claim 1, 2 or 4, characterized in that: In S3, the execution method of the retry request adapter includes: S300, determining the request URL and setting request options; S301, create an adapter instance and initiate a request; S302, use the then method of Promise to monitor the response when the request is successful; when the response is successful, obtain and process the response data; use the catch method of Promise to monitor the error when the request fails. When an error occurs, handle it according to the error type and the preset error handling strategy; S303, inside the adapter, the logic retry processing module automatically processes the request retry according to the preset retry configuration. If the request fails and meets the retry conditions, the module will automatically wait for the specified retry interval and initiate the request again.
7. The retry method according to claim 6, characterized in that: The implementation method of S4 includes: S400, for synchronous requests, the code will be blocked in the waiting stage to wait for the response; for asynchronous requests, use Promise or callback to wait for the response; S401, if the request is successful, directly return the response result; if the request fails, go to step S402; S402, judging whether the current request satisfies the retry condition according to the preset retry strategy; if so, proceeding to step S5.
8. The retry method according to claim 6, characterized in that: In said S5, when the request is successful, response data is returned to the caller; When the request succeeds or the number of retries is exhausted, the execution of the retry logic ends; Return the final response result or error information to the caller; Regardless of whether the request succeeds or fails, necessary resource cleanup is required, including closing the network connection and releasing memory.
9. A system for implementing the retry method according to any one of claims 1 to 8, characterized in that: The system comprises: The user interface layer responsible for interacting with the user; Business logic layer for implementing resource requests and retry mechanisms; The data access layer is responsible for interacting with the database to obtain or store data; The infrastructure layer includes network, server, and storage hardware resources.
10. The system according to claim 9, characterized in that: The business logic layer includes: A resource request module responsible for initiating requests for remote resources; A retry mechanism module responsible for automatically retrying when a request fails; The data access layer includes: An error handling module responsible for handling request failures; Configuration management module responsible for managing configuration information.