An adaptive API gateway intelligent routing method, system, device and medium for an industrial software system

Abstract

The application relates to the technical field of semiconductor manufacturing, in particular to an adaptive API gateway intelligent routing method, system, device and medium for an industrial software system; an API calling causality graph is constructed to predict a fault propagation path and actively avoid fault diffusion; time sequence dependence, security levels and certainty requirements are modeled as constraints and integrated into routing decisions; and multi-stage gray verification is used to ensure that a new strategy is safely put online, so that fault risks caused by model updating are eliminated.

Description

Technical Field

[0001] This invention relates to the field of semiconductor manufacturing technology, and more specifically, to an adaptive API gateway intelligent routing method, system, device, and medium for industrial software systems. Background Technology

[0002] As industrial software systems evolve towards microservice architectures, API gateways have become the core hub of these systems. API calls in industrial scenarios have the following unique characteristics: 1. Strict timing dependencies: Device control APIs must be executed in a strict order (e.g., "device lock → parameter issuance → device unlock"), and incorrect order may damage the device; 2. Clear security levels: The security levels of different APIs vary significantly (from L1 emergency shutdown to L4 data monitoring), and lower-level services cannot call higher-level services; 3. High deterministic requirements: The latency jitter of control APIs must be <10ms, otherwise it will affect the process quality; 4. Severe impact of failures: A service failure can trigger a cascading failure through the API call chain, affecting the entire production line. Summary of the Invention

[0003] This invention addresses the problems of existing optimization methods, such as their inability to predict fault propagation, failure to consider the special constraints of industrial scenarios, and lack of security verification mechanisms. It proposes an adaptive API gateway intelligent routing method, system, device, and medium for industrial software systems. By constructing an API call causal graph, it predicts fault propagation paths and proactively avoids faults before they spread. It models temporal dependencies, security levels, and deterministic requirements as constraints and integrates them into routing decisions. Furthermore, it ensures the safe deployment of new strategies through multi-stage gray-scale verification, eliminating the risk of faults caused by model updates.

[0004] The specific implementation details of this invention are as follows: An adaptive API gateway intelligent routing method for industrial software systems specifically includes the following steps: Step S1: Collect API call data and use the PC algorithm to construct a directed cause-effect graph between services; Step S2: Based on the directed cause-effect graph between services and the set anomaly detection trigger conditions, predict and avoid fault propagation, and output the routing adjustment strategy after avoidance and the real-time health status of downstream services. Step S3: Based on the routing adjustment strategy after avoidance output in Step S2 and the real-time health status of downstream services, construct industrial constraints, and construct a constraint-aware GNN sub-model based on the industrial constraints to obtain the comprehensive reward function and normalize it, and output the normalized comprehensive reward value. Step S4: Based on the normalized comprehensive reward value output in step S3, initialize the constraint-aware GNN sub-model to obtain the shadow model, call the constructed shadow model to run in parallel with the main model, i.e. the constraint-aware GNN sub-model, perform virtual routing for real-time requests, and perform multi-stage grayscale verification. Step S5: A three-level sequence learner architecture is adopted, which is responsible for route optimization at different time scales and outputs the final route weight table. The final route weight table is used to determine the API request route ratio of each service instance.

[0005] To better realize the present invention, step S1 further includes the following steps: Step S11: Collect API call data; Step S12: Based on the API call data, use the security level of the service instance as a node attribute and the Granger causality coefficient as an edge attribute, and call the PC algorithm to construct a directed causal graph between services; wherein, the security level in the node attribute is mapped according to the business priority field in the API call data, and the Granger causality coefficient in the edge attribute is calculated according to the call timestamp and response time sequence in the API call data.

[0006] To better realize the present invention, step S2 further includes the following steps: Step S21: Based on the directed causal graph between services and the set anomaly detection triggering conditions, retrieve the edge of the current abnormal service, the list of downstream services, and the Granger causality coefficient. The outgoing edge is the directed edge in the causal graph that points from the current abnormal service to its downstream service. The downstream service is the service corresponding to the endpoint node of the outgoing edge. Step S22: Based on the downstream service list, call DBN to predict the failure probability and obtain the real-time health status of the downstream services. The DBN is a dynamic Bayesian network model pre-constructed based on historical failure propagation records and causal graph structure. Step S23: Determine the current risk level based on the real-time health status, and execute the corresponding routing adjustment strategy according to the risk level; Step S24: Calculate the prediction accuracy based on the real-time health status of the adjusted downstream services. If the prediction accuracy is less than the set threshold, adjust the DBN model parameters and record them in the fault mode library.

[0007] To better realize the present invention, step S3 further includes the following steps: Step S31: Based on the routing adjustment strategy after avoidance output in step S2 and the real-time health status of downstream services, the risk level, traffic adjustment ratio and security restrictions in the routing adjustment strategy are transformed into dynamic risk constraints, and time-series dependency constraints, security level constraints and deterministic jitter constraints are integrated to construct industrial constraints. Step S32: Based on the constructed industrial constraints, the safety level is used as the node feature, and the Granger causality coefficient, temporal dependency type, and business priority weight are used as the edge features. The constraint-aware GNN sub-model in the mid-term policy learner is constructed according to the set number of graph convolutional layers. Step S33: Based on the constructed constraint-aware GNN sub-model, calculate the response time score, success rate score, security compliance score, and jitter penalty score; Step S34: Based on the set weight coefficients, response time score, success rate score, security compliance score, and jitter penalty score, construct a comprehensive reward function and normalize it, outputting the normalized comprehensive reward value. The normalized comprehensive reward value is used to evaluate the merits of the routing strategy and serves as the training optimization target for the shadow model and the main model in step S4.

[0008] To better realize the present invention, step S4 further includes the following steps: Step S41: Call the shadow model to run in parallel with the main model, perform virtual routing for real-time requests, and record the decision not to execute; the main model is the routing decision model formed by fusing the constraint-aware GNN sub-model and the PPO reinforcement learning model constructed in step S32 within the mid-term policy learner framework, and the shadow model is a copy model with the same structure as the main model but with independently updated parameters. Step S42: Multi-stage grayscale verification to obtain the verification result; Step S43: Perform a rollback operation based on the verification results.

[0009] To better realize the present invention, step S5 further includes the following steps: Step S51: Based on the current set of service instances and the acquired real-time monitoring data, obtain aggregated features according to the set three-level learner collaboration mechanism; Step S52: Calculate the routing weights based on the first-level score, the second-level strategy, the third-level causal prediction, and the set weights to obtain a routing weight table. The routing weight table is used to determine the API request routing ratio of each service instance. The higher the routing weight, the higher the proportion of requests allocated to that service instance.

[0010] Based on the above-mentioned adaptive API gateway intelligent routing method for industrial software systems, in order to better realize the present invention, an adaptive API gateway intelligent routing system for industrial software systems is further proposed, which is used to execute the above-mentioned adaptive API gateway intelligent routing method for industrial software systems, including a cause-effect graph construction unit, a fault propagation prediction unit, a constraint construction unit, a multi-stage grayscale verification unit, and an optimization unit. The cause-effect graph construction unit is used to collect API call data and call the PC algorithm to construct a directed cause-effect graph between services; The fault propagation prediction unit is used to obtain the evaded route based on the directed cause-effect graph between services and the set anomaly detection triggering conditions. The constraint construction unit is used to construct industrial constraints based on the avoided route, construct a constraint-aware GNN sub-model based on the industrial constraints, obtain a reward function and normalize it to obtain a normalized reward value. The multi-stage grayscale verification unit is used to initialize the constraint-aware GNN sub-model to obtain the shadow model based on the normalized comprehensive reward value, run the constraint-aware GNN sub-model and the shadow model in parallel, perform virtual routing of API call requests obtained from the API gateway, and perform multi-stage grayscale verification. The optimization unit is used to distribute the data to the corresponding service instances according to a set ratio based on the grayscale verification results and the constructed three-level sequence learner architecture, thereby completing intelligent routing.

[0011] Based on the above-mentioned adaptive API gateway intelligent routing method for industrial software systems, in order to better realize the present invention, an electronic device is further proposed, including a memory and a processor, wherein a computer program is stored on the memory; when the computer program is executed on the processor, the above-mentioned adaptive API gateway intelligent routing method for industrial software systems is implemented.

[0012] Based on the aforementioned adaptive API gateway intelligent routing method for industrial software systems, and to better realize this invention, a computer-readable storage medium is further proposed, wherein computer instructions are stored on the computer-readable storage medium; when the computer instructions are executed on the aforementioned electronic device, the aforementioned adaptive API gateway intelligent routing method for industrial software systems is implemented.

[0013] The present invention has the following beneficial effects: (1) The present invention constructs an API call cause-effect graph to predict the fault propagation path and realize proactive avoidance before the fault spreads.

[0014] (2) This invention models temporal dependence, security level and deterministic requirements as constraints and integrates them into routing decisions to achieve GNN+RL routing optimization with industrial constraint awareness.

[0015] (3) This invention ensures the safe launch of the new strategy through multi-stage grayscale verification, eliminating the risk of failure caused by model updates. Attached Figure Description

[0016] Figure 1 The overall architecture diagram of the industrial API gateway intelligent routing system provided by this invention is shown.

[0017] Figure 2 The flowchart for grayscale verification of the shadow model provided by this invention. Detailed Implementation

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments, and therefore should not be regarded as a limitation on the scope of protection. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "set up," "connected," and "linked" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0020] Example 1: This embodiment proposes an adaptive API gateway intelligent routing method for industrial software systems, which specifically includes the following steps: Step S1: Collect API call data, including historical call data and real-time received API call requests, and use the PC algorithm to construct a directed causal graph between services; Step S1 specifically includes the following steps: Step S11: Collect API call data; the API call data includes historical call records and real-time API request streams. The historical call records include call timestamps, response times, and business priorities, which are used for cause-effect graph construction and model training. The real-time API request streams are the pending requests currently received by the API gateway. Step S12: Based on the API call data, the security level of the service instance is used as a node attribute, and the Granger causality coefficient is used as an edge attribute. The PC algorithm is called to construct a directed causal graph between services. The security level in the node attribute is mapped to the business priority field in the API call data, and the Granger causality coefficient in the edge attribute is calculated based on the call timestamp and response time sequence in the API call data.

[0021] Step S2: Based on the directed cause-effect graph between services and the set anomaly detection trigger conditions, predict and avoid fault propagation, and output the routing adjustment strategy after avoidance and the real-time health status of downstream services. Step S2 specifically includes the following steps: Step S21: Based on the directed causal graph between services and the set anomaly detection triggering conditions, retrieve the edge of the current abnormal service, the list of downstream services, and the Granger causality coefficient. The outgoing edge is the directed edge in the causal graph that points from the current abnormal service to its downstream service. The downstream service is the service corresponding to the endpoint node of the outgoing edge. Step S22: Based on the downstream service list, call the DBN model to predict the failure probability and obtain the real-time health status of the downstream services; the DBN is a dynamic Bayesian network model pre-constructed based on historical failure propagation records and causal graph structure. Step S23: Determine the current risk level based on the real-time health status, and execute the corresponding routing adjustment strategy according to the risk level; Step S24: Calculate the prediction accuracy based on the real-time health status of the adjusted downstream services. If the prediction accuracy is less than the set threshold, adjust the DBN model parameters to obtain the routing adjustment strategy after avoidance and record it in the fault mode library.

[0022] Step S3: Based on the routing adjustment strategy after avoidance output in Step S2 and the real-time health status of downstream services, construct industrial constraints, obtain the comprehensive reward function and normalize it, and output the normalized comprehensive reward value. Step S3 specifically includes the following steps: Step S31: Based on the routing adjustment strategy after avoidance output in step S2 and the real-time health status of downstream services, construct industrial constraints; Step S32: Based on the constructed industrial constraints, the safety level is used as the node feature, and the Granger causality coefficient, temporal dependency type, and business priority weight are used as the edge features. The constraint-aware GNN sub-model in the mid-term policy learner is constructed according to the set number of graph convolutional layers. Step S33: Based on the constructed constraint-aware GNN sub-model, calculate the response time score, success rate score, security compliance score, and jitter penalty score; Step S34: Based on the set weight coefficients, response time score, success rate score, security compliance score, and jitter penalty score, construct a comprehensive reward function and normalize it, outputting the normalized comprehensive reward value. The normalized comprehensive reward value is used to evaluate the merits of the routing strategy and serves as the training optimization target for the shadow model and constraint-aware GNN sub-model in step S4.

[0023] Step S4: Call the main model and shadow model built in step S3 to run in parallel, perform virtual routing on the API call requests received in real time by the API gateway in the real-time API request stream collected in step S1, and perform multi-stage grayscale verification. Step S4 specifically includes the following steps: Step S41: Call the shadow model to run in parallel with the main model, perform virtual routing for real-time requests, and record the decision not to execute; the main model is the routing decision model formed by fusing the constraint-aware GNN sub-model and the PPO reinforcement learning model constructed in step S32 within the mid-term policy learner framework, and the shadow model is a copy model with the same structure as the main model but with independently updated parameters. Step S42: Multi-stage grayscale verification to obtain the verification result; Step S43: Perform a rollback operation based on the verification results.

[0024] Step S5: A three-level sequence learner architecture is adopted, which is responsible for route optimization at different time scales and outputs the final route weight table. The final route weight table is used to determine the API request route ratio of each service instance.

[0025] Step S5 specifically includes the following steps: Step S51: Based on the current set of service instances and the acquired real-time monitoring data, obtain aggregated features according to the set three-level learner collaboration mechanism; Step S52: Calculate the routing weights based on the first-level score, the second-level strategy, the third-level causal prediction, and the set weights to obtain a routing weight table. The routing weight table is used to determine the API request routing ratio of each service instance. The higher the routing weight, the higher the proportion of requests allocated to that service instance.

[0026] Working principle: This embodiment predicts the failure propagation path by constructing an API call causal graph and actively avoids failures before they spread; it models temporal dependencies, security levels, and deterministic requirements as constraints and incorporates them into routing decisions; and it ensures the safe deployment of new strategies through multi-stage gray-scale verification, eliminating the risk of failures caused by model updates.

[0027] Example 2: This embodiment is based on the above embodiment 1, such as... Figure 1 , Figure 2As shown, a specific embodiment will be described in detail.

[0028] Step S1: API call to construct the cause-effect graph; Collect API call chain time-series data and use causal discovery algorithms to construct a directed causal graph between services: 1. Data Collection: Collect API call data (call timestamp, response time, error code, business priority) for the past 30 days, with a minimum sample size of 10,000. 2. Causal discovery: A directed causal graph was constructed using the PC algorithm (significance level α=0.05); Node attributes: Security level of the service instance (L1~L4, mapped from the business priority field in the API call data), device correlation (statistically obtained from the device identifier field in the API call data), and real-time control cycle (calculated from the call timestamp in the API call data). Edge attributes: Granger causality coefficient (calculated based on call timestamps and response time series in API call data, threshold > 0.6), latency window (maximum 10s), and fault propagation probability (obtained from statistics based on historical fault propagation records).

[0029] 3. Graph Update: Incremental updates every hour; a rebuild is triggered when data changes by more than 10%.

[0030] Step S2: Fault propagation prediction and proactive route avoidance; When a service anomaly is detected, fault propagation is predicted based on a cause-effect graph, and proactive avoidance is implemented: (1) Anomaly detection trigger conditions (triggered if any condition is met): Condition A: Abnormal response time; Triggering condition: T_current > P95_baseline × (1 + θ) and N consecutive samples. Parameter settings: T_current: The real-time response time of the current service, in milliseconds, is collected through the real-time monitoring module of the API gateway; P95_baseline: The P95 response time baseline of this service over the past 24 hours, which is obtained by performing percentile statistical calculations on the response time field in the API call data. θ: Abnormal threshold coefficient, default 1.0 (i.e., exceeding 200% of P95); N: Number of consecutive anomalies, default 5; Sampling interval: 1 second; Example: For a service with P95_baseline=80ms and θ=1.0, the trigger threshold is 160ms; If five consecutive samples are all >160ms, the response time is considered abnormal. Condition B: Abnormal error rate; Triggering condition: Error_rate_current > μ_baseline + k × σ_baseline; Parameter settings: μ_baseline: The average error rate over the past 24 hours; σ_baseline: The standard deviation of the error rate over the past 24 hours; k: Anomaly coefficient, default 3 (3σ principle); Example: μ_baseline=0.1%, σ_baseline=0.05%, k=3; The trigger threshold is 0.25%; exceeding this threshold indicates an abnormal error rate. Condition C: Cascaded fault warning; Triggering conditions: The upstream service has triggered an exception and this service is a downstream node in the cause-effect graph; Judgment logic: Query the cause-effect graph to check if there are any incoming edges from services that are already abnormal; the incoming edge is a directed edge in the cause-effect graph that points to this service, and the upstream service is the service corresponding to the starting node of the incoming edge; If present and the Granger causality coefficient is greater than 0.6, an alert is triggered immediately; Condition D: Manually triggered Triggering condition: Operations personnel manually mark a service as "high risk" through the management interface; Application scenarios: planned maintenance, known defective services, and failed gray-scale verification, etc. Condition E: Trigger the debounce and cooldown mechanism; To prevent routing policies from frequently fluctuating due to instantaneous changes, the following engineering protection logic is added:

[0031] (2) Specific process of proactive route avoidance: Step 1: Anomaly Confirmation (Time T0); Collect monitoring data from the last 5 seconds; Verify whether the abnormal condition persists. If the anomaly disappears, cancel the trigger and return to the normal process; Step 2: Cause-effect graph query (T0+1s); Retrieve outgoing edges from the current abnormal service from the causal graph, where the outgoing edges are directed edges in the causal graph pointing from the current abnormal service to its downstream services; Obtain a list of all downstream services and Granger causality coefficients; the downstream services are the services corresponding to the endpoint nodes of the outgoing edges; Screen for strongly correlated downstream services with a causality coefficient > 0.6; Step 3: Fault Probability Prediction (T0+2s) For each downstream service, the probability of failure in the next 60 seconds is predicted using a DBN model, which is a dynamic Bayesian network model pre-built based on historical failure propagation records and causal graph structure. Inputs: the degree of anomaly of the current abnormal service (defined as T_current / P95_baseline, representing the multiple of the current response time relative to the baseline), causal strength (i.e., Granger causality coefficient), and the real-time health status of downstream services (CPU, memory, and response time metrics obtained through real-time monitoring data). Output: P_fault(t)∈[0,1], t∈[0,60s]; P_fault(t) represents the probability that the downstream service will fail at time t in the future; Step 4: Risk classification (T0+3s); High risk: P_fault > 0.7; Medium risk: 0.4 <P_fault≤0.7; Low risk: P_fault ≤ 0.4; Step 5: Execute the routing adjustment strategy (T0+4s); High-risk services: Weight adjustment: W_new = W_old × 0.1 (reduced by 90%); where W_old is the original route weight of the current abnormal service in the API gateway routing table, and the route weight is used to determine the proportion of API requests allocated to this service instance.

[0032] Temporary removal: Removed from the routing table, duration 300s; L1 / L2 level API: 100% routed to the standby instance; L4 API: Allows delayed queuing, with a maximum delay of 10 seconds; Medium-risk services; Weight adjustment: W_new = W_old × 0.5 (reduced by 50%); Increase monitoring frequency: from 1 time / second to 5 times / second; Prepare backup instances for warm-up; Low-risk services: Keep the current weights unchanged; Continuously monitor and reassess if P_fault rises to >0.4; Step 6: Effect verification and feedback (T0+60s); Statistics on the actual occurrence of faults in downstream services; Comparison of prediction accuracy: ACC = N_correct / N_total; where N_correct is the number of downstream services whose DBN prediction results are consistent with the actual failure occurrence, and N_total is the total number of downstream services participating in the prediction; If ACC < 0.7, adjust the DBN model parameters; Record this event to the fault mode library; Step 7: Recovery Strategy (T0+300s or Abnormal Resolution) The weight of services temporarily removed will be gradually restored: 0.1→0.3→0.6→1.0 (one level every 60 seconds); If another error occurs during the recovery process, re-enter Step 1; If it runs stably for 300 seconds, the routing will be fully restored to normal. (3) Atomicity and consistency guarantees for routing adjustments: Atomicity: A single routing adjustment operation either succeeds completely or is rolled back completely; Consistency: All gateway instances see the same routing table version at the same time; Implementation method: Use a distributed lock (Redis) combined with a version number mechanism; specifically: set a distributed lock in Redis, acquire the lock, read the current routing table version number, perform route adjustment operations, update the version number and release the lock; each gateway instance periodically synchronizes the latest version of the routing table from Redis; Conflict resolution: Higher version numbers override lower version numbers to ensure eventual consistency; when multiple gateway instances initiate route adjustments simultaneously, adjustments with higher version numbers are executed first, and operations with lower version numbers, after acquiring the distributed lock and detecting that the version number has been updated, abandon the current operation and reread the latest routing table; (4) Handling of abnormal situations: Scenario 1: Cause-effect graph query times out (>2s) Degradation strategy: Use locally cached copies of the causal graph, marked as "may expire"; the locally cached copies of the causal graph are causal graph caches maintained in memory by each gateway instance, and are synchronously updated from the central node every hour; Scenario 2: DBN prediction failure Degradation strategy: Risk is estimated based on heuristic rules (causal strength × anomaly degree); the causal strength is the Granger causality coefficient, and the anomaly degree is T_current / P95_baseline; Scenario 3: Route adjustment execution failed; Retry mechanism: Maximum of 3 retries, with a 1-second interval between each retrieval; Alarm notification: Send alarms to the operations and maintenance platform; Scenario 4: The standby instance is unavailable; Degradation strategy: Allow the primary instance to continue providing services, but limit the traffic ratio to ≤30%; Step S3: Industrial constraint-aware GNN+RL routing decision; Based on the routing adjustment strategy after avoidance output in step S2 and the real-time health status of downstream services, industrial scenario constraints are integrated into GNN feature extraction and RL routing strategies: 1. Industrial Constraint Modeling: Timing constraints: Define strict timing dependencies for API calls (e.g., "device lock → parameter delivery → device unlock" must be completed sequentially within 15 seconds); Security constraints: Security level matrix, L4 cannot call L1 / L2 / L3, and L3 cannot call L1 / L2; Deterministic constraints: Control API jitter <10ms, production execution API jitter <50ms.

[0033] 2. Constraint-aware GNN sub-model: Node characteristics: security level, device correlation, response time distribution (P50 / P95 / P99), jitter rate; Edge characteristics: Temporal dependency type (strict order / loose order / no dependency / mutual exclusion), business priority weight; Number of convolutional layers: 3, hidden layer dimension 128, Dropout rate 0.3.

[0034] 3. Constrained Reinforcement Learning (PPO Algorithm): The PPO algorithm uses graph features extracted by the constraint-aware GNN sub-model as state input, routing actions (selecting service instances and assigning weights) as action output, and a comprehensive reward function as the optimization objective. It iteratively optimizes the routing strategy through the policy gradient method. (1) Detailed calculation formulas for the four categories of scores: ① Response time score (S_response) S_response = max(0, min(1, 1- (T_actual - T_min) / (T_max - T_min))) in: T_actual: Actual response time (ms) T_min: The ideal response time for this security level API (L1=50ms, L2=100ms, L3=500ms, L4=2000ms) T_max: The maximum allowed response time for this security level API (T_min × 3) Normalization range: [0, 1], a larger value indicates a faster response. ② Success rate score (S_success) S_success = N_success / N_total in: N_success: The number of successful calls in the last 100 calls. N_total: Total number of calls (fixed at 100) Value range: [0, 1], the larger the value, the higher the success rate. ③ Safety compliance score (S_safety) S_safety = 1 if no violation else 0 Criteria for determining violation: Condition 1: A lower-level service calls a higher-level service (violating the security level matrix). Condition 2: The target instance of the route is in a temporary removal state. Condition 3: The routing action violates the timing dependency constraint. If any condition is met, it is considered a violation, and S_safety = 0. ④ Jitter penalty score (S_jitter) S_jitter = max(0, min(1, 1 - (J_actual -J_threshold) / J_threshold)) in: J_actual: Actual latency jitter (standard deviation, ms) J_threshold: Jitter threshold (control API = 10ms, production execution = 50ms) When J_actual ≤ J_threshold, S_jitter = 1 (no penalty). When J_actual > J_threshold, S_jitter ∈ [0, 1), and decreases linearly. Examples of score calculation for four categories (taking a Level 2 device control API as an example) Assumption: T_actual = 75ms, L2 level T_min=100ms, T_max=300ms 98 out of the last 100 calls were successful. No safety violations, no excessive jitter (J_actual=5ms < 10ms) Calculation process: S_response = 1 (75-100) / (300-100) = 1 (-25 / 200) = 1 + 0.125 = 1.125 → Truncate to 1.0 S_success = 98 / 100 = 0.98 S_safety = 1.0 S_jitter = 1.0 (because J_actual ≤ J_threshold) The total reward R = 0.3×1.0 + 0.4×0.98 + 0.2×1.0 + 0.1×1.0 = 0.3 + 0.392 + 0.2 + 0.1 = 0.992 No penalty term, R_final = 0.992 After normalization, it is approximately 0.99, which is considered a high-reward routing action.

[0035] (2) Comprehensive reward function: R = α × S_response + β × S_success + γ × S_safety + δ × S_jitter Weighting coefficients: α = 0.3 (response time weight) β = 0.4 (Success rate weight, highest priority) γ = 0.2 (Safety compliance weight) δ = 0.1 (jitter penalty weight) Constraint penalty terms (added directly to the reward function): Security violation: R_penalty = -1000 Jitter exceeds limit: R_penalty = -100 × (J_actual / J_threshold) Timeout violation: R_penalty = -200 × (T_actual / T_max) Final reward: R_final = R + R_penalty (3) Normalization of the reward function: R_normalized = (R_final -R_min) / (R_max - R_min) in: R_min = -1000 (Worst-case scenario: security violation + slowest response + 0% success rate) R_max = 1.0 (Optimal case: all four scores are 1, no penalty) Normalized range: [-1, 1] The purpose of the normalization process is to map the comprehensive reward value to a fixed interval [-1, 1], which facilitates the training convergence and policy comparison evaluation of the shadow model and the main model in step S4. The R_normalized is used as the final output data of step S3 and is input into step S4 to drive the iterative optimization of the shadow model and the main model.

[0036] (4) Constraint satisfaction mechanism: Before selecting an action, a valid action is screened using an industrial constraint filter. The probability of an action that violates the constraint is forcibly set to 0; Ensure that the RL strategy always explores within the safe and feasible domain.

[0037] Step S4: Incremental learning and grayscale validation of the shadow model; Based on the normalized comprehensive reward value R_normalized output in step S3, the new strategy is safely launched through multi-stage gray-scale verification: 1. Shadow Model Mechanism: The shadow model runs in parallel with the main model, performing "virtual routing" on API call requests, recording decisions but not executing them; The main model is the routing decision model trained in step S3 using a constraint-aware GNN sub-model as the policy network, a normalized comprehensive reward value R_normalized as the optimization objective, and the PPO algorithm. It is responsible for the routing decision of actual API requests. The shadow model is a copy model with the same network structure as the main model but with independently updated parameters. It is initialized or copied from the main model and uses the normalized comprehensive reward value R_normalized output in step S3 as the training reward signal. It is trained offline on historical call data or virtual routing decision trajectories. During the training process, no actual routing actions are performed. Only the virtual routing decision results are recorded for multi-stage grayscale comparison with the main model. 2. Multi-stage grayscale verification: Phase 1 (Offline Validation): Playback on 100,000 historical data points; the shadow model must outperform the main model by more than 10%. Phase 2 (Online Observation): Virtual routing for 6 hours, prediction accuracy >85%, decision difference <10%; Phase 3 (small-scale gray-scale): 1% → 5% → 10% → 25% → 50% of traffic, each phase lasts 4 hours, monitoring error rate / response time / security violations; Phase 4 (Full Switchover): No abnormalities during the gray-scale period, stable operation > full switchover after 24 hours.

[0038] Automatic rollback: If the error rate rises above 10% or any security violation occurs, automatically roll back to the main model within 5 seconds; Step S5: Multi-level sequence learner architecture and implementation; The routing decision system adopts a three-level sequence learner architecture, each responsible for routing optimization at different time scales, and outputs a final routing weight table. This final routing weight table is used to determine the API request routing ratio for each service instance. (1) First level: Short-term Adaptive Learner Scope of application: Routing adjustments at the second to minute level Input characteristics: Real-time API response time, error rate, jitter rate, current load Model structure: Lightweight LSTM network (2 layers, 64-dimensional hidden layers) Update frequency: Incremental update every 30 seconds Output: Real-time health score of the service instance (0-1 interval) Training data: Sliding window data from the last 5 minutes Application scenarios: Rapid response to sudden traffic surges and transient failures (2) Second level: Midterm Policy Learner Scope of application: Hourly routing policy optimization Input features: Health score timing, historical failure modes, and service priority weights from the first-level output. Model structure: GNN+PPO reinforcement learning (3-layer GCN, 128-dimensional hidden layers) Update frequency: Full training once per hour Output: Routing policy parameters (routing weight matrix for each service instance) Training data: Complete call chain data for the last 24 hours Application scenarios: handling periodic load fluctuations, preventative route optimization (3) Level 3: Longterm Causal Learner Scope of application: Reconstruction of causal graphs from the daily level to the weekly level. Input characteristics: medium- to long-term API call sequence, fault propagation records, and business change logs. Model structure: PC algorithm + Dynamic Bayesian Network (DBN) Update frequency: Full reconstruction of the causal graph every day during the early morning off-peak period. Output: The updated directed causal graph (node ​​attributes, edge weights, and failure propagation probabilities). Training data: Historical data from the last 30 days (minimum sample size 10,000 times) Application scenarios: Discovering new fault propagation paths and adapting to system architecture evolution. Three-level learner collaboration mechanism: Input: The current set of service instances S, which is obtained in real time by the API gateway through the service registry / service discovery module, includes all available service instances and their security level and business priority attributes; and real-time monitoring data metrics, including API response time, error rate, jitter rate and system load.

[0039] Output: The final routing weight table, routing_weights, is used to determine the proportion of API requests allocated to each service instance.

[0040] The processing flow is as follows: First-level processing: Invoke the LSTM network in the short-term adaptive learner, input the real-time monitoring data metrics for the last 5 minutes, and output the instant health score short_term_scores for each service instance; Second-level processing: Call the GNN+PPO model in the mid-term policy learner, input the current service instance set S and the health score time series output from the first level, and output the routing weight matrix mid_term_weights for each service instance; The third level of processing involves calling the causal graph and DBN model in the long-term causal learner, taking the current set of service instances S as input, and outputting the failure propagation probability causal_risks for each service instance. Decision fusion: For each service instance (service) in the set of service instances S, perform the following calculations: Get the instant health score output of the first level: w_short = short_term_scores[service], with a value range of 0 to 1; Get the routing weight factor w_mid = mid_term_weights[service] from the second-level output, with a value range of 0 to 1; Obtain the failure propagation probability of the third-level output, and calculate the risk avoidance weight w_long = 1 - causal_risks[service], with a value range of 0 to 1; The final route weight is calculated using the following fusion formula: final_weights[service] = 0.5 × w_short + 0.3 × w_mid + 0.2 × w_long Conflict resolution: When there is a conflict in the decisions of the three-level learners, the causal constraints of the third level shall be followed first (for the highest safety); specifically: if causal_risks[service] > 0.7 and final_weights[service] > 0.5, then final_weights[service] shall be adjusted to final_weights[service] × 0.1 and the conflict shall be recorded in the conflict log. Security filter: For each service instance, check whether its routing weights violate industry constraints; if they violate security constraints, set final_weights[service] = 0 and log the security violation. Abnormal Degradation: When any level of learner fails, the following fallback strategy is executed: If the short-term adaptive learner fails, the output of the mid-term policy learner is used as the final route weight. If the intermediate policy learner fails, the output of the long-term causal learner is used as the final route weight. If the long-term causal learner fails, then assign the lowest uniform weights emergency_weights(S) to all service instances. Returns the final route weight table: routing_weights = final_weights.

[0041] Data flow: Level 1 → Level 2 → Level 3, aggregating features level by level. Decision Fusion: Final Route Weight = 0.5 × Level 1 Score + 0.3 × Level 2 Policy + 0.2 × Level 3 Causal Prediction Conflict resolution: When the three-level learners make conflicting decisions, the causal constraints of the third level take precedence (for the highest level of safety). Fallback mechanism: When any level of learner malfunctions, it automatically downgrades to the stable strategy of the previous level. Technical advantages: Multi-timescale coverage: second-level response + hour-level optimization + day-level evolution; Computational efficiency stratification: Lightweight models handle high-frequency requests, while heavyweight models are trained offline; High robustness: a single-level failure does not affect the overall system operation; The key technical parameters involved in this embodiment are shown in Table 1 below; Table 1 Key Technical Parameters

[0042] Working principle: Proactive prediction and avoidance of cascading failures: Compared with traditional passive response, this paper illustrates the 83.3% failure reduction effect brought about by cause-effect graph + DBN prediction, and uses specific loss figures from a wafer fab example to support the evidence. Integrating Industrial Constraints into Routing Decisions: This section explains how constraint modeling and filters can reduce the violation rate to 0% for three types of problems: timing violations, security violations, and excessive jitter. Improved response performance and deterministic latency: Explaining why traditional load balancing cannot meet the <10ms jitter requirement, and how this solution achieves a 38.8% response improvement; Shadow Model Eliminates Update Risks: Explaining how four-stage grayscale verification and 5-second automatic rollback reduce model update failures from 3 times / year to 0; Wide Applicability and Scalability: Explaining the three-layer decoupled architecture, multiple algorithm alternatives, and cross-industry applicable scenarios;

[0043] The other parts of this embodiment are the same as those in Embodiment 1 above, so they will not be described again.

[0044] Example 3: This embodiment is based on any one of the above embodiments 1-2, and takes the API routing optimization of a semiconductor MES system as an example for detailed explanation.

[0045] System background: A 12-inch semiconductor wafer fab has 115+ microservices including MES, WMS, SPC, and EAP, with an average of 10 million API calls per day.

[0046] Fault scenario (May 10, 2026, 14:32:15): The device-control-service response time increased from P95=80ms to 350ms, and the error rate increased from 0.1% to 2.3%.

[0047] Traditional API gateway processing: Continuing with load balancing routing, 12 downstream services timed out one after another, causing 3 production lines to shut down for 45 minutes, resulting in a loss of 375,000 yuan.

[0048] The system processing procedure of this invention: T0 (14:30:00): Cause-effect graph (built offline) device-control → workorder-execution (causality strength 0.82, delay 2-5s) device-control → device-status (causality strength 0.76, delay 1-3s) workorder-execution → batch-tracking (causality strength 0.68, latency 5-10s) T0+2s (14:32:17): Anomaly detection The response time P95 increased from 80ms to 350ms after 5 consecutive samplings, and an anomaly was determined.

[0049] T0+3s (14:32:18): Fault propagation prediction The probability of a workorder-execution failure is 78%, with an expected failure time of T0+15s. The probability of device-status failure is 65%, and failure is expected in T0+30s. The probability of batch-tracking failure is 52%, with an expected failure time of T0+45s.

[0050] T0+4s (14:32:19): Active route avoidance device-control-service weight: 1.0 → 0.1 (reduced by 90%). L1 / L2 level API: 100% routed to the standby instance; Level 4 API: Allows for a 5-10 second delay in queuing.

[0051] T0+60s (14:33:15): Effect Verification All downstream services responded normally, with no cascading failures, and the production line was operating normally.

[0052] Comparison results:

[0053] This article will provide a detailed explanation using industrial constraint routing optimization (CVD equipment parameter distribution) as an example.

[0054] API call chain (strict timing constraints): 1. Device lock (L2) → Must be completed within 5 seconds 2. parameter-download (L2) → Must be completed within 10 seconds 3. Device unlock (L2) → Total duration < 15 seconds Problems with traditional GNN+RL routing: The timing constraint violation rate is 12% (device-lock and parameter-download intervals exceed the 5-second limit). Security constraint violation: 5 times / month (L3 service calling L2 API); The jitter exceedance rate is 18% (control API jitter exceeds the 10ms limit).

[0055] This invention relates to constraint-aware routing: Constraint filtering: device-lock-service-B (judder rate exceeding 15%) is filtered out, service-A (judder rate 3%) is selected. Reward calculation: R = 0.3 × 0.2 + 0.4 × 0.999 + 0.2 × 1.0 + 0.1 × 0.97 = 0.757 (high reward); Results: 0% time constraint violation rate, 0 safety violations per month, and 3% jitter exceedance rate.

[0056] Shadow model grayscale validation (model updated after 3 months of system operation) Offline verification (2 hours): The shadow model had a response time of 52ms (compared to 85ms for the main model, a decrease of 38.8%), a success rate of 98.5% (compared to 97.2% for the main model), and 0 security violations. Conclusion: Offline verification passed.

[0057] Online observation (6 hours): 3 million virtual routing tests were conducted, with a prediction accuracy of 87% (>85% threshold), a decision discrepancy of 10%, and no security violations. Conclusion: Based on online observation.

[0058] Small-scale grayscale testing (24 hours, 1% → 50%): Error rate at each stage: 0.08-0.11% (0.10% for the main model); response time: 48-53ms; 0 security violations. Conclusion: Gray-scale verification passed.

[0059] Data from the 7 days following the full switchover: Response time 52ms (down 38.8%), fault propagation 2 times / month (down 83.3%), safety violations 0 times / month, jitter rate 3% (down 15 percentage points).

[0060] The other parts of this embodiment are the same as any one of the above embodiments 1-2, so they will not be described again.

[0061] Example 4: Based on any one of Embodiments 1-3 above, and based on the above-proposed adaptive API gateway intelligent routing method for industrial software systems, in order to better realize the present invention, an adaptive API gateway intelligent routing system for industrial software systems is further proposed, which is used to execute the above-proposed adaptive API gateway intelligent routing method for industrial software systems, including a cause-effect graph construction unit, a fault propagation prediction unit, a constraint construction unit, a multi-stage grayscale verification unit, and an optimization unit. The cause-effect graph construction unit is used to collect API call data and call the PC algorithm to construct a directed cause-effect graph between services; The fault propagation prediction unit is used to predict and avoid fault propagation based on the directed cause-effect graph between services and the set anomaly detection triggering conditions. The constraint construction unit is used to construct industrial constraints based on the avoided route, obtain a comprehensive reward function, and normalize it. The multi-stage grayscale verification unit is used to call the main model and shadow model constructed in step S3 to run in parallel, perform virtual routing on the API call requests received by the API gateway in real time, and perform multi-stage grayscale verification. The optimization unit is used to employ a three-level sequence learner architecture, each responsible for routing optimization at different time scales.

[0062] Based on the above-mentioned adaptive API gateway intelligent routing method for industrial software systems, in order to better realize the present invention, an electronic device is further proposed, including a memory and a processor, wherein a computer program is stored on the memory; when the computer program is executed on the processor, the above-mentioned adaptive API gateway intelligent routing method for industrial software systems is implemented.

[0063] Based on the aforementioned adaptive API gateway intelligent routing method for industrial software systems, and to better realize this invention, a computer-readable storage medium is further proposed, wherein computer instructions are stored on the computer-readable storage medium; when the computer instructions are executed on the aforementioned electronic device, the aforementioned adaptive API gateway intelligent routing method for industrial software systems is implemented.

[0064] The other parts of this embodiment are the same as any one of the embodiments 1-3 above, so they will not be described again.

[0065] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Any simple modifications or equivalent changes made to the above embodiments based on the technical essence of the present invention shall fall within the protection scope of the present invention.

Claims

1. An adaptive API gateway intelligent routing method for industrial software systems, characterized in that, Specifically, the following steps are included: Step S1: Collect API call data and use the PC algorithm to construct a directed cause-effect graph between services; Step S2: Based on the directed cause-effect graph between services and the set anomaly detection trigger conditions, obtain the bypassed route; Step S3: Based on the avoided route, construct industrial constraints, and construct a constraint-aware GNN sub-model based on the industrial constraints to obtain the reward function and normalize it to obtain the normalized reward value. Step S4: Initialize the constraint-aware GNN sub-model based on the normalized comprehensive reward value to obtain the shadow model. Run the constraint-aware GNN sub-model and the shadow model in parallel, perform virtual routing on API call data, and conduct multi-stage grayscale verification. Step S5: Based on the grayscale verification results and the constructed three-level sequence learner architecture, distribute the data to the corresponding service instances according to the set ratio to complete intelligent routing.

2. The adaptive API gateway intelligent routing method for industrial software systems according to claim 1, characterized in that, Step S1 specifically includes the following steps: Step S11: Collect API call data; the API call data includes historical call records and real-time API request streams. The historical call records include call timestamps, response times, and business priorities, which are used for cause-effect graph construction and model training. The real-time API request stream consists of API call requests received from the API gateway. Step S12: Obtain the security level of the service instance based on the business priority mapping, and calculate the Granger causality coefficient based on the call timestamp and response time; Step S13: Use the security level of the service instance as a node attribute and the Granger causality coefficient as an edge attribute, and call the PC algorithm to construct a directed causal graph between services; the incoming edge of the directed causal graph between services is a directed edge pointing to the current service in the causal graph, the service corresponding to the starting node of the incoming edge is the upstream service, and the outgoing edge of the directed causal graph between services is a directed edge pointing from the current service to the downstream service.

3. The adaptive API gateway intelligent routing method for industrial software systems according to claim 1, characterized in that, Step S2 specifically includes the following steps: Step S21: Based on the currently effective directed causal graph between services and the set anomaly detection triggering conditions, retrieve the edges, downstream service list, and Granger causality coefficient of the current abnormal service; Step S22: Based on the downstream service list, call the DBN model to predict the failure probability and obtain the real-time health status of the downstream services; Step S23: Determine the current risk level based on the real-time health status of downstream services, and execute the corresponding routing adjustment strategy according to the risk level; Step S24: Calculate the prediction accuracy based on the real-time health status of the adjusted downstream services. If the prediction accuracy is less than the set threshold, adjust the DBN model parameters to obtain the routing adjustment strategy after avoidance and record it in the fault mode library.

4. The adaptive API gateway intelligent routing method for industrial software systems according to claim 1, characterized in that, Step S3 specifically includes the following steps: Step S31: Construct industrial constraints based on the routing adjustment strategy after avoidance; Step S32: Based on the constructed industrial constraints, the safety level is used as the node feature, and the Granger causality coefficient, temporal dependency type, and business priority weight are used as the edge features. The constraint-aware GNN sub-model in the mid-term policy learner is constructed according to the set number of graph convolutional layers. Step S33: Based on the constructed constraint-aware GNN sub-model, calculate the response time score, success rate score, security compliance score, and jitter penalty score; Step S34: Based on the set weight coefficients, response time score, success rate score, security compliance score, and jitter penalty score, construct a comprehensive reward function and normalize it to obtain the normalized comprehensive reward value.

5. The adaptive API gateway intelligent routing method for industrial software systems according to claim 2, characterized in that, Step S4 specifically includes the following steps: Step S41: Initialize the constraint-aware GNN sub-model based on the normalized comprehensive reward value to obtain the shadow model; Step S42: Run the constraint-aware GNN sub-model and the shadow model in parallel, perform virtual routing on the collected API call requests, record the virtual routing decision results but do not actually forward the API call requests; Step S43: Based on the virtual routing decision results, perform multi-stage grayscale verification on the shadow model and the constraint-aware GNN sub-model to obtain the verification results; Step S44: Perform a rollback operation based on the verification results.

6. The adaptive API gateway intelligent routing method for industrial software systems according to claim 2, characterized in that, Step S5 specifically includes the following steps: Step S51: Input the acquired real-time monitoring data into the LSTM network in the short-term adaptive learner to obtain the instant health score of the service instance; Step S52: Input the current service instance set S and the real-time health score into the constraint-aware GNN sub-model in the mid-term policy learner to obtain the routing weight matrix of the service instances; Step S53: Calculate the risk avoidance weight based on the failure probability, and according to the set weight factor, weight and risk avoidance weight of the service instance are weighted and fused to obtain the final routing weight table. If there is a security constraint conflict, the final routing weight of the current service instance is reset to 0 and the conflict log is recorded. Step S55: Based on the weight ratio of each service instance in the final routing weight table, distribute API call requests proportionally to the corresponding service instances to achieve intelligent routing.

7. An adaptive API gateway intelligent routing system for industrial software systems, used to execute the adaptive API gateway intelligent routing method for industrial software systems as described in claim 1, characterized in that... It includes a cause-effect graph construction unit, a fault propagation prediction unit, a constraint construction unit, a multi-stage grayscale verification unit, and an optimization unit; The cause-effect graph construction unit is used to collect API call data and call the PC algorithm to construct a directed cause-effect graph between services; The fault propagation prediction unit is used to obtain the evaded route based on the directed cause-effect graph between services and the set anomaly detection triggering conditions. The constraint construction unit is used to construct industrial constraints based on the avoided route, construct a constraint-aware GNN sub-model based on the industrial constraints, obtain a reward function and normalize it to obtain a normalized reward value. The multi-stage grayscale verification unit is used to initialize the constraint-aware GNN sub-model to obtain the shadow model based on the normalized comprehensive reward value, run the constraint-aware GNN sub-model and the shadow model in parallel, perform virtual routing of API call requests obtained from the API gateway, and perform multi-stage grayscale verification. The optimization unit is used to distribute the data to the corresponding service instances according to a set ratio based on the grayscale verification results and the constructed three-level sequence learner architecture, thereby completing intelligent routing.

8. An electronic device, characterized in that, The memory includes a memory and a processor, on which a computer program is stored; when the computer program is executed on the processor, it implements an adaptive API gateway intelligent routing method for an industrial software system as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions; when the computer instructions are executed on the electronic device as described in claim 8, they implement an adaptive API gateway intelligent routing method for an industrial software system as described in any one of claims 1-6.

Images