API gateway request processing method and device, API gateway system and storage medium

Abstract

The invention discloses an API gateway request processing method and device, an API gateway system and a storage medium, and relates to the technical field of gateway data processing, the method is applied to the API gateway system comprising a Netty server and a Netty client, the method is executed by the Netty server, and the method comprises the following steps: receiving a network request sent by the Netty client, converting the network request into an internal request object; performing route matching on the internal request object based on the dynamic route configuration information, and determining a target downstream service; processing the internal request object through a real-time filter chain to obtain a processed request; asynchronously forwarding the processed request to a target downstream service, and receiving response data returned by the target downstream service; and returning the response data to the Netty client.

Description

Technical Field

[0001] This application relates to the field of gateway data processing technology, and in particular to an API gateway request processing method, apparatus, API gateway system and storage medium. Background Technology

[0002] Microservice architecture, due to its improved scalability and maintainability, has gradually replaced monolithic applications in enterprise application systems. However, this architecture also brings new challenges, such as the complexity of inter-service communication, security, and performance issues. Among these, the API (Application Programming Interface) gateway serves as the unified entry point for the microservice architecture, handling all external requests and routing them to the appropriate backend services. It integrates authentication and authorization, traffic control, monitoring and analysis, and other functions, becoming one of the core components of the microservice architecture.

[0003] However, existing mainstream API gateways (such as Spring Cloud Gateway, hereinafter referred to as SCG) are based on Spring WebFlux's multi-layered abstraction and filter blocking operation implementation, which leads to non-blocking I / O (Input / Output) performance loss, limited throughput capacity, and low overall processing efficiency.

[0004] Therefore, how to improve the data processing capabilities of API gateways has become an urgent problem to be solved. Summary of the Invention

[0005] The main objective of this application is to provide an API gateway request processing method, apparatus, API gateway system, and storage medium, aiming to solve the technical problem of how to improve the data processing capabilities of API gateways.

[0006] To achieve the above objectives, this application proposes an API gateway request processing method. This method is applied to an API gateway system that includes a Netty server and a Netty client. The method is executed by the Netty server and includes: Receive network requests sent by the Netty client and convert the network requests into internal request objects; Based on dynamic routing configuration information, the internal request object is routed to determine the target downstream service; The internal request object is processed by a real-time filter chain to obtain the processed request; The processed request is asynchronously forwarded to the target downstream service, and the response data returned by the target downstream service is received. The response data is returned to the Netty client.

[0007] In one embodiment, before performing route matching on the internal request object based on dynamic routing configuration information to determine the target downstream service, the method further includes: Read routing configuration data from the distributed coordination service, and generate a configuration snapshot version in local memory based on the routing configuration data; Register a configuration change listener, and when the configuration change listener detects a configuration change event in the distributed coordination service, synchronize the incremental data corresponding to the configuration change event to the local memory to update the configuration snapshot version; Dynamic routing configuration information is generated based on the updated configuration snapshot version.

[0008] In one embodiment, after receiving the network request sent by the Netty client and converting the network request into an internal request object, the method further includes: Obtain the real-time processing capability metrics corresponding to the Netty client; If the request type corresponding to the network request or the real-time processing capability indicator meets the preset buffering conditions, the internal request object is encapsulated into a request message and stored in a buffer message queue; the consumption rate of the buffer message queue is dynamically adjusted based on the real-time processing capability indicator. The step of performing route matching on the internal request object based on dynamic routing configuration information to determine the target downstream service includes: The request message is retrieved from the buffer message queue and deserialized to obtain the internal request object. Based on dynamic routing configuration information, the internal request object is routed and matched to determine the target downstream service.

[0009] In one embodiment, the step of performing route matching on the internal request object based on the dynamic routing configuration information to determine the target downstream service includes: Extract the path information from the internal request object; A parameterized tree structure is constructed based on the dynamic routing configuration information; The path information is matched with the parameterized tree structure at each level, and the target downstream service is determined based on the successfully matched nodes.

[0010] In one embodiment, the nodes of the parameterized tree structure include static character nodes and parameter capture nodes; The step of matching nodes level by level with the path information and the parameterized tree structure, and determining the target downstream service based on the successfully matched nodes, includes: Based on the path information, perform node traversal matching with the static character nodes to obtain the matching character nodes; At the parameter capture node corresponding to the matching character node, the path information is validated using a pre-compiled regular expression; The parameter capture node that passes the parameter verification is taken as the successfully matched node, and the target downstream service is determined based on the successfully matched node.

[0011] In one embodiment, the step of processing the internal request object through a real-time filter chain to obtain the processed request includes: Load the target filter instance corresponding to the route matching result from the pluggable filter repository; The target filter instances are assembled into a real-time filter chain in a preset order; The internal request object is processed one by one by each filter instance in the real-time filter chain to obtain the processed request.

[0012] In one embodiment, the step of asynchronously forwarding the processed request to the target downstream service and receiving the response data returned by the target downstream service includes: Initialize an asynchronous request sending object, and send the processed request to the target downstream service through the asynchronous request sending object; Register a callback interface and receive response data returned by the target downstream service through the callback interface.

[0013] Furthermore, to achieve the above objectives, this application also proposes an API gateway request processing apparatus. The apparatus is applied to an API gateway system including a Netty server and a Netty client. The apparatus is located within the Netty server. The API gateway request processing apparatus includes: The request processing module is used to receive network requests sent by the Netty client and convert the network requests into internal request objects; The routing matching module is used to perform route matching on the internal request object based on dynamic routing configuration information to determine the target downstream service; The request filtering module is used to process the internal request objects through a real-time filter chain to obtain the processed requests; The request forwarding module is used to asynchronously forward the processed request to the target downstream service and receive the response data returned by the target downstream service; The data interaction module is used to return the response data to the Netty client.

[0014] In addition, to achieve the above objectives, this application also proposes an API gateway system, which includes a Netty server and a Netty client; The Netty server is used to execute the steps of the API gateway request processing method described above.

[0015] In addition, to achieve the above objectives, this application also provides a storage medium storing a program implementing the API gateway request processing method, wherein the program implementing the API gateway request processing method is executed by a processor to implement the steps of the API gateway request processing method as described above.

[0016] This application provides an API gateway request processing method, apparatus, API gateway system, and storage medium. The method is applied to an API gateway system including a Netty server and a Netty client. The method is executed by the Netty server and includes: receiving a network request sent by the Netty client and converting the network request into an internal request object; performing route matching on the internal request object based on dynamic routing configuration information to determine the target downstream service; processing the internal request object through a real-time filter chain to obtain a processed request; asynchronously forwarding the processed request to the target downstream service and receiving response data returned by the target downstream service; and returning the response data to the Netty client.

[0017] This application proposes an API gateway system consisting of a Netty server and a Netty client. It replaces WebFlux with the native Netty framework, reducing the overhead of multiple layers of abstraction. Furthermore, in this gateway system, after the Netty server determines the target downstream service through dynamic routing configuration information, it can employ an asynchronous forwarding mechanism to avoid thread blocking and combine it with a real-time filter chain to achieve unified and efficient request processing. This significantly improves the gateway's throughput, reduces request processing latency, and ultimately enhances the API gateway's data processing capabilities. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the first embodiment of the API gateway request processing method of this application; Figure 2 This is a schematic diagram of the routing configuration process in the first embodiment of the API gateway request processing method of this application; Figure 3 This is a schematic diagram of the request processing process in the first embodiment of the API gateway request processing method of this application; Figure 4 This is a flowchart illustrating the second embodiment of the API gateway request processing method of this application; Figure 5 This is a schematic diagram of the request processing process in the second embodiment of the API gateway request processing method of this application; Figure 6 A simplified flowchart of an API gateway request processing method is provided. Figure 7 This is a schematic diagram of the module structure of the API gateway request processing device according to an embodiment of this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] The main solution of this application is to propose an API gateway request processing method. This method is applied to an API gateway system that includes a Netty server and a Netty client. The method is executed by the Netty server and includes: receiving a network request sent by the Netty client and converting the network request into an internal request object; performing route matching on the internal request object based on dynamic routing configuration information to determine the target downstream service; processing the internal request object through a real-time filter chain to obtain a processed request; asynchronously forwarding the processed request to the target downstream service and receiving the response data returned by the target downstream service; and returning the response data to the Netty client.

[0025] The currently popular open-source gateway system, Spring Cloud Gateway (SCG), uses Route, Predicate, and Filter to match, process, and forward requests, and provides extension points such as global and local filters. Users can implement functions such as authentication, rate limiting, circuit breaking, and monitoring. However, SCG is built on top of Spring WebFlux. WebFlux is based on the Reactor model, which theoretically can achieve completely non-blocking I / O, thus exhibiting excellent throughput performance. However, compared to native Netty, SCG relies on WebFlux, which is based on Netty through multiple layers of abstraction, resulting in significant performance overhead. Furthermore, when filters engage in blocking I / O, it can cause Reactor worker threads to exhaust themselves, leading to high latency and decreased throughput. In other words, the existing mainstream API gateway SCG, based on WebFlux's multi-layered abstraction and blocking filter operations, results in non-blocking I / O performance degradation, limited throughput, and low overall processing efficiency.

[0026] To address this issue, this application proposes an API gateway system consisting of a Netty server and a Netty client. It replaces WebFlux with the native Netty framework, reducing the overhead of multiple layers of abstraction. Furthermore, in this system, after the Netty server determines the target downstream service through dynamic routing configuration information, it can employ an asynchronous forwarding mechanism to avoid thread blocking and combine it with a real-time filter chain to achieve unified and efficient request processing. This significantly improves the gateway's throughput, reduces request processing latency, and ultimately enhances the API gateway's data processing capabilities.

[0027] It should be noted that the method proposed in this embodiment is applied to an API gateway system that includes a Netty server and a Netty client. In this case, the API gateway system can be an integrated system that includes both the Netty server and the Netty client, located between the client and the backend microservices. It serves as a unified entry point to process external requests and forward them to downstream services, integrating core functions such as routing configuration, request processing, filtering, and asynchronous forwarding.

[0028] The Netty server, built on the native Netty framework, is the core processing unit deployed on the server side. It is responsible for receiving Netty client requests, performing route matching, filter processing, asynchronous forwarding, and other operations throughout the entire process, serving as the core computing power carrier of the API gateway system. The Netty client, built on the native Netty framework, is the request initiation unit and can be deployed on terminal devices (such as mobile phones and computers) or other service nodes. It establishes a TCP connection with the Netty server, transmits network requests, and receives response data. The following description uses the Netty server as the execution entity to illustrate this embodiment and the subsequent embodiments.

[0029] Based on this, this application provides an API gateway request processing method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the API gateway request processing method of this application.

[0030] In this embodiment, the API gateway request processing method includes steps S10 to S50: Step S10: Receive a network request sent by the Netty client and convert the network request into an internal request object; It's important to understand that the aforementioned network request can be an HTTP protocol request (transmitted as a byte stream) sent from the Netty client to the server. This request may include a request line (method, path, protocol version), request headers (such as Authorization and Content-Type), and a request body (such as JSON-formatted business data). Correspondingly, during the Netty server initialization process, multiple handlers are registered. Once registration is successful, the Netty server can receive and process requests.

[0031] Therefore, the Netty server can standardize and transform network requests sent by the Netty client to generate corresponding internal processing carriers, namely the aforementioned internal request objects. These internal request objects can include EnhancedHttpRequest objects, encapsulating the complete data of the FullHttpRequest, the Netty context (channel information, request timestamp), and request metadata (source IP (Internet Protocol), request type), etc., for unified invocation within the Netty server's internal processes.

[0032] Step S20: Perform route matching on the internal request object based on dynamic routing configuration information to determine the target downstream service; It is easy to understand that the routing configuration of existing gateway systems relies on static configuration files, and hot updates require restarting the gateway or relying on an external configuration center, making the update process rather cumbersome. In contrast, to simplify the routing configuration process, in this embodiment, the aforementioned dynamic routing configuration information can be a real-time updatable configuration set generated based on the routing rules of a distributed coordination service. This dynamic routing configuration information can be standardized and generated from local memory snapshots after incremental synchronization.

[0033] In one feasible implementation, in this embodiment, steps A1 to A3 may be included before step S20: Step A1: Read the routing configuration data from the distributed coordination service, and generate a configuration snapshot version in local memory based on the routing configuration data; It is understood that the aforementioned distributed coordination service can be middleware that provides configuration storage and change notification functions. For example, in this embodiment, Zookeeper (an open-source distributed coordination service that supports high availability and strong consistency configuration management) can be used as the distributed coordination service to centrally store routing configuration data and perform subsequent fast hot updates of routes.

[0034] For ease of understanding, please refer to Figure 2 Provide an explanation. Figure 2 This is a schematic diagram of the routing configuration process for the first embodiment of the API gateway request processing method of this application. Figure 2 As shown, when the Netty server starts, it can load the Zookeeper connection parameters contained in the configuration center connection parameters, including the Zookeeper cluster address, username, password, etc., and establish a stable connection with the Zookeeper cluster through the Zookeeper client API (such as Curator Framework). After a successful connection, it reads the specified node in Zookeeper to obtain the set of all route-related configurations, i.e., the route configuration data mentioned above.

[0035] At this point, each configuration entry in the routing configuration data can include a route ID (Identification), a path template (such as / user / {id}), a list of target downstream services, matching rules, a list of associated filter IDs, a load balancing strategy, etc., and can be stored in JSON format.

[0036] It should be noted that the above configuration snapshot version can be a copy of the routing rules generated in local memory after the Netty server pulls the complete routing configuration data from Zookeeper and loads the routing rules (i.e., Figure 2The local memory snapshot shown can be stored using a ConcurrentHashMap (with the route ID as the key) to ensure thread safety for multi-threaded reads. This configuration snapshot version can be used later for fast local configuration lookups to reduce reliance on Zookeeper.

[0037] Step A2: Register a configuration change listener, and when the configuration change listener detects a configuration change event in the distributed coordination service, synchronize the incremental data corresponding to the configuration change event to the local memory to update the configuration snapshot version; Step A3: Generate dynamic routing configuration information based on the updated configuration snapshot version.

[0038] It should be noted that the configuration change listener mentioned above can be an event listening component implemented based on ZooKeeper's Watcher mechanism. In this case, after registering the configuration change listener with the ZooKeeper routing configuration root node in the API gateway, the configuration change listener can monitor the addition, modification, and deletion operations of routing configuration data in ZooKeeper in real time.

[0039] At this time, configuration change events can be changes that are automatically triggered in Zookeeper and pushed to the listener when operations and maintenance personnel modify, add, or delete route configurations through the Zookeeper management interface or API. Specifically, they can include information such as change type (add / modify / delete), changed route ID, and changed configuration content (modification / addition scenario).

[0040] Accordingly, incremental data can be specific changed portions of data (not the complete configuration dataset) contained in configuration change events. For example, in a add event, incremental data corresponds to the complete configuration data; in a modify event, incremental data corresponds to the latest changed configuration data; and in a delete event, incremental data corresponds to the route ID. Furthermore, the synchronization of this incremental data can be achieved through pre-configured incremental synchronization logic to avoid the performance overhead of full synchronization. For example, a add event can add the new configuration object to a hash table, a modify event can replace the configuration object corresponding to the route ID, and a delete event can remove the configuration object corresponding to the route ID. In addition, the update process of incremental data can employ a read-write lock mechanism to ensure snapshot consistency.

[0041] Therefore, the dynamic routing configuration information mentioned above can be standardized configuration data formed by formatting the updated local configuration snapshot, which can be directly used for subsequent route matching steps.

[0042] In this embodiment, local snapshots reduce the number of Zookeeper accesses, effectively improving route matching response speed; and incremental synchronization only transmits changed data, reducing network overhead and processing costs. Therefore, this embodiment can achieve millisecond-level hot updates of routing rules through Zookeeper + local snapshots + incremental synchronization algorithm, achieving the effect of avoiding service interruption without restarting the gateway.

[0043] At this point, the Netty server can determine the target downstream service to which the request should be forwarded by matching information rules in the dynamic routing configuration information based on the path information of the internal request object.

[0044] Step S30: Process the internal request object through a real-time filter chain to obtain the processed request; Understandably, in this embodiment, the aforementioned real-time filter chain can be a processing chain composed of multiple functionally independent filter instances arranged according to a preset priority. The real-time filter chain can be used to centrally perform operations such as authentication, rate limiting, and logging on internal request objects. After the internal request object undergoes full-process verification by the real-time filter chain (authentication passed, rate limiting compliant, and data format conversion completed), request data conforming to the downstream service reception standards is generated, which is the aforementioned processed request. This processed request can have filter processing metadata (such as user permission identifiers) added on top of retaining the original business data.

[0045] It should be understood that in this embodiment, the real-time filter chain can be constructed using the chain of responsibility pattern and supports dynamically adding or removing internal filter instances according to business needs, without modifying the gateway's main process code. In a feasible implementation, step S30 in this embodiment may include steps S31-S33: Step S31: Load the target filter instance corresponding to the route matching result from the pluggable filter repository; It is easy to understand that the aforementioned pluggable filter repository can be a filter storage and management component built into the gateway. It can adopt a pluggable architecture and support independent development, deployment, and upgrades of filters. Each filter instance stored in this pluggable filter repository can contain a unique ID, processing logic, configuration parameters (such as rate limiting thresholds), execution priority, etc. Each filter instance can be a specific filter implementation object stored in the pluggable filter repository, which can be developed based on the gateway's unified interface (such as GatewayFilter) and encapsulate specific processing logic (such as JWT (JSONWeb Token) authentication, token bucket rate limiting, etc.).

[0046] At this time, refer to Figure 3 It can be seen that, Figure 3This is a schematic diagram of the request processing process in the first embodiment of the API gateway request processing method of this application. The route matching result can be the target downstream service information determined by the previous route matching step and the associated filter ID list (specified by dynamic route configuration information). Therefore, the Netty server can determine the filter instance to be used now, i.e., the target filter instance, from the pluggable filter repository based on the route matching result, and then perform adaptive assembly based on the target filter instance to generate a filter chain and execute it. If no route matching result exists, the request is directly discarded.

[0047] Step S32: Assemble the target filter instances into a real-time filter chain according to a preset order; Step S33: Process the internal request object one by one through each filter instance in the real-time filter chain to obtain the processed request.

[0048] Understandably, in the real-time filter chain constructed using the chain of responsibility pattern described above, each filter holds a reference to the next filter, allowing internal request objects to flow sequentially through each filter instance. Once processed, the request is passed to the next filter, and the process terminates if any filter fails. In this case, the preset order can be the filter execution priority order preset by the gateway, which can be determined by reading the configured priority of each target filter instance. For example, in the real-time filter chain, target filter instances can be sorted by priority value from smallest to largest, with smaller values ​​appearing earlier; if priorities are the same, they are sorted lexicographically by filter ID.

[0049] The core principle for configuring the priority of each filter instance can be "security first, then traffic, then business, and finally logs". For example, the preset order can be: authentication filter (order=10, which can extract JWT tokens from the request header of the internal request object and verify signature and expiration) -> rate limiting filter (order=20, which can use route ID + user ID as the rate limiting key and obtain the request count of the internal request object from Redis for over-limit judgment) -> log filter (order=40, which is used to extract the request information of the internal request object (such as source IP, path, processing time) and format and store it as log information after successful extraction). The order of different types of filter instances in this preset order can be adjusted according to the actual situation.

[0050] Then, after all filter instances in the real-time filter chain perform the corresponding operations on the internal request object and confirm that there are no abnormalities, an internal request object that conforms to the downstream service acceptance standard and contains standardized request data such as request headers, request bodies, request parameters, and user permission information can be generated. This is the processed request mentioned above. If any filter operation is abnormal, the chain is terminated, and error response data is extracted from the response context and returned directly to the Netty client.

[0051] In this implementation, modular management of filters is achieved through a pluggable filter repository and a chain of responsibility model, which shields the complexity of reactive programming. Developers only need to develop filters based on simple interfaces, effectively improving development efficiency. Furthermore, the pluggable filter repository supports dynamic addition / deletion of filters through configuration without modifying the main process code, thereby significantly reducing maintenance costs.

[0052] Step S40: Asynchronously forward the processed request to the target downstream service and receive the response data returned by the target downstream service; Step S50: Return the response data to the Netty client.

[0053] It's easy to understand that the target downstream service mentioned above can be a backend microservice instance determined through route matching, which is the final destination for request forwarding. The asynchronous forwarding described above can be implemented based on a pre-configured non-blocking I / O model. In this case, the Netty server can send and process the request to the target downstream service asynchronously without blocking and waiting for a response; the thread can continue processing other requests. Simultaneously, the Netty server can receive responses from downstream services through a callback mechanism, avoiding thread blocking.

[0054] Therefore, to address the issues of low utilization and limited throughput of existing synchronous request forwarding threads, in a feasible implementation, step S40 in this embodiment may include steps S41-S42: Step S41: Initialize the asynchronous request sending object, and send the processed request to the target downstream service through the asynchronous request sending object; Step S42: Register a callback interface and receive response data returned by the target downstream service through the callback interface.

[0055] Understandably, the aforementioned asynchronous request sending object can be a pre-configured client component that supports asynchronous non-blocking HTTP request sending, such as AsyncHttpClient developed based on Netty, which features high concurrency, low latency, and connection reuse. The initialization mentioned above likely refers to the process of configuring parameters and allocating resources for AsyncHttpClient during API gateway startup, enabling it to send asynchronous requests.

[0056] For example, when the Netty server starts, an AsyncHttpClient instance can be initialized and its core parameters configured, including the request method (consistent with the original request, such as GET or POST), the request URL (Uniform ResourceLocator, request connection address) (including service address + normalized path), the request header (including the original request header, user permission identifier, and log ID), and the request body (the serialized result of the processed request), and an asynchronous request sending object can be obtained.

[0057] Then you can call the `executeRequest` method of `AsyncHttpClient` to asynchronously send the asynchronous request object to the target service instance. The sending process uses non-blocking I / O. `executeRequest` immediately returns a `CompletableFuture` object, and the sending thread does not need to wait for a response. It can directly return to the thread pool to handle other requests.

[0058] The aforementioned callback interface can be a response receiving interface implemented based on CompletableFuture. It is used to trigger a callback function when the target downstream service returns a response or the request fails, to receive and process response data or error information. The response data can be the result data returned by the target downstream service (normal response or error response), including status code, response headers, and response body.

[0059] For example, a success callback (thenAccept) interface and a failure callback (exceptionally) interface can be registered for a CompletableFuture object. The success callback interface can be triggered when the downstream service returns a normal response, receiving an AsyncHttpResponse object and parsing the status code, response headers, and response body. For example, if the status code is 2xx, the response body is deserialized to obtain normal response data; if the status code is 4xx / 5xx, error information is parsed to generate standardized error response data. The failure callback interface can trigger a callback to receive exception objects (such as TimeoutException) when a request timeout, connection failure, or retry failure is detected. It can also generate error response data based on the exception type (e.g., 504 for timeout, 503 for connection failure, and 500 for other exceptions) and record an exception log (which may include request information and the target service address).

[0060] Finally, once the data callback processing of the target downstream service is complete, the Netty server can write the response data back to the Netty client, completing the entire request processing flow.

[0061] In this implementation, AsyncHttpClient, developed based on Netty, is well-compatible with the underlying gateway framework and can be combined with asynchronous non-blocking I / O to improve thread utilization, enhance gateway throughput, and reduce overall request processing latency. At the same time, it is combined with callback interfaces to ensure timely reception of response data, and with a failure retry mechanism, it improves the reliability of request forwarding.

[0062] In summary, this embodiment proposes a high-performance API gateway system based on Netty and custom dynamic routing. By using the native Netty framework instead of WebFlux, the overhead of multi-layered abstraction is significantly reduced and the thread resource exhaustion problem caused by blocking I / O is avoided, thereby improving gateway throughput and reducing latency.

[0063] Meanwhile, this embodiment provides a hybrid persistence strategy for routing. By storing the routing configuration in Zookeeper and combining local memory snapshots and incremental synchronization, millisecond-level hot updates of the routing configuration are achieved, reducing frequent access to the configuration center Zookeeper, improving response speed, and achieving the effect of not needing to restart the gateway or rely on an external configuration center.

[0064] Furthermore, this embodiment provides pluggable filter management, shielding the complexities of reactive programming and the Reactor API. Developers can quickly implement filter logic by configuring a pluggable filter repository, effectively improving development efficiency. It also supports dynamically adding or deleting filters based on business needs without modifying the gateway's main workflow code.

[0065] This embodiment provides an API gateway request processing method. The method is applied to an API gateway system including a Netty server and a Netty client. The method is executed by the Netty server and includes receiving a network request sent by the Netty client and converting the network request into an internal request object; performing route matching on the internal request object based on dynamic routing configuration information to determine the target downstream service; processing the internal request object through a real-time filter chain to obtain a processed request; asynchronously forwarding the processed request to the target downstream service and receiving response data returned by the target downstream service; and returning the response data to the Netty client.

[0066] This embodiment leverages the native Netty framework to reduce abstraction overhead, combines AsyncHttpClient for non-blocking forwarding to effectively improve throughput, and supports millisecond-level hot updates through dynamic routing configuration without requiring a gateway restart. Furthermore, this embodiment can be integrated with pluggable filter chains to reduce development complexity and supports dynamic filter expansion. Its end-to-end asynchronous design maximizes CPU resource utilization, reduces request latency, and adapts to high-concurrency scenarios.

[0067] Based on the first embodiment of this application, in the second embodiment of this application, the same or similar content as the first embodiment described above can be referred to the above description, and will not be repeated hereafter.

[0068] Based on the first embodiment, please refer to Figure 4 , Figure 4 This is a flowchart illustrating the second embodiment of the API gateway request processing method of this application. In this embodiment, steps B1 to B2 may be included after step S10: Step B1: Obtain the real-time processing capability metrics corresponding to the Netty client; It should be understood that the aforementioned real-time processing capability metrics can be quantitative indicators reflecting the current load status of the gateway device corresponding to the Netty client, used to assess whether the gateway has the ability to process requests in real time. In this embodiment, real-time processing capability metrics may include: computing resource metrics (such as CPU (Central Processing Unit) utilization and memory utilization); thread resource metrics (such as the number of idle / active threads in the Netty Worker thread pool); request processing metrics (such as the number of currently active requests and the average processing latency over the past minute); and downstream service metrics (such as the average response latency of downstream services and the number of available instances).

[0069] Step B2: If the request type corresponding to the network request or the real-time processing capability indicator meets the preset buffering conditions, the internal request object is encapsulated into a request message and stored in a buffer message queue; the consumption rate of the buffer message queue is dynamically adjusted based on the real-time processing capability indicator. It is easy to understand that the above request types can be classified according to business importance, including core business requests (such as payment and order submission) and non-core business requests (such as data query and log reporting). In this embodiment, core business requests (which can be identified by path prefixes, such as / pay / and / order / submit) can be directly configured to skip the buffer and perform subsequent route matching; if it is a non-core business request, it can be further determined by combining real-time processing capability indicators.

[0070] In this case, the aforementioned preset buffering conditions can be rules for triggering request buffering preset by the gateway based on the request type and real-time processing capability metrics. For example, the buffering condition corresponding to the real-time processing metrics could be: (CPU utilization > 70%) OR (number of active requests > 10000) OR (downstream service response latency > 500ms); or the buffering condition for the request type could be a non-core business request. In this case, the Netty server can trigger the buffering mode upon detecting that either the buffering condition corresponding to the real-time processing metrics or the buffering condition for the request type (i.e., whether it is a core business request) meets any of these conditions.

[0071] Once the Netty server confirms that buffering mode is enabled, request processing steps can be delayed. For details, please refer to... Figure 5 , Figure 5 This is a schematic diagram of the request processing process in the second embodiment of the API gateway request processing method of this application. Figure 5 As shown, the Netty server can directly process network requests and perform subsequent route matching when buffering mode is not enabled. However, when buffering mode is enabled, requests can be temporarily transferred to a buffer message queue to smooth out request processing pressure. This buffer message queue can be a distributed message queue used to temporarily store request messages. For example, in this embodiment, the buffer message queue can be set to RabbitMQ (RabbitMQ's message persistence and dead-letter queue ensure that messages are not lost or accumulated). The consumption rate can be the rate at which the gateway consumer thread retrieves and processes requests from the buffer message queue (requests / second). In this embodiment, the consumption rate of the buffer message queue can be dynamically adjusted according to real-time processing capabilities to avoid overload or queue accumulation.

[0072] In essence, after determining that the buffer has been triggered, the Netty server can serialize an internal request object containing complete request data and context information into a request message using Protobuf format. This request message can include the serialized request object, a sending timestamp, and a request priority identifier. The Netty server can then send the request message to a RabbitMQ buffer queue for later invocation.

[0073] Accordingly, in this embodiment, step S20 may include steps 21 to S22: Step 21: Obtain the request message from the buffer message queue and deserialize the request message to obtain the internal request object; Step 22: Perform route matching on the internal request object based on the dynamic routing configuration information to determine the target downstream service.

[0074] It is easy to understand that when the Netty server needs to reprocess the internal request object, it can use an asynchronous processing thread to restore the Protobuf format request message obtained from the buffer message queue into an EnhancedHttpRequest object, that is, to perform the above deserialization, and then perform subsequent route matching operations.

[0075] During this process, the Netty server can start multiple consumer threads (the number of which is consistent with the number of CPU cores by default) to form a consumer group and listen to the RabbitMQ buffer queue. Simultaneously, the consumption rate of the consumer threads can be dynamically adjusted based on real-time processing capacity metrics: for example, under low load (CPU utilization < 30%, active requests < 5000), the consumption rate can be increased, fetching 10 messages every 10ms for batch processing; under medium load (CPU utilization 30%-60%, active requests 5000-8000), a normal efficiency rate can be set, fetching 5 messages every 20ms; under high load (CPU utilization > 60%, active requests > 8000), the consumption rate can be decreased, fetching 1 message every 50ms.

[0076] Then, the consumer thread can pull request messages at the adjusted rate and verify message integrity (whether the Protobuf format is valid). If the message is incomplete, it is transferred to the dead letter queue and logged; if it is complete, it is deserialized into an EnhancedHttpRequest object, which is the aforementioned internal request object.

[0077] In this embodiment, a buffered message queue can be used as a distributed buffer layer, and the queue consumption rate can be dynamically adjusted to smooth out peaks and valleys, improving the gateway's resilience. Furthermore, during the buffering decision-making process, core business requests are prioritized to ensure the availability of core services. In addition, this embodiment can reduce message size and transmission overhead through Protobuf serialization, ensuring that the buffering mechanism does not affect the efficiency of normal request processing.

[0078] In another feasible implementation, in this embodiment, step S20 or step S22 includes steps C1 to C3: Step C1: Extract the path information from the internal request object; Step C2: Construct a parameterized tree structure based on the dynamic routing configuration information; Step C3: Match the path information with the parameterized tree structure at each level, and determine the target downstream service based on the successfully matched nodes.

[0079] It's easy to understand that the aforementioned path information can be extracted from the internal request object, representing a standardized array of request path fragments that characterize the path portion of the HTTP request line (e.g., " / user / 123" can be converted to ["user", "123"]), which is the core basis for subsequent route matching. The aforementioned dynamic route configuration information can be a set of configurations formed by incremental synchronization and standardization of local memory snapshots, including route path templates, node structures, and matching rules.

[0080] At this point, the aforementioned parameterized tree structure can be a routing path index structure built on a Trie tree (prefix tree) using the SmartPathMatcher algorithm. This structure stores path templates from dynamic routing configuration information and supports efficient matching of static paths, wildcard paths, and parameterized paths. Each node in this parameterized tree structure can contain attributes such as path fragments, child node references, routing rule IDs, and target service information, making it the core data structure of the SmartPathMatcher algorithm.

[0081] For example, the Netty server can load dynamic routing configuration information, traverse all route path templates (such as / user / {id}, / order / *, / pay / submit), and then construct a Trie tree according to the fragments of the path templates, including node types and construction rules. Static character nodes can store fixed character fragments (such as user, order), including fragment characters, a child node mapping table, and a terminal node identifier (default false); parameter capture nodes can store parameterized fragments (such as {id}), including parameter names, pre-compiled regular expressions, a child node mapping table, and a terminal node identifier (default false); wildcard nodes can store wildcard fragments (*), including wildcard identifiers, a child node mapping table, and a terminal node identifier (default true). Finally, after traversing each path template, the corresponding route rule ID and target service information can be associated with the terminal node, and the terminal node identifier can be set to true, forming a complete parameterized tree structure.

[0082] It is important to understand that the above-mentioned step-by-step node matching process can refer to starting from the root node of the parameterized tree structure, traversing the child nodes sequentially according to the fragments of path information (such as " / user / 123" → ["user", "123"]), and determining whether each fragment matches the node. The matching order is "static character nodes first → parameter capturing nodes → wildcard nodes".

[0083] Therefore, in one feasible implementation, the nodes of the parameterized tree structure include static character nodes and parameter capturing nodes; in this embodiment, step C3 may include steps C31 to C33: Step C31: Perform node traversal matching between the path information and the static character nodes to obtain matching character nodes; Step C32: At the parameter capture node corresponding to the matching character node, the path information is validated using a pre-compiled regular expression; Step C33: The parameter capture node that passes the parameter verification is taken as the successfully matched node, and the target downstream service is determined based on the successfully matched node.

[0084] Understandably, the aforementioned static character nodes can be nodes in a parameterized tree structure that store fixed character path fragments (such as user, order). In this case, the Netty server can traverse the static character nodes of the parameterized tree structure sequentially according to the path fragment array in the path information, search for nodes that completely match the fragments, and use the completely matching static character nodes as the aforementioned matching character nodes.

[0085] For example, after the Netty server extracts the path information and splits it into a fragment array (such as / user / 123 → ["user", "123"]), it can traverse the static fragments in the path fragment array (such as the first fragment "user"). Starting from the root node of the parameterized tree structure, it searches for a static character node (such as the "user" node) in the child node mapping table that completely matches the fragment. If a match is found, the matching pointer is pointed to the static character node (the matching character node), and the counter of the matched fragment is incremented by 1 to continue processing the next dynamic fragment (123). If no match is found, the route matching fails, and a 404 response is returned without needing to enter the parameter validation step.

[0086] The aforementioned parameter capturing nodes can be nodes in a parameterized tree structure that store parameterized path fragments (such as {id}, {orderId}), used to capture dynamic parameters (such as 123, abc123) in the path. In this embodiment, the parameter capturing nodes can also validate the validity of the parameter format using pre-compiled regular expressions, supporting dynamic path scenarios. These pre-compiled regular expressions are pre-compiled by the Netty server for each parameter capturing node's parameter type (such as number, date) (e.g., expression 1 for numbers, expression 2 for dates), avoiding repeated compilation during matching and improving validation efficiency. Finally, the Netty server can extract target downstream services based on nodes that pass parameter validation.

[0087] For example, after the matching pointer points to the matching character node (user node), it can further search the child node mapping table of the node to determine whether there is a parameter capturing node (such as the {id} node): if there is no parameter capturing node, it can further search whether there is a corresponding wildcard node to determine whether there is a matching route; if there is a parameter capturing node, it can extract the pre-compiled regular expression of the parameter capturing node (such as expression 1, indicating that the parameter must be a number), and extract the dynamic fragment (such as 123) in the current path fragment array as the parameter to be verified, and then call the regular expression to perform full matching verification, that is, parameter verification.

[0088] If the parameter validation passes (e.g., 123 matches expression 1), the parameter name (id) and parameter value (123) can be temporarily stored, and the parameter can be added to the request parameter collection of the EnhancedHttpRequest object for use by downstream services. If parameter validation fails (e.g., the fragment is "abc", which does not match expression 1), a 400 response will be returned with the message "Parameter id format is incorrect, it must be a number", and a validation failure log containing the request path, parameter value, and validation rules will be recorded.

[0089] In addition, after identifying the target downstream service, the Netty server can append the temporarily stored dynamic parameters to the request header or parameters of the processed request, and then asynchronously forward them to the target downstream service.

[0090] In this implementation, illegal parameters are directly intercepted at the gateway layer by "static node matching + parameter capture node regular expression verification", thereby effectively reducing the number of abnormal requests to downstream services; at the same time, pre-compiled regular expressions are used to avoid repeated compilation and improve verification efficiency.

[0091] Furthermore, this embodiment constructs a parameterized tree structure based on a Trie tree, with a route matching time complexity of only O(k) (where k is the path segment length). It is not affected by the number of routing rules and maintains millisecond-level matching even if there are more than 10,000 rules, thereby improving routing efficiency and further optimizing performance.

[0092] This embodiment discloses the acquisition of real-time processing capability metrics corresponding to the Netty client. When the request type or real-time processing capability metric corresponding to the network request meets preset buffering conditions, the internal request object is encapsulated into a request message and stored in a buffer message queue. The consumption rate of the buffer message queue is dynamically adjusted based on the real-time processing capability metric. The request message is retrieved from the buffer message queue and deserialized to obtain the internal request object. Path information is extracted from the internal request object. A parameterized tree structure is constructed based on dynamic routing configuration information. Node traversal matching is performed between the path information and static character nodes to obtain matching character nodes. At the parameter capture node corresponding to the matching character node, parameter validation of the path information is performed using pre-compiled regular expressions. The parameter capture node that passes parameter validation is taken as the successfully matched node, and the target downstream service is determined based on the successfully matched node.

[0093] Therefore, this embodiment employs a buffered message queue, combined with an adaptive queue consumption rate to balance system throughput and latency. Simultaneously, this embodiment uses a parameterized tree structure built based on dynamic routing configuration information for path matching, improving routing efficiency and maintainability, solving the problem of low routing matching efficiency in existing gateway systems, and enhancing system flexibility and operational efficiency.

[0094] For example, to help understand the technical concept or principle of the API gateway request processing method after combining this embodiment with the above-described Embodiments 1 and 2, please refer to Figure 6 , Figure 6A simplified flowchart of an API gateway request processing method is provided below: like Figure 6 As shown, the data processing flow of the API gateway system proposed in this application based on the native Netty architecture may include the following steps: 1) System startup initialization: First, load the latest dynamic routing configuration information and the routing rules contained in the dynamic routing configuration information when the system starts up. At the same time, initialize the Netty server and Netty client in the API gateway system. 2) Receive network requests and convert them into internal request objects: When the Netty server starts, it can initialize the NioEventLoopGroup thread group (the Boss thread is responsible for port listening, and the Worker thread handles I / O events), and register HttpServerCodec (HTTP decoding processor), HttpObjectAggregator (request aggregation processor), and custom validity validation processor, while binding the Netty client's port.

[0095] At this point, in the request receiving thread of the Netty server, when a network request sent by the Netty client arrives at the server, the Netty server can verify the received request, that is... Figure 6 The verification request in the request can then be handled by the HttpServerCodec function in the Netty server, which decodes the byte stream of the network request into HTTP protocol fragments (HttpMessage, HttpContent). The HttpObjectAggregator function in the Netty server then aggregates the fragmented data into a complete FullHttpRequest object.

[0096] In addition, the custom validity checker in the Netty server can verify the HTTP protocol version of the network request (supports HTTP / 1.1 and HTTP / 2) and the request format (whether the request line and request header are complete), and discard illegal requests directly and record them in the audit log; for legitimate requests, the request can be encapsulated by combining Netty context information (channel ID, receiving timestamp) to form an EnhancedHttpRequest object, which is the aforementioned internal request object.

[0097] Afterwards, the Netty server can send the internal request object to the asynchronous request processing thread in the form of a buffered message queue.

[0098] 3) Perform route matching based on dynamic routing configuration information to determine the target downstream service: The Netty server can load pre-generated dynamic routing configuration information, extract standardized path information from the internal request object (i.e., the EnhancedHttpRequest object mentioned above), and obtain an array of path fragments. Then, it uses the SmartPathMatcher algorithm (a fusion of Trie tree and regular expressions) to perform route matching, and traverses the path fragment array level by level through the pre-compiled Trie tree structure, extracting the target downstream service address based on the matching results.

[0099] 4) Process the internal request object through a real-time filter chain to obtain the processed request: In the request processing thread, the Netty server can load filter instances (such as authentication filters and rate limiting filters) associated with the route from the pluggable filter repository based on the route matching results. The filter ID is specified by the dynamic route configuration information. Then, a real-time filter chain is built in a preset order and executed using the chain of responsibility pattern. All target filters in the real-time filter chain (i.e., ...) Figure 6 After the routing filter in the Netty class executes without exception, it receives the processed request and triggers an asynchronous downstream service thread; if any filter fails to validate, it directly generates an error response and returns it to the Netty client.

[0100] 5) Asynchronously forward the processed request to the target downstream service and receive the response data: When the Netty server starts, it initializes an asynchronous request sending object, AsyncHttpClient, which implements non-blocking I / O based on Netty NIO. Therefore, the Netty server can use AsyncHttpClient to asynchronously send processed requests to the target downstream service.

[0101] Meanwhile, the Netty server can register a CompleteFuture callback interface in the downstream service thread, which can deserialize the response body to obtain the response data when successfully receiving the downstream response; or generate error response data when the request times out or the connection fails.

[0102] 6) Return the response data to the Netty client: Finally, the Netty server can standardize the response data (i.e., the deserialized response data or the generated error response data mentioned above) and write the response data back to the Netty client through the Netty server's channel (which is the same as the channel used to receive the request), thus completing the entire request-response data processing flow.

[0103] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the API gateway request processing method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0104] This application also provides an API gateway request processing device, please refer to... Figure 7 , Figure 7 This is a schematic diagram of the module structure of the API gateway request processing device according to an embodiment of this application. In this embodiment, the API gateway request processing device is applied to an API gateway system that includes a Netty server and a Netty client. The API gateway request processing device is located in the Netty server, and the device includes: Request processing module 701 is used to receive network requests sent by Netty clients and convert the network requests into internal request objects; The route matching module 702 is used to perform route matching on the internal request object based on dynamic route configuration information to determine the target downstream service; The request filtering module 703 is used to process the internal request object through a real-time filter chain to obtain the processed request; The request forwarding module 704 is used to asynchronously forward the processed request to the target downstream service and receive the response data returned by the target downstream service; The data interaction module 705 is used to return the response data to the Netty client.

[0105] In one possible implementation, in this embodiment, the route matching module 702 is further configured to read route configuration data from the distributed coordination service and generate a configuration snapshot version in local memory based on the route configuration data; register a configuration change listener, and when the configuration change listener detects a configuration change event in the distributed coordination service, synchronize the incremental data corresponding to the configuration change event to the local memory to update the configuration snapshot version; and generate dynamic route configuration information based on the updated configuration snapshot version.

[0106] As one possible implementation, in this embodiment, the request processing module 701 is further configured to obtain the real-time processing capability index corresponding to the Netty client; when the request type corresponding to the network request or the real-time processing capability index meets the preset buffering conditions, the internal request object is encapsulated into a request message and stored in a buffer message queue; the consumption rate of the buffer message queue is dynamically adjusted based on the real-time processing capability index. The routing matching module 702 is further configured to obtain the request message from the buffer message queue, deserialize the request message to obtain the internal request object, and perform routing matching on the internal request object based on dynamic routing configuration information to determine the target downstream service.

[0107] As one possible implementation, in this embodiment, the route matching module 702 is further configured to extract path information from the internal request object; construct a parameterized tree structure based on the dynamic route configuration information; perform step-by-step node matching between the path information and the parameterized tree structure; and determine the target downstream service based on the successfully matched nodes.

[0108] As one possible implementation, the nodes of the parameterized tree structure include static character nodes and parameter capturing nodes. In this embodiment, the route matching module 702 is further configured to: perform node traversal matching with the static character nodes based on the path information to obtain matching character nodes; at the parameter capturing node corresponding to the matching character node, perform parameter validation on the path information using a pre-compiled regular expression; take the parameter capturing node that passes the parameter validation as a successfully matched node, and determine the target downstream service based on the successfully matched node.

[0109] As one possible implementation, in this embodiment, the request filtering module 703 is further configured to load filter instances corresponding to the route matching results from the pluggable filter repository; assemble the filter instances into a real-time filter chain in a preset order; and process the internal request objects one by one through each filter instance in the real-time filter chain to obtain the processed request.

[0110] As one possible implementation, in this embodiment, the request forwarding module 704 is further configured to initialize an asynchronous request sending object, and send the processed request to the target downstream service through the asynchronous request sending object; register a callback interface, and receive the response data returned by the target downstream service through the callback interface.

[0111] The API gateway request processing apparatus provided in this application, employing the API gateway request processing method in the above embodiments, can solve the technical problem of how to improve the data processing capabilities of API gateways. Compared with the prior art, the beneficial effects of the API gateway request processing apparatus provided in this application are the same as those of the API gateway request processing method provided in the above embodiments, and other technical features in the API gateway request processing apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0112] This application provides an API gateway system, which includes a Netty server and a Netty client. The Netty server is used to execute the steps of the API gateway request processing method in the above embodiments.

[0113] It should be noted that in this embodiment, the API gateway system can be an integrated system consisting of a Netty server and a Netty client, deployed in a microservice architecture, serving as an intermediary layer between the client and downstream services, realizing unified request reception, routing, filtering, forwarding, and response writing.

[0114] The Netty server is the core processing unit of the gateway system. It can be deployed on a server cluster (physical server, virtual machine, or K8s (Kubernetes) container) and can execute the API gateway request processing method in the above embodiments, and is responsible for the entire process of request processing.

[0115] The Netty client is the request initiation unit of the gateway system. It can be deployed on terminal devices (mobile phones, computers) or other service nodes. It establishes a long TCP connection with the Netty server to transmit network requests and receive response data, supporting high-concurrency connections and automatic reconnection.

[0116] The API gateway system provided in this application addresses the technical problem of improving the data processing capabilities of API gateways. Compared to existing technologies, the beneficial effects of the API gateway system provided in this application are the same as those of the API gateway request processing method provided in the above embodiments, and will not be repeated here.

[0117] This application provides a storage medium having computer-readable program instructions (i.e., an API gateway request handler) stored thereon, which are used to execute the API gateway request handling method in the above embodiments.

[0118] The storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of the storage medium may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0119] The aforementioned storage medium may be included in the API gateway system; or it may exist independently and not be installed in the API gateway system.

[0120] The aforementioned storage medium carries one or more programs. When these programs are executed by the API gateway system, the API gateway system can effectively improve its data processing capabilities.

[0121] API gateway request handler code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—as well as conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0122] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and API gateway request handler products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0123] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0124] The readable storage medium provided in this application is a storage medium that stores computer-readable program instructions (i.e., API gateway request handlers) for executing the above-described API gateway request processing method, thereby solving the technical problem of how to improve the data processing capabilities of API gateways. Compared with the prior art, the beneficial effects of the storage medium provided in this application are the same as those of the API gateway request processing method provided in the above embodiments, and will not be repeated here.

[0125] The above are only some embodiments of this application and do not limit the scope of the solution of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

Claims

1. An API gateway request processing method, characterized in that, The method is applied to an API gateway system that includes a Netty server and a Netty client. The method is executed by the Netty server and includes: Receive network requests sent by the Netty client and convert the network requests into internal request objects; Based on dynamic routing configuration information, the internal request object is routed to determine the target downstream service; The internal request object is processed by a real-time filter chain to obtain the processed request; The processed request is asynchronously forwarded to the target downstream service, and the response data returned by the target downstream service is received. The response data is returned to the Netty client.

2. The API gateway request processing method as described in claim 1, characterized in that, Before determining the target downstream service by performing route matching on the internal request object based on dynamic routing configuration information, the method further includes: Read routing configuration data from the distributed coordination service, and generate a configuration snapshot version in local memory based on the routing configuration data; Register a configuration change listener, and when the configuration change listener detects a configuration change event in the distributed coordination service, synchronize the incremental data corresponding to the configuration change event to the local memory to update the configuration snapshot version; Dynamic routing configuration information is generated based on the updated configuration snapshot version.

3. The API gateway request processing method as described in claim 1, characterized in that, After receiving the network request sent by the Netty client and converting the network request into an internal request object, the process further includes: Obtain the real-time processing capability metrics corresponding to the Netty client; If the request type corresponding to the network request or the real-time processing capability indicator meets the preset buffering conditions, the internal request object is encapsulated into a request message and stored in a buffer message queue; the consumption rate of the buffer message queue is dynamically adjusted based on the real-time processing capability indicator. The step of performing route matching on the internal request object based on dynamic routing configuration information to determine the target downstream service includes: The request message is retrieved from the buffer message queue and deserialized to obtain the internal request object. Based on dynamic routing configuration information, the internal request object is routed and matched to determine the target downstream service.

4. The API gateway request processing method as described in any one of claims 1 or 3, characterized in that, The step of performing route matching on the internal request object based on the dynamic routing configuration information to determine the target downstream service includes: Extract the path information from the internal request object; A parameterized tree structure is constructed based on the dynamic routing configuration information; The path information is matched with the parameterized tree structure at each level, and the target downstream service is determined based on the successfully matched nodes.

5. The API gateway request processing method as described in claim 4, characterized in that, The nodes of the parameterized tree structure include static character nodes and parameter capture nodes; The step of matching nodes level by level with the path information and the parameterized tree structure, and determining the target downstream service based on the successfully matched nodes, includes: Based on the path information, perform node traversal matching with the static character nodes to obtain the matching character nodes; At the parameter capture node corresponding to the matching character node, the path information is validated using a pre-compiled regular expression; The parameter capture node that passes the parameter verification is taken as the successfully matched node, and the target downstream service is determined based on the successfully matched node.

6. The API gateway request processing method as described in claim 1, characterized in that, The step of processing the internal request object through a real-time filter chain to obtain the processed request includes: Load the target filter instance corresponding to the route matching result from the pluggable filter repository; The target filter instances are assembled into a real-time filter chain in a preset order; The internal request object is processed one by one by each filter instance in the real-time filter chain to obtain the processed request.

7. The API gateway request processing method as described in claim 1, characterized in that, The step of asynchronously forwarding the processed request to the target downstream service and receiving the response data returned by the target downstream service includes: Initialize an asynchronous request sending object, and send the processed request to the target downstream service through the asynchronous request sending object; Register a callback interface and receive response data returned by the target downstream service through the callback interface.

8. An API gateway request processing device, characterized in that, The device is applied to an API gateway system that includes a Netty server and a Netty client. The device is installed in the Netty server and includes: The request processing module is used to receive network requests sent by the Netty client and convert the network requests into internal request objects; The route matching module is used to perform route matching on the internal request object based on dynamic route configuration information to determine the target downstream service. The request filtering module is used to process the internal request objects through a real-time filter chain to obtain the processed requests; The request forwarding module is used to asynchronously forward the processed request to the target downstream service and receive the response data returned by the target downstream service; The data interaction module is used to return the response data to the Netty client.

9. An API gateway system, characterized in that, The API gateway system includes: a Netty server and a Netty client; The Netty server is used to execute the steps of the API gateway request processing method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores an API gateway request handler, which, when executed by a processor, implements the steps of the API gateway request handling method as described in any one of claims 1 to 7.

Images