CN112527635A - Fault injection method and device, electronic equipment and storage medium - Google Patents
Fault injection method and device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN112527635A CN112527635A CN202011380846.4A CN202011380846A CN112527635A CN 112527635 A CN112527635 A CN 112527635A CN 202011380846 A CN202011380846 A CN 202011380846A CN 112527635 A CN112527635 A CN 112527635A
- Authority
- CN
- China
- Prior art keywords
- fault
- service
- configuration information
- calling request
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000002347 injection Methods 0.000 title claims abstract description 73
- 239000007924 injection Substances 0.000 title claims abstract description 73
- 238000000034 method Methods 0.000 title claims abstract description 59
- 238000012545 processing Methods 0.000 claims abstract description 33
- 230000015654 memory Effects 0.000 claims description 20
- 239000003999 initiator Substances 0.000 claims description 4
- 238000012360 testing method Methods 0.000 abstract description 7
- 230000002159 abnormal effect Effects 0.000 description 46
- 239000008186 active pharmaceutical agent Substances 0.000 description 44
- 238000011144 upstream manufacturing Methods 0.000 description 33
- 230000008569 process Effects 0.000 description 9
- 238000010586 diagram Methods 0.000 description 6
- 230000006870 function Effects 0.000 description 6
- 238000004891 communication Methods 0.000 description 4
- 238000004590 computer program Methods 0.000 description 4
- 230000005856 abnormality Effects 0.000 description 3
- 230000015556 catabolic process Effects 0.000 description 3
- 238000006731 degradation reaction Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 238000004088 simulation Methods 0.000 description 2
- 239000000243 solution Substances 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000001953 sensory effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/366—Software debugging using diagnostics
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Telephonic Communication Services (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application discloses a fault injection method, a fault injection device, electronic equipment and a storage medium, relates to the technical field of cloud computing, and further relates to the technical field of testing. The specific implementation scheme is as follows: acquiring fault configuration information associated with the service calling request under the condition that the acquired service calling request carries a fault identifier; the fault configuration information is configured based on a common fault configuration template; and carrying out fault processing on the service calling request according to the fault configuration information. The fault injection of the service can be realized without complicated manual operation, and a new idea is provided for injecting the fault into the service.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for fault injection, an electronic device, and a storage medium.
Background
Fault injection is a common means in fault handling, and can be used for testing different error forms of services in a micro-service architecture, so that downstream services can perform reasonable handling under various failure scenes of upstream services. However, currently, it is difficult to implement fault injection of services, and a tedious manual operation is required, so improvement is urgently needed.
Disclosure of Invention
The disclosure provides a fault injection method, a fault injection device, an electronic device and a storage medium.
According to an aspect of the present disclosure, there is provided a fault injection method, including:
acquiring fault configuration information associated with the service calling request under the condition that the acquired service calling request carries a fault identifier; the fault configuration information is configured based on a common fault configuration template;
and carrying out fault processing on the service calling request according to the fault configuration information.
According to another aspect of the present disclosure, there is provided a fault injection apparatus, the apparatus including:
the information acquisition module is used for acquiring fault configuration information associated with the service calling request under the condition that the acquired service calling request carries a fault identifier; the fault configuration information is configured based on a common fault configuration template;
and the fault processing module is used for carrying out fault processing on the service calling request according to the fault configuration information.
According to another aspect of the present disclosure, there is provided an electronic device including:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform a fault injection method as described in any of the embodiments herein.
According to another aspect of the present disclosure, there is provided a non-transitory computer readable storage medium having stored thereon computer instructions for causing a computer to execute a fault injection method according to any of the embodiments of the present application.
According to the technology of the application, the fault injection of the service can be realized without complicated manual operation, and a new idea is provided for injecting the fault into the service.
It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present disclosure, nor do they limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.
Drawings
The drawings are included to provide a better understanding of the present solution and are not intended to limit the present application. Wherein:
fig. 1 is a flowchart of a fault injection method provided according to an embodiment of the present application;
FIG. 2 is a flow chart of another fault injection method provided in accordance with an embodiment of the present application;
FIG. 3 is a flow chart of yet another fault injection method provided in accordance with an embodiment of the present application;
fig. 4A is a flowchart of yet another fault injection method provided in accordance with an embodiment of the present application;
fig. 4B is a block diagram of a fault injection system provided in accordance with an embodiment of the present application;
fig. 5 is a schematic structural diagram of a fault injection device according to an embodiment of the present application;
fig. 6 is a block diagram of an electronic device for implementing the fault injection method of the embodiment of the present application.
Detailed Description
The following description of the exemplary embodiments of the present application, taken in conjunction with the accompanying drawings, includes various details of the embodiments of the application for the understanding of the same, which are to be considered exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present application. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
Fig. 1 is a flowchart of a fault injection method according to an embodiment of the present application. The method and the device for realizing the fault injection of the service are suitable for the situation of how to realize the fault injection of the service, and are particularly suitable for how to realize the fault injection of the service accessed to the API gateway control platform. The embodiment may be performed by a fault injection apparatus, which may be implemented by software and/or hardware, and may be integrated in an electronic device carrying a fault injection function, such as an API gateway control platform in the electronic device. In the micro service architecture, the API gateway control platform serves as a unified gateway for traffic, processes all service call requests and responses, and can be regarded as a flow splitter. As shown in fig. 1, the method includes:
s101, acquiring fault configuration information associated with the service calling request under the condition that the acquired service calling request carries a fault identifier.
In this embodiment, the service call request may be a request sent by a downstream service to the API gateway control platform when the downstream service has an interface call requirement. Wherein, the downstream service is the caller of the application program interface; specifically, the downstream service may include a common user, and after the interface has accessed the API gateway control platform, the downstream service in this embodiment is preferably a tester of the application program interface in different error form scenarios of the service provided for the test interface; correspondingly, the upstream service is a provider of the application program interface, that is, a party that develops the application program interface, or may be said to be a party that provides the application program interface calling service to the outside.
Furthermore, according to whether the service calling request carries the fault identifier or not, the service calling request can be directly divided into a normal service calling request and an abnormal service calling request. Optionally, the abnormal service invocation request may carry a fault identifier; the API gateway control platform is used for executing a fault logic to simulate a required abnormal condition; optionally, different abnormal situations may be characterized using different fault signatures. In the actual scene, the abnormal condition includes unavailability of service, overload of service, abnormal service, and ultra-long delay, and correspondingly, the fault identifier in this embodiment includes a service rejection identifier, an abnormal service identifier, and an ultra-long delay identifier; further, the service rejection identifier includes a service unavailable identifier, a service overload identifier, and the like. Further, at least one fault identifier may be carried in one service invocation request.
Illustratively, as an optional mode of the embodiment of the present application, the fault identifier carried in the abnormal service invocation request may include a fault identifier field and a fault feature value; the fault identification field is used for distinguishing from a normal service calling request; optionally, the normal service invocation request may not include the fault identification field, or a numerical value of the fault identification field included in the normal service invocation request is different from a numerical value of the fault identification field included in the abnormal service invocation request; different abnormal situations may be characterized using different fault signature values.
Further, the fault identification may be added in a request header, a request path, or a request body of the exception service invocation request, etc. Optionally, the location where the fault identity is added to the request depends on the configuration of the fault configuration information. In this embodiment, the fault configuration information is obtained by configuring, by an upstream service, based on a common fault configuration template, and specifically is composed of an abnormal condition execution logic code segment. The common fault configuration template is a template providing an abnormal situation configuration option, request parameters (the request parameters may be a request header, a request path, a request body, or the like) can be customized in the common configuration template, and various abnormal situation execution logics can be configured based on the request parameters, a fault identifier, and the like. For example, the request header is customized in a common configuration template, and all abnormal-case execution logic is configured based on the request header, and then the fault identification may be added to the request header. In addition, in the common configuration template, standard exception return can be configured for each exception condition, and custom return can also be performed.
For example, different upstream services may each perform fault configuration on a provided interface based on a common fault configuration template; further, different interfaces of the same upstream service may configure the same fault configuration information. In addition, it should be noted that, for each interface, different abnormal-condition execution logic is located in the same fault configuration information; alternatively, for each interface, different exception condition execution logic is located in different fault configuration information.
After the interface is accessed to the API gateway control platform, for testing the abnormal condition of the service provided by the interface, the downstream service can determine a fault identifier and a fault identifier adding position according to the actual requirement and the fault configuration information of the interface configured by the upstream service; and then adding a fault identifier into the service calling request according to the fault identifier adding position, and sending the service calling request to an API gateway control platform, wherein the API gateway control platform can identify the service calling request after acquiring the service calling request, and if the acquired service calling request carries the fault identifier (for example, the fault identifier is carried in a request head of the service calling request), the acquired service calling request is an abnormal service calling request, and at the moment, fault configuration information related to the service calling request can be acquired according to related parameters (such as a service ID) included in the service calling request. Further, when different abnormal condition execution logics of the interface are positioned in the same fault configuration information, acquiring the interface fault configuration information associated with the service calling request; when different abnormal condition execution logics of the interface are located in different fault configuration information, the fault configuration information associated with the fault identification of the interface associated with the service calling request can be directly obtained.
It should be noted that, for a normal service call request, that is, the API gateway control platform does not recognize that the obtained service call request carries a fault identifier, the API gateway control platform may process the service call request according to the normal request processing logic, and specifically, the API gateway control platform may directly forward the service call request to the corresponding upstream service, so that the upstream service processes the service call request, and feeds back a processing result, and the like.
And S102, performing fault processing on the service calling request according to the fault configuration information.
Optionally, if the acquired fault configuration information is fault configuration information associated with a fault identifier of an interface associated with the service invocation request, the API gateway control platform may directly execute the fault configuration information, that is, execute a logic code segment in the fault configuration information associated with the fault identifier, so as to implement fault injection on the service invocation request.
Optionally, if the acquired fault configuration information is fault configuration information of an interface associated with the service call request, the API gateway control platform may determine, from the fault configuration information, an execution logic code segment of an abnormal condition associated with the fault identifier according to the fault configuration information and the fault identifier; the code segment is executed to implement fault injection for the service invocation request.
It is understood that an application program interface can provide one type of service, and further, fault injection of a service call request related to a certain interface is realized, namely, fault injection of the service provided by the interface is realized.
It should be noted that after the interface has been accessed to the API gateway control platform, fault injection needs to be performed on the service for testing different error forms of the service provided by the interface; however, at present, it is necessary to invade the failed execution logic code segment into the request sent by the downstream service, i.e. tamper the request sent by the downstream service, and treat the tampered request as a normal service call request by the upstream service, so as to test the true reaction of the upstream service to the abnormal condition. According to the method, the fault injection of the service provided by the interface can be realized on the API gateway level based on the fault configuration information without tampering the request sent by the downstream service; furthermore, the application can directly return the expected abnormal result obtained by executing the logic code segment to the downstream service without requesting the upstream service, so that the downstream service can process the abnormal result (such as fault tolerance or degradation), namely, the application is essentially a simulation fault injection.
Moreover, it is worth noting that tampering with the request sent by the downstream service is cumbersome and the user experience is poor; meanwhile, fault injection of different interfaces is required to be realized independently, namely multiplexing cannot be realized. The method and the device do not need to tamper the request sent by the downstream service, and are simple to realize; meanwhile, any upstream service in the application can perform fault configuration on the interface provided by the upstream service based on the common fault configuration template, and further can realize fault injection of the service provided by the interface based on the configured fault configuration information without independent realization, namely, the configuration between different interfaces can be reused.
According to the technical scheme of the embodiment of the application, the common fault configuration template is introduced, so that different upstream services can conveniently perform fault configuration on the provided interface, and independent implementation is not needed; and meanwhile, after the API gateway control platform identifies that the acquired service calling request carries a fault identifier, the service calling request is subjected to fault processing according to the acquired fault configuration information so as to realize simulated fault injection of the service provided by the interface. Compared with the existing mode for realizing service fault injection, the method is simple to realize, complex manual operation is not needed, and a new idea is provided for injecting the fault into the service.
In order to facilitate management and maintenance of configuration of fault injection, as an optional manner of the embodiment of the present application, the fault configuration information in the embodiment is configured by an upstream service on a configuration platform based on a common fault configuration template, and the fault configuration information is hosted by the configuration platform, for example, an interface ID (or a service ID) and the fault configuration information may be stored in an associated manner; optionally, in the case that different interfaces of the same upstream service may configure the same fault configuration information, the upstream service ID and the fault configuration information may be stored in an associated manner.
And then the API gateway control platform can acquire the fault configuration information associated with the service calling request from the configuration platform under the condition that the acquired service calling request carries the fault identification. Further, the API gateway control platform may obtain, from the configuration platform, fault configuration information of an interface associated with the service invocation request according to a relevant parameter (such as a service ID) included in the service invocation request; or the fault configuration information associated with the fault identification of the interface associated with the service call request can be directly obtained from the configuration platform. It is to be appreciated that the subject application hosts fault configuration to a configuration platform to enable fault configuration and fault handling decoupling. The configuration of fault injection is convenient to manage and maintain.
As an optional way of the embodiment of the present application, different interfaces of the same upstream service may configure the same fault configuration information; and then when the API gateway control platform acquires at least two service calling requests corresponding to the requests of different interfaces of the same upstream service, the API gateway can acquire fault configuration information of the upstream service under the condition that the API gateway recognizes that the at least two acquired service calling requests both carry fault identifications, and then can perform fault processing on the at least two service calling requests in parallel according to the fault configuration information. It can be understood that, in the scheme of the embodiment, multiple interfaces may share the same fault configuration information, which further increases the flexibility of the scheme and reduces the complexity of configuration.
Fig. 2 is a flowchart of another fault injection method provided in accordance with an embodiment of the present application. On the basis of the foregoing embodiment, in the present embodiment, a manner for performing fault processing on a service invocation request is provided when the obtained service invocation request carries at least two fault identifiers. As shown in fig. 2, the method includes:
s201, acquiring fault configuration information associated with the service calling request under the condition that the acquired service calling request carries a fault identifier; wherein the fault identifications are at least two.
Optionally, when different abnormal condition execution logics of the interface associated with the service invocation request are located in the same fault configuration information, the interface fault configuration information associated with the service invocation request may be obtained, and the fault configuration information includes at least two execution logic code segments of the abnormal condition associated with the fault identifier; when different abnormal condition execution logics of the interface associated with the service calling request are located in different fault configuration information, the fault configuration information associated with each fault identifier carried in the service calling request can be directly obtained.
S202, determining the priority of at least two fault identifications.
Optionally, when different abnormal condition execution logics of the interfaces associated with the service invocation request are located in the same fault configuration information, the priority of each fault identifier, that is, the priority of the execution logic code segment of the abnormal condition associated with each fault identifier, may be determined according to the logic relationship between the execution logic code segments of the abnormal condition associated with each fault identifier in the fault configuration information.
When different abnormal condition execution logics of the interface associated with the service call request are located in different fault configuration information, the priority of each fault identifier, that is, the priority of the execution logic code segment of the abnormal condition associated with each fault identifier, may be determined according to a preset priority condition.
Furthermore, the priority of the fault identification can be flexibly adjusted according to the actual situation. For example, when different abnormal condition execution logics of interfaces associated with the service call request are located in the same fault configuration information, the execution logic code segments of the abnormal conditions associated with each fault identifier do not need to be modified, and the priority among the fault identifiers can be modified only by modifying the logic relationship among the execution logic code segments of the abnormal conditions associated with each fault identifier.
S203, according to the priority, determining a target fault identifier from at least two fault identifiers.
Optionally, after determining the priority of at least two fault identifications, the fault identification with the higher priority may be used as the target fault identification.
And S204, performing fault processing on the service calling request according to the target fault identification and the fault configuration information.
Specifically, when different abnormal condition execution logics of the interface associated with the service call request are located in the same fault configuration information, the API gateway control platform may determine, from the fault configuration information, an execution logic code segment of the abnormal condition associated with the target fault identifier according to the fault configuration information and the target fault identifier; the code segment is executed to implement fault injection for the service invocation request.
Optionally, when different abnormal condition execution logics of the interface associated with the service invocation request are located in different fault configuration information, the API gateway control platform may directly execute the fault configuration information associated with the target fault identifier, so as to implement fault injection on the service invocation request.
According to the technical scheme of the embodiment of the application, different priorities are set for different fault identifications, so that downstream services can flexibly test different error forms of the services provided by the interface according to actual requirements, and the flexibility of the scheme is improved under the condition of realizing simulated fault injection of the services provided by the interface.
Fig. 3 is a flowchart of another fault injection method provided in accordance with an embodiment of the present application. On the basis of the foregoing embodiments, the present embodiment further explains the obtaining of the fault configuration information associated with the service invocation request. As shown in fig. 3, the method includes:
s301, under the condition that the acquired service calling request carries the fault identification, acquiring fault configuration information corresponding to the fault version identification associated with the service request according to the fault version identification carried in the service calling request.
In this embodiment, the fault version identifier is an identifier that serves as a unique identifier and is used to identify a version of fault configuration information used for fault processing of the service invocation request. For example, the upstream service may perform fault configuration on the provided interface based on the common fault configuration template at different stages according to actual needs; further, the upstream service has different fault version identifications of the fault configuration information configured at different stages for the same interface. Optionally, the fault version identifier may be generated according to a set rule, for example, a serial number, and the new fault version identifier is added by one on the basis of the previous fault version identifier.
Specifically, under the condition that the API gateway control platform recognizes that the acquired service calling request carries a fault identifier, if the service calling request also carries a fault version identifier, then fault configuration information corresponding to the fault version identifier associated with the service request is acquired. For example, the failure configuration information corresponding to the failure version identification associated with the service request may be obtained from the configuration platform.
Further, under the condition that the API gateway control platform recognizes that the acquired service calling request carries a fault identifier, if the service calling request does not carry a fault version identifier, the API gateway control platform may default to acquire fault configuration information corresponding to the latest fault version identifier; or the API gateway control platform may obtain the fault configuration information associated with the service invocation request according to the preset usage relationship between the fault configuration information associated with each fault version identifier.
It should be noted that, in this embodiment, when the configured fault configuration information needs to be changed or deleted (for example, the fault configuration information includes two fault identifier-associated execution logic code segments in the abnormal condition, and an execution logic code segment in the abnormal condition associated with any one of the fault identifiers needs to be deleted), the upstream service may reconfigure in the common fault configuration template, and retain the existing fault configuration information, so that when it is necessary to switch to the previous fault configuration information associated with the fault version identifier for fault handling, it may directly switch; meanwhile, the condition of fault processing of fault configuration information associated with different fault version identifications can be conveniently checked subsequently.
And S302, performing fault processing on the service calling request according to the fault configuration information.
According to the technical scheme of the embodiment of the application, the fault version identification is introduced, so that the fault processing condition can be conveniently checked by subsequently and quickly switching to the fault configuration information associated with other previous fault version identifications based on the fault version identification, and the flexibility of the scheme is further improved under the condition of realizing the simulated fault injection of the service provided by the interface.
Fig. 4A is a flowchart of yet another fault injection method provided in accordance with an embodiment of the present application; fig. 4B is a block diagram of a fault injection system according to an embodiment of the present application. In this embodiment, based on the above-described embodiment, a failure process performed on the service invocation request according to the failure configuration information is further explained. As shown in connection with fig. 4A and 4B, the method includes:
s401, under the condition that the acquired service calling request carries the fault identification, acquiring fault configuration information associated with the service calling request.
Optionally, in this embodiment, the upstream service may perform fault configuration on the configuration platform based on the common fault configuration template to obtain fault configuration information. The example is described in which the request header is customized in the common configuration template, and all the abnormal-condition execution logic is configured based on the request header to obtain the fault configuration information. The fault configuration information is as follows:
the special-header of the name of the request header in the fault configuration information can be modified according to requirements; the abort is used for representing a service unavailable identifier, the overload is used for representing a service overload identifier, the delay is used for representing an ultra-long delay identifier, and the mock is used for representing a service abnormal identifier; further, each abnormal condition may be configured with a standard abnormal return, for example, if the simulation service in the fault configuration information is unavailable, an error code 503 will be returned; as another example, the simulated service overload in the fault configuration information returns 502 an error code with a specified probability, that is, a part of the service invocation request is rejected with a specified probability, and the service invocation request that is not rejected can be forwarded to the upstream service for processing according to the normal processing logic. Further, each abnormal condition can also be returned by self-defining, for example, a service abnormality is simulated in the fault configuration information, and a specified service abnormality template (i.e., mock template) is returned; further, for the return of the business exception, a fixed numerical value can be returned.
Optionally, the fault configuration information is stored in the configuration platform. Further, the downstream service may determine a fault identifier (such as abort) and a fault identifier adding location (such as a request header) according to the actual demand and the fault configuration information of the interface configured by the upstream service; and then adding the fault identifier into the service calling request according to the fault identifier adding position, and sending the service calling request to the API gateway control platform, wherein the API gateway control platform can identify the service calling request after acquiring the service calling request, and if the acquired service calling request carries the fault identifier, the fault configuration information associated with the service calling request can be acquired from the configuration platform.
S402, executing fault configuration information to obtain a fault result.
The above-described failure configuration information is explained as an example. If the fault identifier is abort, simulating an abnormal condition that the service is unavailable by the API gateway control platform according to the fault configuration information to obtain a 503 error code; if the fault mark is overload, simulating the abnormal condition of service overload by the API gateway control platform according to the fault configuration information, and obtaining 502 error codes with a specified probability; if the fault identifier is delay, the API gateway control platform simulates an abnormal condition of service ultra-long delay according to the fault configuration information, and the obtained fault result is that the service calling request is delayed by ns (for example, a delay value specified by a delay-closed request header) and then forwarded to the corresponding upstream service; and if the fault identifier is mock, simulating the abnormal condition of the service exception by the API gateway control platform according to the fault configuration information to obtain a specified service exception template. Further, for the abnormal condition of the analog service abnormality, the obtained fault result may also be forwarded to the upstream service after an error parameter is added to the service invocation request.
S403, feeding back a failure result to the initiator of the service invocation request.
Specifically, the API gateway control platform may directly return the failure result to the downstream service for the downstream service to handle (e.g., fault tolerance or degradation) the failure result.
It should be noted that, for a normal service call request, that is, the API gateway control platform does not recognize that the obtained service call request carries a fault identifier, the API gateway control platform may process the service call request according to the normal request processing logic, and specifically, the API gateway control platform may directly forward the service call request to the corresponding upstream service, so that the upstream service processes the service call request, and feeds back a processing result, and the like.
According to the technical scheme of the embodiment of the application, under the condition that the acquired service calling request carries the fault identifier, the API gateway control platform can execute the fault configuration information and directly return the expected fault result without requesting the upstream service on the API gateway level so that the downstream service can process the fault (such as fault tolerance or degradation).
Fig. 5 is a schematic structural diagram of a fault injection apparatus according to an embodiment of the present application. The method and the device for realizing the fault injection of the service are suitable for the situation of how to realize the fault injection of the service, and are particularly suitable for how to realize the fault injection of the service accessed to the API gateway control platform. The embodiment may be performed by a fault injection apparatus, which may be implemented by software and/or hardware, and may be integrated in an electronic device carrying a fault injection function, such as an API gateway control platform in the electronic device. The fault injection apparatus 500 specifically includes:
an information obtaining module 501, configured to obtain fault configuration information associated with the service invocation request when it is identified that the obtained service invocation request carries a fault identifier; the fault configuration information is configured based on a common fault configuration template;
and a fault processing module 502, configured to perform fault processing on the service invocation request according to the fault configuration information.
According to the technical scheme of the embodiment of the application, the common fault configuration template is introduced, so that different upstream services can conveniently perform fault configuration on the provided interface, and independent implementation is not needed; and meanwhile, after the API gateway control platform identifies that the acquired service calling request carries a fault identifier, the service calling request is subjected to fault processing according to the acquired fault configuration information so as to realize simulated fault injection of the service provided by the interface. Compared with the existing mode for realizing service fault injection, the method is simple to realize, complex manual operation is not needed, and a new idea is provided for injecting the fault into the service.
Illustratively, the fault handling module 502 is specifically configured to:
determining the priority of at least two fault identifications;
determining a target fault identifier from at least two fault identifiers according to the priority;
and carrying out fault processing on the service calling request according to the target fault identification and the fault configuration information.
Illustratively, the information obtaining module 501 is specifically configured to:
and acquiring the fault configuration information associated with the service calling request from the configuration platform.
Illustratively, the information obtaining module 501 is further specifically configured to:
and acquiring fault configuration information corresponding to the fault version identification associated with the service request according to the fault version identification carried in the service calling request.
Illustratively, the fault handling module 502 is further specifically configured to:
executing fault configuration information to obtain a fault result;
and feeding back a fault result to the initiator of the service calling request.
Illustratively, the fault flag in this embodiment includes: at least one of a denial of service identification, a traffic anomaly identification, and an ultra-long delay identification.
According to an embodiment of the present application, an electronic device and a readable storage medium are also provided.
Fig. 6 is a block diagram of an electronic device according to the fault injection method of the embodiment of the present application. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the present application that are described and/or claimed herein.
As shown in fig. 6, the electronic apparatus includes: one or more processors 601, memory 602, and interfaces for connecting the various components, including a high-speed interface and a low-speed interface. The various components are interconnected using different buses and may be mounted on a common motherboard or in other manners as desired. The processor may process instructions for execution within the electronic device, including instructions stored in or on the memory to display graphical information of a GUI on an external input/output apparatus (such as a display device coupled to the interface). In other embodiments, multiple processors and/or multiple buses may be used, along with multiple memories and multiple memories, as desired. Also, multiple electronic devices may be connected, with each device providing portions of the necessary operations (e.g., as a server array, a group of blade servers, or a multi-processor system). In fig. 6, one processor 601 is taken as an example.
The memory 602 is a non-transitory computer readable storage medium as provided herein. Wherein the memory stores instructions executable by at least one processor to cause the at least one processor to perform the fault injection method provided herein. The non-transitory computer readable storage medium of the present application stores computer instructions for causing a computer to perform the fault injection method provided herein.
The memory 602, which is a non-transitory computer readable storage medium, may be used to store non-transitory software programs, non-transitory computer executable programs, and modules, such as program instructions/modules (e.g., the information acquisition module 501 and the fault handling module 502 shown in fig. 5) corresponding to the fault injection method in the embodiments of the present application. The processor 601 executes various functional applications of the server and data processing by running non-transitory software programs, instructions and modules stored in the memory 602, that is, implements the fault injection method in the above method embodiment.
The memory 602 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store data created according to the use of the electronic device of the fault injection method, and the like. Further, the memory 602 may include high speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, the memory 602 optionally includes memory located remotely from the processor 601, and these remote memories may be connected over a network to the fault injection method electronics. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
The electronic device of the fault injection method may further include: an input device 603 and an output device 604. The processor 601, the memory 602, the input device 603 and the output device 604 may be connected by a bus or other means, and fig. 6 illustrates the connection by a bus as an example.
The input device 603 may receive input numeric or character information and generate key signal inputs related to user settings and function control of the electronic equipment of the fault injection method, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, a pointing stick, one or more mouse buttons, a track ball, a joystick, or other input devices. The output devices 604 may include a display device, auxiliary lighting devices (e.g., LEDs), and tactile feedback devices (e.g., vibrating motors), among others. The display device may include, but is not limited to, a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display, and a plasma display. In some implementations, the display device can be a touch screen.
Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, application specific ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.
These computer programs (also known as programs, software applications, or code) include machine instructions for a programmable processor, and may be implemented using high-level procedural and/or object-oriented programming languages, and/or assembly/machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.
To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.
The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), Wide Area Networks (WANs), the internet, and blockchain networks.
The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, also called a cloud computing server or a cloud host, and is a host product in a cloud computing service system, so that the defects of high management difficulty and weak service expansibility in the traditional physical host and VPS service are overcome.
According to the technical scheme of the embodiment of the application, the common fault configuration template is introduced, so that different upstream services can conveniently perform fault configuration on the provided interface without independent implementation; and meanwhile, after the API gateway control platform identifies that the acquired service calling request carries a fault identifier, the service calling request is subjected to fault processing according to the acquired fault configuration information so as to realize simulated fault injection of the service provided by the interface. Compared with the existing mode for realizing service fault injection, the method is simple to realize, complex manual operation is not needed, and a new idea is provided for injecting the fault into the service.
It should be understood that various forms of the flows shown above may be used, with steps reordered, added, or deleted. For example, the steps described in the present application may be executed in parallel, sequentially, or in different orders, and the present invention is not limited thereto as long as the desired results of the technical solutions disclosed in the present application can be achieved.
The above-described embodiments should not be construed as limiting the scope of the present application. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made in accordance with design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present application shall be included in the protection scope of the present application.
Claims (14)
1. A fault injection method, comprising:
acquiring fault configuration information associated with the service calling request under the condition that the acquired service calling request carries a fault identifier; the fault configuration information is configured based on a common fault configuration template;
and carrying out fault processing on the service calling request according to the fault configuration information.
2. The method of claim 1, wherein if the number of the fault identifiers is at least two, performing fault processing on the service invocation request according to the fault configuration information includes:
determining the priority of the at least two fault identifications;
determining a target fault identifier from the at least two fault identifiers according to the priority;
and carrying out fault processing on the service calling request according to the target fault identification and the fault configuration information.
3. The method of claim 1, wherein obtaining fault configuration information associated with the service invocation request comprises:
and acquiring the fault configuration information associated with the service calling request from a configuration platform.
4. The method of claim 1, wherein obtaining fault configuration information associated with the service invocation request comprises:
and acquiring fault configuration information corresponding to the fault version identification associated with the service request according to the fault version identification carried in the service calling request.
5. The method of claim 1, wherein performing fault handling on the service invocation request according to the fault configuration information comprises:
executing the fault configuration information to obtain a fault result;
and feeding back a fault result to the initiator of the service calling request.
6. The method of claim 1, wherein the fault identification comprises: at least one of a denial of service identification, a traffic anomaly identification, and an ultra-long delay identification.
7. A fault injection apparatus comprising:
the information acquisition module is used for acquiring fault configuration information associated with the service calling request under the condition that the acquired service calling request carries a fault identifier; the fault configuration information is configured based on a common fault configuration template;
and the fault processing module is used for carrying out fault processing on the service calling request according to the fault configuration information.
8. The apparatus according to claim 7, wherein if the failure flags are at least two, the failure processing module is specifically configured to:
determining the priority of the at least two fault identifications;
determining a target fault identifier from the at least two fault identifiers according to the priority;
and carrying out fault processing on the service calling request according to the target fault identification and the fault configuration information.
9. The apparatus according to claim 7, wherein the information acquisition module is specifically configured to:
and acquiring the fault configuration information associated with the service calling request from a configuration platform.
10. The apparatus of claim 7, wherein the information acquisition module is further specifically configured to:
and acquiring fault configuration information corresponding to the fault version identification associated with the service request according to the fault version identification carried in the service calling request.
11. The apparatus of claim 7, wherein the failure handling module is further specifically configured to:
executing the fault configuration information to obtain a fault result;
and feeding back a fault result to the initiator of the service calling request.
12. The apparatus of claim 7, wherein the fault identification comprises: at least one of a denial of service identification, a traffic anomaly identification, and an ultra-long delay identification.
13. An electronic device, comprising:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the fault injection method of any of claims 1-6.
14. A non-transitory computer readable storage medium having stored thereon computer instructions for causing a computer to perform the fault injection method of any one of claims 1-6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011380846.4A CN112527635B (en) | 2020-11-30 | 2020-11-30 | Fault injection method and device, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011380846.4A CN112527635B (en) | 2020-11-30 | 2020-11-30 | Fault injection method and device, electronic equipment and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112527635A true CN112527635A (en) | 2021-03-19 |
| CN112527635B CN112527635B (en) | 2023-08-11 |
Family
ID=74995603
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011380846.4A Active CN112527635B (en) | 2020-11-30 | 2020-11-30 | Fault injection method and device, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112527635B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114880157A (en) * | 2022-07-08 | 2022-08-09 | 中电金信软件有限公司 | Fault injection method and device |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20040001249A (en) * | 2002-06-27 | 2004-01-07 | 주식회사 케이티 | Method for Probing the Network Section Concerning the Internet Service Failure |
| CN106155883A (en) * | 2015-03-30 | 2016-11-23 | 华为技术有限公司 | A kind of virtual machine method for testing reliability and device |
| CN109032825A (en) * | 2018-06-06 | 2018-12-18 | 阿里巴巴集团控股有限公司 | A kind of fault filling method, device and equipment |
| CN111666563A (en) * | 2020-06-05 | 2020-09-15 | 北京百度网讯科技有限公司 | Method and device for verifying application running state |
-
2020
- 2020-11-30 CN CN202011380846.4A patent/CN112527635B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20040001249A (en) * | 2002-06-27 | 2004-01-07 | 주식회사 케이티 | Method for Probing the Network Section Concerning the Internet Service Failure |
| CN106155883A (en) * | 2015-03-30 | 2016-11-23 | 华为技术有限公司 | A kind of virtual machine method for testing reliability and device |
| CN109032825A (en) * | 2018-06-06 | 2018-12-18 | 阿里巴巴集团控股有限公司 | A kind of fault filling method, device and equipment |
| CN111666563A (en) * | 2020-06-05 | 2020-09-15 | 北京百度网讯科技有限公司 | Method and device for verifying application running state |
Non-Patent Citations (1)
| Title |
|---|
| 陈强;吴立金;张凯;韩新宇;: "基于模型的软件接口故障注入测试平台技术", 计算机测量与控制, no. 11 * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114880157A (en) * | 2022-07-08 | 2022-08-09 | 中电金信软件有限公司 | Fault injection method and device |
| CN114880157B (en) * | 2022-07-08 | 2022-10-14 | 中电金信软件有限公司 | Fault injection method and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112527635B (en) | 2023-08-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110765024B (en) | Simulation test method, simulation test device, electronic equipment and computer readable storage medium | |
| CN112527252B (en) | Applet management method and device, applet platform, electronic equipment and medium | |
| CN111639027B (en) | Test method and device and electronic equipment | |
| KR102488582B1 (en) | Method and apparatus for verifying operation state of application | |
| CN113361838A (en) | Business wind control method and device, electronic equipment and storage medium | |
| CN112491617B (en) | Link tracking method, device, electronic equipment and medium | |
| CN111913884A (en) | Distributed test method, device, equipment, system and readable storage medium | |
| CN111835592A (en) | Method, apparatus, electronic device and readable storage medium for determining robustness | |
| CN111510480B (en) | Request sending method and device and first server | |
| CN111241396B (en) | Information pushing method and device, electronic equipment and storage medium | |
| CN111881387A (en) | Data processing method, device, equipment and medium for small program | |
| CN115222176A (en) | Risk control method, apparatus, device and medium | |
| CN111611767A (en) | Verification method and device | |
| CN111865720A (en) | Method, apparatus, device and storage medium for processing request | |
| CN111049690A (en) | Equipment fault monitoring processing method, device, equipment and storage medium | |
| CN112527635B (en) | Fault injection method and device, electronic equipment and storage medium | |
| CN112491858B (en) | Method, device, equipment and storage medium for detecting abnormal information | |
| CN111767149A (en) | Scheduling method, device, equipment and storage equipment | |
| CN112532528A (en) | Message routing method and device for rule engine | |
| WO2023169193A1 (en) | Method and device for generating smart contract | |
| CN112084000A (en) | Container cluster testing method and device | |
| CN112165430B (en) | Data routing method, device, equipment and storage medium | |
| CN112735601B (en) | Test method, device and equipment for determining infectious disease close-contact population by using Bluetooth | |
| CN111770170B (en) | Request processing method, device, equipment and computer storage medium | |
| CN111694686A (en) | Abnormal service processing method and device, electronic equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |