Data center network policy generation method and system based on policy matrix model

Abstract

The application discloses a data center network policy generation method and system based on a policy matrix model, and belongs to the technical field of computer networks.The method comprises the following steps: a policy matrix model containing multiple conditions such as a client / server network area, a disaster recovery mode, a node type and a public network domain name disaster recovery mode is constructed; in response to user input, the network area, the disaster recovery mode and the node type of a source / destination address are automatically analyzed through IPAM and CMDB to form a hit condition vector; the hit condition vector is matched with a matrix rule to obtain an associated policy template list; and data is transmitted through a virtual intermediate table and rendered according to a template mapping to generate a network policy instance that can be issued. The application realizes the automatic generation of multiple types of network policies, accurately adapts to a data center high-availability architecture, significantly improves the policy deployment efficiency and accuracy, and has millisecond-level matching performance.

Description

Technical Field

[0001] This application relates to the field of computer network technology, specifically to a data center network policy generation method and system based on a policy matrix model, which is applicable to the automated generation and deployment of various types of network policies such as firewalls, load balancers, and proxies in a data center environment. Background Technology

[0002] In data center network management, network policies such as firewall access control lists, load balancing forwarding rules, and proxy configurations are core means to ensure business security and accessibility. As data centers expand and business types increase, the number of policies grows exponentially, posing a significant challenge to traditional manual configuration methods.

[0003] In the prior art, Chinese invention patent CN119232743B discloses an automated configuration method for load balancing devices, which generates configurations by constructing a network matrix and matching demand templates. However, its matrix dimensions are limited to network areas and IP planning, and it is only applicable to load balancing devices. "A Method for Automatic Deployment of Data Center Network Firewall Policies" (Jiangsu Communications, 2024, Issue 03) only involves traffic model matching of firewall policies and does not consider the high availability architecture attributes of data centers. Although Huawei's network security convergence technology proposes a mutual access matrix, it lacks template rendering and automatic address resolution mechanisms.

[0004] In developing this application, the inventors discovered that existing technologies suffer from at least the following problems: limited policy types, lack of awareness of architectural attributes such as disaster recovery modes and node types, reliance on extensive manual conversion of user input, and inability to retain and reuse knowledge. Therefore, there is an urgent need for a method that can uniformly process multiple policy types, automatically adapt to data center architectures, and automate the entire process from simple user input to complete policy configuration. Summary of the Invention

[0005] This application provides a method and system for generating data center network policies based on a policy matrix model, aiming to solve the aforementioned problems. This application achieves intelligent generation of network policies by constructing a policy matrix model that includes multi-dimensional conditions such as disaster recovery mode and node type, combined with IPAM / CMDB automatic address resolution and template rendering mechanisms.

[0006] The technical solution adopted by this application to solve its technical problem is: On the one hand, a method for generating data center network policies based on a policy matrix model is provided, including the following steps: Construct a strategy matrix model, which contains multiple matrix rules. Each matrix rule includes at least six condition fields: client network region, client disaster recovery mode, server network region, server node type, server disaster recovery mode, and public domain name disaster recovery mode. Each matrix rule is associated with one or more strategy templates. In response to the user's input of a target access request, the system obtains the source address and destination address, resolves the network regions to which the source address and destination address belong through the IP Address Management (IPAM) system, and obtains the disaster recovery mode and node type corresponding to the destination address, as well as the disaster recovery mode corresponding to the source address, through the Configuration Management Database (CMDB) to form a hit condition vector. The hit condition vector includes at least the source network region, source disaster recovery mode, destination network region, destination node type, destination disaster recovery mode, and public domain name disaster recovery mode. The hit condition vector is matched with each matrix rule in the strategy matrix model. If the match is successful, the list of strategy templates associated with the matrix rule is obtained. Based on the policy template list, the corresponding field data is extracted from the virtual intermediate table, and the field data is filled into each policy template according to the predefined field mapping relationship of each policy template to generate at least one network policy instance that can be distributed.

[0007] In a preferred embodiment, constructing the policy matrix model includes: obtaining the defined network area types, disaster recovery mode types, and node types in the data center network, and establishing corresponding enumeration value sets for each; determining the policy access path based on the access flow relationship of the data center network architecture, and generating multiple matrix rules; configuring a corresponding policy template for each matrix rule, and setting the activation order. Further, the matrix rules are stored in a relational database and loaded into memory at system startup to build a multi-level hash index for fast matching.

[0008] In a preferred embodiment, the address resolution includes determining the source and destination addresses using IPv4 / IPv6 / domain names, querying the network region for IP addresses using the longest prefix matching method in the IPAM system, and distinguishing between internal and external domain names. Internal domain names are queried through the CMDB, while external domain names are directly marked as Internet third-party entities. Simultaneously, the disaster recovery mode is queried through the CMDB's host model, and the node type is queried through the application service model. The query results are stored in a two-level cache (local + Redis) and support an active invalidation mechanism.

[0009] In the preferred implementation, matrix matching includes simultaneously querying precise partitions and "non-involved" (wildcard) partitions, merging candidate rule sets, and then performing precise filtering on the remaining condition fields. If multiple rules are matched, a weighted matching score is used to select the optimal rule. An exemplary weight vector is: source region 0.3, destination region 0.3, source disaster recovery 0.15, destination node 0.1, destination disaster recovery 0.1, and public domain name disaster recovery 0.05. If no match is found, a miss event is recorded, triggering intelligent recommendation (collaborative filtering) and work order processes, and offline clustering analysis is performed periodically to generate rule suggestions.

[0010] In a preferred embodiment, the template rendering includes creating a virtual intermediate table, rendering it sequentially according to the template order, obtaining data from the virtual table or fixed values ​​according to the field mapping, populating the template to generate a strategy instance, and supporting loop expansion to generate multiple records; after rendering, it is converted into specific device commands such as Cisco ACL, Huawei ACL, F5 REST API, etc. through the device adapter, and then distributed through automated tools.

[0011] On the other hand, a data center network policy generation system based on a policy matrix model is provided, including a model building module, an address parsing module, a matching engine module, and a template rendering module, to implement the above method.

[0012] One of the above technical solutions has the following advantages or beneficial effects: First, by incorporating disaster recovery mode and node type into the matrix conditions, the generated policies can be accurately adapted to the high-availability deployment architecture of the data center, avoiding policy failures or security vulnerabilities caused by architecture mismatch.

[0013] Secondly, through the automatic parsing of IPAM and CMDB, the simple address information entered by the user is automatically converted into structured hit conditions, which greatly reduces the threshold of manual operation and the probability of error.

[0014] Third, through virtual intermediate tables and multi-template rendering mechanisms, it supports the collaborative generation of multiple strategy types, and data can be transferred between templates to ensure the logical consistency of multi-strategy configurations.

[0015] Fourth, by employing APMM algorithms such as multi-level hash indexing, intelligent caching, and dynamic weight scoring, millisecond-level matching responses were achieved, thereby improving system throughput.

[0016] The aforementioned technical approaches, through the synergy of matrix models, automatic parsing, and rendering mechanisms, have produced unexpected technical effects: the combination of the policy matrix model and automatic address parsing allows user input to be directly matched with rules without manual conversion; the virtual intermediate table links the matrix matching results with template rendering, achieving end-to-end automation from business intent to device commands; and the synergy of multi-level hash indexes and dynamic weight scoring ensures high performance while maintaining matching accuracy. This synergy improves policy generation efficiency by tens of times, and the configuration error rate approaches zero, significantly surpassing the effects achievable by using each technical approach individually. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a data center network policy generation method based on a policy matrix model, according to an exemplary embodiment. Figure 2 This is a schematic diagram illustrating the structure of a data center network policy generation system based on a policy matrix model, according to an exemplary embodiment. Figure 3 This is a flowchart illustrating an adaptive strategy matrix matching algorithm based on multidimensional feature fusion, according to an exemplary embodiment. Detailed Implementation

[0018] To more clearly illustrate the technical features of this application, the following detailed description is provided through specific embodiments and in conjunction with the accompanying drawings.

[0019] Example 1 like Figure 1 As shown in this embodiment, a data center network policy generation method based on a policy matrix model includes the following steps: Step 1: Construct the strategy matrix model.

[0020] The strategy matrix model contains multiple matrix rules. Each matrix rule includes at least six condition fields: client network region, client disaster recovery mode, server network region, server node type, server disaster recovery mode, and public domain name disaster recovery mode. Each matrix rule is associated with one or more strategy templates.

[0021] The construction of the strategy matrix model includes the following steps: Obtain the defined network area types, disaster recovery mode types, and node types in the data center network, and establish corresponding enumeration value sets for each. The network area types include at least managed intranets, internet access zones, third-party internet providers, and leased lines; the disaster recovery mode types include at least single-active, primary / backup, dual-active, and not involved; and the node types include at least single-node, multi-node, and not involved. The term "not involved" indicates that this condition field is not included in the matching restrictions. Based on the access flow relationship of the data center network architecture, the policy access path between the client and the server is determined. Based on the policy access path, the value combination of each condition field is selected from the enumerated value set to generate multiple matrix rules. Configure a corresponding policy template for each matrix rule and set the activation order of the policy templates. The policy templates associated with each matrix rule have a preset template order, which is used to indicate the activation priority of the network policy corresponding to each policy template. When generating the network policy instance, each policy template is rendered sequentially according to the template order. The intermediate data generated by the policy template rendered first is passed to the policy template rendered later through a virtual intermediate table.

[0022] Furthermore, the construction of the strategy matrix model also includes the following steps: Each of the matrix rules is stored in a policy matrix rule table in a relational database. The policy matrix rule table includes at least the following fields: rule identifier, client network region, client disaster recovery mode, server network region, server node type, server disaster recovery mode, public domain name disaster recovery mode, rule priority, and activation status. When the system starts up or when the policy matrix rule table changes, the enabled matrix rules are loaded into memory and a multi-level hash index is constructed. The first-level key of the multi-level hash index is a combination of the client network region and the server network region, and the second-level key is a combination of the client disaster recovery mode, the server node type, the server disaster recovery mode, and the public domain name disaster recovery mode.

[0023] Furthermore, the construction of the strategy matrix model also includes the following steps: in response to the administrator's operation of adding, modifying or deleting matrix rules, the changed matrix rules are synchronously written into the relational database, and the change event is sent to the message queue after the transaction is committed; each matching engine instance subscribes to the message queue, and refreshes its own memory index in real time after receiving the change event to ensure that the index data of each instance is consistent.

[0024] Step 2: In response to the user's input of the target access request, obtain the source address and destination address, resolve the network area to which the source address and destination address belong through the IP Address Management (IPAM) system, obtain the disaster recovery mode and node type corresponding to the destination address and the disaster recovery mode corresponding to the source address through the Configuration Management Database (CMDB), and form a hit condition vector. The hit condition vector includes at least the source network area, source disaster recovery mode, destination network area, destination node type, destination disaster recovery mode and public domain name disaster recovery mode.

[0025] Step 2 includes the following steps: The source address is type-determined to determine whether it is an IPv4 address, an IPv6 address, or a domain name. If the source address is an IP address, the IPAM system is invoked to query the network area to which the IP address belongs. If the source address is a domain name, it is determined whether the domain name is an internal domain name. If it is an internal domain name, the corresponding network area is queried through CMDB. Otherwise, it is marked as an Internet third-party entity. The destination address is type-determined to determine if it is an IPv4 address, IPv6 address, or domain name. If the destination address is an IP address, the IPAM system is invoked to query the network area to which the IP address belongs, and the disaster recovery mode and node type corresponding to the IP address are queried through the CMDB. If the destination address is a domain name, it is determined whether the domain name is an internal domain name. If it is an internal domain name, the corresponding network area, disaster recovery mode, and node type are queried through the CMDB. Otherwise, it is marked as an Internet third-party entity, and both the disaster recovery mode and node type are marked as not involved. The parsed source network region, source disaster recovery mode, destination network region, destination node type, destination disaster recovery mode, and public domain name disaster recovery mode are combined into the hit condition vector.

[0026] The step of querying the network area to which the IP address belongs by calling the IPAM system includes the following steps: obtaining the mapping relationship table between IP address segments and network areas stored in the IPAM system, wherein each record in the mapping relationship table contains a network segment CIDR and a corresponding network area identifier; for the target IP address, traversing all network segment CIDRs in the mapping relationship table, finding all network segments containing the target IP address, selecting the network segment with the largest subnet mask length from them, and determining the network area corresponding to the network segment as the network area to which the target IP address belongs.

[0027] The process of querying the disaster recovery mode and node type corresponding to the IP address through CMDB includes the following steps: using the target IP address as the query condition, searching for a matching host record in the host model of the CMDB. The host record contains the host IP address, the application system to which it belongs, the disaster recovery mode, and the data center location fields. If a unique host record is found, the disaster recovery mode field of that host is read as the disaster recovery mode corresponding to the target IP address. If multiple host records are found, the host record with the highest priority is selected according to predefined business rules, or the multi-host association status is returned and a manual review process is triggered. If no host record is found, the default value "not involved" is returned and a log is recorded.

[0028] The step of querying the node type corresponding to an IP address through CMDB includes the following steps: using the target IP address as the query condition, searching for the associated service record in the application service model of the CMDB, wherein the application service model includes service name, service VIP, backend server list, and node type fields; if the target IP address is the VIP of the load balancer, then the node type is directly determined to be multi-node; if the target IP address is a backend server of a certain service, then counting the number of servers in the backend server list of that service, if the number is greater than 1, it is determined to be multi-node, otherwise it is determined to be single-node; if the target IP address is not associated with any service record, it is determined to be single-node by default.

[0029] Furthermore, step 2 also includes the following steps: Before calling IPAM or CMDB to query, the cache is queried using the address as the key. The cache adopts a two-level architecture of local memory cache and distributed Redis cache. If the local cache is hit, the attribute data corresponding to the address is returned directly. If the local cache is not hit but the Redis cache is hit, the attribute data is retrieved from Redis and populated back into the local cache before being returned. If neither cache is hit, the IPAM or CMDB interface is called to query. Write the query results to the Redis cache and set an expiration time. At the same time, write them to the local cache so that subsequent queries with the same address can directly hit the cache.

[0030] Furthermore, the data center network policy generation method based on the policy matrix model further includes: when the address information in the CMDB or IPAM changes, the change system sends an address change notification through a message queue; after receiving the address change notification, the local end deletes the corresponding Redis cache key and local cache item according to the address list contained in the notification.

[0031] Furthermore, step 2 also includes the following steps: For external domains, skip the IPAM and CMDB queries when the cache is not hit, and directly construct a default attribute object; the network zone of the default attribute object is "Internet third-party unit", the disaster recovery mode is "not involved", the node type is "not involved", and the public domain name disaster recovery mode is determined as single active or dual active according to the domain name publishing policy configuration.

[0032] Step 3: Match the hit condition vector with each matrix rule in the strategy matrix model. If the match is successful, obtain the list of strategy templates associated with the matrix rule.

[0033] Step 3 includes the following steps: Using the client network region and server network region in the hit condition vector as the query key, four index partitions are queried simultaneously: the exact client region and the exact server region partition, the exact client region and the "not involved" server region partition, the "not involved" client region and the exact server region partition, and the "not involved" client region and the "not involved" server region partition. The candidate rule sets returned by each partition are merged and deduplicated; wherein, "not involved" means that the condition field does not participate in the matching restriction. In the candidate rule set, each matrix rule is checked to see if the other four condition fields (excluding the client network area and the server network area) match the corresponding fields in the hit condition vector. If a field has the value "not involved" in the matrix rule, then the field passes the matching check unconditionally. If all four fields match successfully, then the matrix rule is added to the list of successfully matched rules.

[0034] The "not involving" client region or "not involving" server region refers to the matrix rule being stored in the wildcard index partition of the corresponding dimension when the corresponding condition field in the matrix rule is set to "not involving". The four index partitions are queried concurrently using coroutines or thread pools. The results are merged after all partition queries are completed to shorten the matching response time.

[0035] The matching process includes: using the client network region and server network region in the hit condition vector as query keys, querying multiple index partitions in parallel in a pre-built multi-level hash index to obtain a candidate rule set; for each matrix rule in the candidate rule set, calculating the matching coefficient between the matrix rule and the hit condition vector on each condition field, calculating the weighted matching degree of the matrix rule based on the weight value of each condition field and the matching coefficient, and selecting the matrix rule with the highest weighted matching degree as the hit rule.

[0036] If the list of successfully matched rules contains multiple matrix rules, the weighted matching degree of each matrix rule is calculated, and the matrix rule with the highest weighted matching degree is selected as the final hit rule. The list of strategy templates associated with this matrix rule is then obtained. The weighted matching degree is calculated as follows: weight values ​​are set for the six condition fields, and the sum of the weight values ​​of all condition fields is 1. For each candidate matrix rule, the matching coefficient of each condition field is calculated. If the value of a condition field in the matrix rule is exactly equal to the value of the corresponding field in the hit condition vector, the matching coefficient of that condition field is 1. If the value of a condition field in the matrix rule is "not involved", the matching coefficient of that condition field is 0.5. The weight values ​​of each condition field are multiplied by their corresponding matching coefficients and then summed to obtain the weighted matching degree of the matrix rule.

[0037] The weight values ​​for the six condition fields are as follows: client network region weight 0.30, server network region weight 0.30, client disaster recovery mode weight 0.15, server node type weight 0.10, server disaster recovery mode weight 0.10, and public domain name disaster recovery mode weight 0.05.

[0038] Furthermore, the data center network policy generation method based on the policy matrix model further includes: periodically collecting historical matching logs, extracting the matching coefficients of each condition field and the finally selected matrix rule in each matching process, using the matching coefficients as features and the finally selected rule as labels, training a weight optimization model using a logistic regression algorithm, and dynamically adjusting the weight values ​​of each condition field according to the output of the weight optimization model.

[0039] If the list of successfully matched rules is empty, it is determined that the hit condition vector failed to match any matrix rule, and the following miss handling operations are performed: Record the miss event, which includes the hit condition vector, the user's input target access requirement, the request timestamp, and the user identifier; write the miss event into the miss event table of the relational database and send it to the miss event topic in the message queue; trigger the intelligent recommendation process: extract the feature vector of the current request, calculate the cosine similarity between it and the feature vector of historically hit requests, recall the K historical requests with the highest similarity, if the highest similarity exceeds a preset threshold, return the matrix rule matched by the historical request as the recommendation rule, otherwise return an empty recommendation result; at the same time, create an operation and maintenance work order, push the complete information of the miss event to the operation and maintenance work order system, and notify the administrator to conduct manual review and rule supplementation.

[0040] Furthermore, the data center network policy generation method based on the policy matrix model also includes an offline clustering analysis process: periodically extracting new missed events from the missed event table, converting each missed event into a feature vector, using the K-Means clustering algorithm to cluster the feature vectors, and obtaining the cluster centroid features; counting the number of requests for each cluster, and if the number of requests for a cluster exceeds a preset threshold, generating a draft rule suggestion based on the centroid features of that cluster, and pushing the draft rule suggestion to the management interface for administrator review; after administrator confirmation, converting the rule suggestion into matrix rules and adding it to the policy matrix model, while simultaneously triggering a memory index refresh.

[0041] Step 4: Based on the policy template list, extract the corresponding field data from the virtual intermediate table, and fill the field data into each policy template according to the predefined field mapping relationship of each policy template to generate at least one network policy instance that can be distributed.

[0042] Step 4 includes the following steps: Create the virtual intermediate table, which is a key-value pair storage structure and initially contains the source address, destination address, protocol type, port number, and the values ​​of each field in the hit condition vector; The strategy templates to be rendered are obtained sequentially according to the order in the strategy template list. The predefined field mapping relationship configuration of the strategy template is read. The field mapping relationship configuration includes the name of each field in the template and its corresponding data source identifier. The data source identifier includes fixed value source and virtual intermediate table reference source. For each field in the strategy template, the field value is obtained according to its data source identifier: if it is a fixed value source, the pre-configured fixed value is read directly; if it is a virtual intermediate table reference source, the corresponding value is queried from the virtual intermediate table using the field name or field path as the key. Fill the values ​​of all fields into the strategy template to generate a strategy instance; if new data is generated during the rendering process of the current strategy template, write the new data into the virtual intermediate table for subsequent strategy templates to read and use; Iterate through all policy templates in the policy template list, generate at least one policy instance, and combine all policy instances into a set of network policies that can be distributed.

[0043] When a loop expansion flag is defined in the policy template, the loop expansion flag is used to indicate that the policy template needs to generate multiple policy records for multiple destination addresses or multiple ports respectively; the filling into each policy template includes: reading the list of data to be expanded associated in the policy template, the list of data to be expanded including multiple destination IP addresses or multiple port numbers; for each data item in the list of data to be expanded, performing the field value acquisition and filling operation of the policy template respectively, generating an independent policy record for each data item; and combining the generated policy records into the rendering result set of the policy template.

[0044] After generating at least one deployable network policy instance, the method further includes: obtaining the target device type of the network policy instance; selecting a target adapter matching the target device type from a plurality of pre-configured device adapters; the device adapter includes at least a Cisco firewall adapter, a Huawei firewall adapter, and an F5 load balancer adapter; invoking the target adapter to convert the network policy instance into a configuration command or application programming interface (API) call recognizable by the target device; distributing the configuration command or API call to the target device through an automated operation and maintenance tool, and receiving the execution result returned by the device; if the distribution is successful, updating the status of the network policy instance to "effective"; if the distribution fails, recording an error log and triggering an alarm, and simultaneously performing a rollback operation to restore the distributed configuration to its state before modification.

[0045] Example 2 To implement the data center network policy generation method based on the policy matrix model described in Example 1, Example 2 provides a data center network policy generation system based on the policy matrix model.

[0046] like Figure 2 As shown in this embodiment, a data center network policy generation system based on a policy matrix model includes: The model building module is used to build a strategy matrix model. The strategy matrix model contains multiple matrix rules. Each matrix rule includes at least six condition fields: client network region, client disaster recovery mode, server network region, server node type, server disaster recovery mode, and public domain name disaster recovery mode. Each matrix rule is associated with one or more strategy templates. The address resolution module is used to respond to the user's input target access request, obtain the source address and destination address, resolve the network area to which the source address and destination address belong through the IP Address Management (IPAM) system, obtain the disaster recovery mode and node type corresponding to the destination address and the disaster recovery mode corresponding to the source address through the Configuration Management Database (CMDB), and form a hit condition vector. The matching engine module is used to match the hit condition vector with each matrix rule in the strategy matrix model. If the match is successful, the strategy template list associated with the matrix rule is obtained. The template rendering module is used to extract corresponding field data from the virtual intermediate table according to the policy template list, and fill the field data into each policy template according to the predefined field mapping relationship of each policy template to generate at least one network policy instance that can be distributed.

[0047] The matching engine module includes a multi-level hash index construction unit. The first-level key of the multi-level hash index is a combination of the client network region and the server network region. The second-level key is a combination key of the client disaster recovery mode, the server node type, the server disaster recovery mode, and the public domain name disaster recovery mode. The matching engine module is also used to simultaneously query exact matching partitions and "not involved" partitions and merge candidate rule sets.

[0048] The matching engine module further includes a weighted scoring unit and a conflict resolution unit; the weighted scoring unit is used to calculate the weighted matching degree of each rule when multiple rules are matched, and the conflict resolution unit is used to select the rule with the highest weighted matching degree as the final matched rule; the system also includes a rule self-learning module, which is used to periodically optimize the weight vector based on historical matching logs.

[0049] The system also includes a caching module, which adopts a two-level architecture of local caching and distributed caching to store query results of IPAM and CMDB. The caching module supports two mechanisms: passive invalidation and active invalidation. Active invalidation is based on CMDB change messages that trigger cache clearing.

[0050] Example 3 This embodiment further elaborates on the core innovative mechanism of this application—the Adaptive Policy Matrix Matching Algorithm (APMM) based on multi-dimensional feature fusion, as well as the specific implementation methods of policy template construction, matrix storage optimization, conflict resolution, and miss self-learning.

[0051] 1. Strategy Template Construction A strategy template is the basic unit of strategy data. After the user fills in the strategy requirements, the data is automatically rendered into the strategy template according to the strategy matched by the matrix. Each strategy template defines the field structure of its output and the data source of each field, including fixed values ​​or virtual intermediate table references.

[0052] The standard table is the data source for the policy template fields, divided into source and destination categories. The virtual intermediate table is a temporary key-value pair storage structure used to transfer data between templates. The data sources for template fields include: fixed values, such as proxy device addresses, and virtual intermediate table references, such as source IP addresses and destination domain names. The standard table structure can be designed according to actual needs and may include, but is not limited to, the structures shown in Table 1.

[0053] Table 1 Field Table

[0054] The policy template type is determined based on the type of device being issued and the field structure, including firewall policies, proxy policies, load balancing policies, etc. When configuring a template, you need to set the template name, type, description, and field mapping relationships.

[0055] 2. Storage and Indexing Optimization of Matrix Models The strategy matrix model adopts a two-layer architecture of "persistent storage + memory acceleration".

[0056] 2.1 Persistent Storage: Matrix rules are stored in a relational database, as shown in Table 2. The core table structure includes rule identifier, six condition fields, priority, and activation status. Strategy templates are stored in a separate table, and a many-to-many relationship between rules and templates is established through association tables.

[0057] The system is designed with three core tables to store the relevant data of the matrix model: matrix rule table, strategy template table, and rule-template association table, as shown in Table 2.

[0058] Table 2 Core Table Structure

[0059] 2.2 Memory Index: Upon system startup, rules in the enabled state are loaded into memory to construct a multi-level hash index. The first-level key is the source network region, and the second-level key is the destination network region. Within the source and destination region groups, composite key indexes are built for the remaining four condition fields: source disaster recovery mode, destination node type, destination disaster recovery mode, and public domain name disaster recovery mode. For fields with a value of "not involved," the rule is stored in the corresponding wildcard partition, allowing for quick location of candidate rules during matching via the wildcard key, with a time complexity close to O(1). The index supports dynamic updates: When a rule changes, all matching engine instances are notified via a message queue to refresh in real time.

[0060] 3. Core Algorithm of the Matrix Matching Engine After receiving the ParsedRequest object, the matching engine executes the following process: 3.1 Parallel Index Query: Simultaneously query four partitions—exact source + exact destination, exact source + "not involved" destination, "not involved" source + exact destination, and "not involved" source + "not involved" destination, and merge and deduplicate to obtain a candidate rule set.

[0061] 3.2 Precise condition matching: Check the remaining four condition fields one by one for each candidate rule. If the rule field is equal to the parsed value or the rule field is "not involved", then the field passes; if all four fields pass, then add it to the matching list.

[0062] 3.3 Weighted Matching Score: If multiple rules are matched, the weighted matching score for each rule is calculated. The weight vector is as follows: Source network region 0.30, Destination network region 0.30, Source disaster recovery mode 0.15, Destination node type 0.10, Destination disaster recovery mode 0.10, Public domain name disaster recovery mode 0.05. Matching coefficient rules: 1.0 for complete equality, 0.5 for "not involved". The score is the sum of the products of each weight and the matching coefficient, and the highest score wins. The system periodically optimizes the weight vector using logistic regression based on historical matching logs.

[0063] 4. Miss handling and self-learning mechanism If the matching list is empty, a miss event is triggered: the miss event is recorded to the database, logs, and message queue. The miss event includes all feature fields, user input, timestamps, etc.; intelligent recommendation is triggered—the most similar rule is recalled from historical hit requests based on cosine similarity. If the similarity exceeds the threshold, a recommendation is made; at the same time, an operation and maintenance work order is created to notify manual intervention.

[0064] The system periodically performs offline K-Means clustering analysis on missed events. If the frequency of a certain feature combination exceeds the threshold, a draft rule suggestion is automatically generated for administrator review. Once approved, the rule is added and the index is refreshed.

[0065] 5. Application Examples The following is a complete example illustrating the implementation process of the present invention.

[0066] Scenario: The source IP is 192.1.68.111, and the disaster recovery mode is master-slave. The managed intranet accesses the Internet domain name www.baidu.com, the protocol is TCP, and the port is 443.

[0067] Step 1: The user fills in the policy requirements, as shown in Table 3.

[0068] Table 3 User-state forms:

[0069] Step 2: Automatic Address Resolution: IPAM queries indicate the source IP belongs to the "hosted intranet," and CMDB queries show the source disaster recovery mode as "primary / backup." The destination domain is identified as an external domain, with the default network zone being "Internet third-party unit," and both the node type and disaster recovery mode being "not involved." The public domain disaster recovery mode is set to "single-active." This forms a hit condition vector: source zone is the hosted intranet, source disaster recovery is primary / backup, destination zone is the Internet third-party unit, destination node is not involved, destination disaster recovery is not involved, and public domain disaster recovery is single-active.

[0070] Step 3: Matrix Matching: Match the corresponding rule in the policy matrix, as shown in Table 4. This rule is associated with three policy templates: unified APP server access to proxy device policy, managed isolation network proxy policy, and managed proxy device access to public network policy, in a fixed order.

[0071] Table 4 Direct Hit Strategy Matrix

[0072] Step 4: Template Rendering: Create a virtual intermediate table and render three templates sequentially. The first template generates proxy device IPs (195.168.8.1 and 195.169.8.1) and port 6099 and writes them to the virtual table. The second template reads the proxy device IPs and ports from the virtual table and combines them with the destination domain name and port to generate a proxy policy. The third template reads the proxy device IPs as the source address and generates a public network access policy. Finally, deployable policy instances are generated, as shown in Tables 5, 6, and 7.

[0073] Table 5. Final generated unified APP server access proxy device policy table

[0074] Table 6. Final Generated Managed Isolation Network Agent Strategy Table

[0075] Table 7. Final generated public network access policy table for managed proxy devices

[0076] Through the above process, users only need to input simple source / destination addresses and protocol ports, and the system will automatically complete address resolution, matrix matching, template rendering, and policy generation, achieving end-to-end policy automation.

[0077] This application names this algorithm the Adaptive Policy Matrix Matching Algorithm based on Multi-Dimensional Feature Fusion (APMM). The algorithm's features are as follows: 1. Multi-level indexing accelerates matching: Hierarchical index structure: The policy matrix rules are constructed into a two-level hash index based on the source network region and the destination network region. Then, within each group, a hash index is built for the remaining conditions using a combination key such as (src_dr_mode, dst_node_type, dst_dr_mode, public_dns_dr_mode). This reduces the matching time complexity from O(N) to close to O(1). O(N) is linear, meaning that the matching time increases linearly with the total number of rules N; O(1) is constant, meaning that the matching time remains relatively stable within a constant range and does not increase significantly with the total number of rules.

[0078] Dynamic index update: When rules are added, deleted, or modified, the index is refreshed in real time to ensure that matching is always based on the latest configuration.

[0079] 2. Intelligent cache prediction: Request parsing cache: The interaction results between the user-input source / destination address and CMDB / IPAM are cached using LRU to avoid repeated queries to external systems and reduce latency.

[0080] Matching result caching: The mapping between the parsed ParsedRequest object and the matching rules is cached. For requests with the same characteristics, the template list is returned directly, further improving throughput.

[0081] Preheating mechanism: Based on historical policy request logs, high-frequency feature combinations are statistically analyzed, and the corresponding rules are preloaded into the cache when the system starts.

[0082] 3. Dynamic weighted scoring and conflict resolution: Rule priority weight: Assign weights to each condition field. For example, the source region has the highest weight. When multiple rules are met at the same time, calculate the weighted matching degree and select the rule with the highest score to avoid ambiguity caused by configuration overlap.

[0083] Machine learning-assisted recommendation: When there is no rule matching, collaborative filtering or similarity algorithms are used to recommend the most similar rules from historical successful matches and provide confidence scores to help operations and maintenance personnel quickly supplement rules.

[0084] 4. Abnormal self-healing and rule self-learning: Missed request log analysis: Records the parsing characteristics of all missed requests, performs periodic cluster analysis, and automatically generates rule suggestions and notifies the administrator if the frequency of the same feature combination exceeds the threshold.

[0085] Rule conflict detection: When adding a new rule, it automatically checks whether it overlaps with existing rules and prompts you to set the priority, ensuring the uniqueness of the matrix.

[0086] 5. Parallel processing: Multi-threaded / coroutine concurrency resolution: For batch strategy requests, coroutines are used to concurrently call external data sources, significantly shortening the overall processing time.

[0087] Piece matching: When the matrix rules are extremely large, the rule set can be divided into pieces, and matching can be performed in parallel in each piece, and finally the results can be merged.

[0088] like Figure 3 As shown, the core matching process of an APMM algorithm in this embodiment is as follows.

[0089] Step A: User submits policy request: Input: A strategy requirement form filled out by the user through the front-end interface, which must include at least the following fields: Source address (can be IP or domain name), destination address (can be IP or domain name), protocol type (such as TCP, UDP), destination port (can be multiple), connection type (optional, such as long connection, short connection); Output: The raw request object (raw_request) in JSON format.

[0090] 1. Generation and validation of dynamic forms on the front end: When a user opens the policy application page, the frontend sends a metadata request to the backend to retrieve the currently available configuration items. The data structure returned by the backend contains the definitions of all fields, such as field name, data type, whether it is required, and the possible values ​​of dropdown options. This metadata is maintained by the backend management interface and can be dynamically adjusted by operations and maintenance personnel. The frontend dynamically renders form components based on this metadata, ensuring that the options in the user interface are always consistent with the backend configuration without requiring modifications to the frontend code.

[0091] After the user completes the data entry, the frontend performs local validation, including ensuring that required fields are not empty, IP address formats conform to IPv4 or IPv6 standards, domain names comply with RFC specifications, and port numbers are within the range of 1-65535. Once validation is successful, the frontend encapsulates the data into a structured JSON object and attaches metadata for tracing purposes, such as a unique request ID generated using a UUID algorithm, the user name, and a timestamp. This JSON object, as the request body, is sent to the backend API gateway via HTTPS.

[0092] 2. Responsibilities and asynchronous decoupling of the backend API gateway: After receiving a request, the backend API gateway first performs basic validation, including verifying the correct JSON format of the request body, the existence of required fields, and the matching of field types. Once the validation passes, the gateway does not perform any business processing but immediately sends the entire request body to the message queue. This design completely decouples request reception from business processing, ensuring the frontend can quickly receive a "request received" response, while actual processing can be done asynchronously, avoiding frontend timeouts due to excessive backend processing time.

[0093] Kafka is chosen as the message queue, and high reliability parameters are configured. Producers send messages in "acks=all" mode, requiring messages to be successfully written to all replicas before acknowledgment; idempotency is also enabled to prevent message duplication due to network retries. Messages are sent to a topic named "policy-request" and partitioned by the hash value of the source address to ensure that requests from the same source address are processed sequentially.

[0094] Step B: Resolve source / destination addresses: Input: raw_request; Output: Preliminary address classification results, including: address type (IP or domain name), whether it is an internal network address (IP) or a public network domain (domain name). Processing logic: Regular expressions are used to determine whether the input is an IPv4, IPv6, or a domain name. If it is an IP address, the internal IP segment configuration library is called to determine whether it belongs to the data center's planned internal network; if it is a domain name, the domain name suffix is ​​checked to see if it matches an internal domain name (such as .internal) or an external domain name.

[0095] 1. Message consumption and parser startup: The backend processing service pulls messages from the Kafka "policy-request" topic in the form of consumer groups. Each consumer processes messages independently, and the consumer group ensures that messages within the same partition are processed sequentially by the same consumer. When a consumer receives a message, it first deserializes it, restoring the JSON string to a request object, and then passes it to the address resolver.

[0096] 2. Regular expression judgment of address type: The address resolver performs type determination on both the source and destination addresses. It uses a pre-compiled regular expression engine to attempt to match IPv4, IPv6, and domain name formats sequentially. The IPv4 regular expression strictly matches dotted decimal notation, the IPv6 regular expression handles standard compressed formats, and the domain name regular expression follows RFC 1035. The determination results are categorized into three types: IPv4, IPv6, and domain name. If none of the three patterns match, it is marked as "unknown address type," an error is returned, and the process terminates.

[0097] 3. Quick prediction of internal network IP addresses: For an address identified as an IP address, the resolver needs to quickly determine whether it belongs to the data center's internal network. When the system starts, it loads all internal network CIDR segment configurations from the database. These configurations include standard private network segments, such as 10.0.0.0 / 8, 172.16.0.0 / 12, and 192.168.0.0 / 16, as well as data center-defined internal network segments, such as 192.1.0.0 / 16. After loading, the system constructs these IP segments into an in-memory interval tree data structure. An interval tree is a balanced binary search tree specifically designed for efficiently resolving interval overlap queries. For an IP address, the interval tree can quickly determine whether the IP falls within any configured internal network segment in logarithmic time complexity. In this example, 192.1.68.111, after being queried using the interval tree, falls within the 192.1.0.0 / 16 segment and is therefore marked as an "internal network IP". If it falls within a standard private network segment, it will be marked as an internal IP address; if it does not fall within either, it will be marked as a "public IP address".

[0098] 4. Preliminary classification of domain names: For addresses identified as domain names, the resolver checks if their suffix belongs to the internal domain whitelist. The internal domain whitelist is configured by operations personnel through a management interface and stored as a list of strings, such as ".bank.cn" or ".internal". The resolver compares the domain suffix with each entry in the whitelist; if a match is found, it is marked as an "internal domain"; otherwise, it is marked as an "external public domain". In this example, www.baidu.com has the suffix ".com", which is not on the whitelist, and therefore is marked as an external public domain.

[0099] 5. Output of preliminary analysis results: After the above steps, the parser generates a lightweight preliminary resolution result object for both the source and destination addresses. This object contains the original string, its type, and a preliminary classification result: whether it's an internal network or an external domain. This preliminary result will be passed to the next stage to determine the subsequent data acquisition strategy.

[0100] Step C: Query the cache: Input: Address resolution result, IP address or domain name; Output: If the cache is hit, return the context attributes corresponding to the address, including network region, disaster recovery mode, node type, etc.; otherwise, proceed to step E.

[0101] Cache Design: Redis is used as a distributed cache, with the key being an address (IP or domain name) and the value being a JSON string containing attributes. The cache employs an LRU eviction policy and sets a TTL (e.g., 24 hours) to prevent data staleness. Active invalidation is also supported: when address information changes in the CMDB, the corresponding cache is cleared via message notification.

[0102] Step D: Retrieve the cached context attributes: If the cache is hit, the attribute object is directly deserialized from Redis, and the process jumps to step H.

[0103] The technical implementation process of step C / step D is as follows: 1. Two-level caching architecture: The system employs a two-level cache to reduce calls to external systems. The first level is a local memory cache, implemented using Caffeine or Guava Cache, stored in the application server's heap memory. Access is extremely fast, but capacity is limited and each service instance operates independently. The second level is a distributed cache, implemented using Redis, shared by all service instances. It has a large capacity but incurs network overhead.

[0104] 2. Cache query process: When detailed attributes of an address are needed, the system first uses the address as the key to query the local cache. The local cache employs an LRU (Least Recently Used) eviction policy and has a reasonable maximum capacity. If the local cache hits, the attribute object is returned directly, skipping subsequent steps. If it misses, the same key is used to query Redis. The Redis key format is fixed as "addr:attr:{address}", and the value is a serialized JSON object. If Redis hits, the system refills the deserialized attribute object into the local cache and then returns it. If Redis also misses, step E is executed, triggering an external system query.

[0105] 3. Design of cached keys and values: The cache key format is "addr:attr:192.1.68.111", which ensures key uniqueness. The cached value is a JSON object containing complete address attributes: network zone, disaster recovery mode, node type, public domain name disaster recovery mode, and last update time. The cache has a 24-hour expiration time (TTL) to prevent data staleness. Furthermore, the system establishes a proactive invalidation mechanism: when address information in CMDB or IPAM changes, the system sends a notification via a message queue. Upon receiving the notification, this system deletes the corresponding Redis key based on the address list, ensuring that the latest data is retrieved for subsequent queries.

[0106] Step E: Call the CMDB / IPAM interface: Input: address; Output: Detailed contextual attributes of the address, including: network zone, such as managed intranet, Internet access zone; disaster recovery mode, including single active, primary backup, dual active, and none; node type, including single node and multiple nodes, which is only meaningful for the destination address; and public domain name disaster recovery mode when it is a domain name.

[0107] API call method: The CMDB query interface is called via HTTP / gRPC, carrying the address parameter. To improve performance, connection pooling and asynchronous I / O (such as aiohttp) are used to concurrently call multiple interfaces. If the interface times out or returns an error, it is logged and a default value (such as "unknown area") is set, triggering subsequent manual review.

[0108] Technical implementation: Encapsulate the CMDB client SDK and integrate circuit breakers (such as Hystrix) to prevent avalanche.

[0109] Step F: Obtain source region / disaster recovery / node type, etc. This step is combined with step E, which involves extracting the required fields after the interface returns the data.

[0110] Step G: Write to cache: Write the attributes obtained in steps E / F into Redis for easy querying next time.

[0111] The technical implementation process of steps E, F, and G is as follows: 1. Orchestration of concurrent queries: When a cache miss occurs, the system needs to simultaneously query both the CMDB and IPAM. To improve efficiency, the system employs a coroutine concurrency model, creating a separate coroutine for each attribute that needs to be queried. At the implementation level, thread pools or asynchronous I / O frameworks are used to manage these coroutines. The system uses a "wait group" mechanism to coordinate the completion of all coroutines: the main coroutine starts all child coroutines and then enters a waiting state until all child coroutines return results or time out. The timeout is set to 3 seconds. If a coroutine does not return before the timeout, the system logs an error, populates the attribute with a default value, and triggers a manual review alert.

[0112] 2. Identification of network areas: Network zone identification relies on the IPAM system. IPAM internally maintains a mapping table between IP address ranges and network zones, using the longest prefix matching algorithm. For example, IPAM might simultaneously show 192.1.0.0 / 16 mapped to the "hosted intranet" and 192.1.68.0 / 24 mapped to the "hosted app zone." When querying 192.1.68.111, IPAM traverses all network segments, finding the most precise match (i.e., the segment with the longest prefix) and returning the corresponding network zone. This design supports fine-grained division of network zones, distinguishing different sub-zones within the same large network segment. For external domain names, since there are no records in IPAM, the system directly returns the default value "Internet third-party unit."

[0113] 3. Disaster recovery mode identification: Disaster recovery mode identification relies on CMDB. The host model in CMDB includes a disaster recovery mode field, with values ​​of single-active, primary / standby, dual-active, and not involved. The system uses CMDB's RESTful API, passing in an IP address, to query the host records associated with that IP. CMDB finds the corresponding host asset based on the IP address and returns detailed information about the host object, including the disaster recovery mode field. For domain names, the system determines the disaster recovery mode based on the domain type: internal domain names read the disaster recovery mode from the CMDB's application service model; external domain names are directly set to "not involved".

[0114] 4. Node type identification: Node type identification is only meaningful for the destination address, used to determine whether the target service is deployed as a single node or multiple nodes, i.e., a load-balanced deployment. The system also achieves this through CMDB queries. For IP addresses, the system queries whether the IP belongs to the backend server list of a certain service model. In the CMDB, the service model records the service name, VIP, backend server list, etc. If the service is associated with multiple backend IPs, it is determined as "multi-node"; otherwise, it is "single-node". For domain names, if the domain name is associated with the load balancer's VIP, the CMDB will explicitly mark the service's node type as "multi-node"; if the domain name directly points to a single server, it is "single-node". For external domain names, the system directly sets them to "not involved".

[0115] 5. Special handling for external domain names: External domain names are a special case in the processing flow. Since there is no configuration information for external domain names in CMDB and IPAM, the system will not initiate an actual CMDB / IPAM query, but will directly construct a default attribute object. The network zone of this object is set to "Internet third-party unit", the disaster recovery mode and node type are set to "not involved", and the public domain name disaster recovery mode is set to "single-active". This default configuration conforms to the business logic of most external access scenarios, and also avoids invalid calls to external systems.

[0116] 6. Cache write: After all attributes are retrieved, the system assembles them into a JSON object and writes it to Redis. The write operation uses the same key format as the query and sets a 24-hour TTL. Simultaneously, the object is also written to a local memory cache so that subsequent queries to the same address can be quickly retrieved.

[0117] Step H: Construct the ParsedRequest object: Input: Context attributes of the source address, context attributes of the destination address, protocol port in the original request, etc. Output: A structured matching condition object ParsedRequest containing the following fields: src_region, src_dr_mode, dst_region, dst_node_type, dst_dr_mode, public_dns_dr_mode; Processing logic: Protocol ports are combined into a string, such as tcp / 443, but they are not directly used in the matrix matching stage; they will be filled in during subsequent template rendering. For certain fields, if they cannot be retrieved from the CMDB, they are set to the default enumeration value UNKNOWN, and an alarm is triggered.

[0118] 1. Data integration: The system integrates the source address attributes and destination address attributes returned in step G, along with information such as the protocol and port from the original request, into a structured matching object called ParsedRequest. This object contains two types of fields: matching condition fields and data fields. The matching condition fields are used for subsequent policy matrix matching and include source network region, source disaster recovery mode, destination network region, destination node type, destination disaster recovery mode, and public domain name disaster recovery mode. The data fields are used for template rendering and include source IP, destination domain name, protocol, and port.

[0119] 2. Field mapping rules: The values ​​of the matching condition fields are directly taken from the attribute results of step G, while the values ​​of the data fields are taken from the original user request. For example, the source network region is taken from the region field in src_attrs, and the source disaster recovery mode is taken from the dr_mode field in src_attrs; the destination network region is taken from the region field in dst_attrs, the destination node type is taken from the node_type field in dst_attrs, the destination disaster recovery mode is taken from the dr_mode field in dst_attrs, and the public domain name disaster recovery mode is taken from the dns_dr_mode field in dst_attrs. The protocol and port are extracted from the original request.

[0120] 3. Instantiation result: In this example, the ParsedRequest object contains the following fields: source network zone is "managed intranet", source disaster recovery mode is "primary / backup", destination network zone is "internet third-party unit", destination node type is "not involved", destination disaster recovery mode is "not involved", public domain name disaster recovery mode is "single-active", protocol is "tcp", and port is "443". This object will be passed to the policy matrix matching module.

[0121] Step I: Detailed description of the strategy matrix matching module: The policy matrix matching module is the core of the entire automated network policy generation system. It is responsible for quickly and accurately locating matching rules within a predefined policy matrix rule set based on the structured conditions (ParsedRequest) parsed from the user request, and outputting the corresponding policy template list. This module integrates innovative mechanisms such as multi-level indexing, dynamic weight scoring, and intelligent caching to ensure the efficiency and accuracy of the matching process.

[0122] 1. Module Overview: Module Name: Policy Matrix Matching Engine; Input: A ParsedRequest object containing parsed conditions such as source / destination network zone, disaster recovery mode, and node type; Output: A matching rule object (MatrixRule) containing an ordered list of policy templates; if no match is found, it returns null and triggers exception handling. Core functionality: Based on multi-dimensional feature combinations, it filters out rules that are complete or optimal matches from the rule set, and supports wildcard (i.e., no processing involved) processing and multi-rule conflict resolution.

[0123] 2. Internal components of the module: 2.1 Index Manager: Responsibilities: Responsible for storing, indexing, and dynamically updating the strategy matrix rules; Key technology: Multi-level indexing is implemented using nested hash tables in memory, with the first-level key being src_region and the second-level key being dst_region.

[0124] To accelerate precise matching, a composite key index is further built within the second level for the remaining conditions such as src_dr_mode, dst_node_type, dst_dr_mode, and public_dns_dr_mode. This is done using Pythondict or JavaHashMap, with tuples as keys and lists of rule objects as values. In practice, the composite key should be unique, but multiple rules are allowed to share the same key due to the presence of wildcards; therefore, it is stored as a list.

[0125] The index supports hot reloading: when the administrator adds, deletes, or modifies rules, the index is refreshed in real time through a message queue to ensure data consistency.

[0126] 2.2 Matching Engine: Responsibilities: Execute the actual rule matching logic, including index queries and condition filtering.

[0127] Its key technologies are as follows: Parallel queries: Since the index is partitioned by source / destination regions, multiple partitions can be queried concurrently, for example, by using coroutines or thread pools, reducing the overall response time; Wildcard handling: During the index query phase, not only is the exact (src_region, dst_region) partition queried, but also (src_region, "not involved"), ("not involved", dst_region) and ("not involved", "not involved") partitions are queried at the same time. The results are merged and deduplicated to ensure that all possible wildcard rules are covered. Exact match: In the candidate rule list, the remaining condition fields are checked in turn, and short-circuit logic is used for fast filtering.

[0128] 2.3 Weight Calculator: Responsibility: When multiple rules match simultaneously, calculate the weighted matching degree of each rule and select the optimal rule.

[0129] Key technology: The preset weight vector W=[w_src_region,w_dst_region,w_src_dr_mode,w_dst_node_type,w_dst_dr_mode,w_public_dns_dr_mode] is used. The weight values ​​are obtained from expert experience or historical data statistics and satisfy the condition that the sum is 1.

[0130] For each candidate rule, the score is calculated using the following formula: , in, n The total number of condition fields participating in the scoring (e.g., source region, destination region, source disaster recovery mode, etc.). matchfactor Value retrieval rule: If the rule field and the parsed value are exactly the same: matchfactor Equals 1; if the rule field is "Not involved": matchfactor Equals 0.5; if fields are inconsistent: matchfactor It equals 0.

[0131] The rule with the highest score is the final selection; if the scores are the same, the rule priority can be considered, such as the rule ID being smaller, or a secondary decision can be triggered, such as manual review.

[0132] 2.4 Result Handler: Responsibility: To perform the corresponding action based on the matching results: Unique match: Directly returns the list of templates in the rules; Multi-rule hit: Returns the result after calling the weight calculator to select the best rule; No match: Record the missing features in the log and trigger the intelligent recommendation or manual intervention process.

[0133] 3. Detailed matching process: 3.1 Step J: Index Query: Input: A ParsedRequest object containing fields such as src_region and dst_region; Operation: Retrieve the first-level index structure from the index manager; concurrently query the following four partitions: P1=index[parsed.src_region][parsed.dst_region], P2 = index[parsed.src_region][“Not involved”], P3 = index["Not involved"][parsed.dst_region], P4 = index["Not involved"]["Not involved"].

[0134] 3.2 Step K: Exact Match and Scoring: Input: a list of candidates and a ParsedRequest; operate: Initialize two lists: exact_matches (completely consistent rules) and fuzzy_matches (rules requiring scoring).

[0135] Iterate through each rule in candidates: check if the four condition fields in the rule, excluding the source / destination region, match the parsed value (or if the rule is "not involved"); if all fields are satisfied, add the rule to exact_matches; otherwise, consider it a mismatch and skip it.

[0136] Here, "exact match" means that the remaining fields are completely matched, that is, the rule field is equal to the parsed value or "not involved". In fact, wildcard cases are already included. Therefore, only some of the candidate rules may meet the remaining conditions.

[0137] Result judgment: If len(exact_matches)==1: proceed to unique match processing; if len(exact_matches)>1: proceed to the weight calculator for selection; if len(exact_matches)==0: proceed to no match processing.

[0138] 3.3 Result Processing: Unique match: Returns exactly_matches[0].template_list directly; Multiple rule match: Call the weight calculator to calculate the score for each rule in exact_matches and return the rule with the highest score; if the highest scores are tied, select the rule according to its priority (such as creation time or manually set order).

[0139] No match: Write the ParsedRequest and its original request information to the "Missed Log" table and record the timestamp.

[0140] Trigger the asynchronous intelligent recommendation service (this service clusters based on historical missed features and generates rule suggestions).

[0141] Returning an empty result notifies the front-end or upper-level caller that manual intervention is required.

[0142] 4. Detailed Explanation of Key Technologies: 4.1 Multilevel hash index: Design rationale: The query conditions of the strategy matrix have a clear hierarchy. The source region and the destination region are the most frequently used filtering dimensions. Dividing based on these two fields first can significantly narrow down the candidate set.

[0143] Implementation details: It uses an in-memory data structure, such as Python's defaultdict(lambda:defaultdict(list)).

[0144] Index building: Load all rules from the database when the system starts up and insert them into the index one by one; at the same time, subscribe to rule change events and update in real time.

[0145] Memory usage optimization: For cases with a large number of rules, compression techniques can be used, such as storing the rule ID list as an integer array, or introducing a third-party in-memory database (such as Redis), but this will increase network overhead.

[0146] 4.2 Wildcard "Not Involved" Handling: Challenge: The "not involved" in the rule means that the field is not subject to restrictions, and the query needs to consider both exact partitions and wildcard partitions.

[0147] Solution: Explicitly include all possible partition combinations during the index query phase to ensure that no wildcard rules are missed.

[0148] Performance considerations: Querying four partitions simultaneously may introduce a small amount of redundancy, but the impact is negligible when the number of rules is controllable; if the partitions are too large, further indexes can be created on the remaining fields within the partitions to reduce scanning.

[0149] 4.3 Weighted Scoring Algorithm: Design goal: To provide an objective and interpretable selection mechanism when multiple rules overlap.

[0150] Weight determination method: Initial values ​​are assigned based on expert experience. For example, the source region and destination region have the highest weights (0.3 each), followed by disaster recovery mode (0.15), node type (0.1), and public domain name disaster recovery (0.05).

[0151] Subsequently, the weights can be dynamically optimized using machine learning methods (such as logistic regression) based on historical matching data, so that the selected rules are more in line with actual habits.

[0152] 4.4 Concurrent Query Optimization: Necessity: When the rule base is large and the number of concurrent requests is high, serial queries may become a bottleneck.

[0153] Implementation: Use coroutines (such as Python asyncio) or thread pools to query the four partitions concurrently, reducing I / O wait. It is actually a memory operation, but concurrency can improve CPU utilization.

[0154] For extremely large rule sets, it is advisable to store rule shards in the memory of multiple machines and aggregate the results through distributed queries.

[0155] 5. Exception handling and logging: Rule not found: When the corresponding partition cannot be found in the index, return an empty candidate list directly and enter the no-match process.

[0156] Inconsistent rule data: If a field value in a rule is invalid (such as an incorrect enumeration value), an error log is recorded and the rule is ignored to ensure the stable operation of the matching engine.

[0157] Performance monitoring: Records the time taken for each match, and issues an alarm if the time exceeds a threshold (e.g., 100ms) to facilitate timely optimization.

[0158] Audit logs record each matching input, rule hit, and result to meet compliance audit requirements.

[0159] 6. Performance Indicators: Matching latency: With 100,000 rules, through multi-level indexing and memory operations, 99% of requests have a matching time of less than 5ms.

[0160] Throughput: A single machine can support more than 5,000 matching requests per second (based on actual testing with an 8-core CPU).

[0161] Cache hit rate: The intelligent caching layer reduces CMDB queries by approximately 60% and overall process time by 40%.

[0162] Step J: Query the index based on the source region and destination region: Objective: To quickly narrow down the candidate rule set and avoid full table scans.

[0163] Index design: The policy matrix rules are preloaded into memory to build a two-level hash index: first-level key: src_region, second-level key: dst_region; Value: A list of all rules belonging to the combination of (src_region and dst_region) (sub-indexes can also be created).

[0164] For cases where the source or destination region in the rule is "not involved", they are grouped into a special group and considered together during the query.

[0165] Query process: Retrieve src_region and dst_region from ParsedRequest; Search the index for a list of rules with Key=(src_region,dst_region), denoted as candidates1; Simultaneously search for rules with Key=(src_region,"Not involved"), Key=("Not involved",dst_region), and Key=("Not involved","Not involved"), merge and deduplicate to obtain candidates.

[0166] The technical implementation is as follows: 1. Data structure design for memory index: When the system starts, the strategy matrix matching module loads all matrix rules in the database that are "enabled" into memory and constructs a multi-level hash index structure. This index is a nested hash table. The key of the first-level hash table is the source network region, and the value is a pointer to the second-level hash table. The key of the second-level hash table is the destination network region, and the value is a list of rules under that (source region, destination region) combination.

[0167] To handle wildcard cases where the rule is "not involved," the system introduces a special wildcard value, typically represented by "". When the source network region of a rule is configured as "not involved," the rule is stored in the second-level hash table corresponding to the "" key in the first-level hash table. Similarly, if the destination network region is "not involved," the rule is stored under the "" key in the second-level hash table. If both the source and destination are "not involved," the rule is stored at the index ("", "*").

[0168] This design allows for quick location of all possible matching rules using wildcard keys during matching, avoiding a full table scan. Once the index is built, the entire structure resides in memory, resulting in a query time complexity close to O(1).

[0169] 2. Dynamic update mechanism of the index: The index is not static; it needs to support runtime updates. When an administrator adds, deletes, or modifies matrix rules through the management interface, the system performs the following operations: First, write the changes to the relational database to ensure data persistence; After a database transaction is successfully committed, the system sends a change event to the message queue. The change event includes the operation type, rule ID, and new rule content. All running matching engine instances subscribe to this message queue; upon receiving a message, each instance performs the corresponding operation in its own memory index: when adding a rule, it calculates the index position where the rule should be stored based on the rule's condition fields and adds the rule to the corresponding rule list; when deleting a rule, it removes it from the corresponding rule list; when modifying a rule, it first deletes the old rule and then adds the new rule.

[0170] This message-based eventual consistency scheme ensures that the indexes of all instances reach consistency in a short period of time, while avoiding database lock contention.

[0171] 3. Execution strategy for concurrent queries: When the matching engine receives the ParsedRequest, it needs to query four index partitions: Partition 1: Exact source region + Exact destination region, Partition 2: Exact source region + Wildcard destination region ("*"), Partition 3: Wildcard source region ("*") + Exact destination region, and Partition 4: Wildcard source region + Wildcard destination region.

[0172] These four queries are independent and have no data dependencies. Therefore, the matching engine employs a parallel query strategy, creating an independent query task for each partition, which can be executed concurrently. At the implementation level, coroutines or thread pools are used to manage these concurrent tasks. After the main task starts all subtasks, it waits for all subtasks to complete using a waiting mechanism (such as a wait group or Future.get).

[0173] Each subtask performs an O(1) lookup operation in an in-memory hash table, returning the corresponding list of rules (which may be empty). After all subtasks are completed, the main task merges the four lists and uses a hash set to remove duplicates, obtaining the final list of candidate rules.

[0174] 4. Performance optimization considerations: To further optimize performance, the system handles rules that are "not involved" in the index specially during index building. These rules actually match all requests, and storing them across all combinations of source and destination regions would consume a significant amount of memory. Therefore, these rules are stored only in the ("") partition, and queries only need to query this partition to retrieve them, avoiding redundant storage in other partitions.

[0175] In addition, the system implements hot and cold partitioning of the index. For frequently accessed (source region, destination region) combinations, the system caches their rule list in a CPU cache-friendly data structure, further reducing access latency.

[0176] Step K: Match the remaining conditions precisely among the candidate rules: For each rule in the candidate list (candidates), check whether the remaining conditions (including src_dr_mode, dst_node_type, dst_dr_mode, public_dns_dr_mode) match the corresponding values ​​in the ParsedRequest. Matching rules: Pass unconditionally if the field values ​​are equal, or if the field is set to "not involved" in the rule.

[0177] The technical implementation is as follows: 1. Matching rule determination logic: After obtaining the list of candidate rules, the matching engine needs to perform precise condition matching on each rule. Precise condition matching targets four condition fields other than the source / destination zone: source disaster recovery mode, destination node type, destination disaster recovery mode, and public domain name disaster recovery mode.

[0178] The matching rules are as follows: If the value of a rule field is exactly equal to the value of the corresponding field in the ParsedRequest, then the field matches; if the value of a rule field is "not involved" (a wildcard), then the field matches unconditionally, regardless of the value of that field in the ParsedRequest; if the value of a rule field is not equal to the value of the corresponding field in the ParsedRequest, and the value of the rule field is not "not involved," then the field does not match. A rule is considered a matching rule only if all four condition fields match.

[0179] 2. Traversal and Short-Circuit Optimization: The candidate rule list is typically significantly reduced in size through index queries, so the system uses a serial traversal approach for precise matching. During the traversal, the system employs a short-circuit optimization strategy: for each rule, the four condition fields are checked sequentially; if a field mismatch is found, the rule is immediately skipped, and subsequent fields are not checked, proceeding directly to the next rule. This optimization reduces unnecessary comparison operations.

[0180] 3. Collection of matching results: After all candidate rules have been traversed, the system collects all matching rules into a list called `matched_rules`. This list will then be passed to the next step for result evaluation.

[0181] Step L: Matching result judgment: The processing depends on the length of matched_rules.

[0182] Case 1: Unique match (len=1), directly select this rule and jump to step M.

[0183] Scenario 2: Multiple rules match (len>1), indicating overlapping matrix configurations (possibly due to multiple rules being set to "not involved"). In this case, a weighted matching score needs to be calculated to select the optimal rule. Weighted matching score calculation: Preset weights for each condition field (based on expert experience or historical data statistics), such as: src_region: 0.3, dst_region: 0.3, src_dr_mode: 0.15, dst_node_type: 0.1, dst_dr_mode: 0.1, public_dns_dr_mode: 0.05; For each rule, calculate the matching score: If the rule field equals the parsed value, the score is the weight; if the rule field is "not involved", the score is the weight * 0.5 (indicating partial match); if the rule field is different from the parsed value, the score is 0. The rule with the highest total score wins. If the total scores are the same, the rule with the smaller ID can be selected or manual intervention can be performed by logging.

[0184] Case 3: No match (len=0), proceed to step O.

[0185] Step M: Return to the list of associated templates: Output the template_list (ordered list) that matches the rule, and proceed to step R.

[0186] When a match is unique, the engine directly reads the list of associated policy templates from the matched rule object. This template list is an ordered array that stores either the template ID or the template name. The order of the list is specified by the administrator when configuring matrix rules and is used to control the activation order of policies.

[0187] The engine returns this template list to the upper-level caller to continue the subsequent rendering process. Simultaneously, the system records an audit log for this match, including the request ID, ParsedRequest content, hit rule ID, and matching time, for later analysis and auditing.

[0188] Step N: Calculate the weighted matching degree and select the optimal one. When multiple rules match simultaneously, the system needs to select the optimal rule from among them. The core of conflict resolution is a weighted scoring mechanism.

[0189] 1. Design of the weight vector: The system assigns a weight value to each condition field, with the sum of all weights being 1. The weight value reflects the importance of that field in strategy matching. The initial weights are set by expert experience. Source network region: 0.3 Target network region: 0.3 Source disaster recovery mode: 0.15 Destination node type: 0.1 Disaster recovery mode: 0.1 Public domain name disaster recovery mode: 0.05; These weights are not fixed. The system supports dynamic weight optimization based on historical data: periodically analyze historical matching logs, use machine learning algorithms (such as logistic regression) to evaluate the contribution of each field to the final rule selection, and fine-tune the weight values ​​accordingly to make the scoring results more in line with actual operation and maintenance habits.

[0190] 2. Determination of matching coefficients: For each candidate rule, the system calculates its matching coefficient with ParsedRequest for each condition field: if the rule field is exactly equal to the ParsedRequest field, the matching coefficient is 1; if the rule field value is "not involved", the matching coefficient is 0.5 (indicating partial match); if the rule field is not equal to the ParsedRequest field and is not "not involved", the matching coefficient is 0. Fields with a matching coefficient of 0 have been filtered out in the exact matching stage of step K, so the matching coefficient for each field of the rule entering the scoring stage can only be 1 or 0.5.

[0191] 3. Score Calculation: The score for each candidate rule is the sum of the weights of all condition fields multiplied by the matching coefficients. The calculation formula is as follows: Score = (src_region weight × src_region matching coefficient) + (dst_region weight × dst_region matching coefficient) + (src_dr_mode weight × src_dr_mode matching coefficient) + (dst_node_type weight × dst_node_type matching coefficient) + (dst_dr_mode weight × dst_dr_mode matching coefficient) + (public_dns_dr_mode weight × public_dns_dr_mode matching coefficient).

[0192] Taking the previous example of multi-rule hits as an example: Rule A (all "not applicable"): Score = 0.3 × 0.5 + 0.3 × 0.5 + 0.15 × 0.5 + 0.1 × 0.5 + 0.1 × 0.5 + 0.05 × 0.5 = 0.5; Rule B (Source disaster recovery mode precisely matches "primary and backup"): Score = 0.3×0.5 + 0.3×0.5 + 0.15×1 + 0.1×0.5 + 0.1×0.5 + 0.05×0.5 = 0.65; Rule B scored higher and was therefore selected as the optimal rule.

[0193] 4. Handling of draws and manual intervention: If multiple rules score exactly the same, the system will further use the following strategy to make a decision: Rules with higher priority field values ​​will be given priority. The rule priority field is an integer that the administrator can specify during configuration. The larger the value, the higher the priority. If the priorities are the same, the rule with the smaller rule ID is selected; assuming that the ID increases in order of creation time, the smaller the ID, the earlier it was created and the more stable it is. If the conflict still cannot be resolved, the system will record a "rule conflict alert" and mark the request as "requiring manual confirmation." Administrators can view the conflict details in the backend and adjust the rule configuration to prevent future occurrences.

[0194] 5. Caching of rating results: To further improve performance, the system caches the feature vector and scoring results of ParsedRequests. For requests with the same feature vector, the previous scoring results can be reused directly, skipping the scoring calculation. The cache uses an LRU eviction policy and sets an appropriate TTL.

[0195] Step O: Record the missed features: Objective: To provide data for subsequent intelligent recommendation and manual rule completion.

[0196] Implementation: Write the ParsedRequest object (containing all parsed features) to a dedicated log table or message queue. Record context such as timestamps and user information.

[0197] When the matching engine determines "no match" in step L, it will enter the miss processing flow.

[0198] 1. Data structure for miss events: The system first constructs a miss event object, which contains the following information: Request identifier: unique request ID, timestamp, and user performing the operation; Matching criteria: All fields in the ParsedRequest: source region, source disaster recovery mode, destination region, destination node type, destination disaster recovery mode, public domain name disaster recovery mode; Raw input: The original source address, destination address, protocol, and port submitted by the user; Environmental information: Request source IP, processing node identifier, etc.

[0199] 2. Multi-dimensional persistence: Miss event objects are written to multiple storage locations: first, they are written to a "miss event table" in a relational database for long-term storage and retrieval; second, they are sent to a log collection system (such as ELK) for real-time monitoring and visualization analysis; and finally, they are sent to a "miss event" topic in a message queue for consumption by intelligent recommendation services.

[0200] 3. Real-time alarm mechanism: For certain critical policy scenarios, such as access to core production systems, the system will set up real-time alerts. When a missed event meets the preset alert conditions, such as the source region being the "core transaction zone," the system will immediately notify the operations and maintenance personnel via WeChat, SMS, or email to ensure that the problem can be responded to quickly.

[0201] Step P: Trigger intelligent recommendation or human intervention: 1. Intelligent Recommendation Module: Offline analysis: Periodically perform cluster analysis (such as K-Means or DBSCAN) on the miss logs to identify frequently occurring feature combinations; Online recommendation: When a new request fails to find the match, collaborative filtering is used to find the historically matched requests that are most similar in features to the current request, calculate the Euclidean distance or cosine similarity, and recommend the corresponding rule. Rule suggestion: If the same combination of features occurs more than the threshold (e.g., 10 times / day), a rule draft will be automatically generated and the administrator will be notified for review.

[0202] 2. Manual intervention: Missed requests are pushed to the operations and maintenance ticket system for manual processing, and manual addition of matrix rules is allowed.

[0203] After manually adding rules, refresh the memory index immediately.

[0204] The technical implementation is as follows: Once a miss event is recorded, the system will initiate an asynchronous intelligent recommendation process and simultaneously trigger a manual intervention process.

[0205] 1. Offline analysis of intelligent recommendations: The intelligent recommendation service periodically (e.g., every early morning) performs offline analysis on the logs of missed events, primarily using clustering algorithms.

[0206] Data preprocessing: Each missed event is converted into a feature vector. Each dimension of the feature vector corresponds to a condition field, and the dimension value is an enumerated value encoding the field. For example, the source region "hosted intranet" is encoded as 1, "internet user" is encoded as 2, and so on.

[0207] Clustering Algorithm: The K-Means algorithm is used to cluster the feature vectors. The value of K is automatically determined by the silhouette coefficient or the elbow rule. After clustering, each cluster represents a class of missed requests with similar features.

[0208] Rule suggestion generation: For each cluster, the system counts the number of requests. If the number of requests for a cluster exceeds a preset threshold (e.g., 10 times / day), the system extracts features from the cluster's central point and generates a draft rule suggestion. The draft includes suggested values ​​for conditions such as source region, destination region, and disaster recovery mode, as well as recommended associated policy templates (selected based on historical similar requests). This draft is then pushed to the management interface for administrator review.

[0209] 2. Online reasoning for intelligent recommendations: When a new missed request occurs, the system will also trigger online recommendations in real time, using a collaborative filtering algorithm.

[0210] Similarity calculation: The similarity between the feature vector of the current request and the feature vectors of all historically matched requests is calculated. The similarity metric used is cosine similarity, which is the cosine of the angle between the two vectors. The closer the value is to 1, the more similar the two requests are.

[0211] Recommendation recall: Find the top K most similar historical requests (K is usually 3-5). If the highest similarity exceeds a preset threshold (e.g., 0.9), the recommendation is considered highly credible.

[0212] Output: The rule matched by the most similar historical request is returned as the recommendation result, along with its confidence score. If the recommendation confidence is high enough, the system can automatically adopt it and directly use the rule to generate a strategy; if the confidence is medium, the recommendation result is shown to the user for confirmation; if the confidence is low, no recommendation is made, and manual intervention is initiated.

[0213] 3. Manual intervention process: For missed requests that cannot be processed automatically or have low confidence in being recommended, the system will create an operations and maintenance ticket. The ticket contains complete information about the missed event, as well as intelligent recommendation suggestions (if any). The ticket is pushed to the operations and maintenance ticket system and assigned to the network policy administrator.

[0214] Administrators view request details in the ticket system to analyze whether new or modified matrix rules are needed. If so, the administrator opens the policy matrix management interface, configures new rules based on request characteristics, and associates appropriate policy templates. After the rules are saved, as mentioned earlier, all matching engine instances will be triggered to refresh their memory indexes via a message queue. After the new rules take effect, the administrator can manually retry the ticket to verify whether the policy was generated correctly.

[0215] 4. Feedback loop: When an administrator adds a rule based on a missed request, the system associates this new rule with the missed event. This association data can be used to optimize intelligent recommendation algorithms, such as serving as positive samples for collaborative filtering to enhance the accuracy of recommendations for similar future requests.

[0216] Step Q: Display recommended rules or report an error: If the intelligent recommendation yields a high-confidence result, it can be displayed to the user for confirmation; otherwise, an error message "Unable to match automatically, please process manually" will be returned.

[0217] The technical implementation is as follows: 1. Synchronization response processing: On the synchronous processing path, after the matching engine completes the matching, if there is no match and the intelligent recommendation service synchronously returns a result (usually via RPC call or cache read), the engine will encapsulate the result into a response object and return it to the front end. The response object contains the following information: Status code: indicates a miss (e.g., "NO_MATCH"); Recommendation information: If there are high-confidence recommendations, include a summary of the recommendation rules (such as source region, destination region, template name) and confidence scores; Work order number: If a work order has been created, return the work order number for the user to query.

[0218] 2. Front-end interface display logic: After receiving the response, the front-end displays it differently based on the status code and recommendation information: High-confidence recommendations: A confirmation dialog box pops up, displaying the recommendation rules in a clear table format, including matching conditions and a list of associated templates. The dialog box provides "Accept" and "Cancel" buttons. After the user clicks "Accept," the frontend re-initiates the request, including the "Accept Recommendation" flag in the request body. Upon receiving this, the backend directly uses the recommendation rules to continue the rendering and distribution process.

[0219] Recommendations are available but with moderate confidence: A notification bar appears at the bottom of the policy application page stating, "Your request did not match any existing policies. The system recommends the following rules for you. Please confirm and resubmit," along with details of the recommended rules. Users can click the "Use Recommendation" button to fill in the recommended rules into the form and then submit manually.

[0220] No recommendations or low recommendation confidence: An error message will be displayed at the top of the page stating, "Unable to automatically match your request. A support ticket has been created for you [Support Ticket Number]. Please wait for the network administrator to process it." Users can check the processing progress using the support ticket number.

[0221] 3. Asynchronous notification mechanism: For requests that fail to be processed automatically, the system will also send an asynchronous notification to the submitting user via WeChat or email, informing them that the request could not be processed automatically and providing a support ticket number. This notification mechanism ensures that users can stay informed about the request's processing status even if they close their browser.

[0222] 4. Monitoring and Statistics: All missed events and their subsequent processing results, including whether users adopted the recommendations and whether administrators added new rules, are recorded in the statistical database. The system displays metrics such as the trend of missed requests, recommendation adoption rate, and average work order processing time through a monitoring dashboard, helping the operations team to continuously optimize the coverage of the strategy matrix and the accuracy of the recommendation algorithm.

[0223] Step R: Template data rendering: Input: A list of templates that match the rules, the original user request, and the parsed intermediate data, such as the source address, destination address, and protocol port.

[0224] Processing logic: Iterate through each template in the template list; extract the corresponding values ​​from the intermediate data table (i.e., the virtual table) according to the predefined field mapping relationship in the template; if the template field requires a fixed value, directly use the fixed value configured in the template; generate instance data for each template, such as multiple strategy records.

[0225] The technical implementation is as follows: 1. Construction of the virtual intermediate table: During rendering, the system maintains a virtual intermediate table, a temporary key-value store whose lifecycle is tied to a single request. The virtual intermediate table initially contains all data fields from the ParsedRequest, such as the source IP, destination domain, and protocol port. During rendering, each template execution may generate new data; for example, the first template might generate the IP address of a proxy device, which needs to be used by the second template. Therefore, the template engine supports writing new data generated during rendering into the virtual intermediate table for subsequent templates to read. This design enables data transfer and dependencies between templates.

[0226] 2. Template structure and field mapping: Each policy template defines its output data structure and the data source for each field. Data sources fall into three categories. The first category is fixed values, such as a policy that always uses the same proxy device address. The second category is read from a virtual intermediate table, such as the source IP address. The third category is read from ParsedRequest, such as the destination port. The template definition is stored in JSON or YAML format and contains complete information such as field names, data types, source types, and source keys.

[0227] 3. Execution logic of the rendering engine: The rendering engine iterates through each template in the template list. For each template, the engine creates a data model containing all the data from the virtual intermediate table and all the data from the ParsedRequest. Then, based on the field mapping relationships defined in the template, the engine parses the value of each field one by one: if it's a fixed value, it directly uses the configured value; if it's a reference type, it looks up the corresponding value in the data model based on the key name. Once all field values ​​are determined, the engine populates these values ​​into the template structure, generating a policy instance. If the template defines logic that requires looping expansion, such as generating multiple policies from multiple destination IPs, the engine will execute the looping generation according to the configuration.

[0228] 4. Data structure of the rendering result: After rendering, the system obtains one or more policy instances. Each policy instance is a structured object containing complete information such as policy type, source address, destination address, destination port, protocol type, and connection type. Policy types include firewall policies, proxy policies, load balancing policies, etc. This object is device-independent, meaning it does not depend on the device syntax of any specific vendor.

[0229] Step S: Generate a deployable policy: The final output is a policy format that the device can recognize, such as firewall command line or JSON configuration, and is distributed to network devices through automated tools.

[0230] Technical Implementation: 1. Device Adapter Mode: The system implements an adapter for each device type. The adapter is responsible for translating a uniform policy instance into device-specific configuration commands. For example, the adapter for a Cisco firewall translates a policy instance into an access-list command line; the adapter for a Huawei firewall translates it into ACL commands; and the adapter for an F5 load balancer translates it into iControlREST API calls. The adapter selection is based on the target device information in the policy instance, which is determined during matrix rule configuration.

[0231] 2. Configuration details: Taking firewall policies as an example, the adapter needs to handle dependencies such as address objects and service objects when generating configurations. For instance, if a policy uses a certain IP address, the adapter may first generate an address object (objectnetwork) and then reference that address object in the access control list (access-list). The adapter internally maintains these dependencies to ensure that the generated configurations are in the correct order.

[0232] 3. Configure automated distribution: Once the configuration is generated, the system calls an automated operation and maintenance tool for deployment. Commonly used tools include Ansible, SaltStack, or a self-developed configuration deployment system. The deployment is initiated via an API request, which includes the target device's IP address, authentication information, and the generated configuration commands. The automated tool establishes a connection with the device, executes the commands, and returns the results. The system records the deployment results; if successful, the policy status is updated to "effective"; otherwise, an error log is logged and an alarm is triggered.

[0233] 4. Full-process auditing and rollback: The entire process, from user request submission to final policy distribution, is meticulously logged with detailed audit logs for each step. These logs include information such as input, output, time consumption, operator, and request ID for each step. If distribution fails, the system supports automatic rollback, which uses automated tools to revert the distributed configuration to its previous state. Simultaneously, the system generates a detailed failure report for operations personnel to analyze the cause.

[0234] How matrix models are stored in computers: The strategy matrix model employs a two-tier architecture of "persistent storage + memory acceleration" in computer systems to balance data persistence and high-performance querying. The specific designs of the two storage methods are described below.

[0235] 1. Persistent storage (relational database): The persistence layer is responsible for storing metadata, historical versions, operation audits, and other information for all matrix rules, ensuring that data is not lost after system restarts, and supporting complex historical queries and statistical analyses.

[0236] 1.1 Core Table Structure Design: The system is designed with three core tables to store the relevant data of the matrix model: matrix rule table, strategy template table, and rule-template association table, as shown in Table 2.

[0237] 1.2 Storage format of field mapping: The `field_mappings` field in the `policy_template` table is stored in JSON format and describes the field composition and data source of the policy template. This design makes the template's field definitions completely data-driven, allowing operations personnel to dynamically add, delete, and modify template fields through the management interface, adapting to new policy requirements without modifying the code.

[0238] 1.3 Index Design and Query Optimization: To improve database query efficiency, the system has created indexes on key fields: Create a composite index on the src_region, dst_region, and status fields of the policy_matrix_rule table to quickly retrieve rules with enabled status; Create an index on the rule_id in the rule_template_relation table to speed up the operation of querying related templates based on rule ID; Create an index on template_type in the policy_template table to filter templates by type.

[0239] 2. Memory storage (acceleration layer): In-memory storage is the core of policy matrix matching. All rules in the enabled state are loaded into memory when the system starts and constructed into an efficient data structure to achieve microsecond-level query response.

[0240] 2.1 Multi-level hash index structure: The in-memory index uses a nested hash map structure. The key of the first-level hash table is the source network region, and the value points to the second-level hash table. The key of the second-level hash table is the destination network region, and the value is a list of rules under that (source region, destination region) combination.

[0241] To handle wildcards that specify "not involved," the system introduces a special key, typically represented by "". When the source region of a rule is "not involved," the rule is stored under the "" key in the first-level hash table; when the destination region is "not involved," it is stored under the "*" key in the second-level hash table. This design allows queries to quickly locate all possible matching rules using the wildcard key.

[0242] 2.2 Internal structure of the rule object: Each rule is stored in memory as a rule object, containing the following attributes: rule ID, source network region, source disaster recovery mode, destination network region, destination node type, destination disaster recovery mode, public domain name disaster recovery mode, a list of associated template IDs (an ordered array), and priority (used to assist in conflict resolution). These attributes are stored using primitive data types to avoid serialization overhead. The template ID list is stored as an integer array, supporting fast traversal.

[0243] 2.3 Optimization of Composite Key Indexes: To further improve matching speed, the system creates a composite key index within each partition of the second-level hash table. The composite key is composed of four condition fields (source disaster recovery mode, destination node type, destination disaster recovery mode, and public domain name disaster recovery mode). For queries that are complete matches (i.e., all fields in ParsedRequest have definite values), the rule can be located directly in O(1) time using the composite key, without traversing the rule list.

[0244] For rules containing "not involved," the system employs a multi-replica storage strategy: a rule may be stored under multiple composite keys within the same partition. For example, a rule with a source disaster recovery mode of "not involved" will be stored under the composite key corresponding to all possible source disaster recovery mode values ​​within the same partition. This design trades space for time to ensure optimal query performance.

[0245] 2.4 Building and updating memory indexes: Startup Loading: When the system starts, it queries the database for all matrix rules with an "enabled" status and builds an in-memory index for each rule. The construction process includes: parsing each condition field of the rule, determining its storage location in the first and second level hash tables based on its values, and storing the rule in the corresponding location according to the composite key indexing strategy. For 100,000 rules, the entire loading process is usually completed within a few seconds.

[0246] Dynamic updates: When administrators add, delete, or modify matrix rules through the management interface, the system adopts a "message-driven eventual consistency" scheme to achieve real-time updates of the in-memory index: changes are first written to the database to ensure persistence; after the database transaction is committed, the system sends the change event containing the operation type, rule ID, and rule content to a message queue, such as RedisPub / Sub or Kafka.

[0247] All running matching engine instances subscribe to this message queue. Upon receiving a message, each instance performs the corresponding operation in its own memory index: when adding a rule, it calculates the index position and inserts it; when deleting a rule, it locates and removes it; when modifying a rule, it first deletes the old rule and then inserts the new rule.

[0248] This design ensures that the indexes of all instances become consistent in a short time, while avoiding database lock contention and complex distributed transactions.

[0249] 2.5 Memory Usage Estimation: The size of the memory index is a crucial consideration in system design. Taking 100,000 rules as an example, each rule object is approximately 200 bytes in size (including field values ​​and pointers). Adding the storage overhead of the hash table itself, the total memory usage is approximately 30-50MB. Multiple replicas of composite key indexes will increase memory overhead to some extent, but it is usually within a manageable range (2-3 times). Therefore, the memory of a single server is sufficient to support the loading of large-scale rule sets.

[0250] The process of resolving network regions, disaster recovery modes, and node types from source / destination addresses is as follows.

[0251] Address resolution is the foundation of policy automation, and its core is to convert user-input IP addresses or domain names into structured attributes that the system can recognize. This process relies on the integration of data from the IP Address Management (IPAM) system and the Configuration Management Database (CMDB), and optimizes performance through multi-level caching and concurrent query mechanisms.

[0252] 1. Overview of the parsing process: The complete process of address resolution can be divided into the following stages: Address type determination: Determine whether the input is an IPv4, IPv6, or a domain name; Internal network prediction: For IP addresses, quickly determine whether they are internal network IPs of the data center; Cache query: Check if the local cache and Redis cache already have the attribute for that address; External system query: When the cache is not hit, concurrently call the IPAM and CMDB interfaces to retrieve attributes; Default value filling: For special addresses such as external domain names, the default properties are returned directly; Cache backfilling: The query results are written to a two-level cache for use by subsequent requests.

[0253] 2. Identification of network areas: Network area identification mainly relies on the IPAM system, whose core mechanism is the mapping relationship between IP address ranges and network areas.

[0254] 2.1 IPAM's storage structure: The IPAM system maintains an IP address range mapping table. Each record contains the following information: ① Network segment CIDR: for example, 192.1.68.0 / 24; ② Network area: for example, "Hosted APP Area"; ③ Area level: for example, "Level 1 Area", "Level 2 Area"; ④ Description information.

[0255] IPAM supports hierarchical management of network segments. It can configure coarse-grained network segments, such as 192.1.0.0 / 16 → "hosted intranet", or fine-grained subnet segments, such as 192.1.68.0 / 24 → "hosted APP zone", and achieves accurate identification through the longest prefix matching algorithm.

[0256] 2.2 Longest prefix matching algorithm: When the system needs to query the network area to which an IP address belongs, IPAM performs the following steps: Iterate through all configured network segments to find all segments containing the IP address; among these segments, select the one with the longest subnet mask (i.e., the most accurate segment); and return the network area corresponding to that segment. For example, the IP address 192.1.68.111 falls into both 192.1.0.0 / 16 (mask length 16) and 192.1.68.0 / 24 (mask length 24). Longest prefix matching will select the larger mask 192.1.68.0 / 24, returning the "Managed APP Area".

[0257] 2.3 Enumerated values ​​of network regions: Network zones are an enumerated type, determined by the data center network architecture. Typical network zones include: Hosted intranet: The network where servers reside within a data center; Hosted App Zone: The sub-zone where the hosted application servers are located; Internet access area: The area that provides internet service to the outside world; Internet third-party entities: logical areas of external third-party services (such as public domain names); Leased network: External units connected via leased lines; Core trading area: The area where the core business systems are located; Development and Testing Area: The area where development and testing environments are located.

[0258] 3. Disaster recovery mode identification: Disaster recovery mode identifies the disaster recovery deployment method of a server or service and is an important condition for determining policy generation.

[0259] 3.1 Disaster recovery mode storage in CMDB: In CMDB, disaster recovery mode is an attribute field of the host model. Each host record contains the following information: host IP address, hostname, and the application system it belongs to; Disaster recovery modes: single-active, primary-backup, dual-active, and none. Data center locations: production center, same-city disaster recovery center, off-site disaster recovery center; The meaning of the values ​​for disaster recovery mode: Single-active: The service is deployed in only one data center and has no disaster recovery capability; Primary and backup: The service is deployed in two data centers, primary and backup. The primary data center provides the service, and the backup data center is on standby. Active-active: Services are deployed in two data centers simultaneously and provide services at the same time; Not applicable: This address is not suitable for disaster recovery mode, such as internet domain names and third-party leased line addresses.

[0260] 3.2 The process of querying disaster recovery mode: When the system needs to query the disaster recovery mode of an IP address, it performs the following steps: using the IP address as the query condition, it searches for a matching record in the host table of the CMDB; if a unique record is found, it directly reads the disaster recovery mode field of the host; if multiple records are found, for example, if an IP is shared by multiple virtual machines, it selects the record with the highest priority according to business rules, or returns "multi-host association" and triggers manual review; if no record is found, it returns "unknown" and logs it for subsequent investigation.

[0261] 3.3 Special handling for domain name disaster recovery mode: The identification logic for disaster recovery modes differs slightly for domain names: Internal domain name: The application service model in CMDB records the disaster recovery mode of the service, which can be read directly; External domains: The system returns "not involved" according to preset rules because the disaster recovery mode of external domains is not controlled by this data center.

[0262] 4-node type identification: The node type is used to determine whether the target service is deployed on a single node or multiple nodes (load balancing), which directly affects whether the policy needs to go through the load balancing device.

[0263] 4.1 Service Model in CMDB: The CMDB maintains an application service model (Service). Each service record contains: service name, service VIP (i.e., virtual IP address), a list of backend servers (multiple IP addresses), node type: single node or multiple nodes, and load balancer information, such as the IP address of an F5 device.

[0264] 4.2 Node type identification logic: When the system queries the node type of a destination IP address, the following logic is executed: IP address lookup: First, determine if the IP address is the VIP of the load balancer. If so, return "Multi-node" directly. Service Query: Query whether a service model in the CMDB is associated with this IP address. If the IP is a backend server for a service, check the number of backend servers for that service. If the number of backend servers is 1, return "Single Node". If the number of backend servers is greater than 1, return "Multi-node"; Default handling: If the IP is not in any service record, assuming it is a standalone deployment, return "single node".

[0265] 4.3 Handling of Misjudgments in Node Type Identification: Simply counting the number of IPs can lead to misjudgments. For example, a service might have only one backend IP, but that IP could actually be a load balancer with multi-node capabilities. To address this, the system supports the following auxiliary mechanisms: Manual assignment: Operations and maintenance personnel can manually specify the node type for a specific IP or service in the CMDB, overriding the automatic identification results; IP Attribution Determination: IPAM is used to determine whether the IP belongs to the load balancer address pool. If it does, it is determined to be "multi-node".

[0266] 5. Special handling for domain name resolution: Domain name resolution differs from IP address resolution; it is necessary to distinguish between internal and external domain names.

[0267] 5.1 Identification of Internal Domain Names: The determination of internal domains relies on an internal domain whitelist. The whitelist is configured by operations personnel and stored as a list of domain suffixes, such as .bank.cn, .internal, and .dc1.local. When a domain is resolved, the system extracts its suffix and matches it against the whitelist. If a match is found, it is marked as an "internal domain" and enters the CMDB query process; otherwise, it is marked as an "external domain".

[0268] 5.2 Obtaining Internal Domain Name Attributes: For internal domain names, the system queries their attributes through the CMDB application service model: query the VIP address corresponding to the domain name, obtain the disaster recovery mode of the service, and obtain the node type of the service (determined by the list of backend servers corresponding to the VIP).

[0269] 5.3 Default attributes of external domain names: For external domain names, since there is no configuration information in the CMDB, the system directly returns the default attribute set: 1) Network Zone: Internet third-party unit, 2) Disaster Recovery Mode: Not involved, 3) Node Type: Not involved, 4) Public Domain Name Disaster Recovery Mode: Single-active. This default handling conforms to the business logic of most external access scenarios, while avoiding invalid queries to the CMDB.

[0270] 6. Caching and Concurrency Optimization: Address resolution involves multiple external system calls, which is a performance bottleneck. The system optimizes this through the following mechanisms: 6.1 Two-level caching architecture: Local caching: Using Caffeine or Guava Cache, stored in the application server's memory, with access latency in the nanosecond range. Capacity is set to 10,000 records, employing an LRU eviction policy. Distributed caching: Uses Redis, shared by all service instances, with access latency in the millisecond range. Unlimited capacity, TTL set to 24 hours.

[0271] Query process: Local cache → Redis → External system query.

[0272] 6.2 Active cache invalidation: When address information in CMDB or IPAM changes, the system sends a notification via a message queue. Upon receiving the notification, this system deletes the corresponding Redis key and local cache entry based on the address list, ensuring that the latest data is retrieved for subsequent queries.

[0273] 6.3 Concurrent Queries: When a cache miss occurs, the system needs to query both IPAM and CMDB simultaneously to retrieve multiple attributes. To improve efficiency, the system employs a coroutine concurrency model, creating a separate coroutine for each attribute query. All coroutines execute in parallel, with the main coroutine waiting for all child coroutines to complete. The timeout is set to 3 seconds; timed-out queries are populated with default values ​​and trigger an alert.

[0274] The specific process of conflict resolution is as follows.

[0275] When multiple rules in the policy matrix match the same user request, the system needs to select the optimal rule through a conflict resolution mechanism. The core of conflict resolution is a dynamic weighted scoring mechanism, supplemented by rule priority and manual intervention.

[0276] 1. The scenario in which the conflict occurs: Conflict resolution mainly occurs in the following two scenarios: 1.1 Explicit overlap: Multiple rules have the same condition field. For example: Rule A: Source zone = managed intranet, destination zone = Internet, all other conditions are "not involved". Rule B: Source zone = managed intranet, destination zone = Internet, all other conditions are "not involved"; This conflict is a configuration error and should be avoided by administrators. The system will detect and alert administrators during rule configuration.

[0277] 1.2 Implicit Overlap: The absence of wildcards causes multiple rules to match simultaneously. For example: Rule A: The source region is equal to the managed intranet, the source disaster recovery mode is equal to primary / backup, the destination region is equal to the Internet, and all other conditions are "not involved". Rule B: The source region is equal to the hosted intranet, the source disaster recovery mode is equal to "not involved", the destination region is equal to the Internet, and all other conditions are "not involved"; When the source disaster recovery mode of a request is "primary backup", both rules will match.

[0278] 2. Detailed Explanation of the Weighted Scoring Mechanism: The weighted scoring mechanism assigns weights to each condition field, calculates the matching score for each rule, and selects the rule with the highest score.

[0279] 2.1 Setting the weight vector: The weight vector reflects the importance of each condition field in policy matching. The initial weights are set by expert experience, as shown in Table 8.

[0280] Table 8 Weight Vector Table

[0281] 2.2 Determination of matching coefficients: For each candidate rule, the system calculates its matching coefficient with ParsedRequest on each condition field, as shown in Table 9.

[0282] Table 9 Matching Coefficient Table

[0283] 2.3 Score Calculation Formula: The score for each rule is the sum of the weights of all condition fields multiplied by the matching coefficients: Score = Σ(weight_i × matching coefficient_i). Taking the previous example of multiple rule hits: Rule A (all "not involved") score = 0.3×0.5 + 0.3×0.5 + 0.15×0.5 + 0.1×0.5 + 0.1×0.5 + 0.05×0.5 = 0.5; Rule B (source disaster recovery mode exactly matches "primary backup") score = 0.3×0.5 + 0.3×0.5 + 0.15×1 + 0.1×0.5 + 0.1×0.5 + 0.05×0.5 = 0.65; Rule B has a higher score and is therefore selected as the optimal rule.

[0284] 2.4 Handling of identical scores: If multiple rules have the same score, the system will use the following strategies to make a decision in sequence: Rule priority: Each rule has a priority field in its configuration; the higher the value, the higher the priority. Rules with higher priority values ​​are selected first. Rule ID: If the priority is the same, choose the rule with the smaller rule ID. Assuming that the ID increases in increments according to the creation time, the smaller the ID, the earlier the creation and the more stable it is. Manual intervention: If the conflict still cannot be distinguished, the system logs a "rule conflict alert" and marks the request as "requiring manual confirmation." Administrators can view the conflict details in the backend and adjust the rule configuration to prevent future occurrences.

[0285] 3. Dynamic weight optimization: The initial weights are set by expert experience, but may not fully reflect actual operation and maintenance scenarios. The system supports dynamic weight optimization based on historical data.

[0286] 3.1 Data Acquisition: The system records the matching process for each policy request, including: all condition fields of the ParsedRequest, the final selected rule, the matching status of each field of that rule, and whether manual intervention was involved. This data is stored as training samples.

[0287] 3.2 Machine Learning Optimization: The system runs offline analysis tasks periodically (e.g., weekly), using a logistic regression algorithm to optimize the weight vector: each request's matching result is treated as a sample, the feature vector consists of the matching coefficients of each field, and the label represents the final selected rule; the logistic regression model learns the contribution of each field to the rule selection and outputs optimized weight values; after small-scale validation, the new weights are gradually rolled out and replace the initial weights. This self-optimization mechanism allows the weight vector to automatically adapt to business changes and continuously improve matching accuracy.

[0288] 4. Conflict prevention mechanisms: In addition to resolving conflicts afterward, the system also provides a mechanism for preventing conflicts beforehand.

[0289] 4.1 Conflict detection during rule configuration: When an administrator adds or modifies matrix rules, the system automatically checks whether the new rule overlaps with existing rules before saving. The detection logic is as follows: Check if there is a rule with exactly the same conditions as the rule to be added. If so, display the message "Rule is duplicated, cannot be added". Check for inclusion relationships, such as all condition fields of the new rule being subsets of existing rules. If so, prompt "The new rule overlaps with existing rules; it is recommended to adjust the priority or refine the conditions."

[0290] 4.2 Visualization of rule conflicts: The system provides a conflict visualization feature in the strategy matrix management interface. When administrators view the rule list, the system highlights overlapping rules and marks overlapping fields to help administrators identify and resolve potential conflict issues.

[0291] The specific handling mechanism for misses is as follows: When a user request cannot find any matching rule in the policy matrix, the system needs to activate a comprehensive miss handling mechanism to ensure that the problem can be detected, analyzed and resolved in a timely manner, and to continuously optimize the coverage of the policy matrix.

[0292] 1. Overall architecture of miss handling: The miss handling mechanism consists of four core modules: 1) Recording module: fully records the detailed information of miss events; 2) Analysis module: performs clustering and pattern recognition on miss events; 3) Recommendation module: recommends possible rules based on historical data; 4) Work order module: triggers manual intervention process.

[0293] 2. Recording of Miss Events: When the matching engine determines "no match", the system immediately constructs a complete miss event object.

[0294] 2.1 Data structure of the record: The miss event contains information as shown in Table 10.

[0295] Table 10 Information on Miss Events

[0296] 2.2 Multi-dimensional persistence: Miss events are written to multiple storage locations to meet different use cases: Relational databases: Write to the "unmatched_events" table for long-term storage and auditing queries; Log system: Logs are sent to the ELK (Elasticsearch, Logstash, Kibana) log platform for real-time monitoring and visualization analysis; Message queue: Sent to the "unmatched_event" topic for consumption by the intelligent recommendation service.

[0297] 2.3 Real-time alarms: For critical business scenarios, the system supports real-time alerts. Administrators can set alert rules in the configuration interface, such as: missed events with the source region being the "core trading area"; missed events with the destination region being the "regulatory reporting system"; the same feature combination occurring more than 5 times within 1 hour; when the alert conditions are triggered, the system will notify operations and maintenance personnel via WeChat, SMS, or email to ensure that the problem can be responded to quickly.

[0298] 3. Intelligent recommendation mechanism: The intelligent recommendation service provides rule suggestions for missed requests through both offline analysis and online reasoning.

[0299] 3.1 Offline Analysis – Clustering Algorithm: The intelligent recommendation service periodically (e.g., every early morning) performs offline analysis on the logs of missed events, primarily using the K-Means clustering algorithm.

[0300] Data preprocessing: Each missed event is converted into a feature vector. Each dimension of the feature vector corresponds to a condition field, and the dimension value is an enumerated value encoding of that field. For example: the source region "hosted intranet" is encoded as 1, the source region "internet user" is encoded as 2, the source disaster recovery mode "primary backup" is encoded as 1, and the source disaster recovery mode "not involved" is encoded as 0; Clustering is performed using the K-Means algorithm to cluster the feature vectors. The K value is automatically determined using the silhouette coefficient or the elbow rule, typically between 10 and 50. After clustering, each cluster represents a class of missed requests with similar features. Rule suggestion generation: For each cluster, the system counts the number of requests. If the number of requests for a cluster exceeds a preset threshold (e.g., 10 times / day), the system extracts features from the cluster's central point and generates a rule suggestion. This includes: the suggested source region, the suggested destination region, the suggested disaster recovery mode, and related policy template recommendations (based on template selection from historically similar requests). This suggestion is pushed to the "Rule Suggestions" list in the management interface for administrator review.

[0301] 3.2 Online Inference – Collaborative Filtering: When a new missed request occurs, the system will also trigger online recommendations in real time, using a collaborative filtering algorithm.

[0302] Similarity calculation: The similarity between the feature vector of the current request and the feature vectors of all historically matched requests is calculated. The similarity metric used is cosine similarity: Similarity = (A·B) / (|A|×|B|), where A and B are the feature vectors of the two requests, respectively. The closer the similarity value is to 1, the more similar the two requests are.

[0303] Recommendation recall: Find the top K most similar historical requests, where K is typically 3-5. If the highest similarity exceeds a preset threshold (e.g., 0.9), the recommendation is considered highly credible.

[0304] Output: The rule matched by the most similar historical request is returned as the recommendation, along with its confidence score. If the recommendation confidence is high enough, the system can automatically adopt it; if the confidence is medium, the recommendation is shown to the user for confirmation; if the confidence is low, it is not recommended.

[0305] 3.3 Recommended self-learning: The recommendation service continuously collects feedback from users and administrators regarding the recommendation results: User-adopted recommendations: positive samples, which enhance the weight of this recommendation pattern; User rejection of recommendation: Negative sample, reduce the weight of this recommendation mode; The administrator added a new rule based on the suggestion: positive samples, to optimize the offline clustering algorithm; This feedback data is used regularly to retrain the recommendation model, creating a positive feedback loop.

[0306] 4. Manual intervention process: For missed requests that cannot be processed automatically or have low confidence levels, the system will create an operation and maintenance work order and initiate a manual intervention process.

[0307] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and not to limit them. Although this application has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation methods of this application. Any modifications or equivalent substitutions that do not depart from the spirit and scope of this application should be covered within the protection scope of the claims of this application.

Claims

1. A method for generating data center network policies based on a policy matrix model, characterized in that, Includes the following steps: Construct a strategy matrix model, which contains multiple matrix rules. Each matrix rule includes at least six condition fields: client network region, client disaster recovery mode, server network region, server node type, server disaster recovery mode, and public domain name disaster recovery mode. Each matrix rule is associated with one or more strategy templates. In response to the user's input of a target access request, the source address and destination address are obtained. The network area to which the source address and destination address belong is resolved through the IP address management system. The disaster recovery mode and node type corresponding to the destination address and the disaster recovery mode corresponding to the source address are obtained through the configuration management database to form a hit condition vector. The hit condition vector includes at least the source network area, source disaster recovery mode, destination network area, destination node type, destination disaster recovery mode and public domain name disaster recovery mode. The hit condition vector is matched with each matrix rule in the strategy matrix model. If the match is successful, the list of strategy templates associated with the matrix rule is obtained. Based on the policy template list, the corresponding field data is extracted from the virtual intermediate table, and the field data is filled into each policy template according to the predefined field mapping relationship of each policy template to generate at least one network policy instance that can be distributed.

2. The data center network policy generation method based on the policy matrix model according to claim 1, characterized in that, The construction of the strategy matrix model includes the following steps: Obtain the defined network area types, disaster recovery mode types, and node types in the data center network, and establish corresponding enumeration value sets for each; wherein, the network area types include at least managed intranet, Internet access zone, Internet third-party unit, and leased line network, the disaster recovery mode types include at least single active, primary backup, dual active, and not involved, and the node types include at least single node, multiple nodes, and not involved; Based on the access flow relationship of the data center network architecture, the policy access path between the client and the server is determined. Based on the policy access path, the value combination of each condition field is selected from the enumerated value set to generate multiple matrix rules. Configure a corresponding strategy template for each of the matrix rules, and set the activation order of the strategy templates.

3. The data center network policy generation method based on the policy matrix model according to claim 2, characterized in that, The construction of the strategy matrix model also includes the following steps: Each of the matrix rules is stored in a policy matrix rule table in a relational database. The policy matrix rule table includes at least the following fields: rule identifier, client network region, client disaster recovery mode, server network region, server node type, server disaster recovery mode, public domain name disaster recovery mode, rule priority, and activation status. When the system starts up or when the policy matrix rule table changes, the enabled matrix rules are loaded into memory and a multi-level hash index is constructed. The first-level key of the multi-level hash index is a combination of the client network region and the server network region, and the second-level key is a combination of the client disaster recovery mode, the server node type, the server disaster recovery mode, and the public domain name disaster recovery mode.

4. The data center network policy generation method based on the policy matrix model according to claim 3, characterized in that, The construction of the strategy matrix model also includes the following steps: In response to the administrator's operation of adding, modifying or deleting matrix rules, the changed matrix rules are synchronously written to the relational database, and the change event is sent to the message queue after the transaction is committed; Each matching engine instance subscribes to the message queue and refreshes its own memory index in real time after receiving the change event, ensuring that the index data of each instance is consistent.

5. The data center network policy generation method based on the policy matrix model according to claim 1, characterized in that, The process of responding to a user's input target access request, obtaining the source address and destination address, resolving the network area to which the source address and destination address belong through the IP address management system, and obtaining the disaster recovery mode and node type corresponding to the destination address and the disaster recovery mode corresponding to the source address through the configuration management database to form a hit condition vector includes the following steps: The source address is typed to determine whether it is an IPv4 address, IPv6 address, or domain name. If the source address is an IP address, the IP address management system is called to query the network area to which the IP address belongs. If the source address is a domain name, it is determined whether the domain name is an internal domain name. If it is an internal domain name, the corresponding network area is queried through the configuration management database. Otherwise, it is marked as an Internet third-party entity. The destination address is type-determined to determine if it is an IPv4 address, IPv6 address, or domain name. If the destination address is an IP address, the IP address management system is invoked to query the network area to which the IP address belongs, and the disaster recovery mode and node type corresponding to the IP address are queried through the configuration management database. If the destination address is a domain name, it is determined whether the domain name is an internal domain name. If it is an internal domain name, the corresponding network area, disaster recovery mode, and node type are queried through the configuration management database; otherwise, it is marked as an Internet third-party entity, and both the disaster recovery mode and node type are marked as not involved. The parsed source network region, source disaster recovery mode, destination network region, destination node type, destination disaster recovery mode, and public domain name disaster recovery mode are combined into the hit condition vector.

6. The data center network policy generation method based on the policy matrix model according to claim 5, characterized in that, The process of responding to a user's input target access request, obtaining the source address and destination address, resolving the network area to which the source address and destination address belong through the IP address management system, obtaining the disaster recovery mode and node type corresponding to the destination address and the disaster recovery mode corresponding to the source address through the configuration management database, and forming a hit condition vector, also includes the following steps: Before calling the IP address management system or configuration management database for querying, the cache is queried using the address as the key. The cache adopts a two-level architecture of local memory cache and distributed Redis cache. If the local cache is hit, the attribute data corresponding to the address is returned directly; if the local cache is not hit but the Redis cache is hit, the attribute data is retrieved from Redis and populated back into the local cache before being returned; if neither cache is hit, the IP address management system or configuration management database interface is called for querying. Write the query results to the Redis cache and set an expiration time. At the same time, write them to the local cache so that subsequent queries with the same address can directly hit the cache.

7. The data center network policy generation method based on the policy matrix model according to claim 5, characterized in that, The process of responding to a user's input target access request, obtaining the source address and destination address, resolving the network area to which the source address and destination address belong through the IP address management system, obtaining the disaster recovery mode and node type corresponding to the destination address and the disaster recovery mode corresponding to the source address through the configuration management database, and forming a hit condition vector, also includes the following steps: For external domain names, when the cache is not hit, the query of the IP address management system and configuration management database is skipped, and a default attribute object is directly constructed. The network zone of the default attribute object is "Internet third-party unit", the disaster recovery mode is "not involved", the node type is "not involved", and the public domain name disaster recovery mode is determined as single active or dual active according to the domain name publishing policy configuration. The "not involved" means that the condition field does not participate in the matching restriction.

8. The data center network policy generation method based on the policy matrix model according to claim 1, characterized in that, The step of matching the hit condition vector with each matrix rule in the policy matrix model, and obtaining the policy template list associated with the matrix rule if a match is successful, includes the following steps: Using the client network region and server network region in the hit condition vector as the query key, four index partitions are queried simultaneously: the exact client region and the exact server region partition, the exact client region and the "not involved" server region partition, the "not involved" client region and the exact server region partition, and the "not involved" client region and the "not involved" server region partition. The candidate rule sets returned by each partition are merged and deduplicated; wherein, "not involved" means that the condition field does not participate in the matching restriction. In the candidate rule set, each matrix rule is checked to see if the other four condition fields (excluding the client network area and the server network area) match the corresponding fields in the hit condition vector. If a field has the value "not involved" in the matrix rule, then the field passes the matching check unconditionally. If all four fields match successfully, then the matrix rule is added to the list of successfully matched rules.

9. The data center network policy generation method based on the policy matrix model according to claim 1, characterized in that, The step of extracting corresponding field data from the virtual intermediate table according to the policy template list, and filling the field data into each policy template according to the predefined field mapping relationship of each policy template to generate at least one deployable network policy instance includes the following steps: Create the virtual intermediate table, which is a key-value pair storage structure and initially contains the source address, destination address, protocol type, port number, and the values ​​of each field in the hit condition vector; The strategy templates to be rendered are obtained sequentially according to the order in the strategy template list. The predefined field mapping relationship configuration of the strategy template is read. The field mapping relationship configuration includes the name of each field in the template and its corresponding data source identifier. The data source identifier includes fixed value source and virtual intermediate table reference source. For each field in the strategy template, the field value is obtained according to its data source identifier: if it is a fixed value source, the pre-configured fixed value is read directly; if it is a virtual intermediate table reference source, the corresponding value is queried from the virtual intermediate table using the field name or field path as the key. Fill the policy template with the values ​​of all fields to generate a policy instance; If new data is generated during the rendering process of the current strategy template, the new data is written into the virtual intermediate table for subsequent strategy templates to read and use. Iterate through all policy templates in the policy template list, generate at least one policy instance, and combine all policy instances into a set of network policies that can be distributed.

10. A data center network policy generation system based on a policy matrix model, characterized in that, include: The model building module is used to build a strategy matrix model. The strategy matrix model contains multiple matrix rules. Each matrix rule includes at least six condition fields: client network region, client disaster recovery mode, server network region, server node type, server disaster recovery mode, and public domain name disaster recovery mode. Each matrix rule is associated with one or more strategy templates. The address resolution module is used to respond to the user's input target access request, obtain the source address and destination address, resolve the network area to which the source address and destination address belong through the IP address management system, obtain the disaster recovery mode and node type corresponding to the destination address and the disaster recovery mode corresponding to the source address through the configuration management database, and form a hit condition vector; the hit condition vector includes at least the source network area, source disaster recovery mode, destination network area, destination node type, destination disaster recovery mode and public domain name disaster recovery mode; The matching engine module is used to match the hit condition vector with each matrix rule in the strategy matrix model. If the match is successful, the strategy template list associated with the matrix rule is obtained. The template rendering module is used to extract corresponding field data from the virtual intermediate table according to the policy template list, and fill the field data into each policy template according to the predefined field mapping relationship of each policy template to generate at least one network policy instance that can be distributed.

Images