Mimicry system component scheduling method and device supporting fault self-healing

Abstract

The invention discloses a mimicry system component scheduling method and device supporting fault self-healing, which can automatically clean or offline problem components when a fault occurs based on dynamic monitoring and screening of the health state of the components in each execution path, and intelligently select the component with higher health degree to continue to execute a task. According to the method, basic operation parameters of the components are considered, and interaction information and historical operation data of the components in different execution paths are integrated. Through the multi-dimensional monitoring mode, the health state of the component can be more accurately judged. In the aspect of intelligent component selection, a comprehensive evaluation strategy based on component health degree and path reliability is adopted, components with high health degree and high path stability are preferentially selected to continue to execute tasks, which is essentially different from a mode purely based on backup priority or random selection in the prior art. Therefore, the fault tolerance and the execution efficiency of the system are effectively improved.

Description

Technical Field

[0001] The present invention belongs to the field of computer network technology, and in particular, relates to a component scheduling method and device for a mimetic system that supports fault self-healing. The invention mainly aims at mimetic systems based on component architecture, which have problems such as slow response speed and high misjudgment rate when handling faults, and improves the availability and stability of the system through an intelligent scheduling algorithm and self-healing mechanism. Background Art

[0002] In the field of modern information technology, the demand for building complex application systems is growing. To meet this challenge, component-based architecture came into being and quickly gained favor in the industry. The core concept of this architecture is to decompose large application systems into multiple independent, loosely coupled small components, each of which is responsible for a specific functional module, so as to achieve the design goals of flexibility, scalability and easy maintenance. Component-based architecture has the following significant advantages:

[0003] (1) Flexibility: Each component can be developed and deployed independently of other components using different programming languages ​​and technology stacks, thereby achieving technological diversity and development flexibility.

[0004] (2) Scalability: The system can independently scale specific components based on actual load requirements without redeploying the entire system, effectively supporting dynamic adjustment of system scale.

[0005] (3) Fault tolerance: Due to the loose coupling between components, the failure of a single component will not cause the collapse of the entire system, which improves the robustness and reliability of the system.

[0006] (4) Rapid iteration: Small components are easy to update and deploy quickly, making feature updates and bug fixes faster, helping to achieve rapid product iteration and market response.

[0007] Although component-based architecture brings many advantages, it also faces a series of challenges in practical applications. In particular, under the complex dependencies between components, the failure of any component may lead to a degradation of system performance or even complete failure. Traditional fault handling methods, such as redundant backup and manual repair, are often inefficient and cannot meet the requirements of modern systems for high availability and automated repair.

[0008] By introducing diversified and dynamic reconstruction techniques, the mimic system enhances the system's anti-attack capability and adaptability, and helps to achieve fine-grained fault isolation and recovery. Compared with traditional component architecture, the component-based mimic system shows higher flexibility and efficiency when facing different types of faults.

[0009] Although existing fault self-healing technologies have solved the problem of component failure to a certain extent, they are often unable to accurately and quickly locate faulty components when dealing with complex component dependencies. Some technologies rely on simple redundant backups and cannot intelligently switch and repair components based on their actual operating status when they fail, resulting in system performance degradation and prolonged service interruptions.

[0010] In a component-based architecture, component failures are inevitable. Although existing fault detection and recovery solutions can solve the problem to a certain extent, they still have the following defects:

[0011] (1) Slow response speed: Existing systems usually take a long time to detect and repair a failure, which significantly prolongs system downtime and affects user experience.

[0012] (2) Insufficient processing accuracy: The existing solutions have a high misjudgment rate and may misjudge normally operating components as faulty services, resulting in unnecessary cleaning or offline operations, thus affecting business continuity.

[0013] In order to improve the reliability of the system, the component-based mimicry system requires an intelligent self-healing mechanism that can monitor the status of each component in real time, automatically detect faults and take repair measures.

[0014] To solve the above problems, the present invention proposes a method and device for scheduling components of a mimic system that supports self-healing of faults. The method is based on dynamic monitoring and screening of the health status of components in each execution path. It can automatically clean or offline problematic components when a fault occurs, and intelligently select components with higher health to continue to execute tasks. Through this mechanism, the present invention greatly improves the fault tolerance and stability of the system, reduces the impact of faults on business processes, and provides a more efficient and reliable fault handling solution for component-based architectures.

[0015] Explanation of terms Components: Components are independent, loosely coupled, small functional modules that each have specific responsibilities. They can be developed and deployed independently of each other and support the use of different programming languages ​​and technology stacks. Summary of the invention

[0016] The purpose of the present invention is at least to solve the problems of slow response speed and high misjudgment rate of the mimetic system of the existing component architecture when handling faults, and to provide a mimetic system component scheduling method and device that supports fault self-healing, which can automatically monitor the operating status of each component and quickly take repair measures when a fault is detected, thereby ensuring the high availability of the system.

[0017] The present invention is implemented in this way. In a first aspect, the present invention provides a method for scheduling components of a mimic system supporting fault self-healing, comprising the following steps: Step S1: System initialization When the system is initialized, an initial health value is assigned to each component , and initialize its cleaning times to 0; at the same time, set the following system parameters: high probability deduction , medium to high probability of deduction , medium and low probability points reduction , low probability reduction , Cleaning health threshold , Offline cleaning times threshold The minimum health threshold of the components of the path .

[0018] Step S2: Request scheduling When the system receives a request, the scheduling module selects three execution paths for each request based on the load balancing strategy. Then, it checks the minimum health of the components in each execution path. If the minimum health of the components in at least two execution paths is greater than , then select the current three execution paths, otherwise reselect the three execution paths.

[0019] Each execution path consists of multiple components in the component pool.

[0020] Step S3: Request distribution The request distribution module distributes the request to the three execution paths selected by the scheduling module; each component of each execution path executes the request in turn and returns the execution results of each path to the arbitration module.

[0021] Step S4: Check the consistency of the execution results The arbitration module compares the execution results of the three execution paths selected by the scheduling module; if the execution results are exactly the same, it traverses all components of the three paths and increases the health of each component by one. , then execute step S6; if the execution results are not completely consistent, it is considered that the system enters a fault screening state, and then execute step S5.

[0022] Components Health The constraints are .

[0023] Step S5: Fault screening and recovery The fault screening module checks the components in each execution path in turn according to the differences in the execution results, and adjusts the health of each component in the path; the specific steps are as follows: Step S5.1: Determine whether the execution results of only two paths are the same. If so, execute step S5.2; otherwise, execute step S5.3.

[0024] Step S5.2: Check different result paths, and the two paths with the same execution results are recorded as and , and another path with different execution results is recorded as ; Specifically: Step S5.2.1: Check paths with different execution results ; Specifically: Step S5.2.1.1, check the same components: Traversing the path For all components in the , first determine whether the current component also has a path or Path If it exists, the health of the current component remains unchanged, and then continue to determine whether the current component is the last component. If it is the last component, execute step S5.2.2. If it is not the last component, repeat the current step for the next component; if it does not exist, execute step S5.2.1.2.

[0025] Step S5.2.1.2 Check components of the same class: Determine if there is a path for a component of the same category as the current component or Path If it exists, traverse the component pool and subtract the health of other components of the same category as the current component. , then continue to determine whether the current component is the last component. If it is the last component, execute step S5.2.2. If it is not the last component, repeat step S5.2.1.1 for the next component; if it does not exist, execute step S5.2.1.3.

[0026] Step S5.2.1.3: Handle the situation where there is no component of the same class: Subtract the health of the current component from , and traverse the component pool at the same time, subtract the health of other components of the same category as the current component , then continue to determine whether the current component is the last component. If it is the last component, execute step S5.2.2. If it is not the last component, repeat step S5.2.1.1 for the next component.

[0027] Step S5.2.2: Check the path ; Specifically: Step S5.2.2.1, check components of the same class: Traversing the path All components in the current component are checked to see if there are no other components of the same category as the current component. But there is a path If so, subtract the health of the current component from , then continue to determine whether the current component is the last component. If it is the last component, execute step S5.2.3. If it is not the last component, repeat step S5.2.2.1 for the next component; if it does not exist, execute step S5.2.2.2.

[0028] Step S5.2.2.2: Handle the situation where there is no component of the same class: Determine whether other components of the same category as the current component do not have paths and If so, traverse the component pool and subtract all other components of the same category as the current component. , then continue to determine whether the current component is the last component. If it is the last component, execute step S5.2.3. If it is not the last component, repeat step S5.2.2.1 for the next component; otherwise, do nothing, and then continue to determine whether the current component is the last component. If it is the last component, execute step S5.2.3. If it is not the last component, repeat step S5.2.2.1 for the next component.

[0029] Step S5.2.3: Check the path ; Specifically: Step S5.2.3.1, check components of the same class: Traversing the path All components in the current component, determine whether there are other components of the same category as the current component. or Path If yes, the health of the current component remains unchanged, and then continue to determine whether the current component is the last component. If it is the last component, execute step S6. If it is not the last component, repeat step S5.2.3.1 for the next component; otherwise, execute step S5.2.3.2.

[0030] Step S5.2.3.2: Handle the situation where there is no component of the same class: Traverse the component pool and subtract the health of other components of the same category as the current component , then continue to determine whether the current component is the last component. If it is the last component, execute step S6. If it is not the last component, repeat step S5.2.3.1 for the next component.

[0031] Step S5.3: Check all paths; specifically: Step S5.3.1, check the path ; Specifically: S5.3.1.1. Check components of the same class: Traversing the path For all components in the , first determine whether the current component also has a path or Path If it exists, the health of the current component will be directly reduced by a low probability deduction. , and then continue to determine whether the current component is the last component. If it is the last component, execute step S5.3.1.2. If it is not the last component, repeat the current step for the next component; if it does not exist, continue to determine whether there is a path for other components of the same category as the current component or Path If there is a path or Path The health of components of the same category as the current component is subtracted , and then continue to determine whether the current component is the last component. If it is the last component, execute step S5.3.1.2. If it is not the last component, repeat the current step for the next component. If there is no path or Path , then execute step S5.3.1.2.

[0032] S5.3.1.2. Handling the situation where there is no component of the same class: Subtract one from the health of the current component , and traverse the component pool at the same time, subtract the health of other components of the same category as the current component , then continue to determine whether the current component is the last component. If it is the last component, execute step S5.3.1.2. If it is not the last component, repeat step S5.3.1.1 for the next component; otherwise, execute step S5.3.2.

[0033] Step S5.3.2: Check the path ; Specifically: Step S5.3.2.1: Check components of the same class Traversing the path All components in the , first determine whether the current component has a path If yes, skip the current component check, and then continue to determine whether the current component is the last component. If it is the last component, execute step S5.3.3. If it is not the last component, repeat step S5.3.2.1 for the next component. If not, continue to determine whether other components of the same category as the current component do not have paths But there is a path If so, directly subtract the low probability deduction from the health of the current component. , then continue to determine whether the current component is the last component. If it is the last component, execute step S5.3.3. If it is not the last component, repeat step S5.3.2.1 for the next component; otherwise, execute step S5.3.2.25.

[0034] Step S5.3.2.2: Handle the situation where there is no component of the same class: Determine whether the current component is in the path and path There are no identical classes. If so, the health of the current component is subtracted from , and traverse the component pool at the same time, subtracting the health of all other components of the same category as the current component , then continue to determine whether the current component is the last component. If it is the last component, execute step S5.3.3. If it is not the last component, repeat step S5.3.2.1 for the next component; otherwise, do nothing, and then continue to determine whether the current component is the last component. If it is the last component, execute step S5.3.3. If it is not the last component, repeat step S5.3.2.15 for the next component.

[0035] Step S5.3.3: Check the path : Step S5.3.3.1, check components of the same class: Traversing the path First determine whether there are other components of the same category as the current component in the path or Path If yes, skip the current component check, and then continue to determine whether the current component is the last component. If it is the last component, execute step S6. If it is not the last component, repeat step S5.3.3.1 for the next component; otherwise, execute step S5.3.3.25.

[0036] Step S5.3.3.2: Handle the situation where there is no component of the same class Judging on the path and path Check if there are no components of the same category or the same component as the current component. If so, subtract a high probability minus point from the health of the current component. , and traverse the component pool at the same time, reducing the health of other components of the same category as the current component by a low probability deduction , then continue to determine whether the current component is the last component. If it is the last component, execute step S6. If it is not the last component, repeat step S5.3.3.1 for the next component. If not, do nothing. Then continue to determine whether the current component is the last component. If it is the last component, execute step S6. If it is not the last component, repeat step S5.3.3.15 for the next component.

[0037] Step S6: Health evaluation, the fault recovery module performs cleaning or offline operations on the identified faulty components according to their health: Step S6.1: Traverse all components in the component pool to determine whether the health of each component is less than the cleaning health threshold If yes, mark the current component as "needs cleaning", add 1 to its cleaning times, and then execute step S6.2; if no, do nothing.

[0038] Step S6.2: Determine whether the number of cleaning times has reached or exceeded the offline cleaning times threshold If it has been reached or exceeded, the current component will be marked as "need to be offline for inspection" and will be offline for inspection; otherwise, the cleaning operation will be performed, and after the cleaning is completed, the health level will be increased by two high probability points .

[0039] In a second aspect, the present invention provides a mimicry system component scheduling device, comprising: The component pool is responsible for storing all components in the system and provides dynamic scheduling and management functions.

[0040] The scheduling module is responsible for selecting appropriate components from the component pool and determining the execution path based on user request requirements and load balancing strategies.

[0041] The request distribution module is responsible for distributing user requests to the three execution paths selected by the scheduling module.

[0042] The arbitration module is responsible for checking the consistency of the execution results of the three execution paths selected by the scheduling module, and performing fault handling or returning a response to the user based on the check results.

[0043] The fault screening module is responsible for checking the components in each execution path in turn according to the differences in the execution results of the three execution paths selected by the scheduling module, and adjusting the health of each component in the path.

[0044] The fault recovery module is responsible for cleaning or offline processing of identified faulty components.

[0045] In a third aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method described.

[0046] In a fourth aspect, the present invention provides a computing device, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the described method is implemented.

[0047] The beneficial effects of the present invention are at least reflected in the following aspects: (1) Improve system fault tolerance: By dynamically monitoring the health status of components in each execution path, this method can quickly identify and handle problematic components when a fault occurs, ensuring that the system can still operate normally in the face of a fault. Such a fault-tolerant mechanism enables the system to remain stable in a complex operating environment, greatly reducing the risk of service interruption caused by a single point of failure.

[0048] (2) Enhance system stability: After detecting a fault, this method can automatically clean or offline the problematic component and select a component with a higher health level to continue the task. This strategy effectively prevents the spread of faults, improves the overall stability of the system, ensures the timely processing of user requests, and thus enhances the user experience.

[0049] (3) Reduce the impact on business processes: By quickly responding to and repairing faults, the invention significantly reduces the impact of faults on business processes. The system can be restored to normal in a very short time, ensuring business continuity and consistency. This is especially important for companies that rely on high-availability services and helps maintain a good business reputation.

[0050] (4) Reduced operation and maintenance costs: The fault self-healing mechanism of the present invention reduces the need for manual intervention and reduces system operation and maintenance costs. Through automated fault handling, the operation and maintenance team can focus on system optimization and innovation instead of spending a lot of time and resources on troubleshooting and repairing.

[0051] (5) Improve resource utilization efficiency: This method ensures that system resources are optimally configured by intelligently selecting components with higher health to perform tasks, thus avoiding idle resources caused by faulty components. This optimization makes the system run more efficiently and improves overall performance.

[0052] (6) Enhanced user experience: By ensuring high availability and stability of the system, users can enjoy a smoother and more reliable service experience. Rapid fault recovery capabilities and reduced system downtime can significantly improve user satisfaction and thus increase customer loyalty. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the technical solution of the present invention, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0054] Figure 1 It is a module flow chart of a mimicry system component scheduling device provided in an embodiment of the present invention.

[0055] Figure 2 It is a flow chart of a method for scheduling mimicry system components provided by an embodiment of the present invention.

[0056] Figure 3 It is a flowchart of the steps of troubleshooting different result paths of the method provided in an embodiment of the present invention.

[0057] Figure 4 It is a flowchart of the steps of checking all paths of the method provided in an embodiment of the present invention.

[0058] Figure 5 The method provided in the embodiment of the present invention is to troubleshoot different result paths. Step flow chart.

[0059] Figure 6 The method provided in the embodiment of the present invention is to troubleshoot different result paths. Step flow chart.

[0060] Figure 7 The method provided in the embodiment of the present invention is to troubleshoot different result paths. Step flow chart.

[0061] Figure 8 The method provided by the embodiment of the present invention is to check the path among all paths. Step flow chart.

[0062] Fig. 9 The method provided by the embodiment of the present invention is to check the path among all paths. Step flow chart.

[0063] Fig.10 The method provided by the embodiment of the present invention is to check the path among all paths. Step flow chart. DETAILED DESCRIPTION

[0064] The technical solutions in the embodiments of the present invention will be described clearly and completely below in conjunction with the accompanying drawings in the embodiments of the present invention.

[0065] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments are 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.

[0066] The terms "including" and "having" and any variations thereof mentioned in the embodiments of the present invention are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device including a series of steps or units is not limited to the listed steps or units, but may optionally include other steps or units that are not listed, or may optionally include other steps or units that are inherent to these processes, methods, products or devices.

[0067] Although component-based architecture brings many advantages, it also faces a series of challenges in practical applications. Especially under the complex dependencies between components, the failure of any component may lead to a decline in system performance or even complete failure. Traditional fault handling methods, such as redundant backup and manual repair, are often inefficient and cannot meet the needs of modern systems for high availability and automated repair. Although existing fault self-healing technologies have solved the problem of component failure to a certain extent, they are often unable to accurately and quickly locate faulty components when dealing with complex component dependencies. Some technologies rely on simple redundant backups and cannot perform intelligent switching and repair according to the actual operating status of the component when a component fails, resulting in system performance degradation and prolonged service interruption.

[0068] It can be seen from the above defects that at least there are problems in the prior art such as slow response speed and high misjudgment rate of the mimic system of the existing component architecture when handling faults. The present invention is based on dynamic monitoring and screening of the health status of components in each execution path, which can automatically clean or offline the problem components when a fault occurs, and intelligently select components with higher health to continue to execute tasks. Through this mechanism, the present invention greatly improves the fault tolerance and stability of the system and reduces the impact of faults on business processes. The dynamic monitoring method of the present invention is different from the prior art. It not only considers the basic operating parameters of the components, but also integrates the interactive information of the components in different execution paths and historical operation data. Through this multi-dimensional monitoring method, the health status of the components can be judged more accurately. In terms of intelligent selection of components, the present invention adopts a comprehensive evaluation strategy based on component health and path reliability, and gives priority to components with high health and strong path stability to continue to execute tasks. This is essentially different from the method based solely on backup priority or random selection in the prior art, thereby effectively improving the fault tolerance and execution efficiency of the system.

[0069] Based on this, an embodiment of the present invention provides a mimic system component scheduling device, such as Figure 1 include: The component pool is responsible for storing all components in the system and provides dynamic scheduling and management functions.

[0070] The scheduling module is responsible for selecting appropriate components from the component pool and determining the execution path based on user request requirements and load balancing strategies.

[0071] The request distribution module is responsible for distributing user requests to the three execution paths selected by the scheduling module.

[0072] The arbitration module is responsible for checking the consistency of the execution results of the three execution paths selected by the scheduling module, and performing fault handling or returning a response to the user based on the check results.

[0073] The fault screening module is responsible for checking the components in each execution path in turn according to the differences in the execution results of the three execution paths selected by the scheduling module, and adjusting the health of each component in the path.

[0074] The fault recovery module is responsible for cleaning or offline processing of identified faulty components.

[0075] The system operation process is as follows: The component-based mimicry system receives a user request After that, the scheduling module schedules according to the running status of each component in the component pool. The scheduling module will select three execution paths , and , and checks the minimum health of the components in each path. If the minimum health of the components in at least two paths is greater than the specified threshold, the system will use this path combination. Subsequently, the request distribution module distributes the request to the selected components, and the execution module starts to process the request. Next, the arbitration module performs a consistency check on the execution results of the three paths. If the results are inconsistent, the system will call auxiliary modules such as the fault screening module and the fault recovery module to handle the fault. Otherwise, the response is sent to the user.

[0076] like Figure 2 As shown, the embodiment of the present invention also provides a method for self-healing scheduling of component faults in a mimic system, which quickly detects and processes faulty components in the system through dynamic path selection and component health evaluation, thereby improving the robustness and reliability of the system; the main steps include: (1) Initialization: When the system is initialized, an initial health score is assigned to each component and the number of cleanings is initialized to 0.

[0077] (2) Request scheduling: According to the load balancing strategy, three execution paths are selected for each request, and the minimum health of the components in each path is checked.

[0078] (3) Request distribution: The request is distributed to the three selected execution paths; each component of each execution path executes the request in turn and returns the execution results of each path to the arbitration module.

[0079] (4) Execution result consistency check: Compare the execution results of the three paths. If they are inconsistent, the system enters the fault screening state.

[0080] (5) Fault screening: Check the components in each path in turn and adjust the health of each component in the path.

[0081] (6) Health Assessment: Perform health assessment and perform cleaning or offline operations.

[0082] The above method is specifically: Step S1: System initialization When the system is initialized, each component is first assigned an initial health value (The default setting in this embodiment is 30), and the number of cleanings is initialized to 0. When the system is initialized, the initial health value of each component can be determined more flexibly. In addition to the default setting of 30, it can be considered comprehensively based on factors such as the importance of the component, the past failure rate, and the degree of business dependence on the component. For example, for some core and fault-prone components, the initial health value can be appropriately lowered so that more attention can be paid to them in the early stages of operation. At the same time, for components in different business modules, the initial health value can be set according to the priority of the business to ensure that the health of key business-related components can be more accurately evaluated and monitored. At the same time, the following system parameters also need to be set:

[0083] (1) High probability of deduction :This parameter is mainly used to quickly reduce the health of a component when a problem occurs that may seriously affect the operation of the system. For example, for a system such as a financial trading system that requires extremely high accuracy and stability, It can be set to a larger value, such as 8-10. This is because any component failure in financial transactions may result in significant losses, and the problem components need to be marked in time for quick processing.

[0084] (2) Medium to high probability of deduction : The value depends on the importance of the component and the probability of failure. For core components with a relatively high probability of failure, it can be set to 4-5; for non-core components, it can be set to 2-3.

[0085] (3) Low to medium probability of deduction : Generally, it can be set to 1-2 to appropriately adjust the health of a component when some problems that are not serious but still require attention occur.

[0086] (4) Low probability deduction : Usually set to 0.5-1, used to fine-tune component health, for example, when component performance fluctuates slightly but does not affect overall runtime.

[0087] (5) Cleaning health threshold : If the system maintenance cost is low and the business has extremely high requirements for continuity, the cleaning health threshold can be appropriately increased, such as setting it to 18-20, to reduce unnecessary component offline operations; for general commercial application systems, it can be set to 12-15.

[0088] (6) Offline cleaning times threshold : For systems with extremely high stability requirements and that cannot withstand frequent component replacement, the offline cleaning threshold can be set to 1-2; for general enterprise-level applications, it can be set to 3-5.

[0089] (7) Minimum health threshold of path components : When the system load is high, in order to ensure that the system can select a healthier combination of components to perform tasks, the threshold can be appropriately lowered. For example, during e-commerce promotions, the system load increases significantly, and the threshold can be lowered from the default 15 to 10-12.

[0090] Step S2: Request scheduling When the system receives a user request, the scheduling module selects three execution paths for each request according to the load balancing strategy and execution needs, which are recorded as Each execution path consists of multiple components in the component pool.

[0091] The system checks the minimum health of the components in each path. If the minimum health of the components in at least two paths is greater than the set threshold, (As mentioned earlier, it may be 10-15 depending on the system situation), then this path combination is selected for execution; otherwise, three execution paths are reselected.

[0092] Step S3: Request distribution The request distribution module distributes the request to the three execution paths selected by the scheduling module; each component of each execution path executes the request in turn and returns the execution results of each path to the arbitration module.

[0093] Step S4: Check the consistency of the execution results The arbitration module compares the execution results of the three execution paths selected by the scheduling module , If the execution results are exactly the same, the system considers the execution to be normal, and then traverses all components of the three paths and increases the health of each component by one. , then execute step S6; if the execution results are not completely consistent, it is considered that the system enters the fault screening state, and then executes step S5 fault screening. The system checks the components in each path one by one and performs corresponding processing according to different fault scenarios.

[0094] Components Health The constraints are .

[0095] Step S5, fault screening and recovery: the fault screening module checks the components in each execution path in turn according to the difference in execution results, and adjusts the health of each component in the path; Step S5.1, determine whether the execution results of only two paths are the same, if so, execute step S5.2, if not, execute step S5.3; Step S5.2: Check different result paths, and the two paths with the same execution results are recorded as and , and another path with different execution results is recorded as ; Specifically: Step S5.2.1: Check paths with different execution results ; Specifically: Step S5.2.1.1, check the same components: Traversing the path If the current component is in the path or Path If it exists in the system, the health of the current component remains unchanged. At the same time, considering the impact of the association between components, if the associated components of the component (determined by the pre-set association rules) also have problems in other paths, the deduction can be appropriately increased, such as an additional deduction of 0.5-1 (the specific value can be determined based on the degree of association and system experience). Then continue to determine whether the current component is the last component. If it is the last component, execute step S5.2.2. If it is not the last component, repeat the current step for the next component. If it does not exist, execute step S5.2.1.2.

[0096] Step S5.2.1.2 Check components of the same class: If other components of the same category as the current component are in the path or Path If it exists in , the health of these components of the same type will be subtracted . For these components of the same type, if their number in other paths is large (for example, more than 50% of the total number of components in the path), consider subtracting an additional 0.5-1 health score from all instances of this type of component in this path to highlight the focus on components of this type that may have common problems. Then continue to determine whether the current component is the last component. If it is the last component, execute step S5.2.2. If it is not the last component, repeat step S5.2.1.1 for the next component. If it does not exist, execute step S5.2.1.3;

[0097] Step S5.2.1.3: Handle the situation where there is no component of the same class: If other components of the same category as the current component are in the path or Path If it does not exist in the component, the health of the component will be reduced by one. . At the same time, traverse the component pool and subtract the health of other components of the same class from Then continue to determine whether the current component is the last component. If it is the last component, execute step S5.2.2. If it is not the last component, repeat step S5.2.1.1 for the next component. In this process, if it is found that the overall health of the module to which the component belongs (the module division can be pre-set according to the system architecture) is low (for example, the average health of the components in the module is lower than 60% of the average health of the system), the health score of all components in the module can be uniformly subtracted by 1-2 to prompt further inspection and maintenance of the module.

[0098] Step S5.2.2: Check the path ; Specifically: Step S5.2.2.1, check components of the same class: Traversing the path If there are other components of the same category as the current component in the path does not exist in the path If it exists, directly subtract the health of the current component from Then continue to determine whether the current component is the last component. If it is the last component, execute step S5.2.3. If it is not the last component, repeat step S5.2.2.1 for the next component. If it does not exist, execute step S5.2.2.2.

[0099] If other components of the same class are in the path If the health of the component is also low (for example, less than 10), the deduction of the score for this component can be increased, such as an additional deduction of 1-2. If these components of the same type are more important in the system (for example, they are key business logic processing components), the health score of all components of the same type can be uniformly deducted by an additional 0.5-1.

[0100] Step S5.2.2.2: Handle the situation where there is no component of the same class: If other components of the same category as the current component are in the path and path There is no same class, traverse the component pool, and subtract the health of all other components of the same class from . Then continue to determine whether the current component is the last component. If it is the last component, execute step S5.2.3. If it is not the last component, repeat step S5.2.2.1 for the next component. Otherwise, do nothing. Then continue to determine whether the current component is the last component. If it is the last component, execute step S5.2.3. If it is not the last component, repeat step S5.2.2.1 for the next component. If other components on the server node where the component is located (assuming that the system adopts a distributed architecture and the components are deployed on different nodes) also have many problems (for example, more than 30% of the components on the same node have a health level lower than 12), all components on the node can be uniformly subtracted from an additional 1-2 health score to prompt the node to be inspected and maintained.

[0101] Step S5.2.3: Check the path ; Specifically: Step S5.2.3.1, check components of the same class: Traversing the path If there are other components of the same category as the current component in the path or Path If it exists, skip the current component check; then continue to determine whether the current component is the last component. If it is the last component, execute step S6. If it is not the last component, repeat step S5.2.3.1 for the next component. If it does not exist, execute step S5.2.3.2.

[0102] Step S5.2.3.2: Handle the situation where there is no component of the same class: If the component is in the path and path If there is no component of the same class or the same component in the component pool, traverse the component pool and reduce the health of all other components of the same class as the component by a low probability deduction Then continue to determine whether the current component is the last component. If it is the last component, execute step S6. If it is not the last component, repeat step S5.2.3.1 for the next component. If the resource usage of the component (such as CPU, memory, etc.) is obviously abnormal (for example, more than 200% of the average resource usage of components of the same type), its health can be further subtracted by 2-3 to highlight the processing of resource abnormal components.

[0103] Step S5.3, check all paths; Figure 4 Specifically: Step S5.3.1, check the path ;like Figure 8 Specifically: S5.3.1.1. Check components of the same class: Traversing the path For all components in the , first determine whether the current component also has a path or Path If it exists, the health of the current component will be directly reduced by a low probability deduction. , and then continue to determine whether the current component is the last component. If it is the last component, execute step S5.3.1.2. If it is not the last component, repeat the current step for the next component; if it does not exist, continue to determine whether there is a path for other components of the same category as the current component or Path If there is a path or Path The health of components of the same category as the current component is subtracted , and then continue to determine whether the current component is the last component. If it is the last component, execute step S5.3.1.2. If it is not the last component, repeat the current step for the next component. If there is no path or Path , then execute step S5.3.1.2.

[0104] S5.3.1.2. Handling the situation where there is no component of the same class: Subtract one from the health of the current component , and traverse the component pool at the same time, subtract the health of other components of the same category as the current component , then continue to determine whether the current component is the last component. If it is the last component, execute step S5.3.1.2. If it is not the last component, repeat step S5.3.1.1 for the next component; otherwise, execute step S5.3.2.

[0105] Step S5.3.2: Check the path ;like Fig. 9 Specifically: Step S5.3.2.1: Check components of the same class Traversing the path All components in the , first determine whether the current component has a path If yes, skip the current component check, and then continue to determine whether the current component is the last component. If it is the last component, execute step S5.3.3. If it is not the last component, repeat step S5.3.2.1 for the next component.

[0106] If not, continue to determine whether other components of the same category as the current component do not have paths But there is a path If so, directly subtract the low probability deduction from the health of the current component. , then continue to determine whether the current component is the last component. If it is the last component, execute step S5.3.3. If it is not the last component, repeat step S5.3.2.1 for the next component; otherwise, execute step S5.3.2.2.

[0107] Step S5.3.2.2: Handle the situation where there is no component of the same class: Determine whether the current component is in the path and path There are no identical classes. If so, the health of the current component is subtracted from , and traverse the component pool at the same time, subtracting the health of all other components of the same category as the current component , then continue to determine whether the current component is the last component. If it is the last component, execute step S5.3.3. If it is not the last component, repeat step S5.3.2.1 for the next component; otherwise, do nothing, and then continue to determine whether the current component is the last component. If it is the last component, execute step S5.3.3. If it is not the last component, repeat step S5.3.2.1 for the next component.

[0108] Step S5.3.3: Check the path ,like Figure 6 Specifically: Step S5.3.3.1, check components of the same class: Traversing the path First determine whether there are other components of the same category as the current component in the path or Path If yes, skip the current component check, and then continue to determine whether the current component is the last component. If it is the last component, execute step S6. If it is not the last component, repeat step S5.3.3.1 for the next component; otherwise, execute step S5.3.3.2.

[0109] Step S5.3.3.2: Process the situation where there is no component of the same class: Judging on the path and path Check if there are no components of the same category or the same component as the current component. If so, subtract a high probability minus point from the health of the current component. , and traverse the component pool at the same time, reducing the health of other components of the same category as the current component by a low probability deduction , then continue to determine whether the current component is the last component. If it is the last component, execute step S6. If it is not the last component, repeat step S5.3.3.1 for the next component. If not, do nothing. Then continue to determine whether the current component is the last component. If it is the last component, execute step S6. If it is not the last component, repeat step S5.3.3.1 for the next component.

[0110] Step S6: Health evaluation, the fault recovery module performs cleaning or offline operations on the identified faulty components according to their health: Step S6.1: Traverse all components in the component pool to determine whether the health of each component is less than the cleaning health threshold If yes, mark the current component as "needs cleaning", add 1 to its cleaning times, and then execute step S6.2; if no, do nothing.

[0111] Step S6.2: Determine whether the number of cleaning times has reached or exceeded the offline cleaning times threshold If it has been reached or exceeded, the current component will be marked as "need to be offline for inspection" and will be offline for inspection; otherwise, the cleaning operation will be performed, and after the cleaning is completed, the health level will be increased by two high probability points .

[0112] Based on the above-mentioned mimicry system component scheduling method, the following embodiment operations are performed.

[0113] Example 1: The health of a microservice component decreases but self-heals successfully Fault scenario description A web application request goes through three execution paths , and , where the path A microservice component An exception occurs, causing the execution result returned by the path Execution results with the other two paths and Inconsistency. This case can represent a situation in which a single component failure affects the execution results of a local path in a distributed microservice architecture. In actual applications, such as the order processing service in an e-commerce system, a component failure in a submodule may cause an exception in a certain path of the order processing process.

[0114] Fault screening and repair (1) System discovery The results are different. First check All microservice components in: Components Only exists in the path , the health value decreases by 5. Since the health value drops from 20 to 15, it is still higher than the cleaning threshold (assuming that the cleaning threshold is set to 12 according to the system), so it is marked as "can continue to be used". In this process, the component can be recorded Detailed fault information, such as the time when the exception occurred and related request parameters, is provided for subsequent analysis and optimization.

[0115] For components After cleaning, the health level increases by 10 and returns to 25. At this time, the number of cleanings is 1, and the offline condition has not been met. During the cleaning operation, the relevant data of the cleaning process can be recorded in detail, such as the algorithm parameters used for cleaning, the performance index changes of the components before and after cleaning, etc., to provide a reference for similar failures that may occur later.

[0116] (2) Path and The health of the microservice components in the cleanup process has not changed, and the troubleshooting is complete. The system returns to normal state and resumes normal operation at the next request. In this case, the system's self-healing ability for single component failures and how to ensure the normal operation of the system through reasonable health threshold settings and cleaning operations are emphasized.

[0117] Example 2: The health of microservice components in multiple paths deteriorates and causes offline Fault scenario description A user request goes through three execution paths and , the results show and If the paths are all different, it means that one or more components in each path are faulty. This situation can be compared to a complex business system where components involved in multiple sub-business processes have problems at the same time, affecting the normal execution of the entire business. For example, in a logistics management system, components involved in the three sub-processes of shipping, transportation, and receiving fail on three paths respectively, causing abnormalities in the entire logistics process.

[0118] Fault screening and repair (1) The system checks all components of the three paths in turn: On the path In the component It only exists in this path, and the health value decreases by 5 to 10. Since the health value is still greater than 5 (here, the offline threshold is assumed to be 5), the cleaning operation is performed and the health value is restored to 20. During the cleaning process, the components can be monitored. If you find that the resource usage during the cleaning process is too high (more than 150% of the normal situation), you can optimize and adjust it, such as adjusting its memory allocation strategy.

[0119] On the path In the component Only exists in this path, health reduced by 5, down to 3. At this time, mark The number of cleanings increases by 1. Since the health level increases by 10 after cleaning, the total health level reaches 13. During this process, components can be analyzed. The cause of the failure is to check whether it is caused by abnormal interaction with other components. If so, the relevant interaction logic can be checked and repaired.

[0120] On the path In the component The health level decreases by 5, and when it drops to 5, the cleaning operation is performed. Since the number of cleaning times for this component has reached 2, it is marked as "need to be offline for inspection" and the component is offline. The system automatically selects a spare component to replace it. When selecting backup components, you can conduct a comprehensive evaluation based on the performance indicators and historical usage of the backup components to select the most suitable backup components to ensure system stability and performance.

[0121] (2) Self-healing results The system successfully repaired the fault by cleaning and removing components from the three faulty paths. Faulty components in The system was replaced and the stability was restored. Due to the timely repair, there was no obvious interruption in the business. This case emphasizes the system's ability to handle multi-path component failures and how to ensure business continuity through reasonable health assessment and component replacement strategies.

[0122] Example 3: Multiple components on a single path fail and go offline Fault scenario description A user request goes through three execution paths , and ,path Multiple components of the same path fail, resulting in inconsistent execution results with the other two paths. This is similar to a core business process where multiple key components fail at the same time, seriously affecting the normal operation of the business. For example, in a bank transfer system, the three key components of transfer verification, amount deduction, and account update fail on the same path, resulting in the transfer operation being unable to complete normally.

[0123] Fault screening and repair (1) The system starts to check the path Components The health value decreases by 5 to 12, which does not reach the cleaning threshold (assuming the cleaning threshold is 10 here), so no repair is required. During this process, the components can be recorded. The health changes and related business operation information of the enterprise are collected to facilitate subsequent analysis to determine whether the health threshold needs to be adjusted.

[0124] Components When the health drops to 4, it is marked as "needs cleaning" and cleaned once, and the health increases to 14. The number of cleanings is 1. During the cleaning process, components can be cleaned. The internal state of the system is checked in detail, such as whether its data structure is complete and whether the algorithm logic is correct, to determine whether the fault is actually repaired.

[0125] Components The health level dropped to 2, and after cleaning, it returned to 12. However, since it had been cleaned twice, it was marked as "need to be offline for testing". Before starting the backup component, you can preload and initialize it to ensure that it can quickly take over the work of the failed component and reduce business interruption time.

[0126] (2) Self-healing results path Components in The system was successfully restored after being replaced. As the backup component intervened in time, the business was not interrupted and the system performance remained stable. This case shows the system's strategy for handling single-path multiple component failures and how to ensure the normal operation of the system and business continuity through a reasonable component repair and replacement mechanism.

[0127] The above is a preferred embodiment of the present invention. It should be pointed out that a person skilled in the art can make several improvements and modifications without departing from the principle of the present invention. These improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A method for scheduling components of a mimicking system supporting self-healing of faults, characterized in that The method comprises the following steps: Step S1: System initialization When the system is initialized, an initial health value is assigned to each component , and initialize the number of cleaning times to 0; at the same time set the following system parameters: high probability deduction , medium to high probability of deduction , medium and low probability points reduction , low probability reduction , Cleaning health threshold , Offline cleaning times threshold The minimum health threshold of the components of the path ; Step S2: Request scheduling When the system receives a request, the scheduling module selects three execution paths for each request based on the load balancing strategy. Then, it checks the minimum health of the components in each execution path. If the minimum health of the components in at least two execution paths is greater than , then select the current three execution paths, otherwise reselect three execution paths; Step S3: Request distribution The request distribution module distributes the request to the three execution paths selected by the scheduling module; each component of each execution path executes the request in turn and returns the execution results of each path to the arbitration module; Step S4: Check the consistency of the execution results The arbitration module compares the execution results of the three execution paths selected by the scheduling module; if the execution results are exactly the same, it traverses all components of the three paths and increases the health of each component by one. , then execute step S6; if the execution results are not completely consistent, it is considered that the system enters the fault screening state, and then execute step S5; Step S5: Fault screening and recovery The fault screening module checks the components in each execution path in turn according to the differences in the execution results, and adjusts the health of each component in the path; Step S6: Health evaluation. The fault recovery module cleans or takes offline the identified faulty components according to their health.

2. The method according to claim 1, characterized in that: Components Health The constraints are .

3. The method according to claim 1, characterized in that: The specific steps of step S5 are as follows: Step S5.1, determine whether the execution results of only two paths are the same, if so, execute step S5.2, if not, execute step S5.3; Step S5.2: Check different result paths, and the two paths with the same execution results are recorded as and , and another path with different execution results is recorded as ; Step S5.3: Check all paths.

4. The method according to claim 3, characterized in that: Step S5.2 specifically includes: Step S5.2.1: Check paths with different execution results ; Specifically: Step S5.2.1.1, check the same components: Traversing the path For all components in the , first determine whether the current component also has a path or Path If it exists, the health of the current component remains unchanged, and then continue to determine whether the current component is the last component. If it is the last component, execute step S5.2.

2. If it is not the last component, repeat the current step for the next component; if it does not exist, execute step S5.2.1.2; Step S5.2.1.2 Check components of the same class: Determine if there is a path for a component of the same category as the current component or Path If it exists, traverse the component pool and subtract the health of other components of the same category as the current component. , then continue to determine whether the current component is the last component. If it is the last component, execute step S5.2.

2. If it is not the last component, repeat step S5.2.1.1 for the next component; if it does not exist, execute step S5.2.1.3; Step S5.2.1.3: Handle the situation where there is no component of the same class: Subtract the health of the current component from , and traverse the component pool at the same time, subtract the health of other components of the same category as the current component , then continue to determine whether the current component is the last component, if it is the last component, execute step S5.2.2, if it is not the last component, repeat step S5.2.1.1 for the next component; Step S5.2.2: Check the path ; Specifically: Step S5.2.2.1, check components of the same class: Traversing the path All components in the current component are checked to see if there are no other components of the same category as the current component. But there is a path If so, subtract the health of the current component from , then continue to determine whether the current component is the last component. If it is the last component, execute step S5.2.

3. If it is not the last component, repeat step S5.2.2.1 for the next component; if it does not exist, execute step S5.2.2.2; Step S5.2.2.2: Handle the situation where there is no component of the same class: Determine whether other components of the same category as the current component do not have paths and If so, traverse the component pool and subtract all other components of the same category as the current component. , then continue to determine whether the current component is the last component. If it is the last component, execute step S5.2.

3. If it is not the last component, repeat step S5.2.2.1 for the next component; otherwise, do nothing, and then continue to determine whether the current component is the last component. If it is the last component, execute step S5.2.

3. If it is not the last component, repeat step S5.2.2.1 for the next component; Step S5.2.3: Check the path ; Specifically: Step S5.2.3.1, check components of the same class: Traversing the path All components in the current component, determine whether there are other components of the same category as the current component. or Path If yes, the health of the current component remains unchanged, and then continue to determine whether the current component is the last component. If yes, execute step S6. If not, repeat step S5.2.3.1 for the next component; otherwise, execute step S5.2.3.

2. Step S5.2.3.2: Handle the situation where there is no component of the same class: Traverse the component pool and subtract the health of other components of the same category as the current component , then continue to determine whether the current component is the last component. If it is the last component, execute step S6. If it is not the last component, repeat step S5.2.3.1 for the next component.

5. The method according to claim 4, characterized in that: Step S5.3 specifically includes: Step S5.3.1, check the path ; Specifically: S5.3.1.

1. Check components of the same class: Traversing the path For all components in the , first determine whether the current component also has a path or Path If it exists, the health of the current component will be directly reduced by a low probability deduction. , and then continue to determine whether the current component is the last component. If it is the last component, execute step S5.3.1.

2. If it is not the last component, repeat the current step for the next component; if it does not exist, continue to determine whether there is a path for other components of the same category as the current component or Path If there is a path or Path The health of components of the same category as the current component is subtracted , and then continue to determine whether the current component is the last component. If it is the last component, execute step S5.3.1.

2. If it is not the last component, repeat the current step for the next component. If there is no path or Path , then execute step S5.3.1.2; S5.3.1.

2. Handling the situation where there is no component of the same class: Subtract one from the health of the current component , and traverse the component pool at the same time, subtract the health of other components of the same category as the current component , then continue to determine whether the current component is the last component, if it is the last component, execute step S5.3.1.2, if it is not the last component, repeat step S5.3.1.1 for the next component; otherwise, execute step S5.3.2; Step S5.3.2: Check the path ; Specifically: Step S5.3.2.1: Check components of the same class Traversing the path All components in the , first determine whether the current component has a path If yes, skip the current component check, and then continue to determine whether the current component is the last component. If it is the last component, execute step S5.3.

3. If it is not the last component, repeat step S5.3.2.1 for the next component. If not, continue to determine whether other components of the same category as the current component do not have paths But there is a path If so, directly subtract the low probability deduction from the health of the current component. , then continue to determine whether the current component is the last component, if it is the last component, execute step S5.3.3, if it is not the last component, repeat step S5.3.2.1 for the next component; otherwise, execute step S5.3.2.2; Step S5.3.2.2: Handle the situation where there is no component of the same class: Determine whether the current component is in the path and path There are no identical classes. If so, the health of the current component is subtracted from , and traverse the component pool at the same time, subtracting the health of all other components of the same category as the current component , then continue to determine whether the current component is the last component, if it is the last component, execute step S5.3.3, if it is not the last component, repeat step S5.3.2.1 for the next component; otherwise, do nothing, then continue to determine whether the current component is the last component, if it is the last component, execute step S5.3.3, if it is not the last component, repeat step S5.3.2.1 for the next component; Step S5.3.3: Check the path ; Specifically: Step S5.3.3.1, check components of the same class: Traversing the path First determine whether there are other components of the same category as the current component in the path or Path If yes, skip the current component check, and then continue to determine whether the current component is the last component. If yes, execute step S6. If not, repeat step S5.3.3.1 for the next component. Otherwise, execute step S5.3.3.

2. Step S5.3.3.2: Handle the situation where there is no component of the same class Judging on the path and path Check if there are no components of the same category or the same component as the current component. If so, subtract a high probability minus point from the health of the current component. , and traverse the component pool at the same time, reducing the health of other components of the same category as the current component by a low probability deduction , then continue to determine whether the current component is the last component, if it is the last component, execute step S6, if it is not the last component, repeat step S5.3.3.1 for the next component; otherwise, do nothing, and then continue to determine whether the current component is the last component, if it is the last component, execute step S6, if it is not the last component, repeat step S5.3.3.1 for the next component; The method according to claim 1 is characterized in that step S6 specifically comprises: Step S6.1: Traverse all components in the component pool to determine whether the health of each component is less than the cleaning health threshold If yes, the fault recovery module marks the current component as "needs cleaning", adds 1 to its cleaning times, and then executes step S6.2; if no, no operation is performed; Step S6.2: Determine whether the number of cleaning times has reached or exceeded the offline cleaning times threshold If it has been reached or exceeded, the current component will be marked as "need to be offline for inspection", and the fault recovery module will take it offline for inspection; otherwise, the cleaning operation will be performed, and after the cleaning is completed, the health level will be increased by two high probability deduction points .

6. A mimic system component scheduling device for implementing the method described in any one of claims 1 to 5, characterized in that include: The component pool is responsible for storing all components in the mimic system; The scheduling module is responsible for selecting appropriate components from the component pool and determining the execution path based on user request requirements and load balancing strategies; The request distribution module is responsible for distributing user requests to the three execution paths selected by the scheduling module; The arbitration module is responsible for checking the consistency of the execution results of the three execution paths selected by the scheduling module, and performing fault handling or returning a response to the user based on the check results; The fault screening module is responsible for checking the components in each execution path in turn according to the differences in the execution results of the three execution paths selected by the scheduling module, and adjusting the health of each component in the path; The fault recovery module is responsible for cleaning or offline processing of identified faulty components.

7. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to any one of claims 1 to 5.

8. A computing device, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 5 is implemented.

Images