Method and system for API gateway to dynamically route backend address

Abstract

The application relates to the computer technical field and discloses a method and system for dynamically routing a backend address of an API gateway, the method comprising: receiving an HTTP request and parsing a URL and a request header; extracting a tenant identifier, supporting multi-mode identification of the request header, a subdomain name or a path segment; loading a set of exclusive routing rules of the tenant identifier; performing longest path prefix matching through a prefix tree according to local priority sorting within the tenant to determine an optimal backend address; and finally forwarding the request. The system comprises request parsing, tenant identification, rule loading, local sorting, longest matching and request forwarding modules, and supports hot updating of routing rules and conflict detection. The application effectively eliminates cross-tenant interference and improves routing accuracy and system isolation through tenant context perception and a two-stage matching mechanism.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of computers, and particularly relates to a method and system for dynamically routing a backend address of an API gateway. BACKGROUND

[0002] With the wide application of cloud computing, micro-service architecture and SaaS platform, the API gateway as the core component of the system entrance undertakes the key functions of request routing, authentication and authorization, traffic control and the like. In the multi-tenant environment, different tenants need to customize routing rules based on their own business needs, for example, matching specific backend services through path prefixes, domain names or Header fields. Such custom mechanisms improve the flexibility and scalability of the system, but also introduce complex rule management challenges. Since each tenant independently configures routing strategies, there is a lack of global coordination between their rules, which can easily cause semantic overlap or logical conflicts at the gateway level, resulting in uncertain request distribution paths.

[0003] The dynamic routing mechanism allows tenants to adjust the backend address mapping relationship at runtime to adapt to scenarios such as elastic scaling, gray release or fault switching. This mechanism usually relies on pre-set static priorities (such as rule creation time, explicit weight value) to sort matching rules, thereby determining the final routing target. However, in a real production environment with high concurrency and multiple tenants coexisting, static priorities cannot reflect the real-time characteristics of the request context (such as tenant identity, call link status, backend health), so that legitimate requests that should be handled by high-priority rules may be intercepted by low-priority but more general rules in advance, causing false rejection or misplacement.

[0004] The mainstream API gateway solution generally uses linear matching or tree index structure to implement routing lookup, which can ensure single query efficiency, but in scenarios where the rule set is frequently updated and the number of tenants is large, it is difficult to effectively identify and eliminate potential conflicts between rules. Some solutions attempt to introduce manual review or offline verification processes to avoid conflicts, but at the expense of real-time response capabilities of the system; other solutions use hard-coded priority strategies to enforce ordering, ignoring the needs for fairness between tenants and context relevance. The above defects are particularly prominent in the fields of finance, government affairs and the like, which have strict requirements for request accuracy and isolation, significantly increasing the complexity of operation and maintenance and business risks. SUMMARY

[0005] The application provides a method and system for dynamically routing backend addresses of an API gateway, aiming to solve the technical problem of incorrect interception of requests and thus high false rejection rate caused by priority conflicts of tenant-defined routing rules in a multi-tenant scenario. In the prior art, the API gateway usually uses static configuration or global priority strategy to process routing rules. When multiple tenants define path prefix matching rules in their respective independent business domains, if the rules of different tenants have path overlap or inclusion relationship, the global sorting mechanism cannot accurately identify the tenant context boundary, resulting in that the high-priority tenant rules indiscriminately cover the valid request paths of low-priority tenants, causing legitimate requests to be incorrectly rejected. In addition, the traditional scheme lacks the ability to dynamically analyze the binding relationship between tenant identity and routing rules in runtime, and cannot real-time perceive the tenant attribution and activate the exclusive routing rule set accordingly during the request processing process, resulting in that the routing decision is separated from the tenant isolation semantics, and the logical isolation and service accuracy of the multi-tenant system are damaged.

[0006] To overcome the above defects, the application proposes a dynamic routing method and system architecture based on tenant context awareness. The method determines the tenant identity at the initial stage of request analysis by constructing a tenant identification extraction mechanism at the API gateway entrance, and dynamically loads the routing rule set strictly bound to the identity based on the identity. On this basis, a local priority sorting mechanism within the tenant is introduced to ensure that multiple custom rules within the same tenant are accurately matched in the order of their declaration or explicit priority value, avoiding unexpected interference between cross-tenant rules. At the same time, a two-level routing matching engine is designed, the first level is used to quickly filter out the rule subset to which the current tenant belongs, and the second level performs the longest matching algorithm of path prefix in the subset, thereby realizing high-precision and low-delay backend address mapping.

[0007] As an embodiment of the present application, the method comprises the following steps: first, receiving an HTTP request from a client, parsing the uniform resource locator and the request header information of the HTTP request; second, extracting a tenant identification field from the request header information, the tenant identification field being a preset standardized header key name, the value of the tenant identification field being injected by an authentication service when a user logs in and verified by digital signature; if the request header does not contain a valid tenant identification, the tenant coding segment in the domain name part or the path prefix of the uniform resource locator is used for auxiliary derivation, and the derivation rule is stored in a tenant mapping table in advance; then, according to the determined tenant identification, a set of routing rules uniquely associated with the tenant is loaded from a routing rule storage unit, the set of routing rules being organized in the form of key-value pairs, the key being a path prefix string, and the value being the corresponding backend service address and additional metadata; then, in the set of routing rules, a local matching sequence is established according to the explicit priority value or the configuration order of each rule; then, the path part of the uniform resource locator is compared with each path prefix in the local matching sequence, and the longest prefix matching principle is used to determine the optimal matching rule; finally, according to the backend service address associated with the optimal matching rule, the original request is forwarded to the corresponding service instance, and the original request header and path information are transmitted.

[0008] Further, the routing rule storage unit is implemented by using a hierarchical data structure, the top layer is a tenant identification hash index table, the next layer is a rule list corresponding to each tenant, and each rule contains a path prefix, a backend address, a priority value, an enable state flag and a version number; the priority value is an integer type, and the smaller the value, the higher the priority; when multiple path prefixes of the same tenant are configured to have a containing relationship, the system automatically checks whether there is a priority inversion risk, and if it is detected that a high-priority rule completely contains the path space of a low-priority rule, a configuration conflict alarm is triggered and the rule update operation is rejected, thereby ensuring the consistency of the tenant internal rule logic.

[0009] Further, the tenant identification extraction mechanism supports multiple identification modes, including but not limited to: direct reading based on the X-Tenant-ID field in the request header, parsing based on the tenant1 segment in the subdomain name tenant1.api.example.com, and extraction based on the tenant1 segment in the uniform resource locator path / api / tenant1 / v1 / resource; the system loads a tenant identification strategy configuration file at startup, the file defines the priority order and regular expression templates of the identification modes, and attempts to match in order at runtime until a valid tenant identification is successfully extracted; if all modes fail, a 403 Forbidden status code is returned and an audit log is recorded.

[0010] Further, the first stage of the two-stage routing matching engine realizes O(1) time complexity of tenant rule set positioning through tenant identification hash index table; the second stage constructs prefix tree data structure inside the tenant rule set, inserts all path prefixes into the prefix tree, each node stores a flag of whether it is a terminal node and a corresponding backend address pointer; when matching, traverse the request path character by character from the root node, record the last encountered terminal node as the candidate matching result; after the end of the traversal, if there is a candidate matching result, select the one with the longest path length as the final matching rule; if there is no any matching, return 404 Not Found status code.

[0011] Further, the routing rule set supports a hot update mechanism; when a tenant submits a new routing configuration through a management interface, the system generates a new version of the rule set snapshot and assigns a unique version number; in subsequent request processing, all requests using the tenant identification are atomically switched to the new version of the rule set, and the old version is automatically recycled after there is no active reference; the version switching process is controlled through read-write locks to ensure the lock-free high performance of read operations and the consistency of write operations.

[0012] As another embodiment of the present application, an API gateway dynamic routing backend address system is provided, which comprises: a request receiving and parsing module for receiving a client HTTP request and parsing a uniform resource locator and request header; a tenant identification extraction module for extracting a tenant identification from the request, supporting multi-mode identification and auxiliary derivation; a tenant routing rule loading module for loading a corresponding routing rule set from a routing rule storage unit according to the tenant identification; a local priority sorting module for establishing a matching sequence arranged in priority or configuration order inside the tenant rule set; a longest prefix matching module for performing a longest matching algorithm of path prefix in the matching sequence to determine the optimal routing rule; and a request forwarding module for forwarding the request to a target service instance according to the backend address specified by the optimal routing rule.

[0013] Further, the routing rule storage unit comprises a tenant hash index table and a tenant rule list library; the tenant hash index table takes tenant identification as the key and a memory pointer pointing to the corresponding rule set in the tenant rule list library as the value; the tenant rule list library stores the complete rule set of each tenant, and each rule contains a path prefix string, a backend service address string, a priority integer value, an enable Boolean flag and a version long integer identification.

[0014] Further, the tenant identification extraction module is internally provided with a tenant identification strategy engine, which loads a pre-configured identification strategy file, the strategy file defining at least three identification modes: request header field matching, subdomain name resolution, and path segment extraction; each mode is configured with a regular expression template and an extraction group index; the engine executes the matching in order of strategy priority, and once a non-empty tenant identification string is successfully extracted by a certain strategy, the subsequent strategy execution is terminated and the identification is returned.

[0015] Further, the longest prefix matching module maintains a prefix tree structure, each node of the prefix tree containing a character mapping table, a Boolean flag indicating whether it is a rule termination point, a corresponding backend address pointer, and a path depth value; in the rule loading stage, each path prefix in the tenant rule set is inserted into the prefix tree character by character, and the node at the end of the path is marked as a termination point and stores the backend address; in the matching stage, the prefix tree is traversed along the character sequence of the request path, and all the passed termination nodes and their path depths are recorded, and finally the one with the largest depth is selected as the matching result.

[0016] Further, the system further comprises a rule hot update management module, which listens to tenant routing configuration change events; when receiving a new configuration, a memory copy of the new rule set is generated, a new version number is allocated, and the corresponding rule set pointer in the tenant hash index table is updated through an atomic pointer exchange operation; the old version rule set is released by the garbage collection mechanism after the reference count is zero.

[0017] Compared with the prior art, the beneficial effects of the present application are:

[0018] 1. By introducing a tenant context awareness mechanism in the API gateway, the matching range of routing rules is strictly limited to the exclusive rule set of the tenant to which the request belongs, fundamentally eliminating the priority conflict problem of cross-tenant routing rules, and effectively avoiding the phenomenon of legal requests being mistakenly intercepted due to global rule sorting;

[0019] 2. A two-level routing matching architecture is adopted, the first level realizes fast positioning of the tenant rule set, and the second level executes the longest matching algorithm based on the prefix tree within the tenant, balancing matching accuracy and processing performance; multi-mode tenant identification extraction and hot update mechanism are supported, improving the adaptability and operation flexibility of the system;

[0020] 3. Through local priority control and configuration conflict detection within the tenant, the self-consistency and maintainability of the routing logic of a single tenant are guaranteed; the overall scheme significantly reduces the request rejection rate in a multi-tenant environment without sacrificing throughput, enhancing the service isolation capability and tenant self-controllability of the API gateway. BRIEF DESCRIPTION OF DRAWINGS

[0021] One or more embodiments are illustrated by way of example in the drawings in which like reference numerals indicate similar elements, and as such, clearances and the like are not necessarily drawn to scale. Unless otherwise noted, like reference numerals are used throughout specific details and illustrative examples that can be implemented as part of one or more embodiments. Also, the drawings provided herein are not to scale as the objects being presented will not require such precision in implementation.

[0022] Figure 1 is the overall technical solution architecture schematic diagram of the API gateway dynamic routing backend address method and system proposed in the present application;

[0023] Figure 2 is the core principle framework schematic diagram of the two-level routing matching engine based on tenant context awareness in the present application;

[0024] Figure 3 is the tenant identification extraction and multi-mode recognition logic flow framework diagram in the present application;

[0025] Figure 4 is the tenant routing rule loading and local priority sorting logic flow framework diagram in the present application;

[0026] Figure 5 is the prefix tree construction and query principle framework diagram of the longest prefix matching within the tenant rule set in the present application;

[0027] Figure 6 is the multi-level interaction relationship and data flow schematic diagram between the API gateway and the tenant management service, routing rule storage unit in the present application. DETAILED DESCRIPTION

[0028] In order to make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0029] Please refer to Figures 1 to 6The application provides a method and system for dynamically routing backend addresses of an API gateway, aiming to solve the technical problem of incorrect interception of requests and thus high false rejection rate caused by priority conflicts of tenant-defined routing rules in a multi-tenant scenario. In a multi-tenant architecture, different tenants can independently configure their exclusive path prefix matching rules to map to their respective backend service addresses. However, existing API gateways generally use a globally unified routing rule sorting mechanism. When the path rules of multiple tenants overlap or contain each other, the rules of high-priority tenants may indiscriminately cover the valid paths of low-priority tenants, resulting in legitimate requests being incorrectly rejected. In addition, traditional solutions lack the ability to dynamically analyze the binding relationship between tenant identity and routing rules in runtime, and cannot activate the exclusive rule set of a tenant in real time during request processing, causing the routing decision to deviate from the tenant isolation semantics and damaging the logical isolation and service accuracy of the multi-tenant system.

[0030] To overcome the defects of mutual interference of routing rules, inability to update dynamically according to tenants, and low path matching efficiency in multi-tenant API gateways, the embodiment constructs a dynamic routing method based on tenant context awareness, which can follow the following S-step sequence:

[0031] S1, receiving an HTTP request from a client, parsing the uniform resource locator and request header information of the HTTP request;

[0032] S2, extracting a tenant identification field from the request header information; the tenant identification field is a pre-set standardized header key name, and the value of the tenant identification field is injected by an authentication service when a user logs in and is verified by digital signature; if the request header does not contain a valid tenant identification, the tenant coding segment in the domain name part or the path prefix of the uniform resource locator is used for auxiliary derivation, and the derivation rule is pre-stored in a tenant mapping table;

[0033] S3, according to the determined tenant identification, loading a routing rule set uniquely associated with the tenant from a routing rule storage unit; the routing rule set is organized in the form of key-value pairs, with the key being a path prefix string and the value being the corresponding backend service address and additional metadata;

[0034] S4, within the routing rule set, establishing a local matching sequence according to the explicit priority values or configuration order of each rule;

[0035] S5, comparing the path part of the uniform resource locator with each path prefix in the local matching sequence item by item, and determining the optimal matching rule using the longest prefix matching principle;

[0036] S6. According to the backend service address associated with the optimal matching rule, the original request is forwarded to the corresponding service instance, and the original request header and path information are transmitted in place.

[0037] The embodiment maintains an independent and dynamically configurable routing rule set for each tenant, and implements a two-level routing decision mechanism based on tenant dimension-based routing rule loading and path dimension-based intra-rule matching, thereby realizing strict routing isolation and efficient dynamic routing in a multi-tenant environment. The mechanism ensures that the routing configurations of different tenants are completely independent and do not interfere with each other, and that the rule changes of any tenant will not affect other tenant services, while the local optimization matching at the tenant level can significantly improve the routing lookup efficiency.

[0038] In the S1 step, the network listening layer of the API gateway continuously listens to the inbound connection on the preset port. When a complete HTTP request message is received, the protocol parsing engine is started immediately. The engine first checks whether the request line conforms to the HTTP / 1.1 or HTTP / 2 specification, and then separates the uniform resource locator string and the request header field set. The uniform resource locator is further decomposed into the protocol type, host name, port number, path part, and query parameter. The request header field set is stored in the memory hash table in the form of key-value pairs, with the key being the standardized header name (such as Host, User-Agent, Authorization) and the value being the corresponding string content. This step ensures that the subsequent processing modules can directly access the structured request metadata, avoiding repeated parsing overhead.

[0039] In the S2 step, the tenant identification extraction mechanism is activated. The mechanism can check whether the X-Tenant-ID field exists in the request header; if the X-Tenant-ID field exists and the value of the field conforms to the pre-defined tenant identification format specification, the X-Tenant-ID field is taken as a valid tenant identification; if the X-Tenant-ID field does not exist or the format is not consistent, the tenant identification is extracted from the subdomain name segment or the path segment of the uniform resource locator in turn, and the extraction process is performed according to the preloaded regular expression template and the tenant mapping table; if all identification modes fail, the 403 Forbidden status code is returned and the audit log is recorded.

[0040] For example, the presence of a key named X-Tenant-ID in the request header field set can be checked first. If present, its value is read as a candidate tenant identification, and the value is verified against a predefined tenant identification format specification, which requires the tenant identification to be an alphanumeric string with a length between 3 and 64 characters, and only allows hyphen and underscore. If the format check passes, the value is marked as a valid tenant identification, and the S2 step ends. If the X-Tenant-ID field is not present in the request header, or its value does not conform to the format specification, the secondary derivation procedure is entered. The secondary derivation procedure first attempts to extract a subdomain name segment from the host name part of the uniform resource locator. For example, if the host name is tenant_alpha.api.example.com, tenant_alpha can be extracted as a candidate identification. This process is implemented by a preloaded regular expression template, which defines the pattern as [a-zA-Z0-9][-a-zA-Z0-9]*.api\.example\.com, where the first capture group is the tenant identification. If the subdomain name resolution fails, the path part is turned to for extraction. The path part is split by slashes into a list of segments, and if the second segment (index 1) conforms to the tenant identification format specification, it is taken as the candidate identification. All derivation operations rely on a tenant mapping table loaded at startup, which records the legal identifications of registered tenants and their corresponding identification pattern weights. If all identification patterns fail to extract a valid tenant identification, the API gateway immediately terminates the processing flow, returns a 403 Forbidden status code, and records the request source IP, timestamp, and missing identification type in the audit log for security tracing.

[0041] In the S3 step, the tenant routing rule loading module performs dynamic loading of the rule set according to the valid tenant identification output in the S2 step. Specifically, the tenant identification hash index table can be used to locate the rule set pointer corresponding to the tenant, the tenant identification hash index table taking the tenant identification as the key and the memory pointer pointing to the rule set in the tenant rule list library as the value; the reference count of the rule set is obtained and incremented to prevent recycling during hot updating; each rule in the routing rule set includes a path prefix string, a backend service address string, a priority integer value, an enable Boolean flag, and a version long integer identification.

[0042] In some examples, the routing rule storage unit can adopt a two-level memory structure organization: the top layer is a tenant identification hash index table, and the bottom layer is a tenant rule list library. The hash index table takes the tenant identification string as the key and the pointer to the starting address of the corresponding rule set in the rule list library as the value. Each rule set in the rule list library is composed of a continuous memory block, including a rule entry array, a version number, a reference count, and a write lock. Each rule entry includes five fields: a path prefix string, a backend service address string, a priority integer value, an enable Boolean flag, and a path depth integer value. The path depth is automatically calculated when the rule is loaded and is equal to the number of segments separated by slashes in the path prefix. The loading operation first calculates the hash value of the tenant identification through a hash function and locates the entry in the hash index table in constant time. If the entry is empty, it indicates that the tenant has not registered any routing rules, and a 404 Not Found status code is returned. If the entry is not empty, the rule set pointer pointed by it is obtained, and the reference count of the set is increased to prevent it from being recycled by the hot update mechanism during subsequent processing. This step ensures that each request only accesses the rule data of its own tenant, completely isolating cross-tenant rule interference.

[0043] In the S4 step, the local priority sorting module internally sorts the rule set loaded in the S3 step to generate a local matching sequence. Specifically, all rules in the rule set can be sorted in ascending order of the priority integer value, with the smaller value indicating higher priority. If the priorities are the same, they are arranged in the original configuration order. After sorting, a rule pointer array is generated as the local matching sequence. During the loading phase, if the path prefix of a high-priority rule completely contains the path prefix of a low-priority rule, a configuration conflict alarm is triggered and the rule update is rejected.

[0044] In some examples, the sorting basis can be a priority integer value in the rule item, and the smaller the value, the higher the priority. If multiple rules have the same priority value, they are arranged in the order of their declaration in the original configuration file. The sorting algorithm uses a stable quicksort implementation with a time complexity of O(n log n), where n is the number of rules for the tenant. After sorting, an array of rule pointers is generated, which is the local matching sequence. This sequence ensures that in the subsequent matching process, high-priority rules are checked before low-priority rules, so that when there is a containing relationship between path prefixes (such as / api / v1 and / api / v1 / user), more specific rules are matched first. In addition, during the rule loading stage, the system performs configuration conflict detection: if rule A's path prefix completely contains rule B's path prefix (i.e., B's path starts with A's path and is longer), but rule A's priority value is greater than rule B's, then it is determined that there is a risk of priority inversion. At this time, the system rejects the tenant's rule update request and returns an error code ERR_PRIORITY_CONFLICT to the management interface, while recording the path prefixes and priority values of the conflicting rules for troubleshooting by the operation and maintenance personnel.

[0045] In the S5 step, the longest prefix matching module performs exact matching on the local matching sequence generated in the S4 step. A prefix tree can be constructed for the tenant during the rule loading stage, and each path prefix is inserted into the prefix tree character by character. The nodes at the end of the path are marked as terminal nodes and store the corresponding rule pointers. During matching, the prefix tree is traversed along the character sequence of the request path, and all passed terminal nodes and their path depths are recorded. After the traversal is completed, the rule corresponding to the node with the maximum path depth is selected as the optimal matching rule.

[0046] If no terminal node is hit, return a 404 Not Found status code.

[0047] It can be understood that the matching process is not simply traversing the sequence, but using the prefix tree data structure to speed up the query. In the rule loading stage (at the end of S3 step), the system can build a special prefix tree for each tenant's rule set. Each node of the prefix tree contains 4 members: a character child node mapping table (with ASCII characters as keys and node pointers as values), a boolean flag indicating whether it is a terminal node, a pointer to the matching rule item, and the current node depth value. When building, the path prefix of each rule (remove the trailing slash if exists) is inserted into the tree character by character. For example, the path prefix / api / vl is split into [' / ', 'a', 'p', 'i', ' / ', 'v', 'l'], and nodes are created or reused in turn, and finally the 'l' node is marked as a terminal node and a pointer to the rule item is stored. When matching, the path part of the uniform resource locator is also split into a character sequence, and it is traversed character by character from the root node. During the traversal process, whenever a terminal node is encountered, the node and its depth value are recorded as a candidate matching result. After the traversal is completed, the candidate with the largest depth value is selected from all candidate results, and the corresponding rule item is the optimal matching rule. If no terminal node is hit, the matching fails and returns a 404 Not Found status code. This mechanism optimizes the matching time complexity from the traditional linear scan O(n) to O(m), where m is the character length of the request path and n is the number of rules. For tenants with a large number of routing rules, especially in the case of paths with common prefixes, this optimization brings a performance improvement of orders of magnitude, which can ensure the low latency response of the gateway under high concurrency.

[0048] In the S6 step, the request forwarding module executes the actual proxy forwarding according to the optimal matching rule determined in the S5 step. Optionally, when building the prefix tree, each node contains a character child node mapping table, a boolean flag indicating whether it is a terminal node, a pointer to the matching rule item, and the current node depth value; the path prefix is removed from the trailing slash before insertion, and nodes are created or reused character by character.

[0049] Specifically, the module can first read the backend service address string from the matching rule entry, which is a complete URL containing the protocol, host, port, and optional base path. The path part of the original request is replaced by the concatenation of the base path (if any) specified in the rule and the remaining part of the original path. For example, if the rule backend address is https: / / user-service:8080 / api and the original request path is / api / v1 / user / profile, the forwarding path is / api / user / profile. The request header information is completely retained, with only the addition of standard proxy headers such as X-Forwarded-For, X-Real-IP, etc. The forwarding operation is performed through an asynchronous I / O channel to avoid blocking the main thread. The response data stream returns to the client through the same channel, with the status code and header information being passed through as is. The entire forwarding process records detailed access logs, including tenant identification, matching rule path, backend address, request time consumption, and response status code, for performance monitoring and fault diagnosis, thus completing the closed loop from routing decision to service invocation, ensuring that requests are accurately and efficiently routed to isolated backend service instances, and achieving fine-grained management and controllable forwarding of network traffic under a multi-tenant architecture.

[0050] The execution of the above method steps relies on a set of precise and coordinated system components. The request receiving and parsing module is responsible for implementing step S1, and its underlying layer is based on an event-driven network library that supports high-concurrency connection processing. The tenant identification extraction module encapsulates all the logic of step S2, and the built-in policy engine executes three recognition modes in the order of preset priorities: request header field matching, subdomain name resolution, and path segment extraction. Each mode is configured with an independent regular expression template and extraction group index, and the policy file is loaded into memory at system startup and cannot be modified at runtime. The tenant routing rule loading module implements step S3, and its core is the joint access mechanism of the tenant hash index table and the rule list library. The hash index table uses open addressing to solve conflicts, with a load factor threshold of 0.75, and automatically expands when exceeded. Each rule set in the rule list library is protected by a read-write lock, and read operations (such as request processing) do not require locking, while write operations (such as hot updates) require acquiring a write lock. The local priority sorting module is dedicated to step S4, and its sorting results are cached inside the tenant rule set, and only recalculated when the rule version changes. The longest prefix matching module carries out step S5, and its prefix tree structure is built once during rule loading, with subsequent matching operations being pure read operations without memory allocation overhead. The request forwarding module completes step S6, integrating connection pool management and health check mechanisms to automatically exclude unavailable backend instances.

[0051] The rule hot update mechanism runs throughout the system life cycle. When a tenant submits a new routing configuration through the management interface, the rule hot update management module is triggered. The module first checks the syntax and semantics of the new configuration, including path prefix format, backend address reachability, priority value range, etc. After passing the check, a complete memory copy of the new rule set is generated, and a new version number (monotonically increasing integer) is assigned. Then, the write lock of the tenant hash index table is acquired, the original rule set pointer is atomically replaced with the new set pointer, and the write lock is released. The reference count of the old rule set is zeroed after the last request processing is completed, and the memory occupied by it is released by the background garbage collection thread. The entire switching process is implemented through atomic pointer exchange and reference counting mechanism, which is completely transparent to online requests, can achieve zero-interruption hot update, and is conducive to meeting the strict requirements of business continuity.

[0052] In some embodiments, an API gateway system for dynamically routing backend addresses is also provided, comprising: a request receiving and parsing module for receiving client HTTP requests and parsing uniform resource locators and request headers; a tenant identification extraction module for extracting tenant identification from the request, supporting multi-mode identification and auxiliary derivation; a tenant routing rule loading module for loading the corresponding routing rule set from the routing rule storage unit according to the tenant identification; a local priority sorting module for establishing a matching sequence arranged by priority or configuration order within the tenant rule set; a longest prefix matching module for performing a longest matching algorithm on path prefixes in the matching sequence to determine the optimal routing rule; and a request forwarding module for forwarding the request to the target service instance according to the backend address specified by the optimal routing rule.

[0053] That is, a routing rule storage unit for storing a separate, dynamically updateable routing rule set for each tenant; a routing decision and forwarding engine connected to the tenant identification determination module and the routing rule storage unit for performing two-level routing decisions:

[0054] In the first-level decision, the corresponding routing rule set is loaded from the routing rule storage unit according to the tenant identification;

[0055] In the second-level decision, the optimal routing rule is determined by the longest prefix matching within the loaded routing rule set based on the path part of the request, and the request is forwarded to the target service instance according to the rule.

[0056] The system modularly implements the two-level routing decision architecture of the above method through hardware, and solidifies tenant isolation, dynamic loading, efficient matching, and reliable forwarding capabilities in the system.

[0057] In some examples, the routing rule storage unit can include a tenant hash index table and a tenant rule list library; the tenant hash index table takes a tenant identification as a key and a memory pointer pointing to a corresponding rule set in the tenant rule list library as a value; and the tenant rule list library stores complete rule sets of each tenant, each rule including a path prefix string, a backend service address string, a priority integer value, an enable Boolean flag, and a version long integer identification.

[0058] The embodiment realizes high-precision, low-latency, and strong-isolation dynamic routing function in a multi-tenant environment through the cooperation of the above-mentioned method and system components. The tenant context is established at the request entry, and the routing decision is strictly limited within the tenant-specific rule set, completely eliminating cross-tenant priority conflicts. The two-level matching architecture takes into account efficiency and accuracy, and the prefix tree structure ensures the optimality of the longest matching. The multi-mode tenant identification and hot update mechanism improves the robustness and operability of the system. Finally, the request rejection rate is significantly reduced, the tenant self-configuration capability is fully guaranteed, and the service quality and isolation level of the API gateway meet the industrial requirements.

[0059] The scope of the application is defined by the appended claims rather than by the description preceding it, therefore, all changes that come within the meaning and range of equivalency of the claims are to be embraced by the application. No limitation is intended to the scope of the claims other than that which is described in the claims themselves. Also, it is intended that only security systems means plus function claims recite means plus function limitations. Furthermore, to the extent that "comprising", "including", "carrying", "containing" or like terms are used in the claims, open-ended language is used, and these terms are intended to mean zero or more, unless the context clearly dictates otherwise. Combining the terms "comprising" and "including" is specifically acknowledged to be within the scope of the disclosure. The use of the term "or" in the claims is used to mean "and / or" unless explicitly indicated to refer to alternatives only or the alternative is clear from the context. The use of the term "one" of an element or the "a" or "an" article is not chosen to be limiting, as the disclosure encompasses cases where "one", "a", or "an" means one or more.

[0060] The above description is merely that of specific embodiments of the application, but the protection scope of the application is not limited thereto, and any person skilled in the art can easily make changes or replacements within the technical range disclosed in the application, which should be covered within the protection scope of the application. Therefore, the protection scope of the application should be subject to the protection scope of the claims, and the above examples should be regarded as exemplary and non-limiting.

Claims

1. A method for API gateway to dynamically route backend address, characterized in that, Comprising: receiving an HTTP request from a client, parsing the uniform resource locator and request header information of the HTTP request; extracting a tenant identification field from the request header information; the tenant identification field is a preset standardized header key name, and a value of the tenant identification field is injected by an authentication service when a user logs in and is verified by digital signature; if the request header does not contain a valid tenant identification, a tenant code segment in a domain name part or a path prefix of the uniform resource locator is used for auxiliary derivation, and a derivation rule is pre-stored in a tenant mapping table; according to the determined tenant identification, loading a routing rule set uniquely associated with the tenant from a routing rule storage unit; the routing rule set is organized in a key-value pair form, the key is a path prefix string, and the value is a corresponding backend service address and additional metadata; inside the routing rule set, a local matching sequence is established according to an explicit priority value or a configuration order of each rule; the path part of the uniform resource locator is compared with each path prefix in the local matching sequence, and the longest prefix matching principle is used to determine an optimal matching rule; according to a backend service address associated with the optimal matching rule, the original request is forwarded to a corresponding service instance, and the original request header and path information are transmitted.

2. The method of claim 1, wherein, extracting a tenant identification field from the request header information, comprising: checking whether an X-Tenant-ID field exists in the request header; if the X-Tenant-ID field exists and the value of the field conforms to a pre-defined tenant identification format specification, the X-Tenant-ID field is taken as a valid tenant identification; if the X-Tenant-ID field does not exist or the format is not consistent, a tenant identification is extracted from a subdomain name segment or a path segment of the uniform resource locator in turn, and the extraction process is performed according to a preloaded regular expression template and a tenant mapping table; if all identification modes fail, a 403 Forbidden status code is returned and an audit log is recorded.

3. The method of claim 1, wherein, according to the determined tenant identification, loading a routing rule set uniquely associated with the tenant from a routing rule storage unit, comprising: locating a rule set pointer corresponding to the tenant through a tenant identification hash index table, the tenant identification hash index table taking the tenant identification as a key and taking an in-memory pointer pointing to a rule set in a tenant rule list library as a value; obtaining a reference count of the rule set and incrementing it to prevent being recycled during a hot update process; each rule in the routing rule set includes a path prefix string, a backend service address string, a priority integer value, an enable Boolean flag and a version long integer identification.

4. The method of claim 3, wherein, inside the routing rule set, a local matching sequence is established according to an explicit priority value or a configuration order of each rule, comprising: sorting all rules in the rule set in ascending order of the priority integer value, and the smaller the value, the higher the priority; if the priority is the same, arrange them in the original configuration order; after sorting, generate a rule pointer array as a local matching sequence; during the loading stage, if the path prefix of a high-priority rule completely contains the path prefix of a low-priority rule, trigger a configuration conflict alarm and refuse rule update.

5. The method of claim 1, wherein, The path part of the uniform resource locator is compared with each path prefix in the local matching sequence one by one, and the optimal matching rule is determined by adopting the longest prefix matching principle, comprising: In the rule loading stage, a prefix tree is constructed for the tenant, each path prefix is inserted into the prefix tree character by character, the node at the end of the path is marked as a terminal node and the corresponding rule pointer is stored; When matching, the prefix tree is traversed along the character sequence of the request path, and all the terminal nodes and their path depths that pass through are recorded; After the traversal ends, the rule corresponding to the path depth with the maximum value is selected as the optimal matching rule; If no terminal node is hit, return the 404 Not Found status code.

6. The method of claim 5, wherein, When constructing the prefix tree, each node contains a character child node mapping table, a Boolean flag indicating whether it is a terminal node, a pointer to the matching rule item, and the current node depth value; the path prefix is removed at the end of the slash before being inserted, and nodes are created or reused level by level according to characters.

7. The method of claim 1, wherein, According to the backend service address associated with the optimal matching rule, the original request is forwarded to the corresponding service instance, comprising: Read the complete backend service address from the matching rule, which includes the protocol, host, port, and optional base path; Replace the matching part in the original request path with the concatenation result of the base path and the remaining path; Keep the original request header information and add a standard proxy header field; Perform forwarding through an asynchronous I / O channel, and pass the response data back to the client as is.

8. The method of any one of claims 1 to 7, wherein, The routing rule set supports a hot update mechanism; when a new configuration is received, a new version of the rule set snapshot is generated and a unique version number is assigned; the rule set pointer in the tenant hash index table is updated through an atomic pointer exchange operation; the old version is released by the garbage collection mechanism after the reference count is zero.

9. A system for API gateway dynamic routing of backend addresses, characterized in that, The system for performing the method of any one of claims 1-8 comprises: A request receiving and parsing module for receiving client HTTP requests and parsing uniform resource locators and request headers; A tenant identification extraction module for extracting tenant identification from the request, supporting multi-mode identification and auxiliary derivation; A tenant routing rule loading module for loading the corresponding routing rule set from the routing rule storage unit according to the tenant identification; A local priority sorting module for establishing a matching sequence arranged by priority or configuration order within the tenant rule set; A longest prefix matching module for performing a longest matching algorithm on path prefixes in the matching sequence to determine the optimal routing rule; A request forwarding module for forwarding the request to the target service instance according to the backend address specified by the optimal routing rule.

10. The system for API gateway dynamic routing backend address of claim 9, wherein, The routing rule storage unit includes a tenant hash index table and a tenant rule list library; the tenant hash index table takes the tenant identification as the key and the memory pointer pointing to the corresponding rule set in the tenant rule list library as the value; The tenant rule list library stores the complete rule set of each tenant, and each rule contains a path prefix string, a backend service address string, a priority integer value, an enable Boolean flag, and a version long integer identification.

Images