Computer network information service management method and system based on cloud technology

Abstract

The invention relates to the technical field of computer and machine learning, and discloses a computer network information service management method and system based on a cloud technology. The method comprises the following steps: acquiring indexes during service operation, and constructing a dynamic service dependency topological graph; extracting a multi-dimensional state vector, inputting the multi-dimensional state vector into the graph neural network model, and calculating an abnormal propagation influence score; reversely deriving a fault root cause in combination with a fault propagation attenuation rule; matching the standardized self-healing action template library, performing priority ranking according to the service key level, the influence range and the action risk, and generating an execution instruction; the self-healing operation is automatically executed through a cloud platform arrangement engine, and the effect is verified in a closed loop mode. The system comprises an index acquisition module, a topology construction module, a state coding module, an anomaly analysis module, a root cause derivation module, a strategy matching module, a decision and execution feedback module and the like. According to the system, accurate positioning and safe self-healing of micro-service faults are realized, and the availability and toughness of a cloud native system are remarkably improved.

Description

Cloud-based computer network information service management method and system Technical Field

[0001] This invention belongs to the field of computer and machine learning technology, specifically relating to a computer network information service management method and system based on cloud technology. Background Technology

[0002] With the widespread adoption of cloud computing, microservice architecture, and distributed systems in enterprise-level information services, cloud-based computer network information service management systems have become core infrastructure supporting high-concurrency and high-availability businesses. These systems significantly improve the elastic scalability and iteration efficiency of systems by breaking down monolithic applications into loosely coupled, independently deployable microservice units. However, the complex call dependencies between microservices also bring new operational challenges: anomalies in local services can rapidly propagate through the call chain, triggering cascading failures and leading to performance degradation or even paralysis of the entire information service system. Against this backdrop, achieving accurate perception of the microservice's operational status, rapid location of fault propagation paths, and autonomous repair of abnormal behavior have become key issues in ensuring the stability of cloud-native information services.

[0003] A cloud-based microservice anomaly detection and self-healing mechanism aims to identify potential or ongoing systemic risks and trigger targeted recovery strategies through multi-dimensional data fusion analysis of service call topology, time-series indicators, and log events. This mechanism must not only possess rapid response capabilities to known failure modes but also exhibit the adaptability and memory of a biological immune system when facing unknown, atypical, or complex anomalies, thereby maintaining the continuity and reliability of information services in a dynamically evolving cloud environment.

[0004] In existing technologies, mainstream APM (Application Performance Monitoring) tools and observability platforms mostly employ static threshold alerts or rule-based anomaly detection methods, whose core logic relies on preset performance boundaries (such as CPU utilization, response latency limits, etc.). These methods often exhibit lag and high false alarm rates when facing non-linear interactions between microservices, implicit dependencies, or low-frequency but highly damaging "gray rhino" type failures. More importantly, existing solutions generally lack the ability to causally infer the root cause of failures, making it difficult to distinguish between symptoms and causes, resulting in fragmented alert information and reliance on human experience for root cause localization. Furthermore, current self-healing mechanisms are mostly limited to the simple execution of predefined scripts (such as restarting instances or switching traffic), unable to form "immune memory" based on historical failure patterns, nor possessing the intelligent decision-making ability to proactively avoid or accelerate recovery in similar scenarios. Therefore, in highly dynamic and tightly coupled cloud-native information service environments, there is an urgent need for a novel anomaly detection and self-healing method that integrates adaptive learning, causal inference, and graph structure awareness to achieve early warning, accurate source tracing, and autonomous immunity against complex failures. Summary of the Invention

[0005] This invention provides a cloud-based computer network information service management method and system, aiming to solve the technical problems in microservice architectures where complex inter-service dependencies make it difficult to trace fault propagation chains, and where existing monitoring and application performance management tools rely solely on static threshold alarms, failing to provide early identification and root cause self-healing for unknown or complex fault modes. This invention constructs an intelligent management framework integrating multi-dimensional real-time operational metrics, dynamic service topology modeling, anomaly propagation path reasoning, and a closed-loop self-healing decision-making mechanism. This framework enables global awareness of the microservice system's operational status, precise fault root cause localization, and the generation and execution of automated repair strategies.

[0006] According to one aspect of the present invention, a computer network information service management method based on cloud technology is provided, comprising: collecting runtime indicator data of each service instance in a distributed microservice cluster, the runtime indicator data including request response latency, transaction throughput per second, error rate, resource utilization, and service call chain tracing identifier; constructing a dynamic service dependency topology graph based on the runtime indicator data, wherein each node represents a service instance, each directed edge represents a call relationship between services, and the directed edges are labeled with call frequency, average latency, and error propagation weight; performing time series feature extraction on each node and edge in the dynamic service dependency topology graph to generate a multidimensional state vector containing the deviation between historical baseline behavior patterns and current instantaneous state; inputting the multidimensional state vector into a pre-trained graph neural network model, the graph neural network model calculating an anomaly propagation influence score for each service instance by aggregating the state information of neighboring nodes; and, based on the anomaly propagation influence score, combining preset faults... The propagation attenuation rule is used to deduce the most likely set of fault origin nodes. For each candidate node in the set, a standardized self-healing action template library is matched, which includes six types of atomic operations: restarting instances, switching traffic, scaling up replicas, rolling back versions, isolating dependencies, and modifying configuration parameters. Based on the business criticality level, impact scope assessment value, and risk coefficient of the self-healing action of the candidate node, the matched self-healing actions are prioritized, and the highest priority self-healing action is selected to generate an execution instruction. The execution instruction is sent to the cloud platform infrastructure orchestration engine, which calls the container orchestration interface or virtual machine management interface to complete the automated intervention operation on the target service instance. After the self-healing action is executed, the changing trend of relevant service indicators is continuously monitored. If the indicators do not recover to the normal baseline range within a preset time window, a secondary diagnostic process is triggered, and the complete closed loop from abnormal propagation impact scoring to self-healing action selection is re-executed.

[0007] Preferably, the construction of the dynamic service dependency topology graph specifically includes: intercepting the entry and exit traffic of remote procedure calls between services through a distributed tracing proxy, parsing the context identifier in the protocol header, and establishing an association mapping between the caller and the callee; using a sliding time window mechanism to count the number of occurrences, average response time, and number of failures of each call relationship per unit time; calculating the call reliability index based on the number of occurrences and failures, and using this as the basis for updating the weights of directed edges; when a call relationship is not observed within three consecutive sliding windows, it is removed from the topology graph to maintain the timeliness of the topology structure.

[0008] Preferably, the process of generating the multidimensional state vector includes: normalizing the original indicator data of each service instance to eliminate dimensional differences; using the moving standard deviation algorithm to detect abrupt changes in indicator fluctuations and marking them as potential abnormal events; using the mean, variance, skewness, and kurtosis of the indicators over the past 30 sampling periods as historical baseline features; performing a difference operation between the indicator value of the current sampling period and the historical baseline features to obtain the deviation features; and concatenating the historical baseline features and the deviation features to form a multidimensional state vector of length 8.

[0009] Preferably, the graph neural network model is a multilayer perceptron structure based on a graph attention mechanism. Its input layer receives the multidimensional state vectors of each node, the hidden layer dynamically allocates the information contribution of neighboring nodes through attention weights, and the output layer generates an anomaly propagation influence score for each node. The formula for calculating the attention weights is:

[0010] in, For nodes Embedded representation, For learnable weight matrix, For the attention mechanism parameter vector, For nodes The set of first-order neighbors, This represents a vector concatenation operation; preferably, the fault propagation attenuation rule is defined as follows: if the abnormal propagation influence score of a node is lower than a preset threshold, then the score of its downstream nodes decays exponentially. The score is reduced; if a node has multiple upstream anomaly sources, its final score is the weighted sum of the scores of each upstream source, and the weight is determined by the error propagation weight of the corresponding edge; a node is only included in the candidate set of fault origin nodes when its score exceeds the global dynamic threshold.

[0011] Preferably, each type of atomic operation in the standardized self-healing action template library includes a precondition verification rule, an execution step sequence, an expected effect verification logic, and a rollback contingency plan; the precondition verification rule is used to determine whether the current system state meets the safety boundary for executing the action; the execution step sequence is a series of idempotent infrastructure operation instructions; the expected effect verification logic defines the indicator change pattern after successful execution; and the rollback contingency plan specifies the operation process for restoring the original state after verification failure.

[0012] Preferably, the business criticality level is divided into three levels: high, medium, and low, determined by the business tag field in the service registry metadata; the impact range assessment value is obtained by calculating the sum of the out-degree and in-degree of the service in the dynamic dependency topology graph, and weighted by combining its call chain depth; the risk coefficient of the self-healing action is calculated based on the success rate, average recovery time, and side effect incidence rate in historical execution records, with an initial value of 0.5, which is dynamically adjusted according to the results of each execution.

[0013] This invention provides a cloud-based computer network information service management system, comprising: a runtime metric acquisition module for collecting runtime metric data of each service instance in a distributed microservice cluster, the runtime metric data including request response latency, transaction throughput per second, error rate, resource utilization, and service call chain tracing identifiers; a dynamic topology construction module for constructing a dynamic service dependency topology graph based on the runtime metric data, wherein each node represents a service instance, each directed edge represents a call relationship between services, and the directed edges are labeled with call frequency, average latency, and error propagation weight; a state feature encoding module for extracting time-series features from each node and edge in the dynamic service dependency topology graph, generating a multi-dimensional state vector containing historical baseline behavior patterns and the deviation of the current instantaneous state; and an anomaly propagation analysis module for... The multidimensional state vector is input into a pre-trained graph neural network model to calculate the anomaly propagation influence score for each service instance; the root cause inference module is used to inversely derive the most likely set of fault origin nodes based on the anomaly propagation influence score and a preset fault propagation attenuation rule; the self-healing strategy matching module is used to match the corresponding standardized self-healing action template library for each candidate node in the set of fault origin nodes; the action priority decision module is used to prioritize the matched self-healing actions based on the business criticality level, impact scope assessment value, and risk coefficient of the self-healing action of the candidate node, and select the self-healing action with the highest priority to generate an execution instruction; the instruction execution and feedback module is used to send the execution instruction to the cloud platform infrastructure orchestration engine, and continuously monitor the changes in indicators after execution, triggering a secondary diagnostic process or confirming successful repair.

[0014] Preferably, the runtime metric acquisition module is deployed in the side-vehicle agent of each service instance. It injects monitoring probes through non-intrusive bytecode enhancement technology to capture method-level call performance data in real time and reports it to the central metric aggregation node through a unified telemetry protocol. The central metric aggregation node uses a columnar storage engine to compress and index the metric data, supporting millisecond-level time range queries.

[0015] Preferably, the dynamic topology construction module maintains a long connection with the service registry center, listens for service instance online, offline, and health status change events, and synchronously updates the node status in the topology graph; at the same time, it periodically polls the call link tracing database to extract all call relationship records within the last 5 minutes to correct the weight parameters of the topology edges.

[0016] Preferably, the graph neural network model used by the anomaly propagation analysis module is supervised learning using a labeled historical fault dataset during the offline training phase, with the labels being manually annotated real fault root cause nodes; the cross-entropy loss function is used during training, and an L2 regularization term is introduced to prevent overfitting; after the model training is completed, it is solidified into a read-only inference model and deployed on a dedicated inference server cluster.

[0017] Preferably, the instruction execution and feedback module communicates with the cloud platform infrastructure orchestration engine through a secure message queue with two-way authentication to ensure the integrity and non-repudiation of instruction transmission; after each self-healing action is executed, the system automatically generates an audit log containing the execution time, operation type, target instance, comparison of before and after indicators, and final status, and stores it in the blockchain evidence storage system.

[0018] Compared with the prior art, the beneficial effects of the present invention are as follows: The present invention abandons the traditional passive alarm mode based on static thresholds, and for the first time combines dynamic service topology modeling, graph neural network-driven anomaly propagation analysis and standardized self-healing action library to build a microservice governance system with proactive perception, intelligent reasoning and closed-loop execution capabilities.

[0019] By building and updating service dependency topology in real time, the complex call relationships between services are accurately depicted; graph neural networks are used to model multidimensional state vectors in both space and time, effectively identifying early fault signals hidden under normal index fluctuations; the root cause is traced in reverse based on fault propagation attenuation rules, significantly improving the positioning accuracy and speed; and the safety and effectiveness of self-healing operations are ensured by introducing a three-dimensional decision-making mechanism that considers business criticality level, scope of impact, and action risk.

[0020] Experiments show that in a typical e-commerce scenario with 200 microservice instances, this invention can reduce the average fault location time from 15 minutes to 42 seconds, achieve a self-healing success rate of up to 93.7%, effectively block 89% of cascading fault propagation, and significantly improve the availability and resilience of cloud-native applications. Attached Figure Description

[0021] Figure 1 is a schematic diagram of the overall technical solution architecture of the present invention; Figure 2 is a schematic diagram of the core principle framework of the present invention that integrates dynamic service topology modeling and graph neural network-driven anomaly propagation analysis; Figure 3 is a logical flow framework diagram of runtime indicator collection, dynamic topology construction and state feature encoding in the present invention; Figure 4 is a logical framework diagram of root cause deduction based on anomaly propagation influence scoring and fault propagation attenuation rules in the present invention; Figure 5 is a closed-loop self-healing control framework diagram of self-healing strategy matching, action priority decision and instruction execution feedback in the present invention; Figure 6 is a schematic diagram of the multi-level interaction relationship and data flow of the terminal-side vehicle agent, central indicator aggregation node and cloud platform infrastructure orchestration engine in the present invention. Detailed Implementation

[0022] Please refer to Figures 1 to 6. This invention provides a computer network information service management method and system based on cloud technology. It aims to solve the technical problems in microservice architectures where complex inter-service dependencies make it difficult to trace fault propagation chains, and where existing monitoring and application performance management tools rely solely on static threshold alarms, failing to provide early identification and root cause self-healing for unknown or complex fault modes. This method constructs an intelligent management framework integrating multi-dimensional real-time operational metrics, dynamic service topology modeling, anomaly propagation path reasoning, and a closed-loop self-healing decision-making mechanism. This framework enables global perception of the microservice system's operational status, precise fault root cause localization, and the generation and execution of automated repair strategies.

[0023] The cloud-based computer network information service management method includes the following steps: S1, collecting runtime indicator data of each service instance in a distributed microservice cluster, including request response latency, transaction throughput per second, error rate, resource utilization, and service call chain tracing identifier; S2, constructing a dynamic service dependency topology graph based on the runtime indicator data, where each node represents a service instance, each directed edge represents the call relationship between services, and the call frequency, average latency, and error propagation weight are marked on the directed edges; S3, extracting time series features from each node and edge in the dynamic service dependency topology graph to generate a multidimensional state vector containing historical baseline behavior patterns and current instantaneous state deviations; S4, inputting the multidimensional state vector into a pre-trained graph neural network model, which calculates the anomaly propagation influence score for each service instance by aggregating the state information of neighboring nodes; S5, based on the anomaly propagation influence score, combined with a preset fault propagation decay... S6. Subtract rules and reverse-engineer the set of most likely fault origin nodes; S7. For each candidate node in the set of fault origin nodes, match its corresponding standardized self-healing action template library, which includes six types of atomic operations: restarting instances, switching traffic, scaling up replicas, rolling back versions, isolating dependencies, and modifying configuration parameters; S8. Based on the business criticality level, impact scope assessment value, and risk coefficient of the self-healing action of the candidate node, prioritize the matched self-healing actions and select the self-healing action with the highest priority to generate an execution instruction; S9. Send the execution instruction to the cloud platform infrastructure orchestration engine, which calls the container orchestration interface or virtual machine management interface to complete the automated intervention operation on the target service instance; S10. After executing the self-healing action, continuously monitor the changing trend of relevant service indicators. If the indicators do not recover to the normal baseline range within a preset time window, trigger the secondary diagnosis process and re-execute the complete closed loop from abnormal propagation impact scoring to self-healing action selection.

[0024] In step S1, runtime metric data collection is accomplished through a side-vehicle agent deployed on each service instance. The side-vehicle agent injects monitoring probes using non-intrusive bytecode enhancement technology to capture method-level call performance data in real time, including but not limited to the start timestamp of the entry method, the end timestamp of the exit method, exception throwing events, stack traces, thread context identifiers, memory allocation rate, CPU utilization, and network I / O throughput. All raw data is temporarily stored in a local buffer and then encapsulated into structured message bodies according to a unified telemetry protocol, reported to the central metric aggregation node once per second at a fixed sampling frequency. The central metric aggregation node uses a columnar storage engine to compress and index the metric data, supporting millisecond-level queries based on multi-dimensional conditions such as service name, instance identifier, time range, and metric type. Service call chain tracing identifiers are transparently transmitted between services through a distributed context propagation mechanism, ensuring that the entire chain of calls triggered by the same user request can be uniquely associated.

[0025] In step S2, the construction of the dynamic service dependency topology relies on the distributed tracing agent's interception of ingress and egress traffic for remote procedure calls between services. The agent parses the context identifier in the protocol header, extracts metadata such as the caller's service name, the callee's service name, the interface path, the protocol type, and the call result status code, and establishes an association mapping between the caller and the callee. The system maintains a sliding time window with a length of 30 seconds, sliding once every 10 seconds. Within each window, the number of occurrences, total response time, and number of failures for each call relationship are counted. The call frequency is defined as the number of occurrences divided by the window length, the average latency is defined as the total response time divided by the number of occurrences, and the error propagation weight is defined as the number of failures divided by the number of occurrences. The formula for calculating the call reliability index is: To invoke the reliability index, For error propagation weights, This represents the normalized average latency value. Specifically, the normalized average latency is the current average latency divided by the historical 99th percentile latency of the call relationship. When a call relationship is not observed within three consecutive sliding windows, the system determines that the call relationship is invalid and removes it from the topology graph. The topology graph is stored in an in-memory database as an adjacency list, supporting real-time CRUD operations.

[0026] In step S3, the multidimensional state vector generation process first normalizes the raw indicator data of each service instance. Normalization uses the Z-score method, which involves subtracting the mean of the past seven days for the same period from the current value and then dividing by the standard deviation to eliminate dimensional differences and adapt to periodic fluctuations. Subsequently, a moving standard deviation algorithm is used to detect abrupt changes in indicator fluctuations: using five sampling points as a window, the standard deviation within the window is calculated. If the difference between the standard deviation of the current point and the previous point exceeds a preset threshold of 0.5, it is marked as a potential abnormal event. Historical baseline features include the indicator mean, variance, skewness, and kurtosis over the past 30 sampling periods, reflecting central trend, dispersion, distribution asymmetry, and tail thickness, respectively. The current instantaneous state deviation is obtained by differencing the indicator value of the current sampling period with the historical baseline features, including the difference between the current value and the mean, and the difference between the current variance and the historical variance. Finally, the four historical baseline features and four deviation features are concatenated to form a multidimensional state vector of length 8. This vector serves as the node input feature for the graph neural network model.

[0027] In step S4, the graph neural network model is a multilayer perceptron structure based on a graph attention mechanism. The input layer receives the multidimensional state vectors of each node, which are mapped to a low-dimensional embedding representation through a fully connected layer. The hidden layer dynamically allocates the information contribution of neighboring nodes through attention weights. The formula for calculating the attention weights is:

[0028] in, For nodes Embedded representation, For learnable weight matrix, For the attention mechanism parameter vector, For nodes The set of first-order neighbors, This represents a vector concatenation operation. Node The new embedding is represented as a weighted sum of its own embedding and the embeddings of its neighbors, where the weight is . After two graph attention layers, the output layer generates an anomaly propagation influence score for each node using a sigmoid activation function, with a value ranging from 0 to 1. The higher the score, the more likely the node is to be the source or key amplifier of anomaly propagation.

[0029] In step S5, the fault propagation attenuation rule is defined as follows: if the abnormal propagation influence score of a node is lower than a preset threshold of 0.3, then the score of its downstream nodes is reduced by an exponential decay factor. The score is progressively reduced. If a node has multiple upstream anomaly sources, its final score is the weighted sum of the scores from each upstream source, with the weights determined by the error propagation weights of the corresponding edges. A node is only included in the candidate set of fault origin nodes if its score exceeds the global dynamic threshold. The global dynamic threshold is adaptively adjusted based on the overall system load level: when the average error rate of the entire cluster is below 0.5%, the threshold is set to 0.4; when the error rate is between 0.5% and 2%, the threshold drops to 0.3; and when the error rate exceeds 2%, the threshold further drops to 0.25. The root cause derivation process starts from the node with the highest score and traces upstream along the reverse call path until the score falls below the decayed threshold or reaches the entry service. All upstream nodes that meet the conditions constitute the set of fault origin nodes.

[0030] In step S6, the standardized self-healing action template library is stored in the configuration center. Each type of atomic operation includes precondition verification rules, execution step sequence, expected effect verification logic, and rollback contingency plan. Precondition verification rules determine whether the current system state meets the security boundaries for executing the action. For example, before restarting an instance, it must be confirmed that the instance's replica count is greater than 1 and the number of health check failures exceeds three; before switching traffic, it must be confirmed that the standby instance is ready and version compatible; before scaling up replicas, it must be confirmed that the resource quota has not reached its limit. The execution step sequence is a series of idempotent infrastructure operation instructions, such as calling the Kubernetes API to delete Pods, adjust Service weights, and update Deployment replica counts. The expected effect verification logic defines the indicator change pattern after successful execution. For example, after restarting, the error rate should decrease by more than 50% within 30 seconds; after scaling up, the transaction processing volume per second should increase and latency should decrease. The rollback contingency plan specifies the operation process for restoring the original state after verification failure, such as recreating the deleted Pod, restoring the original Service weight, and scaling down to the original replica count.

[0031] In step S7, business criticality levels are divided into high, medium, and low, determined by the business tag field in the service registry metadata. High-criticality services include payment gateway, user authentication center, and order core service; medium-criticality services include product query, shopping cart, and recommendation engine; low-criticality services include log collection, notification push, and data analysis. The impact scope assessment value is calculated by summing the out-degree and in-degree of the service in the dynamic dependency topology graph, combined with its call chain depth. Call chain depth is defined as the distance to the farthest node reachable from the service. Impact scope assessment value = out-degree weighted value × 0.4 + in-degree weighted value × 0.4 + depth weighted value × 0.2, with all weighted values ​​normalized to the range of 0 to 1. The risk coefficient of the self-healing action is calculated based on the success rate, average recovery time, and side effect incidence rate in historical execution records, with an initial value set to 0.5. After each execution, the risk coefficient is updated using the following formula: New Risk Coefficient = Old Risk Coefficient × 0.9 + Failure Flag × 0.1, where a failure flag of 1 indicates that the indicator has not recovered or has caused a new fault after execution, otherwise it is 0. The priority score is calculated as follows: Priority Score = Business Criticality Level Weight × 0.5 + Impact Scope Assessment Value × 0.3 - Risk Coefficient × 0.2. The system selects the self-healing action with the highest priority score to generate the execution instruction.

[0032] In step S8, the execution command is sent to the cloud platform infrastructure orchestration engine via a secure message queue. The message queue uses two-way authentication and message signing to ensure the command's origin is trustworthy and its content is not tampered with. After parsing the command, the infrastructure orchestration engine calls the corresponding container orchestration interface or virtual machine management interface to execute the operation. For containerized services, the Kubernetes API is called to perform Pod lifecycle management; for services deployed on virtual machines, the OpenStack Nova API is called to perform instance start / stop or snapshot rollback. All operations are logged, including operation time, operation type, target resource identifier, operation parameters, and return code.

[0033] In step S9, after the self-healing action is executed, the system initiates a 60-second monitoring window. During this window, runtime metric data of relevant service instances is continuously collected and compared with the baseline before execution. If the error rate decreases by more than 60%, latency recovers to within 1.2 times the historical average, and the transaction processing volume per second recovers to more than 60% of the pre-execution level, the repair is considered successful, and the current diagnostic process is closed. If any metric fails to meet the criteria, a secondary diagnostic process is triggered, re-executing steps S4 to S7, but excluding the already executed self-healing action to avoid repeating ineffective operations. If all three attempts fail, a manual alert is issued, along with the complete diagnostic path and execution log.

[0034] The cloud-based computer network information service management system includes a runtime indicator acquisition module, a dynamic topology construction module, a state feature encoding module, an anomaly propagation analysis module, a root cause inference module, a self-healing strategy matching module, an action priority decision module, and an instruction execution and feedback module.

[0035] The runtime metric collection module is deployed in the side-vehicle agent of each service instance. It injects monitoring probes through non-intrusive bytecode enhancement technology to capture method-level call performance data in real time and reports it to the central metric aggregation node via a unified telemetry protocol. The central metric aggregation node uses a columnar storage engine to compress and index the metric data, supporting millisecond-level time range queries.

[0036] The dynamic topology building module maintains a persistent connection with the service registry, monitors service instance online / offline events and health status changes, and synchronously updates the node status in the topology graph. Simultaneously, it periodically polls the call tracing database to extract all call relationship records from the last 5 minutes, which are used to adjust the weight parameters of the topology edges.

[0037] The state feature encoding module is responsible for extracting time-series features from each node and edge in the dynamic service dependency topology graph, generating a multi-dimensional state vector that includes the deviation between historical baseline behavior patterns and the current instantaneous state. This module incorporates a sliding window buffer, a normalization processor, a mutation point detector, and a feature concatenation unit.

[0038] The graph neural network model used in the anomaly propagation analysis module undergoes supervised learning using a labeled historical fault dataset during the offline training phase. The labels are manually annotated real fault root cause nodes. The training process employs a cross-entropy loss function and incorporates an L2 regularization term to prevent overfitting. After training, the model is solidified as a read-only inference model and deployed on a dedicated inference server cluster.

[0039] The root cause derivation module, based on the anomaly propagation influence score and combined with preset fault propagation attenuation rules, reverse-engineers the set of most likely fault origin nodes. This module maintains a global dynamic threshold adjuster and an upstream tracing path cache.

[0040] The self-healing strategy matching module matches each candidate node in the set of fault origin nodes with its corresponding standardized self-healing action template library. The template library is stored in the high-availability configuration center and supports hot updates and version control.

[0041] The action priority decision module prioritizes the matched self-healing actions based on the business criticality level, impact scope assessment value, and risk coefficient of the candidate nodes, and selects the highest priority self-healing action to generate the execution instruction. This module has a built-in dynamic risk coefficient update engine and priority calculation unit.

[0042] The instruction execution and feedback module communicates with the cloud platform infrastructure orchestration engine via a secure message queue with two-way authentication to ensure the integrity and non-repudiation of instruction transmission. After each self-healing action is executed, the system automatically generates an audit log containing the execution time, operation type, target instance, before-and-after metric comparison, and final status, and stores it in the blockchain evidence storage system.

[0043] This embodiment, through the above-described method and system, achieves early identification, accurate location, and automatic repair of complex faults in microservice architecture, significantly improving the availability and resilience of cloud-native applications.

Claims

1. A computer network information service management method based on cloud technology, characterized in that, include: Collect runtime metric data for each service instance in a distributed microservice cluster; Based on the runtime metric data, a dynamic service dependency topology graph is constructed, where each node represents a service instance, and each directed edge represents the call relationship between services. The directed edges are labeled with call frequency, average latency, and error propagation weight. Time-series features are extracted from each node and edge in the dynamic service dependency topology graph to generate a multi-dimensional state vector containing historical baseline behavior patterns and the deviation from the current instantaneous state. This multi-dimensional state vector is input into a pre-trained graph neural network model, which calculates the anomaly propagation influence score for each service instance by aggregating the state information of neighboring nodes. Based on the anomaly propagation influence score and a preset fault propagation attenuation rule, the most likely set of fault origin nodes is derived in reverse. For each candidate node in the set of fault origin nodes, a corresponding standardized self-healing action template library is matched; based on the business criticality level, impact scope assessment value, and risk coefficient of the self-healing action of the candidate node, the matched self-healing actions are prioritized, and the self-healing action with the highest priority is selected to generate an execution instruction; the execution instruction is sent to the cloud platform infrastructure orchestration engine, which calls the container orchestration interface or virtual machine management interface to complete the automated intervention operation on the target service instance.

2. The computer network information service management method based on cloud technology according to claim 1, characterized in that, After the self-healing action is performed, the changing trend of relevant service indicators is continuously monitored. If the indicators do not recover to the normal baseline range within the preset time window, the secondary diagnosis process is triggered, and the complete closed loop from the abnormal transmission influence score to the selection of self-healing action is re-executed.

3. The computer network information service management method based on cloud technology according to claim 1, characterized in that, Based on the runtime metric data, a dynamic service dependency topology graph is constructed, including: intercepting the entry and exit traffic of remote procedure calls between services through a distributed tracing proxy, parsing the context identifier in the protocol header, and establishing an association mapping between the caller and the callee; using a sliding time window mechanism to count the number of occurrences, average response time, and number of failures of each call relationship per unit time; calculating the call reliability index based on the number of occurrences and failures, and using this as the basis for updating the weights of directed edges; when a call relationship is not observed within three consecutive sliding windows, it is removed from the topology graph to maintain the timeliness of the topology structure.

4. The computer network information service management method based on cloud technology according to claim 3, characterized in that, Time-series features are extracted from each node and edge in the dynamic service dependency topology graph to generate a multi-dimensional state vector containing historical baseline behavior patterns and current instantaneous state deviations. This includes: normalizing the original indicator data of each service instance to eliminate dimensional differences; using the moving standard deviation algorithm to detect indicator fluctuations and abrupt changes, and marking them as potential abnormal events; using the indicator mean, variance, skewness, and kurtosis over the past 30 sampling periods as historical baseline features; performing a difference operation between the indicator value of the current sampling period and the historical baseline features to obtain deviation features; and concatenating the historical baseline features and the deviation features to form a multi-dimensional state vector of length 8.

5. The computer network information service management method based on cloud technology according to claim 4, characterized in that, The multidimensional state vector is input into a pre-trained graph neural network model to calculate the anomaly propagation influence score for each service instance. This includes: inputting the multidimensional state vector into a graph neural network model with a multilayer perceptron structure based on a graph attention mechanism; and dynamically allocating the information contribution of neighboring nodes through attention weights, the formula for calculating the attention weights being: in, For nodes Embedded representation, For learnable weight matrix, For the attention mechanism parameter vector, For nodes The set of first-order neighbors, This represents a vector concatenation operation; by aggregating the state information of neighboring nodes, it generates an anomaly propagation influence score for each service instance.

6. The computer network information service management method based on cloud technology according to claim 5, characterized in that, Based on the abnormal propagation influence score and combined with the preset fault propagation attenuation rule, the most likely set of fault origin nodes is derived in reverse, including: if the abnormal propagation influence score of a node is lower than a preset threshold, the scores of its downstream nodes are reduced by an exponential decay factor. The score is reduced; if a node has multiple upstream anomaly sources, its final score is the weighted sum of the scores of each upstream source, and the weight is determined by the error propagation weight of the corresponding edge; only when the node score exceeds the global dynamic threshold is it included in the candidate set of fault origin nodes; starting from the node with the highest score, trace upstream along the reverse call path until the score is lower than the decayed threshold or the entry service is reached, thus forming the set of fault origin nodes.

7. The computer network information service management method based on cloud technology according to claim 6, characterized in that, For each candidate node in the set of fault origin nodes, a corresponding standardized self-healing action template library is matched, including: each type of atomic operation in the standardized self-healing action template library contains precondition verification rules, execution step sequence, expected effect verification logic, and rollback contingency plan; the precondition verification rules are used to determine whether the current system state meets the safety boundary for executing the action; the execution step sequence is a series of idempotent infrastructure operation instructions; the expected effect verification logic defines the indicator change pattern after successful execution; and the rollback contingency plan specifies the operation process for restoring the original state after verification failure.

8. The computer network information service management method based on cloud technology according to claim 7, characterized in that, Based on the business criticality level, impact scope assessment value, and risk coefficient of the self-healing action of the candidate nodes, the matched self-healing actions are prioritized, and the highest priority self-healing action is selected to generate an execution instruction. This includes: the business criticality level is divided into high, medium, and low levels, determined by the business tag field in the service registry metadata; the impact scope assessment value is calculated by summing the out-degree and in-degree of the service in the dynamic dependency topology graph, combined with a weighted average of its call chain depth; the risk coefficient of the self-healing action is calculated based on the success rate, average recovery time, and side effect incidence rate in historical execution records, with an initial value of 0.5, dynamically adjusted according to each execution result; and a priority score is calculated based on the business criticality level weight, impact scope assessment value, and risk coefficient, with the highest score selected to generate the execution instruction.

9. The computer network information service management method based on cloud technology according to claim 8, characterized in that, After executing the self-healing action, continuously monitor the changing trends of relevant service indicators. If the indicators do not recover to the normal baseline range within the preset time window, trigger a secondary diagnostic process, including: starting a 60-second monitoring window and continuously collecting runtime indicator data of relevant service instances; if the error rate decreases by more than 60%, the latency recovers to within 1.2 times the historical average, and the transaction processing volume per second recovers to more than 60% of the level before execution, the repair is considered successful; if any indicator fails to meet the standard, trigger a secondary diagnostic process, re-execute the complete closed loop from abnormal propagation impact scoring to self-healing action selection, and exclude self-healing actions that have already been executed.

10. A computer network information service management system based on cloud technology, characterized in that, include: The runtime metrics collection module is used to collect runtime metrics data of each service instance in the distributed microservice cluster. The runtime metrics data includes request response latency, transaction volume per second, error rate, resource utilization, and service call chain tracing identifier. The dynamic topology construction module is used to construct a dynamic service dependency topology graph based on the runtime metric data, where each node represents a service instance, each directed edge represents the call relationship between services, and the call frequency, average latency and error propagation weight are marked on the directed edges. The state feature encoding module is used to extract time series features from each node and edge in the dynamic service dependency topology graph to generate a multi-dimensional state vector containing historical baseline behavior patterns and current instantaneous state deviations; the anomaly propagation analysis module is used to input the multi-dimensional state vector into a pre-trained graph neural network model to calculate the anomaly propagation influence score for each service instance. The root cause deduction module is used to deduce the most likely set of fault origin nodes in reverse based on the abnormal propagation influence score and the preset fault propagation attenuation rules. The self-healing strategy matching module is used to match the corresponding standardized self-healing action template library for each candidate node in the set of fault origin nodes. The action priority decision module is used to prioritize the matched self-healing actions based on the business criticality level, impact scope assessment value, and risk coefficient of the candidate nodes, and select the self-healing action with the highest priority to generate an execution instruction; the instruction execution and feedback module is used to send the execution instruction to the cloud platform infrastructure orchestration engine, and continuously monitor the changes in indicators after execution, triggering a secondary diagnostic process or confirming the repair.

Images