A method and apparatus for scheduling components in a mimicry system that supports fault self-healing.

Abstract

This invention discloses a component scheduling method and apparatus for a mimicry system that supports fault self-healing. Based on dynamic monitoring and screening of the health status of components in each execution path, it can automatically clean up or take offline problematic components when a fault occurs, and intelligently select components with higher health to continue executing the task. This invention not only considers the basic operating parameters of components but also integrates the interaction information of components in different execution paths and historical operating data. This multi-dimensional monitoring method enables more accurate judgment of component health status. Regarding intelligent component selection, this invention adopts a comprehensive evaluation strategy based on component health and path reliability, prioritizing components with high health and strong path stability to continue executing the task. This is fundamentally different from existing technologies that simply rely on backup priority or random selection, thereby effectively improving the system's fault tolerance and execution efficiency.

Description

Technical Field

[0001] This invention belongs to the field of computer network technology, and specifically relates to a component scheduling method and apparatus for a mimicry system that supports fault self-healing. This invention primarily addresses the problems of slow response speed and high false positive rate in component-based mimicry systems when handling faults, by improving the availability and stability of the system through an intelligent scheduling algorithm and self-healing mechanism. Background Technology

[0002] In the field of modern information technology, the demand for building complex application systems is growing daily. To address this challenge, component-based architecture has emerged 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 responsible for a specific functional module, thereby achieving design goals of flexibility, scalability, and ease of 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 technical diversity and development flexibility.

[0004] (2) Scalability: The system can independently expand specific components according to 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 entire system to collapse, thus improving the robustness and reliability of the system.

[0006] (4) Rapid iteration: Small components facilitate rapid updates and deployment, making feature updates and defect fixes faster, which helps to achieve rapid product iteration and market response.

[0007] While component-based architectures offer numerous advantages, they also face a range of challenges in practical applications. Particularly with complex dependencies between components, the failure of any component can lead to performance degradation or even complete system failure. Traditional fault handling methods, such as redundancy backups and manual repairs, are often inefficient and cannot meet the demands of modern systems for high availability and automated recovery.

[0008] Mimetic systems enhance system resilience and adaptability by introducing diverse and dynamically reconfigurable techniques, and facilitate fine-grained fault isolation and recovery. Compared to traditional component architectures, component-based mimetic systems exhibit greater flexibility and efficiency when facing different types of faults.

[0009] While existing fault self-healing technologies have addressed component failure issues to some extent, they often fail to accurately and quickly locate faulty components when dealing with complex component dependencies. Some technologies rely on simple redundancy backups, which cannot intelligently switch and repair components based on their actual operating status when they fail, leading to degraded system performance and excessively long service interruptions.

[0010] In component-based architectures, component failures are inevitable. While existing fault detection and recovery solutions can address the issue to some extent, they still have the following limitations:

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

[0012] (2) Insufficient processing accuracy: The existing solution has a high misjudgment rate, which may misjudge normally operating components as faulty services, leading to unnecessary cleaning or offline operations, thereby affecting business continuity.

[0013] To improve system reliability, component-based mimicry systems require an intelligent self-healing mechanism that can monitor the status of each component in real time, automatically detect faults, and take corrective measures.

[0014] To address the aforementioned issues, this invention proposes a component scheduling method and apparatus for a mimicry system that supports self-healing. This method is based on dynamic monitoring and filtering of the health status of components in each execution path. When a fault occurs, it can automatically clean up or take offline problematic components and intelligently select components with higher health to continue executing tasks. Through this mechanism, this invention significantly 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] Terminology Explanation

[0016] Components: Components are small, independent, loosely coupled functional modules, each with a specific responsibility. They can be developed and deployed independently and support different programming languages ​​and technology stacks. Summary of the Invention

[0017] The purpose of this invention is at least to solve the problems of slow response speed and high false judgment rate when the existing component architecture of the mimicry system is handled by faults. It provides a mimicry system component scheduling method and device that supports fault self-healing, which can automatically monitor the operating status of each component and take quick repair measures when a fault is detected, thereby ensuring the high availability of the system.

[0018] The present invention is implemented as follows: Firstly, the present invention provides a method for scheduling components of a mimicry system that supports fault self-healing, comprising the following steps:

[0019] Step S1: System Initialization

[0020] During system initialization, each component is assigned an initial health value. The number of cleaning cycles is initialized to 0; simultaneously, the following system parameters are set: high probability of deduction. Medium to high probability of deduction Low to medium probability of deduction Low probability of deduction Cleaning health threshold Threshold for the number of offline cleaning cycles Minimum health threshold for components along the path .

[0021] Step S2: Request scheduling

[0022] When the system receives a request, the scheduling module selects three execution paths for each request based on the load balancing strategy. Next, it checks the minimum health of the components in each execution path. If at least two execution paths have components with a minimum health greater than [a certain value], [the system will proceed as planned]. If the current three execution paths are selected, then the three execution paths will be selected; otherwise, three new execution paths will be selected.

[0023] Each execution path consists of multiple components from the component pool.

[0024] Step S3, request distribution

[0025] 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 sequence and returns the execution results of each path to the adjudication module.

[0026] Step S4: Execution result consistency check

[0027] The adjudication module compares the execution results of the three execution paths selected by the scheduling module; if the execution results are completely consistent, it iterates through all components of the three paths and increments the health of each component by one. Then proceed to step S6; if the execution results are not completely consistent, the system is considered to have entered the fault screening state, and then proceed to step S5.

[0028] Components health The constraints are .

[0029] Step S5: Fault Screening and Recovery

[0030] The fault screening module checks the components in each execution path sequentially based on the differences in execution results and adjusts the health of each component in the path accordingly; the specific steps are as follows:

[0031] Step S5.1: Determine whether the execution results of only two paths are the same. If so, proceed to step S5.2; otherwise, proceed to step S5.3.

[0032] Step S5.2: Investigate different result paths, and record the two paths with the same execution result as... and Another path with a different execution result is denoted as Specifically:

[0033] Step S5.2.1: Investigate paths with different execution results. Specifically:

[0034] Step S5.2.1.1: Check identical components:

[0035] Path traversal For all components, first check if the current component also has a path. or path If the current component's health status remains unchanged, then it continues to determine whether the current component is the last component. If it is the last component, then step S5.2.2 is executed. If it is not the last component, then the current step is repeated for the next component. If the current component does not exist, then step S5.2.1.2 is executed.

[0036] Step S5.2.1.2 Check for components of the same class:

[0037] Determine if a path exists for a component of the same category as the current component. or path If the current component exists, iterate through the component pool and deduct the health score of all other components of the same category as the current component. Then, it continues to determine whether the current component is the last component. If it is the last component, step S5.2.2 is executed. If it is not the last component, step S5.2.1.1 is executed again for the next component. If it does not exist, step S5.2.1.3 is executed.

[0038] Step S5.2.1.3: Handling the case where there are no components of the same class:

[0039] Subtract the current component's health. Simultaneously, iterate through the component pool and subtract the health score of all other components of the same category as the current component. Then, it continues to determine whether the current component is the last component. If it is the last component, step S5.2.2 is executed. If it is not the last component, step S5.2.1.1 is executed again for the next component.

[0040] Step S5.2.2, Troubleshooting Path Specifically:

[0041] Step S5.2.2.1: Check for components of the same class:

[0042] Path traversal For all components, determine if other components of the same category as the current component do not exist in the path. But a path exists. If so, then subtract the current component's health. Then, it continues to determine whether the current component is the last component. If it is the last component, step S5.2.3 is executed. If it is not the last component, step S5.2.2.1 is executed again for the next component. If it does not exist, step S5.2.2.2 is executed.

[0043] Step S5.2.2.2: Handling the case where there are no components of the same class:

[0044] Determine if no other components of the same category as the current component have a path. and If so, then iterate through the component pool and subtract all other components of the same category as the current component. Then, it continues to determine whether the current component is the last component. If it is the last component, it executes step S5.2.3. If it is not the last component, it repeats step S5.2.2.1 for the next component. Otherwise, it does not perform any operation and continues to determine whether the current component is the last component. If it is the last component, it executes step S5.2.3. If it is not the last component, it repeats step S5.2.2.1 for the next component.

[0045] Step S5.2.3, Troubleshooting Path Specifically:

[0046] Step S5.2.3.1: Check for components of the same class:

[0047] Path traversal For all components in the current component, determine if other components of the same category as the current component exist. or path If the current component's health remains unchanged, then it continues to determine whether the current component is the last component. If it is the last component, then step S6 is executed. If it is not the last component, then step S5.2.3.1 is repeated for the next component. Otherwise, step S5.2.3.2 is executed.

[0048] Step S5.2.3.2: Handling the case where there are no components of the same class:

[0049] Iterate through the component pool and subtract the health score of all other components of the same category as the current component. Then, it continues to determine whether the current component is the last component. If it is the last component, step S6 is executed. If it is not the last component, step S5.2.3.1 is repeated for the next component.

[0050] Step S5.3: Investigate all paths; specifically:

[0051] Step S5.3.1, Troubleshooting Path Specifically:

[0052] S5.3.1.1, Check for components of the same class:

[0053] Path traversal For all components, first check if the current component also has a path. or path If it exists, then directly subtract a low-probability deduction from the current component's health score. Then, it continues to determine whether the current component is the last component. If it is the last component, it executes step S5.3.1.2; if it is not the last component, it repeats the current step for the next component. If it does not exist, it continues to determine whether other components of the same category as the current component have paths. or path If a path exists or path Then subtract the health score of all components of the same category as the current component. Then, it continues to determine whether the current component is the last component. If it is the last component, it executes step S5.3.1.2; if it is not the last component, it repeats the current step for the next component. If no path exists... or path Then proceed to step S5.3.1.2.

[0054] S5.3.1.2 Handling the case where there are no components of the same class:

[0055] Subtract one from the current component's health. Simultaneously, iterate through the component pool and subtract the health score of all other components of the same category as the current component. Then, it continues to determine whether the current component is the last component. If it is the last component, it executes step S5.3.1.2. If it is not the last component, it repeats step S5.3.1.1 for the next component. Otherwise, it executes step S5.3.2.

[0056] Step S5.3.2, Troubleshooting Path Specifically:

[0057] Step S5.3.2.1: Check for components of the same class.

[0058] Path traversal For all components, first check if the current component has a path. If the current component is not the last component, skip the current component check and continue to determine if 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.

[0059] Otherwise, continue to check if other components of the same category as the current component do not exist. But a path exists. If so, then directly subtract the low-probability deduction from the current component's health score. Then, it continues to determine whether the current component is the last component. If it is the last component, step S5.3.3 is executed. If it is not the last component, step S5.3.2.1 is executed again for the next component. Otherwise, step S5.3.2.25 is executed.

[0060] Step S5.3.2.2: Handling the case where there are no components of the same class:

[0061] Determine if the current component is in the path and path If none of them are of the same class, then the health of the current component is reduced. Simultaneously, iterate through the component pool and subtract the health score of all other components of the same category as the current component. Then, it continues to determine whether the current component is the last component. If it is the last component, it executes step S5.3.3. If it is not the last component, it repeats step S5.3.2.1 for the next component. Otherwise, it does nothing and continues to determine whether the current component is the last component. If it is the last component, it executes step S5.3.3. If it is not the last component, it repeats step S5.3.2.15 for the next component.

[0062] Step S5.3.3, Troubleshooting Path :

[0063] Step S5.3.3.1: Check for components of the same class:

[0064] Path traversal For all components, first check if other components of the same category as the current component have a path. or path If so, skip the current component check and continue to determine if 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.

[0065] Step S5.3.3.2: Handling the case where there are no components of the same class.

[0066] Determine the path and path If there are no components of the same category or identical to the current component, then deduct a high-probability deduction from the current component's health score. Simultaneously, iterate through the component pool and reduce the health score of other components of the same category as the current component by a low-probability deduction. Then, it continues to determine whether the current component is the last component. If it is the last component, it executes step S6. If it is not the last component, it repeats step S5.3.3.1 for the next component. Otherwise, it does not perform any operation and continues to determine whether the current component is the last component. If it is the last component, it executes step S6. If it is not the last component, it repeats step S5.3.3.15 for the next component.

[0067] Step S6: Health assessment, fault recovery module performs cleaning or offline operations on identified faulty components based on their health status:

[0068] Step S6.1: Traverse all components in the component pool and determine whether the health of each component is less than the cleaning health threshold. If so, mark the current component as "needs cleaning", increment its cleaning count by 1, and then proceed to step S6.2; otherwise, do nothing.

[0069] Step S6.2: Determine whether the number of cleaning cycles has reached or exceeded the threshold for the next cleaning cycle. If the condition has been met or exceeded, the current component will be marked as "needs to be taken offline for testing" and taken offline for testing; otherwise, a cleaning operation will be performed, and after cleaning, the health score will be increased by two high-probability deduction points. .

[0070] In a second aspect, the present invention provides a mimicry system component scheduling device, comprising:

[0071] The component pool is responsible for storing all components in the system and provides dynamic scheduling and management functions.

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

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

[0074] The adjudication 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.

[0075] The fault screening module is responsible for checking the components in each execution path in turn based on 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.

[0076] The fault recovery module is responsible for cleaning or taking offline the identified faulty components.

[0077] Thirdly, 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 perform the method described thereon.

[0078] Fourthly, the present invention provides a computing device, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described above.

[0079] The beneficial effects of this invention are reflected in at least the following aspects:

[0080] (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 when faced with a fault. Such a fault tolerance mechanism enables the system to remain stable in complex operating environments, greatly reducing the risk of service interruption caused by single point of failure.

[0081] (2) Enhanced system stability: After detecting a fault, this method can automatically clean up or take down the problematic component and select the component with higher health to continue performing 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.

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

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

[0084] (5) Improve resource utilization efficiency: This method intelligently selects components with higher health to perform tasks, ensuring optimal allocation of system resources and avoiding resource idleness caused by faulty components. This optimization makes the system run more efficiently and improves overall performance.

[0085] (6) Enhance user experience: By ensuring the 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, thereby increasing customer loyalty. Attached Figure Description

[0086] To more clearly illustrate the technical solution of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0087] Figure 1 This is a flowchart of the mimicry system component scheduling device module provided in an embodiment of the present invention.

[0088] Figure 2 This is a flowchart of the mimicry system component scheduling method provided in the embodiments of the present invention.

[0089] Figure 3 This is a flowchart of the steps for investigating different result paths in the method provided by the embodiments of the present invention.

[0090] Figure 4 This is a flowchart illustrating the steps of investigating all paths in the method provided by the embodiments of the present invention.

[0091] Figure 5 This is a path in the different result paths of the method provided in the embodiments of the present invention. Step-by-step flowchart.

[0092] Figure 6This is a path in the different result paths of the method provided in the embodiments of the present invention. Step-by-step flowchart.

[0093] Figure 7 This is a path in the different result paths of the method provided in the embodiments of the present invention. Step-by-step flowchart.

[0094] Figure 8 This is the method provided in the embodiments of the present invention for tracing all paths. Step-by-step flowchart.

[0095] Figure 9 This is the method provided in the embodiments of the present invention for tracing all paths. Step-by-step flowchart.

[0096] Figure 10 This is the method provided in the embodiments of the present invention for tracing all paths. Step-by-step flowchart. Detailed Implementation

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

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

[0099] The terms "comprising" and "having," and any variations thereof, used in the embodiments of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to such processes, methods, products, or devices.

[0100] While component-based architectures offer numerous advantages, they also face a series of challenges in practical applications. Particularly with complex dependencies between components, the failure of any component can lead to performance degradation or even complete system failure. Traditional fault handling methods, such as redundancy backups and manual repairs, are often inefficient and cannot meet the high availability and automated repair requirements of modern systems. Existing fault self-healing technologies, while addressing component failures to some extent, often fail to accurately and quickly locate the faulty component when dealing with complex component dependencies. Some technologies rely on simple redundancy backups, which cannot intelligently switch over and repair based on the actual operating status of components in the event of failure, resulting in performance degradation and excessively long service interruptions.

[0101] As the aforementioned shortcomings indicate, existing technologies suffer from slow response times and high false positive rates when handling faults in pseudo-systems with existing component architectures. This invention addresses these issues by dynamically monitoring and filtering the health status of components in each execution path. It can automatically clean up or take offline problematic components when a fault occurs, and intelligently select components with higher health to continue the task. Through this mechanism, this invention significantly improves the system's fault tolerance and stability, reducing the impact of faults on business processes. The dynamic monitoring method of this invention differs from existing technologies; it considers not only the basic operating parameters of components but also the interaction information of components in different execution paths and historical operating data. This multi-dimensional monitoring approach enables more accurate assessment of component health status. Regarding intelligent component selection, this invention employs a comprehensive evaluation strategy based on component health and path reliability, prioritizing components with high health and strong path stability to continue the task. This is fundamentally different from existing technologies that rely solely on backup priority or random selection, thereby effectively improving the system's fault tolerance and execution efficiency.

[0102] Based on this, embodiments of the present invention provide a mimicry system component scheduling device, such as... Figure 1 include:

[0103] The component pool is responsible for storing all components in the system and provides dynamic scheduling and management functions.

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

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

[0106] The adjudication 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.

[0107] The fault screening module is responsible for checking the components in each execution path in turn based on 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.

[0108] The fault recovery module is responsible for cleaning or taking offline the identified faulty components.

[0109] The system operation process is as follows:

[0110] The component-based mimicry system receives user requests. Then, the scheduling module performs scheduling based on the running status of each component in the component pool. The scheduling module will select three execution paths. , and The system then checks the minimum health of components along each path. If the minimum health of components along at least two paths exceeds a specified threshold, the system will use that path combination. Next, the request dispatch module distributes the request to the selected components, and the execution module begins processing the request. Then, the adjudication module performs a consistency check on the execution results of the three paths. If the results are inconsistent, the system will invoke auxiliary modules such as the fault screening module and fault recovery module to handle the fault. Otherwise, a response will be sent to the user.

[0111] like Figure 2 As shown, this embodiment of the invention also provides a self-healing scheduling method for mimicry system components. Through dynamic path selection and component health assessment, it quickly detects and handles faulty components in the system, thereby improving the robustness and reliability of the system. The main steps include:

[0112] (1) Initialization: When the system is initialized, an initial health score is assigned to each component and the number of cleaning times is initialized to 0.

[0113] (2) Request scheduling: Based on the load balancing strategy, select three execution paths for each request and check the minimum health of the components in each path.

[0114] (3) Request distribution: Distribute the request to the three selected execution paths; each component of each execution path executes the request in sequence and returns the execution results of each path to the adjudication module.

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

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

[0117] (6) Health assessment: Conduct a health assessment and perform cleaning or shutdown operations.

[0118] The above method is specifically as follows:

[0119] Step S1: System Initialization

[0120] During system initialization, an initial health value is first assigned to each component. (In this embodiment, the default value is 30), and the number of cleaning cycles is initialized to 0. During system initialization, the initial health value for each component can be determined more flexibly. Besides the default value of 30, factors such as the component's importance, past failure rate, and the business's dependence on the component can be considered. For example, for some core and faulty components, the initial health value can be appropriately reduced to allow for greater attention in the early stages of operation. Simultaneously, for components in different business modules, the initial health value can be set according to the business priority to ensure that the health of critical business-related components can be more accurately assessed and monitored. The following system parameters also need to be set:

[0121] (1) High probability of deduction This parameter is primarily used to quickly reduce the health of a component when it experiences problems that could severely impact system operation. For example, this is useful for systems like financial trading systems that have extremely high requirements for accuracy and stability. This can be set to a larger value, such as 8-10. This is because any component failure in financial transactions can lead to significant losses, and problematic components need to be flagged promptly for quick processing.

[0122] (2) Deduction of points for medium to high probability Its 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.

[0123] (3) Deduction for low to medium probability Generally, it can be set to 1-2, which is used to adjust the health level appropriately when some minor but still noteworthy issues arise in the component.

[0124] (4) Low probability of deduction It is usually set to 0.5-1 and is used to fine-tune the health of components, such as adjusting it when the component performance fluctuates slightly but does not affect the overall operation.

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

[0126] (6) Threshold for the number of offline cleaning cycles For systems with extremely high stability requirements and that cannot withstand frequent component replacements, the threshold for the number of offline cleaning cycles can be set to 1-2; for ordinary enterprise-level applications, it can be set to 3-5.

[0127] (7) Minimum health threshold of path components When the system load is high, this threshold can be appropriately lowered to ensure that the system can select a healthier combination of components to perform tasks. For example, during e-commerce promotional events, when the system load increases significantly, the threshold can be reduced from the default 15 to 10-12.

[0128] Step S2: Request scheduling

[0129] When the system receives a user request, the scheduling module selects three execution paths for each request based on the load balancing strategy and execution needs, denoted as follows: Each execution path consists of multiple components from the component pool.

[0130] The system checks the minimum health of components in each path. If the minimum health of components in at least two paths exceeds a set threshold, the system will detect the problem. (As mentioned earlier, depending on the system, it may be 10-15, etc.), then select that path combination for execution; otherwise, select three execution paths again.

[0131] Step S3, request distribution

[0132] 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 sequence and returns the execution results of each path to the adjudication module.

[0133] Step S4: Execution result consistency check

[0134] The adjudication module compares the execution results of the three execution paths selected by the scheduling module. , If the execution results are completely consistent, the system considers the execution to be normal, and then iterates through all components on the three paths, increasing the health of each component by one. Then, step S6 is executed; if the execution results are not completely consistent, the system is considered to have entered the fault screening state, and then step S5 fault screening is executed. The system checks the components in each path one by one and handles them according to different fault scenarios.

[0135] Each component health The constraints are .

[0136] Step S5, Fault Screening and Recovery: The fault screening module checks the components in each execution path in turn according to the differences in execution results and adjusts the health of each component in the path.

[0137] Step S5.1: Determine whether the execution results are the same for only two paths. If so, proceed to step S5.2; otherwise, proceed to step S5.3.

[0138] Step S5.2: Investigate different result paths, and record the two paths with the same execution result as... and Another path with a different execution result is denoted as Specifically:

[0139] Step S5.2.1: Investigate paths with different execution results. Specifically:

[0140] Step S5.2.1.1: Check identical components:

[0141] Path traversal All components in the path, if the current component is in the path or path If the current component's health status exists, its current health status remains unchanged. However, considering the impact of inter-component relationships, if a component's related components (determined by pre-defined association rules) also have problems in other paths, the deduction can be appropriately increased, such as deducting an additional 0.5-1 (the specific value can be determined based on the degree of association and system experience). Then, it continues to determine if the current component is the last component. If it is, step S5.2.2 is executed; otherwise, the current steps are repeated for the next component. If the current component does not exist, step S5.2.1.2 is executed.

[0142] Step S5.2.1.2 Check for components of the same class:

[0143] If other components of the same category as the current component are in the path or path If they exist, then the health score of these components of the same type will be reduced by 1. For these similar components, if their number in other paths is large (e.g., exceeding 50% of the total number of components in a path), consider uniformly 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 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.

[0144] Step S5.2.1.3: Handling the case where there are no components of the same class:

[0145] If other components of the same category as the current component are in the path or path If the component does not exist, then subtract one from its health. Simultaneously, iterate through the component pool and deduct the health score of all other components of the same class. Then, it continues to determine whether the current component is the last component. If it is the last component, step S5.2.2 is executed; otherwise, step S5.2.1.1 is repeated for the next component. During this process, if it is found that the overall health of the module to which the component belongs (module division can be preset according to the system architecture) is low (for example, the average health of components within the module is lower than 60% of the system average health), an additional 1-2 health score can be deducted from all components within the module to prompt further inspection and maintenance of the module.

[0146] Step S5.2.2, Troubleshooting Path Specifically:

[0147] Step S5.2.2.1: Check for components of the same class:

[0148] Path traversal All components in the path, if other components of the same category as the current component are in the path It does not exist in the path. If it exists, directly subtract the current component's health. Then, it continues to determine whether the current component is the last component. If it is the last component, proceed to 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, proceed to step S5.2.2.2.

[0149] If these other components of the same class are in the path If the health score of a component is also low (e.g., below 10), the deduction for this component can be increased, such as deducting an additional 1-2 points. If these components of the same type are of high importance in the system (e.g., they belong to critical business logic processing components), an additional 0.5-1 health score can be deducted from all components of the same type.

[0150] Step S5.2.2.2: Handling the case where there are no components of the same class:

[0151] If other components of the same category as the current component are in the path and path Since none of them are of the same class, traverse the component pool and subtract the health score of all other components of the same class. Then, it continues to determine if the current component is the last component. If it is, proceed to step S5.2.3; otherwise, repeat step S5.2.2.1 for the next component. Otherwise, no action is taken, and the process continues to determine if the current component is the last component. If it is, proceed to step S5.2.3; otherwise, repeat step S5.2.2.1 for the next component. If other components on the server node where this component resides (assuming the system uses a distributed architecture and components are deployed on different nodes) also experience numerous problems (e.g., more than 30% of components on the same node have a health score below 12), an additional 1-2 health score can be deducted from all components on that node to prompt for inspection and maintenance of that node.

[0152] Step S5.2.3, Troubleshooting Path Specifically:

[0153] Step S5.2.3.1: Check for components of the same class:

[0154] Path traversal All components in the path, if other components of the same category as the current component are in the path or path If the current component exists, skip the current component check; then continue to determine if the current component is the last component. If it is the last component, proceed to step S6; otherwise, repeat step S5.2.3.1 for the next component. If the current component does not exist, proceed to step S5.2.3.2.

[0155] Step S5.2.3.2: Handling the case where there are no components of the same class:

[0156] If the component is in the path and path If no components of the same class or identical components exist in the pool, iterate through the component pool and reduce the health score of all other components of the same class as the current component by a low-probability deduction. Then, it continues to determine whether the current component is the last component. If it is the last component, step S6 is executed; otherwise, step S5.2.3.1 is repeated for the next component. If the resource usage of the component (such as CPU, memory, etc.) is obviously abnormal (for example, exceeding 200% of the average resource usage of similar components), its health can be further reduced by 2-3 to highlight the handling of components with abnormal resources.

[0157] Step S5.3: Investigate all paths; such as Figure 4 Specifically:

[0158] Step S5.3.1, Troubleshooting Path ;like Figure 8 Specifically:

[0159] S5.3.1.1, Check for components of the same class:

[0160] Path traversal For all components, first check if the current component also has a path. or path If it exists, then directly subtract a low-probability deduction from the current component's health score. Then, it continues to determine whether the current component is the last component. If it is the last component, it executes step S5.3.1.2; if it is not the last component, it repeats the current step for the next component. If it does not exist, it continues to determine whether other components of the same category as the current component have paths. or path If a path exists or path Then subtract the health score of all components of the same category as the current component. Then, it continues to determine whether the current component is the last component. If it is the last component, it executes step S5.3.1.2; if it is not the last component, it repeats the current step for the next component. If no path exists... or path Then proceed to step S5.3.1.2.

[0161] S5.3.1.2 Handling the case where there are no components of the same class:

[0162] Subtract one from the current component's health. Simultaneously, iterate through the component pool and subtract the health score of all other components of the same category as the current component. Then, it continues to determine whether the current component is the last component. If it is the last component, it executes step S5.3.1.2. If it is not the last component, it repeats step S5.3.1.1 for the next component. Otherwise, it executes step S5.3.2.

[0163] Step S5.3.2, Troubleshooting Path ;like Figure 9 Specifically:

[0164] Step S5.3.2.1: Check for components of the same class.

[0165] Path traversal For all components, first check if the current component has a path. If the current component is not the last component, skip the current component check and continue to determine if 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.

[0166] Otherwise, continue to check if other components of the same category as the current component do not exist. But a path exists. If so, then directly subtract the low-probability deduction from the current component's health score. Then, it continues to determine whether the current component is the last component. If it is the last component, step S5.3.3 is executed. If it is not the last component, step S5.3.2.1 is executed again for the next component. Otherwise, step S5.3.2.2 is executed.

[0167] Step S5.3.2.2: Handling the case where there are no components of the same class:

[0168] Determine if the current component is in the path and path If none of them are of the same class, then the health of the current component is reduced. Simultaneously, iterate through the component pool and subtract the health score of all other components of the same category as the current component. Then, it continues to determine whether the current component is the last component. If it is the last component, it executes step S5.3.3. If it is not the last component, it repeats step S5.3.2.1 for the next component. Otherwise, it does not operate and continues to determine whether the current component is the last component. If it is the last component, it executes step S5.3.3. If it is not the last component, it repeats step S5.3.2.1 for the next component.

[0169] Step S5.3.3, Troubleshooting Path ,like Figure 6 Specifically:

[0170] Step S5.3.3.1: Check for components of the same class:

[0171] Path traversal For all components, first check if other components of the same category as the current component have a path. or path If the current component is not the last component, skip the current component check and continue to determine if 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.

[0172] Step S5.3.3.2: Handling the case where there are no components of the same class:

[0173] Determine the path and path If there are no components of the same category or identical to the current component, then deduct a high-probability deduction from the current component's health score. Simultaneously, iterate through the component pool and reduce the health score of other components of the same category as the current component by a low-probability deduction. Then, it continues to determine whether the current component is the last component. If it is the last component, it executes step S6. If it is not the last component, it repeats step S5.3.3.1 for the next component. Otherwise, it does not perform any operation and continues to determine whether the current component is the last component. If it is the last component, it executes step S6. If it is not the last component, it repeats step S5.3.3.1 for the next component.

[0174] Step S6: Health assessment, fault recovery module performs cleaning or offline operations on identified faulty components based on their health status:

[0175] Step S6.1: Traverse all components in the component pool and determine whether the health of each component is less than the cleaning health threshold. If so, mark the current component as "needs cleaning", increment its cleaning count by 1, and then proceed to step S6.2; otherwise, do nothing.

[0176] Step S6.2: Determine whether the number of cleaning cycles has reached or exceeded the threshold for the next cleaning cycle. If the condition has been met or exceeded, the current component will be marked as "needs to be taken offline for testing" and taken offline for testing; otherwise, a cleaning operation will be performed, and after cleaning, the health score will be increased by two high-probability deduction points. .

[0177] Based on the above-described mimicry system component scheduling method, the following embodiments are performed.

[0178] Example 1: Microservice component health declines but self-heals successfully.

[0179] • Fault scenario description

[0180] A web application request passes through three execution paths , and , where the path A certain microservice component An exception occurred, causing the execution result returned by this path to be inconsistent. Execution results of the other two paths and Inconsistency. This case represents a type of situation in a distributed microservice architecture where the failure of a single component affects the execution result of a local path. In practical applications, such as the order processing service in an e-commerce system, a component failure in a certain submodule may cause an anomaly in the order processing flow on a certain path.

[0181] • Fault screening and repair

[0182] (1) System discovery The results are different, so we should first investigate. All microservice components:

[0183] Components Only exists in the path Health decreases by 5. Since the health drops from 20 to 15, still above the cleaning threshold (assuming the cleaning threshold is set to 12 according to the system), it is marked as "can continue to be used". During this process, components can be recorded. Detailed fault information, such as the time of the anomaly and related request parameters, is required for subsequent analysis and optimization.

[0184] For components A cleaning operation was performed, increasing the health level by 10, restoring it to 25. At this point, the cleaning count was 1, and the shutdown condition had not been met. During the cleaning operation, detailed data can be recorded, such as the algorithm parameters used and changes in component performance metrics before and after cleaning, providing a reference for similar failures in the future.

[0185] (2) Path and The health status of the microservice components remained unchanged, and the investigation is complete. (Due to the cleaned components...) The system returns to normal operation upon the next request. This case highlights the system's self-healing capability in the face of individual component failures and how reasonable health threshold settings and cleanup operations can ensure normal system operation.

[0186] Example 2: Microservice components going offline due to decreased health across multiple paths

[0187] • Fault scenario description

[0188] A user request passed through three execution paths. and The results showed and The fact that all three are different indicates that one or more components in each path are malfunctioning. This situation is analogous to a complex business system where components involved in multiple sub-business processes simultaneously fail, affecting the normal execution of the entire business. For example, in a logistics management system, if components involved in the three sub-processes of shipping, transportation, and receiving fail on three separate paths, the entire logistics process will experience anomalies.

[0189] • Fault screening and repair

[0190] (1) The system sequentially checks all components along the three paths:

[0191] In the path In the middle, components If the device exists only on this path, its health decreases by 5, dropping to 10. Since the health is still greater than 5 (assuming the lower threshold is 5), a cleaning operation is performed, restoring the health to 20. During the cleaning process, components can be monitored. If the resource usage is found to be too high during the cleaning process (more than 150% of the normal level), it can be optimized and adjusted, such as by adjusting its memory allocation strategy.

[0192] In the path In the middle, components If it only exists on this path, its health decreases by 5, dropping to 3. At this point, it is marked. The status is "Needs Cleaning," so the cleaning count is incremented by 1. Since the health increases by 10 after cleaning, the total health reaches 13. During this process, components can be analyzed. To determine the cause of the failure, such as whether it is due to abnormal interaction with other components, if so, the relevant interaction logic can be checked and repaired.

[0193] In the path In the middle, components The health level decreases by 5. Upon reaching 5, a cleaning operation is performed. Since this component has already undergone 2 cleaning cycles, it is marked as "requires offline testing" and taken offline. The system automatically selects a backup component to replace it. When selecting backup components, a comprehensive evaluation should be conducted based on their performance indicators, historical usage, and other factors to choose the most suitable backup component, thereby ensuring system stability and performance.

[0194] (2) Self-healing results

[0195] By cleaning and taking offline the components of the three fault paths, the system successfully completed the fault repair. Faulty components The system was replaced, and its stability was restored. Thanks to the timely repair, there was no significant business interruption. This case highlights the system's ability to handle failures of components along multiple paths and how to ensure business continuity through reasonable health assessments and component replacement strategies.

[0196] Example 3: Multiple components fail and go offline on a single path

[0197] • Fault scenario description

[0198] A user request passed through three execution paths. , and ,path The failure of multiple components in a system can cause inconsistencies in execution results compared to the other two paths. This is similar to the simultaneous failure of multiple critical components in a core business process, severely impacting the normal operation of the business. For example, in a bank transfer system, if the three critical components—transfer verification, amount deduction, and account update—fail on the same path, the transfer operation cannot be completed normally.

[0199] • Fault screening and repair

[0200] (1) The system begins to investigate the path.

[0201] Components The health level decreases by 5, dropping to 12, which does not reach the cleaning threshold (assuming the cleaning threshold is 10 here), so no repair is needed. During this process, components can be recorded. This information includes changes in the health status and related business operation data, so that subsequent analysis can determine whether adjustments to the health status threshold are necessary.

[0202] Components When the health level drops to 4, it is marked as "needs cleaning," and a cleaning is performed, increasing the health level to 14. The cleaning cycle is 1. During the cleaning process, components can be... A detailed inspection of its internal state is conducted, such as checking whether its data structure is complete and whether the algorithm logic is correct, to determine whether the fault has been truly repaired.

[0203] Components The health level dropped to 2. After cleaning, the health level recovered to 12. However, since it had already been cleaned twice, it was marked as "requires offline testing," and the system automatically... Take the system offline and activate the backup component. Before activating the backup component, preloading and initialization can be performed to ensure that it can quickly take over the work of the faulty component and reduce business interruption time.

[0204] (2) Self-healing results

[0205] path Components in The system was successfully restored after being replaced. Thanks to the timely intervention of the backup component, business operations were uninterrupted, and system performance remained stable. This case demonstrates the system's strategy for handling multiple component failures along a single path and how a reasonable component repair and replacement mechanism can ensure normal system operation and business continuity.

[0206] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and 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 in a mimicry system that supports fault self-healing, characterized in that... The method includes the following steps: Step S1: System Initialization During system initialization, each component is assigned an initial health value. The number of cleaning cycles is initialized to 0; the following system parameters are also set: high probability of deduction. Medium to high probability of deduction Low to medium probability of deduction Low probability of deduction Cleaning health threshold Threshold for the number of offline cleaning cycles Minimum health threshold for components along 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. Next, it checks the minimum health of the components in each execution path. If at least two execution paths have components with a minimum health greater than [a certain value], [the system will proceed as planned]. If the current three execution paths are selected, then the three execution paths will be selected; otherwise, three new execution paths will be selected. 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 sequence and returns the execution results of each path to the adjudication module. Step S4: Execution result consistency check The adjudication module compares the execution results of the three execution paths selected by the scheduling module; if the execution results are completely consistent, it iterates through all components of the three paths and increments the health of each component by one. Then proceed to step S6; if the execution results are not completely consistent, the system is considered to have entered the fault screening state, and then proceed to step S5. Step S5: Fault Screening and Recovery The fault screening module checks the components in each execution path in turn based on the differences in the execution results and adjusts the health of each component in the path. Step S6: Health assessment, fault recovery module performs cleaning or offline operations on the identified faulty components based on their health status.

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 are the same for only two paths. If so, proceed to step S5.2; otherwise, proceed to step S5.

3. Step S5.2: Investigate different result paths, and record the two paths with the same execution result as... and Another path with a different execution result is denoted as ; Step S5.3: Investigate all paths.

4. The method according to claim 3, characterized in that, Step S5.2 specifically involves: Step S5.2.1: Investigate paths with different execution results. Specifically: Step S5.2.1.1: Check identical components: Path traversal For all components, first check if the current component also has a path. or path If the current component's health status remains unchanged, then it continues to determine whether the current component is the last component. If it is the last component, step S5.2.2 is executed; if it is not the last component, the current step is repeated for the next component. If the current component does not exist, step S5.2.1.2 is executed. Step S5.2.1.2 Check for components of the same class: Determine if a path exists for a component of the same category as the current component. or path If the current component exists, iterate through the component pool and deduct the health score of all other components of the same category as the current component. Then, it continues to determine whether the current component is the last component. If it is the last component, step S5.2.2 is executed; if it is not the last component, step S5.2.1.1 is executed again for the next component; if it does not exist, step S5.2.1.3 is executed. Step S5.2.1.3: Handling the case where there are no components of the same class: Subtract the current component's health. Simultaneously, iterate through the component pool and subtract the health score of all other components of the same category as the current component. Then, it continues to determine whether the current component is the last component. If it is the last component, step S5.2.2 is executed. If it is not the last component, step S5.2.1.1 is executed again for the next component. Step S5.2.2, Troubleshooting Path Specifically: Step S5.2.2.1: Check for components of the same class: Path traversal For all components, determine if other components of the same category as the current component do not exist in the path. But a path exists. If so, then subtract the current component's health. Then, it continues to determine whether the current component is the last component. If it is the last component, step S5.2.3 is executed; if it is not the last component, step S5.2.2.1 is repeated for the next component; if it does not exist, step S5.2.2.2 is executed. Step S5.2.2.2: Handling the case where there are no components of the same class: Determine if no other components of the same category as the current component have a path. and If so, then iterate through the component pool and subtract all other components of the same category as the current component. Then, it continues to determine whether the current component is the last component. If it is the last component, it executes step S5.2.

3. If it is not the last component, it repeats step S5.2.2.1 for the next component. Otherwise, it does nothing and continues to determine whether the current component is the last component. If it is the last component, it executes step S5.2.

3. If it is not the last component, it repeats step S5.2.2.1 for the next component. Step S5.2.3, Troubleshooting Path Specifically: Step S5.2.3.1: Check for components of the same class: Path traversal For all components in the current component, determine if other components of the same category as the current component exist. or path If the current component's health remains unchanged, then it continues to determine whether the current component is the last component. If it is the last component, then step S6 is executed; if it is not the last component, then step S5.2.3.1 is repeated for the next component; otherwise, step S5.2.3.2 is executed. Step S5.2.3.2: Handling the case where there are no components of the same class: Iterate through the component pool and subtract the health score of all other components of the same category as the current component. Then, it continues to determine whether the current component is the last component. If it is the last component, step S6 is executed. If it is not the last component, step S5.2.3.1 is repeated for the next component.

5. The method according to claim 4, characterized in that, Step S5.3 specifically is: Step S5.3.1, Troubleshooting Path Specifically: S5.3.1.1, Check for components of the same class: Path traversal For all components, first check if the current component also has a path. or path If it exists, then directly subtract a low-probability deduction from the current component's health score. Then, it continues to determine whether the current component is the last component. If it is the last component, it executes step S5.3.1.2; if it is not the last component, it repeats the current step for the next component. If it does not exist, it continues to determine whether other components of the same category as the current component have paths. or path If a path exists or path Then subtract the health score of all components of the same category as the current component. Then, it continues to determine whether the current component is the last component. If it is the last component, it executes step S5.3.1.2; if it is not the last component, it repeats the current step for the next component. If no path exists... or path Then proceed to step S5.3.1.2; S5.3.1.2 Handling the case where there are no components of the same class: Subtract one from the current component's health. Simultaneously, iterate through the component pool and subtract the health score of all other components of the same category as the current component. Then, it continues to determine whether the current component is the last component. If it is the last component, step S5.3.1.2 is executed; if it is not the last component, step S5.3.1.1 is repeated for the next component; otherwise, step S5.3.2 is executed. Step S5.3.2, Troubleshooting Path ; Specifically: Step S5.3.2.1: Check for components of the same class. Path traversal For all components, first check if the current component has a path. If the current component is not the last component, skip the current component check and continue to determine if 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, continue to check if other components of the same category as the current component do not exist. But a path exists. If so, then directly subtract the low-probability deduction from the current component's health score. Then, it continues to determine whether the current component is the last component. If it is the last component, step S5.3.3 is executed; if it is not the last component, step S5.3.2.1 is executed again for the next component; otherwise, step S5.3.2.2 is executed. Step S5.3.2.2: Handling the case where there are no components of the same class: Determine if the current component is in the path and path If none of them are of the same class, then the health of the current component is reduced. Simultaneously, iterate through the component pool and subtract the health score of all other components of the same category as the current component. Then, it continues to determine whether the current component is the last component. If it is the last component, it executes step S5.3.

3. If it is not the last component, it repeats step S5.3.2.1 for the next component. Otherwise, it does nothing and continues to determine whether the current component is the last component. If it is the last component, it executes step S5.3.

3. If it is not the last component, it repeats step S5.3.2.1 for the next component. Step S5.3.3, Troubleshooting Path Specifically: Step S5.3.3.1: Check for components of the same class: Path traversal For all components, first check if other components of the same category as the current component have a path. or path If the current component is the last component, skip the current component check and continue to determine if the current component is the last component. If it is the last component, proceed to step S6. If it is not the last component, repeat step S5.3.3.1 for the next component. Otherwise, proceed to step S5.3.3.

2. Step S5.3.3.2: Handling the case where there are no components of the same class. Determine the path and path If there are no components of the same category or identical to the current component, then deduct a high-probability deduction from the current component's health score. Simultaneously, iterate through the component pool and reduce the health score of other components of the same category as the current component by a low-probability deduction. Then, it continues to determine whether the current component is the last component. If it is the last component, it executes step S6. If it is not the last component, it repeats step S5.3.3.1 for the next component. Otherwise, it does not perform any operation and continues to determine whether the current component is the last component. If it is the last component, it executes step S6. If it is not the last component, it repeats step S5.3.3.1 for the next component. Step S6 is as follows: Step S6.1: Traverse all components in the component pool and determine whether the health of each component is less than the cleaning health threshold. If so, the fault recovery module marks the current component as "needs cleaning", increments its cleaning count by 1, and then executes step S6.2; otherwise, no operation is performed. Step S6.2: Determine whether the number of cleaning cycles has reached or exceeded the threshold for the next cleaning cycle. If the condition has been met or exceeded, the current component will be marked as "needs to be taken offline for testing," and the fault recovery module will take it offline for testing. Otherwise, a cleaning operation will be performed, and after cleaning, the health score will be increased by two high-probability deduction points. .

6. A mimicry system component scheduling device for implementing the method of any one of claims 1-5, characterized in that... include: The component pool is responsible for storing all components in the mimicry system; The scheduling module is responsible for selecting suitable components from the component pool based on user request requirements and load balancing strategies, and determining the execution path. The request distribution module is responsible for distributing user requests to the three execution paths selected by the scheduling module; The adjudication module is responsible for performing consistency checks on 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 based on 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 taking offline the 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 perform the method of any one of claims 1-5.

8. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-5.

Images