Cloud platform fault atomic component library construction method based on micro-service architecture

Abstract

The invention relates to the field of cloud computing and distributed systems, and discloses a cloud platform fault atomic component library construction method based on a micro-service architecture, comprising the following steps: disassembling a cloud platform function module into a plurality of independent micro-services, and designing a fault atomic component library; through the fault detection assembly, the operation state of the micro-service is monitored in real time, fault data is collected, and the fault state is input into the fault diagnosis assembly. Modeling a fault state by adopting a Markov decision process; determining an optimal fault recovery strategy based on a preset reward function; according to the optimal recovery strategy, dynamically calling one or more components in a fault atomic component library, and executing a fault recovery action; and fault state transition information is fed back by monitoring an execution result of fault recovery. According to the method, rapid detection, accurate diagnosis and efficient recovery of cloud platform faults can be realized, fault changes can be dynamically adapted, and the high availability, the self-healing capability and the resource utilization efficiency of the system are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud computing and distributed systems, and in particular to a method for constructing a cloud platform fault atomic component library based on a microservice architecture. Background Art

[0002] With the rapid development of cloud computing technology, cloud platforms, as the core infrastructure of modern information technology, play an important role in supporting the business of various industries. Since cloud platforms usually need to carry a large number of user requests and data processing tasks, their high availability, stability and fault recovery capabilities have a vital impact on the overall performance of the platform and user experience. However, as the scale of cloud platforms continues to expand, the complexity of the system is gradually increasing, and the types, frequency and impact of fault problems are showing a significant growth trend.

[0003] Existing fault detection and recovery mechanisms are often based on overall architectural design, which is highly static and limited. Once a module or node in the cloud platform fails, traditional methods often require suspending the entire system for troubleshooting and repair. This method not only affects the continuous availability of the system, but also easily causes the scope of the fault to expand. In addition, the existing fault recovery mechanism lacks dynamic decision-making capabilities when dealing with complex faults, and cannot accurately recover according to the real-time status and evolution process of the fault, resulting in low fault recovery efficiency and high execution costs of recovery actions.

[0004] On the other hand, traditional fault handling solutions lack effective resource scheduling and optimization mechanisms when facing the high concurrency and dynamic expansion requirements of cloud platforms, resulting in unreasonable resource allocation, resource waste or insufficient resources during fault recovery. At the same time, most fault recovery solutions are based on human intervention, with a low degree of automation, and cannot achieve the system's adaptive and self-learning fault self-healing capabilities, making it difficult to meet the needs of modern cloud platforms for high availability and intelligent operation and maintenance. Summary of the invention

[0005] In view of the shortcomings of the prior art, the present invention provides a method for constructing a cloud platform fault atomic component library based on a microservice architecture, which solves the problems of low efficiency of the existing cloud platform fault detection and recovery process and lack of dynamic decision-making and closed-loop optimization mechanism, and realizes modular processing of faults and dynamic execution of optimal recovery strategies.

[0006] To achieve the above objectives, the present invention is implemented through the following technical solutions: A method for constructing a cloud platform fault atomic component library based on a microservice architecture, comprising the following steps:

[0007] Based on the microservice architecture of the cloud platform, the cloud platform functional modules are disassembled into multiple independent microservices, and a fault atomic component library is designed; the fault atomic component library includes fault detection components, fault diagnosis components, fault tolerance components, load balancing components and fault recovery components;

[0008] Through the fault detection component, the running status of each microservice is monitored, fault data is collected and the fault status is input into the fault diagnosis component;

[0009] The Markov decision process is used to model the fault state of the cloud platform, and the state space, action set and fault state transition probability are established;

[0010] Based on the preset reward function, calculate the benefits and resource consumption of fault recovery actions and determine the optimal fault recovery strategy;

[0011] According to the optimal recovery strategy, dynamically call one or more components in the fault atomic component library to perform fault recovery actions;

[0012] By monitoring the execution results of fault recovery, feeding back fault state transfer information, and updating fault state modeling and reward functions, closed-loop optimization of the system can be achieved.

[0013] Preferably, each component in the fault atomic component library has a standardized interface, and the standardized interface includes:

[0014] Input interface, receiving fault monitoring data and fault status information;

[0015] Output interface, outputs recovery instructions and status feedback information.

[0016] Preferably, the step of modeling the failure state of the cloud platform using a Markov decision process includes:

[0017] defining a fault state as a state space, the state space including a normal state and different types of fault states;

[0018] A fault recovery action is defined as an action set, wherein the action set includes fault recovery actions of restarting a service, performing load balancing, and switching redundant services;

[0019] The fault state transition probability matrix is ​​established through fault history data and monitoring data.

[0020] Preferably, the reward function includes positive benefits of fault repair and negative costs of resource consumption.

[0021] Preferably, the optimal fault recovery strategy is solved by:

[0022] Use dynamic programming or reinforcement learning methods to iteratively solve the value function of the fault state;

[0023] Under each fault state, the recovery action with the maximum benefit and the minimum resource consumption is selected as the optimal strategy.

[0024] Preferably, the fault recovery action includes:

[0025] The load balancing component performs dynamic traffic migration to reduce the risk of service overload;

[0026] Fault-tolerant components switch redundant services to maintain service availability;

[0027] The fault recovery component performs failed node restart or resource rescheduling.

[0028] Preferably, the feedback of the fault state transfer information by monitoring the execution result of the fault recovery includes:

[0029] Monitor the effect of fault recovery actions to determine whether the fault state has been transferred to the normal state;

[0030] Update the fault state transition probability matrix and reward function to achieve dynamic optimization of the fault recovery strategy.

[0031] Preferably, the method further comprises: optimizing resource allocation among faulty atomic components by non-cooperative game theory, specifically:

[0032] Considering the faulty atomic components as game players, defining the profit function of each player, wherein the profit function includes fault recovery efficiency and resource consumption;

[0033] Through iterative calculation, the Nash equilibrium point of resource allocation between faulty atomic components is found to ensure that resource allocation reaches the optimal state.

[0034] Preferably, the fault atomic component library is deployed independently from the microservice architecture of the cloud platform, and each component can run independently and can be dynamically combined and called according to the fault recovery strategy.

[0035] The present invention also provides a cloud platform fault atomic component library construction device based on a microservice architecture, comprising:

[0036] Microservice monitoring module, used to monitor the running status of cloud platform microservices and collect fault data;

[0037] Fault diagnosis module, used to analyze fault causes and generate fault status information;

[0038] Fault state modeling module, used to establish fault state space, action set and state transition probability matrix based on Markov decision process;

[0039] The optimal recovery decision module is used to calculate the optimal fault recovery strategy based on the reward function;

[0040] Resource allocation module, used to optimize resource allocation among faulty atomic components through non-cooperative game theory;

[0041] A recovery execution module, used to dynamically call one or more components in the fault atomic component library to perform recovery actions;

[0042] The feedback optimization module is used to monitor the execution results of the recovery action and update the fault state modeling and reward function to achieve closed-loop optimization.

[0043] The present invention provides a method for constructing a cloud platform fault atomic component library based on a microservice architecture. It has the following beneficial effects:

[0044] 1. The present invention decomposes the fault handling process into independent functional units such as detection, diagnosis, fault tolerance, load balancing and recovery by designing a fault atomic component library. Each component has a standardized interface and can be independently deployed and called. Through this modular design, fault handling functions can be flexibly combined and efficiently executed, avoiding the system downtime problem caused by traditional holistic fault repair and effectively improving the execution efficiency of fault recovery.

[0045] 2. The present invention uses the Markov decision process to model the fault state, establish the state space, action set and state transition probability, and calculate the optimal recovery strategy in combination with the reward function. Through the quantitative description of the evolution law of the fault state, the system can dynamically select the optimal recovery action under different fault states, ensuring that the fault recovery process is more scientific and accurate, and improving the decision-making level of system fault handling.

[0046] 3. Through the monitoring and feedback of fault recovery results, the present invention realizes the dynamic update of state transition probability and reward function, and combines the reinforcement learning method to continuously iterate and optimize the fault recovery strategy. This closed-loop optimization mechanism enables the system to adapt to the real-time changes of fault scenarios, continuously improves the accuracy of fault recovery and the adaptive ability of the system, and ensures that the fault handling solution is always in the optimal state.

[0047] 4. The present invention dynamically calls one or more components in the fault atomic component library to quickly respond and execute fault recovery actions, ensuring the efficiency and continuity of the system fault repair process. At the same time, combined with load balancing and fault tolerance mechanisms, the system service is guaranteed to be uninterrupted when partial faults occur, thereby greatly improving the high availability of the cloud platform and the stability of system operation.

[0048] 5. The present invention introduces a trade-off between resource consumption and cost in the fault recovery process, and ensures efficient fault recovery with minimal resource consumption by calculating the benefits and costs of the fault recovery action. In addition, through dynamic resource scheduling and allocation, resource waste and overuse are avoided, thereby optimizing the overall resource utilization of the system and reducing the operation and maintenance cost of fault recovery.

[0049] 6. The present invention is based on a microservice architecture, and the design of the fault atomic component library is highly decoupled, so that each functional component can be independently deployed, upgraded and expanded. At the same time, the design of the standardized interface facilitates the integration and collaborative work of the components. The system can flexibly combine components for fault recovery according to different fault scenarios, which enhances the scalability and technical adaptability of the cloud platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 It is a schematic diagram of the method flow of the present invention;

[0051] Figure 2 It is a schematic diagram of the device structure of the present invention.

[0052] Among them, 10, microservice monitoring module; 20, fault diagnosis module; 30, fault state modeling module; 40, optimal recovery decision module; 50, resource allocation module; 60, recovery execution module; 70, feedback optimization module. DETAILED DESCRIPTION

[0053] The following will be combined with the drawings in the specification of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0054] Please see attached Figure 1 Aiming at the high availability and rapid fault recovery problems of cloud platforms, the present invention proposes a method for constructing a fault atomic component library based on a microservice architecture. By decomposing cloud platform functions into independent microservices, combining Markov decision process (MDP) for fault modeling and recovery decision, and introducing a dynamic closed-loop feedback optimization mechanism, efficient fault detection, diagnosis, recovery and optimization are achieved, thereby improving the fault self-healing capability and resource utilization of the cloud platform.

[0055] like Figure 1 As shown, the method for constructing a fault atomic component library based on a microservice architecture may include the following steps:

[0056] S1. Design of fault atomic component library and disassembly of microservice architecture;

[0057] S2, fault detection and diagnosis;

[0058] S3, fault state modeling;

[0059] S4, calculation of optimal fault recovery strategy;

[0060] S5, dynamically call the faulty atomic component to perform recovery;

[0061] S6. Closed-loop feedback optimization.

[0062] For step S1, in this embodiment, based on the microservice architecture of the cloud platform, the overall functional module of the cloud platform is disassembled into multiple independent microservices, and a fault atomic component library is designed to make the fault detection, diagnosis and recovery functions modular and independent, thereby achieving rapid fault location and dynamic recovery.

[0063] In a specific implementation, the overall functions of the cloud platform are modularized according to business logic and functional requirements, and each module is independently deployed as a microservice, including but not limited to:

[0064] Request processing service: used to receive and respond to user requests, responsible for data transmission and interaction.

[0065] Data management services: realize data storage, access and maintenance functions.

[0066] Network communication service: used to handle communication protocols and data stream transmission inside and outside the cloud platform.

[0067] Resource scheduling service: performs dynamic resource allocation and scheduling to ensure the stable operation of each microservice.

[0068] It is understandable that the above microservices can be further split or combined according to different cloud platform deployment scenarios to adapt to business needs of different scales.

[0069] Specifically, the fault atomic component library includes the following minimum functional units:

[0070] 1. Fault detection component

[0071] This component is used to monitor the operating status of each microservice in real time and collect data indicators, including but not limited to: CPU utilization, memory consumption, network latency, service response time, etc.

[0072] In some embodiments, by setting a threshold detection method, when a monitoring indicator exceeds a preset threshold, the fault detection component generates a fault status identification.

[0073] As an option, anomaly detection can be performed on data metrics based on machine learning algorithms, such as anomaly classifiers or predictive models, to improve the accuracy of fault capture.

[0074] 2. Fault diagnosis component

[0075] The fault diagnosis component receives the fault status identification and related data, classifies and diagnoses the fault, and outputs the fault type information.

[0076] In a possible implementation, fault diagnosis can locate the cause of the fault based on historical data and fault logs through feature extraction and classification algorithms.

[0077] Exemplarily, the fault diagnosis component may classify faults into multiple types such as service overload, insufficient hardware resources, and network interruption.

[0078] 3. Fault-tolerant components

[0079] The main function of the fault-tolerant component is to provide redundant service switching to ensure service availability when a failure occurs.

[0080] Specifically, when the fault diagnosis component confirms that a microservice has a serious fault, the fault tolerance component triggers the startup of the redundant service and switches to the healthy node.

[0081] It should be noted that redundant services can be dynamically migrated through load balancing strategies to achieve seamless switching of business traffic.

[0082] 4. Load balancing components

[0083] The load balancing component is used to dynamically distribute service traffic and alleviate resource pressure caused by failures or overloads.

[0084] In some embodiments, load balancing can be scheduled based on indicators such as the current CPU utilization rate of each node and network traffic.

[0085] As an option, load balancing strategies such as weighted round-robin, minimum response time, or dynamic feedback adjustment can be used.

[0086] 5. Fault recovery components

[0087] The fault recovery component performs specific recovery actions based on the fault type, such as restarting the faulty node, releasing resources, or reallocating computing tasks.

[0088] In a possible implementation, the fault recovery component may reschedule resources in combination with the fault recovery strategy to maximize the fault recovery effect.

[0089] As an example, in order to improve the flexibility of the fault atomic component library, a standardized interface is designed for each component in this embodiment, specifically including:

[0090] Input interface: used to receive fault status data and diagnostic results from the monitoring system.

[0091] Output interface: used to output fault recovery instructions, execution results and status feedback information.

[0092] It should be noted that the design of standardized interfaces ensures the decoupling between the atomic components of each fault, so that each component can be deployed and called independently, and dynamically combined to work according to actual fault recovery requirements.

[0093] As a technical extension, the fault atomic component library can be combined with the service orchestration tools of the cloud platform (such as Kubernetes) to realize the automatic deployment and dynamic management of components. For example, when a fault is detected, the service orchestration tool can automatically schedule the fault recovery component to handle the fault according to the fault type.

[0094] In addition, in this embodiment, the fault atomic component library can be integrated with the monitoring system and log analysis system of the cloud platform to provide predictive analysis before a fault occurs and effect verification after fault recovery. For example, by collecting monitoring data of fault recovery execution, a recovery effect evaluation report is generated to provide a reference for system optimization.

[0095] It should be understood that the fault atomic component library of the present invention is decoupled from the microservice architecture and can be expanded according to actual application scenarios. For example, in a highly complex cloud platform, fault atomic components with specific functions, such as log analysis components, resource reset components, etc., can be added to further enhance the system's fault handling capabilities.

[0096] In summary, this embodiment realizes the modularization and standardization of fault detection, diagnosis and recovery functions by disassembling the cloud platform functional modules and designing the fault atomic component library, and provides a technical basis for subsequent fault modeling and dynamic recovery.

[0097] Regarding step S2, in this embodiment, the operating status of each microservice is monitored through the fault detection component, fault data is collected and the fault status is input into the fault diagnosis component to achieve rapid capture and preliminary analysis of the fault.

[0098] Specifically, the fault detection component is deployed on each microservice node of the cloud platform to continuously monitor the key operating indicators of each microservice, including but not limited to:

[0099] Computing resource indicators: such as CPU utilization, memory usage, etc.

[0100] Network transmission indicators: such as network bandwidth, data transmission delay, etc.;

[0101] Service response indicators: such as request response time and task processing time;

[0102] System load indicators: such as task queue length and number of concurrent requests.

[0103] In some embodiments, the fault detection component detects anomalies of the above-mentioned operating indicators by setting a threshold. For example, the set threshold of CPU utilization is 90%. When it is detected that the CPU utilization of a microservice exceeds the threshold, the fault detection component generates a fault alarm and marks the node as "fault state".

[0104] As an option, in order to improve the accuracy of fault detection, the fault detection component can use the time window analysis method to process the monitoring data in real time. For example, based on the sliding window technology, the fault detection component aggregates and analyzes the monitoring data of multiple consecutive time points to determine whether there is a continuous anomaly. If an indicator anomaly is detected in multiple time windows, a fault status flag is generated.

[0105] In a possible implementation, the fault detection component can also combine statistical methods or machine learning algorithms to identify anomalies. Specifically, it includes:

[0106] Anomaly detection based on statistics: By calculating the mean and standard deviation of each indicator data, the floating range of normal data is set. When an indicator deviates from the normal range, a fault alarm is triggered.

[0107] Classification model based on machine learning: Automatically identify and classify fault data by training anomaly detection models (such as support vector machines (SVMs), neural networks, etc.).

[0108] It should be noted that the fault detection component transmits the fault status data and identification information to the fault diagnosis component through a standardized interface. The data includes the time of fault occurrence, fault indicator type, abnormal value, and identification information of the monitoring node, etc., to ensure that the fault diagnosis component can quickly analyze the cause of the fault.

[0109] After receiving the fault detection data, the fault diagnosis component classifies and preliminarily locates the fault based on data analysis and fault logs. Specifically, the fault diagnosis component can identify the fault type and impact range based on the characteristics and historical records of the fault data. Fault types include but are not limited to:

[0110] Service overload: Mainly manifested in excessive CPU utilization, excessively long task processing queues, etc.

[0111] Network anomalies: mainly manifested as high network latency and packet loss;

[0112] Node failure: such as hardware resource exhaustion and service process crash;

[0113] Insufficient resources: such as memory usage exceeding the limit, insufficient storage space, etc.

[0114] As an option, the fault diagnosis component can match the fault data with the fault type template in combination with a feature matching algorithm. For example, a feature set of the fault type is stored in advance, and when a fault occurs, the current fault data is compared with the feature set to obtain the best matching fault type.

[0115] In another possible implementation, the fault diagnosis component can also classify fault types based on a decision tree algorithm or a rule engine. For example, based on the response time and resource occupancy indicators of the service, the decision tree rule is used to determine whether the fault is caused by service overload or resource shortage.

[0116] It should be noted that the fault diagnosis component can also output a fault status indicator s t ,The fault state identification is the input data for fault modeling and ,recovery decision, including information such as fault type, fault node location, fault severity, etc.

[0117] In some embodiments, in order to more efficiently support subsequent fault recovery processes, the fault diagnosis component may score the severity of the fault and output the fault level, for example:

[0118] Minor fault: The indicator slightly deviates from the threshold and does not affect business operations;

[0119] Moderate failure: indicators are continuously abnormal, affecting service performance;

[0120] Severe failure: Service is unavailable and business is interrupted.

[0121] It can be understood that, through the coordinated work of the fault detection component and the fault diagnosis component, this embodiment can achieve real-time monitoring, rapid detection and accurate classification of faults, and provide necessary input data for fault state modeling.

[0122] For example, in a highly complex cloud platform scenario, the fault detection component can also deploy multiple instances for distributed fault detection. For example, each node can deploy a detection instance separately, and aggregate the monitoring data to a unified analysis platform to achieve centralized data processing and unified identification of fault status.

[0123] It should be noted that the fault detection component and the fault diagnosis component have clear division of labor and independent functions, and the two interact with each other through standardized interfaces to ensure the efficiency and modular expansion capability of the system.

[0124] In summary, this embodiment implements real-time monitoring and capture of fault status through the fault detection component, and classifies and locates faults through the fault diagnosis component, thus providing a technical basis for subsequent fault status modeling and recovery strategy formulation.

[0125] For step S3, in this embodiment, a Markov decision process is used to model the fault state of the cloud platform, establish a state space, an action set and a fault state transition probability, and provide a theoretical basis for formulating the optimal strategy for fault recovery.

[0126] Specifically, we first abstract the fault state of the cloud platform and define a set of fault states, namely the state space S, which is used to describe the fault conditions of the system at different time points. The state space includes the normal state and multiple fault states, and its representation is:

[0127] S={s0,s1,s2,…,s n}

[0128] Among them, s0 represents the normal operating state of the system, s1, s2, ..., s n Respectively represent different types of fault conditions, for example:

[0129] s1: service overload fault status;

[0130] s2: network delay failure state;

[0131] s3: resource exhaustion failure state;

[0132] s4: Node downtime failure state.

[0133] As an option, in order to improve the sophistication of fault modeling, the state space can be further subdivided according to the severity of the fault. For example, the service overload state can be divided into mild overload, moderate overload and severe overload states, corresponding to different fault impact ranges.

[0134] In a possible implementation, for each fault state s t , define a set of recovery actions A, which represent the fault recovery actions that the system can take in this state:

[0135] A={a1,a2,a3,…,a m}

[0136] Among them, a i Represents different recovery actions, such as:

[0137] a1: trigger load balancing adjustment;

[0138] a2: execute redundant service switching;

[0139] a3: Restart the failed node;

[0140] a4: reallocate resources;

[0141] a5: Add a service instance.

[0142] It should be noted that the action set A is related to the fault state S, that is, the recovery actions corresponding to different fault states may be different. For example, in the service overload fault state, load balancing adjustment and adding service instances are prioritized, while in the node downtime fault state, redundant service switching and node restart are prioritized.

[0143] In this embodiment, by statistically analyzing historical fault data and monitoring logs, a state transition probability matrix P between fault states is established to describe the changing rules of the fault state after the system performs the recovery action. The state transition probability is expressed as:

[0144] P(s t+1 |s t ,a)=Pr{S t+1 =s t+1 ∣S t =s t ,A t =a}

[0145] Among them, s t is the current fault state, a is the fault recovery action taken, S t+1 is the next fault state after the action is executed, and P represents the probability of state transition.

[0146] Specifically, in a possible implementation, the state transition probability matrix can be calculated by the following method:

[0147] Based on historical data statistics: Through the fault recovery log, statistics are collected on the current status s under different recovery actions. t Transition to next state S t+1 The frequency of , and get the corresponding probability value.

[0148] Based on real-time monitoring feedback: Through real-time fault recovery execution results, the state transition probability is dynamically updated to improve the accuracy of modeling.

[0149] For example, assuming that the current state is service overload s1, after taking load balancing action a1, the system has an 80% probability of transferring to the normal state s0, a 15% probability of remaining in the slightly overloaded state s1, and a 5% probability of transferring to the resource-deficient state s3. Part of the state transition matrix is ​​expressed as follows:

[0150]

[0151] Among them, P ij Indicates that from state s i Transfer to state s j probability.

[0152] As an option, in order to achieve real-time update of state modeling, the current fault state data can be dynamically sampled through the sliding window analysis method, and the state transition probability matrix can be continuously optimized in combination with the feedback mechanism.

[0153] In another possible implementation, in order to better adapt to complex fault scenarios, fault state modeling can introduce a semi-Markov process, that is, considering the duration of the system in a certain fault state during state transition, thereby improving the model's ability to describe the impact of fault persistence.

[0154] It should be noted that the results of fault state modeling, namely the state space S, action set A and state transition probability P, will serve as the basic input for fault recovery strategy formulation and provide necessary data support for subsequent optimal strategy solution.

[0155] In summary, this embodiment establishes cloud platform fault state modeling through Markov decision process, defines state space, action set and state transition probability matrix, and provides accurate modeling method and data support for optimal decision making for fault recovery. In some embodiments, combining real-time monitoring with historical fault data can further improve the accuracy and dynamic adaptability of fault modeling.

[0156] For step S4, in this embodiment, based on the fault state modeling result established by the Markov decision process and combined with a preset reward function, the benefits and resource consumption of different fault recovery actions are calculated to determine the optimal fault recovery strategy.

[0157] Specifically, for the fault state space S and the recovery action set A, this embodiment introduces the reward function R(s t ,a), is used to quantify the benefits and costs of fault recovery actions under specific fault conditions. The reward function considers the effect of the fault recovery action after execution and the consumption of resources, and is expressed as:

[0158] R(s t ,a)=R success -C(a)

[0159] in:

[0160] R success It indicates the positive benefits obtained by the system after the failure recovery is successful;

[0161] C(a) represents the resource cost consumed by executing recovery action a, including time cost, computing resource consumption cost, etc.

[0162] It should be noted that R success The value of can be set according to the impact of the fault status on the cloud platform business. For example:

[0163] In the case of service overload, the benefits of successfully executing load balancing actions are higher;

[0164] In the event of a node failure, the benefit of redundant switching depends on the speed and availability of service recovery.

[0165] As an option, the calculation of resource consumption cost C(a) can be dynamically adjusted in combination with the current state of system resources. For example, when system resources are sufficient, the cost of restarting services or reallocating resources is low; when resources are scarce, the resource consumption cost of the same action increases accordingly.

[0166] In one possible implementation, based on the reward function R(s t ,a) and state transition probability P(s t+1 |s t ,a), Calculate the value function V(s) of the fault recovery strategy, and its calculation method follows the Bellman equation:

[0167]

[0168] in:

[0169] V(s) represents the value of the fault state s, that is, the expected benefit that can be obtained by performing recovery actions based on the current state;

[0170] γ is a discount factor, which is used to balance current income and future income, and its value range is [0,1];

[0171] P(s′|s,a) represents the probability that state s transitions to the next state s′ after taking recovery action a.

[0172] Specifically, this embodiment uses a dynamic programming method to iteratively solve the Bellman equation and ultimately determines the optimal recovery strategy π * (s), which is expressed as:

[0173]

[0174] It should be noted that the optimal recovery strategy π * (s) represents the selection of the fault recovery action a that maximizes the benefit and minimizes the resource consumption under a specific fault state s.

[0175] In some embodiments, in order to improve the computational efficiency of solving the optimal strategy, a value iteration or policy iteration algorithm may be used for solving the problem. For example:

[0176] Value iteration method: Starting from the initial state, the value function of each fault state is continuously updated until it converges to the optimal value.

[0177] Policy iteration method: Based on the value function of the current strategy, gradually optimize the strategy and finally obtain the optimal strategy.

[0178] For example, assuming that the system is currently in a service overload fault state s1, the recovery actions that can be taken include load balancing a1 and adding instances a2. By calculating:

[0179] The reward of load balancing a1 is R(s1,a1)=10, and the consumption cost is C(a1)=2;

[0180] The reward for adding instance a2 is R(s1,a2)=15, and the consumption cost is C(a2)=5.

[0181] At the same time, according to the state transition probability, the success rate of executing a1 is 80%, and the success rate of executing a2 is 90%. Through the above formula calculation, it is finally determined that the optimal fault recovery strategy in the current state is to add instance a2.

[0182] In another possible implementation, this embodiment can perform online learning and optimization of the optimal strategy based on a reinforcement learning method (such as a Q-learning algorithm). Specifically, by real-time monitoring of the fault recovery effect, feeding back the actual reward value to the strategy model, and dynamically updating the state transition probability and reward function, the adaptive optimization of the optimal recovery strategy can be achieved.

[0183] It can be understood that this embodiment calculates the benefits and costs of each recovery action through a preset reward function and fault state modeling, and determines the optimal fault recovery strategy based on the Bellman equation, thereby dynamically selecting the most appropriate recovery action under the fault state.

[0184] In summary, in this embodiment, by quantitatively analyzing the fault recovery actions and solving the optimal strategy, dynamic decision-making and benefit maximization of the fault recovery process are achieved, while minimizing resource consumption, providing theoretical support and data guarantee for the efficiency and accuracy of fault recovery.

[0185] For step S5, in this embodiment, according to the optimal recovery strategy calculated in step S4, one or more components in the fault atomic component library are dynamically called to perform corresponding fault recovery actions to achieve efficient processing of fault states and system self-healing.

[0186] Specifically, the optimal recovery strategy π * (s) is the result of decision-making based on the current fault state s and the recovery action benefit. Under the guidance of this strategy, the system selects the component in the fault atomic component library that can perform the optimal recovery action, and performs dynamic calling and task allocation.

[0187] The components in the fault atomic component library include but are not limited to:

[0188] Load balancing component: responsible for distributing the traffic of overloaded nodes to other healthy nodes to alleviate resource pressure;

[0189] Fault-tolerant components: Through the redundant service switching mechanism, the business of the faulty node is migrated to the backup service to ensure the continuous availability of the system;

[0190] Fault recovery component: performs recovery operations such as node restart, resource release, and fault node isolation;

[0191] Resource scheduling component: reallocates computing resources to balance the load of the overall system;

[0192] Monitoring and feedback component: monitors the execution effect of fault recovery actions in real time and provides feedback data for subsequent decision-making.

[0193] In some embodiments, the execution of the fault recovery action is scheduled and managed based on a service orchestration tool (such as Kubernetes). Specifically, when the optimal recovery strategy is determined, the service orchestration tool will send instructions to the target fault atomic component, trigger the execution of the fault recovery action, and monitor the execution process.

[0194] As an option, in order to ensure efficient execution of fault recovery actions, this embodiment implements the calling and collaborative work of faulty atomic components through standardized interfaces. The standardized interfaces include:

[0195] Input interface: receiving fault status t , recovery instructions and resource allocation information;

[0196] Output interface: outputs the execution results of fault recovery, status feedback, and component call logs.

[0197] In one possible implementation, the system can simultaneously call multiple fault atomic components to perform collaborative recovery operations to speed up the fault recovery process. For example, for the service overload fault state s1, the system can simultaneously call the load balancing component and the resource scheduling component:

[0198] The load balancing component distributes traffic from overloaded nodes to other healthy nodes;

[0199] The resource scheduling component adds computing resources to the currently overloaded nodes to achieve rapid recovery.

[0200] For example, the system is currently in node failure state s3, and the optimal recovery strategy is to perform redundancy switching a2 and node restart a3. In this scenario:

[0201] The system first calls the fault-tolerant component and switches to the backup node to ensure business continuity;

[0202] The fault recovery component is then called to restart the failed node and initialize the node resources.

[0203] It should be noted that the process of dynamically calling the faulty atomic component is adjusted based on the change of the real-time fault status, that is, the system continuously monitors the effect of fault recovery while executing the recovery action. If it is detected that the current recovery action fails to completely eliminate the fault, the system can re-call other faulty atomic components for recovery operations according to the suboptimal solution of the optimal strategy.

[0204] In another possible implementation, in order to further improve the execution efficiency of fault recovery actions, this embodiment introduces a resource allocation optimization mechanism to dynamically allocate the resource requirements of each faulty atomic component through non-cooperative game theory. For example, when multiple components need computing resources at the same time, the system allocates resources based on the game equilibrium point to achieve the optimization of overall resource utilization. Specifically, non-cooperative game theory is as follows:

[0205] Considering the faulty atomic components as game players, defining the profit function of each player, wherein the profit function includes fault recovery efficiency and resource consumption;

[0206] Through iterative calculation, the Nash equilibrium point of resource allocation between faulty atomic components is found to ensure that resource allocation reaches the optimal state.

[0207] It should be understood that the dynamic call mechanism in this embodiment not only ensures the optimal execution of the fault recovery action, but also realizes the efficient coordination and task scheduling of the fault atomic component library. In addition, the design of the standardized interface makes the components highly decoupled, which facilitates the expansion and iterative upgrade of the fault recovery function.

[0208] In summary, this embodiment realizes the efficient execution and collaborative work of one or more components in the fault atomic component library through a dynamic call mechanism based on the optimal recovery strategy, ensuring the rapid recovery of system failures and the continuous availability of services. At the same time, combined with the service orchestration tool and resource allocation optimization mechanism, the execution efficiency of fault recovery actions and system stability are effectively improved.

[0209] For step S6, in this embodiment, by monitoring the execution results of fault recovery, the changes in the fault state are obtained in real time, the fault state transition information is fed back, and on this basis, the state transition probability and reward function in the fault state modeling are updated, thereby forming a closed-loop optimization mechanism to achieve dynamic optimization and continuous iteration of the system fault recovery strategy.

[0210] Specifically, after the fault recovery action is completed, the monitoring system re-detects the fault status and obtains the current system status s t+1 And record the failure recovery results.

[0211] It should be noted that the monitoring process includes the collection and analysis of the following key data:

[0212] Fault recovery success rate: whether the fault recovery action effectively eliminates the fault;

[0213] Fault recovery time: the time required from the start of the recovery action to the system returning to normal;

[0214] Resource consumption: computing resources, network resources, etc. consumed during the recovery process;

[0215] Fault state change: The current fault state of the system after the recovery action is executed. t+1 .

[0216] In a possible implementation, the monitoring result of the fault state is transmitted to the fault state modeling module through a standardized feedback interface for dynamically updating the state transition probability matrix P.

[0217] Specifically, the state transition probability is updated based on real-time data statistics. By calculating the number of state transitions before and after fault recovery, the state transition probability P(s) under the current recovery action a is obtained. t+1 |s t ,a):

[0218]

[0219] in:

[0220] N(s t →s t+1 |a) indicates that after taking action a, the fault state changes from s t Transfer to t+1 The number of times;

[0221] The denominator is the state s t The total number of transitions to all states after executing recovery action a.

[0222] For example, assume that the system is currently in fault state s2 (network delay). After taking recovery action a1 (load balancing adjustment), the following monitoring records are obtained:

[0223] In 70% of cases, the system transfers to the normal state s0;

[0224] In 20% of cases, it is still in the fault state s2;

[0225] In 10% of cases, the system moves to the insufficient resource state s3.

[0226] Through the above feedback data, the system can dynamically update the state transition probability matrix to further improve the accuracy of fault state modeling.

[0227] As an option, in order to improve the quantitative evaluation of the system's fault handling effect, the monitoring module will also adjust the reward value in the fault recovery action execution result. Specifically, the reward function R(s t ,a) According to the actual fault recovery effect, the new reward function value can be expressed as:

[0228] R′(s t ,a)=R(s t ,a)+ΔR

[0229] in:

[0230] ΔR is the incremental value dynamically adjusted according to the monitoring feedback results;

[0231] If the fault recovery effect is better than expected, the increment ΔR>0;

[0232] If the fault recovery effect is not good, the increment ΔR<0.

[0233] In some embodiments, the reward value may be adjusted by weighted calculation in combination with indicators such as system recovery time, resource consumption, etc. For example, when the fault recovery action takes too long to execute but the fault is successfully recovered, the reward value is appropriately reduced to reflect the time cost.

[0234] In another possible implementation, based on the updated state transition probability matrix P and reward function R′, the system recalculates the optimal recovery strategy π * (s). Dynamic iterative optimization of fault recovery strategies is achieved through reinforcement learning methods (such as Q-learning).

[0235] Illustratively, during the dynamic iteration process, the system can adapt to the complexity of the fault and environmental changes and continuously select the optimal fault recovery action.

[0236] It is important to understand that the closed-loop feedback optimization process is a continuous cycle mechanism, that is, the system will perform status monitoring and feedback updates after each fault handling is completed to ensure that the fault modeling and recovery strategies always maintain dynamic adaptability.

[0237] Specifically, closed-loop optimization includes the following cyclic processes:

[0238] Monitor fault recovery results and obtain state transition data;

[0239] Update state transition probabilities and reward functions in fault state modeling;

[0240] Recalculate the optimal recovery strategy based on updated data;

[0241] Implement the new recovery strategy and monitor feedback again.

[0242] It can be understood that this embodiment realizes dynamic updating and continuous optimization of fault state modeling and recovery strategy through a closed-loop feedback optimization mechanism, thereby improving the accuracy and efficiency of system fault self-healing.

[0243] In summary, this embodiment forms a closed-loop fault handling mechanism through real-time monitoring and feedback of fault recovery results, dynamic updating of state transition probability and reward function, and iterative optimization of recovery strategy in combination with reinforcement learning method, so as to ensure that the system can continuously adapt to fault changes in a complex cloud platform environment and achieve optimization of fault recovery strategy.

[0244] The present invention realizes modular processing of faults by disassembling cloud platform functional modules into independent microservices and designing atomic components such as fault detection, diagnosis, fault tolerance, load balancing and recovery. The fault state is modeled in combination with the Markov decision process, the optimal fault recovery strategy is calculated based on the state transition probability and reward function, and the fault atomic component is dynamically called to perform the recovery action. In addition, by monitoring the fault recovery results, feeding back the fault state information, dynamically updating the state transition probability and reward function, a closed-loop optimization mechanism is formed to ensure the continuous optimization and efficient execution of the system fault recovery strategy.

[0245] Please see attached Figure 2 The present invention also provides a cloud platform fault atomic component library construction device based on microservice architecture, including:

[0246] Microservice monitoring module 10, used to monitor the running status of cloud platform microservices and collect fault data;

[0247] A fault diagnosis module 20, used to analyze the cause of the fault and generate fault status information;

[0248] A fault state modeling module 30, for establishing a fault state space, an action set and a state transition probability matrix based on a Markov decision process;

[0249] An optimal recovery decision module 40, used to calculate an optimal fault recovery strategy based on a reward function;

[0250] A resource allocation module 50, for optimizing resource allocation among faulty atomic components through non-cooperative game theory;

[0251] A recovery execution module 60, used to dynamically call one or more components in the fault atomic component library to perform a recovery action;

[0252] The feedback optimization module 70 is used to monitor the execution results of the recovery action and update the fault state modeling and reward function to achieve closed-loop optimization.

[0253] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for constructing a cloud platform fault atomic component library based on microservice architecture, characterized in that: The following steps are involved: Based on the microservice architecture of the cloud platform, the cloud platform functional modules are disassembled into multiple independent microservices, and a fault atomic component library is designed; The fault atomic component library includes a fault detection component, a fault diagnosis component, a fault tolerance component, a load balancing component and a fault recovery component; Through the fault detection component, the running status of each microservice is monitored, fault data is collected and the fault status is input into the fault diagnosis component; The Markov decision process is used to model the fault state of the cloud platform, and the state space, action set and fault state transition probability are established; Based on the preset reward function, calculate the benefits and resource consumption of fault recovery actions and determine the optimal fault recovery strategy; According to the optimal recovery strategy, dynamically call one or more components in the fault atomic component library to perform fault recovery actions; By monitoring the execution results of fault recovery, feeding back fault state transfer information, and updating fault state modeling and reward functions, closed-loop optimization of the system can be achieved.

2. The method for constructing a cloud platform fault atomic component library based on microservice architecture according to claim 1 is characterized in that: Each component in the fault atomic component library has a standardized interface, and the standardized interface includes: Input interface, receiving fault monitoring data and fault status information; Output interface, outputs recovery instructions and status feedback information.

3. The method for constructing a cloud platform fault atomic component library based on microservice architecture according to claim 1 is characterized in that: The steps of using the Markov decision process to model the failure state of the cloud platform include: defining a fault state as a state space, the state space including a normal state and different types of fault states; A fault recovery action is defined as an action set, wherein the action set includes fault recovery actions of restarting a service, performing load balancing, and switching redundant services; The fault state transition probability matrix is ​​established through fault history data and monitoring data.

4. The method for constructing a cloud platform fault atomic component library based on microservice architecture according to claim 1 is characterized in that: The reward function includes the positive benefits of fault repair and the negative costs of resource consumption.

5. The method for constructing a cloud platform fault atomic component library based on microservice architecture according to claim 1 is characterized in that: The optimal fault recovery strategy is solved in the following way: Use dynamic programming or reinforcement learning methods to iteratively solve the value function of the fault state; Under each fault state, the recovery action with the maximum benefit and the minimum resource consumption is selected as the optimal strategy.

6. The method for constructing a cloud platform fault atomic component library based on microservice architecture according to claim 1 is characterized in that: The fault recovery action includes: The load balancing component performs dynamic traffic migration to reduce the risk of service overload; Fault-tolerant components switch redundant services to maintain service availability; The fault recovery component performs failed node restart or resource rescheduling.

7. The method for constructing a cloud platform fault atomic component library based on microservice architecture according to claim 1 is characterized in that: The feedback of the fault state transfer information by monitoring the execution result of the fault recovery includes: Monitor the effect of fault recovery actions to determine whether the fault state has been transferred to the normal state; Update the fault state transition probability matrix and reward function to achieve dynamic optimization of the fault recovery strategy.

8. The method for constructing a cloud platform fault atomic component library based on microservice architecture according to claim 1 is characterized in that: The method further includes: optimizing resource allocation among faulty atomic components through non-cooperative game theory, specifically: Considering the faulty atomic components as game players, defining the profit function of each player, wherein the profit function includes fault recovery efficiency and resource consumption; Through iterative calculation, the Nash equilibrium point of resource allocation between faulty atomic components is found to ensure that resource allocation reaches the optimal state.

9. The method for constructing a cloud platform fault atomic component library based on microservice architecture according to claim 1 is characterized in that: The fault atomic component library is deployed independently from the microservice architecture of the cloud platform, and each component can run independently and can be dynamically combined and called according to the fault recovery strategy.

10. A cloud platform fault atomic component library construction device based on microservice architecture, applied to the method according to any one of claims 1 to 9, characterized in that: include: Microservice monitoring module, used to monitor the running status of cloud platform microservices and collect fault data; Fault diagnosis module, used to analyze fault causes and generate fault status information; Fault state modeling module, used to establish fault state space, action set and state transition probability matrix based on Markov decision process; The optimal recovery decision module is used to calculate the optimal fault recovery strategy based on the reward function; Resource allocation module, used to optimize resource allocation among faulty atomic components through non-cooperative game theory; A recovery execution module, used to dynamically call one or more components in the fault atomic component library to perform recovery actions; The feedback optimization module is used to monitor the execution results of the recovery action and update the fault state modeling and reward function to achieve closed-loop optimization.

Images