A cloud-native gateway aggregation service method and device based on a dynamic configuration and plugin architecture, and a medium

Abstract

This invention belongs to the field of cloud computing and microservices technology, specifically relating to a method, device, and medium for cloud-native gateway aggregation services based on dynamic configuration and a plug-in architecture. The method includes: reading configuration files, parsing global filters and routing rules, constructing routing tables and filter configuration objects; loading plug-in modules, registering plug-in names and classes to the global plug-in registry; searching for classes in the registry and instantiating filters and processors to generate a routing table; registering routes to the server and starting listening; matching requests to the routing table, sequentially executing global and route-level pre-processing, reversing post-processing, and returning a response; storing user and quota information in the route-level filter chain via remote caching, counting usage with atomic operations, and asynchronously pushing batch cached logs. This invention achieves hot-swapping and dynamic assembly of filters and processors, facilitating maintenance, ensuring data consistency, and improving gateway scalability.

Description

Technical Field

[0001] This invention belongs to the field of cloud computing and microservice technology, specifically relating to a cloud-native gateway aggregation service method, device, and medium based on dynamic configuration and plug-in architecture. Background Technology

[0002] As a key component of microservice architecture and cloud-native technology stack, cloud-native gateways have become a critical layer of infrastructure as enterprises undergo digital transformation.

[0003] Regarding gateway plugin extensions, gateways typically require developers to place custom filter code directly into the project source code directory and compile and package it together with the main gateway code. This practice results in the main code and business plugin code being mixed together. When multiple teams are developing different plugins simultaneously, code merge conflicts occur frequently, and testing and release cycles are forced to lengthen.

[0004] During gateway request processing, the execution order of global filters and business routing filters is often hard-coded in the program. If the position of a filter in the chain needs to be adjusted, developers need to modify the code and redeploy. This approach makes it difficult for gateways to adapt to the differentiated requirements of filters in different business scenarios. Summary of the Invention

[0005] This invention provides a cloud-native gateway aggregation service method based on dynamic configuration and a plug-in architecture. The method requires no modification to the main program and implements configuration-driven and plug-in-based hot-scaling of gateway functions. The chain-of-responsibility pattern combined with a short-circuit mechanism improves processing controllability; multi-level caching and asynchronous push reduce backend call pressure and improve concurrency performance.

[0006] The method includes the following steps: S1: Read the configuration file, parse the global filter configuration and HTTP routing rule configuration, and build the routing table and filter chain configuration objects; S2: Scan the specified plugin directory, load the plugin modules, and register the plugin name and plugin class to the global plugin registry; S3: Create an aggregator instance based on the configuration object, find the corresponding class from the global plugin registry based on the plugin name, generate filter instances and processor instances by creating instances at runtime, inject the configuration parameters, build the global filter chain, route-level filter chain and processor respectively, and generate the routing table; S4: Register the routes in the routing table with the HTTP server and start the server to listen for client requests; S5: When a client HTTP request is received, the routing table generated based on the URL path and HTTP method is used; If a match is found, the request and response objects are encapsulated, and the preprocessing of the constructed global filter chain and route-level filter chain is executed in sequence. If all preprocessing passes, the processor that executes the build will request to be proxied to the backend service; The post-processing of the route-level filter chain and the global filter chain is executed in reverse order, and finally the response is returned to the client.

[0007] According to another embodiment of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture.

[0008] According to another embodiment of this application, a storage medium is also provided, on which a computer program is stored, wherein when the computer program is executed by a processor, the steps of a cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture are implemented.

[0009] As can be seen from the above technical solutions, the present invention has the following advantages: This invention declares gateway behavior entirely in a separate configuration file, defining routing rules and filter order in text form. Plugin modules are dynamically loaded by scanning specified directories, and plugin names and classes are registered in the global registry. This allows adding or replacing plugins to simply place the file in the directory without modifying the gateway's core code. The corresponding class is retrieved from the registry based on the plugin name in the configuration, an instance is created using runtime reflection, parameters are injected, and the classes are assembled into a global filter chain and a route-level filter chain according to the configuration order. A chain-of-responsibility pattern is used to execute the pre-processors of the global and route-level filters sequentially. If any filter modifies the status code or response body of the response object, a short circuit is triggered, and subsequent filters and handlers are skipped, directly returning an error response. Post-processors are called in reverse order of the pre-processors, ensuring that paired operations are correctly matched.

[0010] The user information filter and quota information filter of this invention prioritize reading the remote cache server; if a match is found, calls to the backend authentication and quota services are skipped. The usage counter uses the atomic increment instruction of the remote cache server, handling high concurrency without additional locking. Log data is first written to a local memory queue, and then asynchronously pushed to persistent storage in batches by an independent thread after accumulating a certain amount or after a predetermined time. This invention enables hot-swapping and dynamic assembly of filters and processors, reducing maintenance complexity and improving the gateway's scalability and processing performance. Attached Figure Description

[0011] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of the system architecture; Figure 2 A flowchart illustrating the cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture; Figure 3 Flowchart of an embodiment of a cloud-native gateway aggregation service method; Figure 4 Flowchart of another embodiment of the cloud-native gateway aggregation service method; Figure 5 This is a schematic diagram of an electronic device. Detailed Implementation

[0013] like Figure 1 As shown, a system architecture diagram is provided for implementing the cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture of the present invention.

[0014] The system includes: a client layer, a gateway entry layer, a core processing layer, a service aggregation layer, and a data persistence layer.

[0015] The client layer, acting as an external caller, sends an HTTP request to the gateway.

[0016] The gateway entry layer includes an HTTP server and a route matching module. The HTTP server has a listening port; the route matching module can match the route table based on the URL path and HTTP method, and returns a 404 if the match fails.

[0017] The core processing layer consists of four sub-modules: The configuration loading module is used to read YAML configuration files and parse them into Config objects.

[0018] The plugin registration module is used to scan the plugin directory, dynamically load plugin files, and register the plugin name and class to the global plugin registry.

[0019] The routing management module is used to create aggregator instances based on Config objects, find and instantiate classes from the plugin registry, build global filter chains, route-level filter chains and processors, and generate routing tables.

[0020] The filter chain execution module sequentially performs the pre-processing of the global filter chain and the route-level filter chain, the processor executes the proxy request, and then performs the post-processing in reverse order.

[0021] The service aggregation layer includes a processor and a cache management module. The processor proxies requests to backend services; the cache management module caches user information and quota information in Redis, counts usage through atomic operations, and batches logs in a memory buffer before asynchronously pushing them.

[0022] The data persistence layer includes the Gallery service, Elasticsearch, and Redis. Gallery stores user information, quota information, and usage data; Elasticsearch stores log data; and Redis serves as a first-level and second-level cache for storing user information and quota information.

[0023] Based on the architecture diagram, client requests enter through the HTTP server, are distributed to the core processing layer by the routing matching module, undergo pre-processing by the filter chain, request proxying by the processor, and post-processing by the filter chain. Finally, the cache management module reduces direct calls to the data persistence layer and returns the response to the client.

[0024] The cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture involved in this application will be described in detail below. Specific details such as particular system architectures and technologies are proposed for illustrative purposes and not for limitation, so as to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details.

[0025] Please see Figure 2 and Figure 3 The diagram shows a flowchart of a cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture in a specific embodiment. The method includes: S1: Read the configuration file, parse the global filter configuration and HTTP routing rule configuration, and build the routing table and filter chain configuration object.

[0026] In some embodiments, the configuration file is a YAML-formatted text file containing two top-level configuration items: global filter configuration (globalFilter) and HTTP routing rule configuration.

[0027] The global filter configuration, globalFilter, is an array. Each element contains the name of the filter, such as cost-filter, and the parameters required by the filter, such as {timeUnit:"ms"}.

[0028] Optionally, the global filter configuration specifies a filter class for each declaration, such as `cost-filter` and its runtime parameters. Global filters are not bound to specific routes but apply to all requests entering the gateway. Global filters provide common cross-cutting concerns across all routes, such as monitoring, auditing, security policies, and request shaping, avoiding redundant configuration in each route.

[0029] HTTP routing rule configuration is based on each element describing a routing rule, including: match.url: URL matching pattern, such as / api / v1 / *; match.method: HTTP method, such as GET, POST, or ANY; filterChain: A list of filters specific to this route, each filter also contains a name and parameters; processor: The name and parameters of the processor used by this route.

[0030] Optionally, HTTP routing rule configuration is a set of route declarations described by the `http` array in the configuration file. Each routing rule defines: Matching conditions for URL path patterns and HTTP methods; Dedicated filter chain; Final Processor. HTTP routing rule configuration maps different URL paths and methods to different processing flows, enabling request distribution and differentiated business logic.

[0031] In some embodiments, the filter chain configuration object is defined as a temporary data structure containing an intermediate representation of the global filter configuration list and the route-level filter configuration list. Each configuration item records the filter's name and key-value pairs. During execution of S3, this object is consumed and transformed into an array of actual filter instances.

[0032] S2: Scan the specified plugin directory, load the plugin modules, and register the plugin name and plugin class in the global plugin registry.

[0033] In some embodiments, the specified plugin directory is a set of file system paths preset in the configuration file or code, used to store plugin modules. Specifically, it may include: Built-in plugin directories: . / filters, . / processors; Extended plugin directories: . / extension / filters, . / extension / processors.

[0034] The goal here is to scan a specified directory, collect all .ts files, and dynamically import them one by one. The directory list determines the scope of plugin loading; only modules placed in these directories will be registered. Built-in directories ensure the availability of major plugins, while extension directories allow users to add or override plugins without modifying built-in files.

[0035] In some embodiments, the plugin name is a string identifier used in the configuration file to reference a specific filter or processor, such as "auth-apikey-filter", "quota-check-filter", or "proxy-processor". The name is registered to the global registry in the plugin module's register function by calling Map.set(name, classConstructor).

[0036] The plugin class is a TypeScript class that implements filters by providing the `handle` method; the processor class provides the `process` method. Classes are defined within modules and exposed via `export`.

[0037] Furthermore, the global plugin registry is based on the process where, when the `register` function is executed, the registry is passed to each plugin module, and the plugin module calls the `set` method to store its own name and class in it. After S2 execution, the registry contains the mapping relationship of all scanned plugins.

[0038] Thus, when the process in step S3 is executed, the plugin name parsed from the configuration is used to call the registry's `get` method to retrieve the corresponding constructor. If `get` returns `undefined`, it means the name is not registered, and the system throws an error and terminates the startup. The registry is the sole basis for dynamic instantiation in step S3.

[0039] As can be seen, the hierarchical loading and overriding method allows the plugin directory to contain both built-in and extended directories, with later-loaded extended plugins overriding built-in plugins. This solves the problem of providing out-of-the-box core plugins while also allowing users to customize and replace them.

[0040] In this embodiment, the registration filter class executed in step S2 is assembled into a chain of responsibility according to the configuration order after the process in step S3 is instantiated, and then executed sequentially or in reverse order in the process in step S5.

[0041] S3: Create an aggregator instance based on the configuration object, find the corresponding class from the global plugin registry based on the plugin name, generate filter instances and processor instances by creating instances at runtime, inject the configuration parameters, build the global filter chain, route-level filter chain and processor respectively, and generate the routing table.

[0042] S4: Register the routes in the routing table with the HTTP server and start the server to listen for client requests.

[0043] S5: Upon receiving a client's HTTP request, match the generated routing table based on the URL path and HTTP method. If a match is successful, encapsulate the request and response objects, and sequentially execute the pre-processing of the constructed global filter chain and route-level filter chain. If all pre-processing passes, execute the constructed processor to proxy the request to the backend service. Execute the post-processing of the route-level filter chain and global filter chain in reverse order, and finally return the response to the client.

[0044] Furthermore, during the pre-processing and / or post-processing of the S5 routing-level filter chain, user information, quota information, usage counts, and log data are stored in a cache. The user information and quota information are cached on a remote cache server, the usage count is performed concurrently and safely through atomic operations, and the log data is batch cached and then asynchronously pushed to persistent storage.

[0045] As can be seen, after the system starts, it reads the YAML configuration file, parses the global filter configuration and HTTP routing rule configuration, and builds the routing table and filter chain configuration objects.

[0046] The system scans the specified plugin directory, loads each plugin module via dynamic import, and registers the plugin name and class in the global plugin registry. An aggregator instance is created based on the configuration object. The system then searches the global plugin registry for the corresponding class based on the plugin name and generates filter and processor instances at runtime, injecting configuration parameters. This constructs a global filter chain, a route-level filter chain, and processors, generating a routing table. Finally, each route in the routing table is registered with an HTTP server, and the server is started to listen for client requests.

[0047] When a client HTTP request is received, the routing table is matched based on the URL path and HTTP method. If a match is found, the request and response objects are encapsulated, and the pre-processing of the global filter chain and the route-level filter chain is executed sequentially. If all pre-processing passes, the handler proxies the request to the backend service. The post-processing of the route-level filter chain and the global filter chain is executed in reverse order, and finally, the response is returned to the client. During the execution of the above filters, a multi-level caching strategy is used to store user information, quota information, usage counts, and log data. User information and quota information are cached on a remote caching server, usage counts are performed concurrently and safely using atomic operations, and log data is batch cached and then asynchronously pushed to persistent storage.

[0048] In this way, by configuring drivers and using a plug-in architecture, the gateway functionality can be dynamically assembled and hot-scaled. Filters or processors can be added or removed without modifying the main program code, reducing development and maintenance costs. A chain-of-responsibility pattern is used to connect global filters and route-level filters, supporting both pre- and post-processing stages, and short-circuiting is introduced to improve the controllability of request processing. Furthermore, multi-level caching strategies reduce repeated calls to backend services, atomic operations ensure counting safety under high concurrency, and batch asynchronous pushes reduce network I / O pressure, improving system throughput and response speed. This makes the method suitable for the high-performance and scalable requirements of microservice gateway scenarios.

[0049] In one embodiment of the present invention, such as Figure 4 As shown, based on step S1, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0050] S11: Read the operating system environment variable RUNTIME_SERVER_PORT. If the variable is not defined, assign the default value 8080 as the server port number.

[0051] S12: Locate and open the YAML-formatted configuration file aggregator.yaml based on the preset configuration file path string.

[0052] S13: Call the YAML parsing library to parse the text content of the file and generate a Config data structure object containing global filter configuration fields and HTTP routing rule configuration fields.

[0053] S14: Based on the listening address and port number fields in the Config object, call the HTTP server constructor to create a server instance and bind the instance to the specified address and port.

[0054] S15: Call the configuration loading method of the server instance, passing in the Config object; the method iterates through the routing rule array and global filter array in the Config object, fills the routing table data structure item by item and assembles the filter chain configuration object.

[0055] In some embodiments, the `loadConfig` method of the server instance created in step S14 is called, with the `Config` object generated in step S13 passed as the only parameter. Internally, the method iterates through the `Config.http` array, creates a `Route` object for each routing rule, sets its `match.url` and `match.method` properties, and searches for the corresponding filter and processor classes in the global plugin registry. After instantiation, these are attached to the `filterChain` and `processor` properties of the `Route` object. Simultaneously, the method iterates through the `Config.globalFilter` array, creates global filter instances, and stores them in the global filter chain array. Finally, all `Route` objects are stored in a routing table `Map` structure, using the URL pattern as the key.

[0056] This approach assembles all routes and filters at once, requiring only table lookups during subsequent request processing, thus reducing decision-making latency along the request path. It also decouples configuration from execution logic, meaning changes to the configuration only require a restart to take effect.

[0057] In one embodiment of the present invention, after configuration loading and parsing are completed, in order to associate the filter names and processor names declared in the configuration file with the actual plugin code, the system executes a dynamic plugin loading and registration process. This process is independent of configuration parsing, and by scanning preset directories, dynamically importing modules, and registering name-class mappings, it provides an instantiable plugin class library for the aggregator initialization in step S3. Specifically, the dynamic plugin loading and registration in step S2 includes the following steps: S21: Read the preset plugin search path list, which includes the built-in plugin directory path and the extended plugin directory path; traverse each directory path in the preset plugin search path list, call the file system interface to open the corresponding directory, recursively read all file entries in the directory, filter the file paths whose file extensions match the preset plugin file extensions, and summarize them into a set of plugin file paths to be loaded.

[0058] S22: Iterate through the set of plugin file paths to be loaded, and call the runtime dynamic import interface for each plugin file path to load the corresponding file as a plugin module.

[0059] The runtime dynamic import interface parses the export declarations in the plugin file and extracts the export object set of the plugin module; it checks whether the export object set contains function exports with preset registered function names. If it exists, the plugin module is marked as a valid plugin module; if it does not exist, the plugin module is marked as an invalid plugin module and skipped.

[0060] S23: For each valid plugin module, call the function with the preset registration function name, passing in the plugin registration context object.

[0061] The plugin registration context object includes a plugin name registration interface and a plugin class registration interface; The effective plugin module calls the plugin name registration interface to pass in the plugin name string and calls the plugin class registration interface to pass in the plugin class reference within the preset registration function. Based on the plugin class reference passed when calling the plugin class registration interface, read the type metadata of the plugin class reference, identify the parent class or implementation interface of the plugin class reference, determine whether the plugin class reference belongs to the filter type or the processor type, and mark the plugin type tag.

[0062] S24: Create a global plugin registry, which includes a filter registration sub-table and a processor registration sub-table; The extracted plugin name string, plugin class reference, and plugin type tag are encapsulated into a plugin registration unit; Based on the plugin type tag, the plugin registration unit is stored in the filter registration sub-table or the processor registration sub-table; Both the filter registration sub-table and the processor registration sub-table adopt a key-value mapping structure, with the plugin name string as the key and the plugin class reference as the value; Check if the plugin name string already exists in the corresponding sub-table. If it already exists, output a plugin name conflict warning and overwrite the original plugin class reference. If it does not exist, write it directly.

[0063] S25: Traverse the filter registration sub-table and the processor registration sub-table in the global plugin registry, and count the number of registered filter plugins and processor plugins; Extract the plugin name string and plugin type tag for each registered plugin, and format them into a plugin loading list; Output the plugin loading list to the standard output stream for operations and maintenance personnel to confirm the plugin loading status; output the completed global plugin registry to the aggregator initialization module for step S3 to call.

[0064] As can be seen, the standard output stream writing method outputs text data to the process's standard output file descriptor. Operations personnel can obtain the plugin loading status by viewing the console output or redirecting the log file. The plugin loading manifest is formatted with fixed-width alignment, and the plugin name string and plugin type tag are aligned to improve readability. The global plugin registry reference is passed using object reference assignment, without copying registry data. The aggregator initialization module and the plugin loading module share the same registry object, ensuring consistency of plugin registration information.

[0065] Furthermore, following the dynamic plugin loading and registration process in steps S21 to S25, the system establishes a global plugin registry. This registry uses the plugin name as the key and the plugin class reference as the value, storing them in the filter registration sub-table and the processor registration sub-table, respectively. At this point, all available filter classes and processor classes have been loaded and registered.

[0066] However, at this point, the global plugin registry is merely a static class repository and has not yet been integrated with specific routing rules, filtering order, and configuration parameters. Related technologies such as Zuul hardcode the instantiation order and parameters of filters in the code, or use configuration files to declare them, but still require pre-importing the classes and restarting the service.

[0067] In order to achieve fully dynamic configuration and plug-in functionality, this embodiment combines the runtime configuration object obtained in step S1 with the global plug-in registry obtained in step S2.

[0068] Step S3 is to complete this combination. Specifically, it iterates through the global filter configuration unit and the route-level filter configuration unit in the configuration object, looks up the corresponding class reference in the registry by the plugin name, creates a plugin instance using runtime reflection, injects the configuration parameters into the instance, and finally assembles the global filter chain, the route-level filter chain and the processor in the order declared in the configuration file to generate a routing table that can be quickly retrieved in the request processing stage.

[0069] This embodiment is based on declarative configuration, followed by dynamic registration, and finally reflection instantiation and injection, completely decoupling the gateway's main code from the implementation of business plugins. When operations and maintenance personnel add or modify filters, they do not need to modify any core code; they only need to update the configuration file or replace files in the plugin directory.

[0070] Compared with related technologies that require modifying source code, recompiling, and restarting services, the embodiments of this application reduce expansion costs and maintenance risks. The specific implementation steps of aggregator initialization and route construction in step S3 are described in detail below.

[0071] S31: Receive the runtime configuration object output in step S1 and the global plugin registry output in step S2; read the server listening parameters in the runtime configuration object and create an aggregator instance; The aggregator instance holds a global filter chain container, a routing table container, and a plugin registry reference.

[0072] S32: Traverse the global filter chain configuration objects in the runtime configuration object, and for each global filter configuration unit, search for the filter class reference corresponding to the plugin name in the filter registration sub-table of the global plugin registry; call the runtime reflection interface to create a filter instance; Read the global configuration parameter field in the global filter configuration unit, parse the parameter key-value pairs, and call the parameter injection interface of the filter instance to write the configuration parameters; The filter instances are appended to the global filter chain container in the order they are configured.

[0073] S33: Traverse the routing table configuration objects in the runtime configuration object and create a route instance for each routing configuration unit; Read the URL path matching field and HTTP method matching field from the routing configuration unit and write them into the matching rule attribute of the routing instance; Create a separate route-level filter chain container and processor placeholder attributes for the route instance.

[0074] S34: Read the route-level filter chain configuration in the route configuration unit corresponding to the route instance created in step S33; For each route-level filter configuration unit, look up the filter class reference corresponding to the plugin name in the filter registration sub-table of the global plugin registry; Create a filter instance by calling the runtime reflection interface; Read the routing-level configuration parameter field in the routing-level filter configuration unit, parse the parameter key-value pairs, and call the parameter injection interface of the filter instance to write the configuration parameters; The filter instances are appended to the route-level filter chain container of the route instance in the configuration order.

[0075] S35: Read the processor configuration from the routing configuration unit corresponding to the routing instance created in step S33; Search the processor class reference corresponding to the processor plugin name in the processor registration sub-table of the global plugin registry; Create a processor instance by calling the runtime reflection interface; Read the processor configuration parameter field in the processor configuration, parse the parameter key-value pairs, and call the parameter injection interface of the processor instance to write the configuration parameters; Bind the processor instance to the processor placeholder attribute of the route instance.

[0076] S36: Store each route instance constructed in steps S33 to S35 into the routing table container of the aggregator instance; The routing table container supports fast retrieval using a composite key consisting of a URL path matching field and an HTTP method matching field; The completed aggregator instance is output to the route registration module for use in step S4.

[0077] As can be seen, in step S33, the route instance serves as the runtime carrier for a single route, encapsulating all the processing elements of that route. The matching rule attribute stores the combined conditions of the URL path matching field and the HTTP method matching field. In the subsequent route registration phase, the matching rules are compiled into executable route matching logic.

[0078] The wildcard expression in the URL path matching field retains its original string form during the configuration phase and is compiled into a matching pattern during the S36 route table assembly or S4 route registration phases, achieving phase separation between configuration semantics and execution semantics. The HTTP method matching field supports multiple method enumerations, allowing a single route to match multiple HTTP methods such as GET and POST, reducing redundant configuration. The route-level filter chain container attribute is private to the route instance and independent of the global filter chain container built in S32, ensuring that adding, deleting, or modifying filters on a single route does not affect the global filter chain or the filter chains of other routes. The processor placeholder attribute uses a delayed binding design; the process executing step S33 only initializes an empty reference, while the process executing step S35 binds to a specific processor instance, decoupling route instance creation from processor instantiation.

[0079] The construction logic of the route-level filter chain adopts the same instantiation and parameter injection pattern as the construction logic of the S32 global filter chain, but the operation target is the route-level filter chain container private to the route instance rather than the global filter chain container of the aggregator instance.

[0080] A filter class with the same plugin name can be instantiated multiple times in the global filter chain and the route-level filter chains of different routes. Each instance independently holds its own configuration parameters, enabling differentiated configuration of the same filter class in multiple scenarios.

[0081] Furthermore, the creation and parameter injection of processor instances adopt the same runtime reflection and parameter injection pattern as filter instances, but the query target is the processor registration sub-table instead of the filter registration sub-table. Processor instances are bound to the processor placeholder attribute of route instances, ensuring that a single route corresponds to a single processor. Upon successful request matching, the processor instance is directly located to execute the request proxy.

[0082] The processor configuration parameters include proxy-related parameters such as backend service address prefix, timeout, and number of retries. After parameter injection, the processor instance directly reads the parameters to construct the proxy request during the request processing phase without needing to query the configuration again.

[0083] The one-to-one binding relationship between processor instances and route instances is determined during the aggregator initialization phase. During the request processing phase, the processor instance is directly obtained through the route instance, avoiding the runtime processor lookup overhead.

[0084] Furthermore, step S36 encodes the URL path matching field and the HTTP method matching field into a single string key, enabling the key-value mapping structure to retrieve route instances simultaneously by path and method. The fixed convention of the concatenation format ensures the uniqueness of the composite key; the same URL path combined with different HTTP methods generates different composite keys, achieving independent storage of routes with multiple methods for the same path.

[0085] Key conflict detection is completed during the route table assembly phase. Multiple route configurations with the same URL path and the same HTTP method are exposed during the initialization phase, avoiding unpredictable route matching ambiguities at runtime.

[0086] The routing table container, as an attribute of the aggregator instance, coexists with the global filter chain container in the same entity. The unified output of the aggregator instance enables step S4 to receive a complete runtime data structure, including the global filter chain, routing table, and plugin registry references. The interface is concise and the data is complete.

[0087] Furthermore, after completing the S3 aggregator initialization and route construction, the system has generated a complete aggregator instance in memory, which contains a global filter chain container and a route table container.

[0088] However, at this point, these data structures only exist within the aggregator and are not yet associated with the HTTP server's request processing mechanism. Zuul typically registers routing rules and filter chains statically with the server at startup, and once registered, they cannot be dynamically modified. In this embodiment, the aggregator instance and the HTTP server registration process are independent of each other. If the configuration file changes subsequently, a new aggregator instance can be rebuilt and hot-swapped without restarting the server.

[0089] To enable rapid location of the corresponding filter chain and handler based on the URL path and HTTP method during request processing, the routing table in the aggregator instance is converted into a route handler closure that the HTTP server can recognize. Step S4 performs this conversion by iterating through each route instance in the aggregator instance, extracting its matching rules, creating a closure function that captures the global filter chain, route-level filter chain, and handler instance, and registering this closure in the HTTP server's route lookup tree. After registration, the server starts listening. When a request arrives, the server retrieves the corresponding closure based on the request's URL path and HTTP method and executes it, thus incorporating the filter chain and handler constructed in S3 into the actual request processing flow.

[0090] This separation design decouples the gateway's filter chain and processor from the specific network server. Operations personnel can change the behavior of the entire gateway by replacing the aggregator instance without modifying the server code, achieving separation of control logic and the transport layer. The specific implementation steps of route registration and server startup in step S4 are described in detail below.

[0091] S41: Receive the aggregator instance output from step S3; Read the routing table container from the aggregator instance; Iterate through each route instance in the route table container and extract the URL path matching field and HTTP method matching field from the matching rule attributes of the route instance.

[0092] S42: Create a route handler closure function for each route instance; The route processor closure function captures the global filter chain reference in the aggregator instance, the route-level filter chain reference in the route instance, and the processor instance reference in the route instance; Inside the route processor closure function, a filter chain instance is created, and the captured global filter chain reference, the route-level filter chain reference, and the processor instance reference are passed to the filter chain instance; The received native request object is encapsulated into a gateway request object, and the native response object is encapsulated into a gateway response object; the startup method of the filter chain instance is called, passing in the gateway request object and the gateway response object.

[0093] S43: Call the HTTP server's route registration interface, passing in the URL path matching field, the HTTP method matching field, and the route processor closure function; The HTTP server constructs a route lookup tree based on the URL path matching field and the HTTP method matching field, and binds the route processor closure function to the corresponding tree node; After the traversal is complete, the HTTP server's route lookup tree contains the route handler closure functions for all registered routes.

[0094] S44: Call the startup method of the HTTP server, passing in the server listening parameters from the aggregator instance; The HTTP server creates a network socket, binds a listening address and a listening port number, and begins listening for client HTTP requests; When a client HTTP request is received, the HTTP server parses the URL path and HTTP method in the request and retrieves a matching route handler closure function in the route lookup tree; If the search finds a match, the matching route handler closure function is invoked to process the request. If the search fails to find a match, a default unmatched response is returned.

[0095] Furthermore, after the route registration and server startup process from S41 to S44, the HTTP server has completed the construction of the route lookup tree and has begun listening for client requests.

[0096] At this point, each route node is bound to a route handler closure function, which captures the global filter chain reference in the aggregator instance, the route-level filter chain reference of the corresponding route instance, and the handler instance reference.

[0097] However, at this point, the HTTP server needs to find the corresponding closure based on the requested URL path and HTTP method. In step S5, when the HTTP server calls the closure, the closure internally performs route matching, request / response object encapsulation, pre-processing of global and route-level filters, backend proxying of the handler, and reverse execution of post-processing, ultimately returning the response.

[0098] In this embodiment, a network listening and routing framework is first established, and the process in step S5 handles the business logic. By coupling through closure-based context capture, the HTTP server does not need to concern itself with the complex filter chains and chain-of-responsibility patterns within the gateway; it only needs to call pre-registered closures.

[0099] The route registration, closure capture, and delayed execution methods in this embodiment improve the modularity and testability of the system. Furthermore, the aggregator instance can be dynamically replaced at runtime without modifying the processing flow of step S5, achieving effective isolation between the control plane and the data plane. The specific implementation steps of request processing and filter chain execution in step S5 are described in detail below.

[0100] S51: Receives client HTTP requests from the HTTP server started by S4; Parse the request line of the client's HTTP request and extract the request method string and request URL path string; Call the retrieval interface of the routing table container of the aggregator instance, passing in the request method string and the request URL path string; If the retrieval interface returns an empty value, a pre-defined unmatched response will be generated and returned. If the retrieval interface returns a route instance reference, proceed to step S52.

[0101] S52: Create a gateway request object instance, read the request method, request URL path, request header set, request query parameter set and request body data of the client HTTP request, and write them into the corresponding attribute fields of the gateway request object instance; Create a gateway response object instance, and initialize the status code attribute of the gateway response object instance to a preset default value, the response header set to an empty set, and the response body attribute to an empty value; Attach the gateway request object instance and the gateway response object instance to the current request context.

[0102] S53: Read the global filter chain container reference in the aggregator instance constructed in S3, and read the route-level filter chain container reference and processor instance reference in the route instance matched in S52; Create a filter chain instance, and pass the global filter chain container reference, the route-level filter chain container reference, the processor instance reference, the gateway request object instance, and the gateway response object instance to the filter chain instance; The global pre-startup method of the filter chain instance is invoked, and the pre-processing method of each global filter instance is invoked in the order of array index in the global filter chain container, passing in the gateway request object instance, the gateway response object instance, and a reference to the filter chain instance itself.

[0103] S54: After the preprocessing method of each global filter instance returns in S53, check whether the status code attribute of the gateway response object instance has been modified to a non-preset default value, or check whether the response body attribute of the gateway response object instance has been written with a non-empty value. If any detection condition is met, the execution of the global pre-start method is terminated, the pre-processing of the remaining global filter instances and all route-level filter instances is skipped, and the process proceeds directly to step S57. If all global pre-start methods have been executed without triggering a short circuit, then the route-level pre-start method of the filter chain instance is called. In the order of the array index in the route-level filter chain container, the pre-processing method of each route-level filter instance is called in turn, passing in the gateway request object instance, the gateway response object instance, and the filter chain instance itself reference. After the preprocessing method of each route-level filter instance returns, the same short-circuit detection as the global filter instance is performed.

[0104] S55: If all the routing-level pre-start methods of S54 have been executed without triggering a short circuit, then the processor execution method of the filter chain instance is called. Read the processor configuration parameters from the processor instance reference, and construct the target backend service address based on the target address prefix in the processor configuration parameters and the request URL path in the gateway request object instance; Construct a backend service request object based on the request method, request header set, and request body data in the gateway request object instance; Send the backend service request object to the target backend service address and receive the response data returned by the backend service; The status code, response header, and response body in the response data are parsed and written into the corresponding attribute fields of the gateway response object instance.

[0105] S56: Invoke the post-startup method of the filter chain instance; First, in reverse order of the array indices in the route-level filter chain container, call the post-processing method of each route-level filter instance in sequence, passing in the gateway request object instance, the gateway response object instance, and a reference to the filter chain instance itself; In reverse order of the array indices in the global filter chain container, the post-processing method of each global filter instance is called sequentially, passing in the gateway request object instance, the gateway response object instance, and a reference to the filter chain instance itself.

[0106] S57: Read the status code attribute, response header set, and response body attribute from the gateway response object instance; create a native response object and write the status code attribute, response header set, and response body attribute into the native response object; The native response object is returned to the HTTP server, which then sends it to the client via a connection socket.

[0107] As can be seen in step 5 above, the filter chain instance acts as the scheduling center for filter execution, holding all references required for execution and avoiding redundant lookups during filter execution. The current execution stage attribute records which stage it is currently in: global pre-processing, route-level pre-processing, processor execution, route-level post-processing, or global post-processing, preventing incorrect stage calls. The design of the continue execution method allows each filter to decide whether to call the next filter. After a filter completes its custom logic, it explicitly calls the continue execution method, returning control to the filter chain instance. The passing of the global filter chain container reference ensures that the filter chain instance does not copy the global filter instance but directly references the same set of global filter instances created in stage S32. Multiple concurrent requests share the same global filter instance, but each request has an independent filter chain instance.

[0108] Furthermore, the short-circuit detection in step S54 is determined by reading the state of the gateway response object instance. After the filter sets an error status code or writes an error response body during preprocessing, the filter chain instance detects a state change and triggers a short circuit. The setting of the short-circuit flag attribute allows subsequent steps to determine whether a short circuit has occurred simply by reading this flag. A direct jump after a short circuit skips all remaining processing steps, including route-level filter preprocessing, processor execution, and all post-processing, immediately proceeding to the response return in S57, reducing unnecessary computation.

[0109] Furthermore, in step S55, the processor instance, created and bound to the route instance in stage S35, allows the processor to directly call the bound processor instance without runtime lookup. The concatenation of the target address prefix and the request URL path allows the same route to proxy to different backend service paths, decoupling the gateway layer path from the backend service path.

[0110] Calls to the network request sending interface block the current thread until the backend service returns a response, or until the connection times out. The timeout period is specified by the processor configuration parameters. The response byte stream is parsed and read in segments according to the HTTP protocol format. The status line and response headers are read first, followed by the response body. The parsed data is written to the gateway response object instance instead of being directly returned to the client, allowing post-processing filters to modify the response content. The gateway response object instance already exists before the processor executes; the processor only modifies its attribute fields and does not create a new response object, maintaining the continuity of the response object reference. The response object reference held by the post-processing filter remains valid after the processor executes.

[0111] Furthermore, in step S56, the global filter preprocessing order is from index zero to the end, and the global filter postprocessing order is from the end to index zero. The preprocessing and postprocessing of the same global filter instance are executed around the processor to form a nested structure.

[0112] The preprocessing order of route-level filters is from index zero to the end, and the postprocessing order is from the end to index zero. Preprocessing and postprocessing of the same route-level filter instance form a nested structure around processor execution and global filter postprocessing. Postprocessing methods do not accept references to the filter chain instance itself as triggers for continued execution. No short-circuiting mechanism is designed in the postprocessing stage, and the return value of postprocessing methods is ignored. The filter chain instance executes all postprocessing in a fixed order before entering S57. The short-circuit flag attribute is not modified in the postprocessing stage; short-circuiting is only determined in the preprocessing stage of S54.

[0113] Furthermore, for S57, the conversion from gateway response object instance to native response object is the reverse process of S52 encapsulation, converting the unified response format within the system back to the native format of the HTTP server framework.

[0114] The write operation of the response header set copies any response headers that may have been modified by post-processing filters from the gateway response object instance to the native response object, ensuring that the response headers received by the client contain all fields added by post-processing. The write operation of the response body data passes the response body, which the processor retrieves from the backend service and may have been modified by post-processing filters, to the native response object. The return of the native response object decouples the request processing logic from the HTTP server's network sending logic, allowing the HTTP server to focus on network I / O. Connection socket reuse ensures that the response is returned through the same connection that received the request, maintaining the consistency of the HTTP connection's lifecycle and improving connection utilization.

[0115] Furthermore, during the execution of the route-level filter chain, in order to reduce repeated calls to the backend authentication service, quota service, database, and logging system, this embodiment integrates a multi-level caching method in the pre-processing logic or post-processing logic of specific filters. The specific implementation is as follows: S61: In the pre-processing, the get command of the remote cache server is called to query the user information object using the user identifier string as the key; If an empty value is returned, the authentication service interface is called to obtain the user information, and then the setex command of the remote cache server is called to store the user information object with the user identifier string as the key and set the time-to-live parameter.

[0116] S62: In the pre-processing, the get command of the remote cache server is called to query the quota information object using the quota identifier string as the key; If an empty value is returned, the quota service interface is called to obtain the quota information, and then the set command of the remote cache server is called to store the quota information object; at the same time, the quota change topic is subscribed to, and after receiving the change message, the del command of the remote cache server is called to delete the corresponding key.

[0117] S63: In the preprocessing, the incr command of the remote cache server is called to perform an atomic auto-increment operation with the usage count key string; The request identifier and timestamp of this usage record are appended to the tail of the usage queue in local memory.

[0118] S64: In post-processing, the log data object containing the response time, status code, and request path of this request is appended to the log buffer array in local memory; Check if the length of the log buffer array is greater than or equal to the preset number of entries threshold, or if the current time minus the last push timestamp is greater than or equal to the preset time threshold.

[0119] S65: If any of the conditions in S64 are true, then retrieve all log data objects from the log buffer array and all usage record objects from the usage queue; Call the nextId method of the snowflake ID generator to assign a globally unique integer identifier to each log and each usage record; Call the asynchronous send function to send log batches to the Elasticsearch server and usage batches to the Gallery service; after successful sending, clear the log buffer array and usage queue.

[0120] As can be seen, in step S61, within the pre-processing method of auth-apikey-filter, the APIKey string is extracted from the request encapsulation object and concatenated into the key name "user:info:{apiKey}". The Redis client's get method is then called, passing in this key name. If null or an empty string is returned, an HTTP request is constructed to call the Gallery service's user authentication interface, passing in the APIKey, and the response body is parsed to obtain the user information object.

[0121] Further, in step S62, within the pre-processing method of quota-check-filter, the apiKey, productId, and skuId are extracted from the request and concatenated into the key name "quota:{apiKey}:{productId}:{skuId}". The Redis get command is then invoked. If null is returned, an HTTP request is constructed to call the quota query interface of the Gallery service, and the response is parsed to obtain the quota information object. The Redis set command is then invoked to store this object. In the pre-processing method of usage-record-filter, the apiKey, productId, and skuId are extracted from the request and concatenated into the key name "usage:{apiKey}:{productId}:{skuId}". The Redis incr command is invoked, which atomically increments the integer value corresponding to the key by 1 and returns the new value. If the key does not exist, it is automatically initialized to 0 and then incremented by 1.

[0122] Furthermore, in step S64, the post-processing method of the http-logging-filter extracts information such as response time, status code, and request path from the response encapsulation object and assembles them into a log object. In step S65, the snowflake ID generator uses the machine ID, timestamp, and sequence number to generate a globally unique, trend-increasing integer ID without coordination. This embodiment defines a globally unique ID to ensure that logs and usage records are sortable in a distributed environment, and batch sending reduces the number of connections and network round trips, improving throughput.

[0123] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0124] like Figure 5 As shown, this application also provides an electronic device, including a display module 103, a memory 102, a processor 101, a communication module 104, and a computer program stored in the memory and executable on the processor 101. When the processor 101 executes the program, it implements the steps of a cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture.

[0125] In embodiments of the present invention, electronic devices include, but are not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments described and / or claimed herein.

[0126] In this embodiment, processor 101 may be implemented using at least one of an application-specific integrated circuit, a programmable logic device, a field-programmable gate array, a processor, a controller, a microcontroller, a microprocessor, or an electronic unit designed to perform the functions described herein. In some cases, such an implementation may be implemented within a controller. For software implementation, implementations such as processes or functions may be implemented with separate software modules that allow the performance of at least one function or operation. Software code may be implemented by a software application (or program) written in any suitable programming language, and the software code may be stored in memory and executed by the controller.

[0127] The display module 103 is used to display information input by the user or information provided to the user. The display module 103 may include a display panel, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like.

[0128] The memory 102 can be used to store software programs and various data. The memory 102 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0129] The communication module 104 transmits radio signals to and / or receives radio signals from at least one of a base station, an external terminal, and a server. Such radio signals may include voice call signals, video call signals, or various types of data sent and / or received according to text and / or multimedia messages.

[0130] The present invention also provides a storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of the cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture.

[0131] The storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A 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 thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable 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.

[0132] The storage medium stores a program product capable of implementing the methods described above in this specification. In some possible implementations, various aspects of this disclosure may also be implemented as a program product comprising program code that, when run on a terminal device, causes the terminal device to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure.

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

Claims

1. A cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture, characterized in that, Includes the following steps: S1: Read the configuration file, parse the global filter configuration and HTTP routing rule configuration, and build the routing table and filter chain configuration objects; S2: Scan the specified plugin directory, load the plugin modules, and register the plugin name and plugin class to the global plugin registry; S3: Create an aggregator instance based on the configuration object, find the corresponding class from the global plugin registry based on the plugin name, generate filter instances and processor instances by creating instances at runtime, inject the configuration parameters, build the global filter chain, route-level filter chain and processor respectively, and generate the routing table; S4: Register the routes in the routing table with the HTTP server and start the server to listen for client requests; S5: When a client HTTP request is received, the routing table generated based on the URL path and HTTP method is used; If a match is found, the request and response objects are encapsulated, and the preprocessing of the constructed global filter chain and route-level filter chain is executed in sequence. If all preprocessing passes, the processor that executes the build will request to be proxied to the backend service; The post-processing of the route-level filter chain and the global filter chain is executed in reverse order, and finally the response is returned to the client.

2. The cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture according to claim 1, characterized in that, During the pre-processing and / or post-processing of the S5 routing-level filter chain, user information, quota information, usage counts, and log data are stored in a cache. The user information and quota information are cached on a remote cache server, the usage count is performed concurrently and safely through atomic operations, and the log data is batch cached and then asynchronously pushed to persistent storage.

3. The cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture according to claim 2, characterized in that, The steps involve caching user information, quota information, usage counts, and log data, specifically including the following: In the pre-processing, user information is read from the remote cache server using the user identifier as the key. If the read fails, the authentication service is called to obtain the user information and write it into the cache, and an expiration time is set. In the pre-processing, quota information is read from the remote cache server using the quota identifier as the key. If the read fails, the quota service is called to obtain the quota information and write it to the cache. In the preprocessing, an atomic auto-increment operation is performed on the usage count key by the remote cache server, and the current usage record is appended to the usage queue in local memory; In post-processing, the log data of this request is appended to the log buffer array in local memory, and it is checked whether the array length reaches the preset number of records threshold or whether the time interval since the last push reaches the preset time threshold. When either the record count threshold or the time threshold is met, all records are retrieved from the log buffer array and the usage queue. A globally unique identifier is generated for each record. Then, the log batch is sent to the log storage server and the usage batch is sent to the usage storage server via asynchronous calls. After successful sending, the buffer array and the usage queue are cleared.

4. The cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture according to claim 1, characterized in that, S1 specifically includes the following steps: Read the operating system environment variable RUNTIME_SERVER_PORT. If the variable is not defined, assign the default value 8080 as the server port number. Based on the preset configuration file path string, locate and open the YAML format configuration file aggregator.yaml; The YAML parsing library is invoked to parse the text content of the file and generate a Config data structure object containing global filter configuration fields and HTTP routing rule configuration fields; Based on the listening address and port number fields in the Config object, the HTTP server constructor is called to create a server instance, and the instance is bound to the specified address and port; Call the configuration loading method of the server instance, passing in a Config object; iterate through the routing rule array and global filter array in the Config object, fill in the routing table data structure item by item, and assemble the filter chain configuration object.

5. The cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture according to claim 1, characterized in that, S2 specifically includes the following steps: Read the preset built-in plugin directory path and extended plugin directory path, traverse each directory and recursively collect all plugin file paths that match the specified file extension, forming a set of file paths to be loaded. Iterate through the set of file paths to be loaded, load the plugin modules one by one through the runtime import interface, and check whether each module contains a preset registration function. Mark the modules containing the registration function as valid plugin modules. For each valid plugin module, its registration function is called. The registration function passes the plugin name and plugin class reference to the plugin registration context. It also determines whether the plugin class belongs to the filter type or the processor type by reading the parent class or interface type of the plugin class and marks the corresponding type tag. Create a global plugin registry containing filter registration sub-tables and processor registration sub-tables. Encapsulate the name, class reference, and type tag of each plugin into a registration unit, store it in the corresponding sub-table according to the type tag, and store the class reference with the plugin name as the key; if the key already exists, overwrite the original value and prompt that the name is duplicated. The global plugin registry is traversed to count the number of registered filters and processors. The name and type tag of each plugin are formatted into a plugin loading list and output to the standard output stream. The completed global plugin registry is then used by the aggregator initialization step.

6. The cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture according to claim 1, characterized in that, S3 specifically includes the following steps: Receive the runtime configuration object and the global plugin registry, and create an aggregator instance after reading the server listening parameters; Iterate through the global filter chain configuration unit in the runtime configuration object, find the filter class reference from the filter registration sub-table of the global plugin registry and create a filter instance, inject the parsed configuration parameters into the instance and append them to the global filter chain container in the configuration order; Iterate through the routing table configuration cells in the runtime configuration object, create a route instance for each route configuration cell, write its URL path matching field and HTTP method matching field into the matching rule attribute of the route instance, and create an independent route-level filter chain container and processor placeholder attribute for the route instance; Read the route-level filter chain configuration corresponding to each route instance, look up the filter class reference from the filter registration sub-table and create a filter instance, inject the parsed configuration parameters into the instance and append them to the route-level filter chain container of the route instance in the configuration order; Read the processor configuration corresponding to each route instance, look up the processor class reference from the processor registration sub-table in the global plugin registry and create a processor instance, inject the parsed configuration parameters into the instance and bind them to the processor placeholder attribute of the route instance; All completed route instances are stored in the routing table container of the aggregator instance. The container supports fast retrieval using a composite key consisting of a URL path matching field and an HTTP method matching field, and the aggregator instance is output for use in the route registration step.

7. The cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture according to claim 1, characterized in that, S4 specifically includes the following steps: Receive the aggregator instance and read the route table container within it. Iterate through each route instance to extract the URL path matching field and HTTP method matching field from the matching rule attributes. Create a route handler closure function for each route instance. The closure captures the global filter chain reference in the aggregator instance, as well as the route-level filter chain reference and handler instance reference in the route instance. Inside the closure, a filter chain instance is created and the captured reference is passed in. The native request and response are encapsulated into a gateway request object and a gateway response object, and then the startup method of the filter chain instance is called. Call the HTTP server's route registration interface, passing in the extracted URL path matching field, HTTP method matching field, and the corresponding route handler closure function, so that the HTTP server can build a route lookup tree and bind the closure function to the corresponding tree node; The HTTP server's startup method is called, passing in the server listening parameters from the aggregator instance. This causes the HTTP server to create a network socket, bind the listening address and port, and then start listening for client requests. When a request is received, the URL path and HTTP method are parsed, and a matching closure function is searched in the route lookup tree. If a match is found, the request is processed; otherwise, a pre-defined unmatched response is returned.

8. The cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture according to claim 1, characterized in that, S5 specifically includes the following steps: Receive client HTTP requests, parse the request line to extract the request method string and request URL path string, call the routing table container of the aggregator instance to retrieve the interface for matching, and return a preset unmatched response if no match is found. After a route instance is matched, a gateway request object instance is created and the request method, request path, request header, query parameters and request body data are written. A gateway response object instance is created and the status code is initialized to the preset default value, the response header is empty and the response body is empty. Then the two instances are attached to the current request context. Read the global filter chain container reference in the aggregator instance and the route-level filter chain container reference and processor instance reference in the matched route instance, create a filter chain instance and pass in the above references and request-response object, and call the global pre-startup method to execute the pre-processing method of each global filter instance in sequence; After the preprocessing method of each global filter instance returns, check whether the status code of the gateway response object instance deviates from the preset default value or whether the response body has been written with a non-empty value. If either condition is met, terminate the global preprocessing and skip the remaining global filters and all route-level filters to directly enter the post-response return step. If all global preprocessing steps have been completed without triggering a short circuit, the route-level preprocessing startup method is called to execute the preprocessing methods of each route-level filter instance in sequence and perform the same short circuit detection. If no short circuit is triggered in all routing-level preprocessing, the processor execution method is called. The backend service address is concatenated according to the target address prefix and request URL path in the processor configuration parameters, a backend service request object is constructed and sent to the backend service, and the status code, response header and response body are parsed after receiving the response data and written to the gateway response object instance. The post-startup method of the filter chain instance is called first, and the post-processing method of each route-level filter instance is called in reverse order of the array index in the route-level filter chain container. Then, the post-processing method of each global filter instance is called in reverse order of the array index in the global filter chain container. Read the status code attribute, response header set, and response body attribute from the gateway response object instance, create a native response object and write the above attributes, and return the native response object to the HTTP server to send it to the client via the connection socket.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture as described in any one of claims 1 to 8.

10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the cloud-native gateway aggregation service method based on dynamic configuration and plug-in architecture as described in any one of claims 1 to 8.

Images