Request processing method, system and equipment based on configuration drive and medium

Abstract

The invention provides a request processing method, system and device based on configuration driving and a medium, and belongs to the technical field of network request processing.The method comprises the steps that a configuration template for client request processing is constructed in advance, the configuration template is filled in according to project requirements, the corresponding relation between a matching rule and modification operation is constructed, and a configuration file is generated; establishing client request processing logic: intercepting a client request, comparing the client request with a matching rule in the configuration file, and if the matching rule is met, executing a corresponding modification operation to modify the client request; client request processing logic is added in the new client request processing code; and for the existing client request processing code, establishing an agency service for importing the client request processing logic, and providing an agency service address for a client request processing code route. Unified management and dynamic adjustment of client requests are achieved through the configuration file, the requirement change can be rapidly adapted without modifying client codes, and the development and operation and maintenance efficiency is improved.

Description

Technical Field

[0001] This application belongs to the technical field of network request processing, and particularly relates to a request processing method, system, device, and medium based on configuration-driven. Background Art

[0002] In the current client-server application architecture, the processing of client requests has always been an important link in the development and operation and maintenance processes. Currently, there are the following problems in the processing of client request changes: Firstly, a large amount of code modification is required. For current mainstream request frameworks, such as Axios and Fetch API, developers need to manually modify business code to achieve request decoration, such as adding common headers and parameter encryption. Taking an e-commerce application that needs to add X-Auth-Token to all order-related interfaces as an example, hundreds of request call points need to be traversed and modified, resulting in high maintenance costs and long release cycles. Secondly, the dynamic adaptation ability is low. Existing proxy tools, such as Nginx and Traefik, only support path-level routing forwarding and cannot achieve fine-grained decoration based on request content. For example, the proxy system disclosed in related documents needs to use Lua scripts to modify parameters, but the script maintenance is complex and cannot be hot-updated. Thirdly, the environmental adaptability is poor. Traditional solutions need to distinguish between client / server deployment modes. For example, when a financial APP needs to inject Mock data in the test environment, the client must be repackaged, and in the production environment, it is necessary to switch to the server proxy, resulting in fragmented configurations.

[0003] In summary, there are problems such as cumbersome code modification, insufficient dynamic adaptation, and complex environmental configuration in the current client request processing, resulting in low development and operation and maintenance efficiency and high costs. There is an urgent need for a more optimized processing method. Summary of the Invention

[0004] In a first aspect, an embodiment of this application provides a request processing method based on configuration-driven, including the following steps: S1. Pre-build a configuration template for client request processing, fill in the configuration template according to project requirements, construct the corresponding relationship between matching rules and decoration operations, and generate a configuration file; S2. Construct client request processing logic: Intercept client requests and compare them with the matching rules in the configuration file. If the matching rules are met, execute the corresponding decoration operation to modify the client requests; S3. Add client request processing logic to the new client request processing code; S4. For the existing client request processing code, set up a proxy service for importing client request processing logic, and provide the proxy service address to the client request processing code for routing.

[0005] Further, the modification operations in step S1 include header information management, request path rewriting, and request parameter management; In step S1, a configuration template is filled in through an interaction with the user via a pre-created configuration interface. The interaction with the user through the configuration interface reduces the complexity of configuration, enabling non-technical users to easily generate configuration files and improving usability; by defining that the modification operations include header information management, request path rewriting, and request parameter management, common request processing requirements are covered, enhancing practicality.

[0006] Further, the specific steps for executing the client request processing logic in step S2 are as follows: Read the configuration file according to a predefined path and parse it into a configuration tree containing the corresponding relationship between matching rules and modification operations; Intercept client requests in HTTP / HTTPS format and sequentially compare the intercepted client requests with the matching rules in the configuration tree; If there are matching rules that are satisfied, take out the modification operations corresponding to the satisfied matching rules and sequentially execute the taken-out modification operations to modify the intercepted client requests, and send the modified client requests to the target server; If there are no matching rules that are satisfied, no operation is performed, and the original client requests are sent to the target server. Through the client request processing logic of reading, parsing, request interception and comparison, and execution of modification operations of the configuration file, the stability and reliability of the application system are ensured; and requests that satisfy the matching rules can be modified, while requests that do not satisfy remain unchanged, which not only meets the customization requirements but also ensures compatibility.

[0007] Further, the matching rules define request URL, method, or parameter matching conditions through regular expressions. Defining the matching rules through regular expressions enables flexible handling of various complex request URL, method, or parameter matching conditions, improving adaptability and flexibility; developers can precisely define the matching rules according to specific requirements to ensure that only requests that meet specific conditions are processed, avoiding unnecessary operations.

[0008] Further, the specific steps of step S3 are as follows: Build a request processing interface and encapsulate the client request processing logic; Embed the request processing interface into the request link of the new client request processing code. By building a request processing interface and embedding it into the request link of the new client request processing code, seamless integration of the request processing logic is achieved, reducing code invasiveness; it also simplifies the development process of the new client code, enabling developers to complete request processing by simply calling the interface without having to deeply understand the implementation details of the request processing logic.

[0009] Further, the following steps are also included: Build a containerized image for the client request processing logic in step S2; When deploying in the sidecar mode, perform the following operations: Use the containerized image as a sidecar container to share the network namespace with the main application container; Declare the sidecar running mode in the environment variables; Automatically listen to the service ports declared by the main application container; In step S3, run the containerized image in the new client request processing code by adding containerized command lines; In step S4, provide a proxy service address through the sidecar container. Through containerized deployment, different operating environments can be quickly adapted, improving the flexibility and portability of deployment; in the sidecar mode, the containerized image shares the network namespace with the main application container, reducing network latency and improving the performance and stability of the application system.

[0010] Further, after adding the client request processing logic in step S3, set the environment variables of the client request processing logic to the embedded mode; After providing the proxy server address to the client request processing code for routing in step S4, set the environment variables of the client request processing logic in the proxy service to the routing mode and set the service address to the port number corresponding to the client processing logic. By setting environment variables to distinguish between the embedded mode and the routing mode, the application system can flexibly adjust the running mode according to different deployment scenarios, enhancing the adaptability of the application system; operation and maintenance personnel can switch the running mode by simply modifying the environment variables without redeploying the code, improving the operation and maintenance efficiency.

[0011] In a second aspect, an embodiment of the present application further provides a configuration-driven request processing system, including: A configuration file generation module, used to pre-build a configuration template for client request processing, fill in the configuration template according to project requirements, build the corresponding relationship between matching rules and modification operations, and generate a configuration file; A request processing logic construction module, used to construct client request processing logic: Intercept client requests and compare them with the matching rules in the configuration file. If the matching rules are met, perform the corresponding modification operations to modify the client requests; A configuration-driven embedding module, used to add client request processing logic to the new client request processing code; Configure a driver routing module to set up a proxy service for importing client request processing logic for existing client request processing code and provide the proxy service address to the client request processing code for routing. Through the interactive cooperation of the configuration file generation module, the request processing logic module, the intercepted client request module, the configuration driver embedding module, and the configuration driver routing module, the unified management and dynamic adjustment of client requests are realized through the configuration file, quickly adapting to the change of requirements without modifying the client code, thus improving the development and operation and maintenance efficiency.

[0012] In a third aspect, an embodiment of the present application further provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, the steps of the request processing method based on configuration drive as described in the first aspect are implemented.

[0013] In a fourth aspect, an embodiment of the present application further provides a storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the request processing method based on configuration drive as described in the first aspect are implemented.

[0014] It can be seen from the above technical solutions that the present application has the following advantages: In the request processing method, system, device, and medium based on configuration drive provided by the present application, through the configuration drive method, the flexibility and configurability of client request processing are enhanced; users can easily adjust and expand the client request processing logic according to project requirements without significantly modifying the code. The present application not only reduces the development and maintenance costs, but also can quickly respond to the changes in business requirements. At the same time, it supports multiple deployment modes and can be seamlessly integrated with the existing application architecture, improving the application compatibility and scalability. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the technical solutions of the present application, the drawings required to be used in the description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0016] Figure 1 It is a flowchart of the request processing method based on configuration drive of the present invention.

[0017] Figure 2 It is a schematic diagram of the request processing system based on configuration drive of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0018] In the following detailed description of the specific steps of the configuration-driven request processing method, various embodiments of the present disclosure will be more comprehensively described. The present disclosure can have various embodiments and adjustments and changes can be made therein. However, it should be understood that there is no intention to limit the various embodiments of the present disclosure to the specific embodiments disclosed herein, but the present disclosure should be understood to cover all adjustments, equivalents and / or alternative solutions that fall within the spirit and scope of the various embodiments of the present disclosure.

[0019] Exemplarily, in the current client-server application architecture, the processing of client requests is a key link in the development and operation and maintenance processes. However, there are many problems in the existing client request processing methods and urgent improvements are needed.

[0020] First of all, the amount of code modification is huge. Taking the current mainstream request frameworks such as Axios and Fetch API as an example, developers need to manually modify the business code to implement request decoration, such as adding common request headers or encrypting parameters. Taking an e-commerce application as an example, if it is necessary to add X-Auth-Token to all order-related interfaces, developers have to modify hundreds of request call points one by one. This method not only has a high maintenance cost but also prolongs the release cycle.

[0021] Secondly, the dynamic adaptation ability is insufficient. Existing proxy tools such as Nginx and Traefik only support path-based routing forwarding and cannot achieve fine-grained decoration based on the request content. For example, some public proxy systems need to use Lua scripts to modify parameters, but this method has complex script maintenance and cannot achieve hot updates.

[0022] Thirdly, the environmental adaptability is poor. Traditional solutions usually need to distinguish between the deployment modes of the client and the server. For example, a certain financial APP needs to inject Mock data in the test environment, which usually requires repackaging the client. And in the production environment, it is necessary to switch to the server proxy, which leads to fragmented configurations and increases the complexity and cost of operation and maintenance.

[0023] In summary, the current client request processing methods have problems such as cumbersome code modification, insufficient dynamic adaptation ability, and complex environmental configuration. These problems seriously affect the efficiency of development and operation and maintenance and increase the cost. Therefore, there is an urgent need for a more optimized processing method to solve these problems.

[0024] In response to the above problems, this embodiment provides a configuration-driven request processing method, which realizes unified management and dynamic adjustment of client requests through a configuration file, and can quickly adapt to demand changes without modifying the client code.

[0025] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0026] Please refer to Figure 1 The figure shows a flowchart of a configuration-driven request processing method in a specific embodiment. The method includes the following steps: S1. Pre-build a configuration template for client request processing, fill in the configuration template according to project requirements, build the corresponding relationship between matching rules and modification operations, and generate a configuration file; It should be noted that pre-building a configuration template, filling it in according to project requirements, generating a configuration file, and establishing the corresponding relationship between matching rules and modification operations enable the request processing logic to be flexibly configured through the configuration file without modifying the code, improving configurability and maintainability. At the same time, the generation process of the configuration file can be customized according to the requirements of different projects, enhancing adaptability; S2. Build the client request processing logic: Intercept the client request and compare it with the matching rules in the configuration file. If the matching rules are met, execute the corresponding modification operation to modify the client request; It should be noted that building the client request processing logic by intercepting the client request and comparing it with the matching rules in the configuration file, and performing corresponding modification operations according to the comparison results can process the client request in real time and dynamically, improving the accuracy and flexibility of request processing. At the same time, associating the request processing logic with the configuration file makes the request processing logic manageable; S3. Add the client request processing logic to the new client request processing code; It should be noted that adding the client request processing logic to the new client request processing code enables the new code to directly utilize the built request processing logic, improving code reusability and development efficiency. At the same time, by adding the request processing logic, the new code can better adapt to different business requirements, enhancing the system's functionality; S4. Set up a proxy service for importing the client request processing logic for the existing client request processing code, and provide the proxy service address to the client request processing code for routing; It should be noted that a proxy service for importing request processing logic is built for the existing client request processing code, and the proxy service address is provided for routing; this method realizes seamless integration of the existing code, without the need to make large-scale modifications to the existing code, reducing the cost of system upgrade and maintenance; at the same time, the introduction of the proxy service enables the request processing logic to be independently deployed and managed, improving the scalability of the system.

[0027] In this embodiment, the request processing is driven by a configuration file, realizing request interception, matching, modification and routing, simplifying the management of client requests, and reducing the frequency of code changes and redeployment; the use of the configuration file enables the client to quickly adapt to demand changes, and the request processing logic can be adjusted without modifying the code, facilitating expansion and maintenance.

[0028] This application realizes the decoupling of request processing rules and business code. In traditional development, if it is necessary to modify the request header or routing logic, the source code must be modified and redeployed. However, in this application, the rules are defined by an external configuration file, and the requests are dynamically processed by a unified rule engine.

[0029] Taking the example that an e-commerce platform needs to temporarily add a risk control header X-Risk-Check, only the configuration file needs to be updated without releasing a new version. All rules are centrally managed through a configuration tree structure, and the operation and maintenance personnel can directly adjust the regular matching rules through the interface. The old applications are connected through the proxy service, and the new applications are directly integrated with the SDK. The two modes share the same set of configurations.

[0030] Furthermore, as a refinement and extension of the specific implementation manner of the above embodiment, in order to completely illustrate the specific implementation process in this embodiment, another configuration-driven request processing method is provided, and this method includes the following steps: S1. Pre-build a configuration template for client request processing, fill in the configuration template according to project requirements, construct the corresponding relationship between matching rules and modification operations, and generate a configuration file; The modification operations in step S1 include header information management, request path rewriting, and request parameter management; In step S1, the configuration template is filled in through interaction with the user through a pre-created configuration interface; Exemplarily, when developing an e-commerce application, it is necessary to add an authentication header X-Auth-Token to all order-related interfaces, and it is necessary to rewrite the request path from / api / orders to / new-api / orders, and at the same time add a query parameter version=2.0 as an example; Open the configuration interface and select "Add New Rule"; Enter / api / orders in "Request Path"; Select GET and POST in "Supported Methods"; Enter X-Auth-Token and the corresponding value your-token-value in "Add Request Header"; Enter version and the corresponding value 2.0 in "Add Query Parameter"; Enter / new-api / orders in "Rewrite Path"; Click "Save" to generate a configuration file in JSON format; The configuration interface reduces the usage threshold through a form-based design, where: Path matching supports wildcards (*) and regular expressions (such as ^ / order / \d+$); Action choreography allows combining multiple modification operations, such as modifying the header information first and then rewriting the path; Dynamic parameters reference environment variables through ${env.KEY} to avoid hard-coding sensitive information; It should be noted that the configuration file is the core component of this method and defines how to handle client requests; the configuration file is generated through a configuration template, which is a predefined structure for guiding users to fill in necessary information; interacting with users through the configuration interface reduces the complexity of configuration, enabling non-technical users to easily generate configuration files and improving usability; by restricting modification operations to include header information management, request path rewriting, and request parameter management, it covers common request processing requirements and enhances practicality; S2. Build the client request processing logic: Intercept the client request and compare it with the matching rules in the configuration file. If the matching rules are met, execute the corresponding modification operations to modify the client request; The specific steps for executing the client request processing logic in step S2 are as follows: Read the configuration file according to the predefined path and parse it into a configuration tree containing the corresponding relationship between matching rules and modification operations; Intercept client requests in HTTP / HTTPS format and compare the intercepted client requests with the matching rules in the configuration tree one by one; the matching rules define the request URL, method, or parameter matching conditions through regular expressions; It should be noted that defining the matching rules through regular expressions enables flexible handling of various complex request URL, method, or parameter matching conditions, improving adaptability and flexibility; developers can precisely define the matching rules according to specific requirements to ensure that only requests meeting specific conditions will be processed, avoiding unnecessary operations; If there are matching rules that are satisfied, the modification operations corresponding to the satisfied matching rules are retrieved, and the retrieved modification operations are sequentially executed to modify the intercepted client request, and the modified client request is sent to the target server according to the modified client request; If there are no matching rules that are satisfied, no operation is performed, and the original client request is sent to the target server; Take the example of a client sending a request to / api / orders with the method GET; Processing logic: Read the configuration file: Read the configuration file from a predefined path (such as / config / config.json); Parse the configuration file: Parse the configuration file into a configuration tree; Intercept the request: Use middleware or an interceptor to intercept the client request; Compare the matching rules: Check whether the request path / api / orders and the method GET match the rules in the configuration tree; Execute the modification operation: According to the matching rules, modify the request header, add query parameters, and rewrite the path; The modified request path is / new-api / orders; The added request header is X-Auth-Token: your-token-value; The added query parameter is version=2.0; Send the request: Send the modified request to the target server; Specifically, in the loading stage, the configuration file is parsed into a configuration tree in memory, and regular expressions are precompiled to improve performance; in the matching stage, a multi-level hash index is adopted, for example, the path / api / payment is preferentially matched, and then the method POST is verified; in the execution stage, the action chain is sequentially executed for the hit rules, such as injecting the signature header first and then encrypting the request body; It should be noted that the client request processing logic through the reading, parsing, request interception and comparison, and execution of modification operations of the configuration file ensures the stability and reliability of the application system; and requests that meet the matching rules can be modified, and requests that do not meet the requirements remain unchanged, which not only meets the customization requirements but also ensures compatibility; S3. Add client request processing logic to the new client request processing code; The specific steps of step S3 are as follows: Build a request processing interface and encapsulate the client request processing logic; Embed the request processing interface into the request link of the new client request processing code; It should be noted that by constructing a request processing interface and embedding it into the request chain of the new client request processing code, seamless integration of the request processing logic is achieved, reducing code invasiveness; it also simplifies the development process of the new client code, enabling developers to complete request processing by simply calling the interface without having to deeply understand the implementation details of the request processing logic; S4. For the existing client request processing code, set up a proxy service for importing the client request processing logic, and provide the proxy service address to the client request processing code for routing; After adding the client request processing logic in step S3, set the environment variable of the client request processing logic to the embedded mode; After providing the proxy server address to the client request processing code for routing in step S4, set the environment variable of the client request processing logic in the proxy service to the routing mode, and set the service address to the port number corresponding to the client processing logic; The environment variable MODE=router declares the proxy identity to prevent competitors from implementing similar functions through the configuration file; the port number PORTS is dynamically bound to coordinate with the ports of the main container Take the existing e-commerce client application as an example, where the code cannot be directly modified, but the request processing logic needs to be introduced. Proxy service setup: Construct the proxy service: Use Node.js and Express to build a simple proxy service; Set the environment variable: Set the environment variable in the proxy service to distinguish between the embedded mode and the routing mode; Client request routing: Route the client request to the proxy service address; It should be noted that by setting the environment variable to distinguish between the embedded mode and the routing mode, the application system can flexibly adjust the running mode according to different deployment scenarios, enhancing the adaptability of the application system; the operation and maintenance personnel can switch the running mode by simply modifying the environment variable without redeploying the code, improving the operation and maintenance efficiency.

[0031] Take an e-commerce application as an example, where a user sends a request through the client to obtain a product list; The configuration template is a JSON file, and the user fills in the matching rules through the configuration interface: The URL matches / api / products, the method is GET, and the parameter contains category=electronics; Modify the operation: Add the request header X-Custom-Header: custom_value, Rewrite the request path to / new / api / products, Replace the parameter category=electronics with category=smartphones; Generate a configuration file; Intercept the client request GET / api / products?category=electronics; Compare with the matching rules in the configuration file and meet the rules; Perform a modification operation, add the request header X-Custom-Header: custom_value, rewrite the request path to / new / api / products, and replace the parameter with category=smartphones; The modified request is GET / new / api / products?category=smartphones and has the request header X-Custom-Header: custom_value, and is sent to the target server; Build a request handling interface and encapsulate the client request handling logic; Embed the request handling interface into the request chain of the new client request handling code, such as using the Django framework; Set the environment variable to the embedding mode; Set up an Nginx proxy service for the existing client request handling code. Provide the proxy server address to the client request handling code for routing; Set the environment variable of the client request handling logic in the proxy service to the routing mode and set the service address to the port number of the client handling logic.

[0032] Furthermore, as a refinement and extension of the specific implementation manner of the above embodiment, in order to completely illustrate the specific implementation process in this embodiment, another configuration-driven request handling method is provided, and this method further includes the following steps: Build a containerized image for the client request handling logic in step S2; When deploying in the sidecar mode, perform the following operations: Use the containerized image as a sidecar container to share the network namespace with the main application container; Declare the sidecar running mode in the environment variable; Automatically listen to the service port declared by the main application container; It should be noted that the main application container is the container to which the original client and server applications belong; the proxy service is used as a sidecar container, sharing the network namespace with the main application container to achieve transparent traffic interception; thus achieving zero code intrusion, without modifying the main application code, and directly injecting the proxy through container orchestration; it also realizes network optimization, sharing the network namespace and reducing port mapping latency, such as directly listening on localhost; and realizes resource isolation, where the proxy service shares resource limits such as CPU / Memory with the main application, but the network stack is independent. In step S3, the containerized image is run in the new client request handling code by adding containerized command lines. In step S4, the proxy service address is provided through the sidecar container. The sidecar mode realizes network sharing and achieves the following functions through Docker's --network=container: parameter or Kubernetes' shareProcessNamespace: Port listening, where the sidecar automatically discovers the ports declared by the main container, such as EXPOSE 8080. Data path, communicating through Unix domain sockets, such as / var / run / sidecar.sock, which reduces latency compared to TCP. It should be noted that the sidecar mode is a software architecture design pattern that is widely used in microservice architectures; similar to the sidecar of a motorcycle, it runs together with the main application; the sidecar container is an independent container that is closely associated with the main application container, and the two share the network namespace; the core advantage of this mode is to decouple some common functions (such as log collection, monitoring, request handling, etc.) from the main application and encapsulate them into the sidecar container; enabling the main application to not need to be involved in the implementation details of additional functions and only focus on its own core business logic; at the same time, the sidecar container can be developed, deployed, and upgraded independently, improving the maintainability and flexibility of the system.

[0033] Through containerized deployment, it can quickly adapt to different operating environments, improving the flexibility and portability of deployment; in the sidecar mode, the containerized image shares the network namespace with the main application container, reducing network latency and improving the performance and stability of the application system. Through the construction of containerized images and the deployment of the sidecar mode, this application supports the embedding of proxy logic into new application code, and the non-intrusive transformation of old applications through proxy services to achieve seamless integration; reducing network latency through the sidecar mode, simplifying operation and maintenance through Kubernetes integration to achieve flexible deployment; adapting to scenarios such as gray release and multi-tenant isolation through hot update configuration and traffic weight control to achieve dynamic governance; reducing latency by sharing the network namespace and ensuring stability through resource limits.

[0034] It should be understood that the sequence numbers of the steps in the above embodiments do not imply the order of execution. The execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present invention.

[0035] As Figure 2 shown, the following is an embodiment of a configuration-driven request processing system provided by an embodiment of the present disclosure. This system and the configuration-driven request processing methods of the above embodiments belong to the same inventive concept. For the details not described in detail in the embodiment of the configuration-driven request processing system, reference may be made to the embodiments of the above configuration-driven request processing method.

[0036] The system includes: A configuration file generation module, configured to pre-construct a configuration template for client request processing, fill in the configuration template according to project requirements, construct the corresponding relationship between matching rules and modification operations, and generate a configuration file; It should be noted that by pre-constructing a configuration template, filling it in according to project requirements, generating a configuration file, and establishing the corresponding relationship between matching rules and modification operations, the request processing logic can be flexibly configured through the configuration file without modifying the code, improving configurability and maintainability. At the same time, the generation process of the configuration file can be customized according to the requirements of different projects, enhancing adaptability; A request processing logic construction module, configured to construct client request processing logic: Intercept the client request and compare it with the matching rules in the configuration file. If the matching rules are met, execute the corresponding modification operation to modify the client request; It should be noted that by constructing the client request processing logic, intercepting the client request and comparing it with the matching rules in the configuration file, and performing corresponding modification operations according to the comparison results, this method can process the client request in real time and dynamically, improving the accuracy and flexibility of request processing. At the same time, associating the request processing logic with the configuration file makes the request processing logic manageable; A configuration-driven embedding module, configured to add client request processing logic to the new client request processing code; It should be noted that adding client request processing logic to the new client request processing code enables the new code to directly utilize the constructed request processing logic, improving code reusability and development efficiency. At the same time, by adding the request processing logic, the new code can better adapt to different business requirements, enhancing the function of the system; A configuration-driven routing module, configured to set up a proxy service for importing client request processing logic for the existing client request processing code, and provide the proxy service address to the client request processing code for routing; Set up a proxy service for importing request processing logic for existing client request processing code and provide a proxy service address for routing; this method achieves seamless integration of existing code without large-scale modification of the existing code, reducing the cost of system upgrade and maintenance; at the same time, the introduction of the proxy service enables the request processing logic to be independently deployed and managed, improving the scalability of the system.

[0037] In this embodiment, through the interaction and cooperation of the configuration file generation module, request processing logic module, intercepted client request module, configuration driver embedding module, and configuration driver routing module, the unified management and dynamic adjustment of client requests are achieved through the configuration file, enabling quick adaptation to demand changes without modifying the client code and improving the development and operation and maintenance efficiency.

[0038] The request processing method based on configuration drive provided by the embodiments of this application can be applied to electronic devices. Those skilled in the art can understand that the structure of the electronic device involved in the embodiments of the present invention does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements. In the embodiments of the present invention, the electronic device includes, but is not limited to, laptop computers, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown in the figure, their connections and relationships, and their functions are only examples and are not intended to limit the implementation of the embodiments of this application described and / or claimed herein.

[0039] The electronic device may include a processor, an external memory interface, an internal memory, a universal serial bus (USB) interface, a charging management module, a power management module, a battery, a wireless communication module, an audio module, a speaker, a microphone, a sensor module, keys, a camera, a display screen, and a subscriber identity module (SIM) card interface, etc.

[0040] It can be understood that the structure schematically shown in the embodiments of this application does not constitute a specific limitation on the electronic device. In other embodiments of this application, the electronic device may include more or fewer components than shown in the figure, or combine certain components, or split certain components, or have different component arrangements. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0041] The processor may include one or more processing units. For example, the processor may include a central processing unit (CPU), an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Among them, different processing units may be independent devices or integrated in one or more processors.

[0042] Among them, the processor may be the nerve center and command center of the electronic device. The controller may generate operation control signals according to the instruction operation code and timing signals to complete the control of fetching and executing instructions.

[0043] A memory may also be provided in the processor for storing instructions and data. In some embodiments, the memory in the processor is a cache memory. This memory can store the instructions or data that the processor has just used or recycled. If the processor needs to use the instruction or data again, it can directly call it from this memory. This avoids repeated accesses, reduces the waiting time of the processor, and thus improves the system efficiency.

[0044] The above-mentioned electronic device implements the technical solution of pre-constructing a configuration template for client request processing based on the configuration-driven request processing method of the present application, filling in the configuration template according to project requirements, constructing the corresponding relationship between the matching rules and the modification operations, and generating a configuration file; constructing the client request processing logic: intercepting the client request and comparing it with the matching rules in the configuration file. If the matching rules are met, the corresponding modification operation is executed to modify the client request; adding the client request processing logic to the new client request processing code; building a proxy service for importing the client request processing logic for the existing client request processing code and providing the proxy service address to the client request processing code for routing, achieving the beneficial effect of unified management and dynamic adjustment of client requests through the configuration file, quickly adapting to demand changes without modifying the client code, and improving the development and operation and maintenance efficiency.

[0045] In the storage medium provided by the present application, there is a program product capable of implementing the configuration-driven request processing method.

[0046] The configuration-driven request processing method includes: pre-building a configuration template for client request processing, filling in the configuration template according to project requirements, building the corresponding relationship between matching rules and modification operations, and generating a configuration file; building client request processing logic: intercepting client requests, comparing them with the matching rules in the configuration file, and if the matching rules are met, performing the corresponding modification operations to modify the client requests; adding the client request processing logic to the new client request processing code; for the existing client request processing code, setting up a proxy service for importing the client request processing logic, and providing the proxy service address to the client request processing code for routing.

[0047] In some possible implementation manners, the configuration-driven request processing method of the present disclosure may be implemented in the form of a program product, which includes program code. When the program product runs on a terminal device, the program code is used to cause the terminal device to execute the steps according to various exemplary embodiments of the present disclosure described in the "Exemplary Method" section of this specification.

[0048] The storage medium of the present disclosure may adopt any combination of one or more readable media. The readable media may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples (non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0049] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but will be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A configuration-driven request processing method, characterized in that It includes the following steps: S1. Pre-build a configuration template for client request processing, fill in the configuration template according to project requirements, build the corresponding relationship between matching rules and modification operations, and generate a configuration file; S2. Build the client request processing logic: Intercept the client request and compare it with the matching rules in the configuration file. If the matching rules are satisfied, execute the corresponding modification operation to modify the client request; S3. Add the client request processing logic to the new client request processing code; S4. For the existing client request processing code, set up a proxy service for importing the client request processing logic, and provide the proxy service address to the client request processing code for routing.

2. The request processing method based on configuration drive according to claim 1, wherein In step S1, the modification operations include header information management, request path rewriting, and request parameter management; In step S1, the configuration template is filled in through an interaction with the user via a pre-created configuration interface.

3. The request processing method based on configuration driving according to claim 1, wherein The specific steps for executing the client request processing logic in step S2 are as follows: Read the configuration file according to a predefined path and parse it into a configuration tree containing the corresponding relationship between matching rules and modification operations; Intercept client requests in HTTP / HTTPS format and compare the intercepted client requests with the matching rules in the configuration tree one by one; If there are matching rules that are satisfied, take out the modification operations corresponding to the satisfied matching rules and execute the taken-out modification operations in sequence to modify the intercepted client request, and send the modified client request to the target server; If there are no matching rules that are satisfied, no operation is performed, and the original client request is sent to the target server.

4. The request processing method based on configuration drive according to claim 3, wherein The matching rules define the request URL, method, or parameter matching conditions through regular expressions.

5. The request processing method based on configuration drive according to claim 1, wherein The specific steps of step S3 are as follows: Build a request processing interface and encapsulate the client request processing logic; Embed the request processing interface into the request link of the new client request processing code.

6. The method for request processing based on configuration driving according to claim 1, wherein , and also includes the following steps: Build a containerized image for the client request processing logic in step S2; When deploying in the sidecar mode, perform the following operations: Use the containerized image as a sidecar container to share the network namespace with the main application container; Declare the sidecar running mode in the environment variables; Automatically listen for the service ports declared by the main application container; In step S3, run the containerized image by adding containerized command lines in the new client request processing code; In step S4, provide the proxy service address through the sidecar container.

7. The request processing method based on configuration drive according to claim 1, wherein After adding the client request processing logic in step S3, set the environment variables of the client request processing logic to the embedding mode; After providing the proxy server address to the client request processing code for routing in step S4, set the environment variables of the client request processing logic in the proxy service to the routing mode, and set the service address to the port number of the corresponding client processing logic.

8. A configuration-driven request processing system, characterized in that, It includes: A configuration file generation module, which is used to pre-build a configuration template for client request processing, fill in the configuration template according to project requirements, build the corresponding relationship between matching rules and modification operations, and generate a configuration file; A request processing logic construction module, which is used to build the client request processing logic: Intercept the client request and compare it with the matching rules in the configuration file. If the matching rules are satisfied, perform the corresponding modification operation to modify the client request. Configure the driver embedding module, which is used to add client request processing logic to the new client request processing code. Configure the driver routing module, which is used to build a proxy service for importing client request processing logic for the existing client request processing code and provide the proxy service address to the client request processing code for routing.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored on the memory and executable on the processor. It is characterized in that when the processor executes the program, the steps of the request processing method based on configuration drive according to any one of claims 1 to 7 are implemented.

10. A storage medium, on which a computer program is stored, characterized in that, When the computer program is executed by the processor, the steps of the request processing method based on configuration drive according to any one of claims 1 to 7 are implemented.

Images