CN110674028A - 故障注入方法及其装置、业务服务系统 - Google Patents

Abstract

本申请公开了一种故障注入方法，包括：第一应用程序生成业务消息，业务消息用于访问第二应用程序；故障注入模块获取业务消息，对业务消息执行故障属性参数所指示的故障注入操作；故障注入模块将执行故障注入操作后的业务消息发送至第二应用程序。本申请提高了根据注入的故障进行可靠性测试的精确度。

Description

故障注入方法及其装置、业务服务系统

技术领域

本申请涉及计算机领域，特别涉及一种故障注入方法及其装置、业务服务系统。

背景技术

随着云计算技术的快速发展，云服务的使用越来越普遍。并且，对于云服务提供商来说，在其他云服务(下面称为云服务A)的基础上构建自己的云服务(下面称为云服务B)，能够有效提高云服务的开发效率。但是，这样会使该云服务B对云服务A具有一定的依赖性，导致当云服务A的实现系统出现故障时，云服务B可能出现服务不可用的情况，因此，测试云服务的实现系统在其所依赖的云服务的实现系统出现故障时的可靠性，是很有必要的。

相关技术中，对云服务B的实现系统进行可靠性测试的实现方式为：向云服务A的实现系统注入故障，以模拟出云服务A的实现系统出现故障的情况，然后使用该出现故障的实现系统继续向云服务B的实现系统提供云服务，再观察云服务B的实现系统在接收到该出现故障的实现系统提供的云服务后的表现，然后根据该表现评估云服务B的实现系统的可靠性。其中，目前注入的故障主要包括：实现云服务的服务器的停机故障、实现云服务的服务器的断网故障和云服务进程的强制退出故障。

但是，以上故障均为全局性的故障，导致根据该故障进行可靠性测试的精确度较低。

发明内容

本申请提供了一种故障注入方法及其装置、业务服务系统，可以解决目前的可靠性测试的精确度较低的问题。

第一方面，提供了一种故障注入方法，该方法应用于业务服务系统，业务服务系统中运行有第一应用程序、第二应用程序和故障注入模块，方法包括：第一应用程序生成业务消息，业务消息用于访问第二应用程序；故障注入模块获取业务消息，对业务消息执行故障属性参数所指示的故障注入操作；故障注入模块将执行故障注入操作后的业务消息发送至第二应用程序。

在本申请实施例提供的故障注入方法中，在第一应用程序生成用于访问第二应用程序的业务消息后，通过故障注入模块获取该业务消息，对业务消息执行故障属性参数所指示的故障注入操作，并向第二应用程序发送执行故障注入操作后的业务消息，能够在业务消息的发送过程中注入故障，相较于相关技术中的全局性故障，细化了注入故障的粒度，有效的提高了根据注入的故障进行可靠性测试的精确度。并且，由于是在业务消息的发送过程中，通过拦截业务消息实现注入故障的，使得无需对注入故障的对象做适配工作，可以做到故障的无感知注入。

作为使故障注入模块获取业务消息的一种可实现方式中，业务服务系统中还运行有地址转换模块，在故障注入模块获取业务消息之前，方法还包括：地址转换模块获取业务消息，将业务消息的目的地址修改为故障注入模块的地址，发送修改后的业务消息。

在一种实现方式中，故障注入模块对业务消息执行故障属性参数所指示的故障注入操作，包括：故障注入模块在业务消息符合过滤条件时，对业务消息执行故障属性参数所指示的故障注入操作。通过使用过滤条件对业务消息进行过滤，并在业务消息符合过滤条件时，对业务消息注入故障，使得可以对业请求有针对性地进行故障注入，能够避免在测试过程中引入无关的测试，实现对故障的精准注入。

其中，当业务消息为业务请求时，过滤条件涉及以下一项或多项内容：请求类型、请求访问的地址、请求头关键字和请求体关键字；当业务消息为针对业务请求的响应时，过滤条件涉及以下一项或多项内容：响应状态码、响应头关键字和响应体关键字。

可选的，故障属性参数所指示的故障注入操作可以为丢包操作、时延操作和错包操作，相应的，执行故障属性参数所指示的故障注入操作，可以包括以下几种情况：

业务消息包括多个数据包，当故障属性参数所指示的故障注入操作为丢包操作时，故障注入模块对业务消息执行故障属性参数所指示的故障注入操作，包括：故障注入模块基于故障属性参数，丢弃多个数据包中的部分或全部。

当故障属性参数所指示的故障注入操作为时延操作时，故障注入模块对业务消息执行故障属性参数所指示的故障注入操作，包括：故障注入模块基于故障属性参数，在延迟故障属性参数指定的时长后，发送业务消息。

当故障属性参数所指示的故障注入操作为错包操作时，故障注入模块对业务消息执行故障属性参数所指示的故障注入操作，包括：故障注入模块基于故障属性参数，修改业务消息。

第二方面，提供了一种业务服务系统，业务服务系统包括：第一服务器、第二服务器和故障注入模块；第一服务器上运行的第一应用程序用于生成业务消息，业务消息用于访问第二服务器上运行的第二应用程序；故障注入模块用于获取业务消息，对业务消息执行故障属性参数所指示的故障注入操作；将执行故障注入操作后的业务消息发送至第二服务器上运行的第二应用程序。

可选的，业务服务系统还包括：地址转换模块；地址转换模块用于获取业务消息，将业务消息的目的地址修改为故障注入模块的地址，发送修改后的业务消息。

可选的，故障注入模块具体用于在业务消息符合过滤条件时，对业务消息执行故障属性参数所指示的故障注入操作。

可选的，当业务消息为业务请求时，过滤条件涉及以下一项或多项内容：请求类型、请求访问的地址、请求头关键字和请求体关键字；当业务消息为针对业务请求的响应时，过滤条件涉及以下一项或多项内容：响应状态码、响应头关键字和响应体关键字。

可选的，业务消息包括多个数据包，当故障属性参数所指示的故障注入操作为丢包操作时，故障注入模块具体用于：故障注入模块基于故障属性参数，丢弃多个数据包中的部分或全部。

可选的，当故障属性参数所指示的故障注入操作为时延操作时，故障注入模块具体用于基于故障属性参数，在延迟故障属性参数指定的时长后，发送业务消息。

可选的，当故障属性参数所指示的故障注入操作为错包操作时，故障注入模块具体用于基于故障属性参数，修改业务消息。

第三方面，提供了一种故障注入装置，该故障注入装置包括：第一监听单元和故障注入单元；第一监听单元用于获取第一应用程序生成的业务消息，业务消息用于访问第二应用程序；故障注入单元用于获取来自第一监听单元的业务消息，对业务消息执行故障属性参数所指示的故障注入操作，将执行故障注入操作后的业务消息发送至第二应用程序。

可选的，该故障注入装置还包括：过滤单元；过滤单元用于接收第一监听单元发送的业务消息，根据过滤条件对业务消息进行过滤，并将符合过滤条件的业务消息发送至故障注入单元。

可选的，该故障注入装置还包括：第二监听单元；故障注入单元具体用于将执行故障注入操作后的业务消息发送至第二监听单元；第二监听单元用于将执行故障注入操作后的业务消息发送至第二应用程序。

可选的，该故障注入装置还包括：地址转换单元；地址转换单元用于将第二监听单元待发送的业务消息的目的地址修改为第二应用程序的地址。

附图说明

图1是本申请实施例提供的一种故障注入模块的结构示意图；

图2是本申请实施例提供的一种故障注入方法所涉及的应用场景示意图；

图3是本申请实施例提供的另一种故障注入方法所涉及的应用场景示意图；

图4是本申请实施例提供的再一种故障注入方法所涉及的应用场景示意图；

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

图6是本申请实施例提供的一种管理客户端中应用程序的用户界面的示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

相关技术中，在测试云服务的实现系统的可靠性时，注入的故障主要包括：实现云服务的服务器的停机故障、实现云服务的服务器的断网故障和云服务进程的强制退出故障等全局性故障。由于该注入的故障的粒度均为服务器层面的故障，导致在注入故障后，会影响其他无关服务的功能实现并引入无关的测试，导致根据注入的故障进行可靠性测试的精确度较低。并且，在向被测云服务所依赖的云服务的实现系统注入故障时，通常需要做大量的适配工作，无法做到故障的无感知注入。

本申请实施例提供了一种故障注入方法，该故障注入方法能够提高根据注入的故障进行可靠性测试的精确度。下面先对本申请实施例提供的故障注入方法所涉及的应用场景进行说明。

该应用场景涉及第一应用程序、第二应用程序和故障注入模块。该第一应用程序和第二应用程序可以为功能实现上具有依赖关系的应用程序。也即是，第一应用程序和第二应用程序中依赖端的功能实现，依赖于第一应用程序和第二应用程序中被依赖端的功能实现。其中，两者的依赖关系可表现为：依赖端可以向被依赖端发送业务请求，被依赖端可以对该业务请求进行处理，并向依赖端发送携带有处理结果的业务响应，依赖端会基于该业务响应实现该依赖端的功能。在第一应用程序和第二应用程序的正常工作过程中，第一应用程序生成的用于访问第二应用程序的业务消息，可以从第一应用程序直接发送至第二应用程序。

而在本申请实施例中，第一应用程序生成的用于访问第二应用程序的业务消息，需要先发送至故障注入模块，在故障注入模块根据故障属性参数，对该业务消息执行该故障属性参数所指示的故障注入操作后，再将注入故障后的业务消息发送至第二应用程序。其中，该故障属性参数可以预先存储在该故障注入模块中，或者，该故障注入模块可以接收故障注入请求，该故障注入请求用于指示对业务消息注入故障，且该故障注入请求中可以携带有该故障属性参数。

在一种可实现方式中，第一应用程序可以为依赖端，第二应用程序可以为被依赖端，即业务消息可以为第一应用程序向第二应用程序发送的业务请求，此时，在业务请求的发送过程中注入故障，从第一应用程序的视角，可视为是第二应用程序出现了故障，相应的，通过对第一应用程序接收第二应用程序发送的业务响应后的反应进行分析，可以实现第二应用程序出现故障时，对第一应用程序的可靠性分析。

在另一种实现方式中，第二应用程序可以为依赖端，第一应用程序可以为被依赖端，即业务消息可以为第一应用程序向第二应用程序发送的业务响应，此时，在业务响应的发送过程中注入故障，从第二应用程序的视角，可视为是第一应用程序出现了故障，相应的，通过对该第二应用程序接收被注入了故障的业务响应后的反应进行分析，可以实现第一应用程序出现故障时，对第二应用程序的可靠性分析。

可选的，将第一应用程序生成的用于访问第二应用程序的业务消息，转发至故障注入模块的功能可以通过地址转换模块实现。例如，可以通过该地址转换模块获取第一应用程序生成的该业务消息，将该业务消息的目的地址修改为故障注入模块的地址，并发送该修改目的地址后的业务消息，以将原本需要发送至第二应用程序的业务消息发送至故障注入模块。

可选的，该故障注入模块的功能可以通过多个功能性单元实现。示例的，如图1所示，该故障注入模块可以包括：第一监听单元C01和故障注入单元C02，该第一监听单元C01用于获取第一应用程序生成的业务消息，并将该业务消息发送至故障注入单元C02。故障注入单元C02用于基于故障属性参数，对业务消息执行所该故障属性参数所指示的故障注入操作，并将注入故障后的业务消息发送至第二应用程序，以使第二应用程序对该业务消息进行处理。此时，由于是通过第一监听单元01获取第一应用程序生成的业务消息，地址转换模块将业务消息的目的地址修改为故障注入模块的地址，实质是将该业务消息的目的地址修改为该第一监听单元C01的地址。

并且，故障注入模块可以向具有特定属性的业务消息注入故障，以有针对性地进行可靠性测试。此时，可以对业务消息进行筛选，并对筛选通过的业务消息注入故障。在一种可实现方式中，该筛选业务消息的功能可以通过过滤单元C03实现。也即是，如图1所示，该多个功能性单元还可以包括：过滤单元C03，该过滤单元C03用于根据过滤条件对业务消息进行过滤，并将符合过滤条件的业务消息发送至故障注入单元C02，将不符合过滤条件的业务消息发送至第二应用程序。通过向具有特定属性的业务消息注入故障，能够避免在测试过程中引入无关的测试，实现对故障的精准注入。

进一步的，如图1所示，该多个功能性单元还可以包括：第二监听单元C04。此时，故障注入单元C02可以将注入故障后的业务消息发送至第二监听单元C04，以通过该第二监听单元C04将注入故障后的业务消息发送至第二应用程序。并且，过滤单元C03可以将不符合过滤条件的业务消息绕过故障注入单元C02发送至第二监听单元C04，以通过该第二监听单元C04将不符合过滤条件的业务消息直接发送至第二应用程序。

在一种可实现方式中，为了保证能够将注入故障后的业务消息发送至第二应用程序，如图1所示，该故障注入模块中还可以包括：地址转换模单元C05，该地址转换单元C05用于将注入故障后的业务消息的目的地址修改为第二应用程序的地址。例如，在故障注入单元C02将注入故障后的业务消息发送至第二监听单元C04后，该地址转换单元C05可以将该注入故障后的业务消息的目的地址修改为第二应用程序的地址，使得第二监听单元04根据修改后的目的地址，将该注入故障后的业务消息发送至第二应用程序。或者，在过滤单元C03将不符合过滤条件的业务消息发送至第二监听单元04后，该地址转换单元C05可以将该不符合过滤条件的业务消息的目的地址修改为第二应用程序的地址，使得第二监听单元04根据修改后的目的地址，将该不符合过滤条件的业务消息的业务消息发送至第二应用程序。

需要说明的是，上述故障注入模块的功能，可以全部或部分地通过软件、硬件或者软件和硬件的结合来实现。并且，当使用软件实现故障注入模块的功能时，该故障注入模块的功能可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机指令时，全部或部分地实现本申请实施例所述的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，例如计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如：同轴电缆、光纤、数据用户线(Digital SubscriberLine，DSL))或无线(例如：红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如：软盘、硬盘、磁带)、光介质(例如：数字通用光盘(Digital Versatile Disc，DVD))、或者半导体介质(例如：固态硬盘(Solid State Disk，SSD))等。

当使用软件实现故障注入模块的功能时，本申请实施例提供的故障注入方法所涉及的应用场景可以有多种部署方式，且应用场景的每种部署方式对应业务服务系统的一种架构。下面以以下几种为例进行说明。

如图2和图3所示，该应用场景包括：第一服务器110和第二服务器120。第一服务器110和第二服务器120均可以是一台服务器，或者由若干台服务器组成的服务器集群，或者是一个云计算服务中心。第一服务器110和第二服务器120之间可以通过有线网络或无线网络连接。

并且，如图2和图3所示，第一服务器110包括第一处理器1101，第一通信接口1102和第一存储器1103。第一处理器1101、第一通信接口1102和第一存储器1103之间通过第一总线1104相互连接。第二服务器120包括第二处理器1201，第二通信接口1202和第二存储器1203。第二处理器1201、第二通信接口1202和第二存储器1203之间通过第二总线1204相互连接。其中，第一存储器1103和第二存储器1203均用于存储计算机程序，且该计算机程序可以是应用程序，第一处理器1101调用第一存储器1103中的应用程序时，能够实现该应用程序的功能，第二处理器1201调用第二存储器1203中的应用程序时，能够实现该应用程序的功能。

在图2所示的应用场景中，第一服务器110中可以运行有第一应用程序、地址转换模块和故障注入模块，第二服务器120中可以运行有第二应用程序。此时，如图2所示，第一存储器1103中可以存储有第一应用程序1103a、地址转换模块1103b和故障注入模块1103c，第二存储器1203中可以存储有第二应用程序1203a。

在图3所示的应用场景中，第一服务器110中可以运行有第一应用程序和地址转换模块，第二服务器120中可以运行有第二应用程序和故障注入模块。此时，如图3所示，第一存储器1103中可以存储有第一应用程序1103a和地址转换模块1103b，第二存储器1203中可以存储有第二应用程序1203a和故障注入模块1203b。

图4是本申请实施例提供的另一种故障注入方法所涉及的应用场景示意图。如图4所示，该应用场景中包括：第一服务器110、第二服务器120和第三服务器130。第一服务器110、第二服务器120和第三服务器130均可以是一台服务器，或者由若干台服务器组成的服务器集群，或者是一个云计算服务中心。第一服务器110和第二服务器120之间、第一服务器110和第三服务器130之间、及第二服务器120和第三服务器130之间均可以通过有线网络或无线网络连接。

并且，如图4所示，第一服务器110包括第一处理器1101，第一通信接口1102和第一存储器1103。第一处理器1101、第一通信接口1102和第一存储器1103之间通过第一总线1104相互连接。第二服务器120包括第二处理器1201，第二通信接口1202和第二存储器1203。第二处理器1201、第二通信接口1202和第二存储器1203之间通过第二总线1204相互连接，第三服务器130包括第三处理器1301，第三通信接口1302和第三存储器1303。第三处理器1301、第三通信接口1302和第三存储器1303之间通过第三总线1304相互连接。第一存储器1103、第二存储器1203和第三存储器1303均用于存储计算机程序，且该计算机程序可以是应用程序，某一服务器中的处理器调用该服务器的存储器中的应用程序时，能够实现该应用程序的功能。

在该图4所示的应用场景中，第一服务器110中可以运行有第一应用程序和地址转换模块，第二服务器120中可以运行有第二应用程序，第三服务器130中可以运行有故障注入模块。此时，如图4所示，第一存储器1103中可以存储有第一应用程序1103a和地址转换模块1103b，第二存储器1203中存储有第二应用程序1203a，第三存储器1303中存储有故障注入模块1303a。

当使用硬件实现故障注入模块的功能时，本申请实施例提供的故障注入方法所涉及的应用场景可以包括：第一服务器、第二服务器和故障注入模块。该第一服务器和第二服务器均可以是一台服务器，或者由若干台服务器组成的服务器集群，或者是一个云计算服务中心。第一服务器和第二服务器之间、第一服务器和故障注入模块之间、及故障注入模块和第二服务器之间可以通过有线网络或无线网络连接。且在该应用场景中，第一应用程序在第一服务器中的部署情况，第二应用程序在第二服务器中的部署情况，请相应参考图3的部署情况，此处不再赘述。

需要说明的是，当第一应用程序与地址转换模块均部署在第一服务器110中时，该地址转换模块可以集成在该第一应用程序中。例如，该地址转换模块可以为第一应用程序中的小程序，当接收到故障注入请求时，该地址转换模块可以获取该第一应用程序生成的用于访问第二应用程序的业务消息，并将该业务消息的目的地址修改为故障注入模块的地址，以便于故障注入模块能够获取该业务消息。

或者，当第一应用程序与地址转换模块均部署在第一服务器110中时，该地址转换模块和该第一应用程序可以独立部署在该第一服务器110中，例如，上述图2至图4均是第一应用程序与地址转换模块独立部署的示例性说明。当地址转换模块与第一应用程序独立部署时，从第一应用程序的视角，在该第一应用程序生成用于访问第二应用程序的业务消息后，由于第一应用程序发送业务消息的流程与不进行可靠性测试时的业务消息发送流程相同，使得在测试过程中无需对第一应用程序进行更改，能够解决相关技术中需要做大量的适配工作才能进行测试的问题，实现了故障的无感知注入。

在图2至图4中，第一总线1104、第二总线1204和第三总线1304中的任一总线可以分为地址总线、数据总线、控制总线等。为便于表示，图2至图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

在图2至图4中，第一处理器1101、第二处理器1201和第三处理器1301中的任一处理器可以是硬件芯片，该硬件芯片可以是专用集成电路(application-specificintegrated circuit，ASIC)，可编程逻辑器件(programmable logic device，PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complex programmable logic device，CPLD)，现场可编程逻辑门阵列(field-programmable gate array，FPGA)，通用阵列逻辑(genericarray logic,GAL)或其任意组合。或者，也可以是通用处理器，例如，中央处理器(centralprocessing unit，CPU)，网络处理器(network processor，NP)或者CPU和NP的组合。

在图2至图4中，第一存储器1103、第二存储器1203和第三存储器1303中的任一存储器可以包括易失性存储器(volatile memory)，例如随机存取存储器(random-accessmemory，RAM)；也可以包括非易失性存储器(non-volatile memory)，例如快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)；还可以包括上述种类的存储器的组合。

下面以图2所示的部署情况，且故障注入模块的多个功能性单元包括：第一监听单元、故障注入单元、过滤单元、第二监听单元和地址转换单元为例，对本申请实施例提供的故障注入方法的实现过程进行说明。当第一应用程序、第二应用程序、地址转换模块和故障注入模块按照其他情况进行部署时，该故障注入方法的实现过程，请相应参考下述步骤501至步骤507的实现过程。如图5所示，该方法包括：

步骤501、第一监听单元接收故障注入请求，并基于该故障注入请求向地址转换模块发送地址转换请求。

其中，地址转换请求用于请求将第一应用程序生成的用于访问第二应用程序的业务消息的目的地址修改为第一监听单元的地址。该故障注入请求用于请求在第一应用程序向第二应用程序发送业务消息的过程中注入故障。且故障注入请求中可以携带有故障属性参数，该故障属性参数用于指示需要注入的故障。此时，第一监听单元接收该故障注入请求后，还需要将该故障属性参数发送至故障注入单元。或者，该故障属性参数也可以预先存储在故障注入单元中，本申请实施例对其不做具体限定。

并且，该故障注入请求是发送至故障注入模块的，且该故障注入请求可以由该故障注入模块中的任一功能性单元接收，例如，可以由第一监听单元接收，或由过滤单元接收，或由故障注入单元接收，或由第二监听模块接收。该图5是由第一监听单元接收该故障注入请求的示例。

在需要对应用程序的实现系统进行可靠性分析时，可以在管理客户端上触发故障注入请求，以请求对待分析可靠性的实现系统注入故障。例如，测试人员可以在管理客户端中提交注入故障的任务，以触发该故障注入请求。或者，可以通过调用软件开发工具包(software development kit，SDK)的方式，触发该故障注入请求。且在管理客户端中提交注入故障的任务，可以在管理客户端中应用程序的用户界面中操作，也可以在管理客户端中浏览器的用户界面中操作。

其中，该故障属性参数可以在管理客户端的用户界面中输入。可选的，该故障属性参数可以包括：注入故障的故障标识。示例的，第一服务器中可以存储有用于注入不同故障的程序指令，第一服务器在接收到携带有故障标识的故障注入请求后，可以根据该故障标识调用该故障标识指示的故障的程序指令，并通过运行调用的程序指令，以实现该故障标识所指示的故障注入。

在一种可实现方式中，该故障属性参数还可以包括以下一个或多个：故障的发生几率和故障的持续时长。通过设置故障的持续时长，能够有效控制故障注入的时长，使得能够在指定时间段内模拟出第一应用程序和第二应用程序中被依赖端出现故障的状态。当故障属性参数包括故障的发生几率时，通过按照该故障属性参数注入故障，可以控制故障按照该发生几率随机地出现故障，以模拟出该被依赖端处于亚健康状态的情况，实现在被依赖端处于亚健康状态时对依赖端的可靠性测试。其中，被依赖端处于亚健康状态是指被依赖端能够提供概率性失败的服务的状态。例如，假设被依赖端为第二应用程序，当注入故障为丢包故障时，若故障的发生几率为100％(即丢包率为100％)，则可以模拟出第二应用程序接收到数据包即丢弃的故障状态，若故障的发生几率为50％(即丢包率为50％)，则可以模拟出第二应用程序按照50％的概率随机丢弃接收到的数据包的亚健康状态。

在另一种可实现方式中，可以有针对性地注入故障，此时，该故障属性参数还可以包括以下一个或多个：注入故障的端口号和Ip，及对业务消息进行过滤的过滤条件。当向业务消息进行故障注入时，注入故障的端口号和Ip为第二应用程序用于接收业务消息的端口的端口号和Ip。此时，通过按照该故障属性参数注入故障，可以模拟出该端口出现故障的情况。通过设置对业务消息进行过滤的过滤条件，能够对具有特定属性的业务消息注入故障，使得可以对业请求有针对性地注入故障，能够避免在测试过程中引入无关的测试以及对其他无需测试的服务造成影响，实现对故障的精准注入。需要说明的是，当故障注入请求中携带有过滤条件时，在第一监听单元接收到该故障注入请求后，还需要将该过滤条件发送至过滤单元。

示例的，图6为本申请实施例提供的一种管理客户端中应用程序的用户界面的示意图，测试人员可以在该用户界面中输入故障属性参数，并在参数输入完成后点击用户界面中的“立即注入”按钮，以触发故障注入请求。其中，图6所示的用户界面中需要输入的故障属性参数包括：测试环境的环境名称，用于部署测试环境的环境节点的名称，运行有第一应用程序的待测服务器的互联网协议地址(internet protocol address，IP)，测试环境中的网络数据交换规则(protocol)，业务所依赖的服务器的Ip和端口号(server_address)，注入故障的类型(drop_type，也称注入故障的故障标识)，故障的发生几率(drop_rate)，故障的持续时长(timeout)，及对业务消息进行过滤的过滤条件(filter_keyword_content)。

该图6为注入故障为丢包故障的用户界面图，如图6所示，该丢包故障的环境名称为：ECS_cui，环境节点的名称为：Apigateway_001，待测服务器的IP为：172.168.200.41，网络数据交换规则为：超文本传输安全协议(hypertext transfer protocol secure，https)，业务所依赖的服务器的Ip和端口号为：172.168.200.42：8080，注入故障的故障标识为：req_drop(该标识用于表示注入故障为丢包故障)，故障的发生几率(即丢包率)为：100％，故障的持续时长为：3600秒，对业务消息进行过滤的过滤条件为：all(全部)，该all表示对所有业务消息均进行过滤，即对所有业务消息进行故障注入。

步骤502、第一应用程序生成用于访问第二应用程序的业务消息。

用户在需要第一应用程序提供业务服务(例如云服务)时，可以通过客户端向第一应用程序发送业务请求指令，第一应用程序在接收到该业务请求指令后，可以生成对应的业务消息(此时也称业务请求)。且由于该第一应用程序的功能实现依赖于第二应用程序的功能实现，因此，第一应用程序可以生成用于访问第二应用程序的业务请求，以便于请求第二应用程序向该第一应用程序提供对应的服务，使得第一应用程序根据其向客户端提供该业务请求指令所指示的服务。或者，用户在需要第二应用程序提供业务服务(例如云服务)时，可以通过客户端向第二应用程序发送业务请求指令，第二应用程序在接收到该业务请求指令后，可以生成对应的业务请求，在第二应用程序向第一应用程度发送业务请求后，第一应用程序可以基于该业务请求生成用于访问第二应用程序业务消息(此时也称业务响应)，以便于第二应用程序根据该业务响应向客户端提供该业务请求指令所指示的服务。

步骤503、地址转换模块获取业务消息，基于地址转换请求，将业务消息的目的地址修改为第一监听单元的地址，发送修改后的业务消息。

地址转换模块接收到地址转换请求后，可以监听第一应用程是否生成了用于访问第二应用程序的业务消息，并在监听到第一应用程序生成了用于访问第二应用程序的业务消息时，获取该业务消息，并将该业务消息的目的地址修改为第一监听单元的地址，并将修改目的地址后的业务消息发送至第一监听单元。

示例的，假设第一应用程序的端口号和IP为：172.168.200.41：4000，第一监听单元的端口号和IP为：172.168.200.41:5000，第二监听单元的端口号和IP为：1.2.3.4:8080，第二应用程序的端口号和IP为：172.168.200.42:8080，第一应用程序生成的业务请求为：http://172.168.200.42:8080/v1/xxxx，在不需要进行故障注入时，该第一应用程序生成的用于访问第二应用程序的业务消息的发送端地址为172.168.200.41：4000，该业务消息的目的地址为172.168.200.42:8080，在第一应用程序发出该业务消息后，网络中的路由器等设备会根据该业务消息的目的地址，将该业务消息发送至第二应用程序。

当需要进行故障注入时，地址转换模块可以将业务消息的目的地址修改为第一监听单元的地址，使得该业务消息的目的地址变为172.168.200.41:5000，即将业务消息的目的地址由172.168.200.42:8080修改为172.168.200.41:5000，此时，地址转换模块发出该修改目的地址的业务消息后，网络中的网关等设备会根据修改后的目的地址，将该业务消息发送至第一监听单元。因此，通过修改业务消息的目的地址，故障注入模块可以拦截预计发送至第二应用程序的业务消息，并在对该业务消息注入故障后，将注入故障后的业务消息发送至第二应用程序。

其中，可以通过iptables命令(一种程序指令)修改业务消息的目的地址，例如，将业务消息的目的地址由172.168.200.42:8080修改为172.168.200.41:5000的命令可以为：iptables–t nat–A OUTPUT–d 172.168.200.42–p tcp–m tcp–dport 8080–j DNAT–to_destination172.168.200.41:5000。

需要说明的是，在需要停止注入故障时，可以通过控制地址装换模块停止工作，以便于第一应用程序能够直接发出用于访问第二应用程序的业务消息，以使第一应用程序和第二应用程序按照原有的方式工作，使得业务恢复正常。

步骤504、第一监听单元接收修改目的地址后的业务消息，向过滤单元发送修改后的业务消息。

步骤505、过滤单元根据过滤条件，对业务消息进行过滤，并在业务消息符合过滤条件时，将业务消息发送至故障注入单元。

在进行可靠性测试时，可以有针对性的进行测试，此时，可以通过向具有特定属性的业务消息注入故障，然后根据注入故障后的业务消息完成可靠性测试。该向具有特定属性的业务消息注入故障的实现方式可以为：使用过滤单元根据过滤条件，对故障注入单元获取的业务消息进行过滤，并在业务消息符合过滤条件时，将业务消息发送至故障注入单元，并通过故障注入单元对业务消息注入故障。这样能够避免在测试过程中引入无关的测试，实现对故障的精准注入。

其中，过滤条件可以根据实际需要进行设置。例如，当业务消息为业务请求时，该过滤条件可以涉及以下一项或多项内容：请求类型、请求访问的地址、请求头关键字和请求体关键字。当业务消息为针对业务请求的响应时，该过滤条件可以涉及以下一项或多项内容：响应状态码、响应头关键字和响应体关键字。

示例的，请求类型可以包括：向接收端发送更改信息的请求(即POST请求)，请求查询数据的请求(即GET请求)，请求页面的首部的请求(即HEAD请求)，允许客户端查看服务器的性能的请求(即OPTIONS请求)，及从客户端向服务器传送的数据取代指定的文档的内容的请求(即PUT请求)等请求类型。请求访问的地址可以使用统一资源标识符(uniformresource identifier，URI)表示，例如，请求访问的地址可以为/v1/createVM。请求头关键字可以为请求内容的类型(content-Type)。请求体关键字可以为请求成功(success)。响应头关键字可以为响应内容的类型(content-Type)。响应体关键字可以为响应成功(success)。响应状态码可以为200、404或500等，该响应状态码200表示请求成功，响应状态码404表示请求资源不存在，响应状态码500表示服务器发生不可预期的错误。

需要说明的是，在图2所示的应用场景中，若过滤单元确定业务消息不符合过滤条件，则可将业务消息发送至第二监听单元，以通过该第二监听单元将该业务消息发送至第二应用程序。在图3或图4所示的应用场景中，当未设置第二监听单元时，若过滤单元确定业务消息不符合过滤条件，则可将业务消息直接发送至第二应用程序。

步骤506、故障注入单元对业务请求执行故障属性参数所指示的故障注入操作，并将执行故障注入操作后的业务消息发送至第二监听单元。

对业务请求注入的故障可以为网络类故障，例如：丢包故障、时延故障和错包故障等。丢包故障是指在发送业务消息的过程中，出现了用于携带该业务消息的数据包被丢弃的情况。也即是，故障注入单元对业务请求注入丢包故障是指：当业务请求包括一个数据包时，故障注入单元根据故障属性参数丢弃该一个数据包，当业务请求包括多个数据包时，故障注入单元根据故障属性参数丢弃该多个数据包中的全部或部分数据包。时延故障是指在发送业务消息的过程中，出现了用于携带该业务消息的数据包被延迟转发的情况。也即是，故障注入单元对业务请求注入时延故障是指：故障注入单元在延迟故障属性参数指定时长后，发送业务消息的数据包。错包故障是指在发送业务消息的过程中，出现了用于携带该业务消息的数据包的内容被修改的情况，例如，出现了数据包中的报文头、报文体和状态码中的一个或多个被修改的情况。也即是，故障注入单元对业务请求注入错包故障是指：故障注入单元根据故障属性参数，修改业务消息。

并且，该注入的故障也可以为系统资源类故障、节点类故障、数据库类故障和容器类故障等类型的故障。示例的，该系统资源类故障可以包括：中央处理器(centralprocessing unit，CPU)升压故障、内存泄露故障、硬盘故障、网络故障、进程异常退出故障、文件异常故障、文件系统故障和系统管理故障等。该节点类故障可以包括：节点异常关机故障和节点异常重启故障等。在本申请实施例中，注入的故障不限于上述描述的故障，还可以为其他故障，即注入的故障是可扩展的。可以通过预先编写注入故障的程序指令，并将该程序指令存储在存储介质中，当需要注入故障时，可以通过本申请实施例提供的故障注入方法确定待注入的故障，并执行用于注入对应故障的程序指令，以实现对应故障的注入。

需要说明的是，当故障注入模块包括第二监听单元时，故障注入单元向业务消息注入故障后，可以将注入故障后的业务消息发送至第二监听单元，以通过第二监听单元将注入故障后的业务消息发送至第二应用程序。当故障注入模块不包括第二监听单元时，故障注入单元向业务消息注入故障后，可以将注入故障后的业务消息直接发送至第二应用程序，即可以不执行步骤507。

并且，在第二监听单元将该注入故障后的业务消息发送至第二应用程序之前，还可以通过故障注入模块中的地址转换单元，将第二监听单元待发送的业务消息的目的地址，修改为第二应用程序的地址。例如，仍以步骤503中的示例为例，地址转换单元可以将该业务消息的目的地址由1.2.3.4:8080修改为172.168.200.42:8080。其中，将业务消息的目的地址由1.2.3.4:8080修改为172.168.200.42:8080的命令可以为：iptables–t nat–AOUTPUT–d 1.2.3.4–p tcp–m tcp–dport 8080–j DNAT–to_destination 172.168.200.42:8080。

还需要说明的是，由于在设置故障属性参数时，可以设置注入故障后的业务消息的接收端为第二应用程序，使得用于将注入故障后业务消息发送至第二应用程序的功能性单元可以根据该故障属性参数，获取注入故障后的业务消息的接收端，因此，该故障注入模块也可以不包括地址转换单元。

还需要说明的是，当向业务消息注入的故障为丢包率为100％的丢包故障时，就无需将业务消息再发送至第二应用程序。

步骤507、第二监听单元向第二应用程序发送注入故障后的业务消息，使第二应用程序对注入故障后的业务消息进行处理。

当该业务消息为业务请求时，第二应用程序接收到注入故障后的业务请求后，会根据其提供业务服务，并根据提供业务服务的结果向第一应用程序发送业务响应，第一应用程序接收到该业务响应后会做出反应。此时，相当于模拟出了第二应该程序出现故障的情况，通过对第一应用程序接收到业务响应后的反应进行分析，可以实现对第一应用程序在第二应用程序出现故障时的可靠性进行分析。

当该业务消息为业务响应时，第二应用程序在接收到注入故障后的业务响应后会做出反应。此时，相当于模拟出了第一应该程序出现故障的情况，通过对第二应用程序接收到业务响应后的反应进行分析，可以实现对第二应用程序在第一应用程序出现故障时的可靠性进行分析。

综上所述，在本申请实施例提供的故障注入方法中，在第一应用程序生成用于访问第二应用程序的业务消息后，通过故障注入模块获取该业务消息，对业务消息执行故障属性参数所指示的故障注入操作，并向第二应用程序发送执行故障注入操作后的业务消息，能够在业务消息的发送过程中对业务消息注入故障，相较于相关技术中的全局性故障，细化了注入故障的粒度，有效的提高了根据注入的故障进行可靠性测试的精确度。

并且，由于是在业务消息的发送过程中，通过拦截业务消息实现注入故障的，使得无需对注入故障的对象做适配工作，可以做到故障的无感知注入。

同时，通过使用过滤条件对业务消息进行过滤，并在业务消息符合过滤条件时，对业务消息注入故障，使得可以对业务消息有针对性地注入故障，能够避免在测试过程中引入无关的测试以及对其他无需测试的服务造成影响，实现对故障的精准注入。

本申请实施例提供的故障注入方法的步骤先后顺序可以进行适当调整，步骤也可以根据情况进行相应增减，例如，可以根据情况选择是否执行步骤507。任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化的方法，都应涵盖在本申请的保护范围之内，因此不再赘述。

本申请实施例还提供了一种故障注入装置，该故障注入装置可以部署在服务器或计算机设备上。该故障注入装置可以包括本申请实施例提供的故障注入模块。例如，该故障注入装置可以包括：第一监听单元和故障注入单元；所述第一监听单元用于获取第一应用程序生成的业务消息，所述业务消息用于访问第二应用程序；所述故障注入单元用于获取来自所述第一监听单元的所述业务消息，对所述业务消息执行故障属性参数所指示的故障注入操作，将执行故障注入操作后的业务消息发送至所述第二应用程序。

可选的，该故障注入装置还可以包括：过滤单元；所述过滤单元用于接收所述第一监听单元发送的所述业务消息，根据过滤条件对所述业务消息进行过滤，并将符合过滤条件的业务消息发送至故障注入单元。

可选的，该故障注入装置还可以包括：第二监听单元；此时，所述故障注入单元具体用于将执行故障注入操作后的业务消息发送至所述第二监听单元；所述第二监听单元用于将执行故障注入操作后的业务消息发送至所述第二应用程序。

可选的，该故障注入装置还可以包括：地址转换单元；所述地址转换单元用于将所述第二监听单元待发送的业务消息的目的地址修改为所述第二应用程序的地址。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，该故障注入装置中各单元的具体工作过程，可以参考前述系统实施例中的对应单元的描述，在此不再赘述。

本申请实施例还提供了一种存储介质，该存储介质为非易失性计算机可读存储介质，当存储介质中的指令被处理器执行时，实现如本申请实施例中故障注入模块或地址转换模块所实现的功能。

本申请实施例还提供了一种包含指令的计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行本申请实施例中故障注入模块或地址转换模块所实现的功能。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本申请实施例中，术语“第一”、“第二”和“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。术语“至少一个”是指一个或多个，术语“多个”指两个或两个以上，除非另有明确的限定。

本申请中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的构思和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (18)

1.一种故障注入方法，其特征在于，所述故障注入方法应用于业务服务系统，所述业务服务系统中运行有第一应用程序、第二应用程序和故障注入模块，所述方法包括：

所述第一应用程序生成业务消息，所述业务消息用于访问所述第二应用程序；

所述故障注入模块获取所述业务消息，对所述业务消息执行故障属性参数所指示的故障注入操作；

所述故障注入模块将执行故障注入操作后的业务消息发送至所述第二应用程序。

2.根据权利要求1所述的方法，其特征在于，所述业务服务系统中还运行有地址转换模块，在所述故障注入模块获取所述业务消息之前，所述方法还包括：

所述地址转换模块获取所述业务消息，将所述业务消息的目的地址修改为所述故障注入模块的地址，发送修改后的所述业务消息。

3.根据权利要求1或2所述的方法，其特征在于，所述故障注入模块对所述业务消息执行故障属性参数所指示的故障注入操作，包括：

所述故障注入模块在所述业务消息符合过滤条件时，对所述业务消息执行所述故障属性参数所指示的故障注入操作。

4.根据权利要求1至3任一所述的方法，其特征在于，当所述业务消息为业务请求时，所述过滤条件涉及以下一项或多项内容：请求类型、请求访问的地址、请求头关键字和请求体关键字；

当所述业务消息为针对业务请求的响应时，所述过滤条件涉及以下一项或多项内容：响应状态码、响应头关键字和响应体关键字。

5.根据权利要求1至4任一所述的方法，其特征在于，所述业务消息包括多个数据包，当所述故障属性参数所指示的故障注入操作为丢包操作时，所述故障注入模块对所述业务消息执行所述故障属性参数所指示的故障注入操作，包括：

所述故障注入模块基于所述故障属性参数，丢弃所述多个数据包的部分或全部。

6.根据权利要求1至5任一所述的方法，其特征在于，当所述故障属性参数所指示的故障注入操作为时延操作时，所述故障注入模块对所述业务消息执行故障属性参数所指示的故障注入操作，包括：

所述故障注入模块基于所述故障属性参数，在延迟所述故障属性参数指定的时长后，发送所述业务消息。

7.根据权利要求1至6任一所述的方法，其特征在于，当所述故障属性参数所指示的故障注入操作为错包操作时，所述故障注入模块对所述业务消息执行故障属性参数所指示的故障注入操作，包括：

所述故障注入模块基于所述故障属性参数，修改所述业务消息。

8.一种业务服务系统，其特征在于，所述业务服务系统包括：第一服务器、第二服务器和故障注入模块；

所述第一服务器上运行的第一应用程序用于生成业务消息，所述业务消息用于访问所述第二服务器上运行的第二应用程序；

所述故障注入模块用于获取所述业务消息，对所述业务消息执行故障属性参数所指示的故障注入操作；将执行故障注入操作后的业务消息发送至所述第二服务器上运行的第二应用程序。

9.根据权利要求8所述的系统，其特征在于，所述业务服务系统还包括：地址转换模块；

所述地址转换模块用于获取所述业务消息，将所述业务消息的目的地址修改为所述故障注入模块的地址，发送修改后的所述业务消息。

10.根据权利要求8或9所述的系统，其特征在于，

所述故障注入模块具体用于在所述业务消息符合过滤条件时，对所述业务消息执行所述故障属性参数所指示的故障注入操作。

11.根据权利要求8至10任一所述的系统，其特征在于，当所述业务消息为业务请求时，所述过滤条件涉及以下一项或多项内容：请求类型、请求访问的地址、请求头关键字和请求体关键字；

当所述业务消息为针对业务请求的响应时，所述过滤条件涉及以下一项或多项内容：响应状态码、响应头关键字和响应体关键字。

12.根据权利要求8至11任一所述的系统，其特征在于，所述业务消息包括多个数据包，当所述故障属性参数所指示的故障注入操作为丢包操作时，所述故障注入模块具体用于：所述故障注入模块基于所述故障属性参数，丢弃所述多个数据包中的部分或全部。

13.根据权利要求8至12任一所述的系统，其特征在于，当所述故障属性参数所指示的故障注入操作为时延操作时，所述故障注入模块具体用于基于所述故障属性参数，在延迟所述故障属性参数指定的时长后，发送所述业务消息。

14.根据权利要求8至13任一所述的系统，其特征在于，当所述故障属性参数所指示的故障注入操作为错包操作时，所述故障注入模块具体用于基于所述故障属性参数，修改所述业务消息。

15.一种故障注入装置，其特征在于，所述装置包括：第一监听单元和故障注入单元；

所述第一监听单元用于获取第一应用程序生成的业务消息，所述业务消息用于访问第二应用程序；

所述故障注入单元用于获取来自所述第一监听单元的所述业务消息，对所述业务消息执行故障属性参数所指示的故障注入操作，将执行故障注入操作后的业务消息发送至所述第二应用程序。

16.根据权利要求15所述的装置，其特征在于，所述装置还包括：过滤单元；

所述过滤单元用于接收所述第一监听单元发送的所述业务消息，根据过滤条件对所述业务消息进行过滤，并将符合所述过滤条件的业务消息发送至故障注入单元。

17.根据权利要求15或16所述的装置，其特征在于，所述装置还包括：第二监听单元；

所述故障注入单元具体用于将执行故障注入操作后的业务消息发送至所述第二监听单元；

所述第二监听单元用于将执行故障注入操作后的业务消息发送至所述第二应用程序。

18.根据权利要求15至17任一所述的装置，其特征在于，所述装置还包括：地址转换单元；

所述地址转换单元用于将所述第二监听单元待发送的业务消息的目的地址修改为所述第二应用程序的地址。

Images