Front-end and back-end communication request response method and device, equipment, storage medium and product

Abstract

The invention discloses a front-end and back-end communication request response method and device, equipment, a storage medium and a product. The method can be applied to the field of financial science and technology, and comprises the following steps: carrying out request interception on a front-end request of a target front end, writing the intercepted front-end request into a preset message queue, and generating a request identifier corresponding to the front-end request for the front-end request; selecting a plurality of initial front-end requests meeting a preset time interval period from the message queue; selecting at least two to-be-merged front-end requests from the initial front-end requests, and performing request merging on the to-be-merged front-end requests based on request identifiers of the to-be-merged front-end requests to obtain a target front-end request; sending the target front-end request to a target rear end corresponding to the target front end, so that the target rear end generates target request response data based on the target front-end request; and feeding back the target request response data to the target front end. According to the technical scheme, the front-end and back-end communication request response efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the field of financial technology, and in particular to a front-end and back-end communication request response method, device, equipment, storage medium and product. Background Art

[0002] Currently, in communication scenarios including those dealing with financial-related businesses, front-end and back-end communication mainly relies on direct HTTP (HyperText Transfer Protocol) requests.

[0003] However, in scenarios such as banking business processing, the communication request volume between the front-end and back-end is large, and the number of requests is high. Frequent requests increase the network burden, resulting in inefficient communication request responses and slow front-end page response speed, which in turn causes a poor user experience for business-related users. Summary of the Invention

[0004] The present invention provides a front-end and back-end communication request response method, device, equipment, storage medium and product to improve the efficiency of front-end and back-end communication request response, thereby increasing the front-end page response speed and further enhancing the user experience of business-related users.

[0005] According to one aspect of the present invention, a front-end and back-end communication request response method is provided, the method comprising:

[0006] Intercept the front-end request of the target front-end, write the intercepted front-end request into a preset message queue, and generate a corresponding request identifier for the front-end request;

[0007] Selecting a plurality of initial front-end requests that meet a preset time interval period from the message queue;

[0008] Selecting at least two front-end requests to be merged from each of the initial front-end requests, and merging the front-end requests to be merged based on the request identifiers of each of the front-end requests to be merged to obtain a target front-end request;

[0009] Sending the target front-end request to a target back-end corresponding to the target front-end, so that the target back-end generates target request response data based on the target front-end request;

[0010] Feedback the target request response data to the target front end.

[0011] According to another aspect of the present invention, a front-end and back-end communication request response device is provided, the device comprising:

[0012] The front-end request interception module is used to intercept the front-end request of the target front-end, write the intercepted front-end request into a preset message queue, and generate a corresponding request identifier for the front-end request;

[0013] An initial request selection module, configured to select a number of initial front-end requests that meet a preset time interval period from the message queue;

[0014] A request merging module, configured to select at least two front-end requests to be merged from each of the initial front-end requests, and merge the front-end requests to be merged based on the request identifiers of the front-end requests to be merged to obtain a target front-end request;

[0015] A target request sending module, configured to send the target front-end request to a target back-end corresponding to the target front-end, so that the target back-end generates target request response data based on the target front-end request;

[0016] The response data sending module is used to feed back the target request response data to the target front end.

[0017] According to another aspect of the present invention, an electronic device is provided, comprising:

[0018] at least one processor; and

[0019] a memory communicatively connected to the at least one processor; wherein,

[0020] The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the front-end and back-end communication request response method described in any embodiment of the present invention.

[0021] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the front-end and back-end communication request response method described in any embodiment of the present invention when executed.

[0022] According to another aspect of the present invention, a computer program product is provided. The computer program product includes a computer program. When the computer program is executed by a processor, the front-end and back-end communication request response method according to any embodiment of the present invention is implemented.

[0023] The technical solution of the embodiment of the present invention intercepts the front-end request of the target front-end and writes it into the message queue, generates the corresponding request identifier for the front-end request, selects the initial front-end request that meets the time interval period, selects the front-end request to be merged from each initial front-end request, and merges each front-end request to be merged based on the request identifier of each front-end request to obtain the target front-end request, sends the target front-end request to the target back-end corresponding to the target front-end so that the target back-end can generate the target request response data based on the target front-end request, and feeds back the target request response data to the target front-end. The above technical solution improves the efficiency of the front-end and back-end communication request response by merging a large number of front-end requests of the target front-end, and the target back-end processes the merged request and then responds, thereby improving the response speed of the front-end page. By reducing the actual number of requests and improving the response speed, the user experience of industry-related users using the target front-end page is significantly improved.

[0024] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the present invention. Other features of the present invention will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0026] Figure 1 This is a flowchart of a front-end and back-end communication request response method provided according to the first embodiment of the present invention;

[0027] Figure 2 This is a flowchart of a front-end and back-end communication request response method provided according to the second embodiment of the present invention;

[0028] Figure 3 This is a flowchart of a front-end and back-end communication request response method provided according to embodiment three of the present invention;

[0029] Figure 4 This is a schematic diagram of the structure of a front-end and back-end communication request response device provided according to a fourth embodiment of the present invention;

[0030] Figure 5 It is a structural diagram of an electronic device that implements the front-end and back-end communication request response method according to an embodiment of the present invention. DETAILED DESCRIPTION

[0031] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0032] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0033] Example 1

[0034] Figure 1 This is a flowchart of a front-end and back-end communication request response method provided in the first embodiment of the present invention. This embodiment can be applied to the situation where a fast request response is performed between the front-end and back-end communications in business scenarios with a large amount of front-end and back-end request responses, such as in the financial field. The method can be executed by a front-end and back-end communication request response device, which can be implemented in the form of hardware and / or software, and can be configured in an electronic device. Figure 1 As shown, the method includes:

[0035] S110: intercepting the front-end request of the target front-end, writing the intercepted front-end request into a preset message queue, and generating a corresponding request identifier for the front-end request.

[0036] S120: Select several initial front-end requests that meet a preset time interval from the message queue.

[0037] S130 . Select at least two front-end requests to be merged from each initial front-end request, and merge each front-end request to be merged based on the request identifier of each front-end request to be merged to obtain a target front-end request.

[0038] S140: Send the target front-end request to the target back-end corresponding to the target front-end, so that the target back-end generates target request response data based on the target front-end request.

[0039] S150: Feedback target request response data to the target front end.

[0040] The execution entity of this solution can be a virtualization module or a virtualization layer, which is set between the target front-end and the target back-end. Its function is similar to that of an API (Application Programming Interface) gateway. It can serve as an intermediary between the target front-end and the target back-end to intercept and temporarily suspend the target front-end request.

[0041] The target front end may be a front end page of a financial business system. When the virtualization layer or virtualization module receives a front end request from the target front end, it intercepts the front end request, temporarily suspends the front end request, and temporarily stores it in a pre-built message queue.

[0042] Generate a request identifier for each front-end request. This identifier uniquely identifies the request. Typically, front-end requests are batch requests, and each request in the batch is assigned a request identifier. For example, the request identifier can be a VRID (Virtual Router Identifier), specifically a 32-bit UUID (Universally Unique Identifier) to ensure uniqueness. The request identifier is used to track the request-response lifecycle of each front-end request.

[0043] A plurality of initial front-end requests that meet a preset time interval are selected from the message queue. The time interval can be preset by relevant technical personnel based on actual needs. For example, the time interval can be set to 100ms. The message queue can be managed using a (First In, First Out) mechanism. Based on the request write time of the front-end requests written into the message queue, the front-end requests within the preset time interval are selected from the front-end requests in the message queue as the initial front-end requests.

[0044] According to the request type of each initial front-end request, the initial front-end request with the same request type is selected from several initial front-end requests as the front-end request to be merged. Among them, the request type can be, for example, a GET request or a POST request. When merging the front-end requests to be merged, the request identifier of the corresponding front-end request to be merged is added to the merged target front-end request for subsequent request and response relationship mapping. Specifically, the corresponding request identifier can be added to the preset field or specific field of the request header (Header) or request body (Body) of the target front-end request so that it can be correctly split after the subsequent response.

[0045] The target front-end request is sent to the target back-end corresponding to the target front-end, and the target back-end responds to the target front-end request to obtain target request response data; the virtualization device or virtual layer intercepts the target request response data and splits the target request response data, determines the request response data corresponding to the front-end request before merging one by one based on the request identifier, and feeds back the request response data to the target component in the target front-end that initiates the corresponding front-end request.

[0046] Optionally, target request response data may be fed back to the target front end based on the second version of the Hypertext Transfer Protocol (HTTP), thereby further improving the request concurrency capability.

[0047] Optionally, you can limit the number of concurrent requests to avoid network congestion caused by excessive requests. The default maximum number of concurrent requests is set to 6-8, which can be dynamically adjusted based on the application scenario.

[0048] The technical solution of the embodiment of the present invention intercepts the front-end request of the target front-end and writes it into the message queue, generates the corresponding request identifier for the front-end request, selects the initial front-end request that meets the time interval period, selects the front-end request to be merged from each initial front-end request, and merges each front-end request to be merged based on the request identifier of each front-end request to obtain the target front-end request, sends the target front-end request to the target back-end corresponding to the target front-end so that the target back-end can generate the target request response data based on the target front-end request, and feeds back the target request response data to the target front-end. The above technical solution improves the efficiency of the front-end and back-end communication request response by merging a large number of front-end requests of the target front-end, and the target back-end processes the merged request and then responds, thereby improving the response speed of the front-end page. By reducing the actual number of requests and improving the response speed, the user experience of industry-related users using the target front-end page is significantly improved.

[0049] Example 2

[0050] Figure 2This is a flowchart of a front-end and back-end communication request response method provided in the second embodiment of the present invention. This embodiment is optimized and improved on the basis of the above technical solutions.

[0051] Further, the step of "selecting at least two front-end requests to be merged from each initial front-end request, merging each front-end request to be merged based on the request identifier of each front-end request to be merged, and obtaining a target front-end request" is refined into "determining the request type, request structure characteristic data, request priority and request dependency data corresponding to each initial front-end request; selecting at least two front-end requests to be merged from each initial front-end request according to the request type, request structure characteristic data, request priority and request dependency data corresponding to each initial front-end request; merging each front-end request to be merged based on the request identifier corresponding to each front-end request to be merged, and obtaining a target front-end request." to improve the request merging method for front-end requests to be merged.

[0052] It should be noted that for the parts not described in detail in the embodiments of the present invention, reference can be made to the descriptions of other embodiments. Figure 2 As shown, the method includes the following specific steps:

[0053] S210: intercepting the front-end request of the target front-end, writing the intercepted front-end request into a preset message queue, and generating a corresponding request identifier for the front-end request.

[0054] S220: Select several initial front-end requests that meet a preset time interval from the message queue.

[0055] S230: Determine the request type, request structure feature data, request priority, and request dependency data corresponding to each initial front-end request.

[0056] The request type can be a GET request type or a POST request type, etc. The request structure feature data is used to describe the structural features of the front-end request, such as the request path, main parameter names, and timestamp. The request priority can be pre-set by relevant technical personnel. For example, different request types can have different request priorities, or different requests under the same request type can also have different priorities. The request dependency relationship can be a dependency relationship between requests. For example, if request A depends on the request result of request B, then request B needs to be executed before request A.

[0057] For any initial front-end request, the request is parsed to obtain the request type, request structure feature data, and request priority. Based on the request execution association or execution order relationship of each initial front-end request, the request dependency relationship between the initial front-end requests is determined, thereby obtaining the request dependency data corresponding to each initial front-end request. For example, if request A depends on the request result of request B, the request dependency data corresponding to request A is dependent on request B; the request dependency data corresponding to request B is dependent on request A.

[0058] S240. Select at least two front-end requests to be merged from each initial front-end request according to the request type, request structure characteristic data, request priority, and request dependency data corresponding to each initial front-end request.

[0059] Exemplarily, each initial front-end request can be clustered according to the request type, request structure feature data, request priority and request dependency data corresponding to each initial front-end request, and several initial front-end requests with high similarity can be obtained as front-end requests to be merged.

[0060] In order to further improve the accuracy of request selection for front-end requests to be merged, similarity judgments can be made in sequence from dimensions such as request type, request structure feature data, request priority, and request dependency data, so as to select front-end requests to be merged.

[0061] In an optional embodiment, at least two front-end requests to be merged are selected from each initial front-end request based on the request type, request structure characteristic data, request priority and request dependency data corresponding to each initial front-end request, including: selecting several first intermediate requests with the same request type from each initial front-end request; determining the request similarity of each first intermediate request based on the request structure characteristic data of each first intermediate request, and selecting several second intermediate requests from each first intermediate request based on the request similarity; selecting at least two front-end requests to be merged from each second intermediate request based on the request priority and request dependency data of the several second intermediate requests.

[0062] Several initial front-end requests of the same request type are selected from each initial front-end request as first intermediate requests. Based on the request structure data of each first intermediate request and a preset similarity model or similarity algorithm, the request similarity of each first intermediate request is determined. For example, the similarity algorithm may be a cosine similarity algorithm or a similarity algorithm based on term frequency-document frequency. Based on the request similarity, several second intermediate requests are selected from the first intermediate requests whose similarity meets a preset condition, such as a request similarity greater than a set similarity threshold.

[0063] Based on the request priority and request dependency data of each second intermediate request, at least two front-end requests to be merged are selected from each second intermediate request. Specifically, a third intermediate request with a higher request priority is selected from each second intermediate request. Based on the request dependency data of the third intermediate request, a determination is made as to whether there are any dependent requests. For example, if third intermediate request A depends on the request result of request B, request B must be executed before request A. Based on the request dependency data and the third intermediate request, at least two front-end requests to be merged are determined.

[0064] The technical solution of the above embodiment selects several first intermediate requests with the same request type from each initial front-end request, determines the request similarity of each first intermediate request based on the request structure feature data of each first intermediate request, and selects several second intermediate requests from each first intermediate request based on the request similarity, selects at least two front-end requests to be merged from each second intermediate request based on the request priority and request dependency data of the several second intermediate requests, and performs request screening of the front-end requests in sequence from multiple request feature dimensions to obtain at least two front-end requests to be merged, thereby improving the accuracy of request selection of the front-end requests to be merged.

[0065] S250 : Based on the request identifiers corresponding to the front-end requests to be merged, merge the front-end requests to be merged to obtain a target front-end request.

[0066] Based on the set format, such as JSON (JavaScript Object Notation) format, the front-end requests to be merged are merged. During the merging process, the request identifier of the front-end request to be merged is embedded into the preset or specific field of the request header or request body to obtain the target front-end request.

[0067] S260: Send the target front-end request to the target back-end corresponding to the target front-end, so that the target back-end generates target request response data based on the target front-end request.

[0068] S270: Feedback target request response data to the target front end.

[0069] The technical solution of this embodiment selects at least two front-end requests to be merged from each initial front-end request according to the request type, request structure feature data, request priority and request dependency data corresponding to each initial front-end request, and merges the front-end requests to be merged based on the request identifier corresponding to each front-end request to be merged to obtain the target front-end request. During the merging process, the request features of multiple dimensions are comprehensively considered to select the front-end requests to be merged, thereby improving the selection accuracy of the front-end requests to be merged, thereby avoiding the occurrence of subsequent request errors or request anomalies or response anomalies due to improper request merging.

[0070] Example 3

[0071] Figure 3 This is a flowchart of a front-end and back-end communication request response method provided in Example 3 of the present invention. This embodiment is optimized and improved on the basis of the above technical solutions.

[0072] Furthermore, after the step of "intercepting the front-end request of the target front-end, writing the intercepted front-end request into a preset message queue, and generating a corresponding request identifier for the front-end request", the step of "determining the request context data of each front-end request, and associating and storing the request identifier of each front-end request with its corresponding request context data" is added; accordingly, the step of "feeding back the target request response data to the target front-end" is refined into "parsing the target request response data to obtain the request response data corresponding to each request identifier; determining the request response data corresponding to each front-end request based on the association between the stored request identifier and the request context data, and feeding back the request response data to the target component that initiates the corresponding front-end request in the target front-end." to improve the processing method of the target request response data.

[0073] It should be noted that for the parts not described in detail in the embodiments of the present invention, reference can be made to the descriptions of other embodiments. Figure 3 As shown, the method includes the following specific steps:

[0074] S310: intercept the front-end request of the target front-end, write the intercepted front-end request into a preset message queue, and generate a corresponding request identifier for the front-end request.

[0075] S320: Determine the request context data of each front-end request, and associate and store the request identifier of each front-end request with its corresponding request context data.

[0076] When the execution subject virtual layer or virtual device intercepts a front-end request sent by the target front-end, it immediately creates a context object for the front-end request as the request context data for the front-end request. The request context data can include the complete HTTP request information, request initiator information, timestamp, and status information.

[0077] Request context data is used to bind requests to frontend requests. Specifically, a global hash table or similar efficient key-value storage structure can be maintained. The key is the request identifier of the frontend request, and the value is the request context data of the frontend request. The request identifier of each frontend request and its corresponding request context data are associated and stored as key-value pairs.

[0078] S330: Select several initial front-end requests that meet a preset time interval from the message queue.

[0079] S340: Select at least two front-end requests to be merged from each initial front-end request, and merge each front-end request to be merged based on the request identifier of each front-end request to obtain a target front-end request.

[0080] S350: Send the target front-end request to the target back-end corresponding to the target front-end, so that the target back-end generates target request response data based on the target front-end request.

[0081] S360: parse the target request response data to obtain request response data corresponding to each request identifier.

[0082] After the target backend processes the merged target frontend request, it generates a merged response, the target request response data, which is fed back to the executing virtual device or virtual layer. The request header or request body in the target request response data contains all the request identifiers corresponding to the request. The target request response data is parsed to separate the data segments corresponding to each request identifier. These data segments are the request response data.

[0083] S370. Determine the request response data corresponding to the front-end requests respectively according to the association relationship between the stored request identifier and the request context data, and feed back the request response data to the target component that initiates the corresponding front-end request in the target front-end.

[0084] Based on the pre-stored association between the request identifier and the request context data, the request response data corresponding to each of the request context data can be determined, thereby obtaining the request response data corresponding to each of the front-end requests corresponding to the request context data. The corresponding request response data is sent to the target component in the target front-end that initiated the corresponding front-end request.

[0085] The technical solution of this embodiment associates and stores the request identifier of each front-end request with its corresponding request context data, parses the target request response data, obtains the request response data corresponding to each request identifier, and determines the request response data corresponding to the front-end request based on the association relationship between the stored request identifier and the request context data, and feeds back the request response data to the target component that initiates the corresponding front-end request in the target front-end, thereby realizing the parsing of the target request response data and the mapping of the parsed request response data with the front-end request, thereby accurately separating the request response data corresponding to each front-end request from a merged response data, and then accurately feeding back the response data.

[0086] Furthermore, in order to ensure the normal operation of the front-end and back-end communication process and to ensure the ability to automatically recover when an error occurs during operation, this embodiment also provides a method for handling abnormal request response scenarios. In an optional embodiment, after sending the target front-end request to the target back-end corresponding to the target front-end, it also includes: if the target front-end request failure alarm information is monitored, and the current monitoring number meets the preset number monitoring condition, then determine the reason for the request failure; generate an exception handling strategy based on the reason for the request failure, and resend the target front-end request to the target back-end based on the exception handling strategy.

[0087] When the number of concurrent requests to the target front-end is too large, it may cause the target front-end request to fail to be sent, and a sending failure alarm message will be generated. Among them, the preset number of monitoring conditions can be, for example, after the sending failure alarm message is monitored for the first time, the retry mechanism is started, that is, the target front-end request is resent. If the sending failure alarm message is received each time after the preset number of retries, the preset number of monitoring conditions is met. The preset number of retries can be pre-set by relevant technical personnel. For example, the preset number of retries can be 3 times.

[0088] Among them, the reason for the failure to send the request can be manually queried by relevant technical personnel, or it can be automatically queried using a preset automatic exception handling mechanism. If an automatic query mechanism is used, it is necessary to pre-store the anomaly detection strategy of the automatic exception handling mechanism. For example, the strategy can be a pre-trained anomaly detection model.

[0089] Based on the determined reason for the request failure, an exception handling strategy is generated. For example, if the request failure is due to network issues, the exception handling strategy is to wait for the network to stabilize and then resend the target front-end request. For another example, if the request failure is due to excessive request volume, the exception handling strategy is to reduce the request concurrency of the target front-end request and resend the request.

[0090] The above technical solution monitors the execution of the target front-end request, and determines the reason for the request sending failure when the target front-end request sending failure alarm information is monitored and the current monitoring number meets the preset number monitoring conditions. According to the reason for the request sending failure, an exception handling strategy is generated, and based on the exception handling strategy, the target front-end request is resent to the target back-end, thereby realizing the execution status monitoring of the request response during the front-end communication process, ensuring that it can be handled in time when an exception occurs in the request, and avoiding the situation where the request exception causes a response timeout.

[0091] It should be noted that the request success rate and network latency affect the efficiency of front-end requests, and the periodicity of sending front-end requests is related to a preset time interval. Therefore, to further improve the flexibility of sending front-end requests, the time interval can also be dynamically adjusted. In an optional embodiment, the request success rate over a historical time period is obtained; a first network status with the target front-end and a second network status with the target back-end are monitored; and the time interval is updated based on the request success rate, the first network status, and the second network status.

[0092] The request success rate is calculated based on the total number of requests and the number of successful requests in a historical time period; the network status may include network delay, network bandwidth, and network jitter frequency.

[0093] For example, if the request success rate is high, the network delay between the first network state and the second network state is low, the network bandwidth is high, and the network jitter frequency is low, a smaller time interval period can be set, such as 50ms to 100ms; if the request success rate is low, the network delay between the first network state and the second network state is high, the network bandwidth is low, and the network jitter frequency is high, a larger time interval period can be set, such as 150ms to 200ms.

[0094] The above technical solution obtains the request success rate under the historical time period, monitors the first network status with the target front end and the second network status with the target back end, and updates the time interval period according to the request success rate, the first network status and the second network status, thereby realizing the dynamic update of the time interval period. In the process of updating the time interval period, the request success rate, the network status with the current front end and the network status with the target back end are comprehensively considered, thereby improving the accuracy of determining the dynamically updated time interval period, thereby further improving the efficiency of responding to front-end and back-end communication requests.

[0095] Example 4

[0096] Figure 4 A schematic diagram of the structure of a front-end and back-end communication request response device provided in the fourth embodiment of the present invention. The front-end and back-end communication request response device provided in the embodiment of the present invention can be used to quickly respond to requests between front-end and back-end communications in business scenarios with a large amount of front-end and back-end request responses, such as in the financial field. The front-end and back-end communication request response device can be implemented in the form of hardware and / or software, such as Figure 4 As shown, the device includes: a front-end request interception module 401, an initial request selection module 402, a request merging module 403, a target request sending module 404 and a response data sending module 405.

[0097] The front-end request interception module 401 is used to intercept the front-end request of the target front-end, write the intercepted front-end request into a preset message queue, and generate a corresponding request identifier for the front-end request;

[0098] An initial request selection module 402 is configured to select a number of initial front-end requests that meet a preset time interval from the message queue;

[0099] A request merging module 403 is configured to select at least two front-end requests to be merged from each of the initial front-end requests, and merge the front-end requests to be merged based on the request identifiers of the front-end requests to be merged to obtain a target front-end request;

[0100] The target request sending module 404 is used to send the target front-end request to the target back-end corresponding to the target front-end, so that the target back-end generates target request response data based on the target front-end request;

[0101] The response data sending module 405 is used to feed back the target request response data to the target front end.

[0102] The technical solution of the embodiment of the present invention intercepts the front-end request of the target front-end and writes it into the message queue, generates the corresponding request identifier for the front-end request, selects the initial front-end request that meets the time interval period, selects the front-end request to be merged from each initial front-end request, and merges each front-end request to be merged based on the request identifier of each front-end request to obtain the target front-end request, sends the target front-end request to the target back-end corresponding to the target front-end so that the target back-end can generate the target request response data based on the target front-end request, and feeds back the target request response data to the target front-end. The above technical solution improves the efficiency of the front-end and back-end communication request response by merging a large number of front-end requests of the target front-end, and the target back-end processes the merged request and then responds, thereby improving the response speed of the front-end page. By reducing the actual number of requests and improving the response speed, the user experience of industry-related users using the target front-end page is significantly improved.

[0103] Optionally, request merging module 403, including:

[0104] a characteristic data determining unit, configured to determine a request type, request structure characteristic data, request priority, and request dependency data corresponding to each of the initial front-end requests;

[0105] a request-to-be-merged selection unit, configured to select at least two front-end requests to be merged from each of the initial front-end requests based on the request type, request structure feature data, request priority, and request dependency data respectively corresponding to each of the initial front-end requests;

[0106] The request merging unit is used to merge the front-end requests to be merged based on the request identifiers corresponding to the front-end requests to be merged to obtain the target front-end request.

[0107] Optional, select the unit of request to be merged, specifically used for:

[0108] Selecting a plurality of first intermediate requests of the same request type from each of the initial front-end requests;

[0109] determining request similarity of each of the first intermediate requests based on the request structure feature data of each of the first intermediate requests, and selecting a plurality of second intermediate requests from each of the first intermediate requests based on the request similarity;

[0110] At least two front-end requests to be merged are selected from each of the second intermediate requests according to the request priorities and request dependency data of the plurality of second intermediate requests.

[0111] Optionally, the device further includes:

[0112] A request association storage module is used to intercept the front-end request of the target front-end, write the intercepted front-end request into a preset message queue, and generate a corresponding request identifier for the front-end request, determine the request context data of each front-end request, and associate and store the request identifier of each front-end request with its corresponding request context data;

[0113] Accordingly, the response data sending module 405 is specifically configured to:

[0114] Parsing the target request response data to obtain request response data corresponding to each request identifier;

[0115] According to the association relationship between the stored request identifier and the request context data, the request response data corresponding to the front-end requests are determined, and the request response data are fed back to the target component that initiates the corresponding front-end request in the target front-end.

[0116] Optionally, the device further includes:

[0117] a failure cause determination module, configured to, after sending the target front-end request to the target back-end corresponding to the target front-end, determine a request sending failure cause if a sending failure alarm message of the target front-end request is detected and the current monitoring number meets a preset number monitoring condition;

[0118] The processing strategy generation module is used to generate an exception processing strategy according to the reason for the failure of the request sending, and resend the target front-end request to the target back-end based on the exception processing strategy.

[0119] Optionally, the device further includes:

[0120] The request success rate acquisition module is used to obtain the request success rate in the historical time period;

[0121] A network status monitoring module, configured to monitor a first network status with the target front end and a second network status with the target back end;

[0122] A time updating module is used to update the time interval period according to the request success rate, the first network status and the second network status.

[0123] The front-end and back-end communication request response device provided in the embodiment of the present invention can execute the front-end and back-end communication request response method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0124] Example 5

[0125] Figure 5 A schematic diagram of the structure of an electronic device 50 that can be used to implement an embodiment of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or claimed herein.

[0126] like Figure 5 As shown, the electronic device 50 includes at least one processor 51 and a memory, such as a read-only memory (ROM) 52, a random access memory (RAM) 53, etc., which is communicatively connected to the at least one processor 51. The memory stores a computer program that can be executed by the at least one processor. The processor 51 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 52 or the computer program loaded from the storage unit 58 into the random access memory (RAM) 53. Various programs and data required for the operation of the electronic device 50 can also be stored in the RAM 53. The processor 51, ROM 52, and RAM 53 are connected to each other via a bus 54. An input / output (I / O) interface 55 is also connected to the bus 54.

[0127] Multiple components in the electronic device 50 are connected to the I / O interface 55, including an input unit 56, such as a keyboard, a mouse, etc.; an output unit 57, such as various types of displays, speakers, etc.; a storage unit 58, such as a magnetic disk, an optical disk, etc.; and a communication unit 59, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 59 allows the electronic device 50 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0128] The processor 51 can be a variety of general-purpose and / or specialized processing components with processing and computing capabilities. Some examples of the processor 51 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various processors that run machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 51 executes the various methods and processes described above, such as the front-end and back-end communication request response method.

[0129] In some embodiments, the front-end and back-end communication request response method can be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as a storage unit 58. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 50 via the ROM 52 and / or the communication unit 59. When the computer program is loaded into the RAM 53 and executed by the processor 51, one or more steps of the front-end and back-end communication request response method described above can be performed. Alternatively, in other embodiments, the processor 51 can be configured to execute the front-end and back-end communication request response method in any other appropriate manner (for example, by means of firmware).

[0130] Various embodiments of the systems and techniques described herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip systems (SOCs), programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0131] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when the computer program is executed by the processor, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The computer program may be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0132] In the context of the present invention, computer-readable storage media can be tangible media that can contain or store a computer program for use with an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. Computer-readable storage media can include but are not limited to electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, computer-readable storage media can be machine-readable signal media. More specific examples of machine-readable storage media can include electrical connections based on one or more lines, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0133] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0134] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0135] A computing system may include clients and servers. The clients and servers are typically remote from each other and typically interact via a communication network. This client-server relationship arises through computer programs running on the respective computers, creating a client-server relationship. The server may be a cloud server, also known as a cloud computing server or cloud host. This server is a hosting product within the cloud computing service ecosystem that addresses the management difficulties and limited scalability of traditional physical hosting and VPS services.

[0136] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in the present invention can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of the present invention can be achieved. This is not limited herein.

[0137] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.

Claims

1. A front-end and back-end communication request response method, characterized in that: include: Intercept the front-end request of the target front-end, write the intercepted front-end request into a preset message queue, and generate a corresponding request identifier for the front-end request; Selecting a plurality of initial front-end requests that meet a preset time interval period from the message queue; Selecting at least two front-end requests to be merged from each of the initial front-end requests, and merging the front-end requests to be merged based on the request identifiers of each of the front-end requests to be merged to obtain a target front-end request; Sending the target front-end request to a target back-end corresponding to the target front-end, so that the target back-end generates target request response data based on the target front-end request; Feedback the target request response data to the target front end.

2. The method according to claim 1, characterized in that The selecting at least two front-end requests to be merged from each of the initial front-end requests, and merging the front-end requests to be merged based on the request identifiers of each of the front-end requests to be merged to obtain a target front-end request, includes: Determining the request type, request structure feature data, request priority, and request dependency data corresponding to each of the initial front-end requests; Selecting at least two front-end requests to be merged from each of the initial front-end requests according to the request type, request structure feature data, request priority, and request dependency data respectively corresponding to each of the initial front-end requests; Based on the request identifiers corresponding to the front-end requests to be merged, the front-end requests to be merged are merged to obtain the target front-end request.

3. The method according to claim 2, characterized in that The selecting at least two front-end requests to be merged from each of the initial front-end requests according to the request type, request structure feature data, request priority, and request dependency data respectively corresponding to each of the initial front-end requests includes: Selecting a plurality of first intermediate requests of the same request type from each of the initial front-end requests; determining request similarity of each of the first intermediate requests based on the request structure feature data of each of the first intermediate requests, and selecting a plurality of second intermediate requests from each of the first intermediate requests based on the request similarity; At least two front-end requests to be merged are selected from each of the second intermediate requests according to the request priorities and request dependency data of the plurality of second intermediate requests.

4. The method according to claim 1, wherein After intercepting the front-end request of the target front-end, writing the intercepted front-end request into a preset message queue, and generating a corresponding request identifier for the front-end request, the method further includes: Determining the request context data of each front-end request, and associating and storing the request identifier of each front-end request with the corresponding request context data; Accordingly, feeding back the target request response data to the target front end includes: Parsing the target request response data to obtain request response data corresponding to each request identifier; According to the association relationship between the stored request identifier and the request context data, the request response data corresponding to the front-end requests are determined, and the request response data are fed back to the target component that initiates the corresponding front-end request in the target front-end.

5. The method according to claim 1, wherein After sending the target front-end request to the target back-end corresponding to the target front-end, the method further includes: If a sending failure alarm message of the target front-end request is detected and the current monitoring times meet the preset times monitoring condition, the reason for the request sending failure is determined; An exception handling strategy is generated according to the reason for the request sending failure, and based on the exception handling strategy, the target front-end request is resent to the target back-end.

6. The method according to claim 1, characterized in that The method further comprises: Get the request success rate in the historical time period; monitoring a first network status with the target front end and a second network status with the target back end; The time interval period is updated according to the request success rate, the first network status, and the second network status.

7. A front-end and back-end communication request response device, characterized in that: include: The front-end request interception module is used to intercept the front-end request of the target front-end, write the intercepted front-end request into a preset message queue, and generate a corresponding request identifier for the front-end request; An initial request selection module, configured to select a number of initial front-end requests that meet a preset time interval period from the message queue; A request merging module, configured to select at least two front-end requests to be merged from each of the initial front-end requests, and merge the front-end requests to be merged based on the request identifiers of the front-end requests to be merged to obtain a target front-end request; A target request sending module, configured to send the target front-end request to a target back-end corresponding to the target front-end, so that the target back-end generates target request response data based on the target front-end request; The response data sending module is used to feed back the target request response data to the target front end.

8. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the front-end and back-end communication request response method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the front-end and back-end communication request response method according to any one of claims 1 to 6 when executed.

10. A computer program product, characterized in that The computer program product includes a computer program, and when the computer program is executed by a processor, the computer program implements the front-end and back-end communication request response method according to any one of claims 1 to 6.

Images