A method and system for multi-service aggregation and arrangement of an API gateway based on a dynamic rule engine

Abstract

The application provides a kind of API gateway multi-service aggregation orchestration method and system based on dynamic rule engine, it is related to distributed system architecture technical field, the method includes: API gateway layer intercepts the business scenario interface call request initiated by client, the request carries business scenario unique identifier identity credential and obtains request parameter by parsing;By business scenario unique identifier, retrieve the preset aggregation orchestration rule topology from rule engine, to obtain target microservice set;Based on identity credential and target microservice set, initiate token joint request to authentication center, obtain access token set;According to the predicate logic of request parameter and target microservice set parameter mapping, the client request load is parsed by regular expression engine, and the parameter key-value pair set for each microservice is generated.The application is used to solve the problem of poor adaptability of multi-service dynamic orchestration in microservice architecture.

Description

Technical Field

[0001] This invention relates to the field of distributed system architecture technology, and in particular to a method and system for multi-service aggregation and orchestration of an API gateway based on a dynamic rule engine. Background Technology

[0002] In a microservice architecture, clients often need to call multiple services to complete complex business scenarios. While traditional API gateways can achieve service aggregation, they have some shortcomings:

[0003] For example, static orchestration rules cannot adapt to dynamic dependency topology changes, leading to rigid call chains; manually configured fault tolerance strategies lack runtime health awareness capabilities, making it difficult to accurately degrade in case of anomalies; data extraction logic for heterogeneous services is hard-coded, making it difficult to flexibly adapt to parameter mapping requirements; global circuit breakers are disconnected from local service states, resulting in low resource utilization. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide a method and system for multi-service aggregation and orchestration of API gateway based on dynamic rule engine, which is used to solve the problem of poor adaptability of multi-service dynamic orchestration in microservice architecture.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0006] Firstly, a method for multi-service aggregation and orchestration of an API gateway based on a dynamic rule engine, the method comprising:

[0007] 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.

[0008] 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.

[0009] 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.

[0010] 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.

[0011] Step 5: Dynamically relax the syntax tolerance constraints of the expression based on the entropy increase coefficient, and extract the standardized data tuples;

[0012] 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.

[0013] Furthermore, the API gateway layer intercepts the business scenario interface 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 them, including:

[0014] 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;

[0015] 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.

[0016] 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.

[0017] Furthermore, by using a unique identifier for the business scenario, a pre-defined aggregation orchestration rule topology is retrieved from the rule engine to obtain the target microservice set; based on the identity credentials and the target microservice set, a token federation request is initiated to the authentication center to obtain an access token set; according to the request parameters and the parameter mapping predicate logic of the target microservice set, the client request payload is parsed through the regular expression engine to generate a set of parameter key-value pairs for each microservice, including:

[0018] 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.

[0019] 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.

[0020] 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.

[0021] Furthermore, 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, a distributed tracing identifier is injected, and three metrics are collected in real time during the call process: response latency percentile, containerized resource quota utilization, and status code anomaly distribution rate.

[0022] 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.

[0023] 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.

[0024] 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.

[0025] Furthermore, a service health tensor in the Lie group space is constructed using three indicators. The rate of curvature change of the tensor field and the service health entropy increase coefficient are calculated based on the covariant derivative, including:

[0026] 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.

[0027] 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.

[0028] 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.

[0029] 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.

[0030] Furthermore, based on the entropy increase coefficient, the syntax tolerance constraints of the extracted expression are dynamically relaxed, and standardized data tuples are extracted, including:

[0031] 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;

[0032] Step 5.2: Based on the syntax relaxation rules, reconstruct the extraction expression for microservice response data;

[0033] 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.

[0034] Furthermore, 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:

[0035] Step 6.1: Load the standardized data tuples into the graph computation working memory of the rule engine;

[0036] 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.

[0037] 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.

[0038] Secondly, a multi-service aggregation and orchestration method for API gateways based on a dynamic rule engine includes:

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] Thirdly, a computing device includes:

[0044] One or more processors;

[0045] A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method.

[0046] Fourthly, a computer-readable storage medium storing a program that, when executed by a processor, implements the method.

[0047] The above-described solution of the present invention has at least the following beneficial effects:

[0048] By leveraging a dynamic rule engine to achieve flexible adaptation of aggregation orchestration rules, the rigidity of static orchestration links in traditional API gateways is resolved, enabling real-time responses to dynamic changes in business scenario-dependent topologies. A service health tensor is constructed based on Lie group space, and an entropy increase coefficient is derived. This integrates multi-dimensional indicators such as response latency, resource consumption, and status code anomalies, achieving precise quantitative perception of service health status. This provides real-time dynamic decision-making basis for fault tolerance strategies, overcoming the shortcomings of manually pre-configured strategies lacking runtime health awareness. A regular expression engine and parameter mapping predicate logic enable flexible configuration of heterogeneous service data extraction logic. The entropy increase coefficient drives dynamic relaxation of syntax fault tolerance constraints and intelligent activation of degradation strategies. Attached Figure Description

[0049] Figure 1 This is a flowchart illustrating a multi-service aggregation and orchestration method for an API gateway based on a dynamic rule engine, provided by an embodiment of the present invention.

[0050] Figure 2 This is a schematic diagram of an API gateway multi-service aggregation and orchestration system based on a dynamic rule engine, provided by an embodiment of the present invention. Detailed Implementation

[0051] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0052] like Figure 1 As shown, an embodiment of the present invention proposes a multi-service aggregation and orchestration method for API gateways based on a dynamic rule engine. The method includes the following steps:

[0053] 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.

[0054] 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.

[0055] 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.

[0056] Step 4: Based on the three indicators, construct the service health tensor in the Lie group space, and calculate the rate of curvature change of the tensor field and the service health entropy increase coefficient through covariant derivatives.

[0057] Step 5: Dynamically relax the syntax tolerance constraints of the expression based on the entropy increase coefficient, and extract the standardized data tuples;

[0058] 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.

[0059] In this embodiment of the invention, requests are dynamically intercepted and parsed by the API gateway layer, and the rule engine is used to flexibly retrieve and aggregate orchestration rule topologies, thereby achieving dynamic adaptation of service dependencies and call sequences and breaking through the limitations of rigid traditional static orchestration links. Non-blocking thread pools are used to concurrently call microservices and collect multi-dimensional health indicators, which, combined with distributed tracing, improves call efficiency and observability. The innovative introduction of Lie group space health tensor construction and entropy increase coefficient calculation, along with the integration of indicators such as response latency, resource consumption, and abnormal status codes, enables precise quantification of service health status, providing real-time dynamic basis for fault tolerance strategies. The entropy increase coefficient drives dynamic relaxation of syntax fault tolerance constraints and intelligent activation of degradation strategies, enhancing system resilience against anomalies while ensuring data aggregation standardization.

[0060] In a preferred embodiment of the present invention, step 1 above may include:

[0061] 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;

[0062] 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.

[0063] 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.

[0064] In this embodiment of the invention, layered processing achieves accurate and efficient request preprocessing. A traffic interceptor accurately captures requests and extracts key identifiers, providing a basis for subsequent rule matching and authorization, and ensuring that the source of the request is traceable. Through hash matching degree calculation and threshold verification, invalid or mismatched requests are filtered out. A regular expression engine is used to flexibly parse heterogeneous request loads. Key parameters are extracted by combining pre-set templates and cached in the order of service dependencies, ensuring the structured and standardized nature of parameter extraction.

[0065] In this embodiment of the invention, the specific steps include:

[0066] Step 1.1: Capture client requests through the API gateway's traffic interceptor and extract the unique identifier for the business scenario and identity credentials carried in the request header.

[0067] 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 matching degree threshold is preset (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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] In a preferred embodiment of the present invention, step 2 above may include:

[0072] 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.

[0073] 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.

[0074] 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.

[0075] 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.

[0076] In this embodiment of the invention, the specific steps include:

[0077] 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.

[0078] 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).

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

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

[0081] The hash value calculated by hash1() is h1=2567; the hash value calculated by hash2() is h2=1892.

[0082] The hash value h3 is calculated as 3409 using hash3().

[0083] 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).

[0084] Calculation process:

[0085] Index 1 = h1%m = 2567%1000 = 567 (2567 divided by 1000 leaves a remainder of 567).

[0086] index2 = h2%m = 1892%1000 = 892;

[0087] Index 3 = h3%m = 3409%1000 = 409.

[0088] The calculated index positions (e.g., 567, 892, 409) are used to label the bit array of the Bloom filter:

[0089] When inserting a rule: set the bit value of these k index positions to 1 (indicating that the rule has been registered);

[0090] 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".

[0091] 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).

[0092] 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:

[0093] 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.

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

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

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

[0097] 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.

[0098] 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.

[0099] 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.

[0100] In a preferred embodiment of the present invention, step 3 above may include:

[0101] 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.

[0102] 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.

[0103] 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.

[0104] 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.

[0105] In this embodiment of the invention, the specific steps include:

[0106] Step 3.1, First step: Select all microservices from the parameters (determine the nodes):

[0107] 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.

[0108] Step 2: Identify the dependencies between services from the parameters (determine the connections):

[0109] 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.

[0110] Specifically, dependencies are identified through the following information:

[0111] 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.

[0112] 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.

[0113] 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.

[0114] Step 3: Organize the dependency graph into a directed graph form:

[0115] 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.

[0116] 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.

[0117] 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.

[0118] 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.

[0119] 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%.

[0120] 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.

[0121] In a preferred embodiment of the present invention, step 4 above may include:

[0122] 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.

[0123] 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.

[0124] 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.

[0125] 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.

[0126] 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.

[0127] In this embodiment of the invention, the specific steps include:

[0128] 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).

[0129] 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).

[0130] 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).

[0131] 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.

[0132] 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).

[0133] 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:

[0134] 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.

[0135] 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.

[0136] 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:

[0137] 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.

[0138] 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:

[0139] 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).

[0140] 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).

[0141] An index of zero indicates that the network is flat, the service dependencies are simple, and the state is stable.

[0142] 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.

[0143] 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:

[0144] Feature vector: Each feature vector corresponds to a service dependency path (direction of change);

[0145] 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).

[0146] 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.

[0147] 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.

[0148] In a preferred embodiment of the present invention, step 5 above may include:

[0149] 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;

[0150] Step 5.2: Based on the syntax relaxation rules, reconstruct the extraction expression for microservice response data;

[0151] 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.

[0152] 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.

[0153] In this embodiment of the invention, the specific steps include:

[0154] 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).

[0155] 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).

[0156] 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).

[0157] 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).

[0158] 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.

[0159] 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).

[0160] In a preferred embodiment of the present invention, step 6 above may include:

[0161] Step 6.1: Load the standardized data tuples into the graph computation working memory of the rule engine;

[0162] 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.

[0163] 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.

[0164] 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.

[0165] In this embodiment of the invention, the specific steps include:

[0166] 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.

[0167] 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).

[0168] 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.

[0169] 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).

[0170] 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.

[0171] 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:

[0172] 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).

[0173] 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.

[0174] 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:

[0175] 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.

[0176] 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.

[0177] 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.

[0178] 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.

[0179] 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 it to obtain 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, 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. Step 6 involves inputting standardized data tuples into the graph nesting operator defined by the rules, generating standardized aggregated data entities, and encapsulating them into protocol frames to return 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.

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 API gateway's traffic interceptor and extract the unique identifier for the business scenario and identity credentials carried in the request header; 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 identity credentials and the target set of microservices, initiate a token request to the authentication center to obtain an 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. 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 5, 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 identity credentials and the target set of microservices, initiate a token request to the authentication center to obtain an 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, and the rate of curvature change of the tensor field and the service health entropy increase coefficient are calculated by covariant derivatives. The syntax tolerance constraints of the extraction expression are dynamically relaxed based on the entropy increase coefficient, and standardized data tuples are extracted. This includes: inputting the output entropy increase coefficient into the fault tolerance strategy decision maker of the rule engine to dynamically generate syntax relaxation rules; reconstructing the extraction expression of microservice response data based on the syntax relaxation rules; executing the reconstructed expression through a streaming data processor, parsing the heterogeneous data returned by the microservice node by node, and outputting standardized data tuples that conform to the standard. 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. This includes: loading standardized data tuples into the graph computation working memory of the rule engine; executing preset graph nesting operators to complete data aggregation based on the data tuples; running traversal operations in normal mode during data aggregation; activating the degradation strategy engine to retrieve default value configuration templates and inject placeholder values ​​into missing fields when a detected degradation flag or entropy increase coefficient exceeds the disaster recovery threshold; generating aggregated data entities through the entity normalization component; encapsulating the aggregated data entities into protocol frames; and returning them to the client through the API gateway's response channel.

7. 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 5.

8. 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 5.

Images