Request processing

Abstract

The present disclosure discloses a request processing method and system, an electronic device, a storage medium, and a program product. The method comprises: receiving an application request; for a call to any application in an application call chain corresponding to the application request, determining a current remaining timeout duration of the application request, wherein the application call chain refers to the sequence of application calls to be completed for processing the application request, and the remaining timeout duration is the time remaining before the application request times out; and when it is determined, on the basis of the remaining timeout duration, that processing of the application request has not timed out, sending a call request to the any application.

Description

[0001] Request for processing of cross-references of related applications

[0002]

[0001] This disclosure claims priority to Chinese patent application No. 202410371452.4, filed on March 28, 2024, entitled “Request Processing Method, System, Electronic Device, Storage Medium, and Program Product,” the entire text of which is incorporated herein by reference.

[0003]

[0002] The present disclosure relates to the field of computer technology, and more particularly to request processing.

[0004] In a distributed system, user requests are processed by calling applications layer by layer, generating responses and returning them to the user. For example, after a user request is forwarded to application A, application A calls application B to complete a certain operation based on the user request. Then, application A calls application C to complete another operation based on the user request and / or the operation results returned by application B. This continues in this manner until application A generates a response based on the operation results returned by applications B, C, and so on, and returns it to the user. Therefore, from the perspective of a distributed system, the processing of user requests forms a call chain, and the time consumed by a request as perceived by the distributed system is the call time of the entire call chain.

[0005]

[0004] Currently, the distributed system performs timeout perception based on the timeout time set in the user request. When the timing time reaches the timeout time due to slow processing of an application on the call link, a timeout notification is returned to the user.

[0006]

[0005] However, in actual usage scenarios, although the application processing slows down, it still returns normal operation results. Therefore, the application that receives the user request will make subsequent calls on the call chain after receiving the operation results of the slowed application. However, this subsequent call is actually a redundant call, which not only increases the processing burden on the subsequent calling application, but also reduces the request processing efficiency.

[0007]

[0006] The present disclosure provides a request processing method, system, electronic device, storage medium and program product.

[0008]

[0007] A first aspect of the present disclosure proposes a request processing method, the method comprising: receiving an application request; the remaining timeout is the remaining time from the timeout of the application request; for a call of any application in an application call link corresponding to the application request, determining the current remaining timeout of the application request; the application call link is the order of application calls that need to be completed to process the application request, and the remaining timeout is the remaining time from the timeout of the application request; and if it is determined based on the remaining timeout that the processing of the application request has not timed out, sending a call request to the any application.

[0009]

[0008] A second aspect of the present disclosure proposes a request processing system, which includes a user terminal and a distributed system, and the distributed system includes multiple applications, each of which is used to provide different services: the user terminal is used to send a service request to the distributed system; the distributed system is used to forward the service request to the target application called by the service request, and the target application determines the current timeout remaining time of the service request for calling any application in the application call link corresponding to the service request, and sends a call request to any application if it is determined that the processing of the service request has not timed out based on the timeout remaining time; wherein the application call link is the application call sequence that needs to be completed to process the application request, and the timeout remaining time is the remaining time of the application request before timeout.

[0010]

[0009] A third aspect of the present disclosure provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in the first aspect above.

[0011]

[0010] A fourth aspect of the present disclosure provides a computer-readable storage medium having a computer program stored thereon, the program being executed by a processor to implement the method described in the first aspect above.

[0012]

[0011] An embodiment of the fifth aspect of the present disclosure provides a computer program product, including a computer program, wherein the computer program is executed by a processor to implement the method described in the first aspect.

[0013] Based on the request processing method described in the first aspect above, the present disclosure has at least the following beneficial effects or advantages: upon receiving an application request, the current remaining timeout of the application request is determined for any application call in the application call chain corresponding to the application request. Based on the determined remaining timeout, it is pre-determined whether the processing of the application request has timed out. Only if it is determined that the timeout has not occurred will the call request be sent to any application. In this way, for any application call in the application call chain, the entire chain can sense the current remaining timeout of the application request. Only if the timeout has not occurred will the call proceed to the next application; otherwise, the call will not proceed to the next application. This avoids the increased processing burden of executing unnecessary calls after a timeout, thereby improving request processing efficiency.

[0014]

[0013] The above description is only an overview of the technical solution of the present disclosure. In order to more clearly understand the technical means of the present disclosure, it can be implemented according to the contents of the description. In order to make the above and other purposes, features and advantages of the present disclosure more obvious and easy to understand, the following specific embodiments of the present disclosure are specifically cited.

[0015]

[0014] The drawings described herein are intended to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The illustrative embodiments of the present disclosure and their descriptions are intended to explain the present disclosure and do not constitute an improper limitation of the present disclosure. In the drawings:

[0016]

[0015] FIG1 is a schematic diagram showing a processing method of a user request according to an exemplary embodiment;

[0017]

[0016] FIG2 is a schematic diagram of an application call scenario requested by a user according to an exemplary embodiment;

[0018]

[0017] FIG3 is a flow chart of an embodiment of a request processing method according to an exemplary embodiment;

[0019] FIG4 is a schematic diagram of a request processing for a normal return response according to an exemplary embodiment;

[0020]

[0019] FIG5 is a schematic diagram illustrating a request processing for returning an error notification according to an exemplary embodiment;

[0021]

[0020] FIG6 is a schematic diagram of a multi-layer call request processing according to an exemplary embodiment;

[0022]

[0021] FIG7 is a schematic diagram of request processing for predicting timeout according to an exemplary embodiment;

[0023]

[0022] FIG8 is a schematic structural diagram of a request processing device according to an exemplary embodiment;

[0024] FIG9 is a schematic diagram of a hardware structure of an electronic device according to an exemplary embodiment;

[0025]

[0024] FIG10 is a schematic diagram showing the structure of a storage medium according to an exemplary embodiment.

[0026]

[0025] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. When the following description refers to the drawings, like numbers in different drawings represent like or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present disclosure. Rather, they are merely examples of systems and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.

[0027]

[0026] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the disclosure. As used in this disclosure and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0028] It should be understood that although the present disclosure may employ terms such as first, second, and third to describe various types of information, such information should not be limited to these terms. These terms are merely used to distinguish information of the same type from one another. For example, without departing from the scope of the present disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the term "if" as used herein may be interpreted as "at the time of," "when," or "in response to a determination."

[0029]

[0028] As mentioned above, a single user call actually results in multiple calls in the distributed system. As shown in FIG1 , when a user calls the interface of application A, the distributed system first forwards the request to application A. Since application A depends on applications B, C, and D, and application C depends on application E, application A calls the interface of application B to complete a certain operation. Application A then calls the interface of application C to complete a certain operation, and application C needs to call application E to complete the operation. Finally, application A calls application D to obtain the final processing result and returns it to the user.

[0030]

[0029] From this perspective, from the perspective of application A, the call chain formed by application A completing request processing is application B - application C - application D, while from the perspective of the distributed system, the call chain formed by completing request processing is application A - application B - application C - application E - application D. Therefore, the call chain can be understood as the order of application calls that need to be completed to process the received request.

[0031]

[0030] As can be seen from FIG. 1 , the time taken for a distributed system to perceive a request is the time taken to complete the calls of the five applications: application A, application B, application C, application E, and application D.

[0032] The timeout detection principle of a distributed system is shown in FIG2 . When a user calls application A, a timeout of 800 milliseconds is set in the request. Upon receiving the user request, the distributed system begins to detect timeouts based on this timeout. Application A takes 20 milliseconds to complete its call to application B. When application A calls application C, application C in turn calls application E. When application E's processing slows, application C takes 1000 milliseconds to complete its call to application E. Adding the time consumed by application C itself, application A takes 1020 milliseconds to complete its call to application C. During application A's call to application C, the distributed system detects the 800 millisecond timeout and returns a timeout notification to the user. After application C returns a normal result to application A, application A continues to call application D and returns the result returned by application D to the user, even though the result returned by application A is no longer important to the user. This shows that application A's call to application D is redundant.

[0033] To address the above technical issues, the present disclosure proposes a request processing method. For any application in a distributed system, upon receiving an application request, the method determines the current remaining timeout of the application request for any application in the application call chain corresponding to the application request. Based on the determined remaining timeout, the method determines in advance whether the processing of the application request has timed out. Only when it is determined that the processing has not timed out will the method send the call request to any application. In this way, for any application call in the application call chain, the entire chain can sense the current remaining timeout of the application request. Only when the processing has not timed out will the method continue to call the next application. Otherwise, the method will not continue to call the next application. This avoids the increased processing burden of executing unnecessary calls after a timeout, thereby improving request processing efficiency.

[0034]

[0033] The following describes in detail the technical solution of the present invention and how the technical solution of the present invention solves the aforementioned technical problems using specific embodiments. The several specific embodiments listed can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The following describes the embodiments of the present invention in detail with reference to the accompanying drawings.

[0035]

[0034] FIG3 is a flow chart of an embodiment of a request processing method according to an exemplary embodiment. This embodiment uses any application in a distributed system as an execution subject to illustrate the request processing method. As shown in FIG3, the method includes the following steps 301 to 303.

[0036]

[0035] Step 301: Receive an application request.

[0037]

[0036] Step 302: For any application call in the application call link corresponding to the application request, determine the current timeout remaining time of the application request; wherein the application call link is the application call sequence that needs to be completed to process the application request, and the timeout remaining time is the remaining time of the application request before timeout.

[0038]

[0037] Step 303: If it is determined based on the determined remaining timeout that the processing of the application request has not timed out, a call request is sent to the any application.

[0039] In the embodiments of the present disclosure, the received application request can be understood as a call sent by an upper-layer application or a call sent by a user terminal. Furthermore, a call request sent to any application can be understood as a call sent to a lower-layer application. Therefore, the terms "application request" and "call request" in the embodiments of the present disclosure both refer to calls to an application, and the two descriptions are used only to distinguish between received calls and outgoing calls.

[0040] The application call chain represents the sequence of application calls required to process an application request. As shown in FIG1 , taking application A receiving an application request as an example, the application call chain corresponding to the application request in application A is application B → application C → application D. Taking application C receiving an application request as an example, the application call chain corresponding to the application request in application C is application E.

[0041] The remaining time before timeout represents the current remaining time until the application request times out. The remaining time before timeout is determined each time a call is executed according to the application call link corresponding to the application request. In other words, the remaining time before timeout changes dynamically on the application call link.

[0042]

[0041] Any application refers to the application that needs to be called currently. If it is determined based on the determined remaining timeout time that the processing of the application request has not timed out, it means that the call of the subsequent application in the application call chain can still be completed, so the call request can be sent to the any application.

[0043]

[0042] Exemplarily, in application A shown in FIG1 , application A receives an application request, and the application call link is application B-application C-application D. First, application A determines the current remaining timeout of the application request for the call to application B, and if it is determined based on the determined remaining timeout that the processing of the application request has not timed out, sends a call request to application B; then, application A determines the current remaining timeout of the application request for the call to application C, and if it is determined based on the determined remaining timeout that the processing of the application request has not timed out, sends a call request to application C; finally, application A determines the current remaining timeout of the application request for the call to application D, and if it is determined based on the determined remaining timeout that the processing of the application request has not timed out, sends a call request to application D, thereby completing the processing of the application request.

[0044] At this point, the request processing flow shown in FIG. 3 is completed. For any application in the distributed system, when an application request is received, the current remaining timeout of the application request is determined for any application call in the application call chain corresponding to the application request. Based on the determined remaining timeout, it is determined in advance whether the processing of the application request has timed out. Only when it is determined that the timeout has not occurred will the call request be sent to any application. In this way, for any application call in the application call chain, the entire chain can sense the current remaining timeout of the application request. If the timeout has not occurred, the call will continue to the next application. Otherwise, the call will not continue to the next application. This avoids the increase in processing burden caused by the execution of unnecessary calls after the timeout, thereby improving request processing efficiency.

[0045]

[0044] In some embodiments of the present disclosure, the process of determining the current remaining timeout of the application request in the above-mentioned step 302 includes: when the any application is the first application in the application call chain, using the time transfer field in the application request to determine the current remaining timeout of the application request; when the any application is not the first application in the application call chain, obtaining the call time consumed when calling the previous application of the any application, using the call time consumed to adjust the remaining timeout determined when calling the previous application, and using the adjusted remaining timeout as the current remaining timeout of the application request.

[0046]

[0045] The time transfer field indicates the field for transferring the remaining time of the timeout when the sender of the application request sends the application request, which can be understood as a field added by the sender of the application request in the application request.

[0047]

[0046] The previous application of any application can be understood as the application that is located before any application in the application call link, that is, the application that completed the call last time.

[0048]

[0047] The call time is the time it takes for the previous application to initiate a call and receive a response.

[0049]

[0048] Obtaining the call duration generated when calling the previous application of any application, specifically by: obtaining the sending time when sending a call request to the previous application, and obtaining the receiving time when receiving a response returned by the previous application, and then using the difference between the receiving time and the sending time as the call duration of the previous application. The response is a response to the call request.

[0049] In this embodiment, if any application is the first application in the application call chain, it indicates that a call has not yet been initiated to the applications in the application call chain. Therefore, the current remaining timeout is determined by using the time transfer field in the application request. If any application is not the first application in the application call chain, it indicates that a call has already been completed to the application preceding the application in the application call chain. Therefore, the remaining timeout determined when calling the previous application is adjusted by using the call duration of the previous application of the any application to obtain the current remaining timeout. This allows full-link perception of the current remaining timeout for any application call in the application call chain.

[0050]

[0050] Optionally, the call time is used to adjust the timeout remaining time determined when calling the previous application, specifically by subtracting the call time from the timeout remaining time determined when calling the previous application to obtain the adjusted timeout remaining time.

[0051]

[0051] That is, each time an application call in an application call link is completed, the call time of this application call is used to deduct the timeout remaining time, thereby realizing the full link perception of the current timeout remaining time.

[0052]

[0052] For example, as shown in FIG4 , application A receives an application request. The application call link corresponding to the application request is application B-application C-application D. Therefore, application A completes processing of the application request according to this application call link. Application A uses the time transfer field in the application request to determine the remaining timeout_system_timetolive=800 milliseconds for the call of application B in the application call link. When application A completes the call of application B, the obtained call time of application B is 20 milliseconds. For the call of application C in the application call link, application A subtracts the call time of application B by 20 milliseconds from the remaining timeout_system_timetolive to determine the current remaining timeout_system_timetolive=780 milliseconds. When application A completes the call of application C, the obtained call time of application C is 110 milliseconds. For the call of application D in the application call link, application A subtracts the call time of application C by 110 milliseconds from the remaining timeout_system_timetolive. The current remaining timeout time _system_timetolive is determined to be 670 milliseconds. When application A completes the call to application D, the call time of application D is obtained to be 50 milliseconds. The remaining timeout time _system_timetolive is subtracted by 50 milliseconds, and _system_timetolive is equal to 620 milliseconds.

[0053]

[0053] For example, application C receives an application request. The application call link corresponding to the application request is application E. Therefore, application C uses the time transfer field in the application request to determine the remaining timeout, _system_timetolive, which is 780 milliseconds. After application C completes the call to application E, the time taken for the call to application E is 90 milliseconds. 90 milliseconds are subtracted from the remaining timeout, _system_timetolive, to obtain 690 milliseconds.

[0054]

[0054] In an optional implementation, the time transfer field in the application request is used to determine the current remaining timeout of the application request, specifically including: when the application request carries the time transfer field, using the field value corresponding to the time transfer field in the application request as the current remaining timeout of the application request; when the application request does not carry the time transfer field, obtaining the timeout setting time for the application request, and using the obtained timeout setting time as the current remaining timeout of the application request.

[0055]

[0055] In this embodiment, the time transfer field is used to indicate the remaining time of the timeout transmitted by the sender when sending the application request. Therefore, when the application request is received, the field value of the time transfer field in the application request can be directly used as the current remaining time of the timeout of the application request.

[0056]

[0056] In specific implementations, distributed link tracing technology can be used. Distributed link tracing technology refers to the generation of a unique identifier for a user request when it enters a distributed system. This identifier, in the form of an extended field, runs through each application call involved in the request, facilitating the tracing of the request's flow path and status between applications. Therefore, relying on distributed link tracing technology, a time transfer field can be added in the form of an extended field in the application request to pass the remaining time after the timeout to the application to be called.

[0057] Taking an HTTP (Hypertext Transfer Protocol) request as an example, a time transfer field is added to the request header using a key-value structure, where the time transfer field is a key and the field value is a value. For example, if the time transfer field is defined as _system_timetolive, then _system_timetolive is the key and the number representing the remaining time after the timeout is the value.

[0058]

[0058] Furthermore, in order to solve the problem that the sender does not transmit the time transfer field, if the application request does not carry the time transfer field, the timeout setting time for the application request is obtained, and the obtained timeout setting time is used as the timeout remaining time to play a fault tolerance role.

[0059] In a distributed system, each call between applications is configured with a timeout. Therefore, the timeout setting is the maximum waiting time set by the sender of the application request in the application request, that is, the maximum waiting time the sender of the application request will wait for the application request. For example, if application A calls application B, and the call sent by application A to application B exceeds the pre-configured timeout, application A will no longer wait for application B to return a result. Therefore, the timeout setting represents the maximum waiting time for a call between the two applications, while the remaining timeout is the remaining timeout for the user terminal.

[0060]

[0060] Taking application C in FIG. 1 as an example, when application C receives an application request sent by application A, if the application request carries a time transfer field, the corresponding field value is 800 milliseconds - 20 milliseconds = 780 milliseconds. Then, the remaining timeout time determined by application C is 780 milliseconds. Assuming that the timeout setting time configured by application A calling application C is 100 milliseconds, if the application request received by application C does not carry a time transfer field, then the remaining timeout time determined by application C is 100 milliseconds.

[0061] In some embodiments of the present disclosure, the process of sending a call request to any application in the above step 303 specifically includes: sending a call request including the current remaining timeout time of the application request to any application, so that the current remaining timeout time is passed downward each time the call is made, thereby realizing timeout awareness of the entire link.

[0061]

[0062] For example, as shown in FIG4 , taking application A as an example, the application call link corresponding to the application request is application B t application CT application D. Then, the call request sent by application A to application B includes a timeout remaining time_system_timetolive = 800 milliseconds, the call request sent by application A to application C includes a timeout remaining time_system_timetolive = 780 milliseconds, and the call request sent by application A to application D includes a timeout remaining time_system_timetolive = 670 milliseconds.

[0062]

[0063] In specific implementation, a time transfer field can be added to the call request in the form of an extended field to pass the current timeout remaining time to the application to be called. For example, a time transfer field can be added in a key-value structure, with the time transfer field as the key and the timeout remaining time as the field value.

[0063]

[0064] In some embodiments of the present disclosure, in step 303, determining whether processing of the application request has not timed out based on the current remaining timeout period is performed, if the remaining timeout period is greater than 0, then the processing of the application request is determined to have not timed out. Furthermore, if the remaining timeout period is less than or equal to 0, then the processing of the application request is determined to have timed out.

[0064]

[0065] In one example, as shown in FIG4 , application A receives an application request. Application A determines that the current remaining timeout of the application request, _system_timetolive, is 800 milliseconds, which is greater than 0. Application A sends a call request to application B. After application A completes the call to application B, it determines that the current remaining timeout of the application request, _system_timetolive, is 800 milliseconds - 20 milliseconds = 780 milliseconds. Since _system_timetolive = 780 milliseconds is greater than 0, application A proceeds to call application C. After application A completes the call to application C, it determines that the current remaining timeout of the application request, _system_timetolive, is 780 milliseconds - 110 milliseconds = 670 milliseconds. Since _system_timetolive = 670 milliseconds is greater than 0, application A proceeds to call application D. After application A completes the call to application D, it determines that the current remaining timeout of the application request, _system_timetolive, is 670 milliseconds - 50 milliseconds = 620 milliseconds. Since _system_timetolive = 620 milliseconds milliseconds>0, so application A returns a normal response to the user.

[0065]

[0066] In another example, as shown in FIG5 , application A determines that the current remaining timeout of the application request, _system_timetolive, is 800 milliseconds and is greater than 0. Application A sends a call request to application B. After application A completes the call to application B, it determines that the current remaining timeout of the application request, _system_timetolive, is 800 milliseconds - 20 milliseconds = 780 milliseconds. Since _system_timetolive = 780 milliseconds is greater than 0, application A continues to call application C. After application A completes the call to application C, it determines that the current remaining timeout of the application request, _system_timetolive, is 780 milliseconds - 1020 milliseconds = -240 milliseconds. Since _system_timetolive = -240 milliseconds is less than 0, application A cancels the call to application D and returns an error notification to the user.

[0067] In other embodiments of the present disclosure, the request processing method further includes: when determining that the processing of the application request has timed out based on the current remaining timeout period, returning an error notification to the sender of the application request and terminating the call to the application in the application call chain, thereby terminating subsequent redundant calls in advance and further improving request processing efficiency.

[0066]

[0068] Among them, the error notification is used to notify the occurrence of a timeout error.

[0067]

[0069] In a distributed system, calls and result returns between applications are passed layer by layer. For example, in Figure 1 above, application E first returns the result to application C, and application C then returns the result to application A. Based on this, the sender of the application request may be a user terminal or an upper-layer application.

[0068]

[0070] In other embodiments of the present disclosure, after sending the call request to any application in step 303, upon receiving an error notification returned by any application, the error notification may be returned to the sender of the application request, and the call to the application in the application call link may be terminated.

[0069]

[0071] As mentioned above, if an application returns an error notification, it indicates that a timeout occurred after the application called its underlying application. Therefore, based on the error notification returned by the application, subsequent calls in the application call chain can be terminated, and error notifications can continue to be returned to the sender of the application request. This allows timeout determination for the entire chain, terminating the call early and saving unnecessary time.

[0070]

[0072] For example, as shown in FIG6 , application A receives an application request. Application A determines that the current remaining timeout of the application request, _system_timetolive, is 800 milliseconds, which is greater than 0. Application A sends a call request to application B. After application A completes the call to application B, it determines that the current remaining timeout of the application request, _system_timetolive, is 800 milliseconds - 20 milliseconds, which is 780 milliseconds. Since _system_timetolive = 780 milliseconds is greater than 0, application A proceeds to call application C and passes _system_timetolive = 780 milliseconds along with the call request to application C. In application C, after application C completes the call to application E, the remaining timeout, _system_timetolive, is deducted by 200 milliseconds. Since _system_timetolive = 580 milliseconds is greater than 0, application C proceeds to call application F. After application C completes the call to application F, the remaining timeout, _system_timetolive, is deducted by 600 milliseconds. system_timetolive = -20 milliseconds < 0, so application C cancels the call to application G and returns an error notification to the upper-layer application A. Application A cancels the call to application D and returns an error notification to the user.

[0071]

[0073] In other embodiments of the present disclosure, with respect to the process of determining in step 303 that the processing of the application request has not timed out based on the determined remaining timeout period, it is also possible to obtain a historical average processing time of any application and determine that the processing of the application request has not timed out if the historical average processing time is less than the determined remaining timeout period.

[0072]

[0074] That is, before sending a call request to any application in the application call chain, the system uses the historical average time consumption of any application to predict whether the remaining time before the timeout is sufficient to complete the call. This allows calls that are likely to time out to be terminated in advance, thereby reducing calls to slow applications, reducing the load on slow applications, and helping to recover slow applications.

[0073]

[0075] In this embodiment, the historical average time consumption of any application is obtained based on the time consumption of each call to the any application within the first preset time closest to the current system time. Therefore, it can represent the time consumption when the any application is currently called. The first preset time represents the statistical range of the historical average time consumption.

[0074]

[0076] For example, as shown in Figure 7, in Application A, Application A determines that the remaining timeout, _system_timetolive, is 800 milliseconds. Before calling Application B, Application A obtains the historical average time consumption of Application B, which is 20 milliseconds. Because the predicted remaining timeout, _system_timetolive, of 800 milliseconds is greater than 20 milliseconds, Application A sends a call request to Application B. After Application A completes the call to Application B, the determined remaining timeout, _system_timetolive, is 800 milliseconds - 20 milliseconds = 780 milliseconds. Application A obtains the historical average time consumption of Application C, which is 1000 milliseconds. Because the predicted remaining timeout, _system_timetolive, is less than 1000 milliseconds, Application A prematurely cancels the calls to Applications C and D and returns an error notification to the user.

[0075]

[0077] In other embodiments of the present disclosure, after obtaining a historical average time consumption of any application based on the time consumption of each call to the application within a first preset time closest to the current system time, timing is started. If a call request from the application is detected before the timing reaches a second preset time, timing is restarted. If no call request from the application is detected after the timing reaches the second preset time, the historical average time consumption is deleted. Until it is needed, the historical average time consumption is obtained again based on the time consumption of each call to the application within the first preset time closest to the current system time. This ensures the timeliness of the historical average time consumption.

[0076]

[0078] The second preset time represents the time range of the historical average time effectiveness, and the second preset time is smaller than the first preset time. For example, the second preset time may be one third of the first preset time.

[0077]

[0079] In other embodiments of the present disclosure, since each call between applications in a distributed system is configured with a timeout, after obtaining the historical average call duration for any application based on the call durations for the first preset time period closest to the current system time, the historical average call duration can be compared with the timeout duration configured for the application. If the historical average call duration exceeds the timeout duration, calls to the application can be stopped for a certain period of time. This process of rejecting any calls to the application for a certain period of time facilitates the recovery of the application. Example 2

[0078]

[0080] Based on the above embodiments, the present disclosure further provides an embodiment of a request processing system, which includes a user terminal and a distributed system. The distributed system includes multiple applications, each of which is used to provide different services. The application can be regarded as a service module deployed in the distributed system, which can be an application program, a service, an instance, a functional module in the form of software, a virtual machine (VM), a container, or a cloud server, or a hardware device with data processing capabilities (such as a server or terminal device) or a hardware chip (such as a CPU, GPU, FPGA, NPU, AI accelerator card, or DPU).

[0079]

[0081] The user terminal is configured to send a service request to the distributed system; the distributed system is configured to forward the received service request to a target application called by the service request. The target application determines the current remaining timeout of the service request for calling any application in the application call chain corresponding to the service request, and sends a call request to any application if it is determined based on the remaining timeout that the processing of the service request has not timed out. The application call chain is the sequence of application calls that need to be completed to process the application request, and the remaining timeout is the remaining time until the application request times out.

[0080]

[0082] In the embodiments of the present disclosure, a user terminal refers to a device of a user instance, which needs to call a service in a distributed system according to actual usage requirements, thereby triggering the call of an application corresponding to the service and generating a service request.

[0081]

[0083] In some embodiments of the present disclosure, since the user terminal may set a timeout setting time for this request in the service request, when the distributed system forwards the received service request to the target application called by the service request, it can add a time transfer field to the service request based on the timeout setting time in the service request, and then forward the service request with the added field to the target application, thereby transferring the timeout setting time to the target application along with the service request.

[0082]

[0084] In this embodiment, the timeout setting time is the maximum waiting time set by the user terminal in the service request. The time transfer field indicates the remaining time before the service request times out.

[0083]

[0085] In specific implementations, distributed link tracing technology can be used. Distributed link tracing generates a unique identifier for a user request when it enters a distributed system. This identifier, as an extended field, permeates each application call involved in the request, facilitating the tracing of the request's path and status between applications. Therefore, relying on distributed link tracing technology, a time propagation field can be added to the service request as an extended field to convey the remaining timeout to the calling application.

[0084]

[0086] For example, if the request is an HTTP request, a time transfer field is added to the request header using a key-value structure. The time transfer field is the key and the field value is the value. For example, if the time transfer field is defined as _system_timetolive, then _system_timetolive is the key and the number indicating the remaining time of the timeout is the value.

[0085]

[0087] Furthermore, in the process of determining the current remaining timeout of the service request for the above-mentioned target application, if any application to be called is the first application in the application call chain, the time transfer field carried by the service request can be obtained. If the time transfer field is obtained, the field value corresponding to the time transfer field in the service request is used as the current remaining timeout of the service request; if any application to be called is not the first application in the application call chain, the call duration generated when calling the previous application of any application is obtained, and the call duration is used to adjust the remaining timeout determined when calling the previous application, and the adjusted remaining timeout is used as the current remaining timeout of the service request.

[0086]

[0088] Taking Figure 1 above as an example, a user terminal calls application A in a distributed system. The timeout set in the service request by the user terminal is 800 milliseconds. After receiving the service request, application A obtains the value of 800 milliseconds corresponding to the time transfer field in the service request of application B, the first application to be called in the application call chain, as the current remaining timeout of the service request. For application C to be called in the application call chain, the call duration incurred when calling application B is obtained. The remaining timeout determined when calling application B is adjusted using this call duration. The adjusted remaining timeout is used as the current remaining timeout of the service request. For application D to be called in the application call chain, the call duration incurred when calling application C is obtained. The remaining timeout determined when calling application C is adjusted using this call duration. The adjusted remaining timeout is used as the current remaining timeout of the service request.

[0087]

[0089] Furthermore, to address the issue of the distributed system failing to deliver the time transfer field, if the target application fails to obtain the time transfer field, it can obtain the timeout setting time for the service request and use the obtained timeout setting time as the current timeout remaining time of the service request to achieve fault tolerance.

[0088]

[0090] The timeout setting is the maximum waiting time for a user terminal to complete a call. In a distributed system, each call between applications has a timeout setting. For example, if application A calls application B, and the call from application A to application B exceeds the pre-configured timeout setting, application A will no longer wait for application B to return a result. Therefore, the timeout setting represents the maximum waiting time for a call between two applications, while the remaining timeout setting is the remaining timeout for the user terminal.

[0089]

[0091] In some embodiments of the present disclosure, the process of sending a call request from a target application to any application specifically includes: sending a call request including the current remaining timeout of the service request to the any application, so that the current remaining timeout is passed downward each time the call is made, thereby achieving timeout awareness throughout the entire link.

[0090]

[0092] For example, as shown in FIG4 , the distributed system sends a service request from a user terminal to application A. In application A, the application call link corresponding to the service request is application BT, application CT, and application D. Then, the call request sent by application A to application B includes a timeout remaining time _system_timetolive = 800 milliseconds, the call request sent by application A to application C includes a timeout remaining time _system_timetolive = 780 milliseconds, and the call request sent by application A to application D includes a timeout remaining time _system_timetolive = 670 milliseconds.

[0091]

[0093] In specific implementation, when sending a call request, the target application can add a time transfer field in the service request in the form of an extended field to pass the current timeout remaining time to the application to be called. For example, the time transfer field is added in a key-value structure, with the time transfer field as the key and the timeout remaining time as the field value.

[0092]

[0094] In some embodiments of the present disclosure, in a process in which a target application determines that processing of a service request has not timed out based on a current remaining timeout period, if the remaining timeout period is greater than 0, then processing of the service request is determined to have not timed out. Furthermore, if the remaining timeout period is less than or equal to 0, then processing of the service request is determined to have timed out.

[0093]

[0095] As shown in Figure 5, the user terminal calls application A. In application A, application A determines that the current remaining timeout of the application request, _system_timetolive, is 800 milliseconds, which is greater than 0. Application A sends a call request to application B. After application A completes the call to application B, it determines that the current remaining timeout of the application request is 800 milliseconds - 20 milliseconds, which is 780 milliseconds. Because _system_timetolive is 780 milliseconds, which is greater than 0, application A continues to call application C. After application A completes the call to application C, it determines that the current remaining timeout of the application request, _system_timetolive, is 780 milliseconds - 1020 milliseconds, which is -240 milliseconds. Because _system_timetolive is -240 milliseconds, which is less than 0, application A cancels the call to application D and returns an error notification to the user.

[0094]

[0096] In other embodiments of the present disclosure, when the target application determines that the processing of the service request has timed out based on the current remaining timeout period, it returns an error notification to the user terminal and terminates the call to the application in the application call chain, thereby terminating subsequent redundant calls in advance and further improving request processing efficiency.

[0095]

[0097] Among them, the error notification is used to notify the occurrence of a timeout error.

[0096]

[0098] In other embodiments of the present disclosure, after sending a call request to any application, the target application may, upon receiving an error notification returned by any application, return the error notification to the user terminal and terminate the call to the application in the application call link.

[0097]

[0099] As mentioned above, if an application returns an error notification, it indicates that a timeout has occurred after the application has called its underlying application. Therefore, based on the error notification returned by the application, the target application can terminate subsequent calls and return an error notification to the user terminal. This allows for full-link timeout determination, prematurely ending the call and saving unnecessary time.

[0098]

[0100] As shown in Figure 6, the user terminal calls application A. Application A determines that the current remaining timeout of the service request, _system_timetolive = 800 milliseconds, is greater than 0. Application A sends a call request to application B. After application A completes the call to application B, it determines that the current remaining timeout of the application request, _system_timetolive = 800 milliseconds - 20 milliseconds = 780 milliseconds. Since _system_timetolive = 780 milliseconds is greater than 0, application A proceeds to call application C and passes _system_timetolive = 780 milliseconds along with the call request to application C. In application C, after application C completes the call to application E, the remaining timeout, _system_timetolive, is deducted by 200 milliseconds. Since _system_timetolive = 580 milliseconds is greater than 0, application C proceeds to call application F. After application C completes the call to application F, the remaining timeout, _system_timetolive, is deducted by 600 milliseconds. system_timetolive = -20 milliseconds < 0, so application C cancels the call to application G and returns an error notification to the upper-layer application A. Application A cancels the call to application D and returns an error notification to the user terminal.

[0099]

[0101] In other embodiments of the present disclosure, the target application determines that the processing of the service request has not timed out based on the determined remaining timeout period. Alternatively, the target application may obtain a historical average processing time of any application and determine that the processing of the service request has not timed out if the historical average processing time is less than the determined remaining timeout period.

[0100]

[0102] That is, before sending a call request to any application in the application call chain, the system uses the historical average time consumption of any application to predict whether the remaining time before the timeout is sufficient to complete the call. This can avoid timeouts before the call and terminate calls that are likely to time out in advance, thereby reducing calls to slow applications, reducing the load on slow applications, and helping to recover slow applications.

[0101]

[0103] In this embodiment, the historical average time consumption of any application is obtained based on the time consumption of each call to the application within the first preset time closest to the current system time. Therefore, it can represent the time consumption when the application is currently called. The first preset time represents the statistical range of the historical average time consumption.

[0102]

[0104] As shown in FIG7 , the user terminal calls application A. When application A receives the service request, the determined remaining timeout, _system_timetolive, is 800 milliseconds. Before calling application B, application A obtains the historical average time consumption of application B, which is 20 milliseconds. Because the predicted remaining timeout, _system_timetolive, of 800 milliseconds is greater than 20 milliseconds, application A sends a call request to application B. After application A completes the call to application B, the determined remaining timeout, _system_timetolive, is 800 milliseconds - 20 milliseconds = 780 milliseconds. Application A obtains the historical average time consumption of application C, which is 1000 milliseconds. Because the predicted remaining timeout, _system_timetolive, is less than 1000 milliseconds, application A prematurely cancels the calls to applications C and D and returns an error notification to the user.

[0103]

[0105] In other embodiments of the present disclosure, after obtaining a historical average time consumption of any application based on the time consumption of each call to the application within a first preset time closest to the current system time, timing is started. If a call request from the application is detected before the timing reaches a second preset time, timing is restarted. If no call request from the application is detected after the timing reaches the second preset time, the historical average time consumption is deleted. Until it is needed, the historical average time consumption is obtained again based on the time consumption of each call to the application within the first preset time closest to the current system time. In this way, the timeliness of the historical average time consumption can be ensured.

[0104]

[0106] The second preset time represents the time range of the historical average time effectiveness, and the second preset time is smaller than the first preset time. For example, the second preset time may be one third of the first preset time.

[0107] In other embodiments of the present disclosure, since each call between applications in a distributed system is configured with a timeout, after obtaining the historical average call duration for any application based on the call durations for each application within a first preset period closest to the current system time, the historical average call duration can be compared with the timeout duration configured for the application. If the historical average call duration exceeds the timeout duration, calls to the application can be stopped for a specified period of time. This process of rejecting any calls to the application for a specified period of time facilitates recovery of the application.

[0105]

[0108] Based on the above-described second embodiment, the distributed system forwards the service request from the user terminal to the corresponding target application. Each time the target application calls any application in the call chain corresponding to the service request, it determines the current remaining timeout for the service request. Before sending the call request to the application currently being called, it determines whether the service request has timed out based on the current remaining timeout. Only if it determines that the timeout has not expired will the call request be sent to any application. This allows the entire application call chain to fully detect the current remaining timeout for the application request. Only if the timeout has not expired will the call proceed to the next application. Otherwise, the call will not proceed to the next application. This avoids the increased processing burden of executing unnecessary calls after a timeout, thereby improving request processing efficiency.

[0106]

[0109] To determine whether a service request has timed out based on the current remaining timeout, the system obtains the historical average duration of the application being called and uses this to predict whether the current remaining timeout is sufficient to complete the call. This allows calls with a high probability of timeout to be terminated early, reducing calls to slow applications, reducing the load on these applications, and facilitating recovery.

[0107]

[0110] Furthermore, upon receiving the error notification returned by the calling application, the target application may also terminate the subsequent call in advance and return the error notification to the user terminal, so that the user terminal can also end its waiting for the result of the service request processing.

[0108]

[0111] It can be seen that the above solution realizes timeout awareness of the entire call link during the process of processing the service request of the user terminal.

[0109]

[0112] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0110]

[0113] Corresponding to the aforementioned embodiments of the request processing method, the present disclosure also provides embodiments of a request processing device.

[0111]

[0114] FIG8 is a schematic structural diagram of a request processing device according to an exemplary embodiment, which is configured to execute the request processing method provided in any of the aforementioned embodiments. As shown in FIG8 , the request processing device includes: a receiving module 810, configured to receive an application request; the remaining timeout time is the remaining time until the application request times out; a time determination module 820, configured to determine, for a call of any application in an application call chain corresponding to the application request, the current remaining timeout time of the application request; the application call chain is the sequence of application calls that need to be completed to process the application request, and the remaining timeout time is the remaining time until the application request times out; and an advance determination module 830, configured to send a call request to the any application if, based on the remaining timeout time, it is determined that processing of the application request has not timed out.

[0112]

[0115] In an optional implementation, the time determination module 820 is specifically configured to, in determining the current remaining timeout of the application request, use a time transfer field in the application request to determine the current remaining timeout of the application request when the any application is the first application in the application call chain; the time transfer field indicates a field used by the sender of the application request to transfer the remaining timeout when sending the application request; and, if the any application is not the first application in the application call chain, obtain a call duration generated when calling a previous application of the any application, use the call duration to adjust the remaining timeout determined when calling the previous application, and use the adjusted remaining timeout as the current remaining timeout of the application request.

[0113]

[0116] In an optional implementation, the time determination module 820 is specifically configured to, in a process of determining the current remaining timeout time of the application request using the time transfer field in the application request, include: if the application request carries the time transfer field, using the field value corresponding to the time transfer field in the application request as the current remaining timeout time of the application request; if the application request does not carry the time transfer field, obtaining the timeout setting time for the application request, and using the timeout setting time as the remaining timeout time; the timeout setting time is the maximum waiting time set by the sender of the application request in the application request.

[0114]

[0117] In an optional implementation, the time determination module 820 is specifically configured to, in the process of adjusting the remaining timeout determined when calling the previous application using the call duration, subtract the call duration from the remaining timeout determined when calling the previous application to obtain the adjusted remaining timeout.

[0115]

[0118] In an optional implementation, the apparatus further includes (not shown in FIG8 ): a first error handling module configured to, when determining based on the remaining timeout period that the processing of the application request has timed out, return an error notification to the sender of the application request and terminate the call to the application in the application call link.

[0116]

[0119] In an optional implementation, the device also includes (not shown in Figure 8): a second error handling module, which is used to, after sending a call request to any of the applications, return the error notification to the sender of the application request upon receiving an error notification returned by any of the applications, and end the call to the application in the application call link.

[0120] In an optional implementation, the advance determination module 830 is specifically configured to obtain a historical average duration of the any application during a process of determining that the processing of the application request has not timed out based on the remaining timeout time; the historical average duration is obtained based on the duration of each call to the any application within a first preset time closest to the current system time; and if the historical average duration is less than the remaining timeout time, determine that the processing of the application request has not timed out.

[0117]

[0121] In an optional implementation, the device further includes (not shown in FIG8 ): a statistical failure module, configured to start timing after obtaining a historical average duration of the any application based on the duration of each call of the any application within a first preset time closest to the current system time; restart timing if a call request of the any application is detected before the timing reaches a second preset time; and delete the historical average duration if no call request of the any application is detected after the timing reaches the second preset time; wherein the first preset time is greater than the second preset time.

[0118]

[0122] In an optional implementation, the advance determination module 830 is specifically configured to, in the process of determining whether the processing of the application request has not timed out based on the remaining timeout time, determine that the processing of the application request has not timed out if the remaining timeout time is greater than 0.

[0119]

[0123] In an optional implementation, the advance determination module 830 is specifically configured to send a call request including the timeout remaining time to the any application during the process of sending the call request to the any application.

[0120]

[0124] The implementation process of the functions and effects of each unit in the above device is specifically described in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0121]

[0125] Since the apparatus embodiments generally correspond to the method embodiments, reference will be made to the description of the method embodiments for relevant details. The apparatus embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one location or distributed across multiple network elements. Some or all of the modules may be selected based on actual needs to achieve the objectives of the disclosed solutions. Persons of ordinary skill in the art will be able to understand and implement the present invention without inventive effort.

[0122]

[0126] The disclosed embodiments further provide an electronic device corresponding to the request processing method provided in the aforementioned embodiments, to execute the aforementioned request processing method.

[0123]

[0127] FIG9 is a hardware structure diagram of an electronic device according to an exemplary embodiment. The electronic device includes a communication interface 601, a processor 602, a memory 603, and a bus 604. The communication interface 601, the processor 602, and the memory 603 communicate with each other via the bus 604. The processor 602 executes the request processing method described above by reading and executing machine-executable instructions corresponding to the control logic of the request processing method in the memory 603. The details of this method are described in the above embodiments and are not further elaborated here.

[0124]

[0128] The memory 603 mentioned in this disclosure may be any electronic, magnetic, optical, or other physical storage system, and may contain stored information, such as executable instructions, data, and the like. Specifically, the memory 603 may be RAM (Random Access Memory), flash memory, a storage drive (such as a hard disk drive), any type of storage disk (such as an optical disk, a DVD, etc.), or similar storage media, or a combination thereof. The communication connection between the system network element and at least one other network element is achieved via at least one communication interface 601 (which may be wired or wireless), and may utilize the Internet, a wide area network, a local area network, a metropolitan area network, and the like.

[0125]

[0129] The bus 604 may be an ISA bus, a PCI bus, or an EISA bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. The memory 603 is used to store programs, and the processor 602 executes the programs after receiving an execution instruction.

[0126]

[0130] Processor 602 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method may be completed by hardware integrated logic circuits or software instructions within processor 602. The above processor 602 may be a general-purpose processor, including a network processor (NP), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. It may implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in conjunction with the embodiments of this disclosure may be directly executed by a hardware decoding processor, or by a combination of hardware and software modules within the decoding processor.

[0127]

[0131] The electronic device provided by the embodiment of the present disclosure and the request processing method provided by the embodiment of the present disclosure are based on the same inventive concept and have the same beneficial effects as the methods adopted, operated or implemented therein.

[0128]

[0132] The present disclosure also provides a computer-readable storage medium corresponding to the request processing method provided in the aforementioned embodiments. Referring to FIG. 10 , the computer-readable storage medium shown is an optical disc 30 storing a computer program (i.e., a program product). When executed by a processor, the computer program executes the request processing method provided in any of the aforementioned embodiments.

[0129]

[0133] It should be noted that examples of the computer-readable storage medium may also include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory, or other optical or magnetic storage media, and are not listed here one by one.

[0134] The computer-readable storage medium provided in the above-mentioned embodiments of the present disclosure and the request processing method provided in the embodiments of the present disclosure are based on the same inventive concept and have the same beneficial effects as the method adopted, run or implemented by the application program stored therein.

[0130]

[0135] The embodiments of the present disclosure further provide a computer program product corresponding to the request processing method provided in the aforementioned embodiments. The computer program product includes a computer program, and the computer program is executed by a processor to implement the request processing method provided in the aforementioned embodiments.

[0131]

[0136] The computer program product provided by the above-mentioned embodiments of the present disclosure and the request processing method provided by the embodiments of the present disclosure are based on the same inventive concept and have the same beneficial effects as the method adopted, run or implemented by the application program stored therein.

[0132]

[0137] Those skilled in the art will readily recognize other embodiments of the present disclosure after considering the specification and practicing the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only; the true scope and spirit of the present disclosure are indicated by the following claims.

[0133]

[0138] It should also be noted that the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, product, or apparatus comprising a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, product, or apparatus. In the absence of further limitations, the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, product, or apparatus comprising the elements.

[0134]

[0139] The above description is merely a preferred embodiment of the present disclosure and is not intended to limit the present disclosure. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present disclosure shall be included in the scope of protection of the present disclosure.

Claims

Claims 1. A request processing method, comprising: receiving an application request; and determining a current remaining timeout of the application request for a call of any application in an application call link corresponding to the application request; The application call link is the application call sequence that needs to be completed to process the application request, and the remaining timeout is the remaining time before the application request times out. If it is determined based on the remaining timeout that the processing of the application request has not timed out, a call request is sent to the any application.

2. The method according to claim 1, wherein: The determining of the current remaining timeout of the application request includes: when any application is the first application in the application call link, using the time transfer field in the application request to determine the current remaining timeout of the application request; the time transfer field indicates the field for transmitting the remaining timeout when the sender of the application request sends the application request; when any application is not the first application in the application call link, obtaining the call consumption generated when calling the previous application of any application, using the call consumption to adjust the remaining timeout determined when calling the previous application, and using the adjusted remaining timeout as the current remaining timeout of the application request.

3. The method according to claim 2, wherein: The determining the current remaining timeout time of the application request by using the time transfer field in the application request includes: when the application request carries the time transfer field, using the field value corresponding to the time transfer field in the application request as the current remaining timeout time of the application request; when the application request does not carry the time transfer field, obtaining the timeout setting time for the application request, and using the timeout setting time as the remaining timeout time; the timeout setting time is the maximum waiting time set by the sender of the application request in the application request.

4. The method according to claim 2, wherein: The using the call time to adjust the remaining timeout determined when calling the previous application includes: subtracting the call time from the remaining timeout determined when calling the previous application to obtain an adjusted remaining timeout.

5. The method according to claim 1, further comprising: If it is determined based on the remaining timeout period that the processing of the application request has timed out, an error notification is returned to the sender of the application request, and the call to the application in the application call link is terminated.

6. The method according to claim 1, wherein: After sending a call request to any of the applications, The method further includes: upon receiving an error notification returned by any of the applications, returning the error notification to the sender of the application request, and ending the call to the application in the application call link.

7. The method according to claim 1, wherein: The determining whether the processing of the application request has not timed out based on the remaining timeout time includes: obtaining the historical average time consumption of any of the applications; the historical average time consumption is obtained based on the time consumption of each call to any of the applications within the first preset time closest to the current system time; when the historical average time consumption is less than the remaining timeout time, determining that the processing of the application request has not timed out.

8. The method according to claim 7, further comprising: After obtaining a historical average duration of the application based on the duration of each call to the application within a first preset time period closest to the current system time, timing is started; if a call request from the application is detected before the timing reaches a second preset time period, timing is restarted; if no call request from the application is detected after the timing reaches the second preset time period, the historical average duration is deleted; Wherein, the first preset time is greater than the second preset time.

9. The method according to claim 1, wherein: The determining, based on the remaining timeout period, that the processing of the application request has not timed out includes: if the remaining timeout period is greater than 0, determining that the processing of the application request has not timed out.

10. The method according to any one of claims 1 to 9, wherein: The sending of the call request to any one of the applications includes: sending a call request including the timeout remaining time to any one of the applications.

11. A request processing system, comprising a user terminal and a distributed system, wherein the distributed system comprises multiple applications, each of which is configured to provide a different service: the user terminal is configured to send a service request to the distributed system; the distributed system is configured to forward the service request to a target application invoked by the service request; the target application determines a current remaining timeout of the service request for invoking any application in an application invocation chain corresponding to the service request; and if it is determined based on the remaining timeout that processing of the service request has not timed out, sends a call request to the any application; wherein: The application call link is the application call sequence that needs to be completed to process the application request, and the remaining time before the timeout is the remaining time before the application request times out.

12. The system according to claim 11, wherein: The distributed system is specifically configured to, during a process of forwarding the service request to a target application invoked by the service request, utilize a timeout setting time of the service request to add a time transfer field to the service request, and forward the service request with the added field to the target application; the timeout setting time being a maximum waiting time set by the user terminal in the service request.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: The processor executes the program to implement the method according to any one of claims 1 to 10.

14. A computer-readable storage medium having a computer program stored thereon, wherein: The program is executed by a processor to implement the method according to any one of claims 1 to 10.

15. A computer program product, comprising a computer program, wherein: The computer program is executed by a processor to implement the method according to any one of claims 1 to 10.

Images