CN109032825B

CN109032825B - Fault injection method, device and equipment

Info

Publication number: CN109032825B
Application number: CN201810573924.9A
Authority: CN
Inventors: 邱硕
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2018-06-06
Filing date: 2018-06-06
Publication date: 2021-09-14
Anticipated expiration: 2038-06-06
Also published as: CN109032825A

Abstract

The embodiment of the specification discloses a fault injection method, a fault injection device and fault injection equipment, wherein the method comprises the following steps: intercepting a calling request of a target service method, wherein the calling request comprises an identifier of the target service method and a numerical value of a calling parameter; and if the preset target fault description information is matched with the identification of the target service method and the numerical value of the calling parameter, injecting target fault injection logic corresponding to the target fault description information into the target service method to determine a fault result generated by executing the target fault injection logic, wherein the target fault description information comprises the identification of the service method for fault injection and the numerical value of the calling parameter corresponding to the service method.

Description

Fault injection method, device and equipment

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a method, an apparatus, and a device for fault injection.

Background

In the internet system, after a single application is split into multiple applications, different applications may perform communication interaction through a distributed service framework, or may also perform communication interaction through a predetermined service framework that can implement RPC (Remote Procedure Call), so as to implement an internet system oriented to a service architecture, and the internet system generally oriented to the service architecture needs to perform online monitoring for a certain service.

Generally, fault data can be injected into a specified service method to determine whether the fault-tolerant capability of an abnormal behavior exists, specifically, fault data can be injected before or after an implementation logic of an original service method, where writing of the fault data (which can be written by a programming language such as Java) is completed inside the implementation of the service method, so that new application codes need to be issued each time a fault type (or a fault behavior) and/or an injection condition is newly added to update corresponding applications and service systems, and the corresponding applications and service systems also need to compile and process the fault data, so that the fault injection logic is complex, the fault injection efficiency is low, and therefore, a scheme with simplicity, rapidness and higher fault injection efficiency needs to be provided.

Disclosure of Invention

An object of the embodiments of the present specification is to provide a fault injection method, apparatus, and device, so as to provide a simpler and faster scheme with higher fault injection efficiency.

In order to implement the above technical solution, the embodiments of the present specification are implemented as follows:

the fault injection method provided by the embodiment of the specification comprises the following steps:

intercepting a calling request of a target service method, wherein the calling request comprises an identifier of the target service method and a numerical value of a calling parameter;

and if the preset target fault description information is matched with the identification of the target service method and the numerical value of the calling parameter, injecting target fault injection logic corresponding to the target fault description information into the target service method to determine a fault result generated by executing the target fault injection logic, wherein the target fault description information comprises the identification of the service method for fault injection and the numerical value of the calling parameter corresponding to the service method.

Optionally, the injecting, by the target service method, a target fault injection logic corresponding to the target fault description information includes:

acquiring a fault type corresponding to the target fault injection logic, wherein the fault type comprises a preposed class and a non-preposed class;

and if the fault type is a pre-class, injecting target fault injection logic corresponding to the target fault description information into the target service method.

Optionally, the preamble classes include throw errors, delay and tamper parameter values,

if the fault type is a pre-class, injecting a target fault injection logic corresponding to the target fault description information into the target service method, including:

and if the fault type is a first subclass in a pre-class, judging whether a target fault injection logic corresponding to the target fault description information is injected into the target service method before the target service method is called according to the first subclass, wherein the first subclass is a parameter value for error throwing, delaying or tampering.

Optionally, the target fault description information is written in a domain specific language DSL.

Optionally, the target fault description information includes a plurality of key fields, where the key fields are respectively used to represent an identifier of a service method for performing fault injection, a value of a call parameter, and a content of an injected fault logic.

Optionally, the plurality of key fields of the target fault description information are FROM, WHERE and UPDATE, respectively.

Optionally, the method further comprises:

analyzing the content of the target fault description information to respectively obtain the content corresponding to each key field;

if the preset target fault description information is matched with the identification of the target service method and the numerical value of the calling parameter, injecting target fault injection logic corresponding to the target fault description information into the target service method, wherein the target fault injection logic comprises the following steps:

and if the obtained content corresponding to the key field is matched with the identification of the target service method and the numerical value of the calling parameter, injecting target fault injection logic corresponding to the target fault description information into the target service method.

Optionally, after injecting the target fault injection logic corresponding to the target fault description information into the target service method, the method further includes:

and modifying the numerical value of the calling parameter or the return value of the calling parameter corresponding to the target fault injection logic by using a Java tool Java Instrument or a facet-oriented programming AOP mechanism so as to update the target fault injection logic.

The fault injection device provided by the embodiment of the specification comprises:

the request intercepting module is used for intercepting a calling request of a target service method, wherein the calling request comprises an identifier of the target service method and a numerical value of a calling parameter;

and the injection module is used for injecting target fault injection logic corresponding to the target fault description information into the target service method to determine a fault result generated by executing the target fault injection logic if preset target fault description information is matched with the identifier of the target service method and the numerical value of the calling parameter corresponding to the service method, wherein the target fault description information comprises the identifier of the service method for fault injection and the numerical value of the calling parameter corresponding to the service method.

Optionally, the device is determined by a facet-oriented programming AOP mechanism.

Optionally, the injection module comprises:

the type acquisition unit is used for acquiring a fault type corresponding to the target fault injection logic, wherein the fault type comprises a pre-class and a non-pre-class;

and the injection unit is used for injecting target fault injection logic corresponding to the target fault description information into the target service method if the fault type is a pre-class.

the injection unit is configured to, if the fault type is a first subclass in a pre-class, determine whether to inject a target fault injection logic corresponding to the target fault description information into the target service method before invoking the target service method according to the first subclass, where the first subclass is a parameter value for error throwing, delaying, or tampering.

Optionally, the apparatus further comprises:

the analysis module is used for analyzing the content of the target fault description information to respectively obtain the content corresponding to each key field;

and the injection module is used for injecting target fault injection logic corresponding to the target fault description information into the target service method if the obtained content corresponding to the key field is matched with the identification of the target service method and the numerical value of the calling parameter.

Optionally, the apparatus further comprises:

and the data updating module is used for modifying the numerical value of the calling parameter or the return value of the calling parameter corresponding to the target fault injection logic by using a Java tool Java Instrument or a facet-oriented programming AOP mechanism so as to update the target fault injection logic.

The embodiment of the present specification provides a fault injection device, including:

a processor; and

a memory arranged to store computer executable instructions that, when executed, cause the processor to:

As can be seen from the above technical solutions provided by the embodiments of the present specification, in the embodiments of the present specification, by intercepting a call request of a target service method, where the call request includes an identifier of the target service method and a numerical value of a call parameter, and under a condition that predetermined target fault description information matches the identifier of the target service method and the numerical value of the call parameter, injecting a target fault injection logic corresponding to the target fault description information into the target service method to determine a fault result generated by executing the target fault injection logic, where the target fault description information includes the identifier of the service method performing fault injection and the numerical value of the call parameter corresponding to the service method, so that a service method in a service system can be selected only by information, such as the identifier of the service method performing fault injection and the numerical value of the call parameter corresponding to the service method, described in the fault description information, and injecting corresponding target fault injection logic, thereby obtaining a fault result generated by executing the target fault injection logic, without compiling the identifier of the service method for fault injection, the numerical value of the calling parameter corresponding to the service method, and the related program code of the information of the target fault injection logic, and the like, and without compiling the program code by using a server or terminal equipment of a service system, thereby greatly simplifying the processing process of fault injection and improving the fault injection efficiency.

Drawings

In order to more clearly illustrate the embodiments of the present specification or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only some embodiments described in the present specification, and for those skilled in the art, other drawings can be obtained according to the drawings without any creative effort.

FIG. 1 illustrates one embodiment of a fault injection method of the present disclosure;

FIG. 2 is a process diagram of a fault injection scheme in the related art;

FIG. 3 is another embodiment of a fault injection method of the present disclosure;

FIG. 4 is a schematic diagram of a fault injection system according to the present disclosure;

FIG. 5 illustrates one embodiment of a fault injection apparatus of the present disclosure;

fig. 6 illustrates an embodiment of a fault injection apparatus according to the present disclosure.

Detailed Description

The embodiment of the specification provides a fault injection method, a fault injection device and fault injection equipment.

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

Example one

As shown in fig. 1, an execution subject of the method may be a server, where the server may be an independent server, or a server cluster composed of multiple servers, and the server may be a server that provides a service for a certain service or multiple services, and the server may be used to carry one or multiple service systems. The method can be used for judging whether a certain service system has the fault-tolerant capability of a certain or a certain type of specified abnormal behaviors or not. The method may specifically comprise the steps of:

in step S102, a call request of a target service method is intercepted, where the call request includes an identifier of the target service method and a value of a call parameter.

The target service method may be a method for solving a problem or implementing a function in one or more services in any service, the target service method may be created in an application program and referred to elsewhere, the target service method may be a plurality of statements written in a predetermined programming language, the steps for solving a problem or implementing a function are combined in a combined order, the plurality of statements are combined, and the plurality of statements may be combined together to perform a function or solve a problem. The invocation request may be a request to invoke execution of a target service method to implement a function. The identification of the target service method may be the name of the target service method (i.e., the method name) or the encoding of the target service method, etc. The invocation parameters may be parameters required for invoking the execution of the target service method.

In implementation, for the internet system, with continuous improvement of service complexity, access volume and data volume, a single application commonly used in the past is gradually split into multiple applications, and different applications in the multiple applications may perform communication interaction through a distributed service framework or through a predetermined service framework capable of implementing RPC (Remote Procedure Call), so as to implement an internet system oriented to a service architecture. Through the service disassembly in the manner, the complexity of the service system can be gathered in each application along with the disassembly of the application (or the application system), and the operation and maintenance, the capacity planning and the like of each application can be independently performed. Meanwhile, the application process under the service-oriented architecture has no state information, and the state information of the application process can be externally arranged in an external persistent storage system, for example, externally arranged in a DB (DataBase).

Based on the above, the service splitting can make the generated application have the above two changes, and further can make a complete service request be split into a cross-process service call tree, and the service as a tree node can have the following characteristics: the service method may be interface oriented rather than implemented; the call parameters and return results of the service methods are POJO (Plain organization Java Object), not stateful objects; the service method is a remote call rather than a local call.

For an internet system which has been made into a service-oriented architecture, generally, the service-line monitoring is as follows: configuring a monitoring large disk according to predetermined indexes (such as error rate, response time, upstream and downstream data consistency and access quantity) of each service; different monitoring thresholds can be configured for different monitoring disks so as to alarm abnormal service method calls occurring in the system and the like.

For monitoring the effectiveness of the large disk monitoring, a fault injection mode may be generally adopted to implement, specifically, for a specific service call of the online system, injecting abnormal behavior data in a specific parameter and a specific time period, for example, delayed abnormal behavior data, abnormal behavior data reporting an error, abnormal behavior data tampering with a parameter value, or the like. Then, after the abnormal behavior data is injected, the monitoring alarm result can be observed, so that whether the monitoring large disk has the capability of finding the abnormal behavior or not is judged.

For example, as shown in fig. 2, the application may be split into two applications, that is, an application a and an application B, where the two applications are respectively provided with a service interface, generally, the application may include a plurality of service methods, for example, the application a includes a service method 1 and a service method 2, and the application B includes a service method 1 and a service method 2, and generally, the fault tolerance capability of determining whether an abnormal behavior exists may be implemented by injecting fault data into a specified service method, and as shown in fig. 2, the fault data may be injected before or after an implementation logic of an original service method. It can be known from the processing manner of the above diagram that writing of fault data is completed inside implementation of a service method, so that new application codes need to be issued each time a fault type (or fault behavior) and/or an injection condition is newly added, and the injection of fault data and the implementation of the service method are represented by the same programming language (such as Java language, etc.), while a common programming language is a procedural programming language rather than a descriptive programming language, and the meaning of the representation is "how to do" rather than "what to do", so that the meaning (fault semantics) behind the statement cannot be embodied at a language level. In addition, the fault injection logic in the processing method has a certain modularity, for example, if the fault injection logic is injected under the condition that the call parameter value and the call occurrence time satisfy a specific condition for a specific service method, and the injected fault generally includes three types, namely delay, misthrowing, parameter value tampering, and the like, and in order to solve the above problem of fault injection in the service method, an embodiment of the present specification provides an implementation scheme, which may specifically include the following contents:

considering that different fault injection scenarios are for different combinations of the above-described patterns, there is a possibility to abstract the fault injection logic by DSL (Domain Specific Language) Language, and considering that the injected fault types can be enumerated, the fault types can also be abstracted as syntax elements in the DSL Language, so that the syntax elements contain fault semantics. If the fault injection logic can be expressed by a described DSL language, the syntax element of the DSL language can embody fault injection semantics, and the fault logic can be injected by a DSL driven execution engine in an explanatory manner rather than a compiled manner, so that the injected online application does not need to be issued and restarted when changing or updating the fault type and/or the injection condition.

A user's terminal device (e.g., a mobile phone, a tablet computer, a computer, or the like) may have a specific application installed therein, and one or more different services may be provided to the user through the application, each service may be implemented by one or more service methods, and different service methods may implement different functions. When a user needs to use the application to perform a certain operation or a certain service, a key or a link provided in the application may be triggered, and after the application obtains the trigger operation, processing logic corresponding to the trigger operation may be executed, where the processing logic may include calling a certain service method (i.e., a target service method), and when the terminal device determines that the target service method needs to be called, an identifier such as a name of the target service method, a value of a calling parameter, and the like may be obtained, and a calling request of the target service method may be generated based on the obtained information or data, and may be sent to a server, and at this time, the server may intercept the calling request.

In step S104, if the predetermined target fault description information matches the identifier of the target service method and the value of the calling parameter, injecting a target fault injection logic corresponding to the target fault description information to the target service method to determine a fault result generated by executing the target fault injection logic, where the target fault description information includes the identifier of the service method performing fault injection and the value of the calling parameter corresponding to the service method.

Based on the above, the target fault description information may be written in a DSL language, and the target fault description information may be used to describe a fault injection logic that is required to be injected into a certain service method in a case where a preset injection condition is satisfied, so as to determine a fault result generated by executing the fault injection logic, and thus determine fault tolerance of the service system, where the fault tolerance may include the capability of finding an abnormal behavior, the capability of self-healing of the service system, and the emergency troubleshooting capability of a service system administrator. The fault description information does not need to be compiled by the business system, but can be directly analyzed by the business system to obtain the identification of the service method and the numerical value of the calling parameter, the corresponding target fault injection logic and the like, and the operation corresponding to the target fault injection logic is executed. The target fault injection logic may be target fault injection data indicating identification of a service method, values of call parameters, and the like, and which service method, what fault (or fault logic) is injected under what injection condition, and the like, and may be represented by any other manner capable of representing which service method, what fault is injected under what injection condition, for example, a flowchart or a logic diagram of an execution process, and the like, which is not limited by the embodiments of the present specification.

In implementation, fault description information of different service methods can be written through a DSL language according to different requirements, and the different fault description information may include identifiers of the different service methods and values of calling parameters of the corresponding service methods. A management system for temporarily storing and managing the written fault description information (i.e., the target fault description information) may be preset, and after the fault description information is written, the fault description information may be stored in the management system, and the management system may push the corresponding fault description information to the corresponding service system in real time. After receiving the fault description information, the service system may analyze the fault description information, and may obtain a service method (that is, which service method the fault description information is directed to, the fault injection logic is injected into), under what condition of the service method the fault injection logic is injected into (that is, the injection condition of the fault injection logic, which may include a call parameter corresponding to the service method, a numerical value thereof, and the like), and the content of the fault logic, and after obtaining the information, the information may be stored in a server of the service system.

After the server intercepts the call request of the target service method through the processing of step S102, the call request may be analyzed, and the identifier of the target service method and the value of the call parameter may be obtained therefrom, then, the server may first match and compare the identifier of the target service method with the service method for which the target fault description information is intended, if the identifier of the target service method matches with the service method for which the target fault description information is intended, the call parameter and the value thereof may be further matched and compared with the call parameter and the value thereof in the target fault description information, and if the identifier of the target service method matches with the service method for which the target fault description information is intended, it may be determined that the target fault description information is the fault description information for the target service method. If the identifier of the target service method does not match the service method targeted by the target fault description information, and/or the calling parameter and the value thereof do not match the calling parameter and the value thereof in the target fault description information, the processing of the step S102 is continuously executed, that is, other service methods are continuously intercepted, and the processing of the step S104 is performed.

The target fault description information may be related description information of fault injection required by the target service method, at this time, a target fault injection logic corresponding to the target fault description information may be injected into the target service method, after the injection is completed, the injected target fault injection logic may be executed, a corresponding fault result may be obtained through the executed target fault injection logic, and it may be determined whether the server or the service system has a fault tolerance capability of an abnormal behavior of a fault category corresponding to the target fault injection logic through the obtained fault result. If the verification is passed, the service system can be indicated to be continuously used, and if the verification is not passed, the service system can be trimmed, and the safety of the service system is also ensured.

It should be noted that, in the above processing procedure, one or more calls of a service method that are expected to inject a fault (or fault logic) may be screened out from normal calls of the service method according to the fault description information, and the fault injection logic may be injected, specifically, there may be many calls (e.g., 10 times or 5 times, etc.) for one service method, and if only one of the calls (e.g., the call parameter meets a certain requirement, etc.) is to perform fault (or fault logic) injection, the fault description information written by the DSL may describe how the service method selects the desired call from the above calls, and what fault (or fault logic) is injected for the call, etc.

The embodiment of the present specification provides a fault injection method, where a call request of a target service method is intercepted, where the call request includes an identifier of the target service method and a value of a call parameter, and when predetermined target fault description information matches the identifier of the target service method and the value of the call parameter, a target fault injection logic corresponding to the target fault description information is injected into the target service method to determine a fault result generated by executing the target fault injection logic, where the target fault description information includes the identifier of the service method performing fault injection and the value of the call parameter corresponding to the service method, so that a service method in a service system can be selected only through information such as the identifier of the service method performing fault injection described in the fault description information and the value of the call parameter corresponding to the service method, and injecting corresponding target fault injection logic, thereby obtaining a fault result generated by executing the target fault injection logic, without compiling the identifier of the service method for fault injection, the numerical value of the calling parameter corresponding to the service method, and the related program code of the information of the target fault injection logic, and the like, and without compiling the program code by using a server or terminal equipment of a service system, thereby greatly simplifying the processing process of fault injection and improving the fault injection efficiency.

Example two

As shown in fig. 3, an execution subject of the method may be a server, where the server may be an independent server, or a server cluster composed of multiple servers, and the server may be a server that provides a service for a certain service or multiple services, and the server may be used to carry one or multiple service systems. The method can be used for judging whether a certain service system has the fault-tolerant capability of a certain or a certain type of specified abnormal behaviors or not. The method may specifically comprise the steps of:

as shown in fig. 4, in the service system, a reference to a downstream service may be determined through an AOP (Aspect Oriented Programming) mechanism, and the fault injection interceptor may be configured to carry fault description information and analyze the fault description information, and meanwhile, may further intercept a service method called by a downstream request, and inject a fault injection logic into a specified service method, and so on.

In step S302, the content of the target fault description information is analyzed to obtain the content corresponding to each key field.

In implementation, in the process of injecting a fault injection logic into a service method, it is necessary to know information of three aspects, that is, which service method is to be injected into the fault injection logic (that is, the service method for which fault description information is intended), under what condition of the service method the fault injection logic is to be injected (that is, the injection condition of the fault injection logic, which may include a calling parameter corresponding to the service method, a numerical value thereof, and the like), and the content of the injected fault logic, and the like, in this embodiment of the present specification, based on the information of the three aspects, the fault description information is written using a DSL, and a specific grammar may be as follows:

dsl:＝'UPDATE'inject[','inject]+'FROM'serviceSignature'WHERE'

expression

inject:＝delay|throw|manipulate

delay:＝'DELAY('time')'

time:＝digit+

throw:＝'THROW('exceptionClassName')'

manipulate:＝'MANIPULATE('paraIdx','targetValue')'

paraIdx:＝digit+

targetValue:＝literal

serviceSignature:＝packageName'.'interfaceName'.'methodName

expression:＝expression logicOperator expression

|'('expression')'

|paramKey compareOperator literal

logicOperator:＝'OR'|'AND'

compareOperator:＝'>'|'<'|'＝'|'！＝'

literal:＝'"'char+'"'

paramKey:＝'['digit+']”.'OGNL|'{time}'

the font is italicized but not bolded, and is a non-terminal character, the font is italicized and bolded, and is syntax of Java Language or syntax of OGNL (Object-Graph Navigation Language), and the like, a part in the quotation mark is a character, and the remaining part may be a terminal character, and the like.

Through the above-mentioned fault description information written by DSL, it can be determined that the fault description information includes a plurality of key fields, such as an "UPDATE" field, a "FROM" field, and a "WHERE" field, and different fields may correspond to different functions, and the content corresponding to different fields may be different, for example, the content corresponding to the UPDATE field may be the content of fault logic (or fault), the content corresponding to the FROM field may be the service method to which the injection is performed (i.e., the identifier of the service method, etc.), and the content corresponding to the WHERE field may be a call parameter and its value, etc.

For example, a service component implements the following interfaces:

wherein, the assetdecreaerequest may contain the following key fields:

the contents of the plurality of key fields may refer to the following fault description information:

UPDATE DELAY(100)

FROM com.alipay.paycore.service.payment.asset.AssetFluxService.decrenent

WHERE[1].assetExtra[“userId”]＝208800000000000000；AND{time}>

'2017-12-3122:01:00'AND{time}>'2017-12-31 22:01:59'。

the above-mentioned fault description information may indicate that for the service method com, alipay, paycore, service, paymate, assetfluxservice, decrement, when in one call to it, the key of assetExtra field (actually map) of the 1 st parameter, i.e. userId corresponds to value equal to '2088000000000000', and the call time is between 2017-12-3122:01:00 to 2017-12-3122:01: 59, a fault (or fault logic) delayed by 100 ms is injected (where it needs to be noted that for each call, 100 ms is delayed).

The fault description information of different service methods can be written through DSL according to different requirements. As shown in fig. 4, a management system of the fault description information may be preset, and after the fault description information is written, the fault description information may be stored in the management system, and the management system may push the corresponding fault description information to the corresponding service system in real time. After receiving the fault description information, the service system may analyze the fault description information, and may obtain the contents corresponding to the UPDATE field, the FROM field, and the WHERE field, respectively. Based on the above example, it can be obtained that the content corresponding to the UPDATE field is DELAY (100), the content corresponding to the FROM field is com.alicay.paycore.service.payment.asset.assetfluxservice.descriptor, and the content corresponding to the WHERE field is [1]. assetExtra [ "userld" ] ═ 208800000000000000; AND { time } > '2017-12-3122:01:00' AND { time } > '2017-12-3122:01: 59'. The above-mentioned content may be correspondingly stored in a server of the service system.

It should be noted that the fault description information written by DSL does not need to be compiled by the service system, but can be directly analyzed by the service system to obtain the identifier of the service method and the value of the invocation parameter, the corresponding fault injection logic, and the like, and perform the operation corresponding to the fault injection logic.

In addition, the key fields included in the fault description information are not limited to the above-mentioned UPDATE field, FROM field, WHERE field, and the like, and may also include various other key fields in practical application, which may be specifically set according to practical situations, and this is not limited in this embodiment of the present specification.

In step S304, a call request of the target service method is intercepted, where the call request includes an identifier of the target service method and a value of a call parameter.

In implementation, as shown in fig. 4, when a service method (i.e., a target service method) depended on downstream needs to be called, the downstream may send a call request to the business system, where the call request reaches the business system and is intercepted by the fault injection interceptor, so as to intercept the call request of the target service method, where the call request may include an identifier of the target service method and a value of a call parameter.

In step S306, if the predetermined target fault description information matches the identifier of the target service method and the value of the calling parameter, a fault type corresponding to the target fault injection logic is obtained, where the fault type includes a pre-class and a non-pre-class.

Wherein, the target fault description information can be written by a domain-specific language DSL. The target fault description information may include a plurality of key fields, and the plurality of key fields are respectively used to characterize an identifier of a service method corresponding to the target fault description information and a value of a call parameter. The multiple key fields of the target fault description information may be FROM, WHERE, UPDATE, etc. respectively. In addition, the key fields included in the fault description information are not limited to the above-mentioned UPDATE field, FROM field, WHERE field, and the like, and may also include various other key fields in practical application, which may be specifically set according to practical situations, and this is not limited in this embodiment of the present specification.

In implementation, since the fault may generally include a pre-posed fault and a non-pre-posed fault, and the non-pre-posed fault generally cannot show a fault result to a user or a technician, but only is recorded inside a service system, a corresponding intuitive fault result may not be directly obtained for the non-pre-posed fault, for this reason, in the embodiment of this specification, injection of the fault injection logic may be performed only for the fault type that is the pre-posed fault, and therefore, before injecting the target fault injection logic into the target service method, the fault type corresponding to the target fault injection logic may be obtained from the target fault description information, or the fault type corresponding to the target fault injection logic may be determined in a manner of pre-specification or the like, and it is determined whether the fault type is a pre-posed fault, if not, the target service method may be invoked, and the original target service method logic is executed, to implement the corresponding functions.

It should be noted that, if the identifier of the target service method is not matched with the service method targeted by the target fault description information, and/or the calling parameter and the value thereof are not matched with the calling parameter and the value thereof in the fault description information, the target service method may be called, and the original target service method logic may be executed to implement the corresponding function, and at the same time, the processing of the step S304 may be continuously executed, that is, other service methods may be continuously intercepted.

In step S308, if the fault type is a pre-class, a target fault injection logic corresponding to the target fault description information is injected into the target service method.

In implementation, as shown in fig. 4, if it is determined that the fault type corresponding to the target fault injection logic is a pre-class through the processing in step S306, the target fault injection logic may be injected into the target service method, after the injection is completed, the injected target fault injection logic may be executed, a corresponding fault result may be obtained through the executed target fault injection logic, and the obtained fault result may be recorded in a service log (e.g., a log file, etc.). When a user or a technician needs to check the fault result, the corresponding service log can be obtained through the monitoring system, the corresponding fault result can be obtained from the service log, and whether the server or the service system has the fault tolerance capability of the abnormal behavior of the fault category corresponding to the target fault injection logic or not can be judged through the obtained fault result. If the verification is passed, the service system can be indicated to be continuously used, and if the verification is not passed, the service system can be trimmed, and the safety of the service system is also ensured.

In practical applications, the pre-class may include three sub-classes, such as error throwing, delay and tampering parameter values, the processing in step S308 may be various, and the following provides an optional processing manner, which may specifically include the following: and if the fault type is a first subclass in the pre-class, judging whether a target fault injection logic corresponding to the target fault description information is injected into the target service method before the target service method is called according to the first subclass, wherein the first subclass is a parameter value for misthrowing, delaying or tampering.

In implementation, if the fault type corresponding to the target fault injection logic is a pre-class, it may be further determined to which subclass of the throw-miss, delay, and tamper parameter values the fault (or fault logic) corresponding to the target fault injection logic belongs, and according to a specific subclass to which the fault (or fault logic) belongs, it may be determined whether it is necessary to inject the target fault injection logic corresponding to the target fault description information to the target service method before the target service method is called, or it is necessary to inject the target fault injection logic corresponding to the target fault description information to the target service method after the target service method is called, and according to a determination result, it may be determined to inject the target fault injection logic corresponding to the target fault description information to the target service method.

In step S310, the Java Instrument or the AOP mechanism is used to modify the value of the called parameter or the return value of the called parameter corresponding to the target fault injection logic, so as to update the target fault injection logic.

In implementation, after target fault injection logic corresponding to target fault description information is injected into a target service method, if the injected target fault injection logic needs to be modified, a Java tool Java Instrument or a facet-oriented programming AOP mechanism (or may be similar to the AOP mechanism, etc.) may be used to modify a numerical value of a call parameter corresponding to the target fault injection logic or a return value of the call parameter, and perform online code replacement on a service system to implant a specific fault logic, so as to implement fault detection or verification through the corresponding fault logic.

EXAMPLE III

Based on the same idea, the fault injection method provided in the embodiments of the present specification further provides a fault injection apparatus, as shown in fig. 5.

The fault injection apparatus includes: a request interception module 501 and an injection module 502, wherein:

a request intercepting module 501, configured to intercept a call request of a target service method, where the call request includes an identifier of the target service method and a numerical value of a call parameter;

an injection module 502, configured to inject, to the target service method, target fault injection logic corresponding to the target fault description information if predetermined target fault description information matches the identifier of the target service method and the value of the call parameter, so as to determine a fault result generated by executing the target fault injection logic, where the target fault description information includes the identifier of the service method performing fault injection and the value of the call parameter corresponding to the service method.

In the embodiments of the present specification, the device is determined by an AOP mechanism oriented to the profile.

In this embodiment, the injection module 502 includes:

In the embodiment of the specification, the pre-class comprises throw error, delay and tamper parameter values,

In this embodiment, the target fault description information is written in a domain-specific language DSL.

In this embodiment of the present specification, the target fault description information includes a plurality of key fields, where the key fields are respectively used to represent an identifier of a service method for performing fault injection, a value of a call parameter, and a content of an injected fault logic.

In this embodiment, the key fields of the target fault description information are FROM, WHERE, and UPDATE, respectively.

In an embodiment of this specification, the apparatus further includes:

The embodiment of the present specification provides a fault injection apparatus, which intercepts a call request of a target service method, where the call request includes an identifier of the target service method and a value of a call parameter, and injects a target fault injection logic corresponding to target fault description information into the target service method to determine a fault result generated by executing the target fault injection logic when predetermined target fault description information matches the identifier of the target service method and the value of the call parameter, where the target fault description information includes the identifier of the service method performing fault injection and the value of the call parameter corresponding to the service method, so that a service method in a service system can be selected only through information such as the identifier of the service method performing fault injection described in the fault description information and the value of the call parameter corresponding to the service method, and injecting corresponding target fault injection logic, thereby obtaining a fault result generated by executing the target fault injection logic, without compiling the identifier of the service method for fault injection, the numerical value of the calling parameter corresponding to the service method, and the related program code of the information of the target fault injection logic, and the like, and without compiling the program code by using a server or terminal equipment of a service system, thereby greatly simplifying the processing process of fault injection and improving the fault injection efficiency.

Example four

Based on the same idea, the fault injection apparatus provided in the embodiments of the present specification further provides a fault injection device, as shown in fig. 6.

The fault injection device may be a server provided in the foregoing embodiment, and the server may include a fault injection interceptor established by a facet-oriented programming AOP mechanism (or may be a fault injection intercepting function or a fault injection intercepting mechanism, etc.).

Fault injection devices, which may vary significantly due to configuration or performance, may include one or more processors 601 and memory 602, where one or more stored applications or data may be stored in memory 602. Wherein the memory 602 may be transient or persistent storage. The application program stored in memory 602 may include one or more modules (not shown), each of which may include a series of computer-executable instructions for a fault injection device. Still further, the processor 601 may be configured to communicate with the memory 602 to execute a series of computer-executable instructions in the memory 602 on the fault injection device. The fault injection apparatus may also include one or more power supplies 603, one or more wired or wireless network interfaces 604, one or more input-output interfaces 605, one or more keyboards 606.

In particular, in this embodiment, the fault injection apparatus includes a memory, and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the fault injection apparatus, and the one or more programs configured to be executed by the one or more processors include computer-executable instructions for:

Optionally, the method further comprises:

The embodiment of the present specification provides a fault injection device, which, by intercepting a call request of a target service method, where the call request includes an identifier of the target service method and a value of a call parameter, and under a condition that predetermined target fault description information matches the identifier of the target service method and the value of the call parameter, injects a target fault injection logic corresponding to the target fault description information into the target service method to determine a fault result generated by executing the target fault injection logic, where the target fault description information includes the identifier of the service method performing fault injection and the value of the call parameter corresponding to the service method, so that a service method in a business system can be selected only through information such as the identifier of the service method performing fault injection described in the fault description information and the value of the call parameter corresponding to the service method, and injecting corresponding target fault injection logic, thereby obtaining a fault result generated by executing the target fault injection logic, without compiling the identifier of the service method for fault injection, the numerical value of the calling parameter corresponding to the service method, and the related program code of the information of the target fault injection logic, and the like, and without compiling the program code by using a server or terminal equipment of a service system, thereby greatly simplifying the processing process of fault injection and improving the fault injection efficiency.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functionality of the various elements may be implemented in the same one or more software and/or hardware implementations in implementing one or more embodiments of the present description.

As will be appreciated by one skilled in the art, embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

Embodiments of the present description are described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the description. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

One or more embodiments of the present description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The above description is only an example of the present specification, and is not intended to limit the present specification. Various modifications and alterations to this description will become apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present specification should be included in the scope of the claims of the present specification.

Claims

1. A fault injection method, comprising:

and if preset target fault description information is matched with the identification of the target service method and the numerical value of the calling parameter, injecting target fault injection logic corresponding to the target fault description information into the target service method to determine a fault result generated by executing the target fault injection logic, wherein the target fault description information comprises the identification of the service method for fault injection and the numerical value of the calling parameter corresponding to the service method, the fault type corresponding to the target fault injection logic comprises a pre-class, and the target fault description information is written by a field-specific language DSL.

2. The method of claim 1, wherein the injecting the target service method into the target fault injection logic corresponding to the target fault description information comprises:

3. The method of claim 2, the preamble classes comprising throw errors, delay and tamper parameter values,

4. The method according to claim 1, wherein the target fault description information includes a plurality of key fields, and the key fields are respectively used for characterizing the identifier of the service method performing fault injection and the value of the calling parameter, and the content of the injected fault logic.

5. The method of claim 4, the plurality of key fields of the target fault description information being FROM, WHERE, and UPDATE, respectively.

6. The method of claim 4 or 5, further comprising:

7. The method of claim 1, after injecting the target fault injection logic corresponding to the target fault description information into the target service method, the method further comprising:

8. A fault injection apparatus comprising:

and the injection module is used for injecting target fault injection logic corresponding to the target fault description information into the target service method to determine a fault result generated by executing the target fault injection logic if preset target fault description information is matched with the identifier of the target service method and the numerical value of the calling parameter, wherein the target fault description information comprises the identifier of the service method for fault injection and the numerical value of the calling parameter corresponding to the service method, the fault type corresponding to the target fault injection logic comprises a pre-class, and the target fault description information is written by a DSL (digital subscriber line) special language.

9. The device of claim 8, the device determined by a facet-oriented programming (AOP) mechanism.

10. The apparatus of claim 9, the injection module, comprising:

11. The apparatus of claim 10, the preamble classes comprising throw error, delay, and tamper parameter values,

12. The apparatus according to claim 9, wherein the target fault description information includes a plurality of key fields, and the plurality of key fields are respectively used to characterize an identifier of a service method performing fault injection and a value of a calling parameter, and a content of an injected fault logic.

13. The apparatus of claim 12, the plurality of key fields of the target fault description information being FROM, WHERE, and UPDATE, respectively.

14. The apparatus of claim 12 or 13, further comprising:

15. The apparatus of claim 9, the apparatus further comprising:

16. A fault checking apparatus, the fault checking apparatus comprising:

a processor; and