Application dependence topology generation method and system based on multi-source configuration analysis

Abstract

The invention discloses an application dependency topology generation method and system based on multi-source configuration analysis, and the method comprises the steps: obtaining an application configuration snapshot in response to a configuration updating event of an application release assembly line; identifying a configuration source protocol, converting configuration data in different formats into a unified standardized key value pair set, and detecting configuration change by calculating a hash feature value; if the change exists, carrying out regular matching and semantic mapping on the standardized key value pair by utilizing a multi-level semantic rule base, extracting implicit service end points and protocol characteristics, and generating application dependency relationship data with confidence coefficient weight; and finally, mapping the data into node and edge objects in a graph database, constructing and updating an application dependent topological graph structure, and driving a rendering engine to generate a dependent topological view. According to the invention, automatic identification and visual display of the application dependency relationship are realized.

Description

Technical Field

[0001] This invention relates to the field of microservice architecture governance and operation and maintenance technology, and in particular to an application dependency topology generation method and system based on multi-source configuration parsing. Background Technology

[0002] Currently, with the widespread adoption of microservice architecture, enterprise application systems are becoming increasingly complex, with intricate inter-service call relationships (dependencies). To ensure system stability and maintainability, accurately understanding the dependency topology between applications is crucial.

[0003] Existing application dependency discovery methods are mainly divided into two categories: one is runtime traffic-based APM (application performance monitoring) tools (such as Zipkin and SkyWalking), which work by capturing actual traffic through bytecode enhancement or network interception; the other is static code analysis-based tools (such as ArchUnit), which identify dependencies by scanning the code structure.

[0004] However, in practical applications, the aforementioned existing technologies have the following drawbacks: APM tools rely on actual traffic generated during operation to generate topology, making it impossible to perform architecture verification before deployment (design or release phase), and they are prone to overlooking internal logic or obscure interfaces that do not generate standard network traffic; static code analysis has difficulty parsing link information dynamically distributed through configuration centers (such as Nacos and Apollo), resulting in the inability to identify the application's true dependencies on middleware such as databases and message queues; the existing dependency discovery process is disconnected from the configuration change process, and after operations and maintenance personnel modify the configuration, they cannot see the impact of the change on the overall architecture topology in real time and intuitively, which can easily lead to production failures caused by configuration drift. Summary of the Invention

[0005] To overcome the technical deficiencies in the prior art, this invention provides an application dependency topology generation method and system based on multi-source configuration parsing.

[0006] To solve the above problems, the present invention is implemented according to the following technical solution:

[0007] The first aspect of this invention provides a method for generating application dependency topology based on multi-source configuration resolution, comprising:

[0008] S10, in response to the configuration update event of the application release pipeline, obtain the application configuration snapshot data of the application to be released and the corresponding release version identifier;

[0009] S20, based on the metadata of the application configuration snapshot data, identify its configuration source protocol, call the parsing logic corresponding to the configuration source protocol, convert the application configuration snapshot data of different formats into a standardized key-value pair set in a unified format, and calculate the hash feature value of the standardized key-value pair set to determine whether there is a configuration change;

[0010] S30, when it is determined that there is a configuration change, perform dependency feature extraction on the standardized key-value pair set, and use a pre-set multi-level semantic rule library to perform regular expression matching and semantic mapping on the extracted configuration key names and key values;

[0011] The semantic mapping includes identifying the target service endpoint address, port number and middleware protocol features implicit in the configuration items, thereby generating application dependency data containing dependent parties, dependent parties and link attributes, and assigning corresponding confidence weights to the application dependency data according to the hierarchy of the matching rules.

[0012] S40, parse the application dependency data and map it to node objects and edge objects in the graph database; construct or update the application dependency topology graph data structure based on the node objects and edge objects, and send the updated topology data instructions to the rendering engine to generate a dependency topology view.

[0013] In conjunction with the first aspect, the present invention provides a first specific implementation of the first aspect. Specifically, in step S20, the specific steps of calculating the hash feature value of the standardized key-value pair set to determine whether there is a configuration change include:

[0014] The current version of the standardized key-value pair set is serialized, and its global digest hash value is calculated;

[0015] The global digest hash value of the previous version of the application to be released is retrieved and compared.

[0016] If the comparison results are inconsistent, the key-value pair sets of the old and new versions are traversed, the differences are identified based on the key name index, the configuration items marked as added, modified or deleted are extracted, and an incremental configuration dataset is generated.

[0017] The incremental configuration dataset is input into S30 as target data, and the dependency feature extraction is performed only on the configuration items that have changed.

[0018] In conjunction with the first aspect, the present invention provides a second specific implementation of the first aspect. Specifically, in step S30, the specific steps of performing regular expression matching and semantic mapping using the multi-level semantic rule base adopt a cascaded matching logic executed according to priority. The logic includes:

[0019] First-level protocol feature matching: Scan the value field of the standardized key-value pair set. If a preset standard link protocol header feature code is matched, determine the protocol type of the application dependency based on the protocol header feature code.

[0020] Second-level key name semantic matching: If the first-level protocol feature matching fails, then perform word segmentation and keyword matching on the key name field of the standardized key-value pair set. If a predefined component identifier is matched, then infer the component type of the application dependency.

[0021] Third-level link structure parsing: Perform string structure parsing on the value field, and extract the target service network address and port number parameters using regular expressions;

[0022] Fourth-level service name extraction: Based on the preset microservice naming rules, extract strings that conform to the rules from the key field or value field and identify them as the names of the microservices that are depended upon.

[0023] In conjunction with the first aspect, the present invention provides a third specific implementation of the first aspect. Specifically, in step S30, the calculation step of the confidence weight includes:

[0024] Obtain the preset base weight values ​​of each level of rules in the multi-level semantic rule base, wherein the base weight value of the first level protocol feature matching is greater than the base weight value of the second level key name semantic matching;

[0025] The matching score is calculated by analyzing the rule hierarchy, the number of rules hit, and the completeness of the extracted fields during the statistical parsing process.

[0026] A weighted calculation is performed based on the basic weight value and the matching score, and the calculation result is normalized and mapped to a predetermined numerical range as the confidence attribute value of the application dependency data.

[0027] In conjunction with the first aspect, the present invention provides a fourth specific implementation of the first aspect. Specifically, in step S40, the step of constructing or updating the application-dependent topology graph data structure specifically includes:

[0028] Retrieve master node objects in the graph database that are uniquely indexed by the identifier of the application to be published;

[0029] Based on the application dependency data, a set of candidate edge objects to be written is constructed, and their attributes are compared with those of the existing associated edge objects in the graph database.

[0030] Based on the comparison results, graph database operation instructions are generated. These instructions include instructions to create new edges pointing to new dependencies, instructions to remove edges pointing to invalid dependencies, and instructions to update the confidence and version attributes of existing edge objects.

[0031] In conjunction with the first aspect, the present invention provides a fifth specific implementation of the first aspect, specifically, the method further includes an architecture compliance detection and release control step:

[0032] After updating the application-dependent topology graph data structure in step S40, a graph traversal algorithm is executed starting from the master node object;

[0033] Check if there is a closed loop path pointing to the starting point in the traversal path, or if there is a target node link that is not in the preset access control list.

[0034] If the closed-loop path or a link not in the preset access control list is detected, an abnormal status identifier is generated, and an interrupt signal is sent to the application release pipeline through the application programming interface to block the release process of the current version.

[0035] In conjunction with the first aspect, the present invention provides a sixth specific implementation of the first aspect, specifically, step S40 further includes the step of constructing a traceability index:

[0036] When generating the application dependency data, the key name, key value, and hit rule ID of the original configuration item on which the dependency was based are recorded;

[0037] Construct a bidirectional mapping index table between the dependency edge object ID and the original configuration item record;

[0038] In response to a received query request for a specific dependent edge object, the corresponding original configuration item record and rule description information are retrieved through the bidirectional mapping index table and returned for front-end rendering and display.

[0039] In conjunction with the first aspect, the present invention provides a seventh specific implementation of the first aspect, specifically including a topology history version backtracking step:

[0040] Maintain a topology version table in the relational database. The topology version table records snapshot data including pipeline identifier, release environment, creation time, and topology change set.

[0041] When S40 generates the latest application dependency topology graph data structure, the incremental part of this change is encapsulated as a snapshot of the topology change set in JSON format and written to the topology version table;

[0042] In response to a topology query request for a specific historical moment, the system first retrieves the most recent complete baseline version from the topology version table. Then, it retrieves snapshot data of all topology change sets from the baseline version to the historical moment in chronological order and replays the snapshot data of the topology change sets sequentially in memory to reconstruct the application-dependent topology graph data structure for that historical moment.

[0043] In conjunction with the first aspect, the present invention provides an eighth specific implementation of the first aspect, specifically including a semantic rule base update step:

[0044] Based on the execution events of the application release pipeline, and listening for changes in the hash value of the rule file, the rule hot reloading process is triggered;

[0045] When a rule update is detected, load the latest rule set configuration and verify it;

[0046] After successful verification, the rule set in memory is updated by switching atomically, so as to achieve zero-downtime update while keeping the old rule set in service.

[0047] A second aspect of the present invention provides an application dependency topology generation system based on multi-source configuration resolution, the system comprising:

[0048] Memory is used to store computer program instructions;

[0049] A processor, configured to execute the computer program instructions to implement the application-dependent topology generation method based on multi-source configuration resolution as described in the first aspect of the present invention; the system further includes:

[0050] The configuration acquisition unit is used to respond to configuration update events in the application release pipeline and obtain application configuration snapshot data and the corresponding release version identifier of the application to be released.

[0051] The standardized parsing unit is used to identify the configuration source protocol of the application configuration snapshot data based on its metadata, call the corresponding parsing logic to convert the data into a standardized key-value pair set in a unified format, and calculate the hash feature value to determine the increment;

[0052] The dependency feature analysis unit is used to perform regular expression matching and semantic mapping on the standardized key-value pair set when a configuration change is determined, using a pre-built multi-level semantic rule base, to identify the target service endpoint address and middleware protocol features, generate application dependency data, and calculate confidence weights.

[0053] The topology data construction unit is used to parse the application dependency data, map it to node objects and edge objects in the graph database, and perform write operations on the graph database to build or update the application dependency topology graph data structure.

[0054] The compliance control and interaction unit is used to perform architecture compliance checks based on the updated application dependency topology graph data structure. When an abnormal path is detected, it generates an interruption signal to block the release and generates visualization rendering instructions for front-end display based on user requests.

[0055] Compared with the prior art, the beneficial effects of the present invention are:

[0056] This invention discloses an application dependency topology generation method and system based on multi-source configuration parsing. By responding to configuration update events in the application release pipeline, a configuration snapshot is obtained and parsed before application execution. This approach allows application dependency generation to be based on static configuration data to be released, providing a dependency analysis perspective independent of runtime business traffic, and enabling the discovery of middleware and service dependencies defined by configuration items. By identifying the configuration source protocol and converting it into a standardized key-value pair set in a unified format, unified processing of configuration data in different formats is achieved. Simultaneously, hash feature value comparison technology is used to determine whether configuration changes exist, ensuring that subsequent dependency feature extraction steps are executed only when changes are detected, thus avoiding redundant calculations of unchanged configuration data and saving system processing resources. A pre-built multi-level semantic rule base is used to perform regular expression matching and semantic mapping on configuration key names and key values, enabling the extraction of implicit target service endpoints, ports, and protocol features from text configuration. Application dependency data is assigned corresponding confidence weights according to the hierarchy of the matching rules, ensuring that the generated dependency topology data contains numerical attributes indicating the reliability of its inference basis. This invention maps the parsed application dependency data into node and edge objects in a graph database, using a graph structure to store the association data between applications. By constructing or updating the application dependency topology graph data structure and sending data instructions to the rendering engine, it can support the generation and display of dependency topology views, making it convenient for operations and maintenance personnel to view the call structure between applications. Attached Figure Description

[0057] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings, wherein:

[0058] Figure 1 This is a flowchart illustrating the steps of an application dependency topology generation method based on multi-source configuration parsing according to the present invention.

[0059] Figure 2 This is a block diagram of an electronic device used to implement embodiments of the present invention;

[0060] In the picture:

[0061] 10 - Task area determination module; 20 - Task generation module;

[0062] 600 - Electronic device, 601 - Computing unit, 602 - ROM, 603 - RAM, 604 - Bus, 605 - I / O interface, 606 - Input unit, 607 - Output unit, 608 - Storage unit, 609 - Communication unit. Detailed Implementation

[0063] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0064] Example 1

[0065] like Figures 1-2 As shown, the first aspect of the present invention provides a method for generating application dependency topology based on multi-source configuration parsing, comprising:

[0066] S10, in response to the configuration update event of the application release pipeline, obtain the application configuration snapshot data of the application to be released and the corresponding release version identifier;

[0067] S20: Identify the configuration source protocol of the application configuration snapshot data based on its metadata, call the parsing logic corresponding to the configuration source protocol, convert application configuration snapshot data of different formats into a standardized key-value pair set in a unified format, and calculate the hash feature value of the standardized key-value pair set to determine whether there is a configuration change.

[0068] S30, when it is determined that there is a configuration change, perform dependency feature extraction on the standardized key-value pair set, and use a pre-built multi-level semantic rule library to perform regular expression matching and semantic mapping on the extracted configuration key names and key values;

[0069] The semantic mapping process includes identifying the target service endpoint address, port number, and middleware protocol features implicit in the configuration items, thereby generating application dependency data containing dependent parties, dependent parties, and link attributes, and assigning corresponding confidence weights to the application dependency data according to the hierarchy of the matching rules.

[0070] S40: Parse application dependency data and map it to node and edge objects in the graph database; build or update the application dependency topology graph data structure based on the node and edge objects, and send the updated topology data instructions to the rendering engine to generate a dependency topology view.

[0071] like Figure 1As shown, this invention provides a method for generating application dependency topology based on multi-source configuration parsing. This embodiment relies on an enterprise's DevOps deployment platform and unified configuration center, enabling automated conversion from static configuration data to dynamic architecture topology. Specifically, it includes the following steps:

[0072] S10, in response to the configuration update event of the application release pipeline, obtains the application configuration snapshot data of the application to be released and the corresponding release version identifier.

[0073] In this embodiment, the dependency analysis system is deeply integrated with the CI / CD release pipeline. When operations or development personnel trigger an application release or configuration change operation on the release platform, a synchronization event is generated when the pipeline reaches the configuration loading stage.

[0074] Triggering timing: Config Update or Deployment Start events in the system listener pipeline.

[0075] Content retrieved:

[0076] Application configuration snapshot data: The system not only obtains local configuration files (such as application.properties) from the application code package, but also obtains a complete copy of the application's configuration that is about to take effect in the configuration center (such as Nacos, Apollo) or container orchestration platform (such as K8sConfigMap) through API calls. These configurations are frozen into a snapshot at this time.

[0077] Release version identifier: Obtain the unique ID or GitCommit number of the current pipeline as the unique version index of this snapshot, ensuring that the generated topology map can accurately correspond to the specific historical moment.

[0078] S20: Identify the configuration source protocol of the application configuration snapshot data based on its metadata, call the parsing logic corresponding to the configuration source protocol, convert application configuration snapshot data of different formats into a standardized key-value pair set in a unified format, and calculate the hash feature value of the standardized key-value pair set to determine whether there is a configuration change.

[0079] Because enterprises have diverse configuration sources and different formats (such as YAML, XML, Properties, JSON), this step uses a multi-source configuration adapter for standardization.

[0080] Protocol identification and conversion: The system first reads the file extension or source tag in the metadata.

[0081] If the source is a KubernetesConfigMap (YAML format), the adapter flattens its hierarchy.

[0082] If the source is Spring Cloud Nacos (Properties format), the adapter directly reads the key-value pairs;

[0083] Transformation result: All configurations in different formats were eventually cleaned into a unified Map.<String,String> The structure (i.e., a standardized collection of key-value pairs), for example, mapping spring.datasource.url to the key and jdbc:mysql: / / 192.168.1.10:3306 / db to the value.

[0084] Change detection (hash comparison):

[0085] To reduce unnecessary computation, the system serializes the cleaned, standardized key-value pair set and calculates its global MD5 hash.

[0086] The hash value is compared with the hash value of the last successfully released version of the application. If the hash values ​​match, it means that the dependency relationship has not changed, and the process terminates; if they do not match, it is determined that there is a configuration change, and the process proceeds to S30.

[0087] S30, when it is determined that there is a configuration change, perform dependency feature extraction on the standardized key-value pair set, and use a pre-built multi-level semantic rule library to perform regular expression matching and semantic mapping on the extracted configuration key names and key values.

[0088] This step is the core intelligent inference process. The system loads a pre-built multi-level semantic rule base, which contains feature definitions for different middleware (Redis, MySQL, Kafka, Dubbo, etc.).

[0089] Regular expression matching and semantic mapping process:

[0090] Endpoint and Protocol Identification: The engine scans configuration values. For example, if a value begins with "jdbc:mysql: / / ", it immediately identifies it as a dependency on a MySQL database; if a value contains a string with the structure "kafka:9092", it identifies it as a Kafka dependency.

[0091] Identifying implicit features: When there is no explicit protocol header in the value (e.g., only a list of IPs), the engine analyzes the configuration key. For example, if the key contains redis.host or mq.server, the system infers the corresponding component type based on the semantic mapping of the key.

[0092] Generate dependency data: After successful parsing, the system extracts the target service's IP address (e.g., 192.168.1.10), port number (e.g., 3306), and protocol type, generating a structured data entry: {Dependency: App_A, Dependency Provider: MySQL_Instance_B, Type: Database, Port: 3306}.

[0093] Assignment of confidence weights:

[0094] The system calculates the reliability of dependencies based on the hierarchy of matching rules.

[0095] High confidence (e.g., 0.9): Hits explicit protocol header rules (e.g., jdbc: / / ), as this is almost impossible to generate from non-dependent configurations.

[0096] Medium confidence level (e.g., 0.6): Only the key name keyword rule is hit (e.g., the key name contains "redis"), and there is a possibility of false positives.

[0097] The final application dependency data will carry this calculated confidence score, which will be used to show the user the credibility of the data in the subsequent topology diagram (e.g., using solid lines to represent high confidence and dashed lines to represent low confidence).

[0098] S40: Parse application dependency data and map it to node and edge objects in the graph database; build or update the application dependency topology graph data structure based on the node and edge objects, and send the updated topology data instructions to the rendering engine to generate a dependency topology view.

[0099] Graph database mapping:

[0100] The system is linked to a graph database (such as Neo4j).

[0101] Node object: Maps the application to be published to a SourceNode, and maps the resolved dependents (such as IP addresses or service names) to TargetNodes. If a TargetNode already exists, it is reused.

[0102] Edge object: Creates a directed edge from SourceNode to TargetNode, with the edge type marked as DEPENDS_ON, and stores the link attributes (port, protocol) and confidence weight generated in S30 as attributes of the edge.

[0103] Topology update and rendering:

[0104] The system executes graph update commands, performing incremental updates only on the subgraphs involved in this release (adding new edges and removing edges that existed in the old version but have been deleted in the new snapshot).

[0105] After the update is complete, the backend generates a JSON instruction set containing node coordinates, connection relationships, and styles, and sends it to the frontend rendering engine (such as a visualization component developed based on D3.js or G6).

[0106] View generation: Finally, a real-time dependency topology view is presented on the operations and maintenance dashboard or console. Operations and maintenance personnel can intuitively see that AppA is connected to MySQLB, and can view the original configuration source and confidence details behind the connection by clicking on the connection.

[0107] In conjunction with the first aspect, the present invention provides a first specific implementation of the first aspect. Specifically, in step S20, the specific steps of calculating the hash feature value of the standardized key-value pair set to determine whether there is a configuration change include:

[0108] Serialize the current version of the standardized key-value pair set and calculate its global digest hash value;

[0109] Retrieve and compare the global digest hash value of the previous version of the application to be released;

[0110] If the comparison results are inconsistent, the key-value pair sets of the old and new versions are traversed, the differences are identified based on the key name index, the configuration items marked as added, modified or deleted are extracted, and an incremental configuration dataset is generated.

[0111] Input the incremental configuration dataset as target data into S30, and perform dependency feature extraction only on the configuration items that have changed.

[0112] It should be noted that this embodiment further describes in detail the process of calculating the hash feature value of the standardized key-value pair set in step S20 to determine whether there is a configuration change.

[0113] In real-world large-scale microservice clusters, application configuration files often contain hundreds or even thousands of configuration items, but a single deployment may only modify one or two parameters (e.g., only changing the maximum number of connections in the database connection pool). Performing regular expression parsing on the entire configuration for each deployment would consume a significant amount of unnecessary computing resources. Therefore, this embodiment employs an incremental filtering mechanism based on hash digests, with the following specific steps:

[0114] Step 1: Full configuration serialization and global hash calculation

[0115] When S20 completes the format conversion of the multi-source configuration, it obtains a standardized key-value pair set (Map).<String,String> Afterwards, the system first sorts the keys in the collection lexicographically. This sorting eliminates serialization differences caused by varying the order in which configuration items are read. Then, the sorted key-value pair collection is converted into a standard JSON string or binary stream. The serialized string is then processed using either MD5 or SHA-256 algorithms to generate a unique global digest hash value (e.g., a1b2c3d4...). This hash value represents the complete configuration state of the application version to be released.

[0116] Step 2: Quick comparison of historical versions

[0117] The system queries the release version table in the database and retrieves the global digest hash value of the last successfully released version of the application based on the application ID. If Current_Hash == Last_Hash: The system determines that this release did not involve any configuration changes (it may only be a code logic change or a restart), and directly terminates the subsequent dependency analysis process, reusing the topology structure of the previous version, greatly reducing system overhead. If Current_Hash != Last_Hash: The system determines that there are configuration changes and proceeds to the next step of fine-grained comparison.

[0118] Step 3: Difference Calculation Based on Key Name Index. Once a change is confirmed, the system simultaneously loads two key-value pair sets: the current version and the previous version. It then compares each item using either a two-pointer traversal or a hash mapping method to identify the differences in the following three states:

[0119] Added: Key names exist in the current version but not in the previous version.

[0120] Example: A new configuration item, kafka.bootstrap.servers=10.0.0.1:9092, has been added.

[0121] Modification: The key name exists in both versions, but the corresponding key values ​​are different.

[0122] Example: Change db.url from jdbc:mysql: / / old-ip to jdbc:mysql: / / new-ip.

[0123] Delete: The key name exists in the previous version but not in the current version.

[0124] Example: The redis.host configuration item has been removed.

[0125] Step 4: Generate incremental datasets and drive downstream processing

[0126] The system encapsulates the identified discrepancies into an incremental configuration dataset. This dataset contains only the changed configuration items and their change type tags. This incremental dataset is then passed as input to step S30. In S30, the intelligent dependency inference engine performs regular expression matching and semantic mapping only on the configuration items in the incremental dataset.

[0127] For items marked as new or modified, the engine recalculates their dependencies;

[0128] For items marked for deletion, the engine directly generates instructions to remove dependencies;

[0129] For a large number of unchanged configurations not included in the dataset, the engine skips parsing entirely and directly inherits the analysis results from the old version.

[0130] Through the above mechanism, this embodiment reduces the time complexity of dependency analysis from being related to the total number of configuration rows to being related to the number of configuration change rows. In common operation and maintenance scenarios, configuration changes usually account for less than 1% of the total configuration, so this mechanism can improve the processing speed of dependency discovery by 1-2 orders of magnitude, achieving near real-time topology updates.

[0131] In conjunction with the first aspect, the present invention provides a second specific implementation of the first aspect. Specifically, in step S30, the specific steps of performing regular expression matching and semantic mapping using a multi-level semantic rule base adopt a cascaded matching logic executed according to priority. The logic includes:

[0132] Level 1 Protocol Feature Matching: Scan the value field of the standardized key-value pair set. If a preset standard link protocol header feature code is matched, determine the protocol type of the application dependency based on the protocol header feature code.

[0133] Second-level key name semantic matching: If the first-level protocol feature matching fails, then perform word segmentation and keyword matching on the key name field of the standardized key-value pair set. If a predefined component identifier is matched, then infer the component type of the application dependency.

[0134] Third-level link structure parsing: Perform string structure parsing on the value field, and extract the target service network address and port number parameters using regular expressions;

[0135] Level 4 Service Name Extraction: Based on preset microservice naming rules, extract strings that conform to the rules from the key or value field and identify them as the names of the microservices that are depended upon.

[0136] In this embodiment, specifically:

[0137] Level 1: Protocol Feature Matching. This is the highest priority matching level. The engine scans the value fields of the standardized key-value pair set to identify whether it contains a standard protocol header.

[0138] The engine has built-in recognition rules for common middleware protocol headers.

[0139] The system scans configuration values ​​one by one. If a value begins with "jdbc:mysql: / / ", it directly infers that the configuration corresponds to a MySQL database dependency; if a value begins with "redis: / / ", it infers a Redis dependency; and if a value begins with "kafka: / / ", it infers a Kafka dependency. Upon hitting the protocol header at this level, the protocol type of the dependency can be determined, and subsequent structure parsing can begin.

[0140] Level 2: Key Name Semantic Matching. If the Level 1 match fails (e.g., the configuration value only contains an IP address or a string without an obvious protocol header), then this level is entered. The engine then analyzes the key field (Key) of the standardized key-value pair set.

[0141] The engine performs matching based on predefined key name patterns to find whether the key name contains specific semantic keywords.

[0142] The system performs word segmentation or fuzzy matching on the key names. For example, if a key name contains the keyword "Redis," even if its corresponding value is just an IP address, the system infers it as a Redis dependency; similarly, if a key name contains the keywords "MySQL" or "Kafka," it is inferred as a MySQL or Kafka dependency, respectively. This step compensates for the blind spots in recognizing non-standard connection string configurations.

[0143] Level 3: Link Structure Parsing After determining or seemingly determining the dependency type, the system performs further structured parsing on the value fields to extract specific link parameters.

[0144] The engine parses complex connection string values ​​to identify information such as host and port.

[0145] The system uses regular expressions to break down configuration values. For example, for a standard database connection string jdbc:mysql: / / 127.0.0.1:3306 / dbname, the engine will parse out the host address 127.0.0.1, port number 3306, and database name dbname. This parsed metadata will serve as an important component of the edge attributes in the dependency topology graph.

[0146] Level 4: Service Naming Extraction. This level is mainly used to identify inter-service dependencies in a microservice architecture.

[0147] The engine analyzes configuration values ​​based on microservice naming conventions.

[0148] The system scans configuration values ​​and identifies strings that conform to a specific format. Based on the microservice naming conventions in the documentation, the system extracts strings that are lowercase letters and separated by hyphens (e.g., names in the style of order-service or user-center). If a configuration value matches this characteristic, the system identifies it as a possible internal network service name, thereby inferring the current application's dependency on that microservice.

[0149] In conjunction with the first aspect, the present invention provides a third specific implementation of the first aspect. Specifically, in step S30, the calculation step of the confidence weight includes:

[0150] Obtain the preset base weight values ​​of each level of rules in the multi-level semantic rule base, where the base weight value of the first level protocol feature matching is greater than the base weight value of the second level key name semantic matching;

[0151] The matching score is calculated by analyzing the rule hierarchy, the number of rules hit, and the completeness of the extracted fields during the statistical parsing process.

[0152] A weighted calculation is performed based on the basic weight value and the matching score, and the calculation result is normalized and mapped to a predetermined numerical range as the confidence attribute value of the application dependency data.

[0153] Because configuration file writing styles vary widely, the results of dependency inference will inevitably differ in terms of determinism (for example, `jdbc:mysql: / / ` is more deterministic than a simple `host` key name). To quantify this determinism, this embodiment introduces a confidence scoring algorithm, the specific calculation logic of which is as follows:

[0154] Step 1: Obtain the basic weight values

[0155] The system uses a pre-built multi-level semantic rule base to assign differentiated base weight coefficients to matching rules at different levels. Based on the technical disclosure document, the weight setting logic follows the principle of "the more significant the feature, the higher the weight," with the specific presets as follows:

[0156] First-level protocol layer identification rule: The base weight is set to 0.4. This is the highest weight because standard protocol headers (such as jdbc: / / , redis: / / ) can usually definitively indicate the dependency type.

[0157] Second-level key name semantic analysis rules: The base weight is set to 0.3. Key names containing keywords (such as redis, mysql) have high reference value, but may have semantic ambiguity.

[0158] Third-level value structure parsing rules: The basic weight is set to 0.2.

[0159] Fourth-level service name extraction rules: The basic weight is set to 0.1.

[0160] BenchmarkWeight: Set to 1.0 for subsequent normalization calculations.

[0161] Step 2: Statistics on matching metrics and calculation of matching degree. When parsing a specific configuration item, the engine will count the rules that the configuration item matches.

[0162] Matching degree: For each matching rule, calculate its matching degree.

[0163] If the rule is an exact match (e.g., the key name is exactly equal to spring.redis.host), the match score is recorded as 1.0;

[0164] If the rule is fuzzy matching (e.g., the key name contains "redis"), the system calculates the matching degree based on the string similarity algorithm (e.g., 0.8).

[0165] Step 3: Weighted Calculation and Normalization

[0166] The system uses a weighted summation formula to calculate the initial score and normalizes it to the [0,1] interval as the final confidence attribute value.

[0167] Calculation formula:

[0168]

[0169] Step 4: Specific Calculation Scenario Examples

[0170] Scenario A (High Confidence):

[0171] Configuration item: spring.datasource.url = jdbc:mysql: / / 127.0.0.1:3306 / db

[0172] Hit rate:

[0173] It hit the first-level protocol rule (jdbc:mysql: / / ), with a weight of 0.4 and a match degree of 1.0.

[0174] It also matched the second-level key name rule (including datasource), with a weight of 0.3 and a match degree of 1.0.

[0175] The third-level structure parsing rule (extracting the IP port) was hit, with a weight of 0.2 and a matching degree of 1.0.

[0176] Calculate: (0.4×1.0+0.3×1.0+0.2×1.0) / 1.0=0.9.

[0177] Result: The confidence level is 0.9, and the system determines that the dependency is reliable.

[0178] Scenario B (low to medium confidence level):

[0179] Configuration item: my.cache.ip = 10.0.0.5

[0180] Hit status: Protocol rules not hit.

[0181] The second-level key name rule was hit (assuming the cache is mapped to Redis), with a weight of 0.3 and a matching degree of 0.8 (fuzzy matching).

[0182] Calculate: (0.3 × 0.8) / 1.0 = 0.24

[0183] Result: The confidence level is 0.24, indicating that the system determines that the dependency exists, but it may be displayed as a dashed line or undertone in the topology diagram, prompting maintenance personnel to manually confirm it.

[0184] In conjunction with the first aspect, the present invention provides a fourth specific implementation of the first aspect. Specifically, in step S40, the step of constructing or updating the application-dependent topology graph data structure specifically includes:

[0185] Retrieve master node objects in the graph database that are uniquely indexed by the identifier of the application to be published;

[0186] A set of candidate edge objects to be written is constructed based on application dependency data, and their attributes are compared with those of existing associated edge objects in the graph database.

[0187] Based on the comparison results, graph database operation instructions are generated. These instructions include adding edges to create new dependencies, removing edges to remove invalid dependencies, and updating the confidence and version attributes of existing edge objects.

[0188] Traditional topology generation schemes typically employ a full deletion and reconstruction approach, which leads to the loss of historical data and inefficient performance. This embodiment utilizes an anchor-based incremental graph update strategy, leveraging the characteristics of graph databases (such as Neo4j) to perform precise operations only on changed dependencies. The specific steps are as follows:

[0189] Step 1: Retrieve Master Node Objects The system first links to the graph database to determine the "anchor point" for the current operation.

[0190] Index location: Using the application identifier to be published obtained in S10 (e.g., AppID:order-service and Environment:prod) as the unique index key, retrieve the corresponding master node object in the graph database.

[0191] Node creation: If the application is being released for the first time and the node does not exist in the graph database, the system will automatically create a new application node and write the application metadata.

[0192] Step 2: Construct a candidate edge and compare it with the existing edge system to calculate the difference between the parsing results output by S30 and the current status in the graph database.

[0193] Constructing the candidate set: The "application dependency data" generated by S30 is converted into a set of edge objects to be written. Each edge contains: target node identifier, dependency type (such as JDBC), confidence weight, and current release version number.

[0194] Get the existing set: Query all outgoing edges of the current master node object, that is, all the dependencies of the application in the old version.

[0195] Attribute comparison logic: The system uses the target node identifier as the key to perform difference and intersection operations on the two sets.

[0196] New set: Data that exists in the candidate set but not in the existing set.

[0197] Deletion set: Data that exists in the existing set but not in the candidate set.

[0198] Update set: Data that exists in both sets but has inconsistent attributes (such as confidence, port) or version number.

[0199] Step 3: Generate and execute graph operation instructions. Based on the comparison results, the system generates batch graph database operation instructions (such as Cypher statements) and executes them:

[0200] Create a new edge instruction that points to the new dependency:

[0201] For newly added centralized data, the system finds or creates a target node (TargetNode, such as a new Redis instance) and establishes a new DEPENDS_ON edge between the master node and the target node.

[0202] Example: The application adds a dependency on the Kafka cluster. The system draws a new connection in the topology and marks it with a confidence level of 0.9.

[0203] Remove the delete edge instruction that points to the invalid dependency:

[0204] For the data in the deletion set, the system identifies that these dependencies have been removed from the current version configuration.

[0205] Perform a deletion operation to remove the edge; or perform a logical deletion operation to mark the edge's state as DEPRECATED and record the end time for subsequent historical backtracking.

[0206] Update the confidence and version attributes of existing edge objects:

[0207] The update indicates that the dependency still exists, but the details may have changed or it may simply be a continuation of the previous version. Update the properties of the edge object.

[0208] Version attribute update: Update the edge's version attribute to the current release version identifier, proving that the dependency is still valid in the latest version.

[0209] Confidence attribute update: If the S30 inference algorithm calculates a new confidence level (for example, the confidence level increases from 0.6 to 0.8 due to the rule base upgrade), the confidence level value in the graph is updated in real time to make the topology view more accurate.

[0210] In conjunction with the first aspect, the present invention provides a fifth specific implementation of the first aspect, specifically including architectural compliance detection and release control steps:

[0211] After updating the application-dependent topology graph data structure in step S40, the graph traversal algorithm is executed starting from the master node object;

[0212] Check if there is a closed loop path pointing to the starting point in the traversal path, or if there is a target node link that is not in the preset access control list.

[0213] If a closed-loop path or a link not in the preset access control list is detected, an abnormal status flag is generated, and an interrupt signal is sent to the application release pipeline through the application programming interface to block the release process of the current version.

[0214] In traditional operations and maintenance processes, architectural violations (such as circular dependencies and broken layered architectures) are often only discovered after deployment when they cause failures. This embodiment intercepts risks during the release phase by performing static architecture auditing immediately after dependency topology generation. The specific steps are as follows:

[0215] Step 1: Graph traversal based on the master node

[0216] After the write operation to the graph database is completed in step S40 and the transaction is successfully committed, the compliance detection task is immediately started. The system starts from the graph database node (i.e., the master node object) corresponding to the application to be released and executes a depth-first search or breadth-first search algorithm. To balance performance and detection scope, the system usually sets a default traversal depth and focuses on detecting the application and its direct / indirect downstream dependency paths.

[0217] Step 2: Detecting circular dependencies

[0218] During graph traversal, the system maintains a current path stack. Each visited node is pushed onto the stack; each backtracking step pops it from the stack. If, while traversing a path, the next node encountered already exists in the current path stack (i.e., it points to the starting point or a previous node on the path), then a closed loop path exists.

[0219] Scenario example:

[0220] The application to be released is Order-Service.

[0221] Traversing the path reveals: Order-Service->User-Service->Payment-Service->Order-Service.

[0222] Conclusion: This is a deadlock risk structure A->B->C->A, which must be intercepted.

[0223] Step 3: Access Control List Validation

[0224] Preset rules: The system backend maintains an architecture access control list that defines allowed or prohibited dependencies.

[0225] Whitelist mode: A certain core database, Core_DB, is only allowed to be accessed by Core_Service.

[0226] Blacklist mode (layered governance): Applications marked as WebLayer (front-end layer) are prohibited from directly linking to databases or middleware marked as DataLayer (data layer).

[0227] Execution: Traverse all direct outgoing edges of the application. Check if the target node of each edge violates the access control list rules.

[0228] Scenario example:

[0229] The application to be released, Front-End-App (Web layer), is configured with a dependency to connect to MySQL-Primary (data layer).

[0230] Access control list rule definition: Web layer applications must call services through the API gateway; direct connection to the database is prohibited.

[0231] Conclusion: A target node link not in the preset access control list was detected, which was determined to be an architecture violation.

[0232] Step 4: Generate anomalies and block release

[0233] Once any of the above violations are detected, the system marks the current analysis task as abnormal and generates a verification report containing specific dependency conflict issues (such as a list of specific loop path nodes or details of the violating dependency edges). The system sends a feedback signal containing a failure status and blocking instructions to the application release pipeline that triggered this release via the application programming interface or message callback mechanism. This feedback signal instructs the application release pipeline to automatically pause or terminate subsequent deployment tasks for the current version, thereby preventing applications with architectural risks from going live. Simultaneously, the system pushes the specific dependency conflict issues to the user so that the user can make architectural adjustments or configuration corrections based on the report.

[0234] In conjunction with the first aspect, the present invention provides a sixth specific implementation of the first aspect, specifically, step S40 further includes the step of constructing a traceability index:

[0235] When generating application dependency data, record the key name, key value, and the hit rule ID of the original configuration item on which the dependency was based;

[0236] Construct a bidirectional mapping index table between dependency edge object IDs and original configuration item records;

[0237] In response to a received query request for a specific dependency edge object, the corresponding original configuration item record and rule description information are retrieved through the bidirectional mapping index table and returned for front-end rendering and display.

[0238] This embodiment describes the specific implementation of constructing the traceability index in step S40.

[0239] When generating dependency data, the system establishes a mapping between topology edge IDs and original configuration item metadata in memory or a database. The original configuration item metadata includes: the source path of the configuration file, the specific key name, the key-value fragment, and the rule ID to which the dependency is inferred.

[0240] When a user clicks on a dependency connection (such as the connection from AppA to Redis) in the front-end visualization interface, the system receives a query command and retrieves the basis for the connection's generation through the aforementioned index.

[0241] Results Display: The system displays a detailed view of the dependency in the sidebar of the interface, directly highlighting the original configuration fragment that caused the dependency, realizing the analysis from the topology view to the specific configuration details.

[0242] In conjunction with the first aspect, the present invention provides a seventh specific implementation of the first aspect, specifically including a topology history version backtracking step:

[0243] Maintain a topology version table in the relational database. The topology version table records snapshot data including pipeline identifier, release environment, creation time, and topology change set.

[0244] When S40 generates the latest application dependency topology graph data structure, the incremental part of this change is encapsulated as a snapshot of the topology change set in JSON format and written to the topology version table;

[0245] In response to a topology query request for a specific historical moment, the system first retrieves the nearest complete baseline version from the topology version table. Then, it retrieves snapshot data of all topology change sets from the baseline version to the historical moment in chronological order and replays the snapshot data of the topology change sets in memory to reconstruct the application-dependent topology graph data structure for that historical moment.

[0246] This embodiment describes the steps for backtracking historical topology versions. This embodiment employs a baseline + incremental storage and reconstruction strategy:

[0247] The system maintains a topology version table in a relational database (such as MySQL). The core fields of this table include: primary key ID, pipeline ID, application name, environment identifier, creation time, and a JSON snapshot of the topology change set. After each dependency analysis, the system does not store the full topology graph; instead, it serializes the incremental change set (i.e., newly added, modified, or deleted nodes and edges) calculated in this analysis into a snapshot data in JSON format and stores it in the aforementioned table. When a user needs to query the topology structure at a specific time point T, the system first searches the table for the closest complete topology version before time point T as the base version. It then reads all incremental change sets (JSON snapshots) from V_base to time point T in chronological order. These change sets are applied (replayed) sequentially in memory, thereby reconstructing the accurate topology graph at time point T within seconds, for the front end to render historical views.

[0248] In conjunction with the first aspect, the present invention provides an eighth specific implementation of the first aspect, specifically including a semantic rule base update step:

[0249] Based on the execution events of the application release pipeline, and listening for changes in the hash value of the rule file, the rule hot reloading process is triggered;

[0250] When a rule update is detected, load the latest rule set configuration and verify it;

[0251] After successful verification, the rule set in memory is updated by switching atomically, so as to achieve zero-downtime update while keeping the old rule set in service.

[0252] Specifically, in this embodiment, the system supports updating the identification rules without restarting the service:

[0253] Change monitoring: The system monitors the status of the rule file. The trigger condition can be a configuration change event that the pipeline has successfully executed, or a change in the MD5 hash value of the rule file itself.

[0254] Loading and Validation: Once an update to the rule definition is detected, the system automatically reads the new rule configuration file (YAML format) and performs syntax validation to ensure that the rule fields (such as rule type, matching mode, weight) are valid.

[0255] Atomic Switching: After successful verification, the system updates the rule engine object in memory using atomic reference switching. This operation ensures that, at the moment of switching, the currently executing analysis task continues to use the old rule set, while newly entered tasks immediately use the new rule set, achieving zero-downtime hot updates of the rule base.

[0256] The working principle of the application dependency topology generation method based on multi-source configuration parsing described in this invention is as follows:

[0257] As part of the DevOps ecosystem, the system first monitors configuration update events in the application deployment pipeline in real time. Upon capturing an event, the system automatically collects application configuration snapshots distributed across code repositories, configuration centers, or container platforms, and cleans and converts them into a standardized key-value pair set in a unified format using a multi-source configuration adapter. The system uses a global digest hash algorithm to perform fast fingerprint comparison on the configuration set. If a configuration change is detected, the system inputs the extracted incremental configuration data into the intelligent dependency inference engine. Based on a pre-built multi-level semantic rule library, this engine performs deep regular expression matching and semantic parsing on configuration items according to the priority order of "protocol features → key name semantics → link structure → service naming," thereby inferring the application's dependencies on external services or middleware, and calculating the confidence weight of the dependency relationship based on the hit rule level. Based on the parsed dependency data, the system links to a graph database and locks the master node object. Through an anchor-based incremental update strategy, it creates, removes, or updates the corresponding node and edge objects in the graph, constructing an application dependency topology structure that reflects the current production environment state. After the topology data is updated, the system immediately triggers an architecture compliance check, using a graph traversal algorithm to check for circular dependencies or illegal links. If the check passes, the system sends the topology data to the rendering engine to generate a visual view, supporting configuration for tracing the source and historical backtracking; if the check fails, an interrupt signal is sent to the pipeline to achieve automatic circuit breaker control for application deployment.

[0258] Example 2

[0259] Application Dependency Topology Generation System Architecture Based on Multi-Source Configuration Parsing

[0260] A second aspect of the present invention provides an application dependency topology generation system based on multi-source configuration parsing, the system comprising:

[0261] Memory is used to store computer program instructions;

[0262] A processor for executing computer program instructions to implement the application-dependent topology generation method based on multi-source configuration resolution according to the first aspect of the present invention; the system further includes:

[0263] The configuration acquisition unit is used to respond to configuration update events in the application release pipeline and obtain application configuration snapshot data and the corresponding release version identifier of the application to be released.

[0264] The standardized parsing unit is used to identify the configuration source protocol of the application configuration snapshot data based on its metadata, call the corresponding parsing logic to convert the data into a standardized key-value pair set in a unified format, and calculate the hash feature value to determine the increment;

[0265] The dependency feature analysis unit is used to perform regular expression matching and semantic mapping on a standardized key-value pair set when a configuration change is determined, using a pre-built multi-level semantic rule base to identify the target service endpoint address and middleware protocol features, generate application dependency data, and calculate confidence weights.

[0266] The topology data construction unit is used to parse application dependency data, map it to node objects and edge objects in the graph database, and perform write operations on the graph database to build or update the application dependency topology graph data structure.

[0267] The compliance control and interaction unit is used to perform architecture compliance checks based on the updated application dependency topology graph data structure. When an abnormal path is detected, it generates an interruption signal to block the release and generates visualization rendering instructions for front-end display based on user requests.

[0268] This embodiment provides a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, application-dependent topology generation is implemented. Logically, the system is divided into the following core processing units:

[0269] 1. Configuration Acquisition and Preprocessing Unit (corresponding to the embedded stage of the release process): This unit is designed as a built-in, automated atomic step in the DevOps release pipeline, realizing the synchronous triggering of configuration changes and dependency discovery.

[0270] Triggering mechanism: When a user submits a release request on the unified release platform, the system locks the version and configuration data of the application to be released. When the pipeline reaches the configuration update node, in response to the configuration file commit event, the system automatically captures the configuration snapshot corresponding to that version through the API interface.

[0271] The system generates a unique task ID, establishing an immutable binding relationship between each dependency analysis task and a specific release ID and code version number, ensuring the traceability of the generated topology data.

[0272] To improve processing efficiency, the system first calculates a global digest hash value (such as MD5) for the captured configuration snapshot. If the digest value is consistent with the previous version, the analysis is skipped; if they are inconsistent, a row-level difference comparison algorithm based on key name index is started to accurately extract incremental configuration items marked as added, modified, or deleted, and only these incremental data are input into subsequent processes.

[0273] 2. Intelligent Dependency Inference Engine (corresponding to the dependency inference stage): This engine uses multi-level cascading matching logic to convert unstructured configuration data into structured dependency metadata.

[0274] Level 1 (Protocol Feature Matching): Scan the standard link protocol header signatures in the configuration values ​​(such as jdbc:mysql: / / , redis: / / , kafka: / / ) to directly identify the dependency type.

[0275] Level 2 (key name semantic matching): If the protocol header is not matched, the key name is segmented and matched using regular expressions. For example, if the key name contains "redis.host", it is inferred to be a Redis dependency; if it contains "db.url", it is inferred to be a database dependency.

[0276] Level 3 (Link Structure Parsing): Performs a structured parsing algorithm on the configuration value string. For example, it extracts the target host IP, port number, and database instance name from the link string jdbc:mysql: / / 127.0.0.1:3306 / dbname using regular expressions.

[0277] Level 4 (Service Name Extraction): Based on the preset microservice naming conventions, identify strings that conform to the lowercase letter + hyphen format from the configuration values ​​and mark them as internal microservice dependencies.

[0278] Confidence-weighted calculation: The engine calculates the reliability weight of dependencies based on the hit rule hierarchy. The calculation logic is as follows:

[0279] Confidence level = min(1.0, Σ(rule base weight × matching completeness coefficient) / normalized baseline).

[0280] Protocol layer matching is assigned the highest weight (e.g., 0.4), while service name extraction is assigned the lowest weight (e.g., 0.1). This value is used to distinguish between deterministic and inferred dependencies in subsequent visualizations.

[0281] Furthermore, in this embodiment, to adapt to the rapid iteration of middleware types, the system implements zero-downtime rule hot loading:

[0282] The system starts a configuration monitoring daemon process that is independent of the main parsing process, and continuously monitors the storage path or configuration center of the rule definition file (YAML format).

[0283] When a change in the file fingerprint of a rule file is detected, the daemon loads the new rule set in a separate memory space and performs syntax parsing and logical conflict verification.

[0284] After successful verification, the atomic reference swapping mechanism or read-write lock mechanism of languages ​​such as Java / C++ is used to atomically point the memory pointer of the parsing engine to the newly compiled rule object instance. During this process, the old rule set continues to serve the request being processed, and is automatically garbage collected after the request is completed, thus achieving seamless hot updates.

[0285] In this implementation, it is necessary to explain how to transform the dependency metadata into a topology in a graph database.

[0286] The system uses a graph database (such as Neo4j) to store topology data. Applications and middleware are mapped to node objects, and dependencies are mapped to edge objects. Each node and edge is accompanied by a release version identifier as a system property.

[0287] When new version data is generated, the system performs the following steps:

[0288] Using the application node to be released as the core anchor point, retrieve the associated subgraphs of the old version from the graph database.

[0289] Iterate through the newly generated dependency list and compare it with the edges of the old version of the subgraph.

[0290] It identifies "newly added edges" (edges that exist in the new graph but not in the old graph), "deleted edges" (edges that exist in the old graph but not in the new graph), and "edges with changed attributes" (edges with changes in confidence or link address).

[0291] Batch execution of write operations enables incremental graph updates with linear complexity.

[0292] After the graph is updated, the graph traversal algorithm is immediately started to perform risk detection.

[0293] Depth-first search is used to detect whether there is a circular path in the graph that points to itself.

[0294] Check whether newly added dependency edges point to sensitive middleware nodes that are not in the default access control list.

[0295] If an anomaly is detected, the system sends an interrupt signal to the publishing pipeline via API and returns a specific risk report, thereby implementing publishing access control.

[0296] In this embodiment, to further address the difficulty of tracing historical versions, the system designs a storage model for snapshots and incremental logs:

[0297] Data persistence strategy:

[0298] The `topology version` table stores metadata and serialized JSON snapshots of each published topology change set.

[0299] Incremental log: Records every atomic change operation command for nodes and edges, along with a precise timestamp.

[0300] Memory replay reconstruction algorithm: When a user requests to view the historical topology at time point T:

[0301] The system retrieves the nearest preceding full baseline snapshot from time point T.

[0302] Extract all incremental change logs from the base time point to time point T.

[0303] These change instructions are executed sequentially in the server's memory buffer to dynamically reconstruct the precise topology at time point T.

[0304] Visualized source tracing interaction: The front-end view is rendered based on the D3.js force-directed algorithm. The system constructs a bidirectional index of dependency edge IDs and original configuration items. When a user clicks on a dependency connection, the front-end queries the index via API, highlighting the original configuration file fragment inferred from the dependency relationship, the description of the hit rule, and the confidence score, realizing drill-down analysis from macro architecture to micro code.

[0305] Example 3

[0306] According to embodiments of the present invention, the present invention also provides an electronic device, a readable storage medium, and a computer program product.

[0307] Figure 2A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present invention is shown. Electronic device 600 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic device 600 may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their links and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0308] like Figure 2 As shown, the electronic device 600 includes a computing unit 601, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. The RAM 603 may also store various programs and data required for the operation of the device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also linked to the bus 604.

[0309] Multiple components in electronic device 600 are linked to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of displays, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows electronic device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0310] The computing unit 601 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as a multi-UAV inspection task planning method. For example, in some embodiments, a multi-UAV inspection task planning method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the multi-UAV inspection task planning method described above can be performed. Alternatively, in other embodiments, computing unit 601 may be configured by any other suitable means (e.g., by means of firmware) to perform a multi-UAV inspection task planning method.

[0311] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0312] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0313] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical links based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0314] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0315] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0316] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0317] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this invention can be achieved, and this is not limited herein.

[0318] The application dependency topology generation method and system based on multi-source configuration parsing described in this invention, and other structures are described in the prior art.

[0319] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Therefore, any modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for generating an application dependency topology based on multi-source configuration resolution, characterized in that, include: S10, in response to the configuration update event of the application release pipeline, obtain the application configuration snapshot data of the application to be released and the corresponding release version identifier; S20, based on the metadata of the application configuration snapshot data, identify its configuration source protocol, call the parsing logic corresponding to the configuration source protocol, convert the application configuration snapshot data of different formats into a standardized key-value pair set in a unified format, and calculate the hash feature value of the standardized key-value pair set to determine whether there is a configuration change; S30, when it is determined that there is a configuration change, perform dependency feature extraction on the standardized key-value pair set, and use a pre-set multi-level semantic rule library to perform regular expression matching and semantic mapping on the extracted configuration key names and key values; The semantic mapping includes identifying the target service endpoint address, port number and middleware protocol features implicit in the configuration items, thereby generating application dependency data containing dependent parties, dependent parties and link attributes, and assigning corresponding confidence weights to the application dependency data according to the hierarchy of the matching rules. S40, parse the application dependency data and map it to node objects and edge objects in the graph database; Based on the node objects and edge objects, construct or update the application-dependent topology graph data structure, and send the updated topology data instructions to the rendering engine to generate the dependent topology view.

2. The application dependency topology generation method based on multi-source configuration resolution according to claim 1, characterized in that, In step S20, the specific steps for calculating the hash feature value of the standardized key-value pair set to determine whether there is a configuration change include: The current version of the standardized key-value pair set is serialized, and its global digest hash value is calculated; The global digest hash value of the previous version of the application to be released is retrieved and compared. If the comparison results are inconsistent, the key-value pair sets of the old and new versions are traversed, the differences are identified based on the key name index, the configuration items marked as added, modified or deleted are extracted, and an incremental configuration dataset is generated. The incremental configuration dataset is input into S30 as target data, and the dependency feature extraction is performed only on the configuration items that have changed.

3. The application dependency topology generation method based on multi-source configuration resolution of claim 1, wherein, In step S30, the specific steps for performing regular expression matching and semantic mapping using the multi-level semantic rule base adopt a cascaded matching logic executed according to priority. This logic includes: First-level protocol feature matching: Scan the value field of the standardized key-value pair set. If a preset standard link protocol header feature code is matched, determine the protocol type of the application dependency based on the protocol header feature code. Second-level key name semantic matching: If the first-level protocol feature matching fails, then perform word segmentation and keyword matching on the key name field of the standardized key-value pair set. If a predefined component identifier is matched, then infer the component type of the application dependency. Third-level link structure parsing: Perform string structure parsing on the value field, and extract the target service network address and port number parameters using regular expressions; Fourth-level service name extraction: Based on the preset microservice naming rules, extract strings that conform to the rules from the key name field or value field and identify them as the names of the microservices that are depended upon.

4. The application dependency topology generation method based on multi-source configuration resolution according to claim 1, characterized in that, In step S30, the calculation of the confidence weight includes: Obtain the preset base weight values ​​of each level of rules in the multi-level semantic rule base, wherein the base weight value of the first level protocol feature matching is greater than the base weight value of the second level key name semantic matching; The matching score is calculated by analyzing the rule hierarchy, the number of rules hit, and the completeness of the extracted fields during the statistical parsing process. A weighted calculation is performed based on the basic weight value and the matching score, and the calculation result is normalized and mapped to a predetermined numerical range as the confidence attribute value of the application dependency data.

5. The application dependency topology generation method based on multi-source configuration resolution according to claim 1, characterized in that, In step S40, the steps of constructing or updating the application-dependent topology graph data structure specifically include: Retrieve master node objects in the graph database that are uniquely indexed by the identifier of the application to be published; Based on the application dependency data, a set of candidate edge objects to be written is constructed, and their attributes are compared with those of the existing associated edge objects in the graph database. Based on the comparison results, graph database operation instructions are generated. These instructions include instructions to create new edges pointing to new dependencies, instructions to remove edges pointing to invalid dependencies, and instructions to update the confidence and version attributes of existing edge objects.

6. The application dependency topology generation method based on multi-source configuration resolution according to claim 1, characterized in that, It also includes architecture compliance testing and release control steps: After updating the application-dependent topology graph data structure in step S40, a graph traversal algorithm is executed starting from the master node object; Check if there is a closed loop path pointing to the starting point in the traversal path, or if there is a target node link that is not in the preset access control list. If the closed-loop path or a link not in the preset access control list is detected, an abnormal status identifier is generated, and an interrupt signal is sent to the application release pipeline through the application programming interface to block the release process of the current version.

7. The application dependency topology generation method based on multi-source configuration resolution according to claim 1, characterized in that, Step S40 also includes the step of constructing a source index: When generating the application dependency data, the key name, key value, and hit rule ID of the original configuration item on which the dependency was based are recorded; Construct a bidirectional mapping index table between the dependency edge object ID and the original configuration item record; In response to a received query request for a specific dependent edge object, the corresponding original configuration item record and rule description information are retrieved through the bidirectional mapping index table and returned for front-end rendering and display.

8. The application dependency topology generation method based on multi-source configuration resolution according to claim 1, characterized in that, It also includes the topology history version backtracking step: Maintain a topology version table in the relational database. The topology version table records snapshot data including pipeline identifier, release environment, creation time, and topology change set. When S40 generates the latest application dependency topology graph data structure, the incremental part of this change is encapsulated as a snapshot of the topology change set in JSON format and written to the topology version table; In response to a topology query request for a specific historical moment, the system first retrieves the most recent complete baseline version from the topology version table. Then, it retrieves snapshot data of all topology change sets from the baseline version to the historical moment in chronological order and replays the snapshot data of the topology change sets sequentially in memory to reconstruct the application-dependent topology graph data structure for that historical moment.

9. The application dependency topology generation method based on multi-source configuration resolution according to claim 1, characterized in that, It also includes the steps for updating the semantic rule base: Based on the execution events of the application release pipeline, and listening for changes in the hash value of the rule file, the rule hot reloading process is triggered; When a rule update is detected, load the latest rule set configuration and verify it; After successful verification, the rule set in memory is updated by switching atomically, so as to achieve zero-downtime update while keeping the old rule set in service.

10. An application-dependent topology generation system based on multi-source configuration resolution, characterized in that, The system includes: Memory is used to store computer program instructions; A processor for executing the computer program instructions to implement the application-dependent topology generation method based on multi-source configuration resolution as described in any one of claims 1 to 9; the system further includes: The configuration acquisition unit is used to respond to configuration update events in the application release pipeline and obtain application configuration snapshot data and the corresponding release version identifier of the application to be released. The standardized parsing unit is used to identify the configuration source protocol of the application configuration snapshot data based on its metadata, call the corresponding parsing logic to convert the data into a standardized key-value pair set in a unified format, and calculate the hash feature value to determine the increment; The dependency feature analysis unit is used to perform regular expression matching and semantic mapping on the standardized key-value pair set when a configuration change is determined, using a pre-built multi-level semantic rule base, to identify the target service endpoint address and middleware protocol features, generate application dependency data, and calculate confidence weights. The topology data construction unit is used to parse the application dependency data, map it to node objects and edge objects in the graph database, and perform write operations on the graph database to build or update the application dependency topology graph data structure. The compliance control and interaction unit is used to perform architecture compliance checks based on the updated application dependency topology graph data structure. When an abnormal path is detected, it generates an interruption signal to block the release and generates visualization rendering instructions for front-end display based on user requests.

Images