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

Abstract

The application belongs to the field of data processing and the field of financial technology, and relates to a service request processing method and device, computer equipment and a storage medium, comprising: judging whether a service request sent by a client is received in a target interface; if yes, intercepting the service request based on a target aspect, and extracting a token from the service request; performing legal verification on the token based on an authentication center; if the token passes the legal verification, acquiring a lock from a 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 acquired successfully, 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 can be stored in a block chain. Through the application, the request repeated execution in the service calling process of micro services can be effectively guaranteed, and the 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, particularly the widespread adoption of cloud computing, big data, and the Internet of Things (IoT), software system architecture is undergoing a profound transformation from monolithic architectures to distributed architectures and even microservices. Microservices, with its high modularity, scalability, and flexibility, has become the preferred approach for building complex, large-scale application systems. In a microservices architecture, a system is broken down into a series of independently deployed, independently scalable, and business-focused small services. These services collaborate through lightweight communication mechanisms (such as RESTful APIs and gRPC) to support the functionality of the entire system.

[0003] However, while microservices architecture offers numerous advantages, it also introduces new challenges, particularly in inter-service communication and invocation. Because services are distributed across different physical or logical nodes and interact over the network, they are inevitably subject to issues such as network latency, service unavailability, and message loss or duplication. These issues can be particularly pronounced in high-concurrency, high-load scenarios, leading to uncertainty in service invocations and, in turn, triggering a series of chain reactions, such as request retries and duplicate message consumption.

[0004] In critical business scenarios such as financial transactions, order processing, and inventory management, duplicate requests are particularly critical. For example, if payment requests are sent multiple times to the payment system due to network jitter or temporary service unavailability, and the payment system fails to effectively identify and process these duplicate requests, it can lead to duplicate deductions or overpayments of user funds, severely damaging user interests and the company's reputation. Furthermore, duplicate operations can lead to data inconsistencies and confusing business logic, posing a serious threat to system stability and reliability.

[0005] Therefore, how to effectively prevent repeated execution of requests during service calls under the 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 equipment 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, the business logic processing corresponding to the service request is executed based on the target interface to obtain a 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 the 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 to pass 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 lock acquisition failure, generating error response information 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] Furthermore, 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:

[0040] Get the preset delete lock key command;

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

[0042] To solve the above technical problems, the embodiment of the application further provides a service request processing device, which adopts the technical scheme as follows:

[0043] The first judging module is configured to judge whether a service request sent by a client is received in a target interface; wherein the target interface is an interface to which a preset idempotent annotation is added, and the service request carries a token;

[0044] The intercepting module is configured to, if yes, intercept the service request based on a preset target aspect, and extract the token from the service request;

[0045] The verifying module is configured to perform legal verification on the token based on a preset authentication center;

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

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

[0048] The constructing module is configured to construct a corresponding response object based on the processing result;

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

[0050] To solve the above technical problems, the embodiment of the application further provides a computer device, which adopts the technical scheme as follows:

[0051] If yes, judge whether a service request sent by a client is received in a target interface; wherein the target interface is an interface to which a preset idempotent annotation is added, and the service request carries a token;

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

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

[0054] If the token passes the legal verification, acquire a lock from a preset distributed lock service, and receive a lock acquisition result returned by the distributed lock service;

[0055] If the lock acquisition result is that the lock is acquired successfully, execute business logic processing corresponding to the service request based on the target interface, and obtain a 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, the business logic processing corresponding to the service request is executed based on the target interface to obtain a 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] This 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, a corresponding response object is constructed based on the processing result; finally, the response object is returned to the client. When receiving a service request issued by a client, this application implements pluggable idempotent operations 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] In order to more clearly illustrate the solutions in this application, a brief introduction will be given below to the drawings required for use in the description of the embodiments of this application. Obviously, the drawings described below are some embodiments of this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without 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 service requests 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 commonly understood by one of ordinary skill in the art to which this application belongs; the terms used in the specification are intended to describe the particular embodiments and are not intended to limit the application; the terms "include" and "have" and their any variations used in the specification and the claims and the above description of drawings are intended to cover the non-exclusive inclusion; the terms "first", "second" and the like used in the specification and the claims and the above description of drawings are intended to distinguish different objects, not to describe a particular order.

[0074] Reference herein to "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment can be included in at least one embodiment of the application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are they necessarily mutually exclusive or alternative embodiments. It is expressly understood that the embodiments described herein are combinable with each other.

[0075] In order to make the person skilled in the art better understand the scheme of the present application, the technical solutions in the embodiments of the present application will be described clearly and completely in conjunction with the drawings below.

[0076] As shown in Figure 1 The system architecture 100 can include a terminal device 101, a network 102 and a server 103, and the terminal device 101 can be a notebook computer 1011, a tablet computer 1012 or a mobile phone 1013. The network 102 is a medium for providing a communication link between the terminal device 101 and the server 103. The network 102 can 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 various electronic devices with a display screen and supporting web browsing, in addition to the notebook computer 1011, the tablet computer 1012 or the mobile phone 1013, the terminal device 101 can also be an electronic book reader, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 player (Moving Picture Experts Group Audio Layer IV), a laptop computer and a desktop computer, etc.

[0079] The server 103 can be a server providing various services, for example, a background server providing support for a page displayed on the terminal device 101.

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

[0081] It should be understood that Figure 1 The number of terminal devices, networks and servers in

[0082] With reference to Figure 2 , a flow chart of one embodiment of the service request processing method according to the present application is shown. The order of the steps in the flow chart can be changed according to different needs, and some steps can be omitted. The service request processing method provided by the embodiments of the present application can be applied to any scenario requiring service request processing, and then the service request processing method can be applied to products in these scenarios, for example, service request processing in the field of finance and insurance. The service request processing method comprises the following steps:

[0083] In step S201, it is determined whether a service request issued by a client is received in a target interface; wherein the target interface is an interface to which a preset idempotent annotation is added, and the service request carries a token.

[0084] In the present embodiment, the electronic device (for example 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 method may include but is 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 execution subject of this 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 implement 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 and insurance data query, the service request may be a request to call a microservice to query financial data. The financial data may include transaction data, payment data, business data, etc. Tokens can 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 uses AOP (Aspect-Oriented Programming). In a microservice, an aspect is defined using AOP (such as Spring AOP) that 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 be a 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 on here.

[0094] Step S204: If the token passes the legality 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 for 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 command with Lua script or use the distributed lock implementation provided by Redis's Redisson, Jedis and other client libraries) 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 acquired successfully, the business logic processing corresponding to the service request is executed based on the target interface to obtain a corresponding processing result.

[0097] In this embodiment, if the lock acquisition result indicates a successful lock acquisition, the service request is allowed to continue executing the business logic portion of the target interface. Specifically, since the distributed lock has been successfully acquired, the business logic of the target interface can be safely executed. Based on the specific requirements of the service request, the target interface is controlled to execute the corresponding business logic, such as database operations, calculations, and calls to other services, 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 this application and will not be elaborated on here.

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

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

[0102] This 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, a corresponding response object is constructed based on the processing result; finally, the response object is returned to the client. When receiving a service request issued by a client, this application implements pluggable idempotent operations 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.

[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.

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

[0107] In this embodiment, the verification request is a request that includes the token. The verification request can typically 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, request header, or 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 indicates 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 the 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 this embodiment, the above-mentioned 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 the signature, issuer, audience and expiration time of the token can be detected to see if they 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, or 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] The application generates a verification request corresponding to the token, sends the verification request to the authentication center based on the HTTP client, receives a response result corresponding to the verification request returned by the authentication center, subsequently analyzes the response result to obtain a corresponding analysis result, and finally performs legal verification on the token based on a preset verification rule using the analysis result to obtain a legal verification result corresponding to the token. The application generates a verification request of a token, sends the verification request to an authentication center using an HTTP client, receives a response result corresponding to the verification request returned by the authentication center, analyzes the response result to obtain an analysis result, and then performs legal verification on the token based on a verification rule using the analysis result, thereby quickly and accurately obtaining a legal verification result corresponding to the token, improving the processing efficiency and processing accuracy of legal verification of the token, and improving the accuracy of the generated legal verification result.

[0117] In some optional implementations of the 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 the embodiment, the status code can include HTTP 200 OK, 400 Bad Request, etc., and the response body contains the result of business logic processing.

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

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

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

[0123] In the embodiment, the constructed response object is sent to the client through an HTTP response. Specifically, a @ResponseBody annotation can be added in a Controller method or a @RestController annotation can be added on a Controller class to achieve this. 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 application generates corresponding status codes, response messages and response bodies based on the processing result, then integrates the status codes, the response messages and the response bodies to obtain corresponding integrated information, and subsequently takes the integrated information as the response object. The application generates corresponding status codes, response messages and response bodies based on the processing result, and then integrates the status codes, the response messages and the response bodies, so that a response object corresponding to the processing result is quickly and intelligently constructed, the construction efficiency of the response object is improved, and the accuracy of the obtained response object is ensured.

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

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

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

[0128] If yes, the authentication center is called.

[0129] In this embodiment, the authentication center can specifically be 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: a JWT authentication center generates a new JWT Token by calling a service of the JWT authentication center, using 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). The Token contains some claims, such as user ID, expiration time, issuer, etc., and a signature. Then set the Token expiration time: when generating the Token, the JWT authentication center sets an expiration time, which can be fixed or based on certain business logic (such as dynamically setting according to user permissions or request types).

[0132] The token is sent to the client.

[0133] In this embodiment, the generated Token (i.e., the 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 the 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 issued by the client can be identified later, 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 to pass the legal verification, a corresponding token authentication failure message is generated.

[0137] In this embodiment, if the token fails the legal verification (e.g., the signature in the token does not match, it has expired, the issuer does not match, etc.), the exception information corresponding to the token, such as the signature does not match, it has expired, the issuer does not match, etc., is obtained, and the exception information is filled into the preset token authentication failure information template to generate the corresponding token authentication failure information. 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, during the process of sending the token authentication failure information, some additional information, such as the retry time interval or the request ID, may also be sent 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 token is detected as not passing the legal verification, the token authentication failure information is generated; then the first preset auxiliary processing information is acquired; and the token authentication failure information and the first auxiliary processing information are returned to the client. When the token is subjected to legal verification based on the preset authentication center, if the token is detected as not passing the legal verification, the corresponding token authentication failure information is intelligently generated, the first preset auxiliary processing information is acquired, and the token authentication failure information and the first auxiliary processing information are returned to the client, so that a user can learn the reason for the abnormal service request processing in time by checking the token authentication failure information received by the client, and can perform corresponding retry or debugging processing by checking the first auxiliary processing information received by the client, thereby effectively improving user experience.

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

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

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

[0146] The second preset auxiliary processing information is acquired.

[0147] In the embodiment, in the process of sending the error response information, some additional information, such as a retry time interval or a request ID, can be sent at the same time and used as the second auxiliary processing information to help the client to perform retry or debugging.

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

[0149] In the embodiment, the error response information and the second auxiliary processing information can be returned to the client by using exception notification of a target aspect or directly in a 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 the present application receives the lock acquisition result returned by the distributed lock service, if it is detected 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 executing the business logic processing corresponding to the service request based on the target interface and completing the business logic execution, regardless of whether the business logic execution succeeds or fails, the distributed lock can be further released. Specifically, by using previously stored lock information (such as the lock key) to release the lock, a delete lock key command, such as DEL, can be first constructed and 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 lock release process (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 issues, 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] This 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, this application also intelligently obtains the preset delete lock key command and sends the delete lock key command to the distributed lock service to complete the release of 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, if any exception occurs during the service request processing (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 errors, 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 generally only suitable for exceptions that you expect to handle at the business logic level.

[0161] Capture in AOP aspects: For exceptions that need to be handled across multiple services or layers (such as token verification failure and 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 the exception.

[0162] 3. Handle exceptions. Record logs: Regardless of whether the exception is caught 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] Construct an error response: Based on the type of exception caught, construct an appropriate error response object. This typically 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 built error response object to the client through an HTTP response. Make sure to use appropriate HTTP status codes to represent different types of errors (e.g., 401 Unauthorized for token validation failure, 500 Internal Server Error for server internal 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 will be automatically called by Spring MVC to handle exceptions thrown in Controllers. Additionally, 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 a Controller, Spring MVC will find the @ExceptionHandler method that matches the exception type and call that method to handle the exception.

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

[0167] It should be understood that the size of the serial number of each step in the above embodiment does not mean the order of execution, and 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 embodiments of the present application.

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

[0169] The blockchain referred to in the present application is a new application mode of distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm and other computer technologies. Blockchain, in essence, is a decentralized database, which is a series of data blocks associated using cryptographic methods, each containing a batch of network transaction information for verifying the validity (anti-fake) of the information and generating the next block. Blockchain can include blockchain underlying platform, platform product service layer, and application service layer, etc.

[0170] The embodiments of the present application can acquire and process relevant data based on artificial intelligence technology. 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 achieve optimal results.

[0171] Fundamental AI technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interaction systems, and mechatronics. AI software technologies primarily encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0172] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing related hardware via computer-readable instructions. The computer-readable instructions can be stored in a computer-readable storage medium, and when the program is executed, it can include the processes in the above-described method embodiments. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic 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 flowcharts of the accompanying drawings are shown in sequence as indicated by the arrows, these steps are not necessarily executed 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 some of the steps in the flowcharts 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 portion 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. 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 apparatus 300 described in this embodiment comprises a first judging module 301, an intercepting module 302, a verifying module 303, a receiving module 304, an executing module 305, a constructing module 306, and a first returning module 307. Among them:

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

[0177] The intercepting module 302 is configured to, if yes, intercept the service request based on a preset target aspect, and extract the token from the service request;

[0178] The verifying module 303 is configured to perform legal verification on the token based on a preset authentication center;

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

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

[0181] The constructing module 306 is configured to construct a corresponding response object based on the processing result;

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

[0183] In this embodiment, the above-mentioned modules or units are respectively used for operations corresponding to the steps of the service request processing method of the foregoing embodiments, which will not be repeated here.

[0184] In some optional implementations of this embodiment, the verifying module 303 comprises:

[0185] A calling sub-module is configured to call a preset HTTP client;

[0186] A first generating sub-module is configured to generate a verification request corresponding to the token;

[0187] A sending sub-module is configured to send the verification request to the authentication center based on the HTTP client;

[0188] A receiving sub-module is configured to receive a response result corresponding to the verification request returned by the authentication center;

[0189] The parsing submodule is configured to parse the response result to obtain a corresponding parsed result.

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

[0191] In the embodiment, the modules or units are respectively configured to perform operations corresponding to the steps of the service request processing method of the foregoing embodiments, and thus no further description is provided herein.

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

[0193] The second generation submodule is configured to generate a corresponding status code, response message, and response body based on the processing result.

[0194] The integration submodule is configured to perform integration processing on the status code, the response message, and the response body to obtain corresponding integration information.

[0195] The determination submodule is configured to determine the integration information as the response object.

[0196] In the embodiment, the modules or units are respectively configured to perform operations corresponding to the steps of the service request processing method of the foregoing embodiments, and thus no further description is provided herein.

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

[0198] The second judgment module is configured to determine whether a token acquisition request sent by the client is received.

[0199] The calling module is configured to call the authentication center if the determination is yes.

[0200] The first generation module is configured to generate a token corresponding to the client based on the authentication center.

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

[0202] In the embodiment, the modules or units are respectively configured to perform operations corresponding to the steps of the service request processing method of the foregoing embodiments, and thus no further description is provided herein.

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

[0204] The second generation module is configured to generate token authentication failure information if the token fails to pass the legal verification.

[0205] The first obtaining module is configured to obtain preset first auxiliary processing information.

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

[0207] In the embodiment, the above modules or units are respectively used for performing operations corresponding to steps of the service request processing method of the foregoing embodiments, and thus will not be described here.

[0208] In some optional implementation forms of the embodiment, the service request processing apparatus further includes:

[0209] The third generating module is configured to generate error response information corresponding to the lock acquisition result if the lock acquisition result is an acquisition failure.

[0210] The second obtaining module is configured to obtain preset second auxiliary processing information.

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

[0212] In the embodiment, the above modules or units are respectively used for performing operations corresponding to steps of the service request processing method of the foregoing embodiments, and thus will not be described here.

[0213] In some optional implementation forms of the embodiment, the service request processing apparatus further includes:

[0214] The third obtaining module is configured to obtain a preset delete lock key command.

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

[0216] In the embodiment, the above modules or units are respectively used for performing operations corresponding to steps of the service request processing method of the foregoing embodiments, and thus will not be described here.

[0217] To solve the above technical problems, the embodiment of the application further provides a computer device. For details, please refer to Figure 4 , Figure 4 The basic structure block diagram of the computer device of the embodiment is shown in FIG. 1.

[0218] The computer device 4 includes a memory 41, a processor 42, and a network interface 43, which are communicatively connected to each other through a system bus. It should be noted that only the computer device 4 with components 41-43 is shown in the figure, but it should be understood that all the shown components are not required to be implemented, and more or fewer components can be alternatively implemented. Among them, those skilled in the art can understand that the computer device herein is a device capable of automatically performing numerical calculation 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 (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0219] The computer device can be a desktop computer, a notebook computer, a palm computer, a cloud server, and the like. The computer device can interact with the user through a keyboard, a mouse, a remote controller, a touchpad, a voice control device, and the like.

[0220] The memory 41 includes at least one type of readable storage medium, which includes a flash memory, a hard disk, a multimedia card, a card-type memory (e.g., an SD or DX memory, etc.), a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, and the like. In some embodiments, the memory 41 can be an internal storage unit of the computer device 4, such as a hard disk or a 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 media card (SMC), a secure digital (SD) card, a flash card, and the like. Of course, the memory 41 can also include both the internal storage unit and the external storage device of the computer device 4. In the present embodiment, the memory 41 is generally used to store an operating system and various application software installed in the computer device 4, such as computer readable instructions of the processing method of the service request, and the like. In addition, the memory 41 can also be used to temporarily store various data that have been output or will be output.

[0221] The processor 42 may be a Central Processing Unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip in some embodiments. The processor 42 is generally used to control the overall operation of the computer device 4. In the present embodiment, the processor 42 is configured to execute computer readable instructions stored in the memory 41 or process data, such as computer readable instructions of the processing method of the service request.

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

[0223] Compared with the prior art, the present embodiment has the following beneficial effects:

[0224] In the present embodiment, it is first determined whether a service request issued by a client is received in a target interface; wherein the target interface is an interface to which a preset idempotent annotation is added, and the service request carries a token; if so, the service request is intercepted based on a preset target aspect, and the token is extracted from the service request; then the token is verified for legality based on a preset authentication center; if the token passes the legality verification, a lock is acquired from a preset distributed lock service, and a lock acquisition result returned by the distributed lock service is received; if the lock acquisition result is that the lock is acquired successfully, a business logic processing corresponding to the service request is performed based on the target interface, and a corresponding processing result is obtained; a corresponding response object is constructed based on the processing result subsequently; and finally, the response object is returned to the client. When the service request issued by the client is received, the present application realizes the pluggable idempotent operation of the target interface by using the combination of the target aspect, the authentication center, and the distributed lock service, so that the request repeated execution in the service calling process of the microservice can be ensured, the correctness and consistency of the service request processing are effectively ensured, and the stability and reliability of the microservice are ensured.

[0225] The present application also provides another embodiment, i.e., a computer readable storage medium storing computer readable instructions, which can be executed by at least one processor to enable the at least one processor to perform the steps of the processing method of the service request as described above.

[0226] Compared with the prior art, the present embodiment has the following beneficial effects:

[0227] In the embodiments of the present application, firstly, it is judged whether a service request issued by a client is received in a target interface; wherein the target interface is an interface to which a preset idempotent annotation is added, and the service request carries a token; if yes, the service request is intercepted based on a preset target aspect, and the token is extracted from the service request; then, the token is legally verified based on a preset authentication center; 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; if the lock acquisition result is that the lock is acquired successfully, a business logic processing corresponding to the service request is executed based on the target interface, and a corresponding processing result is obtained; subsequently, a corresponding response object is constructed based on the processing result; finally, the response object is returned to the client. When the service request issued by the client is received, the combination of the target aspect, the authentication center and the distributed lock service is used, the pluggable idempotent operation of the target interface is realized, the request repeated execution in the service calling process of the micro service is ensured, the correctness and consistency of the service request processing are effectively ensured, and the stability and reliability of the micro service are ensured.

[0228] From the above description of the embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment method can be realized by means of software and a necessary general hardware platform, of course, it can also be realized by hardware, but in many cases, the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as a ROM / RAM, a magnetic disk, an optical disk), and includes a plurality of instructions for making a terminal device (which can be a mobile phone, a computer, a server, an air conditioner, or a network device) execute the methods described in the various embodiments of the present application.

[0229] Obviously, the above-described embodiments are only some of the embodiments of the present application, not all the embodiments, and the preferred embodiments of the present application are given in the drawings, but do not limit the patent scope of the present application. The present application can be realized in many different forms, and conversely, the purpose of providing these embodiments is to make the disclosure of the present application more thorough and comprehensive. Although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions recorded in the foregoing specific embodiments, or make equivalent replacements to some technical features. Any equivalent structure made by using the contents of the specification and drawings, directly or indirectly applied to other related technical fields, is also within the scope of the patent protection of the present 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, the business logic processing corresponding to the service request is executed based on the target interface to obtain a 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, wherein: 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 the 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, wherein: 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, wherein: 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, wherein: After the step of performing legal verification on the token based on the preset authentication center, the method further includes: If the token fails to pass 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, wherein: After the steps 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 lock acquisition failure, generating error response information 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, wherein: 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, configured to construct a corresponding response object based on the processing result; The first returning module is configured 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 when the processor executes the computer-readable instructions, the steps of the method for processing a service request according to any one of claims 1 to 7 are implemented.

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

Images