CN117056081A - 基于混沌工程的系统负载均衡能力验证方法和装置 - Google Patents
基于混沌工程的系统负载均衡能力验证方法和装置 Download PDFInfo
- Publication number
- CN117056081A CN117056081A CN202311177011.2A CN202311177011A CN117056081A CN 117056081 A CN117056081 A CN 117056081A CN 202311177011 A CN202311177011 A CN 202311177011A CN 117056081 A CN117056081 A CN 117056081A
- Authority
- CN
- China
- Prior art keywords
- target
- fault
- fault injection
- target system
- load balancing
- 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.)
- Pending
Links
- 238000012795 verification Methods 0.000 title claims abstract description 165
- 238000000034 method Methods 0.000 title claims abstract description 98
- 230000000739 chaotic effect Effects 0.000 title claims abstract description 62
- 238000002347 injection Methods 0.000 claims abstract description 269
- 239000007924 injection Substances 0.000 claims abstract description 269
- 238000012545 processing Methods 0.000 claims abstract description 61
- 238000004088 simulation Methods 0.000 claims abstract description 55
- 238000012544 monitoring process Methods 0.000 claims abstract description 40
- 230000008569 process Effects 0.000 claims abstract description 38
- 238000004590 computer program Methods 0.000 claims abstract description 23
- 239000003795 chemical substances by application Substances 0.000 claims abstract description 14
- 238000003860 storage Methods 0.000 claims abstract description 12
- 238000011084 recovery Methods 0.000 claims description 108
- 238000002474 experimental method Methods 0.000 description 14
- 230000004044 response Effects 0.000 description 11
- 230000002159 abnormal effect Effects 0.000 description 6
- 238000013515 script Methods 0.000 description 6
- 238000003825 pressing Methods 0.000 description 5
- 239000000725 suspension Substances 0.000 description 5
- 230000005856 abnormality Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 238000002955 isolation Methods 0.000 description 4
- 238000012360 testing method Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 239000000243 solution Substances 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- OKTJSMMVPCPJKN-UHFFFAOYSA-N Carbon Chemical compound [C] OKTJSMMVPCPJKN-UHFFFAOYSA-N 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 229910021389 graphene Inorganic materials 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N7/00—Computing arrangements based on specific mathematical models
- G06N7/08—Computing arrangements based on specific mathematical models using chaos models or non-linear system models
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Artificial Intelligence (AREA)
- Algebra (AREA)
- Nonlinear Science (AREA)
- Computational Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Evolutionary Computation (AREA)
- Mathematical Analysis (AREA)
- Mathematical Optimization (AREA)
- Pure & Applied Mathematics (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
Abstract
本申请涉及一种基于混沌工程的系统负载均衡能力验证方法、装置、计算机设备、存储介质和计算机程序产品。待验证的目标系统包含若干节点，节点部署有故障事件模拟代理程序。混沌工程平台在确定目标系统模拟业务处理场景的情况下，读取负载均衡能力验证配置文件，确定目标故障注入事件以及若干节点中的故障注入目标节点。通过部署于故障注入目标节点的故障事件模拟代理程序，对故障注入目标节点下发目标故障注入事件的执行指令；在目标故障注入事件执行过程中，监测目标系统的运行参数，确定目标系统的负载均衡能力验证结果。采用本方法能够提升负载均衡能力验证效率。
Description
技术领域
本申请涉及系统能力验证技术领域，特别是涉及一种基于混沌工程的系统负载均衡能力验证方法、装置、计算机设备、存储介质和计算机程序产品。
背景技术
分布式系统可以利用多个机器协同处理数据，提升了系统的性能以及并发能力，这使得很多运营商会使用分布式系统进行业务的处理。一般而言，在部署的分布式系统实际投入使用前，会对分布式系统的各项能力进行验证，如最大负载能力、在高负载下的处理能力等。而负载均衡作为分布式系统的优势，在投入使用前也需要进行验证。
相关技术中，一般通过模拟停服务、进程挂起、宕网卡等故障场景的方式进行验证，验证各节点在出现上述故障场景的异常情况下，分布式系统的硬负载或软负载配置能否有效探测出节点异常并进行隔离，并在探测出节点异常并进行隔离后，重新实现负载均衡。其中，上述故障一般通常会通过人工直接操作来模拟故障场景，例如，通过人工在终端执行kill-9PID等命令或者执行停止程序的脚本来实现停服务，执行kill-19PID命令来实现进程挂起，通过人工编写指令执行脚本或拔出网线等方式模拟宕网卡等故障场景。
上述的方式虽然也能够验证出分布式系统的负载均衡能力，但人工模拟故障场景的方式准确率、效率都很低，导致验证系统负载均衡能力的准确率、效率都很低。
发明内容
基于此，有必要针对上述技术问题，提供一种能够提升验证准确率以及效率的基于混沌工程的系统负载均衡能力验证方法、装置、计算机设备、计算机可读存储介质和计算机程序产品。
第一方面，本申请提供了一种基于混沌工程的系统负载均衡能力验证方法。待验证的目标系统包含若干节点，所述节点部署有故障事件模拟代理程序，所述方法包括：
在所述目标系统模拟业务处理场景的情况下，读取负载均衡能力验证配置文件，确定目标故障注入事件以及所述若干节点中的故障注入目标节点；
通过部署于所述故障注入目标节点的故障事件模拟代理程序，对所述故障注入目标节点下发所述目标故障注入事件的执行指令；
在所述目标故障注入事件执行过程中，监测所述目标系统的运行参数，确定所述目标系统的负载均衡能力验证结果。
在其中一个实施例中，所述负载均衡能力验证配置文件包括多个故障注入事件、所述故障注入事件在各节点中对应的故障注入目标节点和所述故障注入事件的开始时间。
在其中一个实施例中，所述方法还包括：
将下发所述目标故障注入事件的执行指令的时刻记录为故障注入时刻；
所述在所述目标故障注入事件执行过程中，监测所述目标系统的运行参数，确定所述目标系统的负载均衡能力验证结果，包括：
监测所述目标系统的运行参数，在所述运行参数符合预设的正常运行参数的情况下，将所述目标系统的运行参数符合所述预设的正常运行参数的时刻作为故障恢复时刻；
基于所述故障注入时刻以及所述故障恢复时刻，确定所述目标系统的故障恢复时长；
比较所述故障恢复时长与预设的故障恢复指标值，确定所述目标系统的负载均衡能力验证结果。
在其中一个实施例中，所述在所述目标故障注入事件执行过程中，监测所述目标系统的运行参数，确定所述目标系统的负载均衡能力验证结果，包括：
在所述目标系统模拟业务处理场景的情况下，对所述故障注入目标节点下发目标故障注入事件执行指令，获取所述目标系统的第一运行参数；
对所述故障注入目标节点下发目标故障注入事件执行指令预设时长后，获取所述目标系统当前的第二运行参数；
比较所述第一运行参数以及所述第二运行参数，确定所述目标系统的负载均衡能力验证结果。
在其中一个实施例中，所述方法还包括：
将下发所述目标故障注入事件的执行指令的时刻记录为故障注入时刻；
所述在所述目标故障注入事件执行过程中，监测所述目标系统的运行参数，确定所述目标系统的负载均衡能力验证结果，包括：
在所述目标系统模拟业务处理场景的情况下，对所述故障注入目标节点下发目标故障注入事件执行指令，获取所述目标系统的第一运行参数；
监测所述目标系统的运行参数，在所述运行参数与所述第一运行参数一致的情况下，将所述目标系统的运行参数与所述第一运行参数一致的时刻作为故障恢复时刻；
基于所述故障注入时刻以及所述故障恢复时刻，确定所述目标系统的故障恢复时长；
比较所述故障恢复时长与预设的故障恢复指标值，确定所述目标系统的负载均衡能力验证结果。
在其中一个实施例中，在所述读取负载均衡能力验证配置文件，确定目标故障注入事件以及所述若干节点中的故障注入目标节点之前，所述方法还包括：
读取所述目标系统的施压配置文件，确定所述目标系统的负载参数；
基于所述负载参数，创建虚拟用户访问所述目标系统，以使所述目标系统模拟业务处理场景。
在其中一个实施例中，所述方法还包括：
在所述目标系统模拟业务处理场景过程中，监测所述目标系统的运行参数；
所述在所述目标系统模拟业务处理场景的情况下，读取负载均衡能力验证配置文件，确定目标故障注入事件以及所述若干节点中的故障注入目标节点，包括：
在所述目标系统的运行参数符合预设的运行参数指标值的时长到达预设的稳定运行时长的情况下，读取负载均衡能力验证配置文件，确定目标故障注入事件以及故障注入目标节点。
第二方面，本申请还提供了一种基于混沌工程的系统负载均衡能力验证装置。待验证的目标系统包含若干节点，所述节点部署有故障事件模拟代理程序，所述装置包括：
读取模块，用于在所述目标系统模拟业务处理场景的情况下，读取负载均衡能力验证配置文件，确定目标故障注入事件以及所述若干节点中的故障注入目标节点；
故障注入模块，用于通过部署于所述故障注入目标节点的故障事件模拟代理程序，对所述故障注入目标节点下发所述目标故障注入事件的执行指令；
验证模块，用于在所述目标故障注入事件执行过程中，监测所述目标系统的运行参数，确定所述目标系统的负载均衡能力验证结果。
在其中一个实施例中，所述负载均衡能力验证配置文件包括多个故障注入事件、所述故障注入事件在各节点中对应的故障注入目标节点和所述故障注入事件的开始时间。
在其中一个实施例中，上述装置还包括：
第一故障注入时刻记录模块，用于将下发所述目标故障注入事件的执行指令的时刻记录为故障注入时刻；
此时，上述验证模块包括：
第一故障恢复时刻记录单元，监测所述目标系统的运行参数，在所述运行参数符合预设的正常运行参数的情况下，将所述目标系统的运行参数符合所述预设的正常运行参数的时刻作为故障恢复时刻；
第一恢复时长确定单元，用于基于所述故障注入时刻以及所述故障恢复时刻，确定所述目标系统的故障恢复时长；
第一验证单元，用于比较所述故障恢复时长与预设的故障恢复指标值，确定所述目标系统的负载均衡能力验证结果。
在其中一个实施例中，上述验证模块包括：
第一运行参数确定单元，用于在所述目标系统模拟业务处理场景的情况下，对所述故障注入目标节点下发目标故障注入事件执行指令，获取所述目标系统的第一运行参数；
第二运行参数确定单元，用于对所述故障注入目标节点下发目标故障注入事件执行指令预设时长后，获取所述目标系统当前的第二运行参数；
第二验证单元，用于比较所述第一运行参数以及所述第二运行参数，确定所述目标系统的负载均衡能力验证结果。
在其中一个实施例中，上述装置还包括：
第二故障注入时刻记录模块，用于将下发所述目标故障注入事件的执行指令的时刻记录为故障注入时刻；
此时，上述验证模块包括：
第三运行参数确定单元，在所述目标系统模拟业务处理场景的情况下，对所述故障注入目标节点下发目标故障注入事件执行指令，获取所述目标系统的第一运行参数；
第二恢复时长确定单元，用于监测所述目标系统的运行参数，在所述运行参数与所述第一运行参数一致的情况下，将所述目标系统的运行参数与所述第一运行参数一致的时刻作为故障恢复时刻；
第二恢复时长确定单元，用于基于所述故障注入时刻以及所述故障恢复时刻，确定所述目标系统的故障恢复时长；
第三验证单元，用于比较所述故障恢复时长与预设的故障恢复指标值，确定所述目标系统的负载均衡能力验证结果。
在其中一个实施例中，上述装置还包括：
负载参数确定模块，用于读取所述目标系统的施压配置文件，确定所述目标系统的负载参数；
施压模块，用于基于所述负载参数，创建虚拟用户访问所述目标系统，以使所述目标系统模拟业务处理场景。
在其中一个实施例中，上述装置还包括：
监测模块，用于在所述目标系统模拟业务处理场景过程中，监测所述目标系统的运行参数；
此时，上述读取模块具体用于：
在所述目标系统的运行参数符合预设的运行参数指标值的时长到达预设的稳定运行时长的情况下，读取负载均衡能力验证配置文件，确定目标故障注入事件以及故障注入目标节点。
第三方面，本申请还提供了一种计算机设备。所述计算机设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：
在所述目标系统模拟业务处理场景的情况下，读取负载均衡能力验证配置文件，确定目标故障注入事件以及所述若干节点中的故障注入目标节点；
通过部署于所述故障注入目标节点的故障事件模拟代理程序，对所述故障注入目标节点下发所述目标故障注入事件的执行指令；
在所述目标故障注入事件执行过程中，监测所述目标系统的运行参数，确定所述目标系统的负载均衡能力验证结果。
第四方面，本申请还提供了一种计算机可读存储介质。所述计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：
在所述目标系统模拟业务处理场景的情况下，读取负载均衡能力验证配置文件，确定目标故障注入事件以及所述若干节点中的故障注入目标节点；
通过部署于所述故障注入目标节点的故障事件模拟代理程序，对所述故障注入目标节点下发所述目标故障注入事件的执行指令；
在所述目标故障注入事件执行过程中，监测所述目标系统的运行参数，确定所述目标系统的负载均衡能力验证结果。
第五方面，本申请还提供了一种计算机程序产品。所述计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现以下步骤：
在所述目标系统模拟业务处理场景的情况下，读取负载均衡能力验证配置文件，确定目标故障注入事件以及所述若干节点中的故障注入目标节点；
通过部署于所述故障注入目标节点的故障事件模拟代理程序，对所述故障注入目标节点下发所述目标故障注入事件的执行指令；
在所述目标故障注入事件执行过程中，监测所述目标系统的运行参数，确定所述目标系统的负载均衡能力验证结果。
上述基于混沌工程的系统负载均衡能力验证方法、装置、计算机设备、存储介质和计算机程序产品，预先在待验证的目标系统中的各节点部署故障事件模拟代理程序，混沌工程平台通过部署的故障事件模拟代理程序，对目标系统中的各节点进行故障注入，实现故障场景的模拟，进而验证目标系统的负载均衡能力。通过故障事件模拟代理程序进行故障注入的方式进行故障模拟，使得故障模拟准确率高。
附图说明
图1为一个实施例中基于混沌工程的系统负载均衡能力验证方法的应用环境图；
图2为一个实施例中基于混沌工程的系统负载均衡能力验证方法的流程示意图；
图3为另一个实施例中基于混沌工程的系统负载均衡能力验证方法的流程示意图；
图4为一个实施例中基于混沌工程的系统负载均衡能力验证装置的结构框图；
图5为一个实施例中计算机设备的内部结构图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
分布式系统的其中一个优势是通过负载均衡的方式，将作业任务分配至各个分布式节点，提高系统的性能及效率，并且，在分布式系统中某分布式节点发生故障时，能够有效检测出发生异常的节点并进行隔离，然后通过负载均衡的相关配置，使其他节点继续运行故障节点运行的任务。
相关技术中，一般是通过人工模拟服务暂停、宕机、进程挂起等，然后通过故障发生前以及发生后的运行参数等，评估系统的负载均衡能力。这种方式准确率、效率都很低，导致验证系统负载均衡能力的准确率、效率都很低。
基于此，本申请提出一种基于混沌工程的系统负载均衡能力验证方法，该方法应用于需要负载均衡验证的目标系统，即待验证的目标系统，其中，待验证的目标系统包含若干节点，节点部署有故障事件模拟代理程序。混沌工程平台部署于负载均衡能力验证系统中，在确定目标系统模拟业务处理场景的情况下，混沌工程平台读取负载均衡能力验证配置文件，确定目标故障注入事件以及若干节点中的故障注入目标节点。通过部署于故障注入目标节点的故障事件模拟代理程序，对故障注入目标节点下发目标故障注入事件的执行指令；在目标故障注入事件执行过程中，监测目标系统的运行参数，确定目标系统的负载均衡能力验证结果。
本申请提供的基于混沌工程的系统负载均衡能力验证方法，预先在待验证的目标系统中的各节点部署故障事件模拟代理程序，混沌工程平台通过部署的故障事件模拟代理程序，对目标系统中的各节点进行故障注入，实现故障场景的模拟，进而验证目标系统的负载均衡能力。通过故障事件模拟代理程序进行故障注入的方式进行故障模拟，故障模拟准确率高，使得验证系统负载均衡能力的效率大大提升。
本申请实施例提供的基于混沌工程的系统负载均衡能力验证方法，可以应用于如图1所示的应用环境中。目标系统为待验证的分布式系统，包括多个节点，混沌工程平台为独立于目标系统的第三方平台，部署于负载均衡能力验证系统，并在目标系统的各节点上部署有故障事件模拟代理程序，其中，混沌工程平台可以通过部署于各节点的故障事件模拟代理程序，对各节点进行控制。
其中，混沌工程平台是通过主动向目标系统注入硬件或软件故障，暴露目标系统薄弱环节，并制定优化方案，以不断提升目标系统韧性的平台。故障事件模拟代理程序部署于目标系统的各节点，负责混沌工程平台与目标系统之间信息交互，当故障事件模拟代理程序接收到混沌工程平台下达一个具体的故障注入的指令之后，故障事件模拟代理程序按照指令内容在其部署的节点上执行相应的故障注入的操作，混沌工程可模拟的故障种类有多种，比如停服务、杀进程、网络丢包等。在一些实施例中，故障事件模拟代理程序可以是agent代理程序。
在一个实施例中，如图2所示，提供了一种基于混沌工程的系统负载均衡能力验证方法，包括负载均衡能力验证系统和待验证的目标系统，以该方法应用于图1中待验证的目标系统为例进行说明，包括以下步骤：
步骤201、在目标系统模拟业务处理场景的情况下，读取负载均衡能力验证配置文件，确定目标故障注入事件以及若干节点中的故障注入目标节点。
故障注入事件为模拟系统运行遇到的各故障事件，如进程被杀、进程被暂停、网络丢包、节点宕机等。故障注入目标节点为目标系统中的节点。目标系统为待验证系统负载均衡能力的系统，包括若干节点，目标系统包括的节点部署有故障事件模拟代理程序。
具体而言，在对目标系统的系统负载均衡能力进行验证前，目标系统还未投入使用，因此一般通过目标系统模拟业务处理场景，然后再模拟实际业务处理场景中的故障，目标系统的硬负载或软负载配置探测出节点发生异常或故障的节点并进行隔离，通过预设的算法或策略对服务器中的请求进行负载的分配，确保每个服务器都能平衡处理请求，避免单一服务器的过载情况，实现对服务器的负载均衡，并对发生异常或故障的节点运行的业务进行恢复。其中，该业务场景可以为高流量的网站或应用程序的后端服务器、数据库服务器或云原生服务器；硬负载可以为安装于服务器和外部网络间的负载均衡设备，用于处理大规模、高并发的计算任务，软负载可以安装于服务器的负载均衡软件，用于处理中小规模的计算任务。在此期间，对目标系统的运行参数进行监测，例如每秒运行业务数据、业务执行失败率、平均响应时间等，根据监测到的运行参数，验证系统的负载均衡能力。因此，在对目标系统模拟故障场景以及对系统负载均衡能力进行验证前，目标系统需要先模拟业务处理场景，当混沌工程平台确定目标系统模拟业务处理场景稳定运行后，开始模拟故障场景，读取负载均衡能力验证配置文件，确定模拟故障场景对应的目标故障注入事件以及目标故障注入事件预计被执行的故障注入目标节点。
步骤203、通过部署于故障注入目标节点的故障事件模拟代理程序，对故障注入目标节点下发目标故障注入事件的执行指令。
具体而言，混沌工程平台确定出目标故障注入事件以及若干节点中的故障注入目标节点后，通过部署于故障注入目标节点的故障事件模拟代理程序，对故障注入目标节点下发目标故障注入事件的执行指令，故障注入目标节点接收到混沌工程平台发送的指令后，识别出目标故障注入事件的执行指令，查找目标故障注入事件对应的脚本并执行，实现对故障注入目标节点的故障模拟。
在一个实施例中，负载均衡能力验证配置文件包括多个目标故障注入事件以及目标故障输入时间预计被执行的故障注入目标节点，还包括每个目标故障注入事件的执行时间，混沌工程平台按照各目标故障注入事件的执行时间，在各目标故障注入事件的执行时间到达时，将各目标故障注入事件的执行指令通过故障事件模拟代理程序下发至相应的目标故障注入事件。例如负载均衡能力验证配置文件配置了目标故障注入事件A、B、C、D，各自预计被执行的故障注入目标节点分别为节点1、节点3、节点2、节点1，各自的预计执行时间分别为：时刻1、3、7、10，当时刻1到达时，混沌工程平台将目标故障注入事件A的执行指令下发至节点1，当时刻3到达时，混沌工程平台将目标故障注入事件B的执行指令下发至节点3，当时刻7到达时，混沌工程平台将目标故障注入事件C的执行指令下发至节点2，当时刻10到达时，混沌工程平台将目标故障注入事件D的执行指令下发至节点1。
步骤205、在目标故障注入事件执行过程中，监测目标系统的运行参数，确定目标系统的负载均衡能力验证结果。
其中，运行参数用于反映系统运行过程中的负载能力指标，如各应用节点的基本资源情况(CPU利用率、内存占用率、IO使用率等)，或者与业务处理相关的指标(每秒业务数，业务处理失败率、业务平均响应时间等)。
具体而言，混沌工程平台对故障注入目标节点下发目标故障注入事件的执行指令后，在故障注入目标节点对目标故障注入事件执行过程中，通过分布式系统的监控体系对目标系统的运行参数进行监测，通过目标故障注入事件执行过程目标系统的运行参数，确定目标系统的负载均衡能力验证结果。
在一个实施例中，负载均衡能力验证结果可以包括多个等级，例如负载均衡能力验证结果分为五个等级，例如一级至五级，一级负载均衡能力最优，五级负载均衡能力最差。负载均衡能力验证结果也可以只包括两个结果，负载均衡能力验证通过，或者负载均衡能力不通过。
可选的，混沌工程平台将目标故障注入事件的执行指令下发后，故障注入目标节点模拟实际故障场景并保持，混沌工程平台对目标系统的负载均衡能力验证完成后，需要恢复目标系统的状态，混沌工程平台对故障注入目标节点下发目标故障注入事件的结束指令，以使故障注入目标节点结束故障场景的模拟，恢复正常运行状态。
在此实施例中，预先在待验证的目标系统中的各节点部署故障事件模拟代理程序，混沌工程平台通过部署的故障事件模拟代理程序，对目标系统中的各节点进行故障注入，实现故障场景的模拟，进而验证目标系统的负载均衡能力。借助于混沌工程平台的故障注入能力，通过故障事件模拟代理程序对目标系统进行故障注入的方式进行故障模拟，故障模拟准确率高，使得验证系统负载均衡能力的效率大大提升。
在其中一个实施例中，负载均衡能力验证配置文件包括多个故障注入事件、故障注入事件在各节点中对应的故障注入目标节点和故障注入事件的开始时间。
本申请实施例中，负载均衡能力验证配置文件是在本申请实施例应用之前完成配置的，以便在负载均衡能力验证系统应用时，其部署的混沌工程平台能够通过读取该负载均衡能力验证配置文件中的信息，确定出故障注入事件、故障注入事件对应的节点和故障注入事件的开始时间，进而实现针对目标系统的负载均衡能力进行验证。其中，负载均衡能力验证配置文件中可以包含但不限于记录有各故障注入事件、各故注入障事件在各节点中对应的故障注入目标节点和记录各故障注入开始执行时间，还可以包含监控和度量配置，用于实时监测整个系统的状态和性能，及时发现异常和预测故障，或者故障恢复配置，用于配置故障恢复策略，当某个服务器或服务不可用时，自动将请求重新分发到其他可用的健康服务器，以提高系统的可用性和容错性。
作为一种可选的实施方式，负载均衡能力配置文件中包含的各种故障注入事件可以为随机故障注入事件，以及故障注入时间的开始时间可以为随机时间，模拟真实世界中的突发故障和意外事件，以测试系统的健壮性和容错能力。通过引入随机性，可以模拟不可预测的故障场景，并更全面地评估目标系统的负载均衡能力，提高负载均衡能力验证系统的适用性。
在此实施例中，通过将基于混沌工程原理的故障注入时间写入负载均衡能力验证配置文件中，避免在负载均衡能力验证的应用过程中人为编写测试脚本出现错误和效率低的情况，进而提高验证系统负载均衡能力的效率。
在其中一个实施例中，上述方法还包括：
步骤207、将下发目标故障注入事件的执行指令的时刻记录为故障注入时刻。
具体而言，在评价目标系统的负载均衡能力时，可以通过目标系统在遇到故障时的业务恢复时长评价，恢复时长与负载均衡能力成反比，恢复时长越长，负载均衡能力越差，因此，负载均衡能力验证系统中的混沌工程平台需要记录故障注入时刻以及目标系统的故障恢复时刻，所以混沌工程平台下发目标故障注入事件的执行指令后，将下发目标故障注入事件的执行指令的时刻记录为故障注入时刻。
此时，上述步骤205包括：
步骤A1、监测目标系统的运行参数，在运行参数符合预设的正常运行参数的情况下，将目标系统的运行参数符合预设的正常运行参数的时刻作为故障恢复时刻。
其中，预设的正常运行参数是指目标系统在正常运行时的运行参数，例如，每秒业务数需要高于预设的每秒业务数，业务处理失败率需要小于预设的业务处理失败率，业务平均响应时间需要小于预设的业务平均响应时间。
具体而言，负载均衡能力验证系统下发目标故障注入事件的执行指令后，目标系统的运行参数会有所下降，例如每秒业务数降低、业务处理失败率升高、业务平均响应时间升高，然后，目标系统基于负载均衡配置，对发生故障的节点进行隔离，并将发生故障的节点运行的业务均衡至其他节点运行，目标系统的运行参数会缓慢上升，直至符合预设的正常运行参数，负载均衡能力验证系统监测目标系统的运行参数，在目标系统的运行参数符合预设的正常运行参数时，将目标系统的运行参数符合预设的正常运行参数的时刻作为故障恢复时刻。
步骤A2、基于故障注入时刻以及故障恢复时刻，确定目标系统的故障恢复时长。
具体而言，负载均衡能力验证系统得到故障注入时刻以及故障恢复时刻后，通过故障注入时刻以及故障恢复时刻，确定目标系统的故障恢复时长，例如，故障注入时刻为时刻A，故障恢复时刻为时刻B，故障恢复时长＝时刻B-时刻A。
步骤A3、比较故障恢复时长与预设的故障恢复指标值，确定目标系统的负载均衡能力验证结果。
其中，故障恢复指标值用于判断故障恢复时长对应的负载均衡能力验证结果，故障恢复指标值可以是一个，故障恢复时长高于指标值，则负载均衡能力验证结果为不通过，故障恢复时长低于指标值，则负载均衡能力验证结果为通过。故障恢复指标值可以是多个，将故障恢复时长划分至不同的负载均衡能力验证结果对应的故障恢复指标值区间，例如，故障恢复指标值包括A、B、C，若故障恢复时长在区间[0，A]中，那么负载均衡能力验证结果为结果1，若故障恢复时长在区间(A，B]中，那么负载均衡能力验证结果为结果2，若故障恢复时长在区间(B，C]中，那么负载均衡能力验证结果为结果3，若故障恢复时长大于C中，那么负载均衡能力验证结果为结果4。
具体而言，负载均衡能力验证系统得到目标系统在故障模拟场景下的故此回复时长后，比较故障恢复时长与预设的故障恢复指标值，得到目标系统此次的负载均衡能力验证结果。
在此实施例中，通过故障回复时长评价目标系统的负载均衡能力。
在其中一个实施例中，上述步骤205包括：
步骤B1、在目标系统模拟业务处理场景的情况下，对故障注入目标节点下发目标故障注入事件执行指令，获取目标系统的第一运行参数。
步骤B2、对故障注入目标节点下发目标故障注入事件执行指令预设时长后，获取目标系统当前的第二运行参数。
步骤B3、比较第一运行参数以及第二运行参数，确定目标系统的负载均衡能力验证结果。
具体而言，在评价目标系统的负载均衡能力时，可以通过目标系统在遇到故障的预设时长后，目标系统的运行参数是否能够符合预期，若符合预期，目标系统的负载均衡能力验证结果为通过，若不符合预期，目标系统的负载均衡能力验证结果为不通过。因此，在目标系统模拟业务处理场景的情况下，对故障注入目标节点下发目标故障注入事件执行指令时，负载均衡能力验证系统获取目标系统的第一运行参数，对故障注入目标节点下发目标故障注入事件执行指令预设时长后，获取目标系统当前的第二运行参数，比较第一运行参数以及第二运行参数，若第一运行参数与第二运行参数之间的差距过大，例如第一运行参数中的每秒交易数与第二运行参数中的每秒交易数之间的差值高于预设差值，那么第二运行参数未达到预期，目标系统的负载均衡能力验证结果为不通过，若第一运行参数与第二运行参数之间的在预设范围内，目标系统的负载均衡能力验证结果为通过。
以上仅为示例性给出的通过第一运行参数以及第二运行参数确定目标系统的负载均衡能力验证结果，实际应用中，还可以通过其他比较方式得到目标系统的负载均衡能力验证结果，此处不进行详细赘述。
在此实施例中，通过比较故障注入前以及故障注入后的运行参数，评价目标系统的负载均衡能力。
在其中一个实施例中，上述方法还包括：
步骤209、将下发目标故障注入事件的执行指令的时刻记录为故障注入时刻。
具体而言，在评价目标系统的负载均衡能力时，可以通过目标系统在遇到故障时，业务恢复至故障发生前的故障时长评价，恢复时长与负载均衡能力成反比，恢复时长越长，负载均衡能力越差，因此，负载均衡能力验证系统需要记录故障注入时刻以及目标系统恢复至故障发生前的故障恢复时刻，所以负载均衡能力验证系统下发目标故障注入事件的执行指令后，将下发目标故障注入事件的执行指令的时刻记录为故障注入时刻。
此时，上述步骤205包括：
步骤C1、在目标系统模拟业务处理场景的情况下，对故障注入目标节点下发目标故障注入事件执行指令，获取目标系统的第一运行参数。
具体而言，如上所述，在评价目标系统的负载均衡能力时，可以通过目标系统在遇到故障时，业务恢复至故障发生前的故障时长评价，因此，在目标系统模拟业务处理场景的情况下，对故障注入目标节点下发目标故障注入事件执行指令后，负载均衡能力验证系统需要获取目标系统的第一运行参数，以使负载均衡能力验证系统后续根据第一运行参数确定目标系统是否恢复至故障发生前的状态。
步骤C2、监测目标系统的运行参数，在运行参数与第一运行参数一致的情况下，将目标系统的运行参数与第一运行参数一致的时刻作为故障恢复时刻。
具体而言，负载均衡能力验证系统下发目标故障注入事件的执行指令后，目标系统的运行参数会有所下降，例如每秒业务数降低、业务处理失败率升高、业务平均响应时间升高，然后，目标系统基于负载均衡配置，对发生故障的节点进行隔离，并将发生故障的节点运行的业务均衡至其他节点运行，目标系统的运行参数会缓慢上升，直至与第一运行参数一致，负载均衡能力验证系统监测目标系统的运行参数，在目标系统的运行参数与第一运行参数一致时，将目标系统的运行参数与第一运行参数一致的时刻作为故障恢复时刻。
步骤C3、基于故障注入时刻以及所述故障恢复时刻，确定目标系统的故障恢复时长。
具体而言，负载均衡能力验证系统得到故障注入时刻以及故障恢复时刻后，通过故障注入时刻以及故障恢复时刻，确定目标系统的故障恢复时长，例如，故障注入时刻为时刻A，故障恢复时刻为时刻B，故障恢复时长＝时刻B-时刻A。
步骤C4、比较故障恢复时长与预设的故障恢复指标值，确定目标系统的负载均衡能力验证结果。
其中，故障恢复指标值用于判断故障恢复时长对应的负载均衡能力验证结果，故障恢复指标值可以是一个，故障恢复时长高于指标值，则负载均衡能力验证结果为不通过，故障恢复时长低于指标值，则负载均衡能力验证结果为通过。故障恢复指标值可以是多个，将故障恢复时长划分至不同的负载均衡能力验证结果对应的故障恢复指标值区间，例如，故障恢复指标值包括A、B、C，若故障恢复时长在区间[0，A]中，那么负载均衡能力验证结果为结果1，若故障恢复时长在区间(A，B]中，那么负载均衡能力验证结果为结果2，若故障恢复时长在区间(B，C]中，那么负载均衡能力验证结果为结果3，若故障恢复时长大于C中，那么负载均衡能力验证结果为结果4。
具体而言，负载均衡能力验证系统得到目标系统在故障模拟场景下的故此回复时长后，比较故障恢复时长与预设的故障恢复指标值，得到目标系统此次的负载均衡能力验证结果。
在此实施例中，通过目标系统恢复至故障注入前的运行参数的时长，评价目标系统的负载均衡能力。
在其中一个实施例中，在执行上述步骤203之前，上述方法还包括：
步骤211、读取目标系统的施压配置文件，确定目标系统的负载参数。
其中，施压配置文件记录有验证负载均衡能力时，目标系统的负载参数，负载参数是指目标系统模拟实际业务处理场景时的负载量，例如以目标系统最大处理能力的50％作为负载压力。
具体而言，目标系统在实际运行过程中，会有繁忙时段，也会有空闲时段，而目标系统的负载均衡能力在繁忙时段与空闲时段也会有所不同，繁忙时段空闲节点数量少，访问数量多，负载均衡能力相对较弱，空闲时段空闲节点数量多，访问数量少，负载均衡能力相对较弱，因此目标系统在不同的施压场景下，负载均衡能力验证结果也会有所不同，因此可以预先配置施压配置文件，负载均衡能力验证系统通过读取目标系统的施压配置文件，确定目标系统的负载参数。
步骤213、基于负载参数，创建虚拟用户访问所述目标系统，以使目标系统模拟业务处理场景。
具体而言，负载均衡能力验证系统确定此次验证的负载参数后，基于负载参数，创建虚拟用户访问所述目标系统，以使目标系统模拟在该负载参数下的业务处理场景。
在此实施例中，通过负载参数，模拟不同负载下目标系统的业务处理场景，以使更全面验证系统的负载均衡能力。
在其中一个实施例中，上述方法还包括：
步骤215、在目标系统模拟业务处理场景过程中，监测目标系统的运行参数。
具体而言，负载均衡能力验证系统在将故障注入前，需要保证目标系统已模拟实际业务处理并平稳运行，然后再将故障注入，因此在目标系统模拟业务处理场景过程中，负载均衡能力验证系统可以通过监测目标系统的运行参数，确定目标系统是否平稳运行。
此时，上述步骤203具体包括：
在目标系统的运行参数符合预设的运行参数指标值的时长到达预设的稳定运行时长的情况下，读取负载均衡能力验证配置文件，确定目标故障注入事件以及故障注入目标节点。
具体而言，负载均衡能力验证系统可以通过监测目标系统的运行参数，确定目标系统是否平稳运行，若目标系统的运行参数符合预设的运行参数指标值的时长到达预设的稳定运行时长时，认为目标系统在平稳运行，此时可模拟实际故障场景，进行故障注入，开始执行步骤201及后续步骤，即，读取负载均衡能力验证配置文件，确定目标故障注入事件以及故障注入目标节点。
在此实施例中，在进行故障注入前，通过监测目标系统的运行参数，确定目标系统已模拟业务场景下平稳地运行。
接下来，对本申请提供的一具体实施例进行详细的说明，如图4所示。
在对系统负载均衡能力验证前，预先做如下部署：
步骤1：创建混沌工程实验案例。创建过程包括：①填写实验名称、实验持续时间、实验描述；②选择实验机器；③添加具体混沌工程实验事件(事件类型：杀进程、暂停进程、网络丢包)，并配置各项参数(实验开始时间、结束时间、事件运行时间、目标应用节点IP、事件类型具体配置参数等)；④保存实验案例，等待执行。
步骤2：预设负载均衡能力验证的指标值。如负载均衡机制的故障节点隔离时间标准设置为1分钟，若实际故障节点隔离时间≤1分钟，则说明系统负载均衡能力有效；若实际故障节点隔离时间>1分钟，或超过10分钟系统故障节点无法被有效隔离，业务仍然无法恢复正常(如：期间的业务指标每秒交易数下降到正常水平的95％以下，交易失败率>1‰，平均响应时间超过300ms)，任何一项满足即说明系统的负载均衡能力无效。
步骤3：预设系统监控体系，用于观察和验证系统状态。在系统监控平台(如APM、ZABBIX、Prometheus、Grafana等)上，预设实验关注的各应用节点的基本资源情况(CPU利用率、内存占用率、IO使用率等)、与业务处理相关的指标(每秒交易数，交易失败率、平均响应时间等)。
步骤4：预设施压场景，模拟生产环境的业务处理。将某个系统应用集群作为实验的目标应用集群，通过LoadRunner、JMeter、APTS等测试工具，以目标应用集群最大处理能力的50％作为负载压力，如通过测试工具模拟客户端并发访问，模拟多个用户同时访问同一页面的多个请求、模拟用户批量注册或登录。
完成步骤1-步骤4的预先部署工作后，开始对系统负载均衡能力进行验证。
步骤5：施压场景稳定运行10分钟后，执行混沌工程实验案例，开始混沌工程实验。由底层混沌工具和预先安装在各应用节点中的Agent代理程序，对目标应用节点执行混沌工程实验事件，进行故障注入，在此期间的施压场景不间断，压力工具持续向目标应用集群发送交易请求，记录故障注入时刻T1。
步骤6：故障注入后，观察目标应用集群的业务处理情况。例如通过监控平台观察系统各类业务每秒交易数，交易失败率、平均响应时间是否如期出现了明显异常(如每秒交易数下降到正常水平的95％以下，交易失败率>1‰，平均响应时间超过300ms)。持续观察系统应用集群的各个应用节点的CPU利用率、内存占用率、IO使用率等基本资源情况和每秒交易数，交易失败率、平均响应时间等各业务指标，若经过一段时间后，各业务指标恢复到正常水平，且此时未注入故障的应用节点的CPU利用率、内存占用率、IO使用率相比故障注入之前均有所升高，此时记录时刻T2，计算实际负载均衡故障节点隔离时间(T2-T1)，并按照步骤2预设负载均衡能力验证的指标值，对系统的负载均衡机制进行验证。
步骤7：停止混沌工程实验案例，结束混沌工程实验，解除目标应用节点的故障注入(暂停进程和网络丢包故障场景会在停止混沌工程实验案例后自动解除故障注入并恢复应用节点服务，若故障场景为“杀进程”，则需要执行相应的业务启动脚本恢复应用节点服务)，施压场景持续运行10分钟，解除故障后的应用节点重现接管服务，观察各业务的恢复情况。
步骤8：记录实验结果数据和结论。
应该理解的是，虽然如上所述的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
基于同样的发明构思，本申请实施例还提供了一种用于实现上述所涉及的基于混沌工程的系统负载均衡能力验证方法的基于混沌工程的系统负载均衡能力验证装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个基于混沌工程的系统负载均衡能力验证装置实施例中的具体限定可以参见上文中对于基于混沌工程的系统负载均衡能力验证方法的限定，在此不再赘述。
在一个实施例中，如图4所示，提供了一种基于混沌工程的系统负载均衡能力验证装置400，所述装置400应用于待验证的目标系统，待验证的目标系统包含若干节点，该节点部署有故障事件模拟代理程序，该装置400包括：
读取模块401，用于在目标系统模拟业务处理场景的情况下，读取负载均衡能力验证配置文件，确定目标故障注入事件以及若干节点中的故障注入目标节点；
故障注入模块403，用于通过部署于故障注入目标节点的故障事件模拟代理程序，对故障注入目标节点下发目标故障注入事件的执行指令；
验证模块405，用于在目标故障注入事件执行过程中，监测目标系统的运行参数，确定目标系统的负载均衡能力验证结果。
在其中一个实施例中，负载均衡能力验证配置文件包括多个故障注入事件、故障注入事件在各节点中对应的故障注入目标节点和故障注入事件的开始时间。
在其中一个实施例中，上述装置400还包括：
第一故障注入时刻记录模块，用于将下发目标故障注入事件的执行指令的时刻记录为故障注入时刻；
此时，上述验证模块405包括：
第一故障恢复时刻记录单元，监测目标系统的运行参数，在运行参数符合预设的正常运行参数的情况下，将目标系统的运行参数符合预设的正常运行参数的时刻作为故障恢复时刻；
第一恢复时长确定单元，用于基于故障注入时刻以及故障恢复时刻，确定目标系统的故障恢复时长；
第一验证单元，用于比较故障恢复时长与预设的故障恢复指标值，确定目标系统的负载均衡能力验证结果。
在其中一个实施例中，上述验证模块405包括：
第一运行参数确定单元，用于在目标系统模拟业务处理场景的情况下，对故障注入目标节点下发目标故障注入事件执行指令，获取目标系统的第一运行参数；
第二运行参数确定单元，用于对故障注入目标节点下发目标故障注入事件执行指令预设时长后，获取目标系统当前的第二运行参数；
第二验证单元，用于比较第一运行参数以及第二运行参数，确定目标系统的负载均衡能力验证结果。
在其中一个实施例中，上述装置400还包括：
第二故障注入时刻记录模块，用于将下发目标故障注入事件的执行指令的时刻记录为故障注入时刻；
此时，上述验证模块405包括：
第三运行参数确定单元，在目标系统模拟业务处理场景的情况下，对故障注入目标节点下发目标故障注入事件执行指令，获取目标系统的第一运行参数；
第二恢复时长确定单元，用于监测目标系统的运行参数，在运行参数与第一运行参数一致的情况下，将目标系统的运行参数与第一运行参数一致的时刻作为故障恢复时刻；
第二恢复时长确定单元，用于基于故障注入时刻以及故障恢复时刻，确定目标系统的故障恢复时长；
第三验证单元，用于比较故障恢复时长与预设的故障恢复指标值，确定目标系统的负载均衡能力验证结果。
在其中一个实施例中，上述装置400还包括：
负载参数确定模块，用于读取目标系统的施压配置文件，确定目标系统的负载参数；
施压模块，用于基于负载参数，创建虚拟用户访问目标系统，以使目标系统模拟业务处理场景。
在其中一个实施例中，上述装置400还包括：
监测模块，用于在目标系统模拟业务处理场景过程中，监测目标系统的运行参数；
此时，上述读取模块401具体用于：
在目标系统的运行参数符合预设的运行参数指标值的时长到达预设的稳定运行时长的情况下，读取负载均衡能力验证配置文件，确定目标故障注入事件以及故障注入目标节点。
上述基于混沌工程的系统负载均衡能力验证装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图5所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作系统、计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于混沌工程的系统负载均衡能力验证方法。
本领域技术人员可以理解，图5中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
在一个实施例中，还提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。
在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。
在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。
需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-OnlyMemory，ROM)、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器(ReRAM)、磁变存储器(Magnetoresistive Random Access Memory，MRAM)、铁电存储器(Ferroelectric Random Access Memory，FRAM)、相变存储器(Phase Change Memory，PCM)、石墨烯存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器等。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic RandomAccess Memory，DRAM)等。本申请所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本申请所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。
Claims (10)
1.一种基于混沌工程的系统负载均衡能力验证方法，其特征在于，待验证的目标系统包含若干节点，所述节点部署有故障事件模拟代理程序，所述方法包括：
在所述目标系统模拟业务处理场景的情况下，读取负载均衡能力验证配置文件，确定目标故障注入事件以及所述若干节点中的故障注入目标节点；
通过部署于所述故障注入目标节点的故障事件模拟代理程序，对所述故障注入目标节点下发所述目标故障注入事件的执行指令；
在所述目标故障注入事件执行过程中，监测所述目标系统的运行参数，确定所述目标系统的负载均衡能力验证结果。
2.根据权利要求1所述的方法，其特征在于，所述负载均衡能力验证配置文件包括多个故障注入事件、所述故障注入事件在各节点中对应的故障注入目标节点和所述故障注入事件的开始时间。
3.根据权利要求1所述的方法，其特征在于，所述方法还包括：
将下发所述目标故障注入事件的执行指令的时刻记录为故障注入时刻；
所述在所述目标故障注入事件执行过程中，监测所述目标系统的运行参数，确定所述目标系统的负载均衡能力验证结果，包括：
监测所述目标系统的运行参数，在所述运行参数符合预设的正常运行参数的情况下，将所述目标系统的运行参数符合所述预设的正常运行参数的时刻作为故障恢复时刻；
基于所述故障注入时刻以及所述故障恢复时刻，确定所述目标系统的故障恢复时长；
比较所述故障恢复时长与预设的故障恢复指标值，确定所述目标系统的负载均衡能力验证结果。
4.根据权利要求1所述的方法，其特征在于，所述在所述目标故障注入事件执行过程中，监测所述目标系统的运行参数，确定所述目标系统的负载均衡能力验证结果，包括：
在所述目标系统模拟业务处理场景的情况下，对所述故障注入目标节点下发目标故障注入事件执行指令，获取所述目标系统的第一运行参数；
对所述故障注入目标节点下发目标故障注入事件执行指令预设时长后，获取所述目标系统当前的第二运行参数；
比较所述第一运行参数以及所述第二运行参数，确定所述目标系统的负载均衡能力验证结果。
5.根据权利要求1所述的方法，其特征在于，所述方法还包括：
将下发所述目标故障注入事件的执行指令的时刻记录为故障注入时刻；
所述在所述目标故障注入事件执行过程中，监测所述目标系统的运行参数，确定所述目标系统的负载均衡能力验证结果，包括：
在所述目标系统模拟业务处理场景的情况下，对所述故障注入目标节点下发目标故障注入事件执行指令，获取所述目标系统的第一运行参数；
监测所述目标系统的运行参数，在所述运行参数与所述第一运行参数一致的情况下，将所述目标系统的运行参数与所述第一运行参数一致的时刻作为故障恢复时刻；
基于所述故障注入时刻以及所述故障恢复时刻，确定所述目标系统的故障恢复时长；
比较所述故障恢复时长与预设的故障恢复指标值，确定所述目标系统的负载均衡能力验证结果。
6.根据权利要求1所述的方法，其特征在于，在所述读取负载均衡能力验证配置文件，确定目标故障注入事件以及所述若干节点中的故障注入目标节点之前，所述方法还包括：
读取所述目标系统的施压配置文件，确定所述目标系统的负载参数；
基于所述负载参数，创建虚拟用户访问所述目标系统，以使所述目标系统模拟业务处理场景。
7.根据权利要求6所述的方法，其特征在于，所述方法还包括：
在所述目标系统模拟业务处理场景过程中，监测所述目标系统的运行参数；
所述在所述目标系统模拟业务处理场景的情况下，读取负载均衡能力验证配置文件，确定目标故障注入事件以及所述若干节点中的故障注入目标节点，包括：
在所述目标系统的运行参数符合预设的运行参数指标值的时长到达预设的稳定运行时长的情况下，读取负载均衡能力验证配置文件，确定目标故障注入事件以及故障注入目标节点。
8.一种基于混沌工程的系统负载均衡能力验证装置，其特征在于，待验证的目标系统包含若干节点，所述节点部署有故障事件模拟代理程序，所述装置包括：
读取模块，用于在所述目标系统模拟业务处理场景的情况下，读取负载均衡能力验证配置文件，确定目标故障注入事件以及所述若干节点中的故障注入目标节点；
故障注入模块，用于通过部署于所述故障注入目标节点的故障事件模拟代理程序，对所述故障注入目标节点下发所述目标故障注入事件的执行指令；
验证模块，用于在所述目标故障注入事件执行过程中，监测所述目标系统的运行参数，确定所述目标系统的负载均衡能力验证结果。
9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述的方法的步骤。
10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311177011.2A CN117056081A (zh) | 2023-09-12 | 2023-09-12 | 基于混沌工程的系统负载均衡能力验证方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311177011.2A CN117056081A (zh) | 2023-09-12 | 2023-09-12 | 基于混沌工程的系统负载均衡能力验证方法和装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117056081A true CN117056081A (zh) | 2023-11-14 |
Family
ID=88662749
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311177011.2A Pending CN117056081A (zh) | 2023-09-12 | 2023-09-12 | 基于混沌工程的系统负载均衡能力验证方法和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117056081A (zh) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10986013B1 (en) * | 2019-09-26 | 2021-04-20 | Amazon Technologies, Inc. | Fault injection service |
| CN115271736A (zh) * | 2022-07-11 | 2022-11-01 | 中电金信软件有限公司 | 验证事务一致性的方法、装置、设备、存储介质及产品 |
| CN116405412A (zh) * | 2023-02-24 | 2023-07-07 | 中电金信软件有限公司 | 服务端集群的有效性验证方法和系统 |
-
2023
- 2023-09-12 CN CN202311177011.2A patent/CN117056081A/zh active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10986013B1 (en) * | 2019-09-26 | 2021-04-20 | Amazon Technologies, Inc. | Fault injection service |
| CN115271736A (zh) * | 2022-07-11 | 2022-11-01 | 中电金信软件有限公司 | 验证事务一致性的方法、装置、设备、存储介质及产品 |
| CN116405412A (zh) * | 2023-02-24 | 2023-07-07 | 中电金信软件有限公司 | 服务端集群的有效性验证方法和系统 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10152382B2 (en) | Method and system for monitoring virtual machine cluster | |
| CN111147322B (zh) | 5g核心网微服务架构的测试系统及方法 | |
| CN110618924B (zh) | 一种web应用系统的链路压力测试方法 | |
| Hamilton | On Designing and Deploying Internet-Scale Services. | |
| CN108351806A (zh) | 分布式基于流的数据库触发器 | |
| CN111881014B (zh) | 一种系统测试方法、装置、存储介质及电子设备 | |
| CN107357688A (zh) | 分布式系统及其故障恢复方法和装置 | |
| US9164857B2 (en) | Scalable structured data store operations | |
| CN110807064A (zh) | Rac分布式数据库集群系统中的数据恢复装置 | |
| WO2024078015A1 (zh) | 基于镜像对的故障注入方法、装置、设备和存储介质 | |
| CN106649000A (zh) | 实时处理引擎的故障恢复方法及相应的服务器 | |
| CN113312205B (zh) | 数据校验方法、装置、存储介质和计算机设备 | |
| CN116389233B (zh) | 容器云管理平台主备切换系统、方法、装置和计算机设备 | |
| CN112068935A (zh) | kubernetes程序部署监控方法、装置以及设备 | |
| CN114780325B (zh) | 一种PCIe设备检测方法及装置 | |
| CN117056081A (zh) | 基于混沌工程的系统负载均衡能力验证方法和装置 | |
| CN114996955A (zh) | 一种云原生混沌工程实验的靶场环境构建方法及装置 | |
| CN109254880A (zh) | 一种处理数据库宕机的方法及装置 | |
| CN113849364B (zh) | 一种边缘应用管理方法、装置、设备及可读存储介质 | |
| CN103095767B (zh) | 分布式缓存系统及基于分布式缓存系统的数据重构方法 | |
| CN112118294B (zh) | 一种基于服务端集群的请求处理方法、设备及介质 | |
| CN117971568A (zh) | 数据库切换方法、装置、设备、存储介质和程序产品 | |
| CN116089283A (zh) | 模拟准生产环境的监控测试方法、系统、设备和可读介质 | |
| CN116737177A (zh) | 应用程序的部署方法、装置、计算机设备和存储介质 | |
| CN118151850A (zh) | 数据存储方法、装置、计算机设备、存储介质 |
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 |