CN116827838A - 基于自动依赖发现和代理的微服务混沌测试方法及系统 - Google Patents

Abstract

本发明涉及一种基于自动依赖发现和代理的微服务混沌测试方法及系统，其方法包括：S1：基于涉及微服务的工作负载和服务，创建微服务混沌测试计划；S2：根据微服务混沌测试计划创建子任务，在执行子任务过程中根据枚举到的故障和下游响应组合注入故障和设置响应，通过上游代理发出测试请求，通过下游代理和域名解析记录发现不可代理下游、依赖的外部服务和依赖缺失，通过下游代理返回设置的响应，通过上游代理记录测试请求结果，合并测试结果相同的故障和下游响应组合，跳过不必要的故障和下游响应组合；S3：检查和生成最终的测试结果。本发明提供的方法将混沌测试过程自动化，并提高测试运行效率和覆盖率，从而发现潜在系统混沌缺陷。

Description

基于自动依赖发现和代理的微服务混沌测试方法及系统

技术领域

本发明涉及云原生技术领域，具体涉及一种基于自动依赖发现和代理的微服务混沌测试方法及系统。

背景技术

微服务架构适用于构建大型Web应用程序，由多个团队用多种编程语言编写的微服务组成微服务系统，从而支持快速发布大规模软件系统。相比于传统单体架构，微服务架构在可伸缩性、可用性、经济效益等方面具有优势。然而，微服务架构要求开发人员处理系统部分故障，即避免或缓解因一个或多个微服务不可用或运行状态不良，对系统对外提供服务产生的不利影响。因此，测试微服务系统不仅需要验证代码逻辑的正确性，还需要验证系统处理部分故障的能力。

Kubernetes(以下简称为k8s)是用于自动部署、扩展和管理容器化应用程序的开源系统。在k8s系统中，k8s对象是持久化的实体，k8s使用这些实体去表示整个集群的状态。实际生产环境中，在k8s系统中部署的微服务一般由k8s对象Service和与其一一对应的作为Service请求转发目标的“工作负载”组成。但本专利测试过程中，通过修改Service将被测微服务对下游的请求有策略地路由到不同目标，因此不必然一一对应。本发明中涉及的工作负载种类包括k8s对象Deployment、StatefulSet或单独的Pod，其中每个Deployment管理不作区分的一个或多个Pod，每个StatefulSet管理有序号作区分的一个或多个Pod，每个Pod包含紧耦合的一个或多个容器，每个容器基于一个镜像。

混沌工程最初是将故障随机注入到生产环境中，从最终用户的角度识别不符合预期的行为。随机注入故障存在重复和遗漏，执行效率不高，不能充分地覆盖测试空间。在生产环境中注入故障，将在按预期导致服务降级或发现处理部分故障问题的同时影响真实用户，不适合失败成本高的场景。

进行充分的混沌测试需要确定和部署测试请求涉及的所有微服务，多次对微服务注入各种故障组合后发出测试请求，检查系统部分故障时的行为是否符合预期。若手动进行以上操作，不但要求测试人员了解每个测试用例涉及的微服务，而且需要大量人力和时间。

现有的微服务混沌测试工具有：

混沌工程平台：以ChaosMesh为代表，支持在k8s环境中注入故障，但每次故障注入都需要人工指定注入目标和配置故障参数，注入后需要人工另行发出测试请求，并人工检查故障注入效果是否符合预期。

HTTP层故障注入工具：以Filibuster为代表，支持发出测试请求后，对引发的下游请求和响应在网络层注入事先配置的故障，并通过请求追踪自动探测微服务间的依赖关系，生成需要注入的故障组合，避免注入不必要的故障组合，自动检查测试结果是否符合人工配置的预期，但请求追踪和故障注入需要修改被测微服务源代码。

随机故障注入工具：以ChaosMonkey为代表，支持在生产环境中定期随机注入崩溃故障，但测试发现问题的同时会影响真实用户，且难以衡量测试进度。

发明内容

为了解决上述技术问题，本发明提供一种基于自动依赖发现和代理的微服务混沌测试方法及系统。

本发明技术解决方案为：一种基于自动依赖发现和代理的微服务混沌测试方法，包括：

步骤S1：基于涉及微服务的工作负载和服务，创建微服务混沌测试计划；

步骤S2：根据所述微服务混沌测试计划创建子任务，在执行所述子任务过程中根据枚举到的故障和下游响应组合注入故障和设置响应，通过上游代理发出测试请求，通过下游代理和域名解析记录发现不可代理下游、依赖的外部服务和依赖缺失，通过所述下游代理返回设置的响应，通过所述上游代理记录测试请求结果，合并测试结果相同的故障和下游响应组合，跳过不必要的故障和下游响应组合；

步骤S3：检查和生成最终的测试结果。

本发明与现有技术相比，具有以下优点：

1、降低人工成本：本发明公开了一种基于自动依赖发现和代理的微服务混沌测试方法，通过基于已有的用于在生产环境部署微服务系统的k8s对象定义，在同样为k8s的环境中执行测试，无需另行定义如何部署微服务。从k8s对象定义和执行过程中记录的信息，分析所需注入的故障种类和参数，绝大多数种类的故障无需人工定义。通过引入代理追踪测试请求引发的下游请求，对于不包含请求追踪的微服务，可以直接使用与生产环境相同的微服务镜像，无需通过修改源代码引入请求追踪。支持自动发现依赖的外部服务，无需人工配置。

2、执行速度快：本发明通过引入代理追踪测试请求引发的下游请求，相比较于传统的分布式请求追踪，执行相同测试过程中产生的请求总数更少，因此执行速度快。本发明通过并行执行测试，减少串行测试时已部署微服务的闲置，可使测试耗时显著减少，特别是当测试环境资源充裕且测试用例多于微服务数量时。此外，本发明通过多种策略，一次性合并处理导致相同响应的不同故障组合，避免注入不必要的故障组合，减少需要实际注入的故障组合数量和测试请求的执行次数，可使测试耗时显著减少。

3、测试覆盖全面：相较于随机注入故障，本发明测试覆盖更全面，测试进度可以衡量。相较于仅在HTTP层注入故障，本发明方法在测试中更能准确的反应发生更底层故障时微服务的表现，特别是当不同底层故障可能导致相同HTTP层表现，或HTTP层表现难以事先人工获知和设置时。同时，本发明支持对依赖的外部服务注入部分种类的故障。

4、节省系统资源：本发明只按需部署测试请求实际涉及微服务的工作负载，只占用必要的系统资源，特别是当测试请求实际涉及的微服务不确定，且占涉及微服务的比例低时，显著节省系统资源。对于每个请求，仅首次由实际被测微服务工作负载处理和返回响应，之后被代理记录由代理返回，特别是处理测试请求消耗系统资源多时，可以显著节省系统资源。

附图说明

图1为本发明实施例中一种基于自动依赖发现和代理的微服务混沌测试方法的流程图；

图2为本发明实施例中测试请求和引发的下游请求示意图；

图3为本发明实施例中基于自动依赖发现和代理的微服务混沌测试的流程图；

图4为本发明实施例中一种基于自动依赖发现和代理的微服务混沌测试系统的结构框图。

具体实施方式

本发明提供了一种基于自动依赖发现和代理的微服务混沌测试方法，将混沌测试过程自动化，并提高测试运行效率和覆盖率，从而发现潜在系统混沌缺陷。

为了使本发明的目的、技术方案及优点更加清楚，以下通过具体实施，并结合附图，对本发明进一步详细说明。

为了更好地理解本发明，对代理进行解释：本发明中代理是指测试计划执行容器(以下简称为执行容器)提供的一种功能，指使用事先手动设置或自动记录的值代替微服务进行请求或响应。其中：上游代理代替原微服务系统中的上游微服务，向被测微服务发出请求以获取响应；下游代理代替原微服务系统中下游微服务，从被测微服务接收请求并返回响应。

实施例一

如图1所示，本发明实施例提供的一种基于自动依赖发现和代理的微服务混沌测试方法，包括下述步骤：

步骤S1：基于涉及微服务的工作负载和服务，创建微服务混沌测试计划；

步骤S2：根据微服务混沌测试计划创建子任务，在执行子任务过程中根据枚举到的故障和下游响应组合注入故障和设置响应，通过上游代理发出测试请求，通过下游代理和域名解析记录发现不可代理下游、依赖的外部服务和依赖缺失，通过下游代理返回设置的响应，通过上游代理记录测试请求结果，合并测试结果相同的故障和下游响应组合，跳过不必要的故障和下游响应组合；

步骤S3：检查和生成最终的测试结果。

在一个实施例中，上述步骤S1：基于涉及微服务的工作负载和服务，创建微服务混沌测试计划，具体包括：

步骤S11：从用户提交的定义文件和k8s系统中，加载k8s对象定义；

其中，k8s对象包括：pod，service，deployment，StatefulSet，NetworkPolicy；每个Deployment管理不作区分的一个或多个Pod，每个StatefulSet管理有序号作区分的一个或多个Pod，每个Pod包含紧耦合的一个或多个容器，每个容器基于一个镜像；

步骤S12：选择测试可能涉及的微服务，通过k8s对象NetworkPolicy网络策略定义的请求权，排除测试实际不可能涉及的微服务；

步骤S13：编写测试计划，包括确定直接被测微服务、测试请求、测试环境命名空间和适用于不同范围的候选故障等测试参数，以及不同故障组合下，对测试请求响应的检查断言。

用户需要指定测试请求，比如对于HTTP测试请求，需要设置请求方法、请求URI、请求头和请求体等请求内容。用户需要指定测试环境命名空间，若使用已有命名空间将首先清空，测试期间所有命名空间级资源均创建在其中。用户可以指定适用于所有微服务、特定微服务和特定微服务特定请求的候选故障种类和参数，用于执行测试时向微服务后端容器注入故障。用户可以指定在不同故障组合下，对测试请求响应的检查断言，即响应的状态码、响应头、响应体等是否满足一定要求。

在一个实施例中，上述步骤S2：根据微服务混沌测试计划创建子任务，在执行子任务过程中根据枚举到的故障和下游响应组合注入故障和设置响应，通过上游代理发出测试请求，通过下游代理和域名解析记录发现不可代理下游、依赖的外部服务和依赖缺失，通过下游代理返回设置的响应，通过上游代理记录测试请求结果，合并测试结果相同的故障和下游响应组合，跳过不必要的故障和下游响应组合，具体包括：

步骤S201：在测试环境命名空间中部署测试计划的执行容器，向执行容器提交测试计划；

步骤S202：执行容器根据测试计划，按其中涉及的不可代理故障，部署对应的模拟工作负载；并按被测微服务的下游微服务配置路由，将被测微服务对下游微服务的请求路由到执行容器的代理服务；

在本步骤中，创建以与微服务名字对应的别名命名的k8s的Service(以下简称为别名Service)，使上游代理对被测微服务的请求路由到按需部署的微服务工作负载；创建以微服务原名命名的k8s的Service(以下简称为原名Service)，使被测微服务对下游微服务的请求路由到下游代理；运行代理服务监听可能涉及微服务的所有端口、HTTP(S)默认端口和测试计划中配置的端口，记录收到请求的来源、目标和内容；部署模拟下游工作负载，用于模拟下文不可代理故障中与具体微服务无关的故障；

步骤S203：执行容器根据被测微服务和测试请求，创建初始测试子任务；

步骤S204：将初始测试子任务加入被测微服务的子任务待执行列表；

当加入子任务待执行列表的子任务未立即被执行协程执行，且当前执行协程总数小于配置时，启动一个新的执行协程；

步骤S205：每个被测微服务的每个执行协程从子任务待执行列表取出子任务，执行测试子任务；

步骤S206：部署子任务的被测工作负载组合，被测工作负载组合包括被测微服务的工作负载，及其不可代理下游微服务的工作负载；

步骤S207：根据被测工作负载组合的故障组合，以及所有可代理下游响应形成的响应组合，构成故障-响应组合；每次枚举一种故障-响应组合，检查当前枚举的被测工作负载组合的故障组合；如果故障时的测试结果与被测工作负载组合无关，即测试请求有固定结果，记录测试结果，重复步骤S207，继续下一次枚举；否则，转至步骤S208；

步骤S208：检查当前枚举的被测工作负载组合中，是否存在不可代理下游微服务的工作负载；如果存在，加写锁阻塞任何其它测试子任务执行，修改路由，使被测微服务工作负载对下游的不可代理请求不再路由到下游代理，而是路由到模拟工作负载或实际工作负载；如果不存在，加读锁阻塞其它下游存在不可代理故障的测试子任务执行，保持路由不变；

步骤S209：根据当前枚举的所有下游响应形成的组合，设置下游代理对收到请求的响应；

步骤S210：当被测工作负载组合就绪后，注入域名解析故障和Pod内部故障；

本发明将故障分为可直接设置故障、域名解析故障、不可代理故障、Pod内部故障和人工定义故障。不同种类的故障采用不同方式模拟或注入，具体过程如下：

(1)可直接设置故障在故障发生时的响应不特定于具体微服务，包括HTTP请求或响应的中止或超时，以及通过手动设置响应状态码模拟的故障等。微服务故障情况为可直接设置故障时，可以直接设置对应的响应。

(2)域名解析故障通过在请求下游时发生影响上游微服务，故障表现不特定于下游微服务但特定于上游微服务，因此必须执行实际故障注入和测试。域名解析故障包括域名解析错误、域名解析返回错误值等。微服务依赖下游的响应组合存在域名解析故障时，需要对被测微服务注入故障。

(3)不可代理故障既无法在代理模拟，也无法通过在故障微服务的上游微服务注入故障来模拟，因为代理需要根据请求来源、目标和内容获取对应响应，并且能够在确定响应后通过代理模拟出对应响应。包括Pod崩溃、不可用，网络缓慢，不确定执行或通过非HTTP协议请求下游时的正常或故障行为等。测试下游组合存在不可代理故障时，通过全局加写锁暂时阻塞其它测试，避免修改故障微服务的原名Service干扰同时执行的其它测试。

其中，对于不特定于实际下游微服务的故障时表现，包括Pod崩溃、Pod不可用、网络缓慢，模拟这些故障无需同时部署实际下游微服务的工作负载，但需要下游工作负载存在，因此对于每种故障部署一个开销尽可能小的工作负载作为模拟下游，实际部署一个Pod，仅包含一个基于pause镜像的容器，即占用资源少、不提供任何功能但可以保持持续存在的容器。pause镜像原本用于隐含地在Pod中第一个启动，用于在Pod中多个容器间共享网络的中间容器，已经存在于k8s系统中，因此部署基于pause镜像的容器无需额外拉取镜像。下游存在此类故障时，修改故障微服务原名Service将被测微服务对此下游的请求路由到此种故障对应的工作负载。持续性故障Pod不可用和网络断开可以维持故障状态，而瞬时故障Pod崩溃故障需要每次测试时执行故障注入；

对于特定于实际下游微服务的正常或故障时表现，即此下游既无法被代理也无法按类别使用相同下游模拟，部署相应的实际下游工作负载，共同枚举故障组合并执行故障注入。下游存在此类故障时，修改故障微服务原名Service将被测微服务对此下游的请求路由到对应实际下游微服务的工作负载。

(4)Pod内部故障无论是否请求下游都可能发生，因故障时的响应特定于具体微服务而必须执行实际故障注入和测试。包括CPU占用，挂载卷IO延迟、错误和返回错误值，时间偏移，JVM触发垃圾回收、增加CPU和内存占用故障，Linux内核slab分配、内存页分配和bio故障等。当依赖的响应组合不为空时，可以与域名解析故障和不可代理故障同时发生。

(5)人工定义故障无法自动确定故障参数，或以人工指定作为自动确定的补充。包括JVM应用抛出自定义异常、增加指定方法延迟、使指定方法返回指定值，以及参数由用户指定的其它故障。根据故障种类和人工设置的参数按上述方式注入或模拟故障。

步骤S211：上游代理向被测微服务发送测试请求，引发其对下游请求，形成域名解析记录，将可代理下游的请求路由到下游代理；

步骤S212：下游代理根据收到的请求，执行对应的预设响应；

步骤S213：上游代理完成对被测微服务的测试请求，记录测试请求的响应，以及测试请求期间下游代理收到的请求和来自工作负载组合的域名解析记录；

步骤S214：从故障中恢复，还原路由并解锁；如果之前执行过故障注入，此时从故障中恢复；如果之前因下游存在不可代理故障而修改路由，此时还原路由为默认配置，即被测微服务工作负载对下游的请求被路由到下游代理，然后释放写锁；否则，释放读锁；

步骤S215：检查下游代理收到的请求，即被测工作负载组合处理测试请求期间依赖的下游微服务；如果发现新的不可代理下游微服务，回退到部署不可代理下游微服务工作负载，转至步骤S206；

在本步骤中，若请求不是基于HTTP协议，或与上次对相同微服务相同请求引发的对下游请求存在不同，即对下游的请求有不确定性，则下游为不可代理微服务；

步骤S216：检查下游代理收到的请求是否存在依赖缺失，即在下游代理预设的响应中，没有响应与收到的请求相对应；如果存在依赖缺失，根据收到的请求创建依赖子任务，加入对应微服务的子任务待执行列表；执行协程暂停执行并跳过存在依赖缺失的当前子任务；

步骤S217：对于存在依赖缺失的子任务，当依赖子任务完成后，将子任务放回子任务待执行列表；

步骤S218：检查域名解析记录，是否存在新的依赖外部服务；如果存在，修改被测工作负载组合的容器内域名解析配置，从而在重试时将原本对外部服务的请求路由到下游代理，回退到加锁和修改路由，转至步骤S208；

步骤S219：如果不存在新的不可代理下游微服务、依赖缺失或新的依赖外部服务，即本次测试请求完成，记录测试结果；

步骤S220：检查故障-响应组合，是否均已被枚举和测试完；如果已枚举完，完成当前子任务；否则，枚举下一个故障组合与响应组合形成的组合；

步骤S221：对于已完成测试子任务，查看测试请求在不同微服务的故障-响应组合所对应测试结果；

步骤S222：当初始测试子任务执行完成时，测试计划执行完成。

如图2所示，当执行协程作为上游代理发出测试请求时，通过别名Service请求执行协程对应的被测微服务工作负载，工作负载处理测试请求过程中对下游服务的请求，随下游服务类型和此时枚举到的下游响应种类路由到不同目标：

(1)可代理响应：服务A和B的响应可代理，比如通过HTTP返回包含特定状态码和响应体内容的响应，因此被测微服务工作负载处理测试请求过程中，对服务A和B的请求被通过默认配置的原名Service路由到下游代理，即在下游代理通过HTTP返回包含特定状态码和响应体内容的响应；

(2)响应不特定于微服务工作负载的不可代理故障：服务C和D的响应为相同种类的不可代理故障，比如服务不可用故障，因此请求被通过事先修改的原名Service，路由到测试计划开始执行时部署的对应种类不可代理故障的模拟下游工作负载，即用不打开任何端口的工作负载模拟服务不可用故障；

(3)响应特定于微服务工作负载的不可代理服务：服务E和F为不可代理服务，比如通过基于TCP的自定义协议与被测微服务工作负载通信，因此请求被通过事先修改的原名Service，路由到当前子任务开始执行时部署的不可代理服务下游的实际工作负载，即同时对微服务和不可代理服务的工作负载注入故障和执行测试。

图3展示了基于自动依赖发现和代理的微服务混沌测试的流程图。

在一个实施例中，上述步骤S3：检查和生成最终的测试结果，具体包括：

步骤S31：在不同故障组合下，检查初始测试子任务的测试结果是否符合预期；

当执行混沌测试计划创建的首个子任务，也就是最上游的子任务执行完成后，开始检查微服务系统对部分故障的处理是否符合断言。每条断言包含故障组合和对响应各部分的要求，部分包含响应状态码、响应头键值对、响应体文本、响应体JSON字段等，要求包含等于、属于集合、字符串包含等。对于每个响应，检查对应的故障组合集合与每个断言的故障组合是否有交集，如果有则检查响应是否符合断言，得到所有断言的检查结果。将所有断言的故障组合合并为已检查故障组合集，然后将每个响应的故障组合集与已检查故障组合集求差集，可以得到未被断言检查的响应和故障组合集，可以作为完善断言的参考；

步骤S32：将初始测试子任务的测试结果可视化，用于后续完善被测微服务和测试计划。

为了便于人工查看微服务系统对部分故障的处理，将各个子任务由首个子任务开始组合成调用图，允许通过指定若干微服务的故障状态，筛选符合要求的调用图。

实施例二

如图4所示，本发明实施例提供了一种基于自动依赖发现和代理的微服务混沌测试系统，包括下述模块：

创建混沌测试计划模块41，用于基于涉及微服务的工作负载和服务，创建微服务混沌测试计划；

执行混沌测试计划模块42，用于根据微服务混沌测试计划创建子任务，在执行子任务过程中根据枚举到的故障和下游响应组合注入故障和设置响应，通过上游代理发出测试请求，通过下游代理和域名解析记录发现不可代理下游、依赖的外部服务和依赖缺失，通过下游代理返回设置的响应，通过上游代理记录测试请求结果，合并测试结果相同的故障和下游响应组合，跳过不必要的故障和下游响应组合；

生成混沌测试结果模块43，用于检查和生成最终的测试结果。

提供以上实施例仅仅是为了描述本发明的目的，而并非要限制本发明的范围。本发明的范围由所附权利要求限定。不脱离本发明的精神和原理而做出的各种等同替换和修改，均应涵盖在本发明的范围之内。

Claims (5)

1.一种基于自动依赖发现和代理的微服务混沌测试方法，其特征在于，包括：

步骤S1：基于涉及微服务的工作负载和服务，创建微服务混沌测试计划；

步骤S2：根据所述微服务混沌测试计划创建子任务，在执行所述子任务过程中根据枚举到的故障和下游响应组合注入故障和设置响应，通过上游代理发出测试请求，通过下游代理和域名解析记录发现不可代理下游、依赖的外部服务和依赖缺失，通过所述下游代理返回设置的响应，通过所述上游代理记录测试请求结果，合并测试结果相同的故障和下游响应组合，跳过不必要的故障和下游响应组合；

步骤S3：检查和生成最终的测试结果。

2.根据权利要求1所述的基于自动依赖发现和代理的微服务混沌测试方法，其特征在于，所述步骤S1：基于涉及微服务的工作负载和服务，创建微服务混沌测试计划，具体包括：

步骤S11：从用户提交的定义文件和k8s系统中，加载k8s对象定义；

步骤S12：选择测试可能涉及的微服务，通过k8s对象NetworkPolicy网络策略定义的请求权，排除测试实际不可能涉及的微服务；

步骤S13：编写测试计划，包括确定所述直接被测微服务、测试请求、测试环境命名空间和适用于不同范围的候选故障等测试参数，以及不同故障组合下，对测试请求响应的检查断言。

3.根据权利要求2所述的基于自动依赖发现和代理的微服务混沌测试方法，其特征在于，所述步骤S2：根据所述微服务混沌测试计划创建子任务，在执行所述子任务过程中根据枚举到的故障和下游响应组合注入故障和设置响应，通过上游代理发出测试请求，通过下游代理和域名解析记录发现不可代理下游、依赖的外部服务和依赖缺失，通过所述下游代理返回设置的响应，通过所述上游代理记录测试请求结果，合并测试结果相同的故障和下游响应组合，跳过不必要的故障和下游响应组合，具体包括：

步骤S201：在所述测试环境命名空间中部署所述测试计划的执行容器，向所述执行容器提交所述测试计划；

步骤S202：所述执行容器根据所述测试计划，按其中涉及的不可代理故障，部署对应的模拟工作负载；并按被测微服务的下游微服务配置路由，将所述被测微服务对下游微服务的请求路由到所述执行容器的代理服务；

步骤S203：所述执行容器根据所述被测微服务和所述测试请求，创建初始测试子任务；

步骤S204：将所述初始测试子任务加入所述被测微服务的子任务待执行列表；

步骤S205：每个所述被测微服务的每个执行协程从所述子任务待执行列表取出子任务，执行测试子任务；

步骤S206：部署所述子任务的被测工作负载组合，所述被测工作负载组合包括被测微服务的工作负载，及其不可代理下游微服务的工作负载；

步骤S207：根据所述被测工作负载组合的故障组合，以及所有可代理下游响应形成的响应组合，构成故障-响应组合；每次枚举一种所述故障-响应组合，检查当前枚举的被测工作负载组合的故障组合；如果故障时的测试结果与所述被测工作负载组合无关，即测试请求有固定结果，记录测试结果，重复步骤S207，继续下一次枚举；否则，转至步骤S208；

步骤S208：检查当前枚举的被测工作负载组合中，是否存在不可代理下游微服务的工作负载；如果存在，加写锁阻塞任何其它测试子任务执行，修改路由，使所述被测微服务工作负载对下游的不可代理请求不再路由到下游代理，而是路由到模拟工作负载或实际工作负载；如果不存在，加读锁阻塞其它下游存在不可代理故障的测试子任务执行，保持路由不变；

步骤S209：根据当前枚举的所有下游响应形成的组合，设置下游代理对收到请求的响应；

步骤S210：当所述被测工作负载组合就绪后，注入域名解析故障和Pod内部故障；

步骤S211：上游代理向所述被测微服务发送测试请求，引发其对下游请求，形成域名解析记录，将可代理下游的请求路由到下游代理；

步骤S212：所述下游代理根据收到的请求，执行对应的预设响应；

步骤S213：上游代理完成对所述被测微服务的测试请求，记录测试请求的响应，以及测试请求期间下游代理收到的请求和来自所述工作负载组合的所述域名解析记录；

步骤S214：从故障中恢复，还原路由并解锁；如果之前执行过故障注入，此时从故障中恢复；如果之前因下游存在不可代理故障而修改路由，此时还原路由为默认配置，即所述被测微服务工作负载对下游的请求被路由到下游代理，然后释放所述写锁；否则，释放所述读锁；

步骤S215：检查下游代理收到的请求，即所述被测工作负载组合处理测试请求期间依赖的下游微服务；如果发现新的不可代理下游微服务，回退到部署不可代理下游微服务工作负载，转至步骤S206；

步骤S216：检查下游代理收到的请求是否存在依赖缺失，即在下游代理预设的响应中，没有响应与收到的请求相对应；如果存在依赖缺失，根据收到的请求创建依赖子任务，加入对应微服务的子任务待执行列表；执行协程暂停执行并跳过存在依赖缺失的当前子任务；

步骤S217：对于存在依赖缺失的子任务，当依赖子任务完成后，将子任务放回所述子任务待执行列表；

步骤S218：检查所述域名解析记录，是否存在新的依赖外部服务；如果存在，修改所述被测工作负载组合的容器内域名解析配置，从而在重试时将原本对外部服务的请求路由到下游代理，回退到加锁和修改路由，转至步骤S208；

步骤S219：如果不存在新的不可代理下游微服务、依赖缺失或新的依赖外部服务，即本次测试请求完成，记录测试结果；

步骤S220：检查所述故障-响应组合，是否均已被枚举和测试完；如果已枚举完，完成当前子任务；否则，枚举下一个所述故障组合与所述响应组合形成的组合；

步骤S221：对于已完成测试子任务，查看测试请求在不同微服务的所述故障-响应组合所对应测试结果；

步骤S222：当所述初始测试子任务执行完成时，所述测试计划执行完成。

4.根据权利要求3所述的基于自动依赖发现和代理的微服务混沌测试方法，其特征在于，所述步骤S3：检查和生成最终的测试结果，具体包括：

步骤S31：在不同故障组合下，检查所述初始测试子任务的测试结果是否符合预期；

步骤S32：将所述初始测试子任务的测试结果可视化，用于后续完善所述被测微服务和所述测试计划。

5.一种基于自动依赖发现和代理的微服务混沌测试系统，其特征在于，包括下述模块：

创建混沌测试计划模块，用于基于涉及微服务的工作负载和服务，创建微服务混沌测试计划；

执行混沌测试计划模块，用于根据所述微服务混沌测试计划创建子任务，在执行所述子任务过程中根据枚举到的故障和下游响应组合注入故障和设置响应，通过上游代理发出测试请求，通过下游代理和域名解析记录发现不可代理下游、依赖的外部服务和依赖缺失，通过所述下游代理返回设置的响应，通过所述上游代理记录测试请求结果，合并测试结果相同的故障和下游响应组合，跳过不必要的故障和下游响应组合；生成混沌测试结果模块，用于检查和生成最终的测试结果。