Decentralized flow management gateway system

Abstract

The embodiment of the invention provides a decentralized flow management gateway system. Comprising a control layer used for sending an increment instruction which carries update strategy information; the gateway node layer comprises a plurality of autonomous gateway nodes, a mesh topology structure is formed among the plurality of autonomous gateway nodes, and a local strategy is stored in each autonomous gateway node; wherein under the condition that any one autonomous gateway node receives an increment instruction, the local strategy of the autonomous gateway node is updated based on the increment instruction, and the increment instruction is sent to other autonomous gateway nodes through a decentration algorithm; and the other autonomous gateway nodes update the local strategies of the other autonomous gateway nodes based on the increment instruction. Through application of the method and the device, the problem that a single-point fault risk exists when a centralized control architecture updates the policy of the gateway node in a large-scale distributed environment in related technologies is solved, and the effect of reducing the single-point fault risk when the policy of the gateway node is updated is further realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and in particular, to a decentralized traffic management gateway system. BACKGROUND

[0002] With the advent of the 5G and Internet of Things era, the generation of massive data and task computing have a great impact on the existing network. Although cloud computing provides extensive access to virtual shared resources, it cannot meet the requirements of high-speed access and ultra-low latency applications and massive terminal interconnection scenarios. Therefore, the industry proposes to migrate the cloud computing platform to the network edge, that is, edge computing, to provide edge services near the data source. In the Internet of Things and large traffic scenarios, in order to meet the needs of wider connectivity, lower latency, and better control, cloud computing is advancing to a more global distributed node combination form, and edge computing is a new touch of its distributed expansion to the edge side.

[0003] The traditional traffic management gateway adopts a centralized control architecture, and all decisions and distribution of configurations depend on the center node. Such an architecture has a single point of failure risk in a large-scale distributed environment, and the processing capacity of the center node becomes a bottleneck for system expansion, making it difficult to support the dynamic access of massive edge nodes and high-concurrency traffic processing requirements. SUMMARY

[0004] The embodiments of the present application provide a decentralized traffic management gateway system to at least solve the problem of single point of failure risk when updating the strategy of the gateway node in a large-scale distributed environment in the centralized control architecture in the related technology.

[0005] According to an embodiment of the present application, a decentralized traffic management gateway system is provided, comprising:

[0006] A control layer for sending an incremental instruction, wherein the incremental instruction carries update strategy information;

[0007] A gateway node layer comprising a plurality of autonomous gateway nodes, a mesh topology formed between the plurality of autonomous gateway nodes, and each autonomous gateway node storing a local strategy; wherein, in the case that any one autonomous gateway node receives the incremental instruction, the local strategy of the autonomous gateway node is updated based on the incremental instruction, and the incremental instruction is sent to other autonomous gateway nodes through a decentralized algorithm, so that the local strategy of the other autonomous gateway nodes is updated based on the incremental instruction.

[0008] In an embodiment, the system further comprises:

[0009] An edge node layer comprising at least one edge processing node configured to receive service data sent by any one of the autonomous gateway nodes, wherein the service data is obtained by the autonomous gateway node based on a traffic request through the local policy.

[0010] In an embodiment, the control layer comprises:

[0011] A control management module configured to generate the incremental instruction in response to a policy update instruction, and send the incremental instruction to the autonomous gateway node.

[0012] In an embodiment, the control layer further comprises:

[0013] An information statistics module configured to collect decision data of the plurality of autonomous gateway nodes, wherein the decision data comprises traffic feature data, processing result data, and response delay data.

[0014] An AI algorithm module configured to learn and analyze the decision data to generate an optimized policy, and integrate the optimized policy into the incremental instruction, and send the incremental instruction to the autonomous gateway node.

[0015] In an embodiment, the control layer further comprises:

[0016] A version management module configured to store historical data generated by the autonomous gateway node, the control management module, the AI algorithm module, and the information statistics module, so that the control management module and the AI algorithm module can real-time access the historical data.

[0017] In an embodiment, the autonomous gateway node comprises:

[0018] An access management module configured to receive a traffic request, encapsulate the traffic request as a standardized internal event, and deliver the internal event to an event bus.

[0019] The event bus.

[0020] A state management module configured to store local state information of the autonomous gateway node that can be merged using a CRDT data structure, and synchronize state of any one of the autonomous gateway nodes with other autonomous gateway nodes based on the CRDT data structure, wherein the local state information comprises policy configuration, traffic statistics, a neighbor node list, and a threat feature library.

[0021] A local state database configured to store the local state information.

[0022] A collaborative communication module configured to enable any autonomous gateway node to communicate with other autonomous gateway nodes in a peer-to-peer manner or in a broadcast manner based on the decentralized algorithm;

[0023] A network layer;

[0024] A processing pipeline including a plurality of processing stages in series or in parallel, configured to sequentially pass a traffic request through the plurality of processing stages, and configured to enable each processing stage to perform a processing operation on the traffic request; wherein the processing operation includes a pass operation, a modification operation, an interception operation, and a forwarding operation;

[0025] A decision engine module including a rule engine and a local AI inference module, configured to integrate detection results of the processing stages and historical data to obtain a decision result, wherein the decision result includes a decision instruction and a processing parameter corresponding to the decision instruction, and the decision instruction includes a pass, a throttling, a fuse, a degradation, and an interception;

[0026] A feedback collection module configured to record multi-dimensional decision data of each traffic request, and configured to report the multi-dimensional decision data to the AI algorithm module through the information statistics module, so as to enable the AI algorithm module to perform offline training and policy optimization based on the multi-dimensional decision data.

[0027] In an embodiment, the collaborative communication module includes:

[0028] A gossip propagation engine configured to periodically and randomly select a neighboring autonomous gateway node, and configured to exchange a state digest and a delta update with the neighboring autonomous gateway node, so as to achieve probabilistic propagation of information;

[0029] A DHT lookup engine configured to locate the autonomous gateway node where a resource is located based on a distributed hash table algorithm;

[0030] A CRDT synchronization engine configured to use a merge operator of CRDT to process a state merge request between the autonomous gateway nodes, so as to make the states of the plurality of autonomous gateway nodes consistent.

[0031] In an embodiment, the CRDT data structure includes:

[0032] A throttling counter configured to maintain independent increments and decrements for each autonomous gateway node, and configured to sum the increments and the decrements of all the autonomous gateway nodes to obtain a global count value when merging;

[0033] A restriction list set configured to assign a unique identifier to each element, add an operation record element and the identifier, and delete an operation record of a deleted identifier, and configured to take a union set and remove deleted elements when merging;

[0034] Configuration mapping table is configured to attach a timestamp to each key-value pair, and the latest value is retained when merging.

[0035] In an embodiment, the AI algorithm module comprises:

[0036] A throttling threshold optimization model is used to obtain a throttling threshold based on historical traffic rates, backend response times, and system loads through a reinforcement learning algorithm.

[0037] A cache strategy optimization model is used to obtain cache priority and replica quantity based on resource access frequency, size, TTL, and hit rate through a collaborative filtering model or a deep learning model.

[0038] A threat detection model is used to obtain a threat probability based on a traffic request feature vector through supervised learning to train a classifier or unsupervised learning to train a classifier.

[0039] A load prediction model is used to obtain traffic prediction for a future time window based on historical traffic time series through a time series model.

[0040] In an embodiment, the processing pipeline comprises:

[0041] A cache acceleration stage is used to store cache data in multiple nodes based on a DHT algorithm after hashing, thereby reducing backend service load and response delay.

[0042] A rate control stage is used to maintain a local share of a global throttling quota for each autonomous gateway node based on a token bucket algorithm, wherein the local share is obtained through a Raft consensus or a proportional allocation algorithm.

[0043] A behavior analysis stage is used to extract a multi-dimensional feature vector from a traffic request, wherein the multi-dimensional feature vector includes traffic request frequency, time interval distribution, access path sequence, parameter features, and User-Agent features; and a normal behavior baseline is established based on historical normal traffic using statistical methods or machine learning methods; and a real-time feature vector is compared with the normal behavior baseline to calculate an anomaly score, wherein if the anomaly score is greater than or equal to a preset threshold, the real-time feature vector is marked as a suspicious traffic request feature; and the suspicious traffic request feature is matched with a threat intelligence library, and if the match is successful, the traffic request is confirmed as a threat.

[0044] A content detection stage is used to perform fine-grained inspection on the traffic request and response content to discover hidden threats; wherein the fine-grained inspection includes protocol analysis, signature matching, semantic analysis, and file detection.

[0045] Through one of the embodiments of the present application, the control layer only undertakes the sending responsibility of the incremental instruction (carrying the update strategy information), and no longer serves as the only core of the strategy distribution, breaking the monopolistic dependence on the center node in the centralized architecture; the gateway node layer is composed of multiple autonomous gateway nodes and forms a mesh topology structure, each autonomous gateway node stores a local strategy and has independent processing capability, when any autonomous gateway node receives the incremental instruction, it can not only update its own local strategy autonomously, but also forward the incremental instruction to other autonomous gateway nodes through a decentralized algorithm, so that all nodes can complete the strategy update, the whole process does not need to rely on a single center node, even if part of the nodes fail, the incremental instruction can still be transmitted through other paths in the mesh topology, thereby completely avoiding the risk of strategy update interruption caused by the failure of the center node in the centralized architecture, so as to realize the effect of reducing the single point failure risk of the gateway node in updating the strategy in the large-scale distributed environment. BRIEF DESCRIPTION OF DRAWINGS

[0046] The drawings described herein are used to provide further understanding of the present application, constitute a part of the present application, the illustrative embodiments of the present application and the description thereof are used to explain the present application, and do not constitute improper limitation on the present application. In the drawings:

[0047] Figure 1 is the structure block of the decentralized traffic management gateway system of the embodiment of the present application Figure 1 ;

[0048] Figure 2 is the structure block of the decentralized traffic management gateway system of the embodiment of the present application Figure 2 ;

[0049] Figure 3 is the structure block of the decentralized traffic management gateway system of the embodiment of the present application Figure 3 ;

[0050] Figure 4 is the structure block diagram of the autonomous gateway node of the embodiment of the present application;

[0051] Figure 5 is the structure block diagram of the cooperative communication module of the embodiment of the present application;

[0052] Figure 6 is the structure block diagram of the CRDT data structure of the embodiment of the present application;

[0053] Figure 7 is the structure block diagram of the AI algorithm module of the embodiment of the present application;

[0054] Figure 8 is the structure block diagram of the processing pipeline of the embodiment of the present application;

[0055] Figure 9is an internal information flow conversion schematic diagram of a processing pipeline of an embodiment of the present application;

[0056] Figure 10 is a Gossip protocol information propagation timing diagram of an embodiment of the present application;

[0057] Figure 11 is a signaling diagram in a system of an embodiment of the present application in which a new node joins the network;

[0058] Figure 12 is a flow chart of a processing method of a single request of an embodiment of the present application;

[0059] Figure 13 is a flow chart of a threat detection and collaborative interception method of an embodiment of the present application;

[0060] Figure 14 is a flow chart of a method of continuously collecting data, training a model, and optimizing a strategy of a system of an embodiment of the present application. DETAILED DESCRIPTION

[0061] Hereinafter, the present application will be described in detail with reference to the accompanying drawings and in conjunction with embodiments. It should be noted that the embodiments in the present application and the features in the embodiments can be combined with each other without conflict.

[0062] It should be noted that the terms “first”, “second”, etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily describe a specific order or sequence.

[0063] In an embodiment of the present application, a decentralized traffic management gateway system is provided, Figure 1 is a structural block of a decentralized traffic management gateway system of an embodiment of the present application Figure 1 As shown in Figure 1 The system comprises:

[0064] a control layer configured to send an incremental instruction, wherein the incremental instruction carries update policy information;

[0065] In an exemplary embodiment, the control layer does not maintain the complete state of each node, and does not perform full calculation and distribution of the policy, thereby reducing the calculation complexity and network overhead to a constant level.

[0066] The gateway node layer consists of multiple autonomous gateway nodes forming a mesh topology. Each autonomous gateway node stores its local policy. When any autonomous gateway node receives an incremental instruction, it updates its local policy based on the incremental instruction and sends the incremental instruction to other autonomous gateway nodes through a decentralized algorithm, so that the other autonomous gateway nodes can update their local policies based on the incremental instruction.

[0067] In one exemplary implementation, the gateway node layer consists of multiple autonomous gateway nodes, each possessing complete traffic processing capabilities and autonomous decision-making abilities. The autonomous gateway nodes form a mesh topology, ensuring that the failure of any node does not affect the normal operation of other nodes. For example, autonomous gateway nodes can communicate via the Gossip protocol, synchronize states through the CRDT mechanism, and discover nodes and locate resources using the DHT algorithm.

[0068] By adopting the above technical solution, the control layer only undertakes the responsibility of sending incremental instructions (carrying updated policy information) and is no longer the sole core of policy distribution, breaking the monopolistic dependence on the central node in the centralized architecture. The gateway node layer consists of multiple autonomous gateway nodes forming a mesh topology. Each autonomous gateway node stores its local policy and has independent processing capabilities. When any autonomous gateway node receives an incremental instruction, it can not only update its own local policy, but also forward the incremental instruction to other autonomous gateway nodes through a decentralized algorithm, so that all nodes can complete the policy update. The whole process does not rely on a single central node. Even if some nodes fail, the incremental instruction can still be transmitted through other paths in the mesh topology, thereby completely avoiding the risk of policy update interruption caused by the failure of the central node in the centralized architecture. This achieves the effect of reducing the risk of single point of failure when the gateway node updates the policy in a large-scale distributed environment.

[0069] Figure 2 This is the structural framework of the decentralized traffic governance gateway system according to an embodiment of this application. Figure 2 ,like Figure 2 As shown, in one embodiment, the system further includes an edge node layer, comprising at least one edge processing node, which is used to receive service data sent by any autonomous gateway node, wherein the service data is obtained by the autonomous gateway node based on traffic requests through local policies.

[0070] In one exemplary implementation, edge processing nodes are deployed at the network edge to process terminal traffic locally. Edge processing nodes can be lightweight gateway nodes or proxy nodes with partial processing capabilities. They report traffic characteristics and threat information to the gateway node layer and receive policy synchronization (service data) from autonomous gateway nodes within that layer.

[0071] Figure 3 This is the structural framework of the decentralized traffic governance gateway system according to an embodiment of this application. Figure 3 ,like Figure 4 As shown, in one embodiment, the control layer includes:

[0072] The control and management module is used to generate incremental instructions in response to policy update commands, and to send the incremental instructions to the autonomous gateway node.

[0073] In one exemplary implementation, for example, the control management module is responsible for managing the global policy version number and node registration information. In response to a policy update command, it generates an incremental command and sends the incremental command to the autonomous gateway node.

[0074] In one implementation, the control layer further includes:

[0075] The information statistics module is used to collect decision data from multiple autonomous gateway nodes. The decision data includes: traffic characteristic data, processing result data, and response latency data.

[0076] In one exemplary implementation, for example, the information statistics module can connect to each autonomous gateway node through a data interface to collect decision data from each autonomous gateway node and aggregate the decision data to the AI ​​algorithm module.

[0077] The AI ​​algorithm module is used to learn and analyze decision data to generate optimization strategies, and integrate the optimization strategies into incremental instructions to send the incremental instructions to the autonomous gateway node.

[0078] In one exemplary implementation, the decision data reported by each autonomous gateway node is learned and analyzed to generate an optimization strategy, and the optimization strategy is integrated into an incremental instruction to send the incremental instruction to the autonomous gateway node.

[0079] In one implementation, the control layer further includes:

[0080] The version management module is used to store historical data generated by the autonomous gateway node, control management module, AI algorithm module, and information statistics module, so that the control management module and AI algorithm module can retrieve historical data in real time.

[0081] In one exemplary implementation, for example, the control layer employs a minimal responsibility design, with its core functions being maintaining the global policy version and issuing incremental update commands. The version management module maintains a policy version chain, where each version includes a version number, timestamp, incremental update content, and a pointer to the previous version. Specifically, an example of a version management data structure is as follows:

[0082] "Strategy version record = {

[0083] Version number: Integer (monotonically increasing)

[0084] Timestamp: Timestamp

[0085] Update type: Enumeration (Full / Incremental / Rollback)

[0086] Incremental content: byte array

[0087] Previous version number: integer

[0088] Signature: Digital signature (used for verification).

[0089] Therefore, when a policy update is needed, the control layer only generates a new version number and an incremental instruction. The incremental instruction describes the differences compared to the previous version and can be in JSON Patch or Protocol Buffer format, with a size between 1-10KB. The control layer sends version update notifications to some autonomous gateway nodes through a lightweight messaging channel. Autonomous gateway nodes that receive the notification will propagate the new version to the entire network via the Gossip protocol.

[0090] The control layer incorporates an incremental update mechanism. For example, upon receiving a new version number, an autonomous gateway node first checks its local version number. If the local version is outdated, it calculates the missing version differences based on the version chain. If the number of version differences is less than a threshold (e.g., 3), it uses the DHT to find the autonomous gateway node holding the latest version, pulls the incremental patch, and applies it sequentially. If the number of version differences exceeds the threshold, it pulls the full baseline policy from the control layer. Therefore, this mechanism ensures that, in most cases, policy synchronization between autonomous gateway nodes only requires the transmission of minimal incremental data.

[0091] Figure 4 This is a structural block diagram of the autonomous gateway node in an embodiment of this application, as shown below. Figure 5 As shown, in one embodiment, the autonomous gateway node includes:

[0092] The access management module is used to receive traffic requests, encapsulate the traffic requests into standardized internal events, and deliver the internal events to the event bus.

[0093] In one exemplary implementation, the access management module is responsible for receiving traffic requests from clients or downstream nodes, performing protocol parsing and preliminary classification, and encapsulating the requests into standardized internal events and delivering them to the event bus.

[0094] Event bus;

[0095] The state management module is used to store the local state information of autonomous gateway nodes that can be merged using the CRDT data structure, so that any autonomous gateway node can synchronize its state with other autonomous gateway nodes based on the CRDT data structure; the local state information includes: policy configuration, traffic statistics, neighbor node list, and threat signature database;

[0096] In one exemplary implementation, the state management module maintains local state information for nodes, including policy configurations, traffic statistics, a list of neighboring nodes, and a threat signature database. This module uses a CRDT data structure to store mergeable states, supporting conflict-free state synchronization with other nodes. State data is persisted to a local state database, supporting fast queries and atomic updates.

[0097] A local state database is used to store local state information;

[0098] The collaborative communication module is used to enable any autonomous gateway node to conduct point-to-point communication and broadcast communication with other autonomous gateway nodes based on a decentralized algorithm;

[0099] In one exemplary implementation, the collaborative communication module is capable of enabling point-to-point communication and broadcast communication with other nodes.

[0100] Network layer;

[0101] A processing pipeline includes multiple serial or parallel processing stages, so that traffic requests pass through multiple processing stages sequentially, and each processing stage performs processing operations on the traffic requests; wherein, the processing operations include: allowing operations, modifying operations, intercepting operations, and forwarding operations;

[0102] In one exemplary implementation, the processing pipeline comprises multiple serial or parallel processing stages, each focusing on a specific traffic governance function. The pipeline employs a chain-of-responsibility pattern, with requests passing sequentially through each processing stage, where each stage can choose to allow, modify, block, or forward the request.

[0103] The decision engine module, including the rule engine and the local AI inference module, is used to integrate the detection results and historical data of various processing levels to obtain decision results. The decision results include decision instructions and processing parameters corresponding to the decision instructions. The decision instructions include: allow, limit, circuit breaker, downgrade, and block.

[0104] In one exemplary implementation, the decision engine module can integrate detection results and historical data from each processing level to make a final decision based on the rule engine and the local AI inference module. The decision results include: allowing, rate limiting, circuit breaking, downgrading, blocking, etc., as well as corresponding processing parameters (such as rate limiting rate, circuit breaking duration, etc.).

[0105] The feedback acquisition module records multidimensional decision data for each traffic request and reports this multidimensional decision data to the AI ​​algorithm module through the information statistics module, so that the AI ​​algorithm module can perform offline training and strategy optimization based on the multidimensional decision data.

[0106] In one exemplary implementation, the feedback acquisition module can record multi-dimensional decision data for each request, including request feature vectors, judgment results at each processing level, final decision, processing latency, resource consumption, and other information. This data is asynchronously reported in batches to the AI ​​algorithm module of the control layer for offline training and policy optimization.

[0107] Figure 5 This is a structural block diagram of the collaborative communication module according to an embodiment of this application, as shown below. Figure 6 As shown, in one embodiment, the cooperative communication module includes:

[0108] Gossip propagation engine: used to periodically and randomly select neighboring autonomous gateway nodes, exchange state summaries and incremental updates with neighboring autonomous gateway nodes, so as to achieve probabilistic propagation of information;

[0109] DHT lookup engine: used to locate the autonomous gateway node where a resource is located based on a distributed hash table algorithm;

[0110] In one exemplary implementation, a Distributed Hash Table (DHT) is used to quickly locate the Autonomous Gateway Node (AGN) where a specific resource resides, supporting efficient resource lookup and load balancing. This application's embodiments employ a variant of the Kademlia protocol. For example, DHT design elements may include: assigning each AGN a 160-bit AGN ID (generated via the SHA-1 hash of the AGN's public key); assigning each resource (such as policy version, cached data) a 160-bit resource key (generated via the hash of the resource content); calculating the "distance" between the AGN ID and the resource key using an XOR metric; the K nearest AGN nodes (K is typically 3-5) are responsible for storing copies of the resource; and each AGN maintains a routing table (K-buckets) that hierarchically stores information about known neighboring AGN nodes by distance.

[0111] The general process of resource lookup based on DHT is as follows:

[0112] S1. Autonomous gateway node A needs to find the resource with resource key K;

[0113] S2. Calculate the nearest node to K in the local routing table. One autonomous gateway node ( Usually 3);

[0114] S3, Towards this Each autonomous gateway node sends a lookup request concurrently;

[0115] S4. Receive the list of autonomous gateway nodes that are closer to K as known to the autonomous gateway nodes.

[0116] S5. Repeat steps S1 to S4, each time selecting the autonomous gateway node closer to K, until an autonomous gateway node storing resource K is found or it is no longer possible to get closer.

[0117] S6. Obtain complete data for resource K from the storage autonomous gateway node.

[0118] Therefore, in this embodiment of the application, using DHT, the search complexity in a network of N autonomous gateway nodes is O(log N), and each autonomous gateway node only needs to store O(log N) routing information. When autonomous gateway nodes dynamically join and leave, the system automatically rebalances resource distribution without the need for central coordination.

[0119] CRDT Synchronization Engine: Used to process state merging requests between autonomous gateway nodes using CRDT merge operators to ensure consistency of state among multiple autonomous gateway nodes.

[0120] Figure 6 This is a structural block diagram of the CRDT data structure according to an embodiment of this application, as shown below. Figure 7 As shown, in one implementation, the CRDT data structure includes:

[0121] The rate limiting counter is used to maintain independent increments and decrements for each autonomous gateway node. When merging, the increments and decrements of all autonomous gateway nodes are summed to obtain a global count value.

[0122] In one exemplary implementation, embodiments of this application may employ a State-based CRDT (Conflict-free Replicated Data Type). For example, the rate limiting counter may employ a PN-Counter (positive and negative counter), maintaining independent increments and decrements for each autonomous gateway node. During merging, the increments and decrements of all autonomous gateway nodes are summed to obtain a global count value.

[0123] The restricted list set is used to assign a unique identifier to each element, add operation record elements and identifiers, delete the identifiers of deleted operation records, and take the union of the sets and remove deleted elements when merging.

[0124] In one exemplary implementation, the restricted list set can be an OR-Set (observation-deletion set), which assigns a unique identifier to each element, adds operation record elements and identifiers, deletes the identifiers of deleted operation records, and takes the union of the sets and removes the deleted elements during merging.

[0125] Configure a mapping table to include a timestamp for each key-value pair, and retain the latest timestamp value when merging.

[0126] In one exemplary implementation, the configuration mapping table can employ an LWW-Map (Last-Write-Wins mapping), where each key-value pair is accompanied by a timestamp, and the latest timestamp value is retained during merging.

[0127] In one exemplary implementation, for example, the process of achieving state synchronization is roughly as follows:

[0128] Autonomous gateway node A updates its local CRDT status, with the timestamp incrementing automatically;

[0129] Autonomous Gateway Node A sends a state digest to its neighbor, Autonomous Gateway Node B, via the Gossip protocol;

[0130] Autonomous Gateway Node B compares the timestamps and finds that Autonomous Gateway Node A's status has been updated.

[0131] Autonomous Gateway Node B requests complete CRDT status data from Autonomous Gateway Node A;

[0132] Autonomous Gateway Node B applies the Merge operator (Merge function) of CRDT to merge the state of Autonomous Gateway Node A into its local replica;

[0133] The merged state satisfies the monotonicity and convergence guarantees of CRDT, and no conflict resolution is required.

[0134] Therefore, by employing the CRDT data structure in this embodiment, each autonomous gateway node can independently modify the shared state without locking or waiting, significantly reducing synchronization latency. This ensures that once the autonomous gateway nodes finally communicate, all replicas will inevitably converge to the same state.

[0135] Figure 7 This is a structural block diagram of the AI ​​algorithm module in an embodiment of this application, as shown below. Figure 8 As shown, in one implementation, the AI ​​algorithm module includes:

[0136] A rate limiting threshold optimization model is used to obtain rate limiting thresholds based on historical traffic rates, backend response times, and system load through reinforcement learning algorithms.

[0137] In one exemplary implementation, the rate limiting threshold optimization model takes historical traffic rates, backend response time, and system load as inputs and outputs the optimal rate limiting threshold. A reinforcement learning algorithm (such as Q-Learning or PPO) is used to train the model with the goal of maximizing system throughput while maintaining backend stability.

[0138] The cache strategy optimization model is used to obtain cache priority and number of replicas based on resource access frequency, size, TTL, and hit rate through collaborative filtering or deep learning models.

[0139] In one exemplary implementation, the caching strategy optimization model takes resource access frequency, size, TTL, and hit rate as inputs and outputs cache priority and number of replicas. It employs collaborative filtering or deep learning models to predict hot resources and dynamically adjusts the caching strategy.

[0140] Threat detection models are used to obtain threat probabilities based on traffic request feature vectors by training a classifier through supervised learning or unsupervised learning.

[0141] In one exemplary implementation, the threat detection model takes a request feature vector as input and outputs a threat probability. A classifier is trained using supervised learning (such as random forests or neural networks) or unsupervised learning (such as isolated forests). The model is periodically updated to adapt to new types of attacks.

[0142] Load forecasting models are used to predict traffic for future time windows based on historical traffic time series data using time series models.

[0143] In one exemplary implementation, the load forecasting model takes historical traffic time series as input and outputs traffic forecasts for future time windows. Time series models (such as LSTM and Prophet) are used for preventative capacity expansion and rate limiting.

[0144] After the AI ​​algorithm module trains a new model or updates its parameters, it generates a new policy version. The policies used to generate the new policy version may include: updated rate limiting thresholds and rate control parameters; adjusted cache priorities and TTL configurations; new threat signatures and detection rules; and optimized routing weights and load balancing strategies.

[0145] The version management module of the control layer assigns a version number to the new policy, generates an incremental patch relative to the current version, and notifies some autonomous gateway nodes via a lightweight messaging channel. Upon receiving the notification, these nodes propagate the policy to the entire network via the Gossip protocol. Each node then applies the new policy and reports the results, forming a closed loop. To avoid introducing problems with the new policy, the system is configured with a canary release mechanism. For example, the control layer uses Raft consensus to select a subset of nodes (e.g., 10%) to initially enable the new policy, monitoring the operational metrics of these autonomous gateway nodes. If the metrics are normal, the coverage of the new policy is gradually expanded; if an anomaly occurs, it is immediately rolled back to the previous version.

[0146] Figure 9 This is a structural block diagram of the processing pipeline according to an embodiment of this application. Figure 8 This is a schematic diagram of the internal information flow of the processing pipeline in an embodiment of this application, as shown below. Figure 9 and Figure 10 As shown, in one embodiment, the processing pipeline includes:

[0147] The cache acceleration stage is used to hash cached data based on the DHT algorithm and distribute it across multiple nodes to reduce the load on backend services and lower response latency.

[0148] In one exemplary implementation, the first stage in the processing pipeline can be a cache acceleration stage. Autonomous Gateway Nodes maintain local caches (e.g., using LRU / LFU algorithms) and participate in a distributed cache network. Based on a DHT algorithm, cached data is hashed and distributed across multiple Autonomous Gateway Nodes. When a local cache miss occurs, the DHT is used to check if other Autonomous Gateway Nodes have cached the data. A version-based weak consistency model is employed. Cached data includes a version number and TTL. When the original data is updated, a failure notification is propagated via the Gossip protocol, and each Autonomous Gateway Node updates or deletes the corresponding cache entry. For data requiring strong consistency, caching is disabled or a very short TTL is set. An AI algorithm module analyzes cache hit rates and access patterns, identifies hot data, and guides Autonomous Gateway Nodes to adjust their caching strategies (e.g., increasing the number of replicas of hot data and improving its storage priority in the DHT). This reduces backend service load and lowers response latency.

[0149] The rate control level is used to maintain a local share of the global rate limiting quota for each autonomous gateway node based on the token bucket algorithm. The local share is obtained through Raft consensus or a proportional allocation algorithm.

[0150] In one exemplary implementation, the second stage in the processing pipeline can be a rate control stage. For example, an improved token bucket algorithm can be used to support dynamic adjustment of rate parameters. Each autonomous gateway node maintains a local share of the global rate limiting quota, which is obtained through Raft consensus or a proportional allocation algorithm. The adaptive adjustment mechanism may include: the autonomous gateway node monitoring traffic rate, backend service response time, and error rate in real time; when excessive backend service pressure is detected (e.g., response time exceeding a threshold or error rate rising), the autonomous gateway node automatically lowers the local rate limiting threshold; when a traffic surge is detected but the backend service still has capacity, the autonomous gateway node borrows additional quota from neighboring autonomous gateway nodes or requests a global quota reallocation via the Raft protocol; and an AI algorithm module predicts traffic trends based on historical data and adjusts rate limiting parameters in advance to achieve preventative rate limiting.

[0151] When the traffic of an autonomous gateway node exceeds its local quota, if the overall system load is not saturated, the autonomous gateway node can request traffic sharing from neighboring autonomous gateway nodes via the Gossip protocol. The neighboring autonomous gateway nodes assess their own load, and if they have spare capacity, they accept some of the traffic and process it on behalf of the node, thus achieving peak shaving across autonomous gateway nodes.

[0152] Therefore, using rate control levels can prevent traffic surges from impacting backend services and protect system stability.

[0153] The behavioral analysis level is used to extract multi-dimensional feature vectors from traffic requests. These feature vectors include: traffic request frequency, time interval distribution, access path sequence, parameter features, and User-Agent features. It also establishes a normal behavior baseline based on historical normal traffic using statistical or machine learning methods. Furthermore, it compares the real-time feature vector with the normal behavior baseline to calculate anomaly scores. If the anomaly score is greater than or equal to a preset threshold, the real-time feature vector is marked as a suspicious traffic request feature. Finally, it matches the suspicious traffic request features with a threat intelligence database; if a match is successful, the traffic request is confirmed to pose a threat.

[0154] In one exemplary implementation, the third stage in the processing pipeline can be the behavior analysis stage. For example, the main processing methods at the behavior analysis stage include: extracting multi-dimensional feature vectors from requests, including request frequency, time interval distribution, access path sequence, parameter features, and User-Agent features; establishing a normal behavior baseline based on historical normal traffic using statistical methods (such as moving average, standard deviation) or machine learning methods (such as isolated forest, autoencoder); comparing the real-time feature vectors with the baseline to calculate anomaly scores. Requests with anomaly scores exceeding a threshold are marked as suspicious; matching the features of suspicious requests with a threat intelligence database (containing known attack signatures), and confirming a threat if a match is successful. Autonomous gateway nodes periodically report locally detected new behavior patterns to the control layer. The AI ​​algorithm module aggregates data from each autonomous gateway node, updates the global behavior baseline and threat signature database, and distributes it to each autonomous gateway node through a version management mechanism. Therefore, the behavior analysis stage can be used to identify abnormal behavior patterns and detect slow attacks and zero-day threats.

[0155] Content inspection level is used to perform fine-grained inspections of traffic request and response content to discover hidden threats; fine-grained inspections include: protocol parsing, signature matching, semantic analysis, and file inspection.

[0156] In one exemplary implementation, the fourth stage in the processing pipeline can be a content inspection stage. For example, the main processing methods in the content inspection stage include: deep parsing protocols such as HTTP, HTTPS (via TLS proxy), and gRPC to extract the content of request headers, request bodies, and response bodies; matching the content against known malicious signature databases (such as SQL injection patterns, XSS scripts, and malicious payloads), using regular expressions or finite state automata for efficient matching; performing semantic analysis on the text content, using NLP techniques to detect phishing scams, sensitive information leaks, etc.; and performing type verification, virus scanning, and malicious code detection on uploaded files. Therefore, the content inspection stage allows for fine-grained inspection of request and response content, uncovering hidden threats.

[0157] Furthermore, for critical decisions requiring strong consistency guarantees (such as distributed locks, master node election, and global sequence number allocation), this application's embodiment employs the Raft consensus algorithm. A subset of nodes in the system form a Raft cluster, achieving consensus through leader election and log replication mechanisms.

[0158] For Raft application scenarios:

[0159] AI model version management in the control layer: ensure that all nodes use a consistent AI model version;

[0160] Global quota allocation for distributed rate limiting: fairly distribute the total rate limiting quota among nodes;

[0161] Canary release node selection: Ensure that only a specified proportion of nodes enable the new strategy.

[0162] Regarding the Raft working mechanism:

[0163] A node in the cluster is in one of three states: Leader, Follower, or Candidate.

[0164] The Leader is responsible for receiving client requests and replicating them as log entries to the Followers.

[0165] Once more than half of the Followers confirm a log entry, the Leader commits the entry and applies it to the state machine.

[0166] If the Leader fails, the Follower will become the Candidate after the timeout and initiate an election. The candidate with the most votes will become the new Leader.

[0167] In this application embodiment, the Raft cluster size is relatively small (3-7 nodes), used for a few strong consistency scenarios. In most scenarios, the Gossip and CRDT mechanisms of eventual consistency are still used to avoid consensus overhead.

[0168] Furthermore, this application's embodiments employ a zero-trust security architecture to implement a "never trust, always verify" security strategy. This mainly includes three parts: node identity authentication, dynamic trust assessment, and chained audit logs.

[0169] Furthermore, each node generates an asymmetric key pair (public key and private key) upon startup, with the public key serving as the node's unique identifier. Before joining the network, a node must apply for an identity certificate from the control layer. After verifying the node's legitimacy, the control layer uses its private key to sign the node's public key, generating the identity certificate.

[0170] An example of an identity certificate structure is shown below:

[0171] "Identity Certificate = {

[0172] Node public key: public key byte array

[0173] Node Roles: Enumeration (Gateway Node / Edge Node)

[0174] Permission list: array of permission identifiers

[0175] Validity period: Start timestamp + End timestamp

[0176] Issuer's signature: digital signature}".

[0177] During inter-node communication, the sender includes an identity certificate and message signature in the message, which the receiver then verifies.

[0178] Whether the certificate signature was issued by the control layer's private key (verify the issuer's signature);

[0179] Is the certificate valid?

[0180] Whether the message signature is issued by the node's public key in the certificate (to verify message integrity and origin).

[0181] Only after successful verification will the recipient process the message content; otherwise, the message will be rejected and the abnormal behavior will be recorded.

[0182] Furthermore, nodes are not permanently trusted simply because they pass initial authentication. The system continuously monitors node behavior and dynamically adjusts trust scores. Each node maintains a trust score (0-100 points) for its neighboring nodes, with an initial value of 60 points.

[0183] The trust score adjustment rules are shown in the following example:

[0184] "The node responds to the request normally, trust score +1; "

[0185] Node timeout or response error, trust score -5;

[0186] A node that provides incorrect data is reported by other nodes, resulting in a trust score of -20.

[0187] The node exhibited abnormal behavior multiple times consecutively, resulting in its trust score being reduced to zero and it being added to the restricted list.

[0188] When a node's trust score falls below a threshold (e.g., 40 points), other nodes reduce their communication priority with it and prioritize cooperating with nodes that have higher trust scores. When the trust score reaches zero, the node is marked as untrusted, its messages are ignored, and the entire network is notified via the Gossip protocol.

[0189] Furthermore, to ensure the traceability and immutability of operations, each node maintains a chained audit log. Each log entry includes a timestamp, operation type, operation parameters, the hash value of the previous log entry, and the hash value of the current log entry.

[0190] The log chain structure is shown below:

[0191] "Log records N={"

[0192] Serial Number: N

[0193] Timestamp: Timestamp

[0194] Operation type: Enumeration (Policy update / Traffic processing / State synchronization / ...)

[0195] Operation details: JSON object

[0196] Preorder hash: Hash(N-1 log records)

[0197] Current hash: Hash (this record)

[0198] Node signature: digital signature}.

[0199] Log records are linked chronologically, with each record's hash value depending on the previous record, forming a tamper-proof chain. Nodes periodically synchronize log summaries (including the start sequence number, end sequence number, and the Merkle root hash of the entire interval) to the control layer and neighboring nodes, enabling distributed auditing.

[0200] In the event of a security incident, auditors can trace the operation sequence through the log chain, verify log integrity (through hash chain verification), and locate the node that initiated the abnormal operation (through node signature verification). Because the logs are distributed across multiple nodes, a single malicious node cannot tamper with the entire network's logs.

[0201] The following explanation of the above system in conjunction with specific application scenarios.

[0202] Figure 10 This is a timing diagram of Gossip protocol information propagation in an embodiment of this application, as follows: Figure 11 As shown, each node maintains a list of neighboring nodes and periodically executes the Gossip propagation process:

[0203] S1. The node randomly selects K neighboring nodes (K is usually 3-5).

[0204] S2. Send a local state summary (including the version number and hash value of each information entry) to the selected neighbor.

[0205] S3. Neighbor node comparison summary to identify missing or expired information entries;

[0206] S4. The neighboring node requests the missing complete information from the source node;

[0207] S5. The source node returns complete information, and the neighboring nodes update their local status.

[0208] To prevent network congestion caused by the unlimited propagation of information, each message carries a TTL (Time to Live) field. The TTL is decremented by 1 with each hop, and propagation stops when the TTL reaches 0. Simultaneously, nodes maintain a Bloom filter for receiving messages to quickly deduplicate them.

[0209] In this embodiment, the Gossip protocol is used. In a network of N nodes, the time complexity of information propagation is O(log N), and the space complexity is O(N). Even if some nodes fail, information can still propagate through other paths, exhibiting strong fault tolerance.

[0210] Figure 11 This is a signaling diagram within the system for adding a new node to the network, as shown in this application embodiment. Figure 12 As shown, the main steps include:

[0211] S1. The node generates a key pair and obtains a globally unique node ID from the public key hash.

[0212] S2. Request an identity certificate from the control layer, and the control layer issues the certificate after verification;

[0213] S3. Obtain the seed node list through the pre-configured bootstrap node;

[0214] S4. Connect the seed nodes and establish the initial DHT routing table and neighbor relationships;

[0215] S5. Obtain the latest policy baseline configuration from the control layer;

[0216] S6. Loading strategy, initializing the processing pipeline and various functional modules;

[0217] S7. Broadcast the online notification via the Gossip protocol so that other nodes can discover it and add it to the routing table;

[0218] S8. Enter normal working state and begin receiving and processing traffic.

[0219] Figure 12 This is a flowchart of a method for processing a single request according to an embodiment of this application, such as... Figure 13 As shown, this process begins with "receiving a customer request," and the specific steps are as follows:

[0220] S1. Enter Level 1 Validation: Query Local Cache:

[0221] If (hit): Proceed to the "Return Response" process;

[0222] If (missed): Proceed to "Level 1: DHT query (in distributed cache)";

[0223] S2, Level 1: DHT query (in distributed cache):

[0224] If (hit): Proceed to the "Return Response" process;

[0225] If (missed): Proceed to "Level 2: Check the full bucket";

[0226] S3, Level 2: Check the full volume container:

[0227] If (quota insufficient): execute "local rate limiting rejection", then proceed to the "return response" process;

[0228] If (quota is sufficient): Proceed to "Level 2: Backend Load Check";

[0229] S4, Level 2: Backend Load Check:

[0230] If the load is too high: Execute "Request neighbor node processing", then proceed to the "Return response" process;

[0231] If (load is normal): Execute "Consume Token";

[0232] S5. After completing "Consume Tokens", proceed to "Level 3: Extract Request Features" and "Level 3: Baseline Comparison" in sequence.

[0233] S6, Level 3: Baseline Comparison:

[0234] If the score is abnormally high: proceed to "Level 3: Threat Intelligence Matching";

[0235] If (normal): Proceed to "Level 4: In-depth detection and judgment";

[0236] S7, Level 4: Depth Detection Judgment:

[0237] If (skip detection): proceed sequentially from "Forward Backend Service" to "Record Decision Data" to "Asynchronous Feedback AI Algorithm Module", and then proceed to the "Return Response" process;

[0238] If (the detection is performed): proceed to "Level 4: Content Depth Detection";

[0239] S8, Level 3: Threat Intelligence Matching:

[0240] If (matches a known threat): Execute "Mark as suspicious", then proceed to "Level 4: Content Deep Detection";

[0241] If (no match): Proceed directly to "Level 4: Content Depth Detection";

[0242] S9, Level 4: Content Depth Detection

[0243] If a threat is detected: execute "Intercept and Log", then proceed to the "Return Response" process;

[0244] If successful: The process proceeds sequentially from "Forward Backend Service" to "Record Decision Data" to "Asynchronous Feedback AI Algorithm Module", and then proceeds to the "Return Response" process.

[0245] Figure 13This is a flowchart of a threat detection and cooperative interception method according to an embodiment of this application, such as... Figure 14 As shown, the core content mainly includes: threat intelligence is disseminated to the entire network within seconds via the Gossip protocol; each node independently verifies the validity of the threat intelligence to prevent the spread of false alarms; the control layer aggregates the verification results of multiple nodes to generate high-confidence detection rules; the rules are distributed through a version management mechanism, and nodes pull and update them themselves.

[0246] Figure 14 This is a flowchart illustrating the method for continuously collecting data, training models, and optimizing strategies according to an embodiment of this application. ​ As shown, the main steps include:

[0247] S1. Each node records decision data in real time and reports it to the control layer in batches;

[0248] S2: The control layer aggregates data, cleans outliers, and constructs a training dataset;

[0249] S3, AI algorithm module offline training and optimization model (such as rate limiting threshold optimization, threat detection optimization);

[0250] S4. Evaluate the performance of the new model on the validation set. If it is better than the current model, adopt it; otherwise, adjust the hyperparameters and retrain.

[0251] S5. Package the optimized strategy parameters into a new version and distribute it through version management;

[0252] S6. The new strategy for node application is fed back to the next round of data collection, forming a closed loop.

[0253] The system automatically adjusts its optimization objectives based on business scenarios. For example, during major e-commerce promotions, the optimization objective leans towards maximizing throughput, while during security incidents, the optimization objective leans towards minimizing threat miss rate.

[0254] Furthermore, embodiments of this application also provide a decentralized traffic governance gateway device, which includes: a control layer device, an autonomous gateway node device, and an edge processing node device.

[0255] The control layer device includes: a computing unit: which runs the control management module, version management module, and AI algorithm module, and performs computing tasks such as strategy generation and model training; a storage unit: which persistently stores the strategy version history, node registration information, training dataset, and model parameters; and a network communication unit: which performs lightweight message interaction with each autonomous node, receives data reported by the node, and sends version update notifications.

[0256] The control layer can employ master-slave backup or multi-replica deployment to improve availability, with replicas maintaining state consistency through Raft consensus.

[0257] The autonomous gateway node device includes: a computing unit: running various functional modules (access management, status management, collaborative communication, processing pipeline, decision engine, etc.) and performing traffic processing and collaborative computing tasks; a storage unit: storing local policy configurations, status databases, cached data, threat signature databases, audit logs, etc.; a network communication unit: communicating with clients, backend services, other nodes, and the control layer; and optional acceleration units: such as GPUs or dedicated AI chips, used to accelerate deep learning inference and content detection computation.

[0258] Nodes can be configured with different hardware specifications depending on their deployment location. Cloud nodes use high-performance servers, while edge nodes use lightweight devices or embedded systems.

[0259] Edge processing node devices are simplified versions of autonomous gateway nodes, retaining core traffic processing and collaborative communication functions while removing some advanced features to reduce resource consumption. They are suitable for resource-constrained edge environments, such as IoT gateways and CDN edge nodes.

[0260] The device adopts a hierarchical mesh topology: the control layer is located at the top and communicates with each gateway node through lightweight connections; the gateway node layer forms a mesh topology, and the nodes communicate directly with each other through protocols such as Gossip, DHT, and CRDT; the edge node layer connects to the nearest gateway node, inherits the gateway node's policies, and processes traffic locally.

[0261] This topology combines the convenience of centralized management with the high availability of decentralization, fully leveraging the computing power at each level.

[0262] By adopting the above technical solution, the control layer of the traditional solution undertakes heavy tasks such as policy calculation and full configuration distribution, with a computational complexity of O(log n). When the number of nodes exceeds 10,000, policy update latency reaches the minute level, and network transmission volume reaches the GB level, becoming a bottleneck for system expansion. This application's embodiment, through a minimalist control layer design, reduces the computational complexity of the control layer to O(1) and the network transmission volume to the KB level. Regardless of how the number of nodes grows, the control layer load remains essentially constant, truly achieving linear scalability. With a node scale of 100,000, the policy update time across the entire network in this application embodiment can be controlled within seconds, improving upon traditional solutions by two orders of magnitude.

[0263] In related solutions, information synchronization between nodes relies on control plane relay, and the threat intelligence propagation path is "detection node to control plane to policy update to network-wide distribution," with end-to-end latency reaching tens of seconds or even minutes. This application's embodiment achieves direct collaboration and parallel propagation between nodes by integrating the Gossip protocol and the CRDT mechanism. Threat intelligence covers the entire network in O(log N) time complexity, reducing propagation latency to the second or even sub-second level. Simultaneously, the conflict-free nature of CRDT allows nodes to concurrently update shared states without coordination, eliminating the synchronization waiting time in traditional solutions and significantly improving network-wide collaboration efficiency and real-time response capabilities.

[0264] Traditional centralized architectures suffer from single points of failure; a failure in the control layer can impair the functionality of the entire system. While Service Mesh achieves distributed data plane, the control plane remains the "brain" of the system. Network partitions or performance degradation can affect all dependent nodes. This application's embodiment employs a truly decentralized architecture, where each autonomous node possesses complete decision-making capabilities, forming a mesh topology. Even in the event of a brief control layer failure or partial node failure, other nodes can continue to function normally based on local policies and Gossip coordination, with the system automatically bypassing the failed node and rerouting. This design ensures that the failure of any single node does not affect the overall system operation, elevating reliability from reliance on a single point to distributed self-healing, achieving a qualitative leap in fault tolerance.

[0265] Existing solutions often employ traditional boundary-based security models and simple certificate authentication, lacking continuous behavioral monitoring and dynamic trust assessment. In decentralized environments, these solutions are prone to security vulnerabilities such as malicious node injection and data tampering, and also lack traceable auditing mechanisms. This application's implementation introduces a zero-trust security concept, achieving a "never trust, always verify" security strategy. It continuously monitors node behavior and adjusts trust scores in real time through a dynamic trust assessment mechanism, and establishes an immutable traceability chain for all operations through a chained audit log mechanism. This design effectively defends against malicious node attacks, quickly locates the source of security incidents, meets compliance auditing requirements, and establishes a robust horizontal trust relationship in a decentralized environment.

[0266] Traditional gateways have limited traffic processing capabilities, typically including only basic functions such as rate limiting and filtering. They employ a serial processing approach, increasing overall latency with each additional function added, and policy parameters rely on manual configuration, lacking adaptive optimization capabilities. This application's embodiment achieves refined traffic governance through a multi-level pipeline architecture: a distributed caching layer improves hit rate, an adaptive rate control layer dynamically adjusts rate limiting thresholds, a behavior analysis layer identifies abnormal patterns, and a deep content detection layer discovers hidden threats. The parallel operation of each level significantly improves throughput. Simultaneously, through an AI-driven policy self-optimization closed loop, the system can continuously learn and evolve based on real-time operational data, automatically discovering optimal configuration parameters and quickly responding to new threats, maintaining optimal operating status without manual intervention. Real-world testing shows that this application's embodiment improves cache hit rate by over 30%, threat identification accuracy by over 20%, and reduces false positive rate by over 50%.

[0267] In related solutions, edge nodes primarily function as passive forwarding points, with their computing power underutilized. Traffic often needs to be relayed back to the central node for processing, increasing network latency and bandwidth consumption. This application's embodiments endow edge nodes with sufficient autonomy, enabling them to make decisions based on local traffic characteristics, collaborate with neighboring nodes to achieve cross-domain traffic smoothing, and intercept threatening traffic locally. This edge intelligent processing mode allows the overall system processing capacity to increase almost linearly with the number of nodes, while significantly reducing response latency (from hundreds of milliseconds to tens of milliseconds) and network transmission overhead (reducing cross-domain traffic by more than 60%), significantly improving user experience and resource utilization.

[0268] In summary, this application's embodiments, by employing the above-described technical solutions, realize a decentralized traffic governance gateway system. This system utilizes core technologies such as a lightweight control layer, autonomous node collaboration, zero-trust security, multi-level pipelines, and AI self-optimization, fundamentally addressing the shortcomings of traditional solutions in terms of scalability, real-time performance, security, and intelligence. It provides a complete and efficient solution for traffic governance in large-scale distributed environments.

[0269] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0270] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular hardware and software combination.

[0271] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A decentralized traffic governance gateway system, characterized in that, include: The control layer is used to send incremental instructions, wherein the incremental instructions carry update strategy information; The gateway node layer includes multiple autonomous gateway nodes forming a mesh topology. Each autonomous gateway node stores a local policy. When any autonomous gateway node receives the incremental instruction, it updates its local policy based on the incremental instruction and sends the incremental instruction to other autonomous gateway nodes through a decentralized algorithm, so that the other autonomous gateway nodes update their local policies based on the incremental instruction.

2. The system according to claim 1, characterized in that, Also includes: The edge node layer includes at least one edge processing node, which is used to receive service data sent by any of the autonomous gateway nodes, wherein the service data is obtained by the autonomous gateway node based on traffic requests through the local policy.

3. The system according to claim 1, characterized in that, The control layer includes: The control and management module is used to generate the incremental instruction in response to the policy update instruction, and to send the incremental instruction to the autonomous gateway node.

4. The system according to claim 3, characterized in that, The control layer also includes: The information statistics module is used to collect decision data from the multiple autonomous gateway nodes, wherein the decision data includes: traffic characteristic data, processing result data, and response latency data; The AI ​​algorithm module is used to learn and analyze the decision data to generate optimization strategies, and integrate the optimization strategies into the incremental instructions to send the incremental instructions to the autonomous gateway node.

5. The system according to claim 4, characterized in that, The control layer also includes: The version management module is used to store historical data generated by the autonomous gateway node, the control management module, the AI ​​algorithm module, and the information statistics module, so that the control management module and the AI ​​algorithm module can retrieve the historical data in real time.

6. The system according to claim 4, characterized in that, The autonomous gateway node includes: The access management module is used to receive traffic requests, encapsulate the traffic requests into standardized internal events, and deliver the internal events to the event bus; The event bus; The state management module is used to store the local state information of the autonomous gateway nodes that can be merged using a CRDT data structure, so that any autonomous gateway node can synchronize its state with other autonomous gateway nodes based on the CRDT data structure; wherein, the local state information includes: policy configuration, traffic statistics, neighbor node list, and threat signature database; A local state database is used to store the local state information; The collaborative communication module is used to enable any autonomous gateway node to conduct point-to-point communication and broadcast communication with other autonomous gateway nodes based on the decentralized algorithm. Network layer; A processing pipeline includes multiple serial or parallel processing stages, so that traffic requests pass through multiple processing stages sequentially, and each processing stage performs a processing operation on the traffic request; wherein the processing operation includes: allowing operation, modifying operation, intercepting operation, and forwarding operation; The decision engine module includes a rule engine and a local AI inference module, which are used to integrate the detection results and historical data of each processing level to obtain a decision result. The decision result includes a decision instruction and processing parameters corresponding to the decision instruction. The decision instruction includes: allowing, limiting, circuit breaking, downgrading, and blocking. The feedback acquisition module is used to record multi-dimensional decision data for each traffic request, and report the multi-dimensional decision data to the AI ​​algorithm module through the information statistics module, so that the AI ​​algorithm module can perform offline training and strategy optimization based on the multi-dimensional decision data.

7. The system according to claim 6, characterized in that, The collaborative communication module includes: Gossip propagation engine: used to periodically and randomly select neighboring autonomous gateway nodes, exchange state summaries and incremental updates with the neighboring autonomous gateway nodes, so as to achieve probabilistic propagation of information; DHT lookup engine: used to locate the autonomous gateway node where the resource is located based on a distributed hash table algorithm; CRDT Synchronization Engine: Used to process state merging requests between the Autonomous Gateway Nodes using CRDT merging operators, so as to make the states of the multiple Autonomous Gateway Nodes consistent.

8. The system according to claim 6, characterized in that, The CRDT data structure includes: A rate limiting counter is used to maintain independent increments and decrements for each of the autonomous gateway nodes. When merging, the increments and decrements of all the autonomous gateway nodes are summed to obtain a global count value. The restricted list set is used to assign a unique identifier to each element, add operation record elements and identifiers, delete the identifiers of deleted operation records, and take the union of the sets and remove deleted elements when merging. Configure a mapping table to include a timestamp for each key-value pair, and retain the latest timestamp value when merging.

9. The system according to claim 4, characterized in that, The AI ​​algorithm module includes: A rate limiting threshold optimization model is used to obtain rate limiting thresholds based on historical traffic rates, backend response times, and system load through reinforcement learning algorithms. The cache strategy optimization model is used to obtain cache priority and number of replicas based on resource access frequency, size, TTL, and hit rate through collaborative filtering or deep learning models. Threat detection models are used to obtain threat probabilities based on traffic request feature vectors by training a classifier through supervised learning or unsupervised learning. Load forecasting models are used to predict traffic for future time windows based on historical traffic time series data using time series models.

10. The system according to claim 6, characterized in that, The processing pipeline includes: The cache acceleration stage is used to hash cached data based on the DHT algorithm and distribute it across multiple nodes to reduce the load on backend services and lower response latency. A rate control level is used to maintain a local share of the global rate limiting quota for each autonomous gateway node based on the token bucket algorithm, wherein the local share is obtained through Raft consensus or a proportional allocation algorithm; The behavioral analysis level is used to extract multi-dimensional feature vectors from traffic requests. These multi-dimensional feature vectors include: traffic request frequency, time interval distribution, access path sequence, parameter features, and User-Agent features. Furthermore, it establishes a normal behavior baseline based on historical normal traffic using statistical or machine learning methods. It compares the real-time feature vector with the normal behavior baseline to calculate an anomaly score, wherein if the anomaly score is greater than or equal to a preset threshold, the real-time feature vector is marked as a suspicious traffic request feature. Finally, it matches the suspicious traffic request feature with a threat intelligence database; if a match is successful, the traffic request is confirmed to pose a threat. The content inspection level is used to perform fine-grained inspections on the traffic request and response content to discover hidden threats; wherein, the fine-grained inspection includes: protocol parsing, signature matching, semantic analysis, and file inspection.

Images