A rollback method, apparatus, device, and medium

Abstract

This application relates to the field of computer technology, and in particular to a rollback method, apparatus, device, and medium. The method includes: acquiring metadata of a new deployment event; acquiring a communication link topology diagram between services; determining the abnormal characteristics and causes of abnormal links based on information about the services involved in the new deployment event in the metadata, the communication link topology diagram, and real-time link performance data; determining a rollback strategy based on the abnormal characteristics and causes; generating a rollback operation sequence corresponding to the target affected links using the link topology diagram according to the rollback strategy; and executing the corresponding rollback operation based on the component corresponding to each rollback operation in the rollback operation sequence. This method enables rapid and efficient rollback application to minimize downtime and impact.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a rollback method, apparatus, device, and medium. Background Technology

[0002] With the widespread adoption of cloud computing, containerization, and microservice architectures, modern enterprise applications commonly employ distributed microservice architectures to build systems. This architecture improves system scalability, resilience, and deployment efficiency by breaking down a monolithic application into multiple independent microservices, each focusing on a specific business function. However, this architecture also brings new challenges: application deployment, maintenance, and fault recovery become more complex.

[0003] In highly interconnected and rapidly changing production environments, stable application operation and rapid fault recovery are critical to maintaining business continuity. Application rollback, as a necessary mechanism to address deployment failures or software defects, aims to restore the system state to a previously known stable and working version. In chain-level distributed application scenarios, because applications typically consist of multiple interdependent services or modules, forming complex call chains, a local failure can quickly propagate along the chain, severely impacting the entire business process. Mean Time Between Failures (MTBF) is an important metric for measuring system reliability.

[0004] In the rapidly iterating development of modern software, how to achieve fast and efficient application rollback to minimize downtime and impact has become a core technical challenge for distributed system management. Summary of the Invention

[0005] The purpose of this application is to provide a rollback method, apparatus, device, and medium that can quickly and efficiently apply rollback to minimize downtime and impact of failures.

[0006] Firstly, a rollback method is provided, comprising: acquiring metadata of a new deployment event; acquiring a communication link topology diagram between services; determining the abnormal characteristics and causes of abnormal links based on the information of the services involved in the new deployment event in the metadata, the communication link topology diagram, and real-time link performance data; determining a rollback strategy based on the abnormal characteristics and causes; generating a rollback operation sequence using the link topology diagram according to the rollback strategy; and executing a corresponding rollback operation based on the component corresponding to each rollback operation in the rollback operation sequence.

[0007] In a preferred embodiment, this application can be further configured to: determine the abnormal characteristics and causes of abnormal links based on the information of services involved in the new deployment event, the communication link topology diagram, and real-time link performance data in the metadata, including: determining at least one affected link based on the information of services involved in the new deployment event and the communication link topology diagram in the metadata; obtaining real-time link performance data, the real-time link performance data including key performance indicators of at least one affected link before and after deployment; evaluating the target affected link based on the real-time link performance data to obtain link abnormal information of the target affected link; the link abnormal information includes: abnormal characteristics, whether the target affected link is an abnormal link, and the cause of abnormality when the target affected link is an abnormal link; the target affected link is any one of the at least one affected link; and determining the abnormal characteristics and causes of abnormal links based on the link abnormal information.

[0008] In a preferred embodiment, this application can be further configured to: evaluate the target affected link based on real-time link performance data to obtain link anomaly information of the target affected link, including: determining the evaluation values ​​of multiple key performance indicators of the target affected link based on the performance data of the target affected link in the real-time link performance data; determining whether the target key performance indicator is an abnormal feature based on the evaluation values ​​of the target key performance indicators of the target affected link, wherein the target key performance indicator is any one of multiple key performance indicators; determining the link evaluation value of the target affected link based on the evaluation values ​​of the multiple key performance indicators of the target affected link; determining whether the target affected link is an abnormal link based on the link evaluation value of the target affected link and the corresponding preset link threshold; and determining the anomaly information of the target affected link if the target affected link is an abnormal link.

[0009] In a preferred embodiment, this application can be further configured to: obtain a communication link topology diagram between services, including: continuously obtaining service instance information of all registered services; performing real-time parsing of network traffic logs in the distributed system to obtain the actual communication mode between services, wherein the actual communication mode represents the call information and communication information between services; obtaining complete call chain data between services; and constructing a communication link topology diagram between services based on the service instance information, the actual communication mode between services, and the complete call chain data.

[0010] In a preferred embodiment, this application can be further configured to: generate a rollback operation sequence based on a link topology diagram according to a rollback strategy, including: generating an initial rollback operation sequence corresponding to the target affected link based on the link topology diagram according to the rollback strategy; detecting whether there is an operation conflict in the initial rollback operation sequence; and optimizing the initial rollback operation sequence to obtain a rollback operation sequence if there is an operation conflict.

[0011] In a preferred embodiment, this application can be further configured to: perform a corresponding rollback operation based on the component corresponding to each rollback operation in the rollback operation sequence, including: performing a corresponding rollback operation based on the component corresponding to each rollback operation in the rollback operation sequence using a distributed transaction and idempotency approach.

[0012] In a preferred embodiment, this application can be further configured to include: real-time monitoring of the execution status and progress of the rollback operation; and / or monitoring whether a fault occurs during the rollback operation; if a fault occurs, performing a fault response based on a preset strategy; and / or, after completing each rollback operation in the rollback operation sequence, monitoring the key performance indicators of the rolled-back link; comparing the key performance indicators with baseline performance indicators to determine a first rollback result; obtaining the health status of the rolled-back link, and determining a second rollback result based on the health status; determining whether the rollback was successful based on the first rollback result and the second rollback result; and / or, after a successful rollback, continuously monitoring the key performance indicators of the rolled-back link and the health status of the rolled-back link for long-term trend monitoring.

[0013] Secondly, a rollback device is provided, comprising: a deployment event sensing unit for acquiring metadata of new deployment events; a link topology modeling unit for acquiring a communication link topology diagram between services; an anomaly impact analysis unit for determining the anomaly characteristics and causes of anomalies in the abnormal links based on information about the services involved in the new deployment event in the metadata, the communication link topology diagram, and real-time link performance data; a rollback strategy generation unit for determining a rollback strategy based on the anomaly characteristics and causes; generating a rollback operation sequence using the link topology diagram based on the rollback strategy; and a rollback execution coordination unit for executing corresponding rollback operations based on the components corresponding to each rollback operation in the rollback operation sequence.

[0014] Thirdly, an electronic device is provided, the electronic device including a memory and a processor, the memory storing a computer program, the processor executing the rollback method according to any one of the first aspects when running the computer program.

[0015] Fourthly, a computer-readable storage medium is provided, wherein at least one piece of program code is stored therein, the program code being loaded and executed by a processor to implement the rollback method as described in any of the first aspects.

[0016] Fifthly, a computer program product is provided, including a computer program or instructions that, when executed by a processor, implement the rollback method as described in any of the first aspects.

[0017] In summary, the rollback method provided in this application offers the following beneficial technical effects: After detecting a new deployment event, based on the information of the services involved in the new deployment event and the communication link topology diagram between the services in the metadata of the new deployment event, the abnormal situation is assessed. This allows for the accurate identification of abnormal links affected by the new deployment, their abnormal characteristics, and their causes. Only necessary services are rolled back, thus achieving refined rollback operations and minimizing the scope of impact. Furthermore, a rollback strategy is determined based on the abnormal characteristics and causes. According to the rollback strategy, a rollback operation sequence is generated using the link topology diagram, accelerating the decision-making process and significantly shortening the average time from problem discovery to system recovery. This application enables rapid and efficient rollback application to minimize downtime and the scope of impact.

[0018] In addition, this application also provides a rollback device, equipment, and medium, all of which have the aforementioned beneficial technical effects. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments or related technologies of this application, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating a rollback method provided in an embodiment of this application;

[0021] Figure 2 This is the core principle and process framework of a link-level application rollback acceleration method provided in the embodiments of this application;

[0022] Figure 3 This is a schematic diagram comparing the core principle of this application with related technologies in terms of mean fault recovery time, provided in an embodiment of this application.

[0023] Figure 4 This is the framework for the composition and classification of the link-level fine-grained rollback strategy provided in the embodiments of this application;

[0024] Figure 5This is a schematic diagram of the structure of a rollback device provided in an embodiment of this application;

[0025] Figure 6 This is the overall technical solution architecture of the link-level application rollback acceleration system provided in the embodiments of this application;

[0026] Figure 7 This is a logical flow framework for an anomaly impact analysis unit provided in an embodiment of this application;

[0027] Figure 8 This is a logical flow framework for a rollback strategy generation unit provided in an embodiment of this application;

[0028] Figure 9 This application provides a logical flow framework for a rollback status verification unit.

[0029] Figure 10 This application provides an embodiment that illustrates the data flow and interaction relationships among various units within a link-level application rollback acceleration system;

[0030] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0031] This specific embodiment is merely an explanation of this application and is not intended to limit it. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they are within the scope of this application.

[0032] It should be noted that, in the optional embodiments of this application, the data related to object information, when applied to specific products or technologies, requires the permission or consent of the object. Furthermore, the collection, use, and processing of this data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. In other words, if the embodiments of this application involve data related to an object, it must be obtained with the permission and consent of the object, the permission and consent of relevant departments, and in accordance with the relevant laws, regulations, and standards of the country and region. If the embodiments involve personal information, the acquisition of all personal information requires the consent of the individual. If sensitive information is involved, the separate consent of the information subject is required. The embodiments also need to be implemented with the permission and consent of the object.

[0033] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0034] Furthermore, the terms "and / or" in this document are merely descriptions of the relationships between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0035] This application relates to a link-level application rollback acceleration method, which can be specifically applied to the application deployment and rollback management system under a distributed microservice architecture.

[0036] To better understand and explain the solutions of the embodiments of this application, some technical terms involved in the embodiments of this application will be briefly explained below.

[0037] Link: In a distributed system, a link refers to the complete path from when a request enters the system, through multiple services or modules, to when a response is finally returned.

[0038] Link-level rollback: A fine-grained rollback operation performed on a specific communication link, rather than a full rollback of the entire application or cluster.

[0039] Deployment Event: Refers to activities such as the deployment, update, and configuration change of an application or service.

[0040] Link topology: A directed graph model that describes the communication links and dependencies between services in a distributed system.

[0041] MTTR (Mean Time To Repair): Mean Time To Repair measures the average time required for a system to return to normal operation after a failure occurs.

[0042] CI / CD (Continuous Integration / Continuous Deployment): Continuous integration and continuous deployment, an automated software development process.

[0043] Blue-Green Deployment: A deployment strategy that runs two identical production environments simultaneously, switching between them by switching traffic.

[0044] Canary Release: A gradual deployment strategy that first deploys a new version to a small number of instances and then gradually expands its scope.

[0045] In modern distributed microservice architectures, rapid application iteration and frequent deployment have become the norm. However, when a newly deployed application experiences failures or performance issues, how to quickly and accurately roll back to a stable version to minimize the impact of the failure and recovery time is a core challenge for operations and maintenance personnel.

[0046] Currently, the industry has several mature technical solutions for application rollback, mainly including: full rollback solutions based on version management; rollback solutions based on blue-green deployment; progressive rollback solutions based on canary releases; rollback solutions based on container orchestration platforms; configuration rollback solutions based on configuration management; and manual rollback solutions based on monitoring and alerts.

[0047] While the aforementioned technical solutions each have their own characteristics, they all primarily focus on the following aspects: 1. Version management: Maintaining historical versions of applications or configurations and supporting rollback to specified versions; 2. Deployment management: Managing application deployment and rollback through deployment systems or container orchestration platforms; 3. Traffic control: Controlling traffic routing through load balancers or service meshes to achieve rapid switching; 4. Monitoring and alerting: Detecting anomalies through monitoring systems and triggering rollback decisions. However, these solutions generally suffer from the following limitations: They primarily focus on service-level rollback, resulting in long rollback times and low efficiency.

[0048] Furthermore, the following limitations exist: rollback decisions are mainly based on simple monitoring metrics, lacking in-depth analysis of link topology and dependencies; the rollback process lacks intelligent policy generation and automated execution coordination; and there is a lack of effective verification mechanisms after rollback.

[0049] This application provides a link-level application rollback acceleration method. By constructing deployment event awareness, link topology modeling, anomaly impact analysis, rollback policy generation, and rollback execution coordination, and further adding rollback status verification, a complete closed loop is achieved, realizing refined, automated link-level rollback capabilities that can significantly shorten recovery time.

[0050] Specifically, embodiments of this application provide a rollback method, such as... Figure 1As shown, the method provided in this application embodiment can be executed by an electronic device, which is a server. This server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. The terminal device can be a smartphone, tablet, laptop, desktop computer, etc., but is not limited to these. The terminal device and electronic device can be directly or indirectly connected via wired or wireless communication. This application embodiment does not impose any limitations on this connection. The method includes:

[0051] S10. Obtain metadata for new deployment events;

[0052] In this embodiment of the application, application deployment activities and accompanying configuration change events in the distributed system are continuously monitored, and metadata related to these events is captured.

[0053] Monitor for new deployment events. This can be achieved by actively listening to the callback interface of the CI / CD toolchain, or by passively detecting deployment events by analyzing the logs of the deployment system.

[0054] Therefore, in one feasible approach, an event listener on an electronic device continuously monitors preset callback interfaces or webhooks in the CI / CD toolchain (such as Jenkins, GitLab CI / CD, and ArgoCD). When a new deployment event (such as application build completion, image push, deployment task startup, or canary release traffic switching) occurs, the event listener receives an event notification immediately. In another feasible approach, the deployment system's log files are scanned periodically; deployment events are identified through log parsing. In yet another feasible approach, for systems using a database to store deployment information, deployment events can be detected by monitoring database changes. This involves using ChangeDataCapture (CDC) technology to monitor changes in deployment-related tables.

[0055] Furthermore, the metadata extractor of the electronic device is used to parse the structured initial metadata from the event notification. The structured initial metadata includes, but is not limited to, the following data: the identifier of the deployment request, the committed code branch, the committer information, the deployment trigger timestamp, the unique version number of the application, the target deployment environment (such as production environment, test environment), the list of service components involved in the changes in this deployment (such as microservice A, service B, service C), the number of service instances before and after the deployment, and changes in resource quotas (such as CPU and memory adjustments).

[0056] The system uses an electronic device configuration change capture module to monitor configuration update events in configuration management systems (such as Consul, Nacos, and Apollo). Through integration with the configuration center system's API, it obtains the old and new values ​​of configuration items in real time (e.g., changes to database connection strings, adjustments to cache expiration times, and switching of feature on / off states). It records detailed configuration change information, including key-value pairs of configuration items, change operations (e.g., adding, modifying, deleting), and change timestamps.

[0057] Through the data structuring and push module of the electronic device: all captured event data (initial metadata and detailed configuration change information) are standardized into a unified data structure (usually in JSON or Protocol Buffers format) to obtain the metadata of the new deployment event. This metadata includes, but is not limited to, the following fields: event ID, timestamp, operator ID, change type (such as deployment, configuration update, service expansion), affected resource identifier (such as service name, cluster ID, namespace), and change details (such as comparison between old and new versions, configuration differences).

[0058] The structured metadata mentioned above can be pushed to high-throughput message queues (such as Kafka and RabbitMQ) as an intermediate storage layer to achieve asynchronous processing and decoupling.

[0059] Furthermore, exception handling mechanisms can be added, including setting a retry mechanism and error logging functionality. Specifically, in one implementable method of this application, the rollback method may further include: if a temporary failure occurs during event capture or data push (such as network interruption or message queue unavailability), multiple attempts will be made according to a preset retry strategy, which may indicate retrying operations according to the number of retries; for unrecoverable errors, detailed error logs will be recorded and alarm notifications will be triggered.

[0060] In this embodiment, deployment events and configuration change events are captured in real time, and the potential impact is immediately assessed; a rollback plan can be initiated before the problem fully manifests; and the rollback strategy and system performance are continuously optimized through the rollback history audit unit.

[0061] Existing technical solutions typically only roll back after a problem occurs, lacking a proactive fault prevention mechanism. This application tightly integrates the rollback strategy with the deployment process, capturing deployment and configuration changes in real time through a deployment event awareness unit. This proactive integration enables the system to assess potential impacts at the nascent stage of a problem, and even activate contingency plans before the problem fully manifests, thereby further optimizing the mean time to recovery and providing a solid guarantee for business continuity.

[0062] S20. Obtain the communication link topology diagram between various services;

[0063] In this embodiment of the application, a communication link topology diagram is pre-constructed, which allows for direct access to the communication link topology diagram.

[0064] In one feasible approach, a communication link topology diagram can be dynamically constructed. Specifically, obtaining the communication link topology diagram between services includes: continuously acquiring service instance information of all registered services; performing real-time parsing of network traffic logs in the distributed system to obtain the actual communication patterns between services, which represent the call information and communication information between services; acquiring complete call chain data between services; and constructing the communication link topology diagram between services based on the service instance information, the actual communication patterns between services, and the complete call chain data.

[0065] Dynamically construct and maintain in real time the communication link topology diagram between various application services in the distributed system and their mutual dependencies.

[0066] Specifically, the service registration and discovery data acquisition module of the electronic device continuously acquires service instance information for all registered services. This is achieved by integrating the API interface of a service registration and discovery system (such as Eureka, Consul, or KubernetesServiceDiscovery), continuously obtaining information on all registered service instances. This service instance information includes, but is not limited to: service name, instance ID, IP address, port number, health status, and metadata tags (such as the service's business domain and version number). Whenever a new service instance comes online, goes offline, or its health status changes, this module captures these dynamics in real time.

[0067] The network traffic log parsing module of the electronic device enables real-time parsing of network traffic logs (such as VPC flow logs and Envoy access logs) in the distributed system. Specifically, by analyzing information such as source IP, destination IP, port number, protocol type, request method, and URL path, the actual communication patterns between services are identified. The actual communication patterns include: which services are calling which services, the direction and frequency of communication, and implicit communication not established through explicit registration and discovery mechanisms.

[0068] The service call chain tracing data aggregation module for electronic devices integrates with distributed tracing systems (such as Zipkin, Jaeger, and SkyWalking) to obtain complete service call chain data. This call chain data records all RPC or HTTP calls from the entry service to downstream dependent services, including the time, status code, and context information for each call. By aggregating this tracing data, a dynamic dependency graph containing rich attributes such as call sequence and latency distribution can be constructed.

[0069] The graph model building and updating engine for electronic devices receives data from all the above modules and builds a directed graph model.

[0070] Node: Represents an independent application service instance or logical service group (all instances that carry the same business logic but are deployed on different servers can be regarded as a logical service group).

[0071] Edge: Represents the communication link between services. Each edge comes with rich attributes: communication protocol type (such as HTTP, gRPC, message queue), port information, expected traffic pattern (such as average requests per second, peak requests per second), and health indicator thresholds of the link.

[0072] Furthermore, an incremental update strategy can be adopted to periodically (e.g., every 10 seconds or based on event triggers) update this topology map to reflect dynamic changes such as service scaling up and down, service migration, and link establishment or disconnection, ensuring the real-time accuracy of topology information.

[0073] Furthermore, the topology graph is typically stored in an in-memory database or a graph database (such as Neo4j), supporting multi-version management.

[0074] Furthermore, data deduplication, conflict resolution, and consistency verification are performed when constructing the topology graph.

[0075] Another feasible approach is to build a communication link topology based on a static configuration file. In this method, the dependencies between services are explicitly declared in the configuration file; the system reads the configuration file and builds the communication link topology at startup. This approach is simple to implement and provides accurate topology information, but it cannot reflect dynamic changes during runtime and requires manual maintenance.

[0076] In another feasible approach, a communication link topology map can be constructed based on service mesh topology discovery. For systems using service meshes (such as Istio and Linkerd), the service mesh's topology discovery capabilities can be leveraged. This involves obtaining topology information through the service mesh's control plane API. The topology information is accurate and well-integrated with traffic management.

[0077] In this application embodiment, a link topology graph is dynamically constructed using multiple data sources (service registration and discovery, network traffic logs, call chain tracing, and explicit dependency configuration); the topology graph is periodically updated to ensure the real-time accuracy of the topology information; and based on the topology information, the affected direct and indirect communication links are accurately identified. Related technical solutions lack the ability to dynamically perceive the topology and dependencies of communication links between services in a distributed system, making it difficult to accurately determine which downstream services and links a service failure will affect. This application provides comprehensive contextual information for rollback decisions by dynamically maintaining the topology and dependencies of communication links between services. This real-time, accurate topology data is the foundation for implementing link-level rollback, enabling the system to understand the complex interactions between different service components, thereby designing a rollback scheme that solves the problem without introducing new side effects, effectively reducing the risk of rollback operations.

[0078] S30. Based on the information of the services involved in the new deployment event in the metadata, the communication link topology diagram, and the real-time link performance data, determine the abnormal characteristics and causes of the abnormal link.

[0079] Among them, real-time link performance data represents the key performance indicators of the link before and after deployment. These key performance indicators include, but are not limited to: request latency (such as average latency, 95th percentile latency), error rate (such as HTTP5xx errors, RPC call failure rate), throughput (such as requests per second), number of connections, and resource utilization (such as CPU utilization, memory utilization).

[0080] Based on deployment event information, link topology diagrams, and real-time link performance data, assess the potential or actual impact of new deployments on communication links, identify abnormal links, and determine the abnormal characteristics and causes of abnormal links.

[0081] Abnormal links are those that directly communicate with the deployed services, as well as those that may be affected through dependency relationships. Links potentially affected through dependency relationships are considered indirectly affected links. For example, if a new version of service A is deployed, and service A depends on service B, and service B depends on service C, then the service AB and BC links may be directly or indirectly affected. A breadth-first search or depth-first search algorithm is used to traverse the topology graph, constructing a complete impact range tree or graph to obtain all potentially affected links, and then identifying abnormal links from these links.

[0082] S40. Determine the rollback strategy based on the anomaly characteristics and causes; based on the rollback strategy, use the link topology diagram to generate the rollback operation sequence corresponding to the target affected link.

[0083] In this embodiment of the application, a link-level rollback strategy, which includes specific rollback operations and execution order, is automatically generated for the identified abnormal links and their impact characteristics.

[0084] This process involves acquiring a list of affected links, identifying anomalous characteristics of the affected links (such as sudden increases in latency, elevated error rates, and abnormal traffic), and obtaining potential root cause analysis results (such as memory leaks and configuration errors). This data is then parsed and standardized for subsequent policy matching.

[0085] In one feasible approach, the matching engine in an electronic device selects or combines matching rollback templates, i.e., rollback strategies, based on a predefined rollback policy rule base.

[0086] The rule base stores multiple rollback policy templates:

[0087] Traffic switching strategy templates are used to gradually or immediately switch traffic for specific services or APIs from faulty versions to stable versions. For example, when a newly deployed service instance is detected to be in poor health, 100% of user traffic can be redirected to the older version service instance. Parameters such as the switching percentage and switching speed can be configured.

[0088] Configure a rollback policy template to restore the runtime configuration of affected services to a stable configuration recorded before deployment. For example, if a new configuration item is found to have caused the system crash, automatically roll back that configuration item to its last valid value. You can specify the configuration key name to roll back.

[0089] Service instance management policy templates are used to isolate, restart, or replace service instances that are malfunctioning. For example, if a service instance's CPU utilization remains excessively high, it can be removed from the load balancer and restarted.

[0090] Data compensation strategy templates are used to perform predefined data repair or compensation operations when rollback causes data inconsistency. For example, after rolling back a database schema change, a data migration script is executed to repair the data under the old schema.

[0091] Based on the anomaly characteristics and root causes, the matching engine searches the rule base for the policy rule that best matches the current situation. For example, if the anomaly impact analysis unit identifies abnormally high traffic for a specific service and the root cause is the incorrect removal of a rate limiting configuration, the matching engine may select to configure a rollback policy template and specify the rollback of the rate limiting configuration.

[0092] This application supports multiple rollback strategy templates (traffic switching, configuration rollback, service instance management, and data compensation), which can be flexibly combined according to specific circumstances. Based on a predefined rollback strategy rule base, it selects or combines matching rollback templates; intelligently matches the most suitable rollback strategy based on anomaly characteristics and root cause analysis results; and generates an ordered sequence of rollback operations based on the dependencies of affected links. This application introduces an intelligent rollback strategy generation mechanism that can automatically combine and execute link-level rollback operation sequences, such as traffic switching, configuration rollback, or data compensation, based on the characteristics and root causes of anomaly impacts. This minimizes the need for manual intervention and accelerates the decision-making process through predefined strategy templates and dynamic adjustments.

[0093] Traditional rollback mechanisms in existing technologies typically rely on pre-defined rules and coarse-grained monitoring metrics, requiring manual judgment on whether and how to rollback, a time-consuming decision-making process. The lack of in-depth analysis of the root causes of anomalies prevents the generation of targeted rollback strategies. This application introduces an intelligent rollback strategy generation mechanism that automatically combines and executes a chain-level rollback operation sequence based on the characteristics and root causes of anomaly impacts. This minimizes the need for manual intervention and accelerates the decision-making process through predefined strategy templates and dynamic adjustments, reducing the average time from problem discovery to system recovery by more than 70%.

[0094] The rule base uses a rule-template mapping table structure. Each rule contains the following key fields: Rule ID: a unique identifier; Rule Name: a descriptive name of the rule; Matching Conditions: matching conditions composed of a set of abnormal features and root cause types; Associated Policy Template: the type of policy template to be used when a match is successful; Matching Priority: the priority order when multiple rules match simultaneously (the smaller the value, the higher the priority); Matching Weight: the confidence weight of the rule match (between 0 and 1); Template Parameter Configuration: the specific parameter settings of the policy template for this rule (such as traffic switching percentage, rollback speed, etc.).

[0095] The rules in the rule base use a combination of anomaly characteristics and root cause types as the matching key. For example: if the anomaly characteristic is high latency and high error rate, and the root cause type is configuration error, the corresponding configuration rollback policy template is used; if the anomaly characteristic is high latency and high error rate, and the root cause type is code defect, the corresponding traffic switching policy template is used; if the anomaly characteristic is resource exhaustion, and the root cause type is insufficient resources, the corresponding service instance management policy template is used; if the anomaly characteristic is data inconsistency, and the root cause type is code defect, the corresponding data compensation policy template and traffic switching policy template (combined policy) are used.

[0096] Specifically, it receives anomaly characteristics and root cause analysis results from the anomaly impact analysis unit, standardizes and classifies the anomaly characteristics, and maps specific anomaly indicators to standardized anomaly characteristic categories, such as: latency anomaly category: including high latency, sudden increase in latency, P95 latency exceeding the standard, etc.; error anomaly category: including high error rate, sudden increase in 5xx errors, connection errors, etc.; traffic anomaly category: including sudden drop in traffic, abnormally high traffic, traffic fluctuation, etc.; resource anomaly category: including memory exhaustion, CPU overload, connection pool exhaustion, thread pool full, etc.; data anomaly category: including data inconsistency, data loss, data format error, etc.

[0097] Root causes are standardized and categorized, mapping specific root cause descriptions to standardized root cause types: Configuration errors: including incorrect configuration items, missing configurations, and unreasonable configuration values; Code defects: including code logic errors, memory leaks, unreleased resources, and concurrency issues; Insufficient resources: including insufficient resource quotas and unreasonable resource allocation; Dependency service anomalies: including downstream service failures and unavailable external dependencies; Deployment issues: including version incompatibility and deployment configuration errors.

[0098] Attempt exact matching by finding rules in the rule base that perfectly match the current set of abnormal features and the root cause type. Calculate the intersection size of the input abnormal feature set and the set of abnormal features in the rules: Matchfeatures = |Featuresinput| |Featuresrule|. Where Matchfeatures is the intersection size of the input abnormal feature set and the set of abnormal features in the rules, Featuresinput is the input abnormal feature set, and Featuresrule is the set of abnormal features in the rules. If the root cause type is a perfect match, then Matchroot_cause = 1.0; otherwise, Matchroot_cause = 0.0. Calculate the exact match score: Scoreexact = wf ⋅ Matchfeatures + wr ⋅ Matchroot_cause, where wf and wr are weight coefficients, and wf + wr = 1. If Scoreexact = 1.0, a perfectly matching rule has been found, and the corresponding policy template is used directly.

[0099] If an exact match fails, a fuzzy match is performed. The partial match score for anomalous features is calculated: Matchfeatures_partial = |Featuresinput| |Featuresrule| |Featuresinput| |Featuresrule|. The root cause type similarity score is also calculated (based on the hierarchical structure or semantic similarity of root cause types).

[0100] If the root cause types belong to the same major category (e.g., all are configuration issues), then `Matchroot_cause_partial` = 0.7; if the root cause types are completely unrelated, then `Matchroot_cause_partial` = 0.0. Calculate the fuzzy matching score: `Scorefuzzy = wf ⋅ Matchfeatures_partial + wr ⋅ Matchroot_cause_partial`; set the fuzzy matching threshold (e.g., 0.6). If `Scorefuzzy ≥ 0.6`, the rule is considered a successful match.

[0101] For all successfully matched strategy templates, they are first sorted in descending order of matching score (higher score takes precedence); if the matching scores are the same, they are sorted in ascending order of rule priority field (lower priority value takes precedence); if the priorities are also the same, they are sorted in descending order of rule matching weight. The strategy template corresponding to the rule with the highest priority is selected. If the rule specifies multiple templates (combined strategy), all templates are selected simultaneously.

[0102] Furthermore, template parameters can be dynamically adjusted based on the specific circumstances of the current anomaly (such as severity and scope of impact): For traffic switching strategies, the switching percentage is determined based on the error rate (100% switching when error rate > 10%, 50% switching when error rate 5-10%, and 10% switching when error rate < 5%); for configuration rollback strategies, the specific configuration key names and rollback target values ​​are determined based on the configuration item information in the root cause analysis results; for service instance management strategies, the decision to isolate, restart, or replace instances is made based on resource usage; for data compensation strategies, the corresponding data repair script is selected based on the type and scope of data inconsistency; for multi-template combination strategies, when a rule requiring multiple strategy templates to be combined is matched, the following principles apply: sequential execution: some operations need to be executed sequentially, such as executing data compensation first and then traffic switching; parallel execution: some operations can be executed in parallel, such as rolling back the configurations of multiple services simultaneously; dependency relationships: the dependency relationships between templates are identified to ensure that dependent templates are executed first. An execution plan for the combined strategy is generated, including the execution order, parallelism, and dependencies of each template.

[0103] Besides the methods mentioned above for determining rollback strategies, simple rules can also be used to generate rollback strategies. For example, a fixed rollback strategy can be defined for each exception type; or the corresponding strategy can be directly selected based on the exception type. Exception types can be categorized based on exception characteristics: e.g., latency exceptions (high latency, sudden latency increases, P95 latency exceeding limits, average latency exceeding limits, etc.); error exceptions; traffic exceptions; resource exceptions; data exceptions. Root cause-based classifications include: e.g., configuration error types (incorrect configuration items, missing configurations, unreasonable configuration values, configuration conflicts, etc.); code defect types; insufficient resource types; dependent service exception types; deployment problem types. Severity-based classifications include: e.g., severe exceptions (complete service unavailability, data loss, system crashes, etc.); moderate exceptions; minor exceptions.

[0104] In another possible scenario, a machine learning model (such as reinforcement learning) is used to learn the optimal rollback strategy. For example, a machine learning model can be trained using historical rollback data, and the model outputs the optimal rollback strategy based on the current situation. The current situation is a multi-dimensional feature vector, including but not limited to the following information: anomaly feature information: such as anomaly indicator values: key performance indicator values ​​of the previous anomaly link; the trend and rate of change of the anomaly indicator; the trend of change of the error rate; the trend of change of latency; the duration of the anomaly; and the scope of the anomaly's impact: the number of links, services, and users affected by the anomaly. In this embodiment, once a suitable strategy template is matched, an ordered sequence of rollback operations is generated based on the dependencies of the affected links in the link topology graph.

[0105] Generate basic operations based on strategy templates:

[0106] For each service component that needs to be rolled back, a corresponding basic rollback operation is generated based on the matched policy template type. For example, the traffic switching policy template generates a traffic switching operation, which includes: Operation type: traffic_switch; Target service: Service component name; Operation parameters: Source version number, target version number, switching percentage, switching speed; Operation description: Switch the traffic of the specified service from the new version to the old version.

[0107] The configuration rollback policy template generates corresponding configuration rollback operations, specifically including: Operation type: config_rollback; Target service: Service component name; Operation parameters: List of configuration key names, rollback target value (obtained from deployment event metadata); Operation description: Roll back the configuration items of the specified service to their values ​​before deployment. The service instance management policy template generates corresponding instance management operations, specifically including: Operation type: instance_management; Target service: Service component name; Operation parameters: Operation subtype (isolate, restart, replace), list of instance IDs (optional; if empty, operate on all instances); Operation description: Isolate, restart, or replace abnormal service instances.

[0108] The data compensation strategy template generates corresponding data compensation operations, which include: Operation type: data_compensation; Target service: Service component name or database service; Operation parameters: Compensation script path, execution parameters; Operation description: Execute data repair or compensation script; If multiple strategy templates are matched (combined strategies), multiple basic operations are generated for the same service component.

[0109] Obtain a complete link topology graph from the link topology modeling unit, and analyze the dependencies between service components that need to be rolled back. Calculate the dependency depth: for each service component, calculate its depth in the dependency graph (the longest path length from the root node to that node). A larger depth indicates that it is closer to the end of the link. Basic principles: Minimize the impact on business operations, ensure that the execution order of the rollback operation can quickly restore system stability, and avoid service interruptions and data inconsistencies during the rollback process.

[0110] Prioritization Rules: Downstream Priority: Roll back downstream services (services with deep dependencies) first, then roll back upstream services. This cuts off the anomaly propagation path and prevents the anomaly from spreading upstream. Root Cause Service Priority: If root cause analysis identifies a specific root cause service component, roll back the root cause service first, as it is the source of the anomaly. Impact Scope Priority: Roll back services with a large impact scope (services depended on by multiple links) first, allowing for rapid recovery of multiple anomaly links. Different operation types have different priorities: Data compensation operations have the highest priority (must be executed before other operations to ensure data consistency); configuration rollback operations have the second highest priority (configuration changes may affect multiple services); traffic switching operations have the next lowest priority (allows for rapid traffic switching, but requires ensuring the target version is available); instance management operations have the lowest priority (usually used as a last resort).

[0111] Calculate a comprehensive priority score for each operation: Priorityop = w1⋅Depthservice + w2⋅IsRootCause + w3⋅ImpactScope + w4⋅OpTypePriority. Where:

[0112] Depthservice represents the service's depth in the dependency graph (normalized to 0-1); IsRootCauseIs indicates whether it is the root cause service (1.0 for yes, 0.0 for no); ImpactScope represents the service's scope of influence (how many abnormal links depend on it, normalized to 0-1); OpTypePriorityOp represents the priority of the operation type (between 0 and 1, data compensation > configuration rollback > traffic switching > instance management); w1, w2, w3, and w4 are weight coefficients, and w1+w2+w3+w4=1. Operations are sorted in descending order of comprehensive priority score (higher scores are executed first); for multiple operations on the same service component, they are sorted according to the priority of the operation type.

[0113] Analyze the dependencies between operations to ensure that certain operations must be executed before others: data compensation operations must be executed before all other operations; configuration rollback operations, if affecting the target version of traffic switching, must be executed before traffic switching; instance management operations (such as restarts), if involving the target instance of traffic switching, must be executed after traffic switching, or traffic switching must be performed first and then the instance restarted; create a dependency list for each operation, recording the IDs of other operations that the operation depends on; in the sorted operation sequence, check and adjust the operation order to ensure that dependencies are satisfied.

[0114] For example, suppose the abnormal links include: link 1 (service A → service B → service C) and link 2 (service A → service B → service D).

[0115] Identify the service components that need to be rolled back: Service A, Service B, Service C, and Service D;

[0116] Root cause analysis identified service B as the root cause service and matched the configured rollback strategy template;

[0117] The sequence of operations is as follows: Operation 1: Data compensation operation (if data inconsistency issues exist); Operation 2: Configuration rollback operation (Service B, rollback of rate limiting configuration) - root cause service priority; Operation 3: Traffic switching operation (Service C, 100% switch to the old version) - downstream service priority; Operation 4: Traffic switching operation (Service D, 100% switch to the old version) - downstream service priority; Operation 5: Traffic switching operation (Service B, 100% switch to the old version) - root cause service; Operation 6: Traffic switching operation (Service A, 100% switch to the old version) - upstream service.

[0118] Each basic operation is encapsulated into a structured set of instructions. The fundamental principle is to minimize the impact on business operations. For example, in a request chain A→B→C, if service B encounters an anomaly, the rollback strategy might first roll back the downstream service C that depends on service B or its related interfaces, and then roll back the request entry point of the upstream service A to the old version, to ensure that the impact on its upstream and downstream services is minimized or controllable when rolling back B.

[0119] Each rollback operation is encapsulated as an atomic instruction, which includes the target service, operation type, parameters, and execution order.

[0120] In this embodiment, a link topology modeling unit dynamically constructs and maintains the inter-service communication link topology in real time; an anomaly impact analysis unit determines the set of direct and indirect communication links that may be affected by this deployment; and an ordered rollback operation sequence is generated based on the dependencies of the affected links. By introducing link topology modeling and anomaly impact analysis, the communication links affected by the new deployment can be accurately identified, thereby achieving fine-grained rollback operations and minimizing the impact scope. This innovation avoids the coarse-grained problem of traditional full rollbacks and achieves precise rollback for specific links. Related technical solutions (such as Kubernetes rollback and blue-green deployment) mainly focus on service-level or application-level rollbacks and cannot achieve fine-grained rollbacks at the link level. When a request passes through the link of service A → service B → service C, if only service B has a problem, related technologies may need to roll back the entire application or the entire cluster, resulting in an excessively large rollback scope, and normal services may also be rolled back. This application, through link topology modeling and anomaly impact analysis, can accurately identify the communication links affected by the new deployment and only roll back the necessary services, thereby achieving fine-grained rollback operations and minimizing the impact scope. This link-level precision avoids unnecessary global rollbacks, significantly reducing system downtime and resource consumption.

[0121] S50. Execute the corresponding rollback operation based on the component corresponding to each rollback operation in the rollback operation sequence.

[0122] Schedule and execute the generated rollback policy to restore the abnormal link to a stable state.

[0123] The rollback instruction parsing module of the electronic device receives and parses the rollback operation sequence provided by the rollback policy generation unit. This sequence is usually a series of structured instructions (such as JSON or YAML format) that describe which service to target, what operation to perform, what parameters to include, and the priority or dependencies of the operation. The parsing module converts these high-level operations into low-level instructions that can be directly called by the system infrastructure API.

[0124] The distributed command distribution module of the electronic device distributes the parsed low-level instructions to the corresponding components or platforms in the distributed system. For example, if the instruction is to switch traffic from a new version of service A to an old version, the API interface of the load balancer (such as Nginx, Envoy, Istio) or API gateway is called to modify the traffic routing rules; if the instruction is to roll back the configuration items of service B, the API of the configuration center (such as Apollo, Nacos) is called to publish the old version of the configuration; if the instruction is to restart an instance of service C, the API of the container orchestration platform (such as Kubernetes, Mesos) is called to perform the service instance restart operation. The execution of each instruction requires a security authentication and authorization mechanism to ensure the legitimacy of the operation.

[0125] In addition to the API calls mentioned above, rollback can also be achieved by executing predefined scripts, writing scripts for each rollback operation, executing scripts through a script executor, or using a workflow engine (such as Airflow or Temporal) to orchestrate and execute rollback operations, defining rollback operations as workflow tasks, and using the workflow engine to schedule and execute tasks.

[0126] As can be seen, in this embodiment, after detecting a new deployment event, the abnormal situation is assessed based on the information of the services involved in the new deployment event and the communication link topology diagram between the services in the metadata of the new deployment event. This allows for the accurate identification of the abnormal links affected by the new deployment, their abnormal characteristics, and their causes. Only necessary services are rolled back, thereby achieving refined rollback operations and minimizing the scope of impact. Furthermore, a rollback strategy is determined based on the abnormal characteristics and causes. According to the rollback strategy, the rollback operation sequence corresponding to the target affected links is generated using the link topology diagram, accelerating the decision-making process and greatly shortening the average time from problem discovery to system recovery. This application can quickly and efficiently apply rollback to minimize downtime and the scope of impact.

[0127] In one possible implementation of this application embodiment, S30 determines the abnormal characteristics and causes of the abnormal link based on information about the service involved in the new deployment event in the metadata, the communication link topology diagram, and real-time link performance data, including:

[0128] S301. Based on the information of the services involved in the new deployment event in the metadata and the communication link topology diagram, identify at least one affected link;

[0129] The system receives deployment metadata captured by the deployment event awareness unit. Based on this metadata (such as the changed list of service components and service instance identifiers) and the communication link topology, it identifies the direct and indirect communication links that may be affected by this deployment or configuration change, as at least one affected link. Directly affected links refer to links that directly communicate with the deployed services; indirectly affected links refer to links that may be affected through hierarchical dependencies.

[0130] S302. Obtain real-time link performance data, which includes at least one key performance indicator that affects the link before and after deployment.

[0131] For at least one potentially affected link identified, obtain key performance indicators (KPIs) of these links before and after deployment from distributed tracing systems, real-time monitoring platforms, and APM tools: request latency, error rate, throughput (e.g., requests per second), number of connections, and resource utilization.

[0132] S303. Based on real-time link performance data, evaluate the target affected link and obtain the link anomaly information of the target affected link; the link anomaly information includes: anomaly characteristics, whether the target affected link is an abnormal link, and the anomaly cause when the target affected link is an abnormal link; the target affected link is any link among at least one affected link.

[0133] Among them, abnormal features refer to abnormal indicators in key performance indicators.

[0134] In one possible implementation of this application embodiment, S303 evaluates the target affected link based on real-time link performance data to obtain link anomaly information of the target affected link, including:

[0135] SA1. Based on the performance data of the target link affected by the real-time link performance data, determine the evaluation value of the target key performance indicator of the target link affected by the performance data, and whether the target key performance indicator is an abnormal feature. The target key performance indicator is any one of multiple key performance indicators.

[0136] Based on the performance data of the target link affected by the real-time link performance data, determine the evaluation values ​​of several key performance indicators of the target link affected by the link.

[0137] The evaluation values ​​can be obtained through Z-score analysis of key performance indicators. Specifically, statistical analysis methods or machine learning models are used to compare performance indicators within the deployment activity time window and before and after deployment to identify significant abnormal fluctuations associated with the deployment activity. Specifically, anomaly detection for each key performance indicator of the performance data in the target impact chain can be performed using Z-score analysis. Where: X represents the currently observed link performance metric value, This represents the historical average or baseline average of the link's performance metrics during a stable operating period. This represents the historical standard deviation or baseline standard deviation of the link's performance metric over a stable operating period, where z represents the metric evaluation value of the key performance indicator.

[0138] This also allows for the establishment of baseline data for each key performance indicator. Baseline data can be obtained from the average or median of historical stable operating cycles (such as the past 7 days). .

[0139] Furthermore, based on the evaluation values ​​of the target key performance indicators of the impact link, it is determined whether the target key performance indicators are abnormal. For each key performance indicator, if the calculated Z value exceeds a preset threshold (such as 2 or 3 standard deviations), the indicator is determined to be abnormal.

[0140] This application uses the Z-score method to detect anomalies in single metrics; calculates a comprehensive anomaly score to comprehensively evaluate multi-dimensional performance metrics; and uses a root cause analysis module to pinpoint the specific causes of link anomalies. By comparing performance metrics before and after deployment using statistical analysis methods (such as Z-score analysis) or machine learning models, significant abnormal fluctuations associated with deployment activities are identified. This intelligent anomaly detection mechanism can accurately identify link anomalies, providing a reliable basis for rollback decisions.

[0141] In another possible approach, a fixed threshold is set for each key performance indicator (KPI), and an KPI is considered abnormal when it exceeds the threshold.

[0142] In another feasible approach, time series forecasting models (such as ARIMA and LSTM) are used to predict the normal range of each key performance indicator, and anomalies are identified when the actual value deviates from the predicted range.

[0143] SA2. Determine the link evaluation value of the target-affected link based on the evaluation values ​​of each of the multiple key performance indicators of the target-affected link.

[0144] SA3. Based on the link evaluation value of the target-affected link and the corresponding preset link threshold, determine whether the target-affected link is an abnormal link;

[0145] Among them, the comprehensive anomaly score for the link based on multi-dimensional performance indicators, i.e., the link evaluation value: ,in: This represents the comprehensive anomaly score for a specific communication link, reflecting the degree of deviation from its overall health status; N represents the number of key performance indicators being monitored. The weights represent the i-th performance metric, used to measure the importance of that metric in the overall health assessment. All weights are... The sum is normalized to 1; Z represents the value of the i-th performance metric.

[0146] Furthermore, when If the preset link threshold is exceeded, the link is considered to have a comprehensive anomaly.

[0147] SA4. If the target-affected link is an abnormal link, then determine the abnormal information of the target-affected link.

[0148] In this embodiment of the application, once a significant anomaly is identified, the anomaly is marked as an anomaly characteristic of the affected link (such as high latency, high error rate, or sudden drop in traffic) in order to obtain the anomaly information of the target-affected link.

[0149] Furthermore, the anomaly characteristics, along with the identifier of the affected link and the deployment event ID, will be structured and output to the rollback policy generation unit of the electronic device for execution of S40.

[0150] S304. Based on the link anomaly information, determine the anomaly characteristics and causes of the abnormal link.

[0151] In this embodiment of the application, the root cause analysis module in the electronic device is used to perform abnormal cause analysis.

[0152] Specifically, upon detecting a link anomaly, a root cause analysis process is immediately initiated. By correlating tracing context information (such as request ID and cross-service call chains) and service log information (such as error logs and exception stacks), the process attempts to pinpoint the specific service component, configuration item, or code change that caused the link anomaly. For example, if the tracing system shows an increase in timeouts for a specific database operation, and the logs contain errors indicating that the database connection pool has been exhausted, combined with the deployment event metadata showing that a new version of the service introduced new database access logic, it can be inferred that the root cause of upstream service call timeouts is a database connection pool leak introduced in the new version of a certain service. Call chain data related to the anomaly link is extracted from the distributed tracing system, including: the time distribution of each service call; the specific error code and error type of the failed call; the service name, instance ID, and version number of each node in the call chain; and the time window and duration of the anomaly. Logs of the affected services within the anomaly time window are retrieved using log aggregation systems (such as ELKStack and Loki), extracting key information: keyword matching of error logs; parsing of exception stack information to identify the specific code location where the anomaly occurred; pattern recognition of warning logs; and trends in log level changes. Obtain deployment event information related to abnormal time windows from the deployment event awareness unit: list of deployed service components and their version numbers; details of configuration changes before and after deployment; code change information; resource quota changes. Obtain more granular performance metrics from the monitoring system: resource usage at the service instance level; database connection pool status; cache hit rate; message queue backlog; JVM metrics.

[0153] Establish the correlation between the anomaly occurrence time window (e.g., from the anomaly start time T1 to the current time T2) and the deployment event timestamp; identify all deployment events and configuration changes that occurred within N minutes (e.g., 5-30 minutes) before the anomaly time window; calculate the time correlation score between the deployment event and the anomaly occurrence: Scoretime = {1.0 if deployment time is within 5 minutes before the anomaly, 0.8 if deployment time is within 5-15 minutes before the anomaly, 0.5 if deployment time is within 15-30 minutes before the anomaly, 0.2 if deployment time is within 30-60 minutes before the anomaly, 0.0 otherwise}; prioritize analyzing deployment events with high time correlation scores.

[0154] Identify abnormal patterns. These include: latency anomaly patterns, analyzing which service node in the call chain experiences the most significant latency spike and identifying the specific operation type causing the spike (e.g., database query, external API call, message queue operation); error rate anomaly patterns, statistically analyzing the error type distribution across service nodes and identifying the most common error types (e.g., 5xx errors, timeout errors, connection errors, business logic errors); resource exhaustion patterns, detecting situations where resource utilization is close to or has reached its limit (e.g., memory utilization > 95%, connection pool exhaustion, thread pool full); configuration error patterns, comparing configuration changes before and after deployment to identify key configuration items that may cause anomalies (e.g., excessively short timeout settings, unreasonable connection pool size settings, incorrect rate limiting threshold settings); and code change impact analysis, analyzing code change summaries to identify change types that may introduce problems (e.g., adding database operations, modifying timeout logic, introducing new external dependencies).

[0155] Based on call chain tracing data, identify the service nodes with the highest latency or error rate in the abnormal chain and mark them as suspected root cause service components. Through comparative analysis, identify configuration items changed within the abnormal time window, especially those related to abnormal characteristics (e.g., timeout configuration is related to latency anomalies, connection pool configuration is related to connection errors). Correlate code change information with the abnormal pattern; for example, if the anomaly manifests as a database operation timeout, and the code change adds a database query operation, the root cause is inferred to be a database operation logic problem in the new code; if the anomaly manifests as a memory overflow, and the code change modifies the caching logic, the root cause is inferred to be a memory leak caused by a change in the caching strategy. Determine whether the anomaly originated from an upstream service or is caused by a problem within the current service itself.

[0156] Comprehensive Root Cause Score: Calculate a comprehensive score for each suspected root cause: Scoreroot_cause = w1⋅Scoretime + w2⋅Scorepattern + w3⋅Scorecorrelation; where: Scoretime represents the time relevance score; Scorepattern represents the anomaly pattern matching score (between 0 and 1, based on the degree of matching between anomaly features and root cause type); Scorecorrelation represents the multi-source data correlation score (between 0 and 1, based on the consistency of call chains, logs, and configuration changes); w1, w2, and w3 are weighting coefficients, and w1 + w2 + w3 = 1.

[0157] The root cause with the highest overall score was selected as the primary root cause, while other high-scoring root causes were retained as alternative root causes.

[0158] Furthermore, the results of root cause analysis (such as the specific error type, affected modules, and suggested repair directions) will serve as important inputs to the rollback strategy generation unit in electronic devices, guiding the generation of more accurate and targeted rollback solutions.

[0159] One possible implementation of this application embodiment is to generate a rollback operation sequence corresponding to the target affected link based on the link topology diagram according to the rollback strategy, including: generating an initial rollback operation sequence corresponding to the target affected link based on the link topology diagram according to the rollback strategy; detecting whether there is an operation conflict in the initial rollback operation sequence; if there is an operation conflict, optimizing the initial rollback operation sequence to obtain a rollback operation sequence.

[0160] In this embodiment of the application, the conflict detection and optimization module of the electronic device is used to detect whether there are potential operation conflicts (such as simultaneously attempting to switch traffic and configure rollback on the same service) during the process of generating the rollback operation sequence.

[0161] If an operational conflict occurs, optimization is performed, including adjusting the operation sequence, merging redundant operations, or adding additional safety checkpoints; the final output is a verified and executable rollback operation sequence.

[0162] Conflicts can be any of the following: resource conflicts, timing conflicts, dependency conflicts, state conflicts, and scope conflicts. Resource conflicts indicate that multiple operations act simultaneously on the same service component or resource, potentially causing mutual interference. Timing conflicts indicate an unreasonable execution order between operations, which may lead to operation failure or side effects. Dependency conflicts indicate circular or contradictory dependencies between operations. State conflicts indicate that the preconditions for operation execution are not met, or that the operation will cause the system to enter an inconsistent state. Scope conflicts indicate overlapping or contradictory impact ranges of operations. Examples include: 1. Executing contradictory operations on different instances of the same service (e.g., some instances switching traffic, some instances restarting); 2. Executing conflicting operation strategies on upstream and downstream services in the same chain.

[0163] Group the operations in the operation sequence according to the target service, and identify all operations that act on the same service; for each service group, check whether there is a resource conflict; define the conflict relationship matrix between operation types: Conflictmatrix[i][j] is 1 if operation type i and operation type j conflict; if operation type i and operation type j do not conflict, Conflictmatrix[i][j] is 0.

[0164] Check the timing of the operation sequence for rationality; check the dependencies between operations for rationality; check for conflicts in the scope of influence of the operations.

[0165] For timing conflicts, adjust the operation order: move operations with unmet preconditions to the end and execute operations that meet preconditions first; move operations that affect the preconditions of subsequent operations forward or backward. For redundant operations, merge them into a single operation; for range conflicts, break down operations into finer-grained operations; for resource conflicts, replace conflicting operations with compatible operations; for unnecessary operations, remove them from the sequence; for potentially risky operations, insert safety checkpoints before and after the operation: insert status check operations before critical operations to verify preconditions, and insert verification operations after critical operations to confirm the operation's effect, etc.

[0166] Specifically, perform conflict detection and generate a conflict list; sort the conflicts by severity (critical conflicts > warning conflicts > informational conflicts); for each conflict, select the corresponding resolution strategy based on the conflict type; apply the resolution strategy and modify the operation sequence; re-execute conflict detection to verify whether the conflict has been resolved; if there are still conflicts, repeat the above steps until all critical and warning conflicts are resolved, or the maximum number of iterations is reached; if there are still conflicts after reaching the maximum number of iterations, mark them as unresolved automatically and require manual intervention.

[0167] One possible implementation of this application embodiment is to execute a corresponding rollback operation based on the component corresponding to each rollback operation in the rollback operation sequence, including: based on distributed transactions and idempotency, executing a corresponding rollback operation based on the component corresponding to each rollback operation in the rollback operation sequence.

[0168] In this embodiment of the application, in order to ensure the atomicity and reliability of the rollback operation, a distributed transaction mechanism (such as two-phase commit, three-phase commit) or an idempotent design is adopted.

[0169] Distributed transactions ensure that all operations in a rollback sequence either succeed entirely or fail entirely and roll back; idempotency guarantees that even if an operation is executed multiple times, its result is the same as if it were executed once, which is crucial for scenarios involving network jitter or retries. Each rollback instruction is assigned a unique transaction ID and idempotency key to track its execution status and prevent duplicate operations.

[0170] As can be seen, in this embodiment, a distributed transaction mechanism (such as two-phase commit or three-phase commit) is used to ensure the atomicity of operations; idempotency design ensures the reliability of operations; and a comprehensive exception handling mechanism is provided, including retry, skipping, or initiating a full rollback. This application ensures the atomicity and reliability of rollback operations through a distributed transaction mechanism or idempotency design. Each rollback instruction is assigned a unique transaction ID and idempotency key to track its execution status and prevent duplicate operations.

[0171] One possible implementation of this application embodiment further includes: real-time monitoring of the execution status and progress of the rollback operation.

[0172] The execution status monitoring and progress tracking module of the electronic device monitors the execution status of each rollback operation in real time, including whether the command was successfully issued, whether the target component received the command, and the execution result of the command. Through continuous polling or event callback mechanisms, the overall progress of the rollback task is updated in real time. All execution status and progress information is recorded in persistent storage for auditing and troubleshooting.

[0173] One possible implementation of this application embodiment further includes: monitoring whether a fault occurs during the rollback operation; if a fault occurs, performing a fault response based on a preset strategy.

[0174] The electronic device's fault handling and recovery module can respond according to a preset strategy if any failure occurs during the rollback operation (such as API call failure, target service unresponsiveness, network timeout).

[0175] Retry: For transient failures, attempt to execute the operation again after a certain delay, until the maximum number of retries is reached;

[0176] Skip: For certain non-critical operations or faults that are determined to be repair-free, you can choose to skip the operation and continue to the next operation in the sequence;

[0177] Initiate full rollback: If a core rollback operation fails and cannot be resolved by retrying or skipping, or if multiple operations fail consecutively, this module may trigger a higher-level contingency plan, such as initiating a full rollback of the entire application to an earlier stable version, or even notifying manual intervention.

[0178] Error codes and detailed error messages from rollback operations will be captured and logged for later analysis.

[0179] The faults include, but are not limited to, network faults, service faults, resource faults, configuration faults, permission faults, data faults, and system faults.

[0180] The system predefines a mapping table (fault handling strategy rule base) between fault types and handling strategies.

[0181] Example of mapping relationship: Rule 1: Fault type is network timeout (a subcategory of network fault) and operation type, corresponding policy is traffic switching, delayed retry (3 retries, 5-second interval); Rule 2: Fault type is target service unresponsive and operation type corresponding policy is traffic switching, policy replace operation (switch to backup version); Rule 3: Fault type is resource not found and operation type corresponding policy is configuration rollback, policy skip operation (configuration item may have been deleted); Rule 4: Fault type is authentication failure and operation type corresponding policy is arbitrary, policy retry immediately (possibly due to temporary token expiration); Rule 5: Fault type is target service error response (HTTP500) and operation type corresponding policy is core operation, policy exponential backoff retry (5 retries, initial 2-second interval); Rule 6: Fault type is 3 consecutive operation failures corresponding policy is policy start overall rollback; Rule 7: Fault type is permission failure and operation type corresponding policy is arbitrary, policy manual intervention (permission issues require manual handling).

[0182] One possible implementation of this application further includes: after completing each rollback operation in the rollback operation sequence, monitoring the key performance indicators of the rolled-back link; comparing the key performance indicators with the baseline performance indicators to determine a first rollback result; obtaining the health status of the rolled-back link, and determining a second rollback result based on the health status; determining whether the rollback was successful based on the first rollback result and the second rollback result; monitoring the status of the rolled-back link to confirm that the system has returned to normal and no new anomalies have occurred.

[0183] The real-time performance metrics acquisition module of the electronic device is activated immediately after the rollback execution coordination unit initiates the rollback operation. It continuously collects key performance metrics of the affected links and their upstream and downstream links from the distributed tracing system, real-time monitoring platform, and health check service. These metrics include, but are not limited to: error rate, request latency, throughput, CPU utilization, memory utilization, network I / O, and connection pool status.

[0184] This module focuses on the recovery of metrics after a rollback to verify its effectiveness. While previous modules used a standard data collection frequency (e.g., every 10-30 seconds), this module uses a higher frequency (once per second in the initial rollback phase) to quickly capture the rollback effect. Previously, primarily affected links were collected; this module collects all affected links and their upstream and downstream links to ensure comprehensive verification.

[0185] The sampling frequency can be dynamically adjusted. In the initial stage of rollback, high-frequency sampling (such as once per second) may be used, and the sampling frequency can be appropriately reduced after the system stabilizes.

[0186] The health check and service status assessment module for electronic devices periodically performs health checks on affected service instances. This is achieved by calling preset health check interfaces for the services (such as / healthz, / actuator / health) to verify whether the service is responding normally and whether dependent databases and caches are reachable. The health check results (second rollback results) include the HTTP status code, response body content, and response time. This module also considers the service instance status in the service registration and discovery system (such as whether it is marked as unhealthy or has been removed).

[0187] The baseline comparison and threshold analysis module of the electronic device compares the collected real-time indicators with pre-established baseline performance data or rollback target states to determine the first rollback result. Baseline performance data can be stable state indicators before deployment or expected normal value ranges defined based on historical data and business SLAs (Service Level Agreements). Statistical methods (such as moving averages and standard deviation analysis) or preset static threshold rules are used to determine whether the current indicators have returned to normal. For example, whether the error rate has dropped below 0.1% or the average latency has recovered to within 50 milliseconds; if the current indicators remain below or above a certain safety threshold within a specific time window, they are considered abnormal.

[0188] The verification result judgment and feedback module of the electronic equipment determines whether the rollback was successful based on the above comparative analysis. If the first rollback result shows no abnormal key performance indicators and the second rollback result shows the link is healthy, then the rollback is considered successful; otherwise, the rollback fails. The judgment result includes success / failure and a specific verification report, indicating which links have returned to normal, which indicators are still abnormal, and the degree of abnormality. For example, if all key indicators have returned to the baseline range and all health checks have passed, the rollback is considered successful. If the verification fails (e.g., the error rate remains high after the rollback), the unit will immediately send feedback information to the rollback execution coordination unit to trigger further diagnosis or the initiation of a backup rollback strategy.

[0189] Failure types for rollback verification include: partial recovery failure, where some metrics return to normal but others remain abnormal (e.g., latency returns to normal, but the error rate remains high); complete recovery failure, where all key metrics fail to return to normal (e.g., both error rate and latency remain abnormal); and metric deterioration, where metrics not only fail to recover after rollback but worsen further (e.g., the error rate increases from 5% to 10%). Check whether each rollback operation was truly executed successfully; verify whether the rollback operation produced the expected effect; and check for any rollback operations that should have been executed but were not.

[0190] The above feedback mechanism forms a closed loop, ensuring the self-correction capability of the rollback process.

[0191] Related technologies lack an effective verification mechanism to confirm whether the rollback truly resolved the problem after execution. This can lead to situations where the problem persists after a rollback, requiring multiple rollback attempts. In this application's embodiment, key performance indicators of the affected links are continuously collected during and after the rollback execution; baseline comparison and threshold analysis are used to determine whether the links have returned to normal; if verification fails, feedback is sent to the rollback execution coordination unit, triggering further diagnostics or alternative rollback strategies. This application ensures the effectiveness of the rollback operation and the stability of system recovery through continuous rollback status verification. The system not only performs the rollback, but more importantly, it confirms whether the rollback truly resolved the problem and returned the affected links to a healthy state. This closed-loop verification mechanism effectively prevents blind or ineffective rollbacks, improving the success rate of fault recovery.

[0192] One possible implementation of this application embodiment can be based on simple verification of a single indicator, such as monitoring only a single indicator like error rate or latency; when the indicator returns to normal, the rollback is determined to be successful; or, based on manual verification, after the system performs the rollback, it notifies the operation and maintenance personnel; the operation and maintenance personnel confirm whether the rollback is successful.

[0193] One possible implementation of this application embodiment further includes: after a successful rollback, continuously monitoring the key performance indicators of the rolled-back link and the health status of the rolled-back link to perform long-term trend monitoring.

[0194] Even if the rollback verification is successful, the long-term trend monitoring module of the electronic device will continue to monitor the relevant links at a low frequency for a period of time to capture potential delay effects or hidden problems and ensure the stable operation of the system over a long period of time.

[0195] Based on any of the above embodiments, the purpose of this application is to provide a link-level application rollback acceleration method, see figure. Figure 2 , Figure 2 This application provides a core principle and process framework for a link-level application rollback acceleration method, which includes steps such as continuously monitoring deployment and configuration change events, capturing events and extracting metadata, dynamically building and maintaining link topology, intelligently assessing deployment impact and identifying anomalies, automatically generating link-level rollback strategies, accurately scheduling and executing rollback operations, continuously monitoring and verifying rollback effectiveness, and restoring the system to normal operating state, as well as the process relationships between them. Figure 3This is a schematic diagram comparing the core principle of this application with related technologies in terms of average fault recovery time, as provided in the embodiments of this application, illustrating that this application can significantly shorten the fault recovery time.

[0196] This application can accurately identify communication links affected by new deployments through link topology modeling and anomaly impact analysis, thereby enabling refined rollback operations and minimizing the scope of impact. Based on the characteristics and root causes of the anomaly impact, it automatically generates link-level rollback operation sequences, such as traffic switching, configuration rollback, or data compensation, minimizing the need for manual intervention. Figure 4 This application provides a framework for the structure and classification of link-level fine-grained rollback strategies, including traffic switching strategy templates, configuration rollback strategy templates, service instance management strategy templates, and data compensation strategy templates. Through automated anomaly detection, strategy generation, and execution coordination, the average time from problem discovery to system recovery is reduced by more than 70%. Continuous rollback status verification ensures that the rollback operation truly resolves the problem and returns affected links to a healthy state. Distributed transactions and idempotency design ensure the atomicity and reliability of rollback operations, avoiding data inconsistency.

[0197] Based on any of the above embodiments, the following are specific application embodiments provided by this application.

[0198] Example 1: Rollback Scenario in E-commerce Platform Order Processing Chain. Scenario Description: In a distributed system of an e-commerce platform, order processing involves multiple microservices such as order service, inventory service, payment service, and logistics service. After a new version of the order service is deployed, the system detects an anomaly in the chain from the order service to the inventory service.

[0199] System operation process:

[0200] 1. Deployment event awareness. The system detected a deployment event for Order Service version v2.0.0; captured deployment metadata: version number v2.0.0, deployment time 2024-01-01 10:00:00, and the changed service component [Order Service].

[0201] 2. Link Topology Modeling. The link topology diagram maintained by the system shows: Order Service → Inventory Service → Payment Service → Logistics Service; the link from the Order Service to the Inventory Service (link-order-inventory) is identified.

[0202] 3. Anomaly Impact Analysis. The system monitored anomalies in the link-order-inventory link after deployment: request latency increased from an average of 50ms to 500ms (Z-score=9.0, exceeding the threshold of 2.0), and the error rate increased from 0.1% to 5% (Z-score=4.9, exceeding the threshold of 2.0). The overall anomaly score was 0.6×9.0+0.4×4.9=7.36 (exceeding the threshold of 5.0). Root Cause Analysis: Log analysis revealed that the new version of the order service introduced a database connection pool configuration error, leading to connection pool exhaustion and consequently affecting calls to the inventory service.

[0203] 4. Rollback Policy Generation. The system matches the configuration rollback policy template based on the anomaly characteristics (high latency, high error rate) and root cause (configuration error). The rollback operation sequence is generated as follows: Operation 1: Roll back the database connection pool configuration of the order service from the new value to the old value; Operation 2: Restart the order service instance to apply the new configuration. Since the order service is an upstream service, it is necessary to roll back the order service first before verifying the downstream service.

[0204] 5. Rollback Execution Coordination. The system calls the configuration center API to roll back the database connection pool configuration of the order service from maxConnections=100 to maxConnections=50. It then calls the Kubernetes API to restart the Pod instance of the order service; all operations are executed within a distributed transaction to ensure atomicity.

[0205] 6. Rollback Status Verification. The system continuously monitors the performance metrics of the link-order-inventory link; after 5 minutes, the metrics return to normal: request latency returns to an average of 50ms, error rate returns to 0.1%, the system determines that the rollback was successful, and the link returns to normal.

[0206] Performance Comparison: Traditional full rollback method: Requires rolling back the entire order service cluster, taking approximately 10 minutes and affecting all order processing requests. This application's link-level rollback method: Only rolls back the order service configuration, taking approximately 2 minutes, minimizing the impact and reducing the mean time to failure (MTTR) by 80%.

[0207] Example 2: Rollback Scenario for Multiple Downlink Anomalies in a Microservice Architecture. Scenario Description: In a complex microservice system, the deployment of a new version of the user service causes anomalies in multiple downstream links.

[0208] System operation process:

[0209] 1. Deployment Event Awareness. The system detected a deployment event for User Service version v3.0.0. Deployment metadata was captured: version number v3.0.0, deployment time 2024-01-02 14:00:00, and the changed service component [User Service].

[0210] 2. Link Topology Modeling. The link topology diagram maintained by the system shows: User Service → Order Service → Payment Service; User Service → Recommendation Service → Content Service; User Service → Message Service.

[0211] 3. Anomaly Impact Analysis. The system identified three links that the user service deployment might affect: link-user-order (user service → order service), link-user-recommend (user service → recommendation service), and link-user-message (user service → message service).

[0212] Monitoring revealed the following issues: link-user-order link anomaly: latency increased by 200%, error rate increased by 10%; link-user-recommend link anomaly: latency increased by 150%, error rate increased by 5%; link-user-message link was normal.

[0213] Root cause analysis: The new version of the user service introduced performance issues when processing user authentication, affecting downstream services that require authentication.

[0214] 4. Rollback Policy Generation. Based on anomaly characteristics and root causes, the system matches a traffic switching policy template and generates a rollback operation sequence: Operation 1: Switch traffic on the link-user-order link from v3.0.0 to v2.9.0 (100% switch); Operation 2: Switch traffic on the link-user-recommend link from v3.0.0 to v2.9.0 (100% switch); Operation 3: Keep traffic on the link-user-message link unchanged (because this link is normal). Based on dependencies, links with fewer downstream dependencies are switched first, followed by links with more downstream dependencies.

[0215] 5. Rollback execution coordination. The system calls the load balancer API to perform traffic switching operations. All operations are completed within 30 seconds. Idempotency design ensures that the operations can be repeated.

[0216] 6. Rollback Status Verification. The system continuously monitors the performance metrics of the three links. After 3 minutes, the link-user-order and link-user-recommend links returned to normal. The link-user-message link remained normal. The system determined that the rollback was successful.

[0217] Performance Comparison: Traditional full rollback method: Requires rolling back the entire user service cluster, takes about 15 minutes, and affects all user service-related requests. This application's link-level rollback method: Only rolls back the traffic of the abnormal link, takes about 3 minutes, does not affect the normal message service link, and reduces the mean time to failure (MTTR) by 80%.

[0218] Example 3: Scenario of Link Anomaly Rollback Due to Configuration Error. Scenario Description: In a distributed system, a configuration item in the configuration center is incorrectly modified, causing link anomalies in multiple services.

[0219] System operation process:

[0220] 1. Deploy event awareness. The system detected a configuration change event: the database connection string configuration was modified. It captured the configuration change metadata: configuration key `database.connection.string`, old value `jdbc:mysql: / / db1:3306 / app`, new value `jdbc:mysql: / / db2:3306 / app`, and change time `2024-01-03 09:00:00`.

[0221] 2. Link Topology Modeling. The system identifies the services using this configuration: Order Service, Inventory Service, and Payment Service. The link topology diagram shows that these services all depend on the Database Service.

[0222] 3. Anomaly Impact Analysis. The system monitored multiple links experiencing anomalies: Order service to database link: 100% connection failure rate; Inventory service to database link: 100% connection failure rate; Payment service to database link: 100% connection failure rate. Root cause analysis: The newly configured database address was incorrect, causing all services to be unable to connect to the database.

[0223] 4. Rollback Policy Generation. The system matches the configuration rollback policy template based on the anomaly characteristics (connection failure) and root cause (configuration error). The rollback operation sequence is generated as follows: Operation 1: Roll back the database.connection.string configuration to its old value; Operation 2: Notify all services using this configuration to reload the configuration (no service restart required, supports hot updates).

[0224] 5. Rollback execution coordination. The system calls the configuration center API to roll back the configuration to the old values. Through the configuration push mechanism, all relevant services are notified to reload the configuration. All operations are completed within 1 minute.

[0225] 6. Rollback Status Verification. The system continuously monitors the performance metrics of the relevant links. After 2 minutes, all links return to normal: the connection failure rate returns to 0%, the service response time returns to normal, and the system determines that the rollback was successful.

[0226] Performance Comparison: Traditional manual rollback method: requires manual identification of configuration errors, manual modification of configuration, and service restart, taking approximately 30 minutes. This application's automated rollback method: automatically detects anomalies, automatically rolls back the configuration, and automatically verifies, taking approximately 3 minutes, reducing the mean time to failure (MTTR) by 90%.

[0227] The following describes a device provided by an embodiment of this application. The device described below can be referred to in correspondence with the method described above. The device of this embodiment is installed in an electronic device. Figure 5 , Figure 5 This is a structural block diagram of the rollback device provided in this application embodiment, including: a deployment event sensing unit 101, used to acquire metadata of new deployment events; a link topology modeling unit 102, used to acquire a communication link topology diagram between services; an anomaly impact analysis unit 103, used to determine the anomaly characteristics and causes of anomalies based on the information of the services involved in the new deployment event in the metadata, the communication link topology diagram, and real-time link performance data; a rollback strategy generation unit 104, used to determine a rollback strategy based on the anomaly characteristics and causes; and generate a rollback operation sequence corresponding to the target affected link using the link topology diagram based on the rollback strategy; and a rollback execution coordination unit 105, used to execute corresponding rollback operations according to the components corresponding to each rollback operation in the rollback operation sequence.

[0228] In one feasible implementation, the anomaly impact analysis unit 103 includes: an event and topology correlation analysis module, used to determine at least one impacting link based on information about the services involved in the new deployment event in the metadata and the communication link topology diagram; a key performance indicator acquisition and baseline establishment module, used to acquire real-time link performance data, which includes key performance indicators of at least one impacting link before and after deployment; an anomaly detection module, used to evaluate the target impacting link based on the real-time link performance data and obtain link anomaly information of the target impacting link; the link anomaly information includes: anomaly characteristics, whether the target impacting link is an anomaly link, and the anomaly cause when the target impacting link is an anomaly link; the target impacting link is any link among at least one impacting link; and a root cause analysis module, used to determine the anomaly characteristics and anomaly cause of the anomaly link based on the link anomaly information.

[0229] In one feasible implementation, the anomaly detection module is configured to: determine the evaluation values ​​of multiple key performance indicators of the target affected link based on the performance data of the target affected link from real-time link performance data; determine whether the target key performance indicator is an anomaly based on the evaluation values ​​of the target key performance indicators of the target affected link, wherein the target key performance indicator is any one of the multiple key performance indicators; determine the link evaluation value of the target affected link based on the evaluation values ​​of the multiple key performance indicators of the target affected link; determine whether the target affected link is an abnormal link based on the link evaluation value of the target affected link and the corresponding preset link threshold; and if the target affected link is an abnormal link, determine the anomaly information of the target affected link.

[0230] In one feasible approach, the link topology modeling unit 102 is used to: continuously acquire service instance information of all registered services; perform real-time parsing of network traffic logs in the distributed system to obtain the actual communication patterns between services, which represent the call information and communication information between services; acquire complete call chain data between services; and construct a communication link topology diagram between services based on the service instance information, the actual communication patterns between services, and the complete call chain data.

[0231] In one possible implementation, the rollback strategy generation unit 104 includes: a dependency parsing and sequence generation module, used to generate an initial rollback operation sequence corresponding to the target affected link based on the rollback strategy and the link topology diagram; and a conflict detection and optimization module, used to detect whether there is an operation conflict in the initial rollback operation sequence; if there is an operation conflict, the initial rollback operation sequence is optimized to obtain a rollback operation sequence.

[0232] In one possible implementation, the rollback execution coordination unit 105 is used to: execute the corresponding rollback operation based on the component corresponding to each rollback operation in the rollback operation sequence, using a distributed transaction and idempotency approach.

[0233] In one possible implementation, it also includes: a progress monitoring unit, used to monitor the execution status and progress of the rollback operation in real time; monitor whether a fault occurs during the rollback operation; and if a fault occurs, respond to the fault based on a preset strategy.

[0234] The rollback status verification unit 106 includes: a real-time performance indicator acquisition module, used to monitor the key performance indicators of the rolled-back link after each rollback operation in the rollback operation sequence; a health check and service status assessment module, used to obtain the health status of the rolled-back link; a baseline comparison and threshold analysis module, used to compare the key performance indicators with the baseline performance indicators to determine the first rollback result; and based on the health status, to determine the second rollback result; a verification result judgment and feedback module, used to determine whether the rollback was successful based on the first and second rollback results; and a long-term trend monitoring module, used to continuously monitor the key performance indicators and health status of the rolled-back link after a successful rollback for long-term trend monitoring.

[0235] Further, see Figure 6 , Figure 6 This application provides an overall technical architecture for a link-level application rollback acceleration system, including a deployment event awareness unit, a link topology modeling unit, an anomaly impact analysis unit, a rollback policy generation unit, a rollback execution coordination unit, a rollback status verification unit, a rollback policy rule management unit, and a rollback history auditing unit, as well as the connections between them.

[0236] The deployment event awareness unit 101 is used to continuously monitor application deployment activities and accompanying configuration change events in the distributed system, and capture metadata related to these events. The deployment event awareness unit 101 includes: an event listener for continuously listening to preset callback interfaces or WebHooks in the CI / CD toolchain; a metadata extractor for parsing structured metadata from event notifications; a configuration change capture module for listening to configuration update events in the configuration management system; and a data structuring and push module for standardizing the captured event data and pushing it to a message queue.

[0237] Link topology modeling unit 102 is used to dynamically construct and maintain in real time the communication link topology diagram and inter-service dependencies among various application services in the distributed system. Link topology modeling unit 102 includes: a service registration and discovery data acquisition module for obtaining information on all registered service instances; a network traffic log parsing module for parsing network traffic logs and identifying inter-service communication patterns; an inter-service call chain tracing data aggregation module for aggregating call chain data from the distributed tracing system; an explicit dependency configuration parsing module for parsing explicitly declared inter-service dependencies; and a graph model construction and update engine for constructing and maintaining a directed graph model and periodically updating the topology diagram.

[0238] The anomaly impact analysis unit 103 receives deployment metadata captured by the deployment event awareness unit, and combines it with topology information provided by the link topology modeling unit and real-time link performance indicators obtained from system monitoring to analyze the impact of the new deployment on the health of the communication links and identify the anomaly characteristics of the affected links. A schematic diagram of the internal structure of the anomaly impact analysis unit 103 is shown below. Figure 7 As shown, Figure 7 This application provides a logical flow framework for an anomaly impact analysis unit, including an event and topology correlation analysis module, a key performance indicator collection and baseline establishment module, an anomaly detection module, an anomaly feature marking and output module, and a root cause analysis module, as well as the processing flow relationships between them. Specifically, the event and topology correlation analysis module is used to determine the set of direct and indirect communication links that may be affected by this deployment; the key performance indicator collection and baseline establishment module is used to collect link performance indicators and establish baselines; the anomaly detection module is used to identify anomalies using statistical analysis methods or machine learning models; the anomaly feature marking and output module is used to mark anomalies as anomaly features of the affected links; and the root cause analysis module is used to locate the specific service components, configuration items, or code changes that caused the link anomalies.

[0239] The rollback strategy generation unit generates a refined, link-level rollback operation sequence based on the affected links and anomaly characteristics identified by the anomaly impact analysis unit. A schematic diagram of the internal structure of the rollback strategy generation unit is shown below. Figure 8 , Figure 8 This application provides a logical flow framework for a rollback strategy generation unit, including an input receiving and parsing module, a rollback strategy rule matching engine, a dependency parsing and sequence generation module, and a conflict detection and optimization module, as well as the processing flow relationships between them. The rollback strategy generation unit includes: an input receiving and parsing module for receiving and parsing the output of the anomaly impact analysis unit; a rollback strategy rule matching engine for selecting or combining matching rollback templates based on the rollback strategy rule base; a dependency parsing and sequence generation module for generating an ordered rollback operation sequence based on the dependencies of the affected links; and a conflict detection and optimization module for detecting operation conflicts and performing optimization.

[0240] The rollback policy rule base includes: traffic switching policy templates for switching traffic from a faulty version to a stable version; configuration rollback policy templates for restoring configurations to their pre-deployment state; service instance management policy templates for isolating, restarting, or replacing abnormal service instances; and data compensation policy templates for performing data repair or compensation operations.

[0241] The rollback execution coordination unit 105 receives the rollback operation sequence generated by the rollback strategy generation unit and is responsible for scheduling and executing these rollback operations in the distributed system to restore the normal state of the affected links. The rollback execution coordination unit 105 includes: a rollback instruction parsing module for parsing the rollback operation sequence and converting it into low-level instructions; a distributed command distribution module for distributing instructions to corresponding components or platforms for execution; a distributed transaction and idempotency guarantee module for ensuring the atomicity and reliability of the rollback operations; an execution status monitoring and progress tracking module for real-time monitoring of the execution status and progress of the rollback operations; and an exception handling and recovery module for handling exceptions during execution.

[0242] The rollback status verification unit 106 is used to continuously monitor the performance and health indicators of the affected links and related services after the rollback execution coordination unit performs the rollback operation, in order to verify the effectiveness of the rollback and the stability of the system.

[0243] The internal structure diagram of the rollback state verification unit 106 is shown below. Figure 9 , Figure 9 This application provides a logical flow framework for a rollback status verification unit, including a real-time performance indicator acquisition module, a health check and service status assessment module, a baseline comparison and threshold analysis module, a verification result judgment and feedback module, and a long-term trend monitoring module, as well as the processing flow relationships between them. The rollback status verification unit 106 includes: a real-time performance indicator acquisition module for continuously acquiring key performance indicators of the affected links; a health check and service status assessment module for periodically performing health checks on service instances; a baseline comparison and threshold analysis module for comparing and analyzing real-time indicators with baselines; a verification result judgment and feedback module for determining whether the rollback was successful and sending feedback; and a long-term trend monitoring module for continuously monitoring the long-term trends of the relevant links.

[0244] The rollback policy rule management unit provides a user interface or API for system administrators or operations personnel to define, edit, and maintain rollback policy rules. It includes: a rule definition and editing module (providing a user interface or API to allow users to create and edit rollback policy rules); a rule version management module (supporting version management of rollback policy rules); a rule approval and release process module (supporting the rule approval process); a conflict detection and priority management module (detecting rule conflicts and managing priorities); and a rule dynamic loading and unloading module (supporting the dynamic loading or unloading of rules without interrupting system operation).

[0245] The rollback history audit unit records every deployment event, anomaly detection results, generated rollback policies, execution process, and final rollback results and verification reports. The rollback history audit unit includes: an event data collection and archiving module, which continuously receives and archives data from various units; a data storage and indexing module, which stores audit data in a persistent storage system and creates indexes; a query and report generation module, which provides query interfaces and generates visual reports; a compliance and security assurance module, which ensures the traceability and security of audit data; and a performance analysis and optimization feedback module, which continuously optimizes rollback policies through analysis of historical data.

[0246] The diagram illustrating the interaction and data flow between the various functional units of the system is as follows: Figure 10 , Figure 10 This application provides an embodiment that illustrates the data flow and interaction relationships between various units within a link-level application rollback acceleration system, including the data transmission relationships and feedback mechanisms between the units.

[0247] Figure 11 A structural diagram of an electronic device provided in an embodiment of this application, such as... Figure 11 As shown, the electronic device includes: a memory 60 for storing a computer program; and a processor 61 for executing the computer program to implement the steps of the method as described in the above embodiments.

[0248] The processor 61 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 61 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 61 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 61 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 61 may also include an Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.

[0249] The memory 60 may include one or more computer-readable storage media, which may be non-transitory. The memory 60 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 60 is used to store at least the following computer program 601, which, after being loaded and executed by the processor 61, is capable of implementing the relevant steps of the method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 60 may also include an operating system 602 and data 603, etc., and the storage method may be temporary storage or permanent storage. The operating system 602 may include Windows, Unix, Linux, etc.

[0250] In some embodiments, the electronic device may further include a display screen 62, an input / output interface 63, a communication interface 64, a power supply 65, and a communication bus 66.

[0251] Those skilled in the art will understand that Figure 11 The structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.

[0252] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the current technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, magnetic disks, or optical disks, and other media capable of storing program code.

[0253] Based on this, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the method described above.

[0254] Based on this, embodiments of this application also provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the above-described method. It should be understood that although the steps in the flowcharts of the accompanying drawings are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying drawings may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0255] The above are only some embodiments of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A rollback method, characterized in that, include: Retrieve metadata for new deployment events; Obtain the communication link topology diagram between each service; wherein the communication link topology diagram adopts an incremental update strategy and is updated periodically to reflect the dynamic changes of service scaling up and down, service migration, and link establishment or disconnection; Based on the information of the services involved in the new deployment events in the metadata, the communication link topology diagram, and the real-time link performance data, determine the abnormal characteristics and causes of the abnormal links. Based on the anomaly characteristics and causes, determine the rollback strategy; based on the rollback strategy, use the link topology diagram to generate the rollback operation sequence; Execute the corresponding rollback operation based on the component corresponding to each rollback operation in the rollback operation sequence; Based on the information of the services involved in the new deployment event in the metadata, the communication link topology diagram, and real-time link performance data, determine the abnormal characteristics and causes of the abnormal links, including: Based on the information of the services involved in the new deployment event in the metadata and the communication link topology, at least one influencing link is identified; the influencing link includes direct links and indirect communication links. A direct influencing link represents a link that is directly communicated by the deployed service; an indirect influencing link represents a link that is affected through layers of dependencies. Acquire real-time link performance data, which includes at least one key performance indicator that affects the link before and after deployment. Based on real-time link performance data, the target affected link is evaluated to obtain link anomaly information of the target affected link; the link anomaly information includes: anomaly characteristics, whether the target affected link is an abnormal link, and the anomaly reason when the target affected link is an abnormal link; the target affected link is any link among the at least one affected link; Based on the link anomaly information, determine the anomaly characteristics and causes of the abnormal link.

2. The method according to claim 1, characterized in that, Based on real-time link performance data, the impact of the target link is assessed, and link anomaly information of the impacted link is obtained, including: Based on the performance data of the target link affected by the real-time link performance data, determine the evaluation values ​​of each of the multiple key performance indicators of the target link affected by the link. Based on the evaluation value of the target key performance indicator of the target impact link, determine whether the target key performance indicator is an abnormal feature. The target key performance indicator is any one of multiple key performance indicators. Based on the evaluation values ​​of the various key performance indicators of the target-affected link, the link evaluation value is determined. Based on the link evaluation value of the target affected link and the corresponding preset link threshold, it is determined whether the target affected link is an abnormal link; If the target impact link is an abnormal link, then the abnormal information of the target impact link is determined.

3. The method according to claim 1, characterized in that, Obtain the communication link topology diagram between various services, including: Continuously obtain service instance information for all registered services; Real-time parsing of network traffic logs in a distributed system yields the actual communication patterns between services, which represent the call information and communication information between services. Obtain the complete call chain data between services; Based on the service instance information, the actual communication mode between services, and the complete call chain data, construct a communication link topology diagram between the services.

4. The method according to claim 1, characterized in that, Based on the rollback strategy, a rollback operation sequence is generated using the link topology diagram, including: Based on the rollback strategy, the initial rollback operation sequence corresponding to the target affected link is generated using the link topology diagram; Detect whether there are operation conflicts in the initial rollback operation sequence; If an operational conflict exists, the initial rollback operation sequence is optimized to obtain a rollback operation sequence.

5. The method according to claim 1, characterized in that, Based on the component corresponding to each rollback operation in the rollback operation sequence, perform the corresponding rollback operation, including: Based on distributed transactions and idempotency, the corresponding rollback operation is executed according to the component corresponding to each rollback operation in the rollback operation sequence.

6. The method according to any one of claims 1 to 5, characterized in that, Also includes: Monitor the execution status and progress of rollback operations in real time.

7. The method according to any one of claims 1 to 5, characterized in that, Also includes: Monitor for any failures during the rollback operation; If a fault occurs, a fault response will be initiated based on a preset strategy.

8. The method according to any one of claims 1 to 5, characterized in that, Also includes: After each rollback operation in the rollback sequence is completed, monitor the key performance indicators of the link after the rollback. Compare key performance indicators with baseline performance indicators to determine the first rollback result; Obtain the health status of the link after rollback, and determine the second rollback result based on the health status; Based on the first rollback result and the second rollback result, determine whether the rollback was successful.

9. The method according to any one of claims 1 to 5, characterized in that, Also includes: After a successful rollback, the key performance indicators and health status of the rolled-back link are continuously monitored to conduct long-term trend monitoring.

10. A rollback device, characterized in that, include: Deployment event awareness unit, used to obtain metadata of new deployment events; The link topology modeling unit is used to obtain the communication link topology diagram between various services; wherein, the communication link topology diagram adopts an incremental update strategy and is updated periodically to reflect the dynamic changes of service scaling up and down, service migration, and link establishment or disconnection. The anomaly impact analysis unit is used to determine the anomaly characteristics and causes of the anomaly based on the information of the services involved in the new deployment event in the metadata, the communication link topology diagram, and the real-time link performance data. The rollback strategy generation unit is used to determine the rollback strategy based on the anomaly characteristics and causes; and to generate a rollback operation sequence based on the rollback strategy using the link topology diagram. The rollback execution coordination unit is used to execute the corresponding rollback operation according to the component corresponding to each rollback operation in the rollback operation sequence; The abnormal impact analysis unit includes: The event and topology association analysis module is used to determine at least one influencing link based on the information of the services involved in the new deployment event and the communication link topology diagram in the metadata. The influencing link includes direct links and indirect communication links. Directly influencing links represent links that are directly communicated by the deployed services. Indirectly influencing links represent links that are affected through the hierarchical transmission of dependencies. The key performance indicator collection and baseline establishment module is used to acquire real-time link performance data, which includes at least one key performance indicator that affects the link before and after deployment. An anomaly detection module is used to evaluate the target affected link based on real-time link performance data and obtain the link anomaly information of the target affected link; the link anomaly information includes: anomaly characteristics, whether the target affected link is an abnormal link, and the anomaly reason when the target affected link is an abnormal link; the target affected link is any link among the at least one affected link; The root cause analysis module is used to determine the abnormal characteristics and causes of abnormal links based on the link anomaly information.

11. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the method according to any one of claims 1 to 9 when running the computer program.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one piece of program code, which is loaded and executed by a processor to implement the method as described in any one of claims 1 to 9.

Images