A fault isolation and rapid recovery system based on microservice architecture
By integrating automated fault detection, intelligent grayscale release, fault isolation and rapid recovery strategies in the microservice architecture, the problems of fault spread and rapid recovery under the microservice architecture are solved, and the stability and availability of the system are improved.
Patent Information
- Application Number
- CN202411575375.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-06
- Publication Date
- 2025-04-08
AI Technical Summary
Under the microservice architecture, how to effectively identify and isolate fault modules when system grayscale is released, prevent fault spread, and achieve rapid recovery.
By integrating automated fault detection and identification technology, intelligent grayscale release mechanism, fault service isolation and rapid recovery strategies, and flexible microservice design, efficient fault management and system recovery are achieved. Specifically, it includes automatic fault detection and identification, intelligent grayscale release, fault isolation technology, serverless call rollback mechanism and elastic microservice design.
It significantly improves the stability, flexibility and maintainability of the system, effectively reduces the impact of system failures on business operations, and ensures the continuity and high availability of services.
Smart Images

Figure CN119782013A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer science and information technology, and in particular to a fault isolation and rapid recovery system based on a microservice architecture. Background Art
[0002] With the widespread application of cloud computing and microservice architecture, system architecture is gradually developing in the direction of distribution and modularization. Microservice architecture divides the application into a group of small services, each of which runs in its own independent process and interacts through lightweight communication protocols. Although this architecture provides great flexibility and scalability, it also introduces complex system management problems. When a component of an application fails, if it cannot be effectively isolated and recovered, it may cause the entire system to crash.
[0003] In modern application deployment, grayscale release is a method of gradually releasing new versions and is widely used in actual production environments. In this process, the new version is first released to a small number of users and then promoted to all users. This gradual approach can minimize the impact caused by new version failures. However, this approach relies on reliable fault detection, isolation, and rapid recovery mechanisms to ensure system stability and availability.
[0004] The technical problems to be solved by the present invention are:
[0005] The present invention aims to solve the problem of fault propagation during grayscale release of the system under the microservice architecture and improve the rapid recovery capability of the system. The specific technical problems to be solved include:
[0006] 1. How to effectively identify faulty modules in a microservice architecture.
[0007] 2. How to effectively isolate the faulty module from other modules to prevent the fault from spreading.
[0008] 3. How to quickly restore the system to normal operation after a fault is discovered.
[0009] 4. How to design a coordination mechanism between different modules to ensure service continuity and minimize the impact of failures.
[0010] 5. How to design the overall system architecture to support fault isolation and rapid recovery capabilities. Summary of the invention
[0011] The present invention relates to a fault isolation and rapid recovery system based on microservice architecture, which aims to improve the robustness and availability of the system and ensure the continuity and stability of services. By integrating automated fault detection and identification technology, intelligent grayscale release mechanism, fault service isolation and rapid recovery strategy, and flexible microservice design, the system can achieve efficient and reliable fault management and system recovery in complex and changeable production environments.
[0012] Specifically, the system includes the following core functional modules:
[0013] Automatic fault detection and identification: By analyzing various operating indicators of microservices (such as CPU usage, memory usage, response time, etc.) and log data, using machine learning algorithms to identify abnormal behaviors, using Prometheus for data collection, ElasticSearch for log storage and analysis, and Grafana for data visualization and configuration of alarm rules, the operating status of microservices is monitored in real time to achieve automatic fault detection and identification.
[0014] Intelligent grayscale release: Based on containerization technology and Kubernetes cluster, new versions of applications are gradually released in grayscale, the running status of new version Pods is monitored in real time, and a blue-green deployment strategy is adopted to achieve dynamic traffic switching through Kubernetes Ingress resources to ensure the stability and performance of the system during the new version release process.
[0015] Fault isolation technology: By using service meshes (such as Istio), traffic control for faulty services is implemented, fuses and current limiting policies are deployed to prevent the spread of faults, and Kubernetes' automatic expansion policies are used to increase the number of healthy Pods, thereby quickly isolating faults and reducing their impact on the system.
[0016] Serverless call rollback mechanism: By utilizing Kubernetes' Deployment and Service resources, when a failure is detected, the failed Pod is replaced with a stable version by executing the rollback operation in the CI / CD process to achieve rapid system recovery and ensure service continuity and high availability.
[0017] Elastic microservice design: All microservices are designed to be stateless and self-contained so that when a failure occurs, the problem instance can be quickly replaced without affecting other services. Load balancing is used to distribute requests, and Kubernetes's HPA (Horizontal Pod Autoscaler) is used to automatically expand or reduce the number of instances based on traffic, and dynamic calls between services are achieved through service registration and discovery mechanisms (such as Eureka and Consul).
[0018] Real-time monitoring and alarm system: Build a centralized monitoring platform, use tools such as Prometheus and Grafana to collect and monitor the operating indicators of each microservice, manage logs through ElasticSearch and Fluentd, configure alarm rules, and integrate communication tools such as Slack and email to notify the operation and maintenance team in real time to ensure that problems can be discovered and handled in a timely manner.
[0019] Fault analysis and recovery log system: The system records detailed fault handling logs and recovery operation logs, including the discovery time, type, handling operation and recovery time of each fault, automatically tracks and records all recovery scripts and processes, and integrates issue tracking systems (such as JIRA) to facilitate post-fault analysis of fault causes and continuous improvement of fault recovery processes.
[0020] Continuous Integration / Continuous Deployment (CI / CD) process: Build an automated CI / CD process to ensure the quality and reliability of new versions. This includes code submission triggering, automated testing, automatic deployment, and quality inspection. Through dynamic routing and traffic management, human operation errors can be reduced and release efficiency can be improved.
[0021] Through the above-mentioned multiple technical measures, the present invention significantly improves the stability, flexibility and maintainability of the system, is suitable for complex and changeable production environments, and effectively reduces the impact of system failures on business operations.
[0022] Beneficial effects of the present invention:
[0023] The fault isolation and recovery technical solution provided by the present invention can effectively identify and isolate faulty modules quickly during the grayscale release process and achieve rapid recovery of the system. By adopting containerization technology and microservice architecture design, the robustness and availability of the system are greatly improved, the risk of fault propagation is reduced, and the continuity of services is ensured. At the same time, the automated grayscale release and rollback process also reduces the error probability of manual operation and improves operation and maintenance efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0024] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings in the following description are only for the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0025] Figure 1 It is a schematic diagram of the overall flow of the system in the present invention. DETAILED DESCRIPTION
[0026] The present invention is described in detail below in conjunction with the accompanying drawings and specific embodiments. At the same time, it is explained here that in order to make the embodiments more detailed, the following embodiments are the best and preferred embodiments, and those skilled in the art may also adopt other alternatives to implement some known technologies; and the accompanying drawings are only for more specific description of the embodiments, and are not intended to specifically limit the present invention.
[0027] It should be noted that the references to "one embodiment", "an embodiment", "an exemplary embodiment", "some embodiments" and the like in the specification indicate that the embodiments described may include specific features, structures or characteristics, but not every embodiment may include the specific features, structures or characteristics. In addition, when a specific feature, structure or characteristic is described in conjunction with an embodiment, it should be within the knowledge of a person skilled in the art to implement such feature, structure or characteristic in conjunction with other embodiments (whether or not explicitly described).
[0028] In general, a term can be understood, at least in part, from its use in context. For example, depending, at least in part, on the context, the term "one or more" as used herein can be used to describe any feature, structure, or characteristic in the singular sense, or can be used to describe a combination of features, structures, or characteristics in the plural sense. Additionally, the term "based on" can be understood as not necessarily intended to convey an exclusive set of factors, but can instead, depending, at least in part, on the context, allow for the presence of other factors that are not necessarily explicitly described.
[0029] Example 1
[0030] A fault isolation and rapid recovery system based on microservice architecture, the collective awareness method is as follows:
[0031] 1. Automatic fault detection mechanism
[0032] Function description: Monitor the operation status of microservices in real time and automatically identify faults.
[0033] detail:
[0034] Use Prometheus to collect the operating indicators of each microservice (CPU usage, memory usage, response time, etc.).
[0035] Use ElasticSearch to store and analyze log data.
[0036] Based on Grafana visualization monitoring data, configure alarm rules to notify the operation and maintenance team in real time.
[0037] Use machine learning algorithms (e.g., time series anomaly detection algorithms) to analyze indicator data and automatically identify abnormal behavior.
[0038] Example:
[0039] Suppose an order service encounters performance issues after a new version is released, causing a sharp increase in response time. Prometheus monitors these indicators abnormally, and an alarm is immediately displayed on the Grafana dashboard, and an alarm notification is sent to the operation and maintenance team, who confirms the abnormality after verifying the fault.
[0040] 2. Intelligent grayscale release mechanism
[0041] Function description: Gradually release the new version of the application in grayscale and monitor the status of the new version in real time.
[0042] detail:
[0043] Use Docker to containerize the new version of the application and deploy it on a Kubernetes cluster.
[0044] Use Kubernetes' Blue-Green Deployment strategy to deploy the new version to a new Deployment resource.
[0045] Dynamic switching of traffic routing is achieved through Kubernetes Ingress resources.
[0046] Monitor the running status of the new version of Pod in real time, including logs, indicators, and system load.
[0047] Example:
[0048] Assume that before a new version of an application is released, a Docker image is first built and a Deployment named A is deployed on Kubernetes. Kubernetes Ingress directs part of the traffic to the new version Pod based on the request header (such as user group or geographic region). The monitoring system determines the health status of the new version Pod based on its performance indicators.
[0049] 3. Fault isolation technology
[0050] Function description: When a fault is detected, quickly isolate the faulty service to avoid affecting the entire system.
[0051] detail:
[0052] Use a service mesh such as Istio to achieve fine-grained control over traffic.
[0053] Deploy circuit breakers between the faulty service and its callers to prevent cascading failures.
[0054] Limit the flow of traffic to the Pod where the faulty service is located to reduce the traffic received by the problematic instance.
[0055] Through Kubernetes' automatic expansion strategy, the number of healthy Pods of the same service can be increased to compensate for the loss of faulty Pods.
[0056] Example:
[0057] Suppose an application service fails after a new version is released. Istio can quickly switch the application traffic back to the healthy version and enable the circuit breaker policy between the conflicting microservices to prevent the failure from spreading.
[0058] 4. Rapid recovery strategy
[0059] Function description: When a faulty service is discovered, the system can quickly switch back to the stable version and resume normal operation.
[0060] detail:
[0061] Use Kubernetes' Deployment and Service resources to achieve zero-downtime deployment and fast recovery of faulty services.
[0062] The operation and maintenance team can automatically replace the failed Pod with a stable version by executing commands or triggering a rollback operation in the CI / CD process.
[0063] Complete version control and deployment logs are pre-integrated into the CI / CD process design to facilitate rapid rollback to a stable state.
[0064] Example:
[0065] When bad behavior is discovered after releasing a new version of an application, the operations team immediately triggers a Rollback action through the CI / CD process's web interface. The Pipeline tool immediately executes the rollback script, automatically replacing the faulty version Pod with the stable version and redirecting traffic back to the old version Pod.
[0066] 5. Microservice elastic design
[0067] Functional description: All microservices are designed to be stateless and self-contained to ensure that when a failure occurs, the faulty instance can be quickly replaced without affecting other services.
[0068] detail:
[0069] Stateless service: Each service does not need to save the status information of the client request, can be horizontally expanded, and the failure of any instance will not affect the entire system.
[0070] Load balancing: Use load balancing between service instances to distribute the request load.
[0071] Automatic scaling: Use Kubernetes’ HPA (Horizontal Pod Autoscaler) to automatically scale up or down the number of instances based on traffic.
[0072] Service discovery: Use service registration and discovery mechanisms (such as Eureka and Consul) to implement dynamic calls between services without relying on hard-coded service addresses.
[0073] Example:
[0074] User services in the platform system participate in load balancing. If a user service encounters a problem after releasing a new version, the new version of the user service will not save the local state of the service. When a problem occurs, it can be quickly replaced to ensure that other parts of the platform can still run unimpeded.
[0075] 6. Monitoring and alarm system
[0076] Functional description: Build a centralized monitoring platform to collect monitoring data of all microservices. By configuring alarm rules, timely discover and notify the operation and maintenance team of relevant problems.
[0077] detail:
[0078] Monitoring data collection: Use tools such as Prometheus and Grafana to monitor and collect indicators for each microservice.
[0079] Log management: Use components such as ElasticSearch and Fluentd to collect and analyze logs.
[0080] Alert settings: Configure alert rules to warn of specific situations, such as sudden increase in indicators, high error rate, etc.
[0081] Real-time alerts: Integrate communication tools such as Slack and email to notify the operation and maintenance team in real time.
[0082] Example:
[0083] In the payment service, if the transaction failure rate suddenly increases, Prometheus detects the anomaly of this indicator, and a warning will appear on the corresponding dashboard on Grafana. At the same time, the alarm notification will be sent to the operation and maintenance team so that they can take immediate action.
[0084] 7. Fault Analysis and Recovery Log
[0085] Function description: The system records detailed fault handling logs and recovery operation logs to facilitate post-fault analysis of fault causes and continuous improvement of fault recovery processes.
[0086] detail:
[0087] Operation log: records the discovery time, type, processing operation and recovery time of each fault.
[0088] Automated Script Recording: Automatically track and record all recovery scripts and processes.
[0089] Issue tracking system: Integrate JIRA or similar tools to track issue handling status and subsequent improvement measures.
[0090] Example:
[0091] Consider a failure example, such as a recommendation system that causes a database connection failure after a version update. All related problem handling processes and decisions are recorded in real time in JIRA, whether it is the command to solve the problem, the manual deployment rollback operation or the final recovery process, all are recorded and transparent to the entire team.
[0092] 8. Continuous Integration / Continuous Deployment (CI / CD) Process
[0093] Function description: Build an automated CI / CD process to ensure the quality and reliability of new versions and reduce human errors.
[0094] detail:
[0095] Code submission trigger: When the code is submitted to a version control system such as Git, the build process is automatically triggered.
[0096] Automated testing: Perform automated testing such as unit testing, integration testing, and performance testing.
[0097] Automated deployment: Deploy to test, pre-production, and production environments through automated pipelines.
[0098] Quality testing: Ensure code quality and deployment traceability.
[0099] Dynamic routing: Leverage cloud-native tools such as Istio for dynamic routing and traffic management.
[0100] Example:
[0101] When a developer submits a new version of the code, the CI / CD system automatically builds and tests the new version. After passing all automated tests, the new version is automatically deployed to a pre-production environment for further verification. After being confirmed to be stable, it is further automatically deployed to the production environment, and the Istio service mesh is used to implement grayscale release and traffic control. Throughout the process, the CI / CD system will generate detailed deployment logs and status changes, providing a complete audit trail.
[0102] The present invention covers any substitution, modification, equivalent method and scheme made on the essence and scope of the present invention. In order to make the public have a thorough understanding of the present invention, specific details are described in detail in the following preferred embodiments of the present invention, but those skilled in the art can fully understand the present invention without the description of these details. In addition, in order to avoid unnecessary confusion about the essence of the present invention, well-known methods, processes, procedures, components and circuits are not described in detail.
[0103] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.
Claims
1. A fault isolation and rapid recovery system based on microservice architecture, characterized in that: This includes comprehensive analysis of multiple indicators of microservice operation (including CPU usage, memory usage, response time) and log data, using machine learning algorithms to identify abnormal behaviors, using Prometheus for data collection, ElasticSearch for log storage and analysis, and Grafana for data visualization and alarm configuration, to achieve real-time monitoring of the operating status of microservices and automatic fault identification.
2. According to the microservice architecture-based fault isolation and rapid recovery system of claim 1, it is characterized in that: It also includes using containerization technology and Kubernetes clusters to gradually release new versions of applications in grayscale and monitor the running status of new versions of Pods in real time, including blue-green deployment, dynamic traffic switching, and real-time performance monitoring.
3. According to the microservice architecture-based fault isolation and rapid recovery system of claim 1, it is characterized in that: It also includes using service meshes such as Istio to control traffic to faulty services, deploying circuit breakers and current limiting policies, and leveraging Kubernetes' automatic expansion policies to increase the number of healthy Pods to quickly isolate failures and reduce their impact.
4. According to the microservice architecture-based fault isolation and rapid recovery system of claim 1, it is characterized in that: It also includes using Kubernetes' Deployment and Service resources to replace the faulty Pod with a stable version by executing the rollback operation in the CI / CD process when a failure occurs, thereby achieving rapid recovery of the system.
5. A fault isolation and rapid recovery system based on microservice architecture according to claim 1, characterized in that: It also includes that all microservices are designed to be stateless and self-contained, request distribution is achieved through load balancing, Kubernetes' HPA is used to automatically expand and reduce the number of instances, and dynamic calls between services are achieved through service registration and discovery mechanisms.
6. A fault isolation and rapid recovery system based on microservice architecture according to claim 1, characterized in that: It also includes using tools such as Prometheus and Grafana to collect and monitor the operating indicators of microservices, managing logs through ElasticSearch and Fluentd, and configuring alarm rules to notify the operation and maintenance team in real time.
7. A fault isolation and rapid recovery system based on microservice architecture according to claim 1, characterized in that: It also includes recording the discovery time, type, handling operations and recovery time of each fault, automatically tracking and recording all recovery scripts and processes, and integrating issue tracking systems such as JIRA to facilitate fault analysis and continuous improvement.
8. A fault isolation and rapid recovery system based on microservice architecture according to claim 1, characterized in that: It also includes automatically triggering the build, test, and deployment processes, performing code quality detection and dynamic routing management through automated pipelines to ensure the quality and reliability of new versions and reduce the probability of errors in human operations.
Citation Information
Cited By
Short message channel fault processing method based on dynamic routing adjustment
CN120075859A
Micro-service fault diagnosis and self-healing system based on large model
CN120610872A
Consul cluster construction and self-healing method and system for desktop cloud
CN121262206A