Intelligent chaos testing method and device for micro-service architecture

Abstract

The application provides a micro-service architecture-oriented intelligent chaos test method and device, relates to the technical field of software testing, and solves the problems of one-sided fault coverage of traditional tests, rigid strategies, easy triggering of system risks and disconnection with business scenarios. The method comprises the following steps: collecting a service call chain through a distributed tracking technology, and constructing a dynamic dependency graph comprising node importance and link throughput; adopting an LSTM neural network to analyze a business log sequence to identify a business process stage, and establishing a "stage-link-fault" triplet rule; integrating topology features, business stages and real-time operation indexes to construct a state space, and optimizing a fault injection strategy based on a reinforcement learning algorithm and a multi-objective reward function; and limiting the injection intensity and range through a conflict detection and pre-check mechanism. The application is used for reliability verification of a micro-service system, and improves test efficiency and safety.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to an intelligent chaos testing method and apparatus for microservice architecture. Background Technology

[0002] In the fields of cloud computing and distributed systems, microservice architectures face three core challenges due to the large number of services (often exceeding one hundred) and complex dependencies (each service depends on 5-8 other services on average):

[0003] 1. Incomplete fault coverage: Traditional testing only covers 30%-45% of potential fault combinations, and cannot simulate cascading failures on dependent links (such as chain failures of payment service → risk control service → account service). 2. Static and rigid strategies: Existing tools (such as Chaos Monkey) use random or rule-driven injection, which may trigger cascading crashes during peak business hours, resulting in a business interruption rate as high as 15%, and more than 55% of these are invalid failures. 3. Business scenario disconnect: Lack of awareness of business processes (such as order placement → payment → delivery), inability to inject targeted faults at specific stages (such as payment confirmation), and test results are disconnected from real business risks.

[0004] Existing technologies lack the ability to comprehensively model the dynamic topology of microservices, business process stages, and real-time operational metrics, making it difficult to achieve efficient, secure, and business-relevant chaos testing.

[0005] Therefore, there is an urgent need for intelligent chaos testing methods and devices for microservice architectures to solve the problems existing in current technologies. Summary of the Invention

[0006] This invention provides an intelligent chaos testing method and apparatus for microservice architectures. It addresses the problems of traditional chaos testing methods, which cannot dynamically perceive the microservice dependency topology, business process stages, and real-time running status, resulting in incomplete fault coverage, rigid strategies that easily lead to system risks, and a disconnect between testing and business scenarios.

[0007] The core technology of this invention is to construct a dynamic dependency graph that integrates the importance of multi-dimensional weighted nodes and combine it with a long short-term memory network to identify business stages and establish accurate mapping rules. In a multi-dimensional state space, the fault injection strategy is dynamically optimized based on multi-objective reinforcement learning. Combined with a security blocking mechanism based on multiple thresholds, risk-controllable intelligent chaotic testing is achieved.

[0008] In a first aspect, the present invention provides an intelligent chaos testing method for microservice architectures, the method comprising the following steps: S1. Collect service call chains through distributed tracing technology and construct a dynamic dependency graph that includes node importance and link throughput; S2. Parse the business log sequence to identify the business process stage, and establish fault mapping rules for the target link and preset fault types under specific business stages; S3. Integrate topological features, business stages, and real-time operational metrics to construct a state space. Optimize and generate fault injection strategies based on reinforcement learning algorithms and multi-objective reward functions, where the multi-objective reward function integrates fault coverage, business interruption rate, and invalid fault count. S4. Limit the strength and scope of the fault injection strategy through conflict detection and pre-checking mechanisms.

[0009] Furthermore, node importance is calculated using a graph algorithm, which incorporates factors such as the frequency of calls between nodes, the number of outgoing edges, and the weight of the service itself during the calculation process. The service's own weight is calculated by weighting business priority, requests per second, and the historical impact of failures.

[0010] Furthermore, the bottleneck link is determined through a dual mechanism of dynamic thresholds and industry benchmarks, including: Calculate the average throughput of the target link within a set time period. If the current link throughput meets the primary judgment condition of being lower than the product of a preset proportional coefficient and the average throughput, or lower than a preset industry benchmark value, and meets the primary judgment condition for a consecutive preset number of statistical periods, then it is finally determined to be a bottleneck link.

[0011] Furthermore, the business log sequence is parsed to identify the business process stage. This is achieved using a bidirectional long short-term memory network. Before inputting the bidirectional long short-term memory network, the business log sequence is subjected to noise filtering, regular expression cleaning, and sliding window context processing.

[0012] Furthermore, the state space is composed of topological feature vectors, business stage vectors, and real-time indicator vectors concatenated together; The formula for calculating the multi-objective reward function is: Reward value = Fault coverage × a Business interruption rate × b The number of invalid faults × c, where a = 0.6, b = 0.3, and c = 0.1.

[0013] Furthermore, the strength and scope of the fault injection strategy are limited through conflict detection and pre-checking mechanisms, including: Injecting multiple types of faults simultaneously on links with throughput below a first preset threshold is prohibited; The fault intensity of core nodes whose importance exceeds the second preset threshold is limited to a preset level range; Before performing the injection, a fault impact simulation is performed. If the expected business interruption rate exceeds the third preset threshold, the current fault injection is automatically skipped.

[0014] Secondly, this invention provides an intelligent chaos testing engine for microservice architectures, comprising: The dynamic topology awareness module is used to collect service call chains through distributed tracing technology and build a dynamic dependency graph that includes node importance and link throughput. The business semantic modeling module is used to parse business log sequences to identify business process stages and establish fault mapping rules for target links and preset fault types under specific business stages. The reinforcement learning decision module is used to integrate topological features, business stages, and real-time operation metrics to construct a state space, and to optimize and generate fault injection strategies based on reinforcement learning algorithms and multi-objective reward functions. The risk control module is used to limit the strength and scope of fault injection strategies through conflict detection and pre-checking mechanisms.

[0015] Furthermore, when calculating the importance of nodes, the dynamic topology awareness module integrates the call frequency between nodes, the number of outgoing edges, and the service's own weight, which is calculated by weighting business priority, requests per second, and the historical impact of faults.

[0016] Thirdly, the present invention provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the above-described intelligent chaos testing method.

[0017] Fourthly, the present invention provides a readable storage medium storing a computer program, the computer program including program code for controlling a process to execute the process, the process including the intelligent chaos test method described above.

[0018] The main contributions and innovations of this invention are as follows: 1. Significantly improved fault coverage: Through the synergy of dynamic topology awareness and business semantic modeling, the fault coverage rate has been increased from 45% in traditional tools to 82%, effectively solving the problem of incomplete coverage in cascading failure scenarios; 2. Significantly reduced business interruption rate: Through graph theory constraints and pre-check mechanisms, the business interruption rate was strictly controlled from 15% to 2.1% (a decrease of 86%), fundamentally avoiding the risk of system-level crashes caused by testing and ensuring the safety of the production environment; 3. Significantly reduced percentage of invalid faults: Based on the precise matching rules of "stage-link-fault", the percentage of invalid faults has been reduced from more than 55% to 15%, which has greatly eliminated test noise and significantly improved test efficiency; 4. Significantly improved fault detection efficiency: By combining real-time indicator monitoring with business stage correlation analysis, the average fault detection time has been reduced from 12 minutes to 4.2 minutes (a reduction of 65%), greatly accelerating the defect localization process; 5. Significantly improved business transaction success rate: By balancing test intensity and system stability through dynamic strategies, the business transaction success rate increased from 85% to 97.2%, verifying the high friendliness of the chaos test of this invention to real business processes.

[0019] Details of one or more embodiments of the present invention are set forth in the following drawings and description, so that other features, objects and advantages of the invention will be more readily understood. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is the flow of an intelligent chaos testing method for microservice architecture according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0021] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0022] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0023] Traditional chaos testing methods are fragmented in terms of topology dynamics, business semantic awareness, and risk control, resulting in low fault coverage (≤45%), high business interruption rate (≥15%), and many invalid faults (≥55%).

[0024] Based on this, the present invention addresses the problems existing in the prior art by quantifying the importance of nodes using a dynamic topology sensing module.

[0025] Example 1 This invention aims to propose an intelligent chaos testing method for microservice architectures, which can be specifically referred to... Figure 1 The method includes the following steps: S1. Dynamic Topology Awareness: Service call chains are collected through distributed tracing technology (such as OpenTelemetry) to construct a dynamic dependency graph that includes node importance and link throughput; The calculation of node importance takes into account the service's own weight and call frequency. The specific calculation formula is as follows: Node importance value = damping coefficient × (Σ(imported edge node importance × call frequency) / number of outgoing edges) + damping coefficient × service weight itself; The damping coefficient is a pre-set smoothing factor (e.g., set to 0.85).

[0026] The service's own weight adopts a multi-dimensional weighted fusion method. In a specific application scenario, the weight ratio of each indicator can be dynamically configured. For example, when the weight ratios of business priority, service QPS (requests per second), and historical impact of faults are configured as 40%, 30%, and 30% respectively, the formula for calculating the service's own weight is: Service own weight = 0.4 × business priority + 0.3 × QPS weight + 0.3 × historical impact of faults.

[0027] The call frequency is calculated using a sliding time window mechanism. Specifically, a short-term window and a long-term window are set, and the call frequency is obtained by weighted summing the number of calls within the short-term window and the number of calls within the long-term window. For example, if the short-term window is set to 5 minutes and the long-term window to 1 hour, and the weight of the short-term window is 0.6 and the weight of the long-term window is 0.4, then the call frequency = 0.6 × the number of calls in the last 5 minutes + 0.4 × the number of calls in the last 1 hour.

[0028] The bottleneck link is determined using a dual verification mechanism that combines dynamic thresholds and industry benchmarks. The dynamic threshold determination rule is as follows: calculate the average throughput T of the target link within a set time period (e.g., the last 10 minutes). avg If the current link throughput T curr ≤k×T avg (k is a preset proportional coefficient, such as 0.3), then the primary judgment is triggered; The industry benchmark judgment rule is: if the current link throughput is lower than the preset industry benchmark value (such as 500TPS in high-concurrency scenarios in finance), a preliminary judgment is triggered. The final determination rule is as follows: if the throughput is lower than the corresponding threshold for two consecutive statistical periods (e.g., each period is 5 minutes) after the initial determination is triggered, then it is ultimately determined to be a bottleneck link. The aforementioned benchmark value can be set through the initialization configuration file or automatically generated through dynamic learning of historical data.

[0029] S2. Business semantic modeling: Long Short-Term Memory (LSTM) network is used to parse business log sequences, identify business process stages, and establish "stage-link-fault" triple rules. These rules limit the target links and preset fault types under specific business stages. To improve the accuracy of stage boundary identification, the LSTM neural network used is configured as a bidirectional structure, containing two hidden layers with 128 neurons in each layer. Before the input log sequence, log preprocessing operations are performed, including: noise filtering, excluding system-level logs and pure monitoring logs, and retaining key logs containing business stage identifiers; regular expression cleaning, removing timestamps and unifying service instance numbers; word segmentation and feature engineering, performing word segmentation based on a predefined business term dictionary, generating event type labels (such as request REQ, response RSP, exception ERR), and constructing a sliding window context to form a local dependency feature vector.

[0030] Fault mapping establishes a "stage-link-fault" triple rule. For example, in the payment confirmation stage, for the payment → risk control link, a fault type with a preset risk control service response delay (200-500 milliseconds) is defined.

[0031] For example, Table 1 below shows the core hyperparameter configurations for an LSTM neural network: Table 1

[0032] Preferably, it also includes a log preprocessing method: (1) Noise filtering rules 1. Exclude system-level logs (such as [INFO] heartbeat detection successful) and pure monitoring logs (such as [METRIC] CPU utilization = 75%). 2. Retain key logs containing business stage identifiers (such as [PAYMENT] payment confirmation request received, [INVENTORY] inventory lock failure); 3. Regular expression cleaning: Use \d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2} to remove timestamps, and `service-\d+unified service instance number` to get `service-`. .

[0033] (2) Word segmentation and feature engineering 1. Employs a domain-based dictionary-based word segmentation method, predefining 1200+ business terms (such as "order creation", "inventory deduction", and "logistics allocation"). 2. Generate event type tags: Divide log actions into three categories: requests (REQ), responses (RSP), and exceptions (ERR), as auxiliary features; 3. Construct a sliding window context: Associate each log entry with the previous 3 / the next 2 log entries to form a local dependency feature vector.

[0034] Preferably, it also includes stage labeling rules: (1) Label definition standard 1. A four-level hierarchical tagging system is adopted, as shown in the example below: Primary tag: Transaction process; Secondary tag: Payment sub-process; Level 3 label: Payment confirmation stage; Level 4 label: Risk control verification sub-stage (belongs to the payment confirmation stage).

[0035] 2. The core stage must include business decision points (such as "payment confirmation" requiring merchant signature verification, and "inventory lock" requiring inventory balance judgment); (2) Annotation tools and processes 1. Use Label Studio for interactive annotation. Annotators must have business knowledge (such as e-commerce order state machines). 2. Ambiguous logs are handled using majority voting: 3 annotators annotate independently, and the architect makes the final review of the divergent logs; 3. Granularity of labeling: accurate to the atomic business operation (such as "coupon redemption" being independent of the "payment confirmation" stage).

[0036] In this embodiment, the "stage-link-fault" triplet rule expansion is shown in the following tables: Table 2 Typical Scenarios for E-commerce Order Processing

[0037] Table 3 Special Scenarios of Financial Transactions

[0038] In addition, the establishment of the "stage-link-fault" triple rule should follow the following design principles: dynamic fault parameters (e.g., random fluctuations are added to the basic delay value for delay-type faults); limited link scope (only direct dependency link injection faults that meet preset conditions such as depth ≤ 3 are allowed, excluding non-core business links); stage correlation verification (the fault type must be strongly related to the stage business logic, and the current effective state of the system in the target stage must be verified by the state machine).

[0039] Specifically: (1) Dynamic Fault Parameters 1. Delay-related faults: The base delay value fluctuates randomly by ±20% (e.g., if the preset delay is 200ms, the actual injection will be 160-240ms). 2. Error-related faults: Error codes follow the distribution of business anomalies (e.g., in payment scenarios, 60% are due to insufficient balance and 30% are due to network problems). (2) Link range limitation 1. Inject faults only into direct dependency chains (call chain depth ≤ 3) to avoid the uncontrollable impact of complex cross-domain dependencies; 2. Eliminate non-core business links such as monitoring / logging (e.g., log collection service → ES storage link does not inject faults).

[0040] (3) Stage correlation verification 1. The fault type must be strongly related to the business logic of the stage (e.g., user authentication-related faults are not allowed to be injected in the "inventory lock stage"). 2. Use state machine verification: Ensure that the system is in a valid state of the target stage when fault injection occurs (e.g., the "payment confirmation" stage requires "order creation" to be completed first).

[0041] S3, Reinforcement Learning Decision: The topological features, business stage features and real-time operation indicators of the microservice architecture are concatenated into vectors to construct a high-dimensional state space. The fault injection strategy is optimized based on the Deep Deterministic Policy Gradient Algorithm (DDPG) and multi-objective reward function.

[0042] The formula for calculating the reward function is as follows: Bonus value = Fault coverage × a Business interruption rate × b The number of invalid failures is multiplied by c, and a + b + c = 1. In a specific embodiment, the state space is constructed as a 150-dimensional vector, specifically including: topological features (60 dimensions, covering the importance features of core nodes, the proportion of bottleneck links, and the density of dependency graphs, etc.), business stages (20 dimensions, using one-hot encoding to represent preset business process stages), and real-time metrics (70 dimensions, covering global business metrics such as the resource utilization rate of core nodes, the response time and throughput of critical links, etc.). Meanwhile, to balance test depth and system stability, the weight coefficients a, b, and c in the reward function are set to Pareto optimality-oriented proportions (e.g., a = 0.6, b = 0.3, c = 0.1).

[0043] The reward function weight design logic (0.6 / 0.3 / 0.1) adopts a Pareto optimal goal orientation, as detailed below: (1) Core objective: Fault coverage (weight 0.6) 1. To address the pain point of "incomplete fault coverage" in traditional testing, we prioritize improving coverage (target from 45% to 82%) to ensure that critical fault scenarios are effectively triggered.

[0044] 2. Pareto analysis shows that covering the top 20% of high-frequency fault scenarios can solve 70% of actual online problems, so it is given the highest weight.

[0045] (2) Risk control: Business interruption rate (weight 0.3) 1. Limit system-level crashes caused by extreme failures (traditional tools have an interruption rate of 15%, while this invention aims for ≤3%), thus avoiding irreversible impacts of chaotic testing on the production environment.

[0046] 2. Adopt a "penalty mechanism": For every 1% increase in the interruption rate above the threshold, the reward value decreases by 0.15, forcing the strategy engine to prioritize low-risk fault combinations.

[0047] (3) Efficiency optimization: number of invalid failures (weight 0.1) 1. Filter out invalid faults that are irrelevant to the business (such as injecting payment link faults in non-payment stages) to reduce test noise (invalid faults account for 55% in traditional tools, target ≤15%).

[0048] 2. Based on historical data statistics: For every 10% increase in invalid faults, the testing efficiency decreases by 8%, so a basic penalty weight is set.

[0049] S4. Risk Control: Limit the intensity and scope of fault injection through conflict detection and pre-check mechanisms to avoid system-level crashes.

[0050] The conflict detection mechanism includes: limiting concurrent fault injection on low-throughput links (e.g., prohibiting the simultaneous injection of multiple types of faults on links with throughput below a preset security threshold such as 500 TPS); and limiting the fault intensity of core nodes (e.g., limiting the fault intensity of core nodes with importance values ​​above a preset importance threshold such as 0.8 to the highest level of preset proportion, such as limiting it to level 1-3 in fault intensity levels 1-5).

[0051] The pre-check mechanism includes: performing simulations before executing fault injection, and automatically intercepting and skipping the fault if the expected business interruption rate exceeds the safety threshold (e.g., 5%).

[0052] In actual operation, the system updates the dynamic dependency graph according to a preset cycle (e.g., every 5 minutes) and synchronously parses business logs to identify the current stage; the reinforcement learning model outputs a strategy based on the real-time status and executes the injection after risk control verification; after each injection, business indicators are collected to update the model parameters, and the strategy is retrained using newly accumulated data every preset batch (e.g., every 10 injection operations) to achieve closed-loop dynamic optimization.

[0053] Specifically, the method and process are as follows: Real-time awareness: The dependency graph is updated every 5 minutes, and business logs are parsed synchronously to identify the current stage.

[0054] Intelligent Decision Making: The reinforcement learning model outputs strategies based on real-time states, such as injecting a 300ms delay fault into the risk control link during the payment stage. For example, by constructing a state space containing a 150-dimensional input vector, which integrates the microservice topology features (node ​​importance, link throughput), business stages (business process stage information after one-hot encoding), and real-time metrics (CPU, memory, response time, etc.), the model optimizes the fault injection strategy based on a deep deterministic policy gradient algorithm, combined with a reward function consisting of a weighted sum of fault coverage (weight 0.6), business interruption rate (weight -0.3), and invalid faults (weight -0.1), thereby generating specific decisions on fault type, intensity, and injection timing.

[0055] Security Injection: Perform fault injection after pre-checking, and monitor business metrics (such as transaction success rate) in real time.

[0056] Closed-loop optimization: Model parameters are updated based on test results, and the strategy is retrained after every 10 injections. For example, after each fault injection is completed, business metrics (such as transaction success rate) and relevant fault injection data are collected in real time to update the parameters of the reinforcement learning model. Furthermore, after every 10 fault injection operations, the reinforcement learning strategy is retrained using the newly accumulated data. This method enables dynamic optimization of the fault injection strategy, allowing it to adapt to the dynamic changes in the microservice architecture and the continuous adjustments in business requirements.

[0057] The 500TPS threshold was set after taking into account both general industry practices and the actual operating data of the target system. Industry High-Concurrency Scenarios Reference: In common distributed systems such as e-commerce and finance, the average peak processing capacity of the core links in small and medium-sized systems is typically 2000-3000 TPS. To reserve sufficient fault handling buffer space for the system and avoid injecting faults that could cause cascading crashes when the system is close to saturation, a safety threshold is set at 25%-30% of the peak processing capacity, with 500 TPS falling within this reasonable range.

[0058] Historical data support for the target system: By collecting and analyzing the link throughput data of the target system over the past 30 days, it was found that the minimum stable operating threshold of the core links of the tested system within the 95% confidence interval falls within the range of 400-600 TPS. Taking the median of 500 TPS as the general default value, it can adapt to the actual operating conditions of most systems.

[0059] The determination of core nodes is based on node importance values ​​and graph centrality analysis, with the following specific criteria: Importance value calculation: The node importance is calculated using a variant of the algorithm similar to PageRank. It takes into account factors such as the importance of the node's incoming edges, call frequency, number of outgoing edges, and the weight of the service itself, and can accurately reflect the criticality of the node in the entire microservice dependency graph.

[0060] Threshold setting basis: After analyzing the dependency graphs of over 100 microservice systems, it was found that although nodes with an importance value greater than 0.8 only account for 15%-20% of the total number of nodes (meeting the Pareto principle, i.e., the critical minority), they account for over 75% of the probability of triggering cascading failures, making them the core factor affecting system stability. Therefore, nodes with an importance value greater than 0.8 are designated as core nodes and are the focus of key monitoring and risk control.

[0061] The table below compares the performance metrics of this invention with those of traditional tools: Table 4

[0062] As can be seen, the indicators of this invention are superior to those of traditional tools (such as Chaos Monkey), and can significantly improve the efficiency and security of reliability verification of microservice systems.

[0063] Example 2 Based on the same concept, this invention also proposes an intelligent chaos testing engine for microservice architectures, comprising: Dynamic topology awareness module: used to construct dynamic dependency graphs, calculate node importance, and identify bottleneck links; Business semantic modeling module: used to parse logs to identify business stages and establish "stage-link-fault" rules; Reinforcement learning decision engine: used to generate optimized fault injection strategies; Risk control module: Used to implement conflict detection and pre-check mechanisms; Each module and engine executes the steps of the intelligent chaos testing method for microservice architecture described in Example 1.

[0064] Example 3 This embodiment also provides an electronic device, see reference. Figure 2 It includes a memory 404 and a processor 402, wherein the memory 404 stores a computer program and the processor 402 is configured to run the computer program to perform the steps in any of the above method embodiments.

[0065] Specifically, the processor 402 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement embodiments of the present invention.

[0066] Memory 404 may include a mass storage device for data or instructions. For example, and not limitingly, memory 404 may include a hard disk drive (HDD), a floppy disk drive, a solid-state drive (SSD), flash memory, an optical disk drive, a magneto-optical disk drive, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 404 may include removable or non-removable (or fixed) media. Where appropriate, memory 404 may be internal or external to a data processing device. In a particular embodiment, memory 404 is non-volatile memory. In a particular embodiment, memory 404 includes read-only memory (ROM) and random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable read-only memory (PROM), an erasable read-only memory (EPROM), an electrically erasable read-only memory (EEPROM), an electrically alterable read-only memory (EAROM), or flash memory, or a combination of two or more of these. Where appropriate, the RAM can be Static Random-Access Memory (SRAM) or Dynamic Random-Access Memory (DRAM). DRAM can be Fast Page Mode Dynamic Random-Access Memory (FPMDRAM), Extended Data Out Dynamic Random-Access Memory (EDODRAM), Synchronous Dynamic Random-Access Memory (SDRAM), etc.

[0067] The memory 404 can be used to store or cache various data files that need to be processed and / or communicated, as well as possible computer program instructions executed by the processor 402.

[0068] The processor 402 reads and executes computer program instructions stored in the memory 404 to implement the intelligent chaos testing method for any microservice architecture described in the above embodiments.

[0069] Optionally, the electronic device may further include a transmission device 406 and an input / output device 408, wherein the transmission device 406 is connected to the processor 402, and the input / output device 408 is connected to the processor 402.

[0070] The transmission device 406 can be used to receive or send data via a network. Specific examples of the network described above may include wired or wireless networks provided by the communication provider of the electronic device. In one example, the transmission device includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 406 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0071] Input / output device 408 is used to input or output information.

[0072] Example 4 This embodiment also provides a readable storage medium storing a computer program, the computer program including program code for controlling a process to execute the process, the process including the intelligent chaos testing method for microservice architecture according to Embodiment 1.

[0073] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0074] Generally, various embodiments can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects of the invention can be implemented in hardware, while others can be implemented by firmware or software executed by a controller, microprocessor, or other computing device, but the invention is not limited thereto. Although various aspects of the invention may be shown and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that, by way of non-limiting example, these blocks, apparatuses, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0075] Embodiments of the present invention can be implemented by computer software, which may be executable by a data processor of a mobile device, such as a processor entity, or by hardware, or by a combination of software and hardware. Computer software or programs (also referred to as program products) including software routines, applets, and / or macros can be stored in any device-readable data storage medium, and they include program instructions for performing specific tasks. The computer program product may include one or more computer-executable components configured to perform the embodiments when the program is run. The one or more computer-executable components may be at least one piece of software code or a portion thereof. Additionally, it should be noted in this respect that, as Figure 1 Any box in the logical flow can represent a program step, or interconnected logic circuits, boxes and functions, or a combination of program steps and logic circuits, boxes and functions. Software can be stored on physical media such as memory chips or blocks of storage implemented within a processor, magnetic media such as hard disks or floppy disks, and optical media such as DVDs and their data variants, CDs, etc. The physical medium is a non-transient medium.

[0076] Those skilled in the art should understand that the technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0077] The above embodiments are merely illustrative of several implementations of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of the present invention should be determined by the appended claims.

Claims

1. An intelligent chaos testing method for microservice architecture, characterized in that, Includes the following steps: S1. Collect service call chains through distributed tracing technology and construct a dynamic dependency graph that includes node importance and link throughput; S2. Parse the business log sequence to identify the business process stage, and establish fault mapping rules for the target link and preset fault types under specific business stages; S3. Integrate topology features, business stages and real-time operation metrics to construct a state space, and optimize and generate a fault injection strategy based on reinforcement learning algorithm and multi-objective reward function, wherein the multi-objective reward function integrates fault coverage, business interruption rate and invalid fault number; S4. Limit the strength and scope of the fault injection strategy through conflict detection and pre-checking mechanisms.

2. The intelligent chaos testing method as described in claim 1, characterized in that, The importance of the nodes is calculated using a graph algorithm, which incorporates the call frequency between nodes, the number of outgoing edges, and the weight of the service itself during the calculation process. The service's own weight is calculated by weighting business priority, requests per second, and the historical impact of failures.

3. The intelligent chaos testing method as described in claim 1, characterized in that, The link throughput is determined to be a bottleneck link through a dual mechanism of dynamic threshold and industry benchmark, including: Calculate the average throughput of the target link within a set time period. If the current link throughput meets the primary judgment condition of being lower than the product of a preset proportional coefficient and the average throughput, or lower than a preset industry benchmark value, and meets the primary judgment condition for a consecutive preset number of statistical periods, then it is finally determined to be a bottleneck link.

4. The intelligent chaos testing method as described in claim 1, characterized in that, The process of parsing business log sequences to identify business process stages is implemented using a bidirectional long short-term memory network. Before inputting the bidirectional long short-term memory network, the business log sequences are subjected to noise filtering, regular expression cleaning, and sliding window context processing.

5. The intelligent chaos testing method as described in claim 1, characterized in that, The state space is composed of topological feature vectors, business stage vectors, and real-time indicator vectors. The multi-objective reward function is calculated as follows: Reward value = Fault coverage rate × a Business interruption rate × b The number of invalid faults × c, where a = 0.6, b = 0.3, and c = 0.

1.

6. The intelligent chaos testing method as described in claim 1, characterized in that, The strength and scope of the fault injection strategy are limited through conflict detection and pre-checking mechanisms, including: Injecting multiple types of faults simultaneously on links with throughput below a first preset threshold is prohibited; The fault intensity of core nodes whose importance exceeds the second preset threshold is limited to a preset level range; Before performing the injection, a fault impact simulation is performed. If the expected business interruption rate exceeds the third preset threshold, the current fault injection is automatically skipped.

7. An intelligent chaos testing engine for microservice architecture, characterized in that, include: The dynamic topology awareness module is used to collect service call chains through distributed tracing technology and build a dynamic dependency graph that includes node importance and link throughput. The business semantic modeling module is used to parse business log sequences to identify business process stages and establish fault mapping rules for target links and preset fault types under specific business stages. The reinforcement learning decision module is used to integrate topological features, business stages, and real-time operation metrics to construct a state space, and to optimize and generate fault injection strategies based on reinforcement learning algorithms and multi-objective reward functions. The risk control module is used to limit the strength and scope of the fault injection strategy through conflict detection and pre-checking mechanisms.

8. The intelligent chaos testing engine according to claim 7, characterized in that, When calculating the importance of nodes, the dynamic topology awareness module integrates the call frequency between nodes, the number of outgoing edges, and the service weight itself, which is calculated by weighting business priority, requests per second, and the impact of historical faults.

9. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the intelligent chaos testing method according to any one of claims 1 to 6.

10. A readable storage medium, characterized in that, The readable storage medium stores a computer program, the computer program including program code for controlling a process to execute the process, the process including the intelligent chaos testing method according to any one of claims 1 to 6.

Images