API gateway multi-service aggregation arrangement method and system based on dynamic rule engine

Abstract

The invention provides an API gateway multi-service aggregation arrangement method and system based on a dynamic rule engine, and relates to the technical field of distributed system architecture.The method comprises the steps that an API gateway layer intercepts a service scene interface calling request initiated by a client side, and the request carries a service scene unique identifier identity certificate and analyzes the service scene unique identifier identity certificate to obtain a request parameter; retrieving a preset aggregation arrangement rule topology from a rule engine through the business scene unique identifier to obtain a target micro-service set; based on the identity credential and the target micro-service set, initiating a token joint request to an authentication center, and obtaining an access token set; and mapping predicate logic according to the request parameter and the target micro-service set parameter, analyzing a client request load through a regular expression engine, and generating a parameter key value pair set for each micro-service. The method is used for solving the problem of poor multi-service dynamic arrangement adaptability in the micro-service architecture.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of distributed system architecture, in particular to an API gateway multi-service aggregation arrangement method and system based on a dynamic rule engine. BACKGROUND

[0002] Under a micro-service architecture, a client often needs to call multiple services to complete a complex business scenario, and a traditional API gateway can realize service aggregation, but has some defects: For example, static arrangement rules cannot adapt to dynamic dependence topology changes, resulting in rigid call links; manually preset fault tolerance strategies lack runtime health sensing capabilities and are difficult to accurately degrade in the event of an exception; the data extraction logic of heterogeneous services is hard-coded and is difficult to flexibly adapt to parameter mapping requirements; global fusing is disconnected from local service states, and resource utilization is low. SUMMARY

[0003] The technical problem to be solved by the application is to provide an API gateway multi-service aggregation arrangement method and system based on a dynamic rule engine, which is used to solve the poor adaptability of multi-service dynamic arrangement in a micro-service architecture.

[0004] To solve the above technical problems, the technical solution of the application is as follows: In a first aspect, an API gateway multi-service aggregation arrangement method based on a dynamic rule engine, the method comprising: Step 1: The API gateway layer intercepts a business scenario interface call request initiated by a client, the request carries a business scenario unique identifier identity credential and the request parameters are parsed; Step 2: Retrieve the preset aggregation arrangement rule topology from the rule engine through the business scenario unique identifier, to obtain a target micro-service set; based on the identity credential and the target micro-service set, initiate a token joint request to the authentication center to obtain an access token set; according to the request parameters and the target micro-service set parameter mapping predicate logic, parse the client request load through the regular expression engine to generate a parameter key-value pair set for each micro-service; Step 3: According to the access token set and the parameter key-value pair set, execute the authorized target micro-service API call through a non-blocking thread pool in parallel, inject a distributed link tracking identifier, and in the call process, real-time collect three indicators of response time percentile, containerized resource quota occupancy rate and state code abnormal distribution rate of each micro-service; Step 4: Construct a service health degree tensor in a Lie group space through the three indicators, calculate the curvature change rate and service health degree entropy increase coefficient of the tensor field according to the covariant derivative; Step 5: Dynamically relax the syntax fault tolerance constraints of the expression according to the entropy increase coefficient, and extract the standardized data tuple; Step 6, input the standardized data tuple into the rule-defined graph-nested operator, generate the canonical aggregated data entity, and return it to the client as a protocol frame.

[0005] Further, the API gateway layer intercepts the business scenario interface call request initiated by the client, which carries the business scenario unique identifier identity credential, and parses the request parameters, including: Step 1.1, capture the client request through the traffic interceptor of the API gateway, extract the business scenario unique identifier and identity credential carried in the request header; Step 1.2, based on the business scenario unique identifier, perform rule matching verification, initiate real-time query to the topology configuration warehouse of the rule engine, calculate the hash matching degree of the identifier and the registered rules, and generate a rule verification pass signal when the matching degree exceeds the preset threshold; Step 1.3, respond to and process the rule verification pass signal, perform request load parsing, call the regular expression engine to scan the original data of the request body, extract the key parameter fragment set from the original data according to the preset parameter template, and inject the key parameter fragment set into the memory cache queue as the final output according to the service dependency order, to obtain the request parameters.

[0006] Further, retrieve the preset aggregation orchestration rule topology from the rule engine through the business scenario unique identifier to obtain the target microservice set; based on the identity credential and the target microservice set, initiate a token federation request to the authentication center to obtain the access token set; according to the request parameter and target microservice set parameter mapping predicate logic, parse the client request load through the regular expression engine to generate parameter key-value pair sets for each microservice, including: Step 2.1, based on the output business scenario unique identifier, calculate its matching degree confidence value with the preset topology in the rule engine, input the identifier into the topology matcher of the rule engine, perform hash space fast retrieval through the Bloom filter, calculate the feature similarity between the identifier and the registered rules using the Levenshtein distance algorithm, and when the similarity exceeds the preset threshold, load the target microservice dependency graph, service call timing constraint matrix, and global timeout fuse threshold vector from the topology configuration warehouse to obtain the target microservice set; Step 2.2, based on the identity credential and the target microservice set, perform dynamic token federation authorization, and through the multi-scope token issuance mechanism of the OAuth protocol, generate a set of access tokens with time-sensitive weight factors; Step 2.3, based on the cached request load data, perform parameter structure conversion, extract the field conversion rules in the predicate logic, match the original parameter key names through the weighted edit distance algorithm, generate standardized key-value pairs through type coercion functions, and output the parameter key-value pair set arranged in service dependency order.

[0007] Further, according to the access token set and the parameter key-value pair set, the authorized target microservice API call is executed concurrently through a non-blocking thread pool, a distributed link tracking identifier is injected, and three indicators, including response time percentile, containerized resource quota occupancy rate and state code abnormal distribution rate, are collected in real time during the call process. Step 3.1, based on the dependency graph parsed from the standardized parameter key-value pair set, a concurrent task scheduling blueprint is constructed, the concurrency degree parameter of the non-blocking thread pool is dynamically calculated according to the number of nodes of the dependency graph, the partial order relation matrix defined by the time sequence constraint is parsed, the topologically sorted task execution sequence is generated, and the thread pool task queue is initialized; Step 3.2, traverse the task queue to execute tracking identifier injection, generate a globally unique distributed tracking identifier for each microservice call task, match and bind the obtained access token set according to the microservice instance, inject TraceID and the corresponding token into the call request header to form an executable call unit; Step 3.3, execute the call unit and collect health indicators in real time, collect three indicators through the performance probe mounted by the container runtime interface, including response time percentile, containerized resource quota occupancy rate and state code abnormal distribution rate.

[0008] Further, through the three indicators, a service health degree tensor in Lie group space is constructed, and the curvature change rate and service health degree entropy increase coefficient of the tensor field are calculated according to the covariant derivative, including: Step 4.1, through the three indicators, perform vector space construction and calculation, perform logarithmic normalization on the response time percentile of each microservice node to eliminate dimensional differences, convert the container resource quota occupancy rate into a complementary residual as a health positive correlation factor, calculate the sliding window weighted average value of the state code abnormal distribution rate to suppress transient fluctuation interference, and output the three-dimensional health degree vector formed; Step 4.2, according to the three-dimensional health degree vector, construct a health degree tensor field in Lie group space, map each microservice node to an independent tangent space coordinate frame of Lie group space; assign the three components of the health degree vector to the covariant components of the tensor respectively, construct the connection coefficient according to the edge weight of the service dependency graph, and describe the curvature correlation strength between nodes; Step 4.3, through the tensor field, perform curvature change rate derivation calculation, calculate the covariant derivative along the tangent vector direction of the service call path, where the tangent vector is determined by the topological sorting of the dependency graph, measure the curvature change through the non-commutativity of the connection coefficient, calculate the Riemann curvature tensor, perform contraction operation on the curvature tensor, and output the scalar curvature change rate; Step 4.4, perform eigenvalue decomposition on the curvature change rate tensor, and take the natural logarithm of the maximum eigenvalue as the entropy increase coefficient.

[0009] Further, the syntax fault-tolerant constraints of the expression are extracted according to the dynamic relaxation of the entropy increase coefficient, and the standardized data tuples are extracted, including: Step 5.1, input the output entropy increase coefficient into the fault-tolerant strategy decision maker of the rule engine, and dynamically generate the syntax relaxation rule; Step 5.2, reconstruct the extraction expression of the microservice response data based on the syntax relaxation rule; Step 5.3, execute the reconstructed expression through the streaming data processor, parse the heterogeneous data returned by the microservice node by node, and output the standardized data tuples conforming to the standard.

[0010] Further, the standardized data tuples are input into the rule-defined graph nesting operator to generate the standardized aggregation data entity and encapsulated as a protocol frame returned to the client, including: Step 6.1, load the standardized data tuples to the graph computing working memory of the rule engine; Step 6.2, based on the data tuples, execute the pre-set graph nesting operator to complete data aggregation, run traversal operation in normal mode in data aggregation, when the detected degradation marker or entropy increase coefficient is greater than the disaster recovery threshold, activate the degradation strategy engine to retrieve the default value configuration template, and inject placeholder values to the missing fields; Step 6.3, generate the aggregation data entity through the entity normalization component, encapsulate the aggregation data entity as a protocol frame, and return to the client through the response channel of the API gateway.

[0011] The second aspect is a multi-service aggregation orchestration method based on a dynamic rule engine API gateway, including: The acquisition module is used for intercepting the business scenario interface call request initiated by the client at the API gateway layer, the request carrying a business scenario unique identifier identity credential and obtaining request parameters through analysis; The analysis module is used for retrieving the pre-set aggregation orchestration rule topology from the rule engine through the business scenario unique identifier, to obtain a target microservice set; based on the identity credential and the target microservice set, a token joint request is initiated to the authentication center to obtain an access token set; according to the request parameter and the target microservice set parameter mapping predicate logic, the client request load is parsed through the regular expression engine to generate a parameter key-value pair set for each microservice; The computing module is used for executing the authorized target micro-service API call, injecting the distributed link tracking identifier, and collecting three indexes of response time delay percentile, containerized resource quota occupancy rate and state code abnormal distribution rate of each micro-service in real time during the call according to the access token set and the parameter key-value pair set through a non-blocking thread pool. The processing module is used for inputting the standardized data tuple into a rule-defined graph nesting operator, generating a standard aggregation data entity and returning the protocol frame to the client.

[0012] In a third aspect, a computing device includes: one or more processors; a memory device storing one or more programs, which when executed by the one or more processors, cause the one or more processors to implement the method.

[0013] In a fourth aspect, a computer-readable storage medium stores a program, which when executed by a processor, implements the method.

[0014] The above scheme of the present application at least has the following beneficial effects: The dynamic rule engine is used to realize flexible adaptation of aggregation arrangement rules, solves the problem of rigid link of traditional API gateway static arrangement, and responds to dynamic changes of business scene dependent topology in real time; the service health degree tensor is constructed based on the Lie group space and the entropy increase coefficient is derived, multi-dimensional indexes such as response time delay, resource occupancy and state code abnormality are fused, accurate quantitative perception of the service health state is realized, real-time dynamic decision basis is provided for the fault-tolerant strategy, and the defect that the artificially preset strategy lacks runtime health perception is overcome; the regular expression engine and the parameter mapping predicate logic are used to realize flexible configuration of heterogeneous service data extraction logic; the entropy increase coefficient is used to drive the dynamic relaxation of the syntax fault-tolerant constraint and the intelligent activation of the degradation strategy. BRIEF DESCRIPTION OF DRAWINGS

[0015] Figure 1 FIG. 1 is a flowchart of an API gateway multi-service aggregation arrangement method based on a dynamic rule engine according to an embodiment of the present application.

[0016] Figure 2 FIG. 2 is a schematic diagram of an API gateway multi-service aggregation arrangement system based on a dynamic rule engine according to an embodiment of the present application. DETAILED DESCRIPTION

[0017] Exemplary embodiments of the present disclosure will be described below in greater detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it is to be understood that the present disclosure can be embodied in various forms without being limited by the embodiments set forth herein. Rather, these embodiments are provided so that the present disclosure will be thoroughly and completely understood, and will fully convey the scope of the present disclosure to those skilled in the art.

[0018] As Figure 1 shown, an embodiment of the present application proposes a dynamic rule engine-based API gateway multi-service aggregation orchestration method, which comprises the following steps: Step 1, the API gateway layer intercepts the service scenario interface call request initiated by the client, which carries the business scenario unique identifier identity credential and parses the request parameters; Step 2, retrieve the pre-set aggregation orchestration rule topology from the rule engine through the business scenario unique identifier to obtain the target micro-service set; based on the identity credential and the target micro-service set, initiate a token joint request to the authentication center to obtain an access token set; according to the request parameters and the target micro-service set parameter mapping predicate logic, parse the client request load through the regular expression engine to generate a parameter key-value pair set for each micro-service; Step 3, according to the access token set and the parameter key-value pair set, execute the authorized target micro-service API call through a non-blocking thread pool, inject a distributed link tracking identifier, and in the calling process, real-time collect three indicators of response delay percentile, containerized resource quota occupancy rate and state code abnormal distribution rate of each micro-service; Step 4, based on the three indicators, construct a service health degree tensor in the Lie group space, calculate the curvature change rate and service health degree entropy increase coefficient of the tensor field through the covariant derivative; Step 5, dynamically relax the syntax fault tolerance constraints of the expression according to the entropy increase coefficient, and extract the standardization data tuple; Step 6, input the standardized data tuple into the rule-defined graph nesting operator to generate a standard aggregation data entity and encapsulate it as a protocol frame returned to the client.

[0019] In the embodiment of the application, the request is dynamically intercepted and parsed through the API gateway layer, the rule engine is combined to flexibly retrieve and aggregate the arrangement rule topology, the dynamic adaptation of service dependence and calling sequence is realized, and the limitation of traditional static arrangement link rigidity is broken through; with the help of non-blocking thread pool, micro services are called in parallel and multi-dimensional health indicators are collected, and the calling efficiency and observability are improved by combining with distributed link tracking; the Lee group space health degree tensor construction and entropy increase coefficient calculation are innovatively introduced, the response time, resource occupation, state code anomaly and other indicators are fused to realize the accurate quantification of service health status, and real-time dynamic basis is provided for fault tolerance strategy; the syntax fault tolerance constraint dynamic relaxation and degradation strategy intelligent activation are driven by the entropy increase coefficient, the system abnormal elasticity is enhanced while the data aggregation specification is ensured.

[0020] In a preferred embodiment of the application, the above step 1 can include: Step 1.1, capturing the client request through the traffic interceptor of the API gateway, and extracting the business scenario unique identifier and identity credentials carried in the request header; Step 1.2, based on the business scenario unique identifier, performing rule matching verification, initiating real-time query to the topology configuration warehouse of the rule engine, calculating the hash matching degree of the identifier and the registered rule, and generating a rule verification pass signal when the matching degree exceeds the preset threshold; Step 1.3, responding to and processing the rule verification pass signal, performing request load analysis, calling the regular expression engine to scan the original data of the request body, extracting the key parameter fragment set from the original data according to the preset parameter template, and injecting the key parameter fragment set into the memory cache queue as the final output according to the service dependence order, to obtain the request parameters.

[0021] In the embodiment of the application, the request preprocessing is accurate and efficient through hierarchical processing, the request is accurately captured and the key identifier is extracted through the traffic interceptor, which provides a basis for subsequent rule matching and authorization, and ensures that the request source is traceable; through hash matching degree calculation and threshold verification, invalid or unmatched requests are filtered, the heterogeneous request load is flexibly parsed by using the regular expression engine, the key parameters are extracted according to the preset template and cached according to the service dependence order, and the structure and specification of parameter extraction are ensured.

[0022] In the embodiment of the application, the specific steps include: Step 1.1, capturing the client request through the traffic interceptor of the API gateway, and extracting the business scenario unique identifier and identity credentials carried in the request header.

[0023] Step 1.2 involves performing hash operations on the unique identifier for the business scenario and the rules registered in the rule engine. The purpose is to convert the original string (or identifier) ​​into a fixed-length binary hash value, eliminating differences in the original data format. The SHA-256 algorithm is typically used, converting an input of arbitrary length into a 256-bit (32-byte) binary hash value (e.g., 10110011...0110, a total of 256 bits). For example, assuming the unique identifier for the business scenario is the string "order_payment_v2", after SHA-256 hashing, it yields a 256-bit binary value H1=b1b2...b256 (b1 to b256 are either 0 or 1). A registered rule in the rule engine is identified as "order_payment_v1", and after hashing, it yields a 256-bit binary value H2=c1c2...c256. The matching degree between the identifier's hash value and the hash value of each rule is calculated (e.g., the proportion of identical binary bits in the two hash values ​​out of the total number of bits). This proportion is the hash matching degree. A preset matching degree threshold is set (e.g., 80%, which can be adjusted according to business accuracy requirements). If the calculated hash matching degree exceeds this threshold, the rule is considered to have matched successfully, and a rule verification pass signal is generated. For example, if the preset threshold is 80%, and in the above example 79.69% < 80%, the match fails, and no pass signal is generated; if the hash value of another rule has 205 identical bits with H1, the matching degree = 205 ÷ 256 ≈ 80.08% > 80%, and a pass signal is generated.

[0024] Step 1.3: Once the rule verification signal is received, the system will immediately respond to this signal, triggering the request load parsing start command, essentially a green light indicating the start of data extraction. At this point, the API gateway will pass the raw load data of the client request (which may be a string in JSON, form, XML, or other formats) to a dedicated parsing module for parameter extraction. The parsing module will call the regular expression engine, using a pre-defined parameter template (pre-defined parameter extraction rules) to scan the raw load data character by character. First, based on the definition of parameter location in the template (such as in the phone field of the form within the user object in the request body), locate the area in the original data that may contain the target parameter; then, based on the definition of format characteristics in the template (such as an 8-12 digit order number starting with ORD-), use regular expressions to match the content of that area. For example, if the template requires user_id to be an 8-digit number, the engine will scan the corresponding position for content that matches the format, and mark it as a candidate parameter if it does.

[0025] After the regular expression engine finishes scanning, it extracts all candidate parameters from the original data and performs secondary validation: it checks whether each candidate parameter fully conforms to the template rules (e.g., whether the length is within the specified range and whether the format is correct); it filters out invalid data that does not conform to the rules (e.g., parameters with incorrect format or fragments with incorrect position), retains valid parameters, and forms a set of key parameter fragments.

[0026] In a preferred embodiment of the present invention, step 2 above may include: Step 2.1: Based on the output unique identifier for the business scenario, calculate the matching confidence value between it and the preset topology in the rule engine. Input the identifier into the topology matcher of the rule engine, perform fast hash space retrieval through a Bloom filter, and use the Levenshtein distance algorithm to calculate the feature similarity between the identifier and the registration rule. When the similarity exceeds the preset threshold, load the target microservice dependency graph, service call timing constraint matrix and global timeout circuit breaker threshold vector from the topology configuration repository to obtain the target microservice set. Step 2.2: Based on the identity credentials and the target microservice set, perform dynamic token federated authorization. Through the multi-scope token issuance mechanism of the OAuth protocol, generate a batch of access token sets with time-sensitive weight factors. Step 2.3: Based on the cached request load data, perform parameter structure transformation, extract field transformation rules from the predicate logic, match the original parameter key names using a weighted edit distance algorithm, generate standardized key-value pairs using a type casting function, and output a set of parameter key-value pairs arranged in the order of service dependencies.

[0027] In this embodiment of the invention, service aggregation and orchestration are made more precise and efficient through hierarchical optimization. A Bloom filter enables fast hash space retrieval, and the Levenshtein distance algorithm is used to calculate feature similarity, improving the efficiency of topology matching. Similarity threshold filtering ensures the accuracy of rule matching. By constructing a joint authorization request based on the hash digest of a microservice set, and utilizing the OAuth multi-scope token mechanism to generate access tokens with time-sensitive weights in batches, the centralized authorization requirements in multi-service scenarios are adapted. The time-sensitive weight factor enhances the security and dynamic management capabilities of the tokens, while the Cartesian product permission identifier ensures the precise correspondence between permissions and services. The load is parsed based on a deterministic finite automaton, and the weighted edit distance algorithm is used to match parameter key names and generate standardized key-value pairs.

[0028] In this embodiment of the invention, the specific steps include: Step 2.1: Based on the output unique identifier for the business scenario, the Bloom filter will use k different hash functions (k is a preset value, such as 3) to calculate the unique identifier for the business scenario and generate k integer hash values.

[0029] The function of a hash function is to convert the original identifier (such as the string "order_payment_v2") into a randomly distributed integer (hash value). A Bloom filter has a bit array of length m (composed of 0s and 1s, for example, length m=5000), and needs to convert the k hash values ​​obtained in the first step into k index positions in the array (i.e., the nth position in the array).

[0030] Apply k hash functions to the unique identifier of the business scenario to generate k integer hash values.

[0031] Example: Suppose k=3, bit array length m=1000, and identifier is "order_payment_v2".

[0032] The hash value calculated by hash1() is h1=2567; the hash value calculated by hash2() is h2=1892. The hash value h3 is calculated as 3409 using hash3().

[0033] Perform a modulo operation of "hash value % bit array length m" on each hash value to obtain the index position in the bit array (range: 0~m-1).

[0034] Calculation process: Index 1 = h1%m = 2567%1000 = 567 (2567 divided by 1000 leaves a remainder of 567). index2 = h2%m = 1892%1000 = 892; Index 3 = h3%m = 3409%1000 = 409.

[0035] The calculated index positions (e.g., 567, 892, 409) are used to label the bit array of the Bloom filter: When inserting a rule: set the bit value of these k index positions to 1 (indicating that the rule has been registered); When retrieving rules: check if all the bit values ​​at these k index positions are 1; if all are 1, it means the rule "may exist" (there is a probability of hash collision); if any one of them is 0, it means the rule "definitely does not exist".

[0036] For candidate rules selected by the Bloom filter, the edit distance between the identifier and the rule feature string is calculated, and the minimum number of single-character edit operations (insertion, deletion, replacement) required to convert the source string into the target string is calculated. The calculated similarity value is compared with a preset threshold (e.g., 0.7). If the similarity exceeds the threshold, the associated configuration data is loaded from the topology configuration repository as the target microservice dependency graph (stored in the form of a directed acyclic graph DAG), the service call timing constraint matrix (a two-dimensional matrix that defines the call order relationship between services), and the global timeout circuit breaker threshold vector (a one-dimensional array, where each element corresponds to the timeout limit of a microservice).

[0037] Step 2.2: Perform a hash operation on each service ID in the target microservice set. Sort all the generated hash values ​​lexicographically, concatenate them into a string, and then perform another hash operation on the concatenated string to generate a hash digest of the set, thus defining two basic sets: Set A (User Identity Credentials Set): Contains only the user's unique identifier (such as the unique ID of a JWT token), and is usually a single-element set.

[0038] Example: A={"user_12345"} (assuming the unique identifier of the user's identity credentials is user_12345).

[0039] Set B (target microservice set): contains the unique IDs of all microservices that need to be accessed.

[0040] Example: B={"service_payment","service_order","service_user"} (representing payment service, order service, and user service respectively).

[0041] Perform a Cartesian product operation to generate all possible ordered pairs. The core of the Cartesian product is to combine each element in set A with each element in set B to form a new ordered tuple. The tuple format is fixed as (element of set A, element of set B), i.e., (identity credential ID, service ID). Submit a federated authorization request to the authentication center, including the user's identity credential (original JWT token), the hash digest of the microservice set, and the Cartesian product permission identifier set. After the authentication center verifies the request, it generates a separate access token for each service through OAuth 2.0's multi-scope token mechanism and adds a time-sensitivity weight factor to each token, which is the current timestamp divided by the token's expiration timestamp (the value ranges from 0 to 1, with values ​​closer to 1 indicating that the token is closer to expiration). This weight factor is used to dynamically adjust the token's priority and resource access permissions.

[0042] Step 2.3: Input the cached original request payload into the deterministic finite automaton (DFA) of the regular expression engine. The DFA performs state transitions according to the preset regular expression pattern, identifies and extracts matching parameter fragments, generates a set of original parameter key-value pairs, extracts the target field transformation rules from the parameter mapping predicate logic for each microservice node, calculates the weighted edit distance between the original parameter key name and the target key name, and selects the matching result with the smallest weighted edit distance as the final mapping.

[0043] Based on the target data type (such as int, float, timestamp) defined by the field conversion rules, apply type conversion functions to standardize the format, such as converting a string to an integer (original value) and a timestamp to a timestamp (original value, format template). Record type conversion error logs (including original value, target type, and error information). Select to apply default values, skip the field, or terminate the processing flow according to the configuration strategy. Based on the topological sorting result of the microservice dependency graph, rearrange the generated standardized key-value pairs according to the service call order to obtain the parameter key-value pair set.

[0044] In a preferred embodiment of the present invention, step 3 above may include: Step 3.1: Based on the dependency graph parsed from the standardized parameter key-value pair set, construct a concurrent task scheduling blueprint, dynamically calculate the concurrency parameter of the non-blocking thread pool according to the number of nodes in the dependency graph, parse the partial order relation matrix defined by the timing constraint, generate a topologically sorted task execution sequence, and initialize the thread pool task queue. Step 3.2: Traverse the task queue and perform trace identifier injection. Generate a globally unique distributed trace identifier for each microservice call task. Match and bind the obtained access token set according to the microservice instance. Inject TraceID and corresponding token into the call request header to form an executable call unit. Step 3.3: Execute the calling unit and collect health indicators in real time. Collect third-order indicators through the performance probe mounted on the container runtime interface. The third-order indicators include response latency percentile, containerized resource quota utilization rate, and status code anomaly distribution rate.

[0045] In this embodiment of the invention, by dynamically constructing a concurrent task scheduling blueprint that adapts to the dependency graph, the thread pool concurrency is flexibly adjusted according to the number of nodes and the execution sequence is generated by combining topological sorting, which avoids the waste of thread resources and ensures that service calls comply with timing constraints. By injecting a globally unique distributed tracing identifier and binding an access token, the security of call authorization is guaranteed, providing a basis for problem localization and link analysis. The performance probe of the container runtime interface is used to collect three-level indicators in real time: response latency percentile, resource quota utilization rate, and status code anomaly distribution rate.

[0046] In this embodiment of the invention, the specific steps include: Step 3.1, First step: Select all microservices from the parameters (determine the nodes): In the standardized set of parameter key-value pairs, each parameter is associated with a corresponding microservice (e.g., the parameter `user_info` corresponds to the user service, and `order_detail` corresponds to the order service). First, extract the unique identifiers (such as service ID and service name) of all microservices from the parameter key-value pairs. These unique identifiers are the nodes in the dependency graph. Count the number of nodes to obtain the total number of microservices, N.

[0047] Step 2: Identify the dependencies between services from the parameters (determine the connections): Each microservice's parameter key-value pairs implicitly contain dependency information on other services. For example, the order service's parameter user_id requires the result returned by the user service, indicating that the order service depends on the user service.

[0048] Specifically, dependencies are identified through the following information: Parameter source tag: Parameter key-value pairs may contain a dependent service ID field. For example, the parameter user_id of the order service will be marked with the source service: user_service, which directly indicates the dependency relationship. Parameter generation order: Standardized parameters are cached in the order of service dependencies (as mentioned in step 1.3). For example, the parameter order is user_service parameters → order_service parameters → payment_service parameters, which means that the calling order is user service → order service → payment service. That is, the order service depends on the user service, and the payment service depends on the order service. The standardized parameter key-value pair set is generated based on the aggregation and orchestration rules of the rule engine (as mentioned in step 2.1, the dependency graph is loaded). When extracting, the rules will refer to constraints such as service A must call service C before service B and depend on the output of service A to supplement the dependency relationship.

[0049] Step 3: Organize the dependency graph into a directed graph form: Combine the nodes (microservices) from step one and the dependencies (who depends on whom) from step two to form a directed graph, where each node represents a microservice. Connect the nodes with arrowed lines (edges), and the direction of the arrows indicates the direction of dependency (e.g., an arrow pointing from the user service to the order service indicates that the order service depends on the user service). Calculate the optimal concurrency parameter for the non-blocking thread pool: the optimal concurrency parameter equals the smaller value between the number of CPU cores multiplied by the blocking coefficient and the total number of microservices N, where the blocking coefficient is dynamically adjusted based on the I / O intensity of the service.

[0050] The partial order relation matrix (denoted as M) is extracted from the loaded timing constraint definition. The element in the i-th row and j-th column of the matrix means that if the element value is 1, it means that service i must be called before service j; if the element value is 0, it means that there is no mandatory call order constraint between service i and service j. Based on the microservice dependency graph and the partial order relation matrix, the Kahn algorithm is used to generate the topological sorting sequence of service calls. For example, an empty queue and an empty result list are initialized. All nodes with an in-degree of 0 (services without prerequisite dependencies) are added to the queue. The following operations are performed in a loop: a node is taken from the queue and added to the result list; all outgoing edges of the node are removed (the node's dependency association with subsequent services is removed); the in-degree of related nodes is updated; if the in-degree of a node becomes 0 after the update, it is added to the queue. The final result list is the topological sorting execution sequence that meets the timing constraints. A thread pool with a fixed size is created with the calculated optimal concurrency parameter. According to the topological sorting sequence, the service call tasks are added to the task queue of the thread pool in sequence. The information contained in each task is the unique identifier of the target microservice, the corresponding set of standardized parameter key-value pairs, and the list of prerequisite services that the service depends on.

[0051] Step 3.2: Generate a globally unique trace ID for each microservice call task. The UUIDv1 algorithm is used to generate this ID, ensuring its uniqueness within the distributed system. Based on the target microservice ID for each task, match the corresponding access token from the obtained access token set. A mapping is established between each task's unique ID, the corresponding global trace ID, and the access token. Construct an HTTP request header for each task, including the key fields: the X-Trace-ID field filled with the global trace ID; and the Authorization field filled with the matched access token. Integrate these to form an executable call unit, containing the target microservice's request URL, request method (e.g., GET / POST), constructed request headers, and the corresponding request body.

[0052] Step 3.3: Obtain the calling unit from the task queue in the thread pool and execute the microservice call. Record the start time and end time of each call. Calculate the response time of each call. The response time is equal to the end time minus the start time. Arrange all response times in ascending order to form an ordered array. Calculate the response latency of a specified percentile (e.g., the 50th percentile, 95th percentile, 99th percentile). The response latency of a certain percentile is equal to the percentile value multiplied by (array length minus 1) and the result is taken as an integer. Then, take the response time value at the corresponding position in the ordered array.

[0053] The following resource usage metrics are collected through performance probes mounted via container runtime interfaces (such as Docker and Kubernetes interfaces): CPU utilization is the percentage obtained by dividing the used CPU time by the total CPU time and then multiplying by 100%; memory utilization is the percentage obtained by dividing the used memory amount by the total allocated memory quota and then multiplying by 100%; and network bandwidth utilization is the percentage obtained by dividing the used network bandwidth by the total limited bandwidth and then multiplying by 100%.

[0054] Collect all HTTP status codes returned by microservice calls, calculate the distribution rate of each type of status code. The distribution rate of a certain type of status code is equal to the number of times that status code appears divided by the total number of calls, and then multiplied by 100% to get the percentage. Define the range of abnormal status codes (such as client error status codes in the range of 400-499, server error status codes in the range of 500-599), calculate the abnormal distribution rate, which is equal to the total number of times abnormal status codes appear divided by the total number of calls, and then multiplied by 100% to get the percentage.

[0055] In a preferred embodiment of the present invention, step 4 above may include: Step 4.1: Based on the three indicators, perform vector space construction calculation, log normalize the percentile of response latency of each microservice node to eliminate the difference in units, convert the container resource quota occupancy rate into complementary surplus as a positive correlation factor for health, calculate the sliding window weighted average of the abnormal distribution rate of status codes, suppress instantaneous fluctuation interference, and output the constructed three-dimensional health vector. Step 4.2: Based on the three-dimensional health vector formed by the output, construct a health tensor field in the Lie group space, and map each microservice node to an independent tangent space coordinate frame of the Lie group space; assign the three components of the health vector to the covariant components of the tensor respectively, and reconstruct the connection coefficients based on the edge weights of the service dependency graph to describe the curvature correlation strength between nodes. Step 4.3: Based on the constructed tensor field, perform curvature change rate derivation calculation, calculate the covariant derivative along the tangent vector direction of the service call path, where the tangent vector is determined by the topological sorting of the dependency graph, calculate the Riemann curvature tensor by measuring curvature change through the noncommutativity of the connection coefficient, perform a contraction operation on the curvature tensor, and output the scalar curvature change rate. Step 4.4: Perform eigenvalue decomposition on the rate of curvature tensor and take the natural logarithm of the largest eigenvalue as the entropy increase coefficient.

[0056] In this embodiment of the invention, a three-dimensional health vector is generated by standardizing three indicators: response latency, resource usage, and abnormal distribution (logarithmic normalization to eliminate dimensions, conversion of remaining resource quantity to strengthen positive correlation, and sliding window weighted averaging to suppress fluctuations). Microservice nodes are mapped to a Lie group space to construct a health tensor field, and the strength of health associations between services is characterized by covariant components and connection coefficients. The rate of curvature change is calculated using covariant derivatives and the Riemann curvature tensor, and differential geometry tools are used to quantify the dynamic trend of service health status. Finally, the natural logarithm, the largest eigenvalue of the rate of curvature change tensor, is used as the entropy increase coefficient, condensing multidimensional health status changes into a single comparable quantitative indicator.

[0057] In this embodiment of the invention, the specific steps include: Step 4.1: Perform a natural logarithmic operation on the percentile of response latency (e.g., P95 latency) of each microservice node to obtain a logarithmic latency value. Normalize the logarithmic latency value and convert the container resource quota occupancy rate into complementary surplus. Calculate the complementary surplus of container resource quota (convert the occupancy rate, which is negatively correlated with health, into a positively correlated surplus; the larger the value, the more abundant the resources).

[0058] A sliding window is defined (e.g., including the most recent 10 call records). The anomaly distribution rate at each time point within the window is weighted according to time (the anomaly rate closer to the current time has a higher weight, and the sum of the weights for all time points is 1). A weighted average is calculated (weighted smoothing eliminates the interference of instantaneous fluctuations on the anomaly rate). The three-dimensional health vector of each microservice node consists of the following three components (normalized latency, remaining resource amount, and sliding window weighted anomaly rate).

[0059] Step 4.2: Map each microservice node to an independent tangent space (local coordinate system) in the Lie group space. Each tangent space is equipped with a dedicated coordinate frame (basis vector). The three components of the three-dimensional health vector correspond to the three covariant components of the tensor. The normalized latency corresponds to the first covariant component of the tensor, the remaining resource corresponds to the second covariant component of the tensor, and the sliding window weighted anomaly rate corresponds to the third covariant component of the tensor (the component value is the projection value of the vector on the local coordinate frame).

[0060] Based on the weights of the edges in the microservice dependency graph (the larger the weight, the stronger the inter-service dependency), a connection coefficient is constructed. The connection coefficient is used to describe the association between different slicing spaces. The larger the value, the stronger the association between the health status of two microservice nodes.

[0061] Step 4.3: Along the tangent vector direction of the service call path (the tangent vector is determined by the topological sorting of the dependency graph, following the order of calls), calculate the covariant derivative of the health tensor field. The covariant derivative equals the ordinary derivative of the tensor with respect to the path parameters plus the connection coefficient multiplied by the tensor component (the connection coefficient reflects the influence of different tangent spaces on the derivative). The connection coefficient can be understood as the elasticity of the network, describing the degree of stretching or distortion of the network when moving from one node (service) to another. Non-commutativity means that the deformation of the network is different when taking two different routes (call order). For example, calling service A first and then service B may result in different changes in the final service health status (such as response speed and resource consumption) compared to calling service B first and then service A. The phenomenon that the order affects the result reflects the complexity of service dependencies (such as the existence of circular dependencies and cross dependencies).

[0062] The Riemann curvature tensor is used to measure the degree of wrinkling in a network. Specifically, it measures the degree of twisting (or deviation in node states) of the network as it travels along a very small closed path (e.g., A→B→C→A) from a single node. The calculation is broken down into two steps: First, examine the change in network cable elasticity with the route (partial derivative of the connection coefficient), for example, whether the elasticity from A to B changes symmetrically with the elasticity from B to A. Next, examine the mutual influence of the elasticity of different routes (the product of the connection coefficients), for example, how the elasticity from A to B affects the elasticity from B to C, and how much the overall distortion is after superposition.

[0063] The resulting curvature tensor essentially describes the differences in wrinkles in different directions of the network. The more pronounced the wrinkles in a certain direction, the more likely the service dependencies in that direction are to cause fluctuations in health status. The curvature tensor is a complex multidimensional data set (similar to describing wrinkles in multiple directions such as x, y, and z of a network), making it difficult to directly judge the overall state using a single indicator. The contraction operation simplifies the multidimensional wrinkles into an intuitive wrinkle index, a process involving two steps: The first step is to merge: This is equivalent to merging folds in multiple directions into the main fold direction. For example, ignoring minor folds and only keeping the most influential ones. The second step is to shrink the network (to obtain the scalar curvature): The main wrinkle directions are weighted using the mesh thickness (the strength of the service dependency, which is a metric tensor), and finally merged into a single number, which is the overall wrinkle index (scalar curvature). For example: A positive index indicates that there are tangled parts in the network (such as loop calls), which can easily become more and more tangled and lead to breakage (cascade failure). A negative index indicates that the network is relatively loose, with few wrinkles and is flexible (a problem with a certain service will have a small impact). An index of zero indicates that the network is flat, the service dependencies are simple, and the state is stable.

[0064] Finally, calculate the change in the wrinkle index over time (e.g., the change per second): a fast change (large rate value) indicates that the wrinkles in the network are becoming more severe rapidly. The network was relatively flat just now, but suddenly it twists into a ball, indicating that the service network is about to have a problem; a slow change (small rate value) indicates that the wrinkles in the network are changing gently and the service status is stable.

[0065] Step 4.4: The scalar curvature rate of change tensor is a multi-dimensional data volume describing changes in service health status, like a multi-directional force field. Each direction represents a service dependency path (e.g., a call chain A→B→C, a call chain A→D, etc.), and the intensity in each direction represents the magnitude of health status changes along that path (e.g., latency fluctuations, resource usage fluctuations). Eigenvalue decomposition breaks down this complex force field, yielding two sets of results: Feature vector: Each feature vector corresponds to a service dependency path (direction of change); Eigenvalue: Each eigenvalue corresponds to the intensity of change along the eigenvector direction (the larger the value, the more drastic the change in health status along the path).

[0066] For example, after decomposition, three feature values ​​are obtained: 5.2, 2.1, and 0.8. The intensity of health status changes on three different service dependency paths are 5.2, 2.1, and 0.8, respectively, with the first path showing the most significant change. From all the feature values ​​obtained from the decomposition, the one with the largest value is selected. The largest value represents the path that has the greatest impact on the overall change in service health status. For example, in the above example, the largest feature value is 5.2, and the corresponding path is the dependency chain in the current service network where the health status change is most drastic.

[0067] The largest selected eigenvalue is subjected to a natural logarithm (e.g., ln(5.2)≈1.65 for 5.2), and the result is the entropy increase coefficient. The natural logarithm can compress very large eigenvalues ​​(e.g., 100) into a more comparable range (ln(100)≈4.6), while preserving the trend that the larger the value, the more drastic the change; entropy represents the degree of disorder in physics, and the result of the natural logarithm can better reflect the relationship between the degree of disorder and the intensity of change. The larger the eigenvalue (the more drastic the change), the larger the logarithmic result (entropy increase coefficient), which means that the disorder of the service health state increases faster.

[0068] In a preferred embodiment of the present invention, step 5 above may include: Step 5.1: Input the output entropy increase coefficient into the fault tolerance strategy decision maker of the rule engine to dynamically generate syntax relaxation rules; Step 5.2: Based on the syntax relaxation rules, reconstruct the extraction expression for microservice response data; Step 5.3: Execute the reconstructed expression through the streaming data processor, parse the heterogeneous data returned by the microservice node by node, and output standardized data tuples that conform to the standard.

[0069] In this embodiment of the invention, by using the entropy increase coefficient as a dynamic input to drive the generation of syntax relaxation rules, the fault tolerance strategy can adapt to the service health status in real time (the higher the entropy increase, the looser the syntax constraints), overcoming the limitation that static fault tolerance rules are difficult to cope with complex fluctuations; based on the dynamic rule reconstruction of the extracted expression, it can flexibly adapt to the heterogeneous data format returned by the microservice (such as missing fields, format deviation), avoiding the problem of parsing failure of fixed expressions when the data format changes.

[0070] In this embodiment of the invention, the specific steps include: Step 5.1: Input the output entropy increase coefficient into the fault tolerance strategy decision maker of the rule engine to establish a mapping relationship between the entropy increase coefficient and the degree of syntax relaxation. The larger the entropy increase coefficient, the faster the disorder of the service health status increases. In actual data, this means that the response data returned by the microservice may become increasingly non-standard (e.g., missing fields, incorrect format, incorrect type, etc.). The relaxation factor is obtained by establishing a dynamic mapping relationship between the entropy increase coefficient and the degree of syntax relaxation. The value of the relaxation factor is the result of a monotonically increasing function, which takes the entropy increase coefficient as input. For example, the relaxation factor is equal to the smaller value between 1 and the adjustment coefficient multiplied by the entropy increase coefficient (when the result of the adjustment coefficient multiplied by the entropy increase coefficient is greater than 1, the relaxation factor is 1; otherwise, the result of the adjustment coefficient multiplied by the entropy increase coefficient is taken).

[0071] Multiple syntax constraint parameters are dynamically adjusted based on the relaxation factor: field matching tolerance (the maximum edit distance allowed between the field name and the standard format); data type tolerance (the allowed range of data type conversions); null value tolerance (the maximum proportion of null value fields allowed out of the total number of fields); and field missing tolerance (the maximum number of missing non-critical fields allowed). The weight of each rule is equal to the weight calculated based on the relaxation factor and the rule type (for example, the weight of a field matching rule decreases as the relaxation factor increases to improve matching flexibility).

[0072] Step 5.2: Parse the original extraction expression of the microservice response data, extracting key elements from the expression, including: the path of the target field, the data type constraints of the field (e.g., must be an integer), and the conditional matching predicate (e.g., equal to or greater than). Based on the generated syntax relaxation rules, adjust the original extraction expression by adding wildcards to the field path (e.g., matching any field name), allowing deviations from non-critical nodes in the path; adjusting strict single-type checks to type family matching (e.g., allowing conversions between numeric and string types, and between date and timestamp strings); and reducing the strictness of conditional judgments (e.g., adjusting exact equal to include, and strict greater than to greater than or equal to).

[0073] Verify that the adjusted expression meets the minimum matching requirements (e.g., it can match at least 80% of the standard fields), merge duplicate matching conditions, and eliminate conflicting rules (e.g., when there are rules that must include field A and rules that allow missing field A, retain the rules that conform to the current relaxation factor).

[0074] Step 5.3: Configure the streaming data processor, set core parameters, input data format (supports heterogeneous formats such as JSON, XML, and CSV), output the standard structure of data tuples (including field names, data types, and required / optional constraints), read each node in the microservice response data in the order of the data flow, apply the refactored extraction expression for matching and processing, if the node matches the main path of the expression, extract and record the corresponding field value; if the node does not match the main path but conforms to the syntax relaxation rules, trigger fault tolerance processing (such as performing type conversion and filling preset default values), perform standardization operations on the extracted raw data, uniformly convert heterogeneous data types to the target type (such as converting string numbers to integers); unify the format of dates (such as yyyy-MM-dd), numbers (such as retaining two decimal places), etc. Check if the field values ​​are within the preset range, correct (e.g., truncate to the maximum value) or filter out values ​​that are out of range (skip after logging the exception), assemble all processed field values ​​into standardized data tuples according to the preset standard structure, and attach metadata to the tuples, including data processing time, microservice identifier of the data source, and confidence of field matching (which decreases as the matching strictness decreases).

[0075] In a preferred embodiment of the present invention, step 6 above may include: Step 6.1: Load the standardized data tuples into the graph computation working memory of the rule engine; Step 6.2: Based on the data tuple, execute the preset graph nesting operator to complete the data aggregation. In the normal mode of data aggregation, run the traversal operation. When the detected degradation mark or entropy increase coefficient is greater than the disaster recovery threshold, activate the degradation strategy engine to retrieve the default value configuration template and inject placeholder values ​​into the missing fields. Step 6.3: Generate aggregated data entities through the entity normalization component, encapsulate the aggregated data entities into protocol frames, and return them to the client through the API gateway's response channel.

[0076] In this embodiment of the invention, by loading standardized data tuples into the graph computing working memory, fast response of aggregation operations is ensured; when executing preset graph nested operators to realize data aggregation, degradation strategies are dynamically activated by combining degradation flags and entropy increase coefficients; when service is abnormal (such as entropy increase exceeding limits), default values ​​are injected to ensure aggregation continuity and avoid overall aggregation failure due to missing local fields; nested fields are structured with the help of entity normalization components and attached with full-link tracking metadata; finally, the aggregated entity is encapsulated into a protocol frame and returned to ensure that the response meets the client protocol requirements.

[0077] In this embodiment of the invention, the specific steps include: Step 6.1: Load the output standardized data tuples into the graph computing working memory of the rule engine. Group the standardized data tuples according to the unique identifier of the microservice node and establish a mapping relationship between the node unique identifier and the corresponding tuple list. Allocate an independent memory address index for each data tuple and associate it with the node data structure in the graph computing engine (this structure contains node attribute information and pointers to associated edges). Initialize the memory cache and set the data expiration time (consistent with the timeout threshold of the service call) to prevent memory overflow.

[0078] Step 6.2: Based on the data tuples, execute the pre-defined graph nesting operator. According to the topological sorting order of the microservice dependency graph, traverse the data tuples in the working memory. Starting from the starting node of the dependency graph, merge the tuple fields of the associated nodes layer by layer (for example, associate and nest the user unique identifier of service A with the order details of service B according to the identifier). Retain the key fields in each node tuple and remove redundant and duplicate fields (for example, the timestamp field contained in multiple nodes is retained only from the source node).

[0079] The system monitors in real time whether two degradation trigger conditions exist and whether the entropy increase coefficient is greater than the preset disaster recovery threshold. If a degradation marker exists or the entropy increase coefficient is greater than the disaster recovery threshold, degradation processing is triggered, the degradation strategy engine is activated, and the default value configuration template is retrieved (the template contains preset placeholder values ​​for different types of fields, such as 0 for numeric fields, N / A for string fields, and 1970-01-01 for date fields). For fields that are missing due to service exceptions during the aggregation process, the corresponding placeholder values ​​are injected according to the template to ensure the integrity of the aggregated data structure.

[0080] Step 6.3: Using the entity normalization component, the aggregated flat data is reconstructed into a nested structure according to the business logic hierarchy (e.g., constructing a multi-level nested structure of user basic information → associated order list → product details included in the order), and the naming format of fields is unified (e.g., using camelCase and converting user_name to userName) and data type (e.g., converting transaction amount to Decimal type and retaining two decimal places).

[0081] Add end-to-end tracing related fields to the aggregated data entity, including those consistent with the distributed tracing identifier generated in step 3.2; record the start and end times of each microservice call; the execution time of the current step from start to finish; and mark it as true if degradation processing is triggered, and as false if it is not triggered.

[0082] Step 6.4: Based on the protocol type of the client request (e.g., HTTP / 2, gRPC), encapsulate the aggregated data entity into a protocol frame corresponding to the protocol: If using the HTTP / 2 protocol, convert the aggregated data entity into a JSON or XML response body and set the response header information (including the Content-Type field specifying the data format and the X-Trace-ID field carrying the global trace identifier). If it is a gRPC protocol, the aggregated data entity is serialized into Protocol Buffers binary format, associated with the corresponding service method metadata (such as method name and version number), the checksum of the aggregated data entity is calculated, and the checksum is appended to the end of the protocol frame for the client to verify data integrity.

[0083] like Figure 2 As shown, embodiments of the present invention also provide an API gateway multi-service aggregation and orchestration system based on a dynamic rule engine, comprising: The acquisition module is used by the API gateway layer to intercept business scenario interface call requests initiated by the client. The request carries a unique identifier identity credential for the business scenario and is parsed to obtain the request parameters. The analysis module is used to retrieve the pre-set aggregation orchestration rule topology from the rule engine using a unique identifier for the business scenario to obtain the target microservice set; based on the identity credentials and the target microservice set, it initiates a token federation request to the authentication center to obtain the access token set; according to the request parameters and the parameter mapping predicate logic of the target microservice set, it parses the client request load through the regular expression engine to generate a set of parameter key-value pairs for each microservice. The computation module is used to concurrently execute authorized target microservice API calls through a non-blocking thread pool based on the access token set and parameter key-value pair set, inject distributed tracing identifiers, and collect three indicators in real time during the call process: response latency percentile, containerized resource quota utilization rate, and status code anomaly distribution rate of each microservice. Based on the three indicators, a service health tensor in Lie group space is constructed, and the curvature change rate and service health entropy increase coefficient of the tensor field are calculated through covariant derivatives. The syntax tolerance constraints of the extracted expression are dynamically relaxed according to the entropy increase coefficient, and standardized data tuples are extracted. The processing module is used to input standardized data tuples into the graph nesting operators defined by the rules, generate standardized aggregated data entities, and encapsulate them into protocol frames to return to the client.

[0084] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for multi-service aggregation and orchestration of an API gateway based on a dynamic rule engine, characterized in that, The method includes: Step 1: The API gateway layer intercepts the business scenario interface call request initiated by the client. The request carries a unique identifier identity credential for the business scenario and parses the request parameters. Step 2: Using the unique identifier of the business scenario, retrieve the pre-set aggregation orchestration rule topology from the rule engine to obtain the target microservice set; Based on the identity credentials and the target microservice set, initiate a token federation request to the authentication center to obtain the access token set; According to the request parameters and the parameter mapping predicate logic of the target microservice set, parse the client request load through the regular expression engine to generate a set of parameter key-value pairs for each microservice. Step 3: Based on the access token set and parameter key-value pair set, execute the authorized target microservice API call concurrently through a non-blocking thread pool, inject the distributed tracing identifier, and collect three indicators in real time during the call process: response latency percentile, containerized resource quota utilization rate, and status code anomaly distribution rate of each microservice. Step 4: Construct the service health tensor in the Lie group space using three indicators, and calculate the rate of curvature change of the tensor field and the service health entropy increase coefficient based on the covariant derivative. Step 5: Dynamically relax the syntax tolerance constraints of the expression based on the entropy increase coefficient, and extract the standardized data tuples; Step 6: Input the standardized data tuples into the graph nesting operator defined by the rules, generate standardized aggregated data entities, and encapsulate them into protocol frames to return to the client.

2. The API gateway multi-service aggregation and orchestration method based on a dynamic rule engine according to claim 1, characterized in that, The API gateway layer intercepts the business scenario API call request initiated by the client. This request carries a unique identifier identity credential for the business scenario, and the request parameters are parsed to obtain the following: Step 1.1: Capture client requests through the traffic interceptor of the API gateway and extract the unique identifier and identity credentials carried in the request header for the business scenario; Step 1.2: Based on the unique identifier of the business scenario, perform rule matching verification, initiate a real-time query to the topology configuration repository of the rule engine, calculate the hash matching degree between the identifier and the registered rule, and generate a rule verification pass signal when the matching degree exceeds the preset threshold. Step 1.3: Respond to and process the rule verification pass signal, perform request load parsing, call the regular expression engine to scan the original request body data, extract the key parameter fragment set from the original data according to the preset parameter template, and inject the key parameter fragment set into the memory cache queue in the order of service dependency as the final output to obtain the request parameters.

3. The API gateway multi-service aggregation and orchestration method based on a dynamic rule engine according to claim 2, characterized in that, By using a unique identifier for the business scenario, the pre-defined aggregation and orchestration rule topology is retrieved from the rule engine to obtain the target set of microservices; Based on the identity credentials and the target set of microservices, a token request is sent to the authentication center to obtain the access token set; Based on the request parameters and the predicate logic mapping the target microservice set parameters, the client request payload is parsed using a regular expression engine to generate a set of parameter key-value pairs for each microservice, including: Step 2.1: Based on the output unique identifier for the business scenario, calculate the matching confidence value between it and the preset topology in the rule engine. Input the identifier into the topology matcher of the rule engine, perform fast hash space retrieval through a Bloom filter, and use the Levenshtein distance algorithm to calculate the feature similarity between the identifier and the registration rule. When the similarity exceeds the preset threshold, load the target microservice dependency graph, service call timing constraint matrix and global timeout circuit breaker threshold vector from the topology configuration repository to obtain the target microservice set. Step 2.2: Based on the identity credentials and the target microservice set, perform dynamic token federated authorization. Through the multi-scope token issuance mechanism of the OAuth protocol, generate a batch of access token sets with time-sensitive weight factors. Step 2.3: Based on the cached request load data, perform parameter structure transformation, extract field transformation rules from the predicate logic, match the original parameter key names using a weighted edit distance algorithm, generate standardized key-value pairs using a type casting function, and output a set of parameter key-value pairs arranged in the order of service dependencies.

4. The API gateway multi-service aggregation and orchestration method based on a dynamic rule engine according to claim 3, characterized in that, Based on the access token set and parameter key-value pair set, the authorized target microservice API calls are executed concurrently through a non-blocking thread pool. Distributed tracing identifiers are injected, and during the call process, three metrics are collected in real time: the response latency percentile, containerized resource quota utilization, and status code anomaly distribution rate for each microservice. Step 3.1: Based on the dependency graph parsed from the standardized parameter key-value pair set, construct a concurrent task scheduling blueprint, dynamically calculate the concurrency parameter of the non-blocking thread pool according to the number of nodes in the dependency graph, parse the partial order relation matrix defined by the timing constraint, generate a topologically sorted task execution sequence, and initialize the thread pool task queue. Step 3.2: Traverse the task queue and perform trace identifier injection. Generate a globally unique distributed trace identifier for each microservice call task. Match and bind the obtained access token set according to the microservice instance. Inject TraceID and corresponding token into the call request header to form an executable call unit. Step 3.3: Execute the calling unit and collect health indicators in real time. Collect third-order indicators through the performance probe mounted on the container runtime interface. The third-order indicators include response latency percentile, containerized resource quota utilization rate, and status code anomaly distribution rate.

5. The API gateway multi-service aggregation and orchestration method based on a dynamic rule engine according to claim 4, characterized in that, A service health tensor in a Lie group space is constructed using three indicators. The rate of curvature change and the service health entropy increase coefficient of the tensor field are calculated based on the covariant derivatives, including: Step 4.1: Using three indicators, perform vector space construction calculation, log normalize the percentile of response latency of each microservice node to eliminate the difference in units, convert the container resource quota occupancy rate into complementary surplus as a positive correlation factor for health, calculate the sliding window weighted average of the abnormal distribution rate of status codes, suppress instantaneous fluctuation interference, and output the constructed three-dimensional health vector. Step 4.2: Based on the three-dimensional health vector, construct a health tensor field in the Lie group space, and map each microservice node to an independent tangent space coordinate frame of the Lie group space; assign the three components of the health vector to the covariant components of the tensor respectively, and reconstruct the connection coefficients based on the edge weights of the service dependency graph to describe the curvature correlation strength between nodes. Step 4.3: Through the tensor field, perform curvature change rate derivation calculation, calculate the covariant derivative along the tangent vector direction of the service call path, where the tangent vector is determined by the topological sorting of the dependency graph, calculate the Riemann curvature tensor by measuring curvature change through the noncommutativity of the connection coefficient, perform a contraction operation on the curvature tensor, and output the scalar curvature change rate. Step 4.4: Perform eigenvalue decomposition on the rate of curvature tensor and take the natural logarithm of the largest eigenvalue as the entropy increase coefficient.

6. The API gateway multi-service aggregation and orchestration method based on a dynamic rule engine according to claim 5, characterized in that, Based on the entropy increase coefficient, the syntax tolerance constraints of the expression are dynamically relaxed, and standardized data tuples are extracted, including: Step 5.1: Input the output entropy increase coefficient into the fault tolerance strategy decision maker of the rule engine to dynamically generate syntax relaxation rules; Step 5.2: Based on the syntax relaxation rules, reconstruct the extraction expression for microservice response data; Step 5.3: Execute the reconstructed expression through the streaming data processor, parse the heterogeneous data returned by the microservice node by node, and output standardized data tuples that conform to the standard.

7. The API gateway multi-service aggregation and orchestration method based on a dynamic rule engine according to claim 6, characterized in that, The standardized data tuples are input into the graph nesting operators defined by the rules, generating standardized aggregated data entities and encapsulating them into protocol frames to be returned to the client, including: Step 6.1: Load the standardized data tuples into the graph computation working memory of the rule engine; Step 6.2: Based on the data tuple, execute the preset graph nesting operator to complete the data aggregation. In the normal mode of data aggregation, run the traversal operation. When the detected degradation mark or entropy increase coefficient is greater than the disaster recovery threshold, activate the degradation strategy engine to retrieve the default value configuration template and inject placeholder values ​​into the missing fields. Step 6.3: Generate aggregated data entities through the entity normalization component, encapsulate the aggregated data entities into protocol frames, and return them to the client through the API gateway's response channel.

8. An API gateway multi-service aggregation and orchestration system based on a dynamic rule engine, the system implementing the method as described in any one of claims 1 to 7, characterized in that, include: The acquisition module is used by the API gateway layer to intercept business scenario interface call requests initiated by the client. The request carries a unique identifier identity credential for the business scenario and is parsed to obtain the request parameters. The analysis module is used to retrieve the pre-defined aggregation orchestration rule topology from the rule engine using a unique identifier for the business scenario, in order to obtain the target set of microservices; Based on the identity credentials and the target set of microservices, a token request is sent to the authentication center to obtain the access token set; Based on the request parameters and the parameter mapping predicate logic of the target microservice set, the client request load is parsed through the regular expression engine to generate a set of parameter key-value pairs for each microservice. The calculation module is used to concurrently execute authorized target microservice API calls through a non-blocking thread pool based on the access token set and parameter key-value pair set, inject distributed tracing identifiers, and collect three indicators in real time during the call process: response latency percentile, containerized resource quota utilization rate, and status code anomaly distribution rate of each microservice. Based on three indicators, a service health tensor in the Lie group space is constructed. The rate of curvature change of the tensor field and the entropy increase coefficient of service health are calculated by covariant derivatives. The syntax tolerance constraints of the extracted expression are dynamically relaxed according to the entropy increase coefficient, and standardized data tuples are extracted. The processing module is used to input standardized data tuples into the graph nesting operators defined by the rules, generate standardized aggregated data entities, and encapsulate them into protocol frames to return to the client.

9. A computing device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images