Service request processing method and device, computer equipment and storage medium

Abstract

The invention belongs to the field of data processing and financial science and technology, and relates to a service request processing method and device, computer equipment and a storage medium, and the method comprises the steps: judging whether a service request sent by a client is received in a target interface or not; if yes, intercepting the service request based on the target tangent plane, and extracting a token from the service request; performing legal verification on the token based on the authentication center; if the token passes the legal verification, acquiring a lock from the distributed lock service, and receiving a lock acquisition result returned by the distributed lock service; if the lock acquisition result is that the lock is successfully acquired, executing business logic processing corresponding to the service request based on the target interface to obtain a processing result; constructing a corresponding response object based on the processing result; and returning the response object to the client. In addition, the response object may be stored in the blockchain. According to the method and the device, repeated execution of the request in the service calling process of the micro-service can be effectively ensured, and correctness and consistency of service request processing are ensured.

Description

Technical Field

[0001] The present application relates to the fields of data processing technology and financial technology, and in particular to methods, devices, computer equipment and storage media for processing service requests. Background Art

[0002] With the rapid development of information technology, especially the widespread application of cloud computing, big data and Internet of Things technologies, software system architecture is undergoing a profound transformation from monolithic architecture to distributed architecture and even microservice architecture. Microservice architecture has become the preferred solution for building complex and large-scale application systems with its high modularity, scalability and flexibility. In the microservice architecture, the system is divided into a series of small services that are independently deployed, independently expanded, and built around business capabilities. These services collaborate with each other through lightweight communication mechanisms (such as RESTful API, gRPC, etc.) to jointly support the functions of the entire system.

[0003] However, while microservice architecture brings many advantages, it also introduces new challenges, especially in the communication and calling process between services. Since services are distributed on different physical or logical nodes and interact through the network, they are inevitably affected by network delays, service unavailability, message loss or duplication, etc. Especially in high-concurrency and high-load scenarios, these problems may be more prominent, resulting in uncertainty in service calls, which in turn triggers a series of chain reactions, such as request retries and repeated message consumption.

[0004] In key business scenarios involving financial transactions, order processing, inventory management, etc., repeated execution of requests is particularly fatal. Take payment transactions as an example. If payment requests are sent to the payment system multiple times due to network jitter or temporary service unavailability, and the payment system fails to effectively identify and process these repeated requests, it may cause repeated deductions or overpayments of user funds, seriously damaging user interests and corporate reputation. In addition, repeated operations may also cause data inconsistency, business logic confusion and other problems, posing a serious threat to the stability and reliability of the system.

[0005] Therefore, how to effectively prevent repeated execution of requests during service calls under a microservice architecture and ensure the correctness and consistency of business processing has become a technical problem that needs to be solved urgently. Summary of the invention

[0006] The purpose of the embodiments of the present application is to propose a method, apparatus, computer device and storage medium for processing service requests to solve the technical problem of how to effectively prevent repeated execution of requests during service calls under a microservice architecture and ensure the correctness and consistency of business processing.

[0007] In order to solve the above technical problems, the embodiment of the present application provides a method for processing a service request, which adopts the following technical solution:

[0008] Determine whether a service request issued by a client is received in a target interface; wherein the target interface is an interface with a preset idempotent annotation added, and the service request carries a token;

[0009] If so, intercept the service request based on a preset target aspect, and extract the token from the service request;

[0010] Performing a legal verification on the token based on a preset authentication center;

[0011] If the token passes the legal verification, the lock is acquired from the preset distributed lock service, and the lock acquisition result returned by the distributed lock service is received;

[0012] If the lock acquisition result is that the lock is acquired successfully, then executing the business logic processing corresponding to the service request based on the target interface to obtain the corresponding processing result;

[0013] Constructing a corresponding response object based on the processing result;

[0014] Return the response object to the client.

[0015] Furthermore, the step of verifying the legitimacy of the token based on a preset authentication center specifically includes:

[0016] Call the preset HTTP client;

[0017] generating a verification request corresponding to the token;

[0018] Based on the HTTP client, sending the verification request to the authentication center;

[0019] Receiving a response result corresponding to the verification request returned by the authentication center;

[0020] Parsing the response result to obtain a corresponding parsing result;

[0021] Based on preset verification rules, the token is verified to be legal using the parsing result to obtain a legal verification result corresponding to the token.

[0022] Furthermore, the step of constructing a corresponding response object based on the processing result specifically includes:

[0023] Generate a corresponding status code, response message and response body based on the processing result;

[0024] Integrate the status code, the response message and the response body to obtain corresponding integrated information;

[0025] The integrated information is used as the response object.

[0026] Furthermore, before the step of determining whether the service request sent by the client is received in the target interface, the method further includes:

[0027] Determine whether a token acquisition request sent by the client is received;

[0028] If so, calling the authentication center;

[0029] Generate a token corresponding to the client based on the authentication center;

[0030] The token is sent to the client.

[0031] Furthermore, after the step of verifying the legitimacy of the token based on the preset authentication center, the method further includes:

[0032] If the token fails the legal verification, a corresponding token authentication failure message is generated;

[0033] Obtaining preset first auxiliary processing information;

[0034] The token authentication failure information and the first auxiliary processing information are returned to the client.

[0035] Furthermore, after the step of acquiring a lock from a preset distributed lock service and receiving a lock acquisition result returned by the distributed lock service, the method further includes:

[0036] If the lock acquisition result is a failure to acquire the lock, generating an error response message corresponding to the lock acquisition result;

[0037] Obtaining preset second auxiliary processing information;

[0038] The error response information and the second auxiliary processing information are returned to the client.

[0039] Further, after the step of executing the business logic processing corresponding to the service request based on the target interface to obtain the corresponding processing result, it also includes:

[0040] Get the preset delete lock key command;

[0041] The delete lock key command is sent to the distributed lock service.

[0042] In order to solve the above technical problems, the embodiment of the present application further provides a device for processing a service request, which adopts the following technical solution:

[0043] A first judgment module is used to judge whether a service request issued by a client is received in a target interface; wherein the target interface is an interface with a preset idempotent annotation added, and the service request carries a token;

[0044] An interception module, for intercepting the service request based on a preset target aspect and extracting the token from the service request;

[0045] A verification module, used to verify the legitimacy of the token based on a preset authentication center;

[0046] A receiving module, configured to obtain a lock from a preset distributed lock service if the token passes legal verification, and receive a lock acquisition result returned by the distributed lock service;

[0047] An execution module, configured to execute a business logic process corresponding to the service request based on the target interface to obtain a corresponding processing result if the lock acquisition result is that the lock is successfully acquired;

[0048] A construction module, used to construct a corresponding response object based on the processing result;

[0049] The first returning module is used to return the response object to the client.

[0050] In order to solve the above technical problems, the embodiment of the present application further provides a computer device, which adopts the following technical solution:

[0051] If so, determine whether a service request issued by the client is received in the target interface; wherein the target interface is an interface with a preset idempotent annotation added, and the service request carries a token;

[0052] Intercepting the service request based on a preset target aspect, and extracting the token from the service request;

[0053] Performing a legal verification on the token based on a preset authentication center;

[0054] If the token passes the legal verification, the lock is acquired from the preset distributed lock service, and the lock acquisition result returned by the distributed lock service is received;

[0055] If the lock acquisition result is that the lock is acquired successfully, then executing the business logic processing corresponding to the service request based on the target interface to obtain the corresponding processing result;

[0056] Constructing a corresponding response object based on the processing result;

[0057] Return the response object to the client.

[0058] In order to solve the above technical problems, the embodiment of the present application further provides a computer-readable storage medium, which adopts the following technical solution:

[0059] Determine whether a service request issued by a client is received in a target interface; wherein the target interface is an interface with a preset idempotent annotation added, and the service request carries a token;

[0060] If so, intercept the service request based on a preset target aspect, and extract the token from the service request;

[0061] Performing a legal verification on the token based on a preset authentication center;

[0062] If the token passes the legal verification, the lock is acquired from the preset distributed lock service, and the lock acquisition result returned by the distributed lock service is received;

[0063] If the lock acquisition result is that the lock is acquired successfully, then executing the business logic processing corresponding to the service request based on the target interface to obtain the corresponding processing result;

[0064] Constructing a corresponding response object based on the processing result;

[0065] Return the response object to the client.

[0066] Compared with the prior art, the embodiments of the present application have the following beneficial effects:

[0067] The present application first determines whether a service request issued by a client is received in the target interface; wherein the target interface is an interface with a preset idempotent annotation added, and the service request carries a token; if so, the service request is intercepted based on the preset target aspect, and the token is extracted from the service request; then the token is legally verified based on the preset authentication center; if the token passes the legal verification, the lock is acquired from the preset distributed lock service, and the lock acquisition result returned by the distributed lock service is received; if the lock acquisition result is that the lock is acquired successfully, the business logic processing corresponding to the service request is executed based on the target interface to obtain the corresponding processing result; subsequently, the corresponding response object is constructed based on the processing result; finally, the response object is returned to the client. When the present application receives a service request issued by a client, the pluggable idempotent operation of the target interface is realized by combining the target aspect, the authentication center and the distributed lock service, thereby ensuring the repeated execution of requests in the service call process of the microservice, effectively ensuring the correctness and consistency of the service request processing, and ensuring the stability and reliability of the microservice. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] In order to more clearly illustrate the scheme in the present application, a brief introduction is given below to the drawings required for use in the description of the embodiments of the present application. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0069] Figure 1 is an exemplary system architecture diagram to which the present application may be applied;

[0070] Figure 2 A flowchart of an embodiment of a method for processing a service request according to the present application;

[0071] Figure 3 is a structural diagram of an embodiment of a device for processing a service request according to the present application;

[0072] Figure 4 It is a structural diagram of an embodiment of a computer device according to the present application. DETAILED DESCRIPTION

[0073] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by technicians in the technical field of the present application; the terms used in the specification of the application herein are only for the purpose of describing specific embodiments and are not intended to limit the present application; the terms "including" and "having" and any variations thereof in the specification and claims of the present application and the above-mentioned drawings are intended to cover non-exclusive inclusions. The terms "first", "second", etc. in the specification and claims of the present application or the above-mentioned drawings are used to distinguish different objects, not to describe a specific order.

[0074] Reference to "embodiments" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0075] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings.

[0076] like Figure 1 As shown, the system architecture 100 may include a terminal device 101, a network 102 and a server 103. The terminal device 101 may be a laptop 1011, a tablet computer 1012 or a mobile phone 1013. The network 102 is used to provide a medium for a communication link between the terminal device 101 and the server 103. The network 102 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0077] The user can use the terminal device 101 to interact with the server 103 through the network 102 to receive or send messages, etc. Various communication client applications can be installed on the terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0078] The terminal device 101 can be any electronic device with a display screen and supporting web browsing. In addition to the laptop computer 1011, tablet computer 1012 or mobile phone 1013, the terminal device 101 can also be an e-book reader, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 (Moving Picture Experts Group Audio Layer IV), a laptop computer, a desktop computer, etc.

[0079] The server 103 may be a server that provides various services, such as a background server that provides support for a web page displayed on the terminal device 101 .

[0080] It should be noted that the service request processing method provided in the embodiment of the present application is generally executed by a server / terminal device, and accordingly, the service request processing device is generally set in the server / terminal device.

[0081] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0082] Continue to refer Figure 2 , showing a flowchart of an embodiment of a method for processing a service request according to the present application. According to different requirements, the order of the steps in the flowchart can be changed, and some steps can be omitted. The method for processing a service request provided in the embodiment of the present application can be applied to any scenario where service request processing is required, and the method for processing a service request can be applied to products in these scenarios, for example, service request processing in the financial insurance field. The method for processing a service request comprises the following steps:

[0083] Step S201, determining whether a service request issued by a client is received in a target interface; wherein the target interface is an interface with a preset idempotent annotation added, and the service request carries a token.

[0084] In this embodiment, the service request processing method is executed on the electronic device (eg Figure 1The server / terminal device shown in the figure) can obtain the service request through a wired connection or a wireless connection. It should be noted that the above-mentioned wireless connection methods may include but are not limited to 3G / 4G / 5G connection, WiFi connection, Bluetooth connection, WiMAX connection, Zigbee connection, UWB (ultra wideband) connection, and other wireless connection methods currently known or to be developed in the future. The executor of the present application may specifically be a microservice. The above-mentioned target interface is an interface with an idempotent annotation added to the microservice, that is, the above-mentioned target interface is an interface with the @Idempotence annotation added. The pluggable idempotent operation of the API interface can be achieved by introducing the @Idempotence annotation on the API interface that needs to achieve idempotence.

[0085] Specifically, the annotation content of the above @Idempotence annotation may include:

[0086] @GetMapping(" / upload")

[0087] @Idempotence

[0088] Public Share uploadRepoprt(@PathVariable Integer id,HttpServletRequest request){

[0089] In the business scenario of financial insurance data query, the service request may be a query request for financial data by calling a microservice, and the financial data may include transaction data, payment data, business data, etc. The token may be represented by Token.

[0090] Step S202: If yes, intercept the service request based on a preset target aspect, and extract the token from the service request.

[0091] In this embodiment, the target aspect specifically adopts AOP (Aspect Oriented Programming). In the microservice, an aspect is defined by using AOP (such as Spring AOP), which intercepts all methods annotated with @Idempotence. A pointcut expression is defined in the aspect to match all methods annotated with @Idempotence.

[0092] Step S203: verify the legitimacy of the token based on a preset authentication center.

[0093] In this embodiment, the authentication center may specifically adopt JWT authentication center (JSON Web Token). The specific implementation process of the above-mentioned authentication center based on the preset authentication center to verify the legality of the token will be further described in detail in the subsequent specific embodiments of this application, and will not be elaborated here.

[0094] Step S204: if the token passes the legal verification, a lock is acquired from a preset distributed lock service, and a lock acquisition result returned by the distributed lock service is received.

[0095] In this embodiment, the above-mentioned distributed lock service can specifically adopt a distributed lock service based on Redis. Specifically, the process of obtaining a lock from a distributed lock service includes: Logic in the AOP aspect: In the before advice of the AOP aspect, immediately after the Token verification is passed, add the logic of obtaining a distributed lock. Distributed lock client: Use a Redis client library (such as Jedis, Lettuce or Spring Data Redis) to interact with the distributed lock service. Generation of lock keys: Generate a unique lock key based on certain unique identifiers of the target interface (such as request path, request parameters, user ID, etc.). This helps ensure that locks are managed correctly even for different interface requests. Try to obtain the lock: Use an atomic operation of Redis (such as SETNX, SET commands with Lua scripts or distributed lock implementations provided by Redis client libraries such as Redisson and Jedis) to try to obtain the lock. If the lock is already held by other requests, the operation will fail.

[0096] Step S205: If the lock acquisition result is that the lock is successfully acquired, the business logic processing corresponding to the service request is executed based on the target interface to obtain the corresponding processing result.

[0097] In this embodiment, if the lock acquisition result is that the lock is successfully acquired, the service request is allowed to continue to execute the business logic part of the target interface. Specifically, since the distributed lock has been successfully acquired, the business logic of the target interface can be safely executed. According to the specific requirements of the service request, the target interface is controlled to execute the corresponding business logic, such as database operations, calculations, calling other services, etc., and obtain the corresponding processing results.

[0098] Step S206: construct a corresponding response object based on the processing result.

[0099] In this embodiment, the specific implementation process of constructing the corresponding response object based on the processing result will be further described in detail in subsequent specific embodiments of the present application, and will not be elaborated on here.

[0100] Step S207: returning the response object to the client.

[0101] In this embodiment, the constructed response object may be sent to the client via HTTP response.

[0102] The present application first determines whether a service request issued by a client is received in the target interface; wherein the target interface is an interface with a preset idempotent annotation added, and the service request carries a token; if so, the service request is intercepted based on the preset target aspect, and the token is extracted from the service request; then the token is legally verified based on the preset authentication center; if the token passes the legal verification, the lock is acquired from the preset distributed lock service, and the lock acquisition result returned by the distributed lock service is received; if the lock acquisition result is that the lock is acquired successfully, the business logic processing corresponding to the service request is executed based on the target interface to obtain the corresponding processing result; subsequently, the corresponding response object is constructed based on the processing result; finally, the response object is returned to the client. When the present application receives a service request issued by a client, the pluggable idempotent operation of the target interface is realized by combining the target aspect, the authentication center and the distributed lock service, thereby ensuring the repeated execution of requests in the service call process of the microservice, effectively ensuring the correctness and consistency of the service request processing, and ensuring the stability and reliability of the microservice.

[0103] In some optional implementations, step S203 includes the following steps:

[0104] Call the default HTTP client.

[0105] In this embodiment, an HTTP client (such as RestTemplate, WebClient or Feign client) is configured in the microservice in advance, so that a request can be sent to the authentication center by using the configured HTTP client later.

[0106] A verification request corresponding to the token is generated.

[0107] In this embodiment, the verification request is a request including the token. The verification request can usually be a GET or POST request, depending on the API design of the authentication center. The verification request includes the token as a query parameter, a request header, or a part of the request body.

[0108] Based on the HTTP client, the verification request is sent to the authentication center.

[0109] In this embodiment, an HTTP client may be used to send a verification request including a token to an authentication center in a pre-notification of the target aspect.

[0110] Receive a response result corresponding to the verification request returned by the authentication center.

[0111] In this embodiment, after receiving the verification request, the authentication center will verify the token included in the verification request and return a corresponding response result. The response result is a result indicating whether the token is valid.

[0112] The response result is parsed to obtain a corresponding parsing result.

[0113] In this embodiment, by parsing the response result, data such as the signature, issuer, audience, and expiration time of the token are obtained.

[0114] Based on preset verification rules, the token is verified to be legal using the parsing result to obtain a legal verification result corresponding to the token.

[0115] In the present embodiment, the above verification rules are pre-built rules for validating the token. Specifically, the data such as the signature, issuer, audience and expiration time of the token can be verified, and whether the signature, issuer, audience and expiration time of the token match the preset normal data. If the signature, issuer, audience and expiration time of the token match the normal data, the token is determined to have passed the legal verification, and a legal verification result indicating that the token has passed the legal verification is generated. If at least one of the signature, issuer, audience and expiration time of the token does not match the corresponding normal data (for example, the signature does not match, the issuer does not match, the audience does not match, and the expiration time has expired), the token is determined to have failed the legal verification, and a legal verification result indicating that the token has failed the legal verification is generated.

[0116] This application generates a verification request for a token, and uses an HTTP client to send the verification request to an authentication center, and then receives a response result corresponding to the verification request returned by the authentication center, and then parses the response result to obtain a corresponding parsing result; finally, based on a preset verification rule, uses the parsing result to perform a legal verification on the token, and obtains a legal verification result corresponding to the token. This application generates a verification request for a token, and uses an HTTP client to send the verification request to an authentication center, and then receives a response result corresponding to the verification request returned by the authentication center, and parses the response result to obtain a parsing result, and then based on the verification rule, uses the parsing result to perform a legal verification on the token, thereby achieving rapid and accurate acquisition of a legal verification result corresponding to the token, improving the processing efficiency and accuracy of the legal verification of the token, and improving the accuracy of the generated legal verification result.

[0117] In some optional implementations of this embodiment, step S206 includes the following steps:

[0118] A corresponding status code, response message and response body are generated based on the processing result.

[0119] In this embodiment, the above status code may include HTTP 200OK, 400Bad Request, etc., and the response body includes the result of the business logic processing.

[0120] The status code, the response message and the response body are integrated to obtain corresponding integrated information.

[0121] In this embodiment, the corresponding integrated information can be obtained by calling a preset data integration tool and integrating the status code, the response message and the response body using a combination operation in the data integration tool. The data integration tool is a tool with a combination operation function.

[0122] The integrated information is used as the response object.

[0123] In this embodiment, the constructed response object is sent to the client via HTTP response. Specifically, this can be achieved by adding the @ResponseBody annotation to the Controller method or the @RestController annotation to the Controller class. In this way, Spring will automatically serialize the return value of the method into JSON or other formats and write it into the HTTP response body.

[0124] The present application generates a corresponding status code, a response message, and a response body based on the processing result; then integrates the status code, the response message, and the response body to obtain corresponding integrated information; and subsequently uses the integrated information as the response object. The present application generates a corresponding status code, a response message, and a response body based on the processing result, and then integrates the status code, the response message, and the response body to achieve fast and intelligent construction of a response object corresponding to the processing result, thereby improving the construction efficiency of the response object and ensuring the accuracy of the obtained response object.

[0125] In some optional implementations, before step S201, the electronic device may further perform the following steps:

[0126] Determine whether a token acquisition request sent by the client is received.

[0127] In this embodiment, it can be determined whether the token acquisition request sent by the client is received in the preset token providing interface. The client can call the token providing interface and issue a corresponding token acquisition request.

[0128] If so, call the authentication center.

[0129] In this embodiment, the above-mentioned authentication center may specifically adopt a JWT authentication center.

[0130] A token corresponding to the client is generated based on the authentication center.

[0131] In this embodiment, the process of generating a token corresponding to the client based on the authentication center includes: by calling the service of the JWT authentication center, the JWT authentication center uses a key (such as an HMAC key or an RSA private key) and a JWT library (such as JJWT in Java or Nimbus JOSE+JWT) to generate a new JWT Token. The Token contains some claims, such as user ID, expiration time, issuer, etc., as well as a signature. Then set the Token validity: When generating a Token, the JWT authentication center will set an expiration time, which can be fixed or based on certain business logic (such as dynamically set according to user permissions or request type).

[0132] The token is sent to the client.

[0133] In this embodiment, the generated Token (i.e., token) is returned to the client as a response body or a response header. The Token is returned as part of a JSON object, which only contains a Token string.

[0134] This application determines whether a token acquisition request sent by the client is received; if so, calls the authentication center; then generates a token corresponding to the client based on the authentication center; and subsequently sends the token to the client. After receiving the token acquisition request sent by the client, this application will intelligently call the authentication center to generate a token corresponding to the client, and send the token to the client, so that the rationality of the token in the service request sent by the client can be identified later, so as to achieve accurate processing of the service request, thereby avoiding repeated processing of the request, and effectively improving the processing intelligence and accuracy of the service request.

[0135] In some optional implementations, after step S203, the electronic device may further perform the following steps:

[0136] If the token fails the legal verification, corresponding token authentication failure information is generated.

[0137] In this embodiment, if the token fails to pass the legal verification (such as the signature in the token does not match, has expired, the issuer does not match, etc.), the abnormal information corresponding to the token is obtained, such as the signature does not match, has expired, the issuer does not match, etc., and the abnormal information is filled into the preset token authentication failure information template to generate the corresponding token authentication failure information. Among them, the content of the above-mentioned token authentication failure information template can be set according to the actual business processing requirements.

[0138] Obtain preset first auxiliary processing information.

[0139] In this embodiment, in the process of sending the token authentication failure information, some additional information, such as the retry time interval or the request ID, can also be sent at the same time as the first auxiliary processing information to help the client to retry or debug.

[0140] The token authentication failure information and the first auxiliary processing information are returned to the client.

[0141] In this embodiment, the token authentication failure information and the first auxiliary processing information may be returned to the client by using the exception advice of the target aspect or directly in the pre-notification.

[0142] If the present application detects that the token has not passed the legal verification, it will generate corresponding token authentication failure information; then obtain the preset first auxiliary processing information; and subsequently return the token authentication failure information and the first auxiliary processing information to the client. When the present application performs a legal verification on the token based on a preset authentication center, if it is detected that the token has not passed the legal verification, it will intelligently generate corresponding token authentication failure information, obtain the preset first auxiliary processing information, and then return the token authentication failure information and the first auxiliary processing information to the client, so that the relevant user can promptly understand the cause of the abnormal service request processing by consulting the token authentication failure information received in the client, and perform corresponding retries or debugging by consulting the first auxiliary processing information received in the client, which effectively improves the user experience.

[0143] In some optional implementations of this embodiment, after step S204, the electronic device may further perform the following steps:

[0144] If the lock acquisition result is a failure to acquire the lock, an error response message corresponding to the lock acquisition result is generated.

[0145] In this embodiment, if the content of the lock acquisition result is a failure to acquire the lock (indicating that other requests are being processed), a corresponding error response information is constructed, such as HTTP 429 Too Many Requests or a custom status code.

[0146] Obtain preset second auxiliary processing information.

[0147] In this embodiment, in the process of sending the error response information, some additional information, such as a retry time interval or a request ID, may also be sent simultaneously as the second auxiliary processing information to help the client to retry or debug.

[0148] The error response information and the second auxiliary processing information are returned to the client.

[0149] In this embodiment, the error response information and the second auxiliary processing information may be returned to the client by using the exception notification of the target aspect or directly in the pre-notification.

[0150] If the present application detects that the lock acquisition result is a failure to acquire the lock, an error response message corresponding to the lock acquisition result is generated; then the preset second auxiliary processing information is obtained; and the error response message and the second auxiliary processing information are subsequently returned to the client. When receiving the lock acquisition result returned by the distributed lock service, if the present application detects that the lock acquisition result is a failure to acquire the lock, an error response message corresponding to the lock acquisition result is intelligently generated, and the preset second auxiliary processing information is obtained, and then the error response message and the second auxiliary processing information are returned to the client, so that the relevant user can promptly understand the cause of the abnormal service request processing by consulting the error response information received in the client, and perform corresponding retry or debugging processing by consulting the second auxiliary processing information received in the client, thereby effectively improving the user experience.

[0151] In some optional implementations of this embodiment, after step S205, the electronic device may further perform the following steps:

[0152] Gets the preset delete lock key command.

[0153] In this embodiment, after the business logic processing corresponding to the service request is executed based on the target interface and the business logic is executed, the distributed lock can be further released regardless of whether the business logic is executed successfully or failed. Specifically, by using the previously stored lock information (such as the lock key) to release the lock, a delete lock key command, such as DEL, can be constructed to be sent to the distributed lock service.

[0154] The delete lock key command is sent to the distributed lock service.

[0155] In this embodiment, the delete lock key command may be sent to the distributed lock service by using after advice or around advice of the target aspect.

[0156] In addition, if any exception occurs during the process of releasing the lock (such as failure to connect to the distributed lock service), appropriate error handling is required. However, since the purpose of the lock is to prevent concurrency problems, even if the lock release fails, it usually does not have much impact on the business logic (unless the lock is held permanently, which is usually caused by serious problems such as distributed lock service failure).

[0157] The present application obtains a preset delete lock key command; and then sends the delete lock key command to the distributed lock service. After executing the business logic processing corresponding to the service request based on the target interface and obtaining the corresponding processing result, the present application will also intelligently obtain the preset delete lock key command, and send the delete lock key command to the distributed lock service to complete the process of releasing the distributed lock, thereby improving the intelligence of the release process of the distributed lock and ensuring the standardization of the use of the distributed lock.

[0158] In some optional implementations of this embodiment, during the processing of the service request, if any exception occurs (such as token verification failure, distributed lock acquisition failure, business logic execution error, etc.), corresponding exception handling logic is set to ensure system stability and user experience. Specifically, the specific implementation process of exception handling includes the following:

[0159] 1. Custom exceptions: To more clearly represent and handle different types of errors, you can define custom exception classes. For example, you can define exception classes such as TokenValidationException, DistributedLockFailureException, and BusinessLogicException to represent token validation failure, distributed lock acquisition failure, and business logic execution error, respectively.

[0160] 2. Capture exceptions. Capture in business logic: During the execution of business logic, you can use try-catch blocks to capture and handle possible exceptions. However, this approach is usually only applicable to exceptions that you expect to handle at the business logic level.

[0161] Capture in AOP aspects: For exception handling that needs to span multiple services or layers (such as token verification failure, distributed lock acquisition failure), these exceptions can be captured and handled in AOP aspects. For example, in the around advice of the AOP aspect, try-catch blocks can be added before and after calling the target method to capture and handle exceptions.

[0162] 3. Handle exceptions. Record logs: Whether the exception is captured in the business logic or in the AOP aspect, detailed log information should be recorded, including the exception type, exception message, stack trace, etc., to facilitate subsequent problem tracking and troubleshooting.

[0163] Build an error response: Based on the type of exception caught, build the corresponding error response object. This usually includes a clear error code, an easy-to-understand error message, and possible error details (such as which parameter caused the problem).

[0164] Send error response: Send the constructed error response object to the client via HTTP response. Make sure to use appropriate HTTP status codes to represent different types of errors (such as 401Unauthorized for token verification failure, 500Internal Server Error for internal server error, etc.).

[0165] 4. Global exception handling. In Spring MVC, you can create a global exception handling class by using the @ControllerAdvice or @RestControllerAdvice annotation. This class can contain multiple methods to handle different types of exceptions, and these methods are automatically called by Spring MVC to handle exceptions thrown in the Controller. In addition, in the global exception handling class, use the @ExceptionHandler annotation to mark methods that handle specific types of exceptions. When an exception is thrown in the Controller, Spring MVC will look for an @ExceptionHandler method that matches the exception type and call that method to handle the exception.

[0166] By defining custom exception classes, capturing exceptions in business logic and AOP aspects, building error responses, and using global exception handling mechanisms, you can ensure that your microservices can gracefully handle various exceptions throughout the entire processing process, thereby improving system stability and user experience.

[0167] It should be understood that the order of execution of the steps in the above embodiment does not necessarily mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present invention.

[0168] It should be emphasized that in order to further ensure the privacy and security of the above-mentioned response object, the above-mentioned response object can also be stored in a node of a blockchain.

[0169] The blockchain referred to in this application is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, platform product service layer, and application service layer.

[0170] The embodiments of the present application can acquire and process relevant data based on artificial intelligence technology. Among them, artificial intelligence (AI) is the theory, method, technology and application system that uses digital computers or machines controlled by digital computers to simulate, extend and expand human intelligence, perceive the environment, acquire knowledge and use knowledge to obtain the best results.

[0171] AI basic technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing technology, operation / interaction systems, mechatronics, etc. AI software technologies mainly include computer vision technology, robotics technology, biometrics technology, speech processing technology, natural language processing technology, and machine learning / deep learning.

[0172] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through computer-readable instructions, and the computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, the aforementioned storage medium can be a non-volatile storage medium such as a disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0173] It should be understood that, although the steps in the flowchart of the accompanying drawings are displayed in sequence as indicated by the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least a part of the steps in the flowchart of the accompanying drawings may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a part of the sub-steps or stages of other steps.

[0174] Further references Figure 3 , as a response to the above Figure 2 The present application provides an embodiment of a device for processing a service request, and the device embodiment is similar to Figure 2 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0175] like Figure 3As shown, the service request processing device 300 described in this embodiment includes: a first judgment module 301, an interception module 302, a verification module 303, a receiving module 304, an execution module 305, a construction module 306 and a first return module 307. Among them:

[0176] The first judgment module 301 is used to judge whether a service request issued by a client is received in a target interface; wherein the target interface is an interface with a preset idempotent annotation added, and the service request carries a token;

[0177] An interception module 302 is used to intercept the service request based on a preset target aspect and extract the token from the service request;

[0178] Verification module 303, used for verifying the legitimacy of the token based on a preset authentication center;

[0179] The receiving module 304 is used to obtain a lock from a preset distributed lock service if the token passes the legal verification, and receive a lock acquisition result returned by the distributed lock service;

[0180] An execution module 305 is configured to execute a business logic process corresponding to the service request based on the target interface to obtain a corresponding processing result if the lock acquisition result is that the lock is successfully acquired;

[0181] A construction module 306 is used to construct a corresponding response object based on the processing result;

[0182] The first returning module 307 is used to return the response object to the client.

[0183] In this embodiment, the operations performed by the above modules or units correspond one-to-one to the steps of the method for processing service requests in the aforementioned implementation mode, and are not described in detail here.

[0184] In some optional implementations of this embodiment, the verification module 303 includes:

[0185] Call submodule, used to call the preset HTTP client;

[0186] A first generating submodule, used to generate a verification request corresponding to the token;

[0187] A sending submodule, used for sending the verification request to the authentication center based on the HTTP client;

[0188] A receiving submodule, used to receive a response result corresponding to the verification request returned by the authentication center;

[0189] The parsing submodule is used to parse the response result to obtain a corresponding parsing result;

[0190] The verification submodule is used to perform a legal verification on the token using the parsing result based on a preset verification rule to obtain a legal verification result corresponding to the token.

[0191] In this embodiment, the operations performed by the above modules or units correspond one-to-one to the steps of the method for processing service requests in the aforementioned implementation mode, and are not described in detail here.

[0192] In some optional implementations of this embodiment, the construction module 306 includes:

[0193] A second generating submodule, used to generate a corresponding status code, a response message and a response body based on the processing result;

[0194] An integration submodule, used for integrating the status code, the response message and the response body to obtain corresponding integration information;

[0195] A determination submodule is used to use the integration information as the response object.

[0196] In this embodiment, the operations performed by the above modules or units correspond one-to-one to the steps of the method for processing service requests in the aforementioned implementation mode, and are not described in detail here.

[0197] In some optional implementations of this embodiment, the service request processing device further includes:

[0198] A second determination module is used to determine whether a token acquisition request sent by the client is received;

[0199] A calling module, used for calling the authentication center if yes;

[0200] A first generating module, used to generate a token corresponding to the client based on the authentication center;

[0201] The first sending module is used to send the token to the client.

[0202] In this embodiment, the operations performed by the above modules or units correspond one-to-one to the steps of the method for processing service requests in the aforementioned implementation mode, and are not described in detail here.

[0203] In some optional implementations of this embodiment, the service request processing device further includes:

[0204] A second generating module, for generating corresponding token authentication failure information if the token fails to pass the legal verification;

[0205] A first acquisition module, used to acquire preset first auxiliary processing information;

[0206] The second returning module is used to return the token authentication failure information and the first auxiliary processing information to the client.

[0207] In this embodiment, the operations performed by the above modules or units correspond one-to-one to the steps of the method for processing service requests in the aforementioned implementation mode, and are not described in detail here.

[0208] In some optional implementations of this embodiment, the service request processing device further includes:

[0209] A third generating module is used to generate error response information corresponding to the lock acquisition result if the lock acquisition result is a failure to acquire the lock;

[0210] A second acquisition module, used to acquire preset second auxiliary processing information;

[0211] A third returning module is used to return the error response information and the second auxiliary processing information to the client.

[0212] In this embodiment, the operations performed by the above modules or units correspond one-to-one to the steps of the method for processing service requests in the aforementioned implementation mode, and are not described in detail here.

[0213] In some optional implementations of this embodiment, the service request processing device further includes:

[0214] A third acquisition module is used to acquire a preset delete lock key command;

[0215] The second sending module is used to send the lock key deletion command to the distributed lock service.

[0216] In this embodiment, the operations performed by the above modules or units correspond one-to-one to the steps of the method for processing service requests in the aforementioned implementation mode, and are not described in detail here.

[0217] To solve the above technical problems, the present application also provides a computer device. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0218] The computer device 4 includes a memory 41, a processor 42, and a network interface 43 that are interconnected through a system bus. It should be noted that the figure only shows a computer device 4 with components 41-43, but it should be understood that it is not required to implement all the components shown, and more or fewer components can be implemented instead. Among them, those skilled in the art can understand that the computer device here is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes but is not limited to microprocessors, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable gate arrays (Field-Programmable Gate Array, FPGA), digital processors (Digital Signal Processor, DSP), embedded devices, etc.

[0219] The computer device may be a computing device such as a desktop computer, a notebook, a PDA, a cloud server, etc. The computer device may interact with a user through a keyboard, a mouse, a remote controller, a touch pad, or a voice control device.

[0220] The memory 41 includes at least one type of readable storage medium, and the readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (for example, SD or DX memory, etc.), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, etc. In some embodiments, the memory 41 can be an internal storage unit of the computer device 4, such as a hard disk or memory of the computer device 4. In other embodiments, the memory 41 can also be an external storage device of the computer device 4, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (FlashCard), etc. equipped on the computer device 4. Of course, the memory 41 can also include both the internal storage unit of the computer device 4 and its external storage device. In this embodiment, the memory 41 is generally used to store the operating system and various application software installed on the computer device 4, such as computer-readable instructions of a method for processing a service request, etc. In addition, the memory 41 can also be used to temporarily store various types of data that have been output or are to be output.

[0221] The processor 42 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chips in some embodiments. The processor 42 is generally used to control the overall operation of the computer device 4. In this embodiment, the processor 42 is used to run computer-readable instructions or process data stored in the memory 41, such as computer-readable instructions for running the method for processing the service request.

[0222] The network interface 43 may include a wireless network interface or a wired network interface. The network interface 43 is generally used to establish a communication connection between the computer device 4 and other electronic devices.

[0223] Compared with the prior art, the embodiments of the present application have the following beneficial effects:

[0224] In an embodiment of the present application, first determine whether a service request issued by a client is received in the target interface; wherein the target interface is an interface with a preset idempotent annotation added, and the service request carries a token; if so, intercept the service request based on the preset target aspect, and extract the token from the service request; then perform a legal check on the token based on the preset authentication center; if the token passes the legal check, obtain the lock from the preset distributed lock service, and receive the lock acquisition result returned by the distributed lock service; if the lock acquisition result is a successful lock acquisition, then execute the business logic processing corresponding to the service request based on the target interface to obtain the corresponding processing result; subsequently construct a corresponding response object based on the processing result; and finally return the response object to the client. When receiving a service request issued by a client, the present application implements a pluggable idempotent operation of the target interface by combining the target aspect, the authentication center, and the distributed lock service, thereby ensuring that requests are repeatedly executed during the service call process of the microservice, effectively ensuring the correctness and consistency of the service request processing, and ensuring the stability and reliability of the microservice.

[0225] The present application also provides another implementation, namely, providing a computer-readable storage medium, wherein the computer-readable storage medium stores computer-readable instructions, and the computer-readable instructions can be executed by at least one processor to enable the at least one processor to perform the steps of the service request processing method as described above.

[0226] Compared with the prior art, the embodiments of the present application have the following beneficial effects:

[0227] In an embodiment of the present application, first determine whether a service request issued by a client is received in the target interface; wherein the target interface is an interface with a preset idempotent annotation added, and the service request carries a token; if so, intercept the service request based on the preset target aspect, and extract the token from the service request; then perform a legal check on the token based on the preset authentication center; if the token passes the legal check, obtain the lock from the preset distributed lock service, and receive the lock acquisition result returned by the distributed lock service; if the lock acquisition result is a successful lock acquisition, then execute the business logic processing corresponding to the service request based on the target interface to obtain the corresponding processing result; subsequently construct a corresponding response object based on the processing result; and finally return the response object to the client. When receiving a service request issued by a client, the present application implements a pluggable idempotent operation of the target interface by combining the target aspect, the authentication center, and the distributed lock service, thereby ensuring that requests are repeatedly executed during the service call process of the microservice, effectively ensuring the correctness and consistency of the service request processing, and ensuring the stability and reliability of the microservice.

[0228] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0229] Obviously, the embodiments described above are only some embodiments of the present application, rather than all embodiments. The preferred embodiments of the present application are given in the accompanying drawings, but they do not limit the patent scope of the present application. The present application can be implemented in many different forms. On the contrary, the purpose of providing these embodiments is to make the understanding of the disclosure of the present application more thorough and comprehensive. Although the present application is described in detail with reference to the aforementioned embodiments, for those skilled in the art, it is still possible to modify the technical solutions recorded in the aforementioned specific implementation methods, or to perform equivalent replacement of some of the technical features therein. Any equivalent structure made using the contents of the specification and drawings of this application, directly or indirectly used in other related technical fields, is similarly within the scope of patent protection of this application.

Claims

1. A method for processing a service request, characterized in that: The steps include: Determine whether a service request issued by a client is received in a target interface; wherein the target interface is an interface with a preset idempotent annotation added, and the service request carries a token; If so, intercept the service request based on a preset target aspect, and extract the token from the service request; Performing a legal verification on the token based on a preset authentication center; If the token passes the legal verification, the lock is acquired from the preset distributed lock service, and the lock acquisition result returned by the distributed lock service is received; If the lock acquisition result is that the lock is acquired successfully, then executing the business logic processing corresponding to the service request based on the target interface to obtain the corresponding processing result; Constructing a corresponding response object based on the processing result; Return the response object to the client.

2. The method for processing a service request according to claim 1, characterized in that: The step of performing legal verification on the token based on a preset authentication center specifically includes: Call the preset HTTP client; generating a verification request corresponding to the token; Based on the HTTP client, sending the verification request to the authentication center; Receiving a response result corresponding to the verification request returned by the authentication center; Parsing the response result to obtain a corresponding parsing result; Based on preset verification rules, the token is verified to be legal using the parsing result to obtain a legal verification result corresponding to the token.

3. The method for processing a service request according to claim 1, characterized in that: The step of constructing a corresponding response object based on the processing result specifically includes: Generate a corresponding status code, response message and response body based on the processing result; Integrate the status code, the response message and the response body to obtain corresponding integrated information; The integrated information is used as the response object.

4. The method for processing a service request according to claim 1, characterized in that: Before the step of determining whether the service request sent by the client is received in the target interface, the method further includes: Determine whether a token acquisition request sent by the client is received; If so, calling the authentication center; Generate a token corresponding to the client based on the authentication center; The token is sent to the client.

5. The method for processing a service request according to claim 1, characterized in that: After the step of verifying the legitimacy of the token based on the preset authentication center, the method further includes: If the token fails the legal verification, a corresponding token authentication failure message is generated; Obtaining preset first auxiliary processing information; The token authentication failure information and the first auxiliary processing information are returned to the client.

6. The method for processing a service request according to claim 1, characterized in that: After the step of acquiring a lock from a preset distributed lock service and receiving a lock acquisition result returned by the distributed lock service, the method further includes: If the lock acquisition result is a failure to acquire the lock, generating an error response message corresponding to the lock acquisition result; Obtaining preset second auxiliary processing information; The error response information and the second auxiliary processing information are returned to the client.

7. The method for processing a service request according to claim 1, characterized in that: After the step of executing the business logic processing corresponding to the service request based on the target interface to obtain the corresponding processing result, the method further includes: Get the preset delete lock key command; The delete lock key command is sent to the distributed lock service.

8. A service request processing device, characterized in that: include: A first judgment module is used to judge whether a service request issued by a client is received in a target interface; wherein the target interface is an interface with a preset idempotent annotation added, and the service request carries a token; An interception module, configured to intercept the service request based on a preset target aspect and extract the token from the service request; A verification module, used to verify the legitimacy of the token based on a preset authentication center; A receiving module, configured to obtain a lock from a preset distributed lock service if the token passes legal verification, and receive a lock acquisition result returned by the distributed lock service; An execution module, configured to execute a business logic process corresponding to the service request based on the target interface to obtain a corresponding processing result if the lock acquisition result is that the lock is successfully acquired; A construction module, used to construct a corresponding response object based on the processing result; The first returning module is used to return the response object to the client.

9. A computer device, characterized in that: The method comprises a memory and a processor, wherein the memory stores computer-readable instructions, and the processor implements the steps of the method for processing a service request as claimed in any one of claims 1 to 7 when executing the computer-readable instructions.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-readable instructions, and when the computer-readable instructions are executed by a processor, the steps of the method for processing a service request according to any one of claims 1 to 7 are implemented.

Images