CN112527635A - 一种故障注入方法、装置、电子设备以及存储介质 - Google Patents

Abstract

本申请公开了故障注入方法、装置、电子设备以及存储介质，涉及云计算技术领域，进一步涉及测试技术领域。具体实现方案为：在识别到所获取的服务调用请求中携带有故障标识的情况下，获取所述服务调用请求关联的故障配置信息；所述故障配置信息基于公共故障配置模板进行配置得到；根据所述故障配置信息，对所述服务调用请求进行故障处理。无需繁冗的手工操作，即可实现服务的故障注入，为向服务中注入故障提供了一种新思路。

Description

一种故障注入方法、装置、电子设备以及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及云计算技术，具体涉及一种故障注入方法、装置、电子设备以及存储介质。

背景技术

故障注入是故障处理中的一种常用手段，可以用来测试微服务架构中服务的不同的错误形式，便于下游服务作好上游服务多种失败场景下的合理应对。然而，目前实现服务的故障注入，比较困难，需要繁冗的手工操作，亟需改进。

发明内容

本公开提供了一种故障注入方法、装置、电子设备以及存储介质。

根据本公开的一方面，提供了一种故障注入方法，该方法包括：

在识别到所获取的服务调用请求中携带有故障标识的情况下，获取所述服务调用请求关联的故障配置信息；所述故障配置信息基于公共故障配置模板进行配置得到；

根据所述故障配置信息，对所述服务调用请求进行故障处理。

根据本公开的另一方面，提供了一种故障注入装置，该装置包括：

信息获取模块，用于在识别到所获取的服务调用请求中携带有故障标识的情况下，获取所述服务调用请求关联的故障配置信息；所述故障配置信息基于公共故障配置模板进行配置得到；

故障处理模块，用于根据所述故障配置信息，对所述服务调用请求进行故障处理。

根据本公开的另一方面，提供了一种电子设备，该电子设备包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本申请任一实施例所述的故障注入方法。

根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行本申请任一实施例所述的故障注入方法。

根据本申请的技术无需繁冗的手工操作，即可实现服务的故障注入，为向服务中注入故障提供了一种新思路。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本申请的限定。其中：

图1是根据本申请实施例提供的一种故障注入方法的流程图；

图2是根据本申请实施例提供的另一种故障注入方法的流程图；

图3是根据本申请实施例提供的又一种故障注入方法的流程图；

图4A是根据本申请实施例提供的再一种故障注入方法的流程图；

图4B是根据本申请实施例提供的一种故障注入***的框架图；

图5是根据本申请实施例提供的一种故障注入装置的结构示意图；

图6是用来实现本申请实施例的故障注入方法的电子设备的框图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1是根据本申请实施例提供的一种故障注入方法的流程图。本申请实施例适用于如何实现服务的故障注入的情况，尤其适用于如何实现已接入API网关控制平台的服务的故障注入。该实施例可以由故障注入装置来执行，该装置可以采用软件和/或硬件来实现，并可集成于承载故障注入功能的电子设备中，如电子设备中API网关控制平台中。其中，在微服务架构中，API网关控制平台作为流量的统一出入口，处理所有的服务调用请求和响应，可以看作为分流器。如图1所示，该方法包括：

S101，在识别到所获取的服务调用请求中携带有故障标识的情况下，获取服务调用请求关联的故障配置信息。

本实施例中，服务调用请求可以是下游服务在具有接口调用需求的情况下，向API网关控制平台所发送的请求。其中，所谓下游服务为应用程序接口的调用方；具体的，下游服务可以包括普通用户，在接口已接入API网关控制平台后，为测试接口所提供服务的不同错误形式场景下，本实施例中下游服务优选为应用程序接口的测试者；对应的，上游服务为应用程序接口的提供方，即开发应用程序接口的一方，或者也可以说是对外提供应用程序接口调用服务的一方。

进一步的，按照服务调用请求中是否携带故障标识，可直接将服务调用请求分为正常服务调用请求和异常服务调用请求两类。可选的，异常服务调用请求中可携带故障标识；其中，故障标识用于指示API网关控制平台执行故障逻辑，以模拟所需异常情况；可选的，不同异常情况可使用不同故障标识进行表征。实际场景中异常情况包括服务不可用、服务过载、业务异常和超长延迟等，对应的，本实施例中的故障标识包括服务拒绝标识、业务异常标识和超长延迟标识；进一步的，服务拒绝标识包括服务不可用标识和服务过载标识等。进一步的，一个服务调用请求中可以携带至少一个故障标识。

示例性的，作为本申请实施例的一种可选方式，异常服务调用请求中所携带的故障标识可以包括故障标识字段和故障特征值；故障标识字段用于区别于正常服务调用请求；可选的，正常服务调用请求中可以不包括故障标识字段，或者正常服务调用请求中所包括的故障标识字段的数值与异常服务调用请求中所包括的故障标识字段的数值不同；不同异常情况可使用不同故障特征值进行表征。

进一步的，故障标识可添加在异常服务调用请求的请求头、请求路径或者请求体中等。可选的，故障标识添加到请求中的位置取决于故障配置信息的配置。本实施例中，故障配置信息由上游服务基于公共故障配置模板进行配置得到，具体由异常情况执行逻辑代码段构成。其中，所谓公共故障配置模板为提供异常情况配置选项的模板，在公共配置模板中可自定义请求参数(请求参数可以是请求头、请求路径或请求体等)，并可基于请求参数和故障标识等配置各种异常情况执行逻辑。例如，在公共配置模板中自定义请求头，且所有的异常情况执行逻辑均基于请求头进行配置，进而故障标识可添加到请求头中。此外，在公共配置模板中，每个异常情况均可配置标准异常返回，也可以进行自定义返回。

示例性的，不同上游服务均可基于公共故障配置模板对所提供的接口进行故障配置；进一步的，同一上游服务的不同接口可配置相同的故障配置信息。此外，需要说明的是，对于每一接口，不同的异常情况执行逻辑位于同一故障配置信息中；或者，对于每一接口，不同的异常情况执行逻辑位于不同的故障配置信息中。

在接口已接入API网关控制平台后，为测试接口所提供服务的异常情况，下游服务可以根据实际需求以及上游服务所配置的该接口的故障配置信息，确定故障标识以及故障标识添加位置；之后根据故障标识添加位置，将故障标识添加到服务调用请求中，并向API网关控制平台发送服务调用请求，API网关控制平台在获取到服务调用请求之后，可以对服务调用请求进行识别，若识别到所获取的服务调用请求中携带故障标识(例如，服务调用请求的请求头中携带有故障标识)，则说明所获取的服务调用请求是异常服务调用请求，此时可以根据服务调用请求中所包括的相关参数(比如服务ID)，获取服务调用请求关联的故障配置信息。进一步的，在该接口的不同的异常情况执行逻辑位于同一故障配置信息中时，获取服务调用请求关联的接口故障配置信息；在该接口的不同的异常情况执行逻辑位于不同的故障配置信息中时，可以直接获取服务调用请求关联的接口的故障标识关联的故障配置信息。

需要说明的是，对于正常服务调用请求，即API网关控制平台未识别到所获取的服务调用请求中携带故障标识，则API网关控制平台可以按照正常请求处理逻辑进行处理，具体的，API网关控制平台可直接将服务调用请求转发给对应的上游服务，以便上游服务对该服务调用请求进行处理，并反馈处理结果等。

S102，根据故障配置信息，对服务调用请求进行故障处理。

可选的，若所获取的故障配置信息是服务调用请求关联的接口的故障标识关联的故障配置信息，则API网关控制平台可以直接执行故障配置信息，即执行故障标识关联的故障配置信息中逻辑代码段，以实现对服务调用请求的故障注入。

可选的，若所获取的故障配置信息是服务调用请求关联的接口的故障配置信息，则API网关控制平台可以根据故障配置信息和故障标识，从故障配置信息中确定故障标识关联的异常情况的执行逻辑代码段；执行该代码段，以实现对服务调用请求的故障注入。

可以理解的是，一个应用程序接口可以提供一种类型服务，进而实现关于某一接口的服务调用请求的故障注入，即实现了该接口所提供服务的故障注入。

需要说明的是，在接口已接入API网关控制平台后，为测试接口所提供服务的不同错误形式，需对服务进行故障注入；然而，目前，需要将故障的执行逻辑代码段侵入到下游服务所发送的请求中，即篡改下游服务所发送的请求，并将篡改后的请求当作正常服务调用请求，由上游服务进行处理，以测试上游服务对异常情况的真实反应。而本申请无需篡改下游服务所发送的请求，基于故障配置信息，在API网关层面即可实现对接口所提供服务的故障注入；进一步的，本申请可以不请求上游服务，直接将执行逻辑代码段得到的预期异常结果返回给下游服务，以便下游服务对此处理(如容错或降级)，即本申请实质是一种模拟故障注入。

此外，值得注意的是，篡改下游服务所发送的请求比较繁琐，且用户体验不佳；同时，对于不同的接口的故障注入，均需要单独实现，即无法复用。而本申请无需篡改下游服务所发送的请求，实现简单；同时本申请中任一上游服务均可基于公共故障配置模板对其所提供的接口进行故障配置，进而基于所配置的故障配置信息，即可实现接口所提供服务的故障注入，无需单独实现，即不同接口之间的配置可复用。

本申请实施例的技术方案，通过引入公共故障配置模板，便于不同上游服务对所提供的接口进行故障配置，无需单独实现；同时，由API网关控制平台后在识别到所获取的服务调用请求中携带故障标识的情况下，根据所获取的故障配置信息，对服务调用请求进行故障处理，以实现对接口所提供服务的模拟故障注入。相比于现有实现服务故障注入方式，本申请实现简单，无需繁琐的手工操作，为向服务中注入故障提供了一种新思路。

为了便于对故障注入的配置进行管理和维护，作为本申请实施例的一种可选方式，本实施例中的故障配置信息由上游服务在配置平台基于公共故障配置模板进行配置得到，且故障配置信息托管于配置平台，例如，可以将接口ID(或服务ID)与故障配置信息进行关联存储；可选的，在同一上游服务的不同接口可配置相同的故障配置信息的情况下，还可以将上游服务ID与故障配置信息进行关联存储。

进而API网关控制平台在识别到所获取的服务调用请求中携带故障标识的情况下，可以从配置平台中获取服务调用请求关联的故障配置信息。进一步的，API网关控制平台可以根据服务调用请求中所包括的相关参数(比如服务ID)，从配置平台中获取服务调用请求关联的接口的故障配置信息；或者可以直接从配置平台中获取服务调用请求关联的接口的故障标识关联的故障配置信息。可以理解的是，本申请将故障配置托管于配置平台，以实现故障配置和故障处理解耦。便于对故障注入的配置进行管理和维护。

作为本申请实施例的一种可选方式，同一上游服务的不同接口可配置相同的故障配置信息；进而在API网关控制平台获取到至少两个服务调用请求，且至少两个服务调用请求对应于同一上游服务的不同接口的请求时，API网关在识别到所获取的至少两个服务调用请求中均携带有故障标识的情况下，可以获取该上游服务的故障配置信息，之后可以根据故障配置信息，并行对至少两个服务调用请求进行故障处理。可以理解的是，本实施例的方案多个接口可共用同一故障配置信息，进一步增加了方案的灵活度，同时降低了配置的复杂度。

图2是根据本申请实施例提供的另一种故障注入方法的流程图。本实施例在上述实施例的基础上，在所获取的服务调用请求携带至少两个故障标识的情况下，提供了一种对服务调用请求进行故障处理的方式。如图2所示，该方法包括：

S201，在识别到所获取的服务调用请求中携带有故障标识的情况下，获取服务调用请求关联的故障配置信息；其中，故障标识为至少两个。

可选的，在服务调用请求关联的接口的不同的异常情况执行逻辑位于同一故障配置信息中时，可以获取服务调用请求关联的接口故障配置信息，且故障配置信息中包括至少两个故障标识关联的异常情况的执行逻辑代码段；在服务调用请求关联的接口的不同的异常情况执行逻辑位于不同的故障配置信息中时，可以直接获取服务调用请求中携带的各故障标识关联的故障配置信息。

S202，确定至少两个故障标识的优先级。

可选的，在服务调用请求关联的接口的不同的异常情况执行逻辑位于同一故障配置信息中时，可以根据故障配置信息中各故障标识关联的异常情况的执行逻辑代码段之间的逻辑关系，确定各故障标识的优先级，即各故障标识关联的异常情况的执行逻辑代码段的优先级。

在服务调用请求关联的接口的不同的异常情况执行逻辑位于不同的故障配置信息中时，可以根据预先设定的优先级情况，确定各故障标识的优先级，即各故障标识关联的异常情况的执行逻辑代码段的优先级。

进一步的，故障标识的优先级也可根据实际情况灵活调整。例如，在服务调用请求关联的接口的不同的异常情况执行逻辑位于同一故障配置信息中时，无需修改各故障标识关联的异常情况的执行逻辑代码段，只需通过修改各故障标识关联的异常情况的执行逻辑代码段之间的逻辑关系，即可以修改各故障标识之间的优先级。

S203，根据优先级，从至少两个故障标识中确定目标故障标识。

可选的，在确定至少两个故障标识的优先级之后，可以将优先级高的故障标识，作为目标故障标识。

S204，根据目标故障标识和故障配置信息，对服务调用请求进行故障处理。

具体的，在服务调用请求关联的接口的不同的异常情况执行逻辑位于同一故障配置信息中时，API网关控制平台可以根据故障配置信息和目标故障标识，从故障配置信息中确定目标故障标识关联的异常情况的执行逻辑代码段；执行该代码段，以实现对服务调用请求的故障注入。

可选的，在服务调用请求关联的接口的不同的异常情况执行逻辑位于不同的故障配置信息中时，API网关控制平台可以直接执行目标故障标识关联的故障配置信息，以实现对服务调用请求的故障注入。

本申请实施例的技术方案，通过为不同故障标识设置不同优先级，便于下游服务根据实际需求灵活测试接口所提供服务的不同错误形式，在实现对接口所提供服务的模拟故障注入的情况下，增加了方案的灵活度。

图3是根据本申请实施例提供的又一种故障注入方法的流程图。本实施例在上述实施例的基础上，进一步对获取服务调用请求关联的故障配置信息进行解释说明。如图3所示，该方法包括：

S301，在识别到所获取的服务调用请求中携带有故障标识的情况下，根据服务调用请求中携带的故障版本标识，获取服务请求关联的故障版本标识对应的故障配置信息。

本实施例中，故障版本标识是一个起到唯一标识作用的标识符，用于标识对服务调用请求进行故障处理所使用的故障配置信息的版本。示例性的，上游服务可以根据实际需求，在不同阶段基于公共故障配置模板，对所提供的接口进行故障配置；进一步的，上游服务对于同一接口，在不同阶段所配置的故障配置信息的故障版本标识不同。可选的，故障版本标识可以按照设定规则生成，例如流水号，进而新的故障版本标识是在前一故障版本标识的基础上加一。

具体的，API网关控制平台在识别到所获取的服务调用请求中携带故障标识的情况下，若服务调用请求中还携带故障版本标识，则获取服务请求关联的故障版本标识对应的故障配置信息。例如，可以从配置平台中获取服务请求关联的故障版本标识对应的故障配置信息。

进一步的，API网关控制平台在识别到所获取的服务调用请求中携带故障标识的情况下，若服务调用请求中未携带有故障版本标识，则API网关控制平台可以默认获取最新的故障版本标识对应的故障配置信息；或者可以是API网关控制平台可以根据预先设定的各故障版本标识关联的故障配置信息之间的使用关系，获取服务调用请求关联的故障配置信息。

需要说明的是，本实施例中，上游服务在需要对已配置好的故障配置信息进行更改或删除(例如，故障配置信息中包括两个故障标识关联的异常情况的执行逻辑代码段，需要删除其中的任一故障标识关联的异常情况的执行逻辑代码段)时，可在公共故障配置模板中重新配置，而保留已有的故障配置信息，这样在需要切换到之前故障版本标识关联的故障配置信息进行故障处理时，可直接切换；同时，后续还可以方便地查看不同故障版本标识关联的故障配置信息进行故障处理的情况等。

S302，根据故障配置信息，对服务调用请求进行故障处理。

本申请实施例的技术方案，通过引入故障版本标识，便于后续基于故障版本标识快速切换至之前其他故障版本标识关联的故障配置信息查看故障处理情况，在实现对接口所提供服务的模拟故障注入的情况下，进一步增加了方案的灵活度。

图4A是根据本申请实施例提供的再一种故障注入方法的流程图；图4B是根据本申请实施例提供的一种故障注入***的框架图。本实施例在上述实施例的基础上，进一步对根据故障配置信息，对服务调用请求进行故障处理进行解释说明。结合图4A和4B所示，该方法包括：

S401，在识别到所获取的服务调用请求中携带有故障标识的情况下，获取服务调用请求关联的故障配置信息。

可选的，本实施例中上游服务可在配置平台基于公共故障配置模板进行故障配置得到故障配置信息。以在公共配置模板中自定义请求头，且所有的异常情况执行逻辑均基于请求头进行配置得到故障配置信息为例进行说明。故障配置信息如下：

其中，故障配置信息中请求头header的名称special-header可根据需求进行修改；abort用于表示服务不可用标识，overload用于表示服务过载标识，delay用于表示超长延迟标识，mock用于表示业务异常标识；进一步的，每个异常情况均可配置标准异常返回，例如，上述故障配置信息中模拟服务不可用，将返回503错误码；又如，故障配置信息中模拟服务过载，将以指定概率返回502错误码，即以指定概率拒绝部分服务调用请求，对于未拒绝的服务调用请求还可以按照正常处理逻辑，转发给上游服务进行处理。进一步的，每个异常情况也可以进行自定义返回，例如，上述故障配置信息中模拟业务异常，将返回指定的业务异常模板(即mock模板)；进一步的，对于业务异常的返回，也可以返回固定的数值。

可选的，故障配置信息存储于配置平台。进而下游服务可以根据实际需求以及上游服务所配置的该接口的故障配置信息，确定故障标识(比如abort)以及故障标识添加位置(比如请求头)；之后根据故障标识添加位置，将故障标识添加到服务调用请求中，并向API网关控制平台发送服务调用请求，API网关控制平台在获取到服务调用请求之后，可以对服务调用请求进行识别，若识别到所获取的服务调用请求中携带故障标识，则可以从配置平台获取服务调用请求关联的故障配置信息。

S402，执行故障配置信息，得到故障结果。

以上述所示的故障配置信息为例进行说明。若故障标识为abort，则API网关控制平台根据故障配置信息，模拟服务不可用异常情况，得到503错误码；若故障标识为overload，则API网关控制平台根据故障配置信息，模拟服务过载异常情况，以指定概率得到502错误码；若故障标识为delay，则API网关控制平台根据故障配置信息，模拟服务超长延迟异常情况，得到的故障结果即为将服务调用请求延迟ns(例如delay-millisecond请求头所指定的延时取值)后转发给对应的上游服务；若故障标识为mock，则API网关控制平台根据故障配置信息，模拟业务异常的异常情况，得到指定的业务异常模板。进一步的，对于模拟业务异常的异常情况，得到的故障结果也可以是向服务调用请求中添加一个错误参数后转发给上游服务。

S403，向服务调用请求的发起方反馈故障结果。

具体的，API网关控制平台可以直接将故障结果返回给下游服务，以便下游服务对此处理(如容错或降级)。

需要说明的是，对于正常服务调用请求，即API网关控制平台未识别到所获取的服务调用请求中携带故障标识，则API网关控制平台可以按照正常请求处理逻辑进行处理，具体的，API网关控制平台可直接将服务调用请求转发给对应的上游服务，以便上游服务对该服务调用请求进行处理，并反馈处理结果等。

本申请实施例的技术方案，API网关控制平台在识别到所获取的服务调用请求中携带故障标识的情况下，可以不请求上游服务，在API网关层面，执行故障配置信息，并直接将预期的故障结果返回，以便下游服务对此处理(如容错或降级)。

图5是根据本申请实施例提供的一种故障注入装置的结构示意图。本申请实施例适用于如何实现服务的故障注入的情况，尤其适用于如何实现已接入API网关控制平台的服务的故障注入。该实施例可以由故障注入装置来执行，该装置可以采用软件和/或硬件来实现，并可集成于承载故障注入功能的电子设备中，如电子设备中API网关控制平台中。该故障注入装置500具体包括：

信息获取模块501，用于在识别到所获取的服务调用请求中携带有故障标识的情况下，获取服务调用请求关联的故障配置信息；故障配置信息基于公共故障配置模板进行配置得到；

故障处理模块502，用于根据故障配置信息，对服务调用请求进行故障处理。

本申请实施例的技术方案，通过引入公共故障配置模板，便于不同上游服务对所提供的接口进行故障配置，无需单独实现；同时，由API网关控制平台后在识别到所获取的服务调用请求中携带故障标识的情况下，根据所获取的故障配置信息，对服务调用请求进行故障处理，以实现对接口所提供服务的模拟故障注入。相比于现有实现服务故障注入方式，本申请实现简单，无需繁琐的手工操作，为向服务中注入故障提供了一种新思路。

示例性的，故障处理模块502具体用于：

确定至少两个故障标识的优先级；

根据优先级，从至少两个故障标识中确定目标故障标识；

根据目标故障标识和故障配置信息，对服务调用请求进行故障处理。

示例性的，信息获取模块501具体用于：

从配置平台获取服务调用请求关联的故障配置信息。

示例性的，信息获取模块501还具体用于：

根据服务调用请求中携带的故障版本标识，获取服务请求关联的故障版本标识对应的故障配置信息。

示例性的，故障处理模块502还具体用于：

执行故障配置信息，得到故障结果；

向服务调用请求的发起方反馈故障结果。

示例性的，本实施例中故障标识包括：服务拒绝标识、业务异常标识、以及超长延迟标识中的至少一个。

根据本申请的实施例，本申请还提供了一种电子设备和一种可读存储介质。

如图6所示，是根据本申请实施例的故障注入方法的电子设备的框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图6所示，该电子设备包括：一个或多个处理器601、存储器602，以及用于连接各部件的接口，包括高速接口和低速接口。各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示GUI的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个电子设备，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器***)。图6中以一个处理器601为例。

存储器602即为本申请所提供的非瞬时计算机可读存储介质。其中，所述存储器存储有可由至少一个处理器执行的指令，以使所述至少一个处理器执行本申请所提供的故障注入方法。本申请的非瞬时计算机可读存储介质存储计算机指令，该计算机指令用于使计算机执行本申请所提供的故障注入方法。

存储器602作为一种非瞬时计算机可读存储介质，可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块，如本申请实施例中的故障注入方法对应的程序指令/模块(例如，附图5所示的信息获取模块501和故障处理模块502)。处理器601通过运行存储在存储器602中的非瞬时软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中的故障注入方法。

存储器602可以包括存储程序区和存储数据区，其中，存储程序区可存储操作***、至少一个功能所需要的应用程序；存储数据区可存储根据故障注入方法的电子设备的使用所创建的数据等。此外，存储器602可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中，存储器602可选包括相对于处理器601远程设置的存储器，这些远程存储器可以通过网络连接至故障注入方法的电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

故障注入方法的电子设备还可以包括：输入装置603和输出装置604。处理器601、存储器602、输入装置603和输出装置604可以通过总线或者其他方式连接，图6中以通过总线连接为例。

输入装置603可接收输入的数字或字符信息，以及产生与故障注入方法的电子设备的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置604可以包括显示设备、辅助照明装置(例如，LED)和触觉反馈装置(例如，振动电机)等。该显示设备可以包括但不限于，液晶显示器(LCD)、发光二极管(LED)显示器和等离子体显示器。在一些实施方式中，显示设备可以是触摸屏。

此处描述的***和技术的各种实施方式可以在数字电子电路***、集成电路***、专用ASIC(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程***上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储***、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储***、该至少一个输入装置、和该至少一个输出装置。

这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令，并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(PLD))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互，可以在计算机上实施此处描述的***和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的***和技术实施在包括后台部件的计算***(例如，作为数据服务器)、或者包括中间件部件的计算***(例如，应用服务器)、或者包括前端部件的计算***(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的***和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算***中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将***的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)、互联网和区块链网络。

计算机***可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务中，存在的管理难度大，业务扩展性弱的缺陷。

根据本申请实施例的技术方案，通过引入公共故障配置模板，便于不同上游服务对所提供的接口进行故障配置，无需单独实现；同时，由API网关控制平台后在识别到所获取的服务调用请求中携带故障标识的情况下，根据所获取的故障配置信息，对服务调用请求进行故障处理，以实现对接口所提供服务的模拟故障注入。相比于现有实现服务故障注入方式，本申请实现简单，无需繁琐的手工操作，为向服务中注入故障提供了一种新思路。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。

Claims (14)

1.一种故障注入方法，包括：

在识别到所获取的服务调用请求中携带有故障标识的情况下，获取所述服务调用请求关联的故障配置信息；所述故障配置信息基于公共故障配置模板进行配置得到；

根据所述故障配置信息，对所述服务调用请求进行故障处理。

2.根据权利要求1所述的方法，其中，若所述故障标识为至少两个，则根据所述故障配置信息，对所述服务调用请求进行故障处理，包括：

确定所述至少两个故障标识的优先级；

根据所述优先级，从所述至少两个故障标识中确定目标故障标识；

根据所述目标故障标识和所述故障配置信息，对所述服务调用请求进行故障处理。

3.根据权利要求1所述的方法，其中，获取所述服务调用请求关联的故障配置信息，包括：

从配置平台获取所述服务调用请求关联的故障配置信息。

4.根据权利要求1所述的方法，其中，获取所述服务调用请求关联的故障配置信息，包括：

根据所述服务调用请求中携带的故障版本标识，获取所述服务请求关联的所述故障版本标识对应的故障配置信息。

5.根据权利要求1所述的方法，其中，根据所述故障配置信息，对所述服务调用请求进行故障处理，包括：

执行所述故障配置信息，得到故障结果；

向所述服务调用请求的发起方反馈故障结果。

6.根据权利要求1所述的方法，其中，所述故障标识包括：服务拒绝标识、业务异常标识、以及超长延迟标识中的至少一个。

7.一种故障注入装置，包括：

信息获取模块，用于在识别到所获取的服务调用请求中携带有故障标识的情况下，获取所述服务调用请求关联的故障配置信息；所述故障配置信息基于公共故障配置模板进行配置得到；

故障处理模块，用于根据所述故障配置信息，对所述服务调用请求进行故障处理。

8.根据权利要求7所述的装置，其中，若所述故障标识为至少两个，则所述故障处理模块具体用于：

确定所述至少两个故障标识的优先级；

根据所述优先级，从所述至少两个故障标识中确定目标故障标识；

根据所述目标故障标识和所述故障配置信息，对所述服务调用请求进行故障处理。

9.根据权利要求7所述的装置，其中，所述信息获取模块具体用于：

从配置平台获取所述服务调用请求关联的故障配置信息。

10.根据权利要求7所述的装置，其中，所述信息获取模块还具体用于：

根据所述服务调用请求中携带的故障版本标识，获取所述服务请求关联的所述故障版本标识对应的故障配置信息。

11.根据权利要求7所述的装置，其中，所述故障处理模块还具体用于：

执行所述故障配置信息，得到故障结果；

向所述服务调用请求的发起方反馈故障结果。

12.根据权利要求7所述的装置，其中，所述故障标识包括：服务拒绝标识、业务异常标识、以及超长延迟标识中的至少一个。

13.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-6中任一项所述的故障注入方法。

14.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使计算机执行权利要求1-6中任一项所述的故障注入方法。

Images