Method and apparatus for processing service request

Abstract

The application provides a service request processing method and device, and relates to the technical field of data processing. The method comprises the following steps: receiving a plurality of service request messages for requesting any type of service sent by at least one sending end, wherein the request header in the service request message is the request identifier of the sending end added when the sending end of the service is intercepted by a preset interception program; in the case that the request identifier of the sending end is identified based on the request header in the receiving end, the plurality of service request messages are screened based on a preset abnormal screening rule to determine an abnormal request message from the plurality of service request messages; and whether the request message from the at least one sending end is isolated is determined according to the number of the abnormal request message, so that any type of service of the sending end is isolated, the isolation granularity of the service is reduced, and the reliability of the service is improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method and apparatus for processing service requests. Background Technology

[0002] Currently, when service requests from the sending end connect to the receiving end, non-standard or excessively large service requests can cause exceptions during parsing or processing, leading to program crashes. Therefore, it is necessary to isolate abnormal service requests. Related technologies include methods where the sending end initiates different service requests, and the gateway, based on the type and address of the service request, distributes them to different receiving ends. For example, a service request from sender A is processed by receiver a, and a service request from sender B is processed by receiver b. In this scenario, if a problem occurs at sender A causing receiver a to malfunction, receiver b continues to operate normally. However, as the number of senders increases, the number of receivers inevitably increases, significantly increasing receiver costs and subsequent maintenance costs. Therefore, a more reliable method for isolating service requests is urgently needed. Summary of the Invention

[0003] The present invention aims to at least partially solve one of the technical problems in the related art.

[0004] Therefore, the first objective of this invention is to provide a service request processing method that isolates any type of service at the sending end, thereby reducing the granularity of service isolation and improving service reliability.

[0005] A second objective of the present invention is to provide a service request processing apparatus.

[0006] The third objective of this invention is to provide an electronic device.

[0007] The fourth objective of this invention is to provide a non-transitory computer-readable storage medium storing computer instructions.

[0008] The fifth objective of this invention is to provide a computer program product.

[0009] To achieve the above objectives, a first aspect of the present invention provides a method for processing service requests, comprising:

[0010] Receive multiple service request messages sent by at least one sender for requesting any type of service, wherein the request header in the service request message is a request identifier of the sender added by the sender when the service request message is intercepted by a preset interception program.

[0011] When the receiving end identifies the sending end to which the request identifier belongs based on the request header, it performs anomaly screening on the multiple service request messages based on preset anomaly screening rules to determine the abnormal request message from the multiple service request messages.

[0012] Based on the number of abnormal request messages, determine whether to isolate request messages from the at least one sender.

[0013] To achieve the above objectives, a second aspect of the present invention provides a service request processing apparatus, comprising:

[0014] A receiving module is configured to receive multiple service request messages sent by at least one sending end for requesting any type of service, wherein the request header in the service request message is a request identifier of the sending end added when the sending end of the service request message is intercepted by a preset interception program.

[0015] The screening module is used to perform anomaly screening on the multiple service request messages based on preset anomaly screening rules when the receiving end identifies the sending end to which the request identifier belongs based on the request header, so as to determine the abnormal request message from the multiple service request messages.

[0016] The determination module is used to determine whether to isolate request messages from the at least one sender based on the number of abnormal request messages.

[0017] To achieve the above objectives, a third aspect of the present invention provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method described in the first aspect.

[0018] To achieve the above objectives, a fourth aspect of the present invention provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the method described in the first aspect.

[0019] To achieve the above objectives, a fifth aspect of the present invention provides a computer program product that, when executed by a processor, implements the method described in the first aspect.

[0020] The service request processing method, apparatus, electronic device, and storage medium provided in this invention receive multiple service request messages from at least one sender requesting any type of service. The request header in each service request message is a request identifier added by the sender when the service request message is intercepted by a preset interception program. If the receiving end identifies the sender to which the request identifier belongs based on the request header, it performs anomaly screening on the multiple service request messages based on preset anomaly screening rules to identify abnormal request messages. Based on the number of abnormal request messages, it determines whether to isolate request messages from at least one sender. This isolates any type of service from the sender, reducing the granularity of service isolation and improving service reliability.

[0021] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0022] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0023] Figure 1 A flowchart illustrating a service request processing method provided in an embodiment of the present invention;

[0024] Figure 2 A flowchart illustrating another service request processing method provided in an embodiment of the present invention;

[0025] Figure 3 A flowchart illustrating another service request processing method provided in an embodiment of the present invention;

[0026] Figure 4 This is a schematic diagram of a service request processing device provided in an embodiment of the present invention. Detailed Implementation

[0027] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0028] It should be noted that the acquisition, storage, use, and processing of data in the technical solution of this invention all comply with the relevant provisions of national laws and regulations.

[0029] The method and apparatus for processing service requests according to embodiments of the present invention are described below with reference to the accompanying drawings.

[0030] Figure 1 This is a flowchart illustrating a service request processing method provided in an embodiment of the present invention.

[0031] like Figure 1 As shown, the method includes the following steps:

[0032] Step 101: Receive multiple service request messages sent by at least one sender for requesting any type of service. The request header in the service request message is a request identifier added by the sender when the service request message is intercepted by a preset interception program.

[0033] Optionally, the sending end can be a bank branch, but it is not limited to this, and this embodiment does not specifically limit it.

[0034] Optionally, any type of service may include, but is not limited to, financial services and information services; this embodiment does not specifically limit this.

[0035] Optionally, when multiple service request messages are transmitted via the Hypertext Transfer Protocol (HTTP), the request header can be an HTTP header, but is not limited to this.

[0036] In HTTP requests or responses, headers are fields used to convey additional information, modify the semantics of the message (or message body), or make it more precise. Message headers are case-insensitive, begin at the start of a line, and are followed by a colon (':') and its associated value. Field values ​​either precede a newline character (CRLF) or end at the end of the message.

[0037] Optionally, the preset interception program can be implemented by an interceptor that can be set at the sending end's output port to intercept service request messages and add the sending end's request identifier to the HTTP header.

[0038] Optionally, the request identifier of the sending end is determined based on the identity identifier of the sending end. For example, if the sending end is a bank branch, the branch code of the bank branch can be used as the request identifier, but it is not limited to this. This embodiment does not specifically limit it.

[0039] Step 102: If the receiving end identifies the sending end to which the request identifier belongs based on the request header, it performs anomaly screening on multiple service request messages based on preset anomaly screening rules in order to determine the abnormal request message from the multiple service request messages.

[0040] Optionally, the receiving end can be the head office of a bank, but it is not limited to this, and this embodiment does not specifically limit it.

[0041] Optionally, the preset anomaly screening rules can be determined by the target service request messages that the receiving end can process, but are not limited to this.

[0042] The target service request message may include target data format and target data content information.

[0043] In some embodiments, after determining the abnormal request information, the abnormal request message can also be recorded in a preset abnormal request table, and the abnormal request table can be displayed in the corresponding visualization platform of the receiving end, thereby facilitating the maintenance of abnormal request information in the later stage.

[0044] Understandably, when the sending end is a bank branch and the receiving end is the bank's head office, and the request identifier is the branch code of each bank branch, the recording method of the abnormal request table may include, but is not limited to, the branch code, the Uniform Resource Locator (URL), and the recording time, such as HB, / api / v1 / qryAcct, 2022-11-11 11:11:11.

[0045] Step 103: Determine whether to isolate request messages from at least one sender based on the number of abnormal request messages.

[0046] In some embodiments, determining whether to isolate request messages from at least one sender based on the number of abnormal request messages can be implemented by isolating service request messages from at least one sender to refuse service execution when the number of abnormal request messages is greater than or equal to a preset error screening threshold, and allowing service calls to respond to service request messages from at least one sender when the number of abnormal request messages is less than the preset error screening threshold, thereby achieving precise isolation of request messages from senders.

[0047] The preset error screening threshold is determined based on the number of abnormal request messages within multiple preset time intervals. For example, the error screening threshold (isolation percentage) = the number of abnormal request messages in the past day within this time interval / the number of abnormal request messages in the past week within this time interval, but it is not limited to this.

[0048] Optionally, the isolation format for isolating request messages from at least one sender can be line break encoding, time interval, URL, error screening threshold, isolation percentage, but is not limited to these, for example, HB, 11:00~12:00, / api / v1 / qryAcct, 20, 10%.

[0049] The service request processing method of this invention receives multiple service request messages from at least one sending end, requesting any type of service. The request header in each service request message is a request identifier added by the sending end when it intercepts the service request message using a preset interception program. If the receiving end identifies the sending end to which the request identifier belongs based on the request header, it performs anomaly screening on the multiple service request messages based on preset anomaly screening rules to identify abnormal request messages. Based on the number of abnormal request messages, it determines whether to isolate request messages from at least one sending end. This isolates any type of service from the sending end, reducing the granularity of service isolation and improving service reliability.

[0050] To clearly illustrate the previous embodiment, this embodiment also provides a method for processing service requests. Figure 2 This is a flowchart illustrating another service request processing method provided in an embodiment of the present invention.

[0051] like Figure 2 As shown, the method may include the following steps:

[0052] Step 201: Receive multiple service request messages sent by at least one sender for requesting any type of service. The request header in the service request message is a request identifier added by the sender when the service request message is intercepted by a preset interception program.

[0053] It should be noted that the specific implementation of step 201 can be found in the relevant description in the above embodiments.

[0054] Step 202: If the receiving end identifies the sending end to which the request identifier belongs based on the request header, obtain the data format and data content information of each service request message.

[0055] Optionally, the data format and content information of each service request message are generated by the sending end when making the request. Specifically, when the sending end is a bank branch, the service request information of the bank branch is bank data generated when the bank branch makes the request, wherein the bank data includes the format of the bank data and the content information of the bank data.

[0056] Step 203: Based on preset anomaly screening rules, perform anomaly screening on the data format and data content information of each service request message to obtain abnormal request messages among multiple service request messages.

[0057] In some embodiments, anomaly screening rules can be set based on the target data format and target data content information in the target service request message that the receiving end can process, thereby screening out abnormal request messages in multiple service request messages based on the differences between the target data format and target data content information and the data format and data content information.

[0058] Among them, service request messages with different target data formats and / or different target data content information and data content information can be regarded as abnormal request messages.

[0059] Specifically, when the sending end is a bank branch and the receiving end is the bank's head office, the target data format of the bank's head office service can be the request method, request address, URL, and target data content information, such as POST, 127.0.0.1:8080, / api / v1 / qryAcct, {"acctNo":"62123456"}.

[0060] Step 204: Determine whether to isolate request messages from at least one sender based on the number of abnormal request messages.

[0061] The service request processing method of this invention receives multiple service request messages from at least one sending end, requesting any type of service. The request header in each service request message is a request identifier added by the sending end when the service request message is intercepted by a preset interception program. When the receiving end identifies the sending end to which the request identifier belongs based on the request header, it obtains the data format and data content information of each service request message. Based on preset anomaly screening rules, it performs anomaly screening on the data format and data content information of each service request message to obtain abnormal request messages among the multiple service request messages. Based on the number of abnormal request messages, it determines whether to isolate the request messages from at least one sending end. Thus, based on the data format and data content information in the multiple service request messages sent by the sending end for requesting any type of service, it processes any type of service from the sending end, achieving precise isolation of any type of service.

[0062] In summary, to better understand this invention, embodiments of the invention also provide a flowchart illustrating another service request processing method, where the sending end consists of multiple bank branches (bank branch 1...bank branch n), and the receiving end is the bank's head office. Figure 3As shown, specifically, the system receives multiple service request messages from bank branches 1 to n, requesting any type of service, and transmits these messages via HTTP. Once the receiving end identifies the sender of the request based on the request header in the service request message, it processes the multiple service request messages and saves the processing results in the database (DB).

[0063] To implement the above embodiments, the present invention also proposes a service request processing apparatus.

[0064] Figure 4 This is a schematic diagram of a service request processing device provided in an embodiment of the present invention.

[0065] like Figure 4 As shown, the service request processing device 40 includes: a receiving module 41, a screening module 42, and a determining module 43.

[0066] The receiving module 41 is used to receive multiple service request messages sent by at least one sending end for requesting any type of service, wherein the request header in the service request message is a request identifier of the sending end added when the sending end of the service is intercepted by a preset interception program.

[0067] The screening module 42 is used to perform anomaly screening on the multiple service request messages based on preset anomaly screening rules when the receiving end identifies the sending end to which the request identifier belongs based on the request header, so as to determine the abnormal request message from the multiple service request messages.

[0068] The determination module 43 is used to determine whether to isolate request messages from the at least one sender based on the number of abnormal request messages.

[0069] Furthermore, in one possible implementation of this invention, the screening module 42 is specifically used for:

[0070] When the receiving end identifies the sending end to which the request identifier belongs based on the request header, it obtains the data format and data content information of each service request message;

[0071] Based on preset anomaly screening rules, anomaly screening is performed on the data format and data content information of each service request message to obtain abnormal request messages among multiple service request messages.

[0072] Furthermore, in one possible implementation of this invention, the preset anomaly screening rule is determined based on the target data format and target data content information that the receiving end can process.

[0073] Furthermore, in one possible implementation of this invention, the determining module 43 is specifically used for:

[0074] If the number of abnormal request messages is greater than or equal to a preset error screening threshold, service request messages from at least one sender are isolated to refuse to execute the service.

[0075] If the number of abnormal request messages is less than the preset error screening threshold, the service response from the at least one sender is allowed to be invoked.

[0076] Furthermore, in one possible implementation of this invention, the preset error screening threshold is determined based on the number of abnormal request messages within multiple preset time intervals.

[0077] Furthermore, in one possible implementation of this invention, the request identifier of the sending end is determined based on the identity identifier of the sending end.

[0078] Based on the above embodiments, this embodiment of the invention also provides a possible implementation of a service request processing device, which, based on the previous embodiment, further includes:

[0079] The recording module is used to record the abnormal request message in a preset abnormal request table, so as to display the abnormal request table in the visualization platform corresponding to the receiving end.

[0080] The service request processing apparatus of this invention receives multiple service request messages from at least one sending end, requesting any type of service. The request header in each service request message is a request identifier added by the sending end when it intercepts the service request message using a preset interception program. If the receiving end identifies the sending end to which the request identifier belongs based on the request header, it performs anomaly screening on the multiple service request messages based on preset anomaly screening rules to identify abnormal request messages. Based on the number of abnormal request messages, it determines whether to isolate request messages from at least one sending end. This isolates any type of service from the sending end, reducing the granularity of service isolation and improving service reliability.

[0081] To achieve the above embodiments, the present invention also proposes an electronic device, comprising:

[0082] At least one processor; and

[0083] A memory communicatively connected to the at least one processor; wherein,

[0084] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the aforementioned method.

[0085] To implement the above embodiments, the present invention also proposes a non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the aforementioned method.

[0086] To implement the above embodiments, the present invention also proposes a computer program product, including a computer program that, when executed by a processor, implements the method described above.

[0087] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0088] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0089] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of the invention pertain.

[0090] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0091] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any of the following techniques known in the art, or a combination thereof: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0092] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0093] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0094] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention.

Claims

1. A method of processing a service request, characterized by, The method comprises: receiving a plurality of service request messages sent by at least one sending end for requesting any type of service, wherein a request header in the service request message is added with a request identifier of the sending end when the sending end sending the service is intercepted by a preset interception program, wherein the request identifier of the sending end is determined based on the identity of the sending end, and in the case that the sending end is a branch of a bank, the branch code of the branch of the bank is taken as the request identifier; in the case that the request identifier of the sending end is identified based on the request header at the receiving end, the plurality of service request messages are screened based on a preset abnormality screening rule to determine abnormal request messages from the plurality of service request messages; determining whether to isolate the request messages from the at least one sending end according to the number of abnormal request messages, wherein one isolation format of the request messages from the at least one sending end includes branch code, time interval, URL, error screening threshold, and isolation percentage.

2. The method of claim 1, wherein in the case that the request identifier of the sending end is identified based on the request header at the receiving end, the plurality of service request messages are screened based on a preset abnormality screening rule to determine abnormal request messages from the plurality of service request messages, comprising: in the case that the request identifier of the sending end is identified based on the request header at the receiving end, obtaining data format and data content information of each service request message; screening the data format and data content information of each service request message based on a preset abnormality screening rule to obtain abnormal request messages in the plurality of service request messages.

3. The method of claim 2, wherein, The preset abnormality screening rule is determined based on target data format and target data content information that can be processed by the receiving end.

4. The method of claim 1, wherein, The determination of whether to isolate the request messages from the at least one sending end according to the number of abnormal request messages comprises: in the case that the number of abnormal request messages is greater than or equal to a preset error screening threshold, isolating the service request messages from the at least one sending end to reject to execute the service; in the case that the number of abnormal request messages is less than the preset error screening threshold, allowing to call the service to respond to the service request messages from the at least one sending end.

5. The method of claim 4, wherein, The preset error screening threshold is determined based on the number of abnormal request messages in a plurality of preset time intervals.

6. The method of claim 1, wherein, The method further comprises: recording the abnormal request messages in a preset abnormal request table to display the abnormal request table in a visual platform corresponding to the receiving end.

7. A service request processing apparatus characterized by comprising: The device comprises: receive a plurality of service request messages for requesting any type of service sent by at least one sending end, wherein a request header in the service request message is added by a preset interception program when the service request message is intercepted by the sending end sending the service, and the request header is a request identifier of the sending end, wherein the request identifier of the sending end is determined based on an identity of the sending end, and in the case that the sending end is a branch of a bank, a branch code of the branch of the bank is used as the request identifier; screening module, configured to, in the case that the request identifier of the sending end is identified based on the request header at the receiving end, perform abnormal screening on the plurality of service request messages based on a preset abnormal screening rule, to determine an abnormal request message from the plurality of service request messages; determination module, configured to determine whether to isolate the request message from the at least one sending end according to the number of abnormal request messages, wherein an isolation format of the request message from the at least one sending end includes a branch code, a time interval, a URL, an error screening threshold, and an isolation percentage.

8. The apparatus of claim 7, wherein the screening module is specifically configured to: in the case that the request identifier of the sending end is identified based on the request header at the receiving end, obtain data format and data content information of each service request message; perform abnormal screening on the data format and data content information of each service request message based on a preset abnormal screening rule, to obtain an abnormal request message from the plurality of service request messages.

9. The apparatus of claim 8, wherein, The preset abnormal screening rule is determined based on target data format and target data content information that can be processed by the receiving end.

10. The apparatus of claim 7, wherein, The determination module is specifically configured to: in the case that the number of abnormal request messages is greater than or equal to a preset error screening threshold, isolate the service request message from the at least one sending end to reject to execute the service; in the case that the number of abnormal request messages is less than the preset error screening threshold, allow to call the service to respond to the service request message from the at least one sending end.

11. The apparatus of claim 10, wherein, The preset error screening threshold is determined based on the number of abnormal request messages in a plurality of preset time intervals.

12. The apparatus of claim 7, wherein, The apparatus further comprises: a recording module, configured to record the abnormal request message in a preset abnormal request table, and display the abnormal request table in a visual platform corresponding to the receiving end.

13. An electronic device, comprising: comprises: at least one processor; and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method of any one of claims 1-6.

14. A non-transitory computer-readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to enable the computer to execute the method of any one of claims 1-6.

15. A computer program product, characterised in that, The computer program, when executed by the processor, implements the method of any one of claims 1-6.

Images