Request processing method, electronic device, storage medium, and computer program product

Abstract

This application provides a request processing method, an electronic device, a storage medium, and a computer program product. The method includes: receiving a user request; in response to the user request, if a first verification item is detected, obtaining the verification result of the first verification item in the request context of the user request; if the verification result of the first verification item is a first result, then continuing to process the user request without performing the verification processing of the first verification item; wherein the first result indicates that the user request passes the verification of the first verification item. This application's solution enables the reuse of verification results, reducing the overhead of request processing.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a request processing method, electronic device, storage medium, and computer program product. Background Technology

[0002] With the rapid development of internet technology, distributed system architecture, and microservices, business scenarios are becoming increasingly diverse and complex. For example, in e-commerce platforms, an order request may involve the coordination of multiple service stages such as risk control, inventory verification, and payment confirmation; in financial platforms, the completion of a transaction request may require multiple steps such as format review, compliance screening, and accounting processing. To cope with this complexity, request processing flows are typically broken down into multiple processing stages to reduce the difficulty of request processing.

[0003] By decomposing the request processing flow into multiple processing stages, decoupling of the request processing flow and task splitting can be achieved. Different request processing stages correspond to different processing tasks, thereby greatly improving the flexibility and scalability of request processing. However, in different processing stages of the same business request, the same validation logic may be executed repeatedly, which will increase the performance overhead of request processing. Summary of the Invention

[0004] To address the related technical issues, embodiments of this application provide a request processing method, an electronic device, a storage medium, and a computer program product.

[0005] The technical solution of this application embodiment is implemented as follows: This application provides a request processing method, the method comprising: Receive user requests; In response to the user request, if the first verification item is detected, the verification result of the first verification item is obtained in the request context of the user request; If the verification result of the first verification item is the first result, then the user request will continue to be processed without performing the verification process of the first verification item; wherein, the first result indicates that the user request has passed the verification of the first verification item.

[0006] The method in the above scheme further includes: If the verification result of the first verification item does not exist in the request context, or if the verification result of the first verification item is the second result, then the verification processing of the first verification item is performed on the user request to obtain the verification result of the first verification item; wherein, the second result indicates that the user request has failed the verification of the first verification item. Write the verification result of the first verification item into the request context.

[0007] In the above scheme, writing the verification result of the first verification item into the request context includes: With the request context locked, the verification result of the first verification item is written into the request context.

[0008] In the above scheme, the step of performing the verification processing of the first verification item on the user request to obtain the verification result of the first verification item includes: The validator corresponding to the first verification item is invoked to perform verification processing on the user request, and the verification result of the first verification item is obtained.

[0009] In the above scheme, in response to the user request, the method further includes: The user request is parsed; If the user request carries the verification results of one or more verification items, the verification results of the one or more verification items are written into the request context created for the user request.

[0010] In the above scheme, the request context also includes the memory offset address of the business data; continuing to process the user request includes: Access the corresponding business data based on the memory offset address in the request context; The user request will continue to be processed based on the business data.

[0011] The method in the above scheme further includes: Send a user request, the user request carrying the verification results of one or more verification items in the request context.

[0012] This application also provides an electronic device, including: a processor and a memory for storing a computer program that can run on the processor; wherein, when the processor runs the computer program, it executes the method provided in this application.

[0013] This application also provides a storage medium storing a computer program thereon, which, when executed by a processor, implements the method provided in this application.

[0014] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the method provided in this application.

[0015] The request processing method, electronic device, storage medium, and computer program product provided in this application respond to a user request by writing the verification results of one or more verification items into the request context of the user request. During the processing of the user request, if a first verification item to be executed is detected, the verification result of the first verification item is obtained from the request context of the user request. If the verification result of the first verification item indicates that the user request passes the verification of the first verification item, the user request continues to be processed without executing the verification processing corresponding to the first verification item. By caching the verification results of one or more verification items in the request context, the verification results of the same verification items can be reused in subsequent processing, reducing the repeated execution of the same verification item's verification processing, lowering the performance overhead of request processing, and improving the efficiency of request processing. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a request processing method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a request context provided in an embodiment of this application; Figure 3 This is a flowchart illustrating an application example of a request processing method provided in this application embodiment; Figure 4 This is a schematic diagram of the structure of a request processing device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the application will now be described in further detail with reference to the accompanying drawings.

[0018] The processing flow of a request can be divided into multiple processing stages. Different processing stages can be executed by the same service process or by different service processes. The service processes for different processing stages can be deployed on the same electronic device or on different electronic devices. Therefore, the processing of a request may be completed across processes or across devices.

[0019] A request typically involves multiple validation processes during processing. For example, to ensure the security and compliance of request processing, authentication, permission verification, and data format validation are required. The same validation processes may be executed repeatedly at different stages of request processing, leading to redundant calculations and increased performance overhead. Especially in high-concurrency scenarios, redundant calculations consume significant resources, limiting performance in such environments.

[0020] To reduce the resource overhead of repeatedly performing the same verification process, relevant technical solutions store the verification result in an in-process cache (such as a global cache pool or database cache) after performing the verification process for later use. However, this caching scheme still has the following problems: 1. Insufficient scalability: The validation logic is tightly bound to the business logic. When a new validation type needs to be introduced or existing validation logic needs to be modified, the core business code related to the request must be modified synchronously. This makes it difficult to dynamically extend the validation logic and increases the maintenance burden.

[0021] II. Challenges in Distributed Collaboration: Caching is typically confined to a single service or process. When the processing chain of a business request spans multiple service processes, the cache spaces of different service processes are isolated from each other. That is, one service process usually has difficulty accessing the cache space of another service process, making it difficult for different service processes to reuse the verification results of the same verification logic. This caching scheme struggles to reduce the redundant computational overhead of cross-service verification processing.

[0022] Third, it increases security risks: In a multi-threaded environment of the service process, it is easy to cause multiple threads to compete for the cache, which increases the complexity of managing the verification results in the cache, and increases the overall complexity and failure risk.

[0023] Based on this, embodiments of this application provide a request processing scheme. The verification results of one or more (one or more can be understood as at least one) verification items are cached within the request context of the user request. Upon receiving a user request, the system responds to the user request and processes it. During the processing of the user request, if any verification item to be executed is detected, the verification result of that verification item is retrieved from the request context of the user request. If the verification result of that verification item indicates that the user request passes the verification of that item, the user request continues to be processed without executing the corresponding verification processing. By caching the verification results of one or more verification items in the request context, the verification results of the same verification items can be reused in subsequent processing, reducing the repeated execution of the same verification item's verification processing, lowering the performance overhead of request processing, and improving the efficiency of request processing.

[0024] The request processing scheme provided in this application is applicable to any request processing business scenario. For example, this method is suitable for request processing business scenarios with high concurrency or distributed architecture. The request processing scheme provided in this application is described below with reference to the accompanying drawings.

[0025] First, this application provides a request processing method. The following describes the request processing method provided by this application using an electronic device as the execution subject. The electronic device in this application can be a server, computer, or other device with computing power. For example, in a distributed architecture business scenario, the electronic device can act as any node (such as a service node) in the distributed system or host any node in the distributed system. This node can be a gateway node, server, service instance, etc. This application does not limit the specific form of the electronic device.

[0026] like Figure 1 As shown, the request processing method provided in this application embodiment includes the following steps: Step 101: The electronic device receives the user request; Step 102: In response to the user request, if the first verification item is detected, the electronic device obtains the verification result of the first verification item in the request context of the user request; Step 103: If the verification result of the first verification item is the first result, the electronic device will continue to process the user request without performing the verification process of the first verification item.

[0027] In step 101, the user request can be an operation instruction or message in any business scenario. For example, in a transaction scenario, the user request can be a business request such as a transfer request or a payment request.

[0028] In practical applications, electronic devices receive user requests sent or forwarded by clients, user terminals, or any node in a distributed system. Alternatively, a service process within an electronic device receives a user request sent by another service process.

[0029] In step 102, the first verification item is any verification item requested by the user. For example, the first verification item is a verification item used for permission verification. Or, the first verification item is a verification item used for data format verification. Or, the first verification item is a verification item used for business logic verification.

[0030] The validation result of a validation item indicates whether a user request passes the validation for that item. For example, if a user request passes the validation of an item, the validation result for that item is the first result. The first result indicates that the user request passes the validation of that item; that is, the first result indicates that the validation is successful. If a user request fails the validation of an item, the validation result for that item is the second result. The second result indicates that the user request fails the validation of that item; that is, the second result indicates that the validation is unsuccessful.

[0031] The request context (or request context object) is used to store information related to user requests. For example, the request context includes metadata, validation results of one or more validation items, and memory offsets of business data. The metadata includes request identifiers, user identity identifiers, business parameters, business attributes, timestamps, etc. The request context is bound to the corresponding user request and stores and manages relevant information about the user request throughout its processing cycle.

[0032] In some implementations, the validation result of a validation item recorded in the request context can be represented by a validation flag. For example, when the validation flag of a validation item is "1" or "true", it indicates that the validation result of that validation item is successful (i.e., the first result). When the validation flag of a validation item is "0" or "false", it indicates that the validation result of that validation item is unsuccessful (i.e., the second result).

[0033] In practical applications, electronic devices respond to user requests and process them. This processing may involve verifying one or more validation items. If the electronic device detects any one of these validation items, taking the first validation item as an example, the device will determine whether the validation result of the first validation item is recorded in the request context of the user request.

[0034] In some implementations, after receiving a user request, the electronic device first parses the request. The user request may carry the verification results of one or more validation items. Then, the electronic device creates a corresponding request context for the user request. If the user request carries the verification results of one or more validation items, the electronic device writes the verification results of those items into the request context created for the user request.

[0035] When a user request carries the verification results of one or more verification items, the electronic device records the verification results of one or more verification items in the request context corresponding to the user request, so that the verification results of one or more verification items can be reused in subsequent processes, thereby avoiding repeated execution of the same verification item verification process, improving request processing efficiency and resource utilization.

[0036] In practical applications, electronic devices create an independent request context for each user request. Different user requests correspond to different request contexts, thereby isolating the relevant information between different user requests.

[0037] To quickly access requested business data, some implementations allow electronic devices to record the memory offset addresses of the required business data within the request context. For example, the electronic device can determine the access frequency of business data that might be accessed during the user request processing based on the type of business requested. The device can then pre-load business data with an access frequency exceeding a preset threshold and store the corresponding memory offset addresses in the request context. The access frequency of the business data can be determined based on historical user requests of the same business type. When the requested business data needs to be accessed, the electronic device directly accesses the corresponding business data based on the memory offset addresses in the request context and continues processing the user request based on the accessed data, thereby improving request processing efficiency.

[0038] For example, Figure 2 This diagram illustrates the memory offset addresses of multiple associated attribute business data in a user request, as recorded in the request context. The data structure storing these memory offset addresses in the request context includes: a user token ((User / ClientToken), P1, P2, P3, ..., PN). The user token provides an index for the associated data in the user request; P1 represents the memory offset address corresponding to associated attribute 1; P2 represents the memory offset address corresponding to associated attribute 2; P3 represents the memory offset address corresponding to associated attribute 3; ...; PN represents the memory offset address corresponding to associated attribute N. N is a positive integer.

[0039] Taking a user request whose business type is a transaction request as an example, during the transaction request processing, the electronic device may frequently access transaction amount data. Assume the transaction amount data is the business data of the transaction amount attribute of the transaction request. After the electronic device determines that the transaction amount attribute is a frequently accessed associated attribute, it writes the memory offset address corresponding to the transaction amount attribute into the request context of the transaction request; that is, it writes the memory offset address of the transaction amount data into the request context of the transaction request. In this way, during the processing of the transaction request, the electronic device can quickly access the transaction amount data through the memory offset address of the transaction amount data cached in the request context.

[0040] In this embodiment, the electronic device can preload the business data required by the user request during processing, based on the user's business needs, thereby enabling rapid access to the required business data during request processing. In some implementations, the electronic device can also reserve multiple fields in the request context. These reserved fields are used for request context expansion. For example, the electronic device can reserve three fields in the request context. In this way, when the electronic device writes new information to the request context according to actual needs, it does not need to modify the request context's data structure; it can directly write the new information to the reserved fields, thus achieving a smooth transition in the request context.

[0041] In this embodiment of the application, during the processing of a user request, the electronic device can detect one or more verification items through a verification interceptor. Upon detecting any verification item (such as a first verification item), the verification interceptor intercepts the verification processing of the first verification item and searches for the verification result of the first verification item in the request context of the user request. If the verification result of the first verification item exists in the request context, the electronic device obtains the verification result of the first verification item.

[0042] In some implementations, a validation interceptor can detect one or more validation items based on their validation declarations. A validation declaration is a predefined way of identifying validation items. For example, a validation declaration can be a VALIDATE macro declaration, a decorator, an annotation, etc. If the validation interceptor detects a validation declaration for any validation item, it considers that validation item has been detected. In this case, the electronic device intercepts the validation processing of that validation item through the validation interceptor and looks up the validation result of that validation item in the request context of the user request.

[0043] Understandably, validation interceptors are execution units implemented using C++ templates and lambda expressions, based on Aspect-Oriented Programming (AOP) technology. Validation interceptors implement a validation result reuse process using the decorator pattern. By checking one or more validation items through validation declarations, electronic devices can intercept the validation logic of one or more validation items using the decorator pattern. That is, electronic devices can achieve non-intrusive validation logic interception, thereby adding a validation item reuse step to the request processing flow without modifying the original core business logic code, reducing the cost of validation result reuse.

[0044] In step 103, if the verification result of the first verification item is the first result, meaning the verification result of the first verification item indicates that the verification has passed, it means that the verification processing of the first verification item has already been executed and passed in the previous user request processing. In this case, the electronic device will skip the verification processing of the first verification item and continue to execute the business process of the user request, thus reusing the verification result of the first verification item. By reusing the verification result of the verification item, the repeated execution of the same verification item is reduced, the performance overhead of request processing is reduced, and the efficiency of request processing is improved.

[0045] In some implementations, if the verification result of the first verification item is not present in the request context of the user request, it indicates that the first verification item has not been verified in the previous processing flow. In this case, the electronic device performs the verification processing of the first verification item for the user request and obtains the verification result of the first verification item. After performing the verification processing of the first verification item, the electronic device writes the verification result of the first verification item into the request context of the user request so that the verification result of the first verification item can be reused in subsequent processing flows.

[0046] In some implementations, if the validation result of the first validation item in the request context of the user request is the second result, it indicates that the user request failed the validation of the first validation item in the previous processing flow. In this case, the electronic device can terminate the processing flow of the user request without performing the validation processing of the first validation item and return a validation failure message.

[0047] To reduce the impact of temporary states or recoverable errors on the user request processing flow, some implementations define a second result as follows: if the validation result of the first validation item in the user request's request context is a second result, it indicates that the user request failed the validation of the first validation item in the previous processing flow. In this case, the electronic device can re-execute the validation process of the first validation item to obtain its validation result. After executing the validation process of the first validation item, the electronic device writes the validation result of the first validation item into the user request's request context for reuse in subsequent processing flows.

[0048] In some implementations, if the verification result of the first verification item in the request context of the user's request is the second result, the electronic device can also determine whether to re-execute the verification process of the first verification item based on the verification type of the first verification item.

[0049] If the verification type of the first verification item is the first verification type, the electronic device will re-execute the verification process for the first verification item. For example, if the first verification item is a temporary verification type, such as a dynamic password verification item, the electronic device will re-execute the verification process for the first verification item and write the verification result of the first verification item obtained after the verification process into the request context of the user request.

[0050] If the first verification item is of the second verification type, the electronic device will terminate the user request processing flow and return a verification failure message. For example, if the first verification item is a user permission verification item, such as an identity authentication verification item, the electronic device will terminate the user request processing flow without performing the verification processing of the first verification item and return a verification failure message.

[0051] In this embodiment, the electronic device determines whether to perform the verification process of the first verification item based on the request context of the user request, thereby avoiding unnecessary repeated verification processes, improving the processing efficiency of user requests and resource utilization, and enhancing the stability and performance of request processing in high-concurrency scenarios.

[0052] To enhance the scalability and flexibility of the request processing flow, some implementations encapsulate and invoke the validation logic code of validation items through templates and macro definitions, thereby achieving non-intrusive dynamic expansion of validation items. For example, the validation logic code of each validation item is encapsulated as a validator. Taking the first validation item as an example, when the electronic device detects the validation declaration of the first validation item, the validator of the first validation item is invoked through the validator factory to perform validation processing on the user request, and the validation result of the first validation item is obtained.

[0053] Verification claims are used to trigger verification processing for verification items. A verification claim includes a verification identifier for the verification item. The verification identifier identifies the corresponding verification item. Electronic devices can use verification claims to test one or more verification items.

[0054] A validator factory manages validators for one or more validation items. The validator factory maintains a mapping between validation identifiers for validation items and their validators. Based on this mapping, the validator factory dynamically loads the validator corresponding to the validation identifier to perform validation processing. The validator factory can also update the maintained mapping based on the validation item's configuration file. For example, when adding a new validation item, the validator factory creates the new validator for the new validation item based on the new validation item's configuration file and registers the mapping between the new validation item's validation identifier and the validator. During this process, the core business logic of the request processing flow does not need to be modified, thus achieving scalability and flexibility for validation items.

[0055] To ensure safe access to the request context, some implementations use locking mechanisms to enable thread-safe access. For example, an electronic device can set a mutex (represented as std::mutex) or a read-write lock for the request context. Under the control of these locks, only one thread is allowed to modify the request context at any given time, thus improving its security.

[0056] When writing the verification result of the first verification item to the request context, the electronic device checks whether the request context is in an unlocked state. If the request context is in a locked state, it indicates that another thread is operating on the request context. In this case, the electronic device waits for the other thread to release the security lock of the request context, that is, waits for the request context to become unlocked.

[0057] If the request context is unlocked, the electronic device acquires the security lock of the request context, locking it and thus excluding its access permissions. When the request context is locked, the electronic device writes the validation result of the request context to it. During this period, the request context is locked, and other threads cannot modify it.

[0058] After the electronic device writes the verification result of the first verification item into the request context, the electronic device releases the security lock of the request context, that is, sets the request context to an unlocked state, thereby allowing other threads to access the request context.

[0059] In this embodiment of the application, by locking the request context when modifying the request context, the consistency and integrity of the request context in multi-threaded access scenarios can be achieved, thereby improving the stability and reliability of the reuse of verification results.

[0060] In this embodiment, the processing of a user request by the electronic device may only be one stage in the overall processing flow of that user request. In a distributed architecture, the entire processing flow of a user request may involve the collaborative processing of multiple nodes. When a user request needs to be processed across processes or nodes, the electronic device can obtain the verification results of one or more verification items in the request context of the user request. Then, the electronic device serializes the verification results of one or more verification items and carries the serialized verification results of one or more verification items in the user request. The electronic device sends the user request carrying the verification results to other service processes or service nodes, so that other service processes or service nodes can obtain the verification results corresponding to one or more verification items in the user request, thereby achieving the reuse of verification results.

[0061] For example, when a user request requires cross-process or cross-node processing, the electronic device obtains the verification flags (i.e., verification results) corresponding to one or more verification items in the request context, and serializes the verification flags corresponding to one or more verification items into JSON (JavaScript Object Notation) format verification information. Taking a Hypertext Transfer Protocol (HTTP) request as an example, the electronic device carries the JSON format verification information in the HTTP request header and sends the HTTP request containing the verification information. After receiving the HTTP request, the receiver (such as other service processes or other service nodes) parses the verification results of one or more verification items from the HTTP request header and injects the verification results of one or more verification items into the request context created for the HTTP request to achieve the reuse of verification results.

[0062] The request processing method provided in this application embodiment is described below through an application example. In this example, the user request is an HTTP request, and a service process in an electronic device receives the HTTP request. Figure 3 As shown, the request processing method provided in this application example includes the following steps: Step 301: The service process responds to the HTTP request by parsing the HTTP request and creating the request context for the HTTP request; The service process receives HTTP requests from clients or other service processes. After receiving an HTTP request, the service process parses the HTTP request and creates a request context bound to the main thread.

[0063] The service process injects the metadata of the HTTP request into the created request context.

[0064] An HTTP request may carry the validation results of one or more validation items. When an HTTP request carries the validation results of one or more validation items, the service process writes the validation results of one or more validation items into the created request context.

[0065] The service process can also write the memory offset address of business data of one or more related attributes that may be frequently used during the processing of the HTTP request into the request context of the HTTP request.

[0066] Step 302: The service process detects the first checksum during the processing of the HTTP request; During the processing of an HTTP request, the service process may involve the validation of one or more validation items. The service process uses a validation interceptor to check one or more validation items during the HTTP request processing. Taking the first validation item as an example, if the validation interceptor detects the first validation item, it will block the validation processing of the first validation item.

[0067] Step 303: The service process determines whether the verification result of the first verification item exists in the request context; if the verification result of the first verification item exists in the request context, proceed to step 304; otherwise, proceed to step 305. The service process uses a verification interceptor to look up the verification result of the first verification item in the HTTP request.

[0068] If the cached verification result of the first verification item exists in the request context of the HTTP request, the service process obtains the verification result of the first verification item through the verification interceptor and executes step 304.

[0069] If the cached verification result of the first verification item is not present in the request context of the HTTP request, the service process performs the verification processing of the first verification item, i.e., executes step 305.

[0070] Step 304: The service process determines whether the verification result of the first verification item is the first result; if the verification result of the first verification item is the first result, then proceed to step 306; otherwise, proceed to step 305. The service process uses a verification interceptor to determine whether the verification result of the first verification item is the first result indicating that the verification has passed.

[0071] If the verification result of the first verification item is the first result indicating that the verification has passed, such as the verification flag of the first verification item being "true" (i.e., the first result), the service process will skip the verification processing of the first verification item and execute step 306.

[0072] If the verification result of the first verification item is a second result indicating that the verification failed, such as the verification flag of the first verification item being "false" (i.e., the second result), the service process performs the verification processing of the first verification item and executes step 305.

[0073] Step 305: The service process performs the verification processing of the first verification item for the HTTP request and writes the verification result of the first verification item into the request context; If it is confirmed that a validation handler for the first validation item needs to be executed, the service process passes the validation identifier of the first validation item to the validation factory through the validation interceptor. The service process registers and creates a validation handler for the first validation item through the validation factory and loads the validation handler for the first validation item. The service process executes the validation processing of the first validation item through the validation handler for the first validation item, obtains the processing result of the first validation item, and writes the validation result of the first validation item into the request context of the HTTP request.

[0074] If the processing result of the first verification item indicates that the verification has passed, such as the verification flag of the first verification item being "true" (i.e., the first result), the service process will continue to execute step 306.

[0075] If the verification result of the first verification item is a second result indicating that the verification failed, such as the verification flag of the first verification item being "false" (i.e., the second result), the service process can terminate the current processing flow and issue a verification failure message. Alternatively, the service process can continue to execute step 306, wait for the local processing flow to finish, summarize the verification results of all verification items, and then issue a verification details message.

[0076] Step 306: The service process continues to execute the HTTP request processing flow; During the processing of HTTP requests, the service process may access business data for one or more associated attributes. To improve the access speed of this business data, the service process pre-loads the business data for one or more associated attributes that may be used during HTTP request processing, based on the business type and request context of the HTTP request. During HTTP request processing, the service process obtains the memory offset address corresponding to the one or more associated attributes to be accessed from the request context and reads the business data for those attributes using the obtained memory offset address. Directly accessing business data through the memory offset address shortens the business data access path, reduces resource overhead, and accelerates the access speed.

[0077] To improve memory resource utilization, the service process can also dynamically manage cached business data. For example, during HTTP request processing, the Least Recently Used (LRU) algorithm can be used to determine the business data of the least accessed related attributes in a recent period. When cache space is insufficient, the service process evicts the business data of the least accessed related attributes from the cache. Alternatively, the service process can adjust the position of one or more related attributes in the cache based on the access frequency of each related attribute's business data, storing the business data of more frequently accessed related attributes in the high-speed cache. In this way, memory resource utilization can be improved, the access speed of business data can be increased, and support for high-concurrency business scenarios can be provided.

[0078] Step 307: When an HTTP request involves processing by other service processes, the service process sends an HTTP request to the other service processes; If an HTTP request requires further processing by other services, and the current service process completes its local processing of the HTTP request, the service process serializes the verification results of all validation items recorded in the request context. For example, the service process converts the verification results of one or more validation items into JSON format to obtain the verification information. Then, the service process includes the serialized verification information in the HTTP request header and sends the HTTP request containing the verification information to other service processes.

[0079] After receiving an HTTP request, other service processes parse the verification results of one or more verification items from the verification information in the HTTP request header, and write the verification results of one or more verification items into the created request context to achieve cross-service transmission and reuse of verification results.

[0080] Step 308: The service process deletes the request context of the HTTP request; After processing an HTTP request, the service process deletes the request context of the HTTP request. For example, after the service process has completed local processing of the HTTP request, or after the entire processing flow of the HTTP request has been completed, the service process deletes the request context created for the HTTP request, thereby reclaiming memory resources.

[0081] The method provided in this application, through request context, dynamic validator factory, and declarative interception mechanism, achieves caching and reuse of verification results, improving system throughput and making it suitable for high-concurrency scenarios such as financial transactions and real-time risk control. This method has at least the following advantages: First, secure access in multi-threaded, high-concurrency scenarios is achieved by using a security lock (such as a mutex) mechanism built into the request context.

[0082] Second, the zero-intrusive dynamic registration of the validator is achieved through template metaprogramming and macro definition, which improves the scalability and maintainability of the verification process.

[0083] Third, by serializing the verification flag in the request context, the request is passed across services, enabling the reuse and collaborative processing of verification results in a distributed architecture.

[0084] Fourth, by preloading business data and recording memory offset addresses, efficient access to business data is achieved.

[0085] To implement the request processing method provided in the embodiments of this application, the embodiments of this application also provide a request processing apparatus. For example... Figure 4 As shown, the device includes: Communication module 41 is used to receive user requests; The detection module 42 is configured to, in response to the user request, obtain the verification result of the first verification item in the request context of the user request if the first verification item is detected; The processing module 43 is configured to continue processing the user request without performing the verification processing of the first verification item if the verification result of the first verification item is the first result; wherein the first result indicates that the user request passes the verification of the first verification item.

[0086] In some alternative implementations, the processing module 43 is further configured to: If the verification result of the first verification item does not exist in the request context, or if the verification result of the first verification item is the second result, then the verification processing of the first verification item is performed on the user request to obtain the verification result of the first verification item; wherein, the second result indicates that the user request has failed the verification of the first verification item. Write the verification result of the first verification item into the request context.

[0087] In some alternative implementations, the processing module 43 is specifically used for: With the request context locked, the verification result of the first verification item is written into the request context.

[0088] In some alternative implementations, the processing module 43 is specifically used for: The validator corresponding to the first verification item is invoked to perform verification processing on the user request, and the verification result of the first verification item is obtained.

[0089] In some alternative implementations, the detection module 42 is further configured to: The user request is parsed; If the user request carries the verification results of one or more verification items, the verification results of the one or more verification items are written into the request context created for the user request.

[0090] In some optional implementations, the request context also includes the memory offset address of the business data; the processing module 43 is further configured to: Access the corresponding business data based on the memory offset address in the request context; The user request will continue to be processed based on the business data.

[0091] In some alternative implementations, the communication module 41 is further configured to: Send a user request, the user request carrying the verification results of one or more verification items in the request context.

[0092] In practical applications, the communication module 41 can be implemented by the processor in the request processing device in combination with the communication interface, and the detection module 42 and the processing module 43 can be implemented by the processor in the request processing device.

[0093] It should be noted that the request processing apparatus provided in the above embodiments is only illustrated by the division of the above-described program units. In practical applications, the above processing can be assigned to different program units as needed, that is, the internal structure of the apparatus can be divided into different program units to complete all or part of the processing described above. In addition, the request processing apparatus and the request processing method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0094] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiments of this application, the embodiments of this application also provide an electronic device, such as... Figure 5 As shown, the electronic device includes: The communication interface 501 is capable of exchanging information with other electronic devices (such as other service nodes); The processor 502 is connected to the communication interface 501 to enable information interaction with other electronic devices (such as other service nodes) and to execute the methods provided by one or more of the above technical solutions when running computer programs; The computer program is stored in memory 503.

[0095] Specifically, the processor 502, in conjunction with the communication interface 501, receives user requests; The processor 502 is also used for: In response to the user request, if the first verification item is detected, the verification result of the first verification item is obtained in the request context of the user request; If the verification result of the first verification item is the first result, then the user request will continue to be processed without performing the verification process of the first verification item; wherein, the first result indicates that the user request has passed the verification of the first verification item.

[0096] In some alternative implementations, the processor 502 is further configured to: If the verification result of the first verification item does not exist in the request context, or if the verification result of the first verification item is the second result, then the verification processing of the first verification item is performed on the user request to obtain the verification result of the first verification item; wherein, the second result indicates that the user request has failed the verification of the first verification item. Write the verification result of the first verification item into the request context.

[0097] In some alternative implementations, the processor 502 is specifically used for: With the request context locked, the verification result of the first verification item is written into the request context.

[0098] In some alternative implementations, the processor 502 is specifically used for: The validator corresponding to the first verification item is invoked to perform verification processing on the user request, and the verification result of the first verification item is obtained.

[0099] In some alternative implementations, the processor 502 is further configured to: The user request is parsed; If the user request carries the verification results of one or more verification items, the verification results of the one or more verification items are written into the request context created for the user request.

[0100] In some optional implementations, the request context also includes the memory offset address of the business data; the processor 502 is specifically used for: Access the corresponding business data based on the memory offset address in the request context; The user request will continue to be processed based on the business data.

[0101] In some alternative implementations, the processor 502, in conjunction with the communication interface 501, sends a user request, the user request carrying the verification results of one or more verification items in the request context.

[0102] It should be noted that the specific processing procedures of the processor 502 and the communication interface 501 can be understood by referring to the above method.

[0103] Of course, in practical applications, the various components in an electronic device are coupled together through a bus system 504. It can be understood that the bus system 504 is used to realize the connection and communication between these components. In addition to a data bus, the bus system 504 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, in... Figure 5 The general designated all buses as Bus System 504.

[0104] The memory 503 in this embodiment is used to store various types of data to support the operation of the electronic device. Examples of such data include any computer program used to operate on the electronic device.

[0105] The methods disclosed in the embodiments of this application can be applied to the processor 502, or implemented by the processor 502. The processor 502 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in the processor 502 or by instructions in the form of software. The processor 502 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor 502 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in the memory 503. The processor 502 reads the information in the memory 503 and combines its hardware to complete the steps of the aforementioned method.

[0106] In an exemplary embodiment, the electronic device may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned method.

[0107] It is understood that the memory 503 in this embodiment can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memories described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable types of memories.

[0108] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a memory 503 storing a computer program, which can be executed by a processor 502 of an electronic device to complete the steps described in the aforementioned method. The computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM.

[0109] In an exemplary embodiment, this application also provides a computer program product, including a computer program that can be executed by a processor 502 of an electronic device to perform the steps described in the foregoing method.

[0110] It should be noted that terms such as "first" and "second" are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0111] Furthermore, the technical solutions described in the embodiments of this application can be combined arbitrarily without conflict.

[0112] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application.

Claims

1. A request processing method characterized by comprising: The method includes: Receive user requests; In response to the user request, if the first verification item is detected, the verification result of the first verification item is obtained in the request context of the user request; If the verification result of the first verification item is the first result, then the user request will continue to be processed without performing the verification process of the first verification item; wherein, the first result indicates that the user request has passed the verification of the first verification item.

2. The method of claim 1, wherein, The method further includes: If the verification result of the first verification item does not exist in the request context, or if the verification result of the first verification item is the second result, then the verification processing of the first verification item is performed on the user request to obtain the verification result of the first verification item; wherein, the second result indicates that the user request has failed the verification of the first verification item. Write the verification result of the first verification item into the request context.

3. The method of claim 2, wherein, The step of writing the verification result of the first verification item into the request context includes: With the request context locked, the verification result of the first verification item is written into the request context.

4. The method of claim 2, wherein, The step of performing the verification processing on the user request for the first verification item to obtain the verification result of the first verification item includes: The validator corresponding to the first verification item is invoked to perform verification processing on the user request, and the verification result of the first verification item is obtained.

5. The method of claim 1, wherein, In response to the user request, the method further includes: The user request is parsed; If the user request carries the verification results of one or more verification items, the verification results of the one or more verification items are written into the request context created for the user request.

6. The method of claim 1, wherein, The request context also includes the memory offset address of the business data; continuing to process the user request includes: Access the corresponding business data based on the memory offset address in the request context; The user request will continue to be processed based on the business data.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: Send a user request, the user request carrying the verification results of one or more verification items in the request context.

8. An electronic device, comprising: include: Processor and memory used to store computer programs that can run on the processor; When the processor is used to run a computer program, it executes the steps of the method according to any one of claims 1 to 7.

9. A storage medium having stored thereon a computer program, characterized in that When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer program product comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images