WO2023124314A1 - 混合cpu架构设备的微服务测试方法、系统及相关装置 - Google Patents

混合cpu架构设备的微服务测试方法、系统及相关装置 Download PDF

Info

Publication number
WO2023124314A1
WO2023124314A1 PCT/CN2022/121642 CN2022121642W WO2023124314A1 WO 2023124314 A1 WO2023124314 A1 WO 2023124314A1 CN 2022121642 W CN2022121642 W CN 2022121642W WO 2023124314 A1 WO2023124314 A1 WO 2023124314A1
Authority
WO
WIPO (PCT)
Prior art keywords
fault
microservice
cpu
traffic
node
Prior art date
Application number
PCT/CN2022/121642
Other languages
English (en)
French (fr)
Inventor
吕宪国
吴栋
Original Assignee
广东浪潮智慧计算技术有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 广东浪潮智慧计算技术有限公司 filed Critical 广东浪潮智慧计算技术有限公司
Publication of WO2023124314A1 publication Critical patent/WO2023124314A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2205—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested
    • G06F11/2236—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested to test CPU or processors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2247—Verification or detection of system hardware configuration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2273—Test methods
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network

Definitions

  • the present application relates to the field of servers, and in particular to a microservice testing method, system and related devices for mixed CPU architecture devices.
  • microservice systems are inherently interdependent, prone to errors, improper handling can easily lead to business damage, or other unpredictable abnormal behaviors, especially in recent years with multiple architecture CPUs (
  • Central Processing Unit/Processor central processing unit
  • This application provides a microservice testing method for mixed CPU architecture devices, including:
  • the fault code is used to simulate the fault handling of the network delay
  • the fault delay parameter is used to simulate the fault processing of the error report
  • determining the CPU architecture corresponding to the node to which the test request belongs includes:
  • the selected proxy image is used as an injection target
  • a proxy image of the same architecture as the single architecture is targeted for injection.
  • hijacking the traffic injected by the microservice on the CPU node, and performing fault detection based on the traffic includes:
  • processing the fault codes and/or fault delay parameters according to the traffic policy includes:
  • the traffic is delayed and forwarded to the upstream component, and the device stability is determined according to the processing behavior of the upstream component or the downstream component.
  • the fault code and/or fault delay parameter corresponding to the CPU architecture before determining the fault code and/or fault delay parameter corresponding to the CPU architecture, it also includes:
  • the traffic status after fault injection is displayed through the schematic diagram of the traffic topology relationship.
  • the proxy image before hijacking the injected microservice traffic on the CPU node after the fault code and/or fault delay parameter is injected by using the proxy image, it also includes:
  • the second aspect of the present application provides a microservice testing system for mixed CPU architecture devices, including:
  • a request receiving module configured to receive a test request
  • the architecture determination module is used to parse the test request and determine the CPU architecture corresponding to the node to which the test request belongs;
  • the fault preparation module is used to determine the fault code and/or fault delay parameter corresponding to the CPU architecture; the fault code is used to simulate the fault handling of the network delay, and the fault delay parameter is used to simulate the fault processing of the error report;
  • a fault injection module for injecting fault codes and/or fault delay parameters into the agent of the microservice on the CPU node
  • the fault test module is used to hijack the injected traffic of the microservice on the CPU node, and perform fault detection based on the traffic.
  • the third aspect of the present application provides a non-volatile computer-readable storage medium on which computer-readable instructions are stored.
  • the computer-readable instructions are executed by one or more processors, the above hybrid CPU architecture device is implemented.
  • the fourth aspect of the present application provides a server, including a memory and a processor, where computer-readable instructions are stored in the memory, and when the processor invokes the computer-readable instructions in the memory, the microservice test of the above hybrid CPU architecture device is implemented method steps.
  • Fig. 1 is a flowchart of a microservice testing method of a mixed CPU architecture device provided in one or more embodiments of the present application;
  • Fig. 2 is a flowchart of a microservice testing method for a device with a mixed CPU architecture provided in one or more embodiments of the present application.
  • Fig. 3 is a schematic structural diagram of a server provided in one or more embodiments of the present application.
  • FIG. 1 is a flow chart of a microservice testing method for a hybrid CPU architecture device provided in an embodiment of the present application. The method includes:
  • container microservices are run on different CPU architectures, and different microservices are deployed in Kubernetes clusters composed of machines with different CPU architectures to form a complete application system.
  • the user selects microservices deployed on different CPU architectures through the page to perform microservice governance and testing functions.
  • This step is intended to receive a test request, and the test request refers to a test for a microservice, usually for a microservice on a device with a mixed CPU architecture, so as to detect the fault handling capability of the microservice.
  • This embodiment can perform chaos testing.
  • chaos testing is an experimental and system-based method to verify and test the chaos problems in large-scale microservice systems. It is a testing method similar to "fault drill". The verification method helps the microservice application system in the production environment to run more stably.
  • the selected proxy image is used as an injection target
  • a proxy image of the same architecture as the single architecture is targeted for injection.
  • This step needs to determine the fault code and/or fault delay parameter corresponding to the CPU architecture.
  • the fault code is used to simulate the fault handling of network delay
  • the fault delay parameter is used to simulate the fault processing of error reporting. Both of them are used as Fault simulation for injection.
  • This step may include the configuration process of the fault code and/or fault delay parameters.
  • the fault code and/or fault delay parameters corresponding to the CPU architecture may be determined according to the user's operation instructions on the UI interface, or relevant instructions may be received directly. In this way, the fault code and/or fault delay parameter can be obtained by parsing.
  • S104 Inject the fault code and/or fault delay parameters into the agent of the microservice on the CPU node;
  • This step needs to inject the fault code and/or fault delay parameters into the agent of the microservice.
  • S105 Hijack the injected traffic of the microservice on the CPU node, and perform fault detection based on the traffic.
  • the traffic needs to be hijacked and forwarded to the upstream and downstream components to verify whether the fault handling mechanism of the upstream and downstream components is sound, thus completing the chaos test.
  • an executable method of this step may be as follows:
  • the first step is to use the proxy image to hijack the injected microservice traffic on the CPU node after the injected fault code and/or fault delay parameters;
  • the second step is to use the filter to read the traffic policy of the traffic
  • the third step is to process the fault code and/or fault delay parameters according to the traffic policy.
  • the proxy image is used to hijack the traffic passing through the microservice after fault injection, and before the first step is executed, the proxy image can be determined from the image repository according to the CPU architecture type corresponding to the microserver.
  • the proxy image select a proxy image that is compatible with the CPU architecture type from the mirror warehouse and inject it.
  • the difference between different agent architectures lies in the different compilation methods, so as to adapt to the instruction sets of different CPU architecture types.
  • This filter is used for fault simulation of hijacked traffic. It should be noted that the fault code and/or fault delay parameters need to be injected into the agent of the microservice, and the agent has a fixed CPU architecture, so it is possible to inject faults at the same time for a single microservice without involving CPUs of different architectures.
  • the fault here is equivalent to the fault code and/or fault delay parameter above.
  • the filter can be software or computer-readable instructions generated in advance by those skilled in the art to implement the above process.
  • corresponding processing methods are adopted for different traffic policies.
  • For fault codes generate corresponding error messages and return them to downstream components.
  • the fault delay parameter the traffic is delayed and forwarded to the upstream component, and the device stability is determined according to the processing behavior of the upstream component or the downstream component.
  • the above processing manner may be executed simultaneously.
  • the traffic status after the fault injection can also be displayed through the schematic diagram of the traffic topology relationship.
  • the UI interface can be used to display the schematic diagram of the traffic topology relationship of all microservice application systems, which can not only display the configuration and distribution of fault policies, but also display the detailed information of the traffic changes through each microservice after the fault is injected in real time. More preferably, different colors can be used to identify the pros and cons of different components for fault simulation, so that for components that do not handle faults, the business logic can be optimized to improve the ability of the system to apply sudden faults.
  • the microservice after receiving the test request, firstly determine the CPU architecture corresponding to the node to which the test request belongs, thereby determining the corresponding fault code and/or fault delay parameter for the CPU architecture, and can automatically identify the CPU architecture of the node where the microservice is located , Automatically implement differential injection of agents based on different CPU architectures, and set different failure strategies for chaos testing.
  • the microservice can be tested as a separate process, and the fault can be injected into the chaos test after the proxy hijacks the traffic.
  • This method can be injected into the microservice on different CPU architectures without modifying the business logic of the proxy, and the business itself Failure simulation of services can be realized without intrusion at all.
  • the implementation process is convenient and simple, and rapid chaos testing can be realized, which greatly saves manpower and time costs.
  • the actual number of fault codes and/or fault delay parameters injected can be configured according to the ratio of the number of test requests received and the number of requests. For example, if the ratio of requests is set to 40%, and 100 test requests are received, 40 of them will be injected with faults and returned to verify whether the application logic for fault handling is sound. In other words, if the request ratio is configured, each time a test request is received, the request ratio will be judged first, and if the current request ratio is not exceeded, the test request can be selected to be executed. And the test requests do not have to be executed sequentially in chronological order, it is only required to satisfy the ratio of the number of requests.
  • Step 1 The user deploys different components of the application to nodes with different CPU architectures on the kubernetes container cloud platform through the UI;
  • Step 2 Execute the microservice test, and inject the agent into the component differently in the sidecar mode through the proxy differential injection device according to the CPU architecture of the node where the component is located;
  • Step 3 Register the filter with fault simulation capability to the agent in step 2;
  • Step 4 Configure the failure strategy through the UI, that is, the failure code and/or failure delay parameters, and send it to the agent;
  • Step 5 When the traffic passes through the microservice component, the agent containing the filter is used to hijack the traffic, and the filter simulates the fault according to the configured fault ratio and strategy, and performs the chaos test;
  • Step 6 Use the UI to display the complete traffic topology of the application, and view the details of the traffic changes of the upstream and downstream components after the simulated failure displayed on the UI interface in real time.
  • both the agent differential injection device and the filter may be in the form of software, for example, run in the form of computer readable instructions or scripts.
  • the Sidecar mode is a design mode that separates some application functions from the application itself and runs as a separate process. This design mode allows many functions to be added to the application without the need for configuration of additional third-party components and modification of the application code itself.
  • microservice testing system for a hybrid CPU architecture device provided in the embodiment of the present application.
  • the microservice testing system described below and the microservice testing method for a hybrid CPU architecture device described above can be referred to in correspondence.
  • the present application also provides a microservice testing system for mixed CPU architecture devices, including
  • a request receiving module configured to receive a test request
  • the architecture determination module is used to parse the test request and determine the CPU architecture corresponding to the node to which the test request belongs;
  • the fault preparation module is used to determine the fault code and/or fault delay parameter corresponding to the CPU architecture; the fault code is used to simulate the fault handling of the network delay, and the fault delay parameter is used to simulate the fault processing of the error report;
  • a fault injection module configured to inject fault codes and/or fault delay parameters into the agent of the microservice on the CPU node
  • the fault test module is used to hijack the injected traffic of the microservice on the CPU node, and perform fault detection based on the traffic.
  • the architecture determination module includes:
  • the architecture determination unit is used to determine the corresponding CPU architecture according to the properties of the image corresponding to the current microservice; in response to the image supporting multiple architectures and the microservice execution node selection, the selected proxy image is used as the injection target; in response to the image supporting multiple One architecture, and the microservice does not perform node selection, select the proxy image that supports multiple architectures as the injection target; in response to the image supporting a single architecture, use the proxy image with the same architecture as the single architecture as the injection target.
  • the fault testing module includes:
  • the hijacking unit is used to hijack the injected microservice traffic on the CPU node after the fault code and/or fault delay parameters are injected by using the proxy image;
  • the policy reading unit is used to read the traffic policy of the traffic by using the filter
  • the fault setting unit is used for processing fault codes and/or fault delay parameters according to traffic policies.
  • the fault setting unit is a unit for performing the following steps:
  • the traffic is delayed and forwarded to the upstream component, and the device stability is determined according to the processing behavior of the upstream component or the downstream component.
  • the request ratio setting module is used to configure the request number ratio of the fault code and/or fault delay parameter.
  • the display module is used to display the traffic state after the fault injection through the schematic diagram of the traffic topology relationship.
  • the fault testing module also includes:
  • the image selection unit is configured to determine the proxy image from the image repository according to the CPU architecture type corresponding to the server.
  • the present application also provides a non-volatile computer-readable storage medium on which computer-readable instructions are stored.
  • the storage medium may include: various media that can store program codes such as U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disk.
  • the present application also provides a server, as shown in FIG. 3 , which may include a memory and a processor, where computer-readable instructions are stored in the memory, and when the processor invokes the computer-readable instructions in the memory, the server provided by the above-mentioned embodiments can be implemented.
  • the server may also include components such as various network interfaces and power supplies.
  • each embodiment in the description is described in a progressive manner, each embodiment focuses on the difference from other embodiments, and the same and similar parts of each embodiment can be referred to each other.
  • the description is relatively simple, and for relevant details, please refer to the description of the method part.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

本申请提供一种混合CPU架构设备的微服务测试方法，包括：接收测试请求；解析测试请求，确定测试请求所属节点对应的CPU架构；确定CPU架构对应的故障码和/或故障延时参数；故障码用于模拟对网络延迟的故障处理，故障延时参数用于模拟报错的故障处理；将故障码和/或故障延时参数注入至CPU节点上微服务的代理；劫持CPU节点上微服务被注入后的流量，并基于流量进行故障处理检测。

Description

混合CPU架构设备的微服务测试方法、系统及相关装置
相关申请的交叉引用
本申请要求于2021年12月31日提交中国专利局，申请号为202111675291.0，申请名称为“混合CPU架构设备的微服务测试方法、系统及相关装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及服务器领域，尤其涉及一种混合CPU架构设备的微服务测试方法、系统及相关装置。
背景技术
随着云原生技术的不断发展，不断推进微服务进一步解耦，越来越多的应用系统不断进行微服务改造部署在以kubernetes为代表的容器云平台上。然而，发明人意识到，微服务系统天生有着各种相互依赖，容易发生错误，处理不当容易导致业务受损，或者是其他各种无法预期的异常行为，特别是近几年多种架构CPU(Central Processing Unit/Processor，中央处理器)芯片的推出，越来越多的用户希望能将应用通过微服务化的方式将系统部署在多种不同的CPU架构的平台上，不同的CPU架构加大了不同微服务之间通信产生无法预知异常的风险，对于服务系统的稳定运行提出了更大的挑战。
发明内容
本申请提供了一种混合CPU架构设备的微服务测试方法，包括：
接收测试请求；
解析测试请求，确定测试请求所属节点对应的CPU架构；
确定CPU架构对应的故障码和/或故障延时参数；故障码用于模拟对网络延 迟的故障处理，故障延时参数用于模拟报错的故障处理；
将故障码和/或故障延时参数注入至CPU节点上微服务的代理；及
劫持CPU节点上微服务被注入后的流量，并基于流量进行故障处理检测。
在其中一些实施例中，确定测试请求所属节点对应的CPU架构包括：
根据当前微服务对应镜像的属性确定对应的CPU架构；
响应于镜像支持多种架构，且微服务执行节点选择，将已选择的代理镜像作为注入目标；
响应于镜像支持多种架构，且微服务未执行节点选择，选择支持多种架构的代理镜像作为注入目标；及
响应于镜像支持单一架构，将与单一架构相同架构的代理镜像作为注入目标。
在其中一些实施例中，劫持CPU节点上微服务注入后的流量，并基于流量进行故障处理检测包括：
利用代理镜像劫持被注入故障码和/或故障延时参数后CPU节点上被注入后微服务的流量；
利用过滤器读取流量的流量策略；及
根据流量策略进行处理故障码和/或故障延时参数。
在其中一些实施例中，根据流量策略进行处理故障码和/或故障延时参数包括：
对于故障码，生成对应的报错信息返回到下游组件；及
对于故障延时参数，对流量进行延迟处理后转发至上游组件，根据上游组件或下游组件对流量的处理行为确定设备稳定性。
在其中一些实施例中，确定CPU架构对应的故障码和/或故障延时参数之前，还包括：
配置故障码和/或故障延时参数的请求数比例；
则将故障码和/或故障延时参数注入至CPU节点上微服务的代理时，还包括：及
按照测试请求的接收次数和请求数比例配置实际注入故障码和/或故障延时参数的次数。
在其中一些实施例中，劫持CPU节点上微服务注入后的流量，并基于流量 进行故障处理检测之后，还包括：
通过流量拓扑关系示意图显示故障注入后的流量状态。
在其中一些实施例中，利用代理镜像劫持被注入故障码和/或故障延时参数后CPU节点上被注入后微服务的流量之前，还包括：
根据为服务器对应的CPU架构类型从镜像仓库中确定代理镜像。
本申请的第二方面，提供了一种混合CPU架构设备的微服务测试系统，包括：
请求接收模块，用于接收测试请求；
架构确定模块，用于解析测试请求，确定测试请求所属节点对应的CPU架构；
故障准备模块，用于确定CPU架构对应的故障码和/或故障延时参数；故障码用于模拟对网络延迟的故障处理，故障延时参数用于模拟报错的故障处理；
故障注入模块，用于将故障码和/或故障延时参数注入至CPU节点上微服务的代理；及
故障测试模块，用于劫持CPU节点上微服务被注入后的流量，并基于流量进行故障处理检测。
本申请的第三方面，提供了一种非易失性计算机可读存储介质，其上存储有计算机可读指令，计算机可读指令被一个或多个处理器执行时实现如上混合CPU架构设备的微服务测试的方法的步骤。
本申请的第四方面，提供了一种服务器，包括存储器和处理器，存储器中存有计算机可读指令，处理器调用存储器中的计算机可读指令时实现如上混合CPU架构设备的微服务测试的方法的步骤。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本申请一个或多个实施例中提供的一种混合CPU架构设备的微服务 测试方法的流程图；
图2为本申请一个或多个实施例中提供的一种混合CPU架构设备的微服务测试方法的流程图。
图3为本申请一个或多个实施例中提供的一种服务器的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
请参考图1，图1为本申请实施例所提供的一种混合CPU架构设备的微服务测试方法的流程图，该方法包括：
S101：接收测试请求；
通常，不同CPU架构上运行容器微服务，在由不同CPU架构的机器组成Kubernetes集群中部署不同的微服务组成一个完整应用系统。而用户通过页面选择微服务部署在不同CPU架构上的应用，以便执行微服务治理和测试功能。
本步骤旨在接收测试请求，该测试请求指针对于微服务的测试，通常针对于混合CPU架构设备上的微服务，以检测该微服务的故障处理能力。本实施例可执行混沌测试，所谓混沌测试，是一种可试验的、基于系统的方法来验证和测试大规模微服务系统中的混乱问题一种类似于“故障演练”的测试方式，通过实证的验证方法帮助生产环境的微服务应用系统能更稳定的运行。
S102：解析测试请求，确定测试请求所属节点对应的CPU架构；
本步骤需要确定测试请求所属节点对应的CPU架构，具体的，根据当前微服务对应镜像的属性确定对应的CPU架构：
响应于镜像支持多种架构，且微服务执行节点选择，将已选择的代理镜像作为注入目标；
响应于镜像支持多种架构，且微服务未执行节点选择，选择支持多种架构的 代理镜像作为注入目标；
响应于镜像支持单一架构，将与单一架构相同架构的代理镜像作为注入目标。
S103：确定CPU架构对应的故障码和/或故障延时参数；
本步骤需要确定该CPU架构对应的故障码和/或故障延时参数，其中，故障码用于模拟对网络延迟的故障处理，故障延时参数用于模拟报错的故障处理，二者均作为用于注入的故障模拟。
本步骤可以包含对于故障码和/或故障延时参数的配置过程，例如可以根据用户在UI界面的操作指令确定CPU架构对应的故障码和/或故障延时参数，也可以直接接收相关指令，从而解析得到故障码和/或故障延时参数。
S104：将故障码和/或故障延时参数注入至CPU节点上微服务的代理；
本步骤需要将故障码和/或故障延时参数注入至微服务的代理。
S105：劫持CPU节点上微服务被注入后的流量，并基于流量进行故障处理检测。
在注入故障后，需要劫持流量并转发至上游组件和下游组件，以验证上游组件和下游组件对于故障的处理机制是否健全，从而完成混沌测试。
作为一种优选的执行方式，本步骤的一种可执行方式可以如下：
第一步、利用代理镜像劫持被注入故障码和/或故障延时参数后CPU节点上被注入后微服务的流量；
第二步、利用过滤器读取流量的流量策略；
第三步、根据流量策略进行处理故障码和/或故障延时参数。
该代理镜像用于劫持故障注入后经过微服务的流量，而在执行第一步前，可以先根据微服务器对应的CPU架构类型从镜像仓库中确定代理镜像。需要注入代理时，从镜像仓库中选择与CPU架构类型适配的代理镜像再进行注入。不同的代理架构的区别在于编译方式不同，从而适配不同CPU架构类型的指令集。
该过滤器用于对劫持的流量进行故障模拟。需要注意的是，该故障码和/或故障延时参数需要注入到微服务的代理上，而代理为固定的CPU架构，因此可以对于单个微服务不涉及不同架构的CPU同时注入故障。此处故障等同于上文的故障码和/或故障延时参数。该过滤器可以为本领域技术人员事先生成的软件或者计算机可读指令，用于实现上文的过程。
在劫持流量前，可以先请求应用服务，从而制造流量经过已注入故障的微服务，通过流量验证微服务的上下游是否对故障进行处理。
在第三步中，分别对于不同的流量策略采用相应的处理方式。对于故障码，生成对应的报错信息返回到下游组件。而对于故障延时参数，对流量进行延迟处理后转发至上游组件，根据上游组件或下游组件对流量的处理行为确定设备稳定性。响应于流量策略同时包含故障码和故障延时参数，可同时执行上文的处理方式。
特别的，在劫持CPU节点上微服务被注入后的流量后，还可以通过流量拓扑关系示意图显示故障注入后的流量状态。具体的，可以利用UI界面展示全部微服务应用系统的流量拓扑关系示意图，不仅可以显示故障策略的配置和下发，还能实时展示注入故障后经过各微服务的流量变化的详细信息。更优选的，还可以采用不同的颜色标识不同组件对故障模拟的处理优劣程度，以便对于对故障没有进行处理的组件，可以针对性的优化业务逻辑以提升系统应用突发故障的能力。
本申请实施例通过在接收测试请求，首先确定测试请求所属节点对应的CPU架构，从而针对该CPU架构确定相应的故障码和/或故障延时参数，能够进行自动识别微服务所在节点的CPU架构，自动实现基于不同CPU架构代理的差分注入，设置不同的故障策略，以便进行混沌测试。同时能够将微服务作为单独进程进行测试，在代理劫持流量后对故障进行注入进行混沌测试，该方法无需对代理进行业务逻辑的改造就可注入到不同cpu架构上的微服务里，对业务本身完全没有侵入就可实现对业务的故障模拟。同时实施过程方便、简单，可实现快速的混沌测试，极大的节省了人力和时间成本。
在上述实施例的基础上，作为本申请的一种优选执行方式，还可以在确定CPU架构对应的故障码和/或故障延时参数之前，事先配置故障码和/或故障延时参数的请求数比例；
则在将故障码和/或故障延时参数注入至CPU节点上微服务的代理时，可以按照测试请求的接收次数和请求数比例配置实际注入故障码和/或故障延时参数的次数。举例而言，若请求数比例配置为40％，且接收到100个测试请求，那么其中的40个请求会被注入故障并返回，以验证应用对故障处理的逻辑是否健全。换言之，若配置了请求数比例，则每次接收到测试请求后，先执行请求数比例的 判断，若未超过当前的请求数比例，可以选择执行该测试请求。且该测试请求并不必须按照时间顺序依次执行，仅要求满足该请求数比例即可。
下文以用户角度对本申请的一种可执行过程进行补充说明：
步骤1.用户通过UI在kubernetes容器云平台上将应用的不同组件部署到不同CPU架构的节点；
步骤2.执行微服务测试，通过代理差分注入装置根据组件所在节点的CPU架构将代理以sidecar模式有差别的注入到组件中；
步骤3.将具备故障模拟能力的过滤器注册到步骤2中的代理中；
步骤4.通过UI配置故障策略，也即故障码和/或故障延时参数，下发到代理中；
步骤5.流量经过微服务组件时，利用包含过滤器的代理对流量进行劫持，过滤器根据配置的故障比例和策略进行模拟故障，进行混沌测试；
步骤6.利用UI展示应用完整的流量拓扑，并实时查看UI界面显示的模拟故障后上游、下游组件的流量变化详情。
本实施例中，该代理差分注入装置和过滤器均可以为软件形式，例如以计算机可读指令或者脚本方式运行。而Sidecar模式是一种将一部分应用功能从应用本身剥离出来作为单独进程来运行的设计模式，这种设计模式允许为应用程序添加许多功能，而无需额外第三方组件的配置和应用本身代码的修改
下面对本申请实施例提供的混合CPU架构设备的微服务测试系统进行介绍，下文描述的微服务测试系统与上文描述的混合CPU架构设备的微服务测试方法可相互对应参照。
参见图2，本申请还提供一种混合CPU架构设备的微服务测试系统，包
请求接收模块，用于接收测试请求；
架构确定模块，用于解析测试请求，确定测试请求所属节点对应的CPU架构；
故障准备模块，用于确定CPU架构对应的故障码和/或故障延时参数；故障码用于模拟对网络延迟的故障处理，故障延时参数用于模拟报错的故障处理；
故障注入模块，用于将故障码和/或故障延时参数注入至CPU节点上微服务的代理；
故障测试模块，用于劫持CPU节点上微服务被注入后的流量，并基于流量进行故障处理检测。
基于上述实施例，作为优选的实施例，架构确定模块包括：
架构确定单元，用于根据当前微服务对应镜像的属性确定对应的CPU架构；响应于镜像支持多种架构，且微服务执行节点选择，将已选择的代理镜像作为注入目标；响应于镜像支持多种架构，且微服务未执行节点选择，选择支持多种架构的代理镜像作为注入目标；响应于镜像支持单一架构，将与单一架构相同架构的代理镜像作为注入目标。
基于上述实施例，作为优选的实施例，故障测试模块包括：
劫持单元，用于利用代理镜像劫持被注入故障码和/或故障延时参数后CPU节点上被注入后微服务的流量；
策略读取单元，用于利用过滤器读取流量的流量策略；
故障设置单元，用于根据流量策略进行处理故障码和/或故障延时参数。
基于上述实施例，作为优选的实施例，故障设置单元为用于执行如下步骤的单元：
对于故障码，生成对应的报错信息返回到下游组件；
对于故障延时参数，对流量进行延迟处理后转发至上游组件，根据上游组件或下游组件对流量的处理行为确定设备稳定性。
基于上述实施例，作为优选的实施例，还包括：
请求比例设定模块，用于配置故障码和/或故障延时参数的请求数比例。
基于上述实施例，作为优选的实施例，还包括：
显示模块，用于通过流量拓扑关系示意图显示故障注入后的流量状态。
基于上述实施例，作为优选的实施例，故障测试模块还包括：
镜像选择单元，用于根据为服务器对应的CPU架构类型从镜像仓库中确定代理镜像。
本申请还提供了一种非易失性计算机可读存储介质，其上存有计算机可读指令，该计算机可读指令被执行时可以实现上述实施例所提供的步骤。该存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储 程序代码的介质。
本申请还提供了一种服务器，如图3所示，可以包括存储器和处理器，存储器中存有计算机可读指令，处理器调用存储器中的计算机可读指令时，可以实现上述实施例所提供的步骤。当然服务器还可以包括各种网络接口，电源等组件。
说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例提供的系统而言，由于其与实施例提供的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。
还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (20)

  1. 一种混合CPU架构设备的微服务测试方法，其特征在于，包括：
    接收测试请求；
    解析所述测试请求，确定所述测试请求所属节点对应的CPU架构；
    确定所述CPU架构对应的故障码和/或故障延时参数；所述故障码用于模拟对网络延迟的故障处理，所述故障延时参数用于模拟报错的故障处理；
    将所述故障码和/或所述故障延时参数注入至所述CPU节点上微服务的代理；及
    劫持所述CPU节点上所述微服务被注入后的流量，并基于所述流量进行故障处理检测。
  2. 根据权利要求1所述的微服务测试方法，其特征在于，确定所述测试请求所属节点对应的CPU架构包括：
    根据当前微服务对应镜像的属性确定对应的CPU架构；
    响应于所述镜像支持多种架构，且所述微服务执行节点选择，将已选择的代理镜像作为注入目标；
    响应于所述镜像支持多种架构，且所述微服务未执行节点选择，选择支持多种架构的代理镜像作为注入目标；及
    响应于所述镜像支持单一架构，将与所述单一架构相同架构的代理镜像作为注入目标。
  3. 根据权利要求1所述的微服务测试方法，其特征在于，劫持所述CPU节点上微服务注入后的流量，并基于所述流量进行故障处理检测包括：
    利用代理镜像劫持被注入所述故障码和/或故障延时参数后所述CPU节点上被注入后所述微服务的流量；
    利用过滤器读取所述流量的流量策略；及
    根据所述流量策略进行处理所述故障码和/或故障延时参数。
  4. 根据权利要求3所述的微服务测试方法，其特征在于，根据所述流量策略进行处理所述故障码和/或故障延时参数包括：
    对于所述故障码，生成对应的报错信息返回到下游组件；及
    对于所述故障延时参数，对所述流量进行延迟处理后转发至上游组件，根据所述上游组件或所述下游组件对所述流量的处理行为确定设备稳定性。
  5. 根据权利要求1所述的微服务测试方法，其特征在于，确定所述CPU架构对应的故障码和/或故障延时参数之前，还包括：
    配置所述故障码和/或所述故障延时参数的请求数比例。
  6. 根据权利要求1所述的微服务测试方法，其特征在于，劫持所述CPU节点上微服务注入后的流量，并基于所述流量进行故障处理检测之后，还包括：
    通过流量拓扑关系示意图显示故障注入后的流量状态。
  7. 根据权利要求1所述的微服务测试方法，其特征在于，所述接收测试请求，包括：
    接收针对于微服务的测试请求；所述测试请求用以检测微服务的故障处理能力。
  8. 根据权利要求7所述的微服务测试方法，其特征在于，所述微服务在多个不同的CPU架构上运行。
  9. 根据权利要求8所述的微服务测试方法，其特征在于，所述多个不同的CPU架构位于相应的多个不同机器；
    所述多个不同机器组成Kubernetes集群，用以部署不同的所述微服务进而组成一个完整应用系统。
  10. 根据权利要求1所述的微服务测试方法，其特征在于，确定所述CPU架构对应的故障码和/或故障延时参数，还包括：
    根据用户在UI界面的操作指令确定CPU架构对应的故障码和/或故障延时参数；或
    在接收相关指令后，解析获得故障码和/或故障延时参数。
  11. 根据权利要求1所述的微服务测试方法，其特征在于，所述故障码和故障延时参数均作为用于注入故障的模拟。
  12. 根据权利要求3所述的微服务测试方法，其特征在于，利用代理镜像劫持被注入所述故障码和/或故障延时参数后所述CPU节点上被注入后所述微服务的流量之前，还包括：
    根据所述微服务器对应的CPU架构类型从镜像仓库中确定所述代理镜像。
  13. 根据权利要求3所述的微服务测试方法，其特征在于，利用代理镜像劫持被注入所述故障码和/或故障延时参数后所述CPU节点上被注入后所述微服务的流量之时，还包括：
    从镜像仓库中选择与所述CPU架构类型适配的代理镜像再进行注入。
  14. 根据权利要求3所述的微服务测试方法，其特征在于，在利用代理镜像劫持所述CPU节点上微服务注入后的流量之前，还包括：
    请求应用服务，用以制造流量经过已注入故障的微服务；及
    验证所述微服务的上下游，用以判断是否对故障进行处理。
  15. 根据权利要求3所述的微服务测试方法，其特征在于，在劫持所述CPU节点上微服务注入后的流量之后，还包括：
    采用多种不同的颜色标识来标识多种不同组件对故障模拟的处理优劣程度，用以检测出没有处理的组件。
  16. 根据权利要求1所述的微服务测试方法，其特征在于，确定所述CPU架构对应的故障码和/或故障延时参数之前，还包括：
    配置故障码和/或故障延时参数的比例。
  17. 根据权利要求1所述的微服务测试方法，其特征在于，在将故障码和/或故障延时参数注入至CPU节点上微服务的代理时，还包括：
    按照测试请求的接收次数和请求数比例配置实际注入故障码和/或故障延时参数的次数。
  18. 一种混合CPU架构设备的微服务测试系统，其特征在于，包括：
    请求接收模块，用于接收测试请求；
    架构确定模块，用于解析所述测试请求，确定所述测试请求所属节点对应的CPU架构；
    故障准备模块，用于确定所述CPU架构对应的故障码和/或故障延时参数；所述故障码用于模拟对网络延迟的故障处理，所述故障延时参数用于模拟报错的故障处理；
    故障注入模块，用于将所述故障码和/或故障延时参数注入至所述CPU节点上微服务的代理；及
    故障测试模块，用于劫持所述CPU节点上所述微服务被注入后的流量，并 基于所述流量进行故障处理检测。
  19. 一种非易失性计算机可读存储介质，其上存储有计算机可读指令，其特征在于，所述计算机可读指令被一个或多个处理器执行时实现如权利要求1-17任一项所述的混合CPU架构设备的微服务测试方法的步骤。
  20. 一种服务器，其特征在于，包括存储器和一个或多个处理器，所述存储器中存有计算机可读指令，所述处理器调用所述存储器中的计算机可读指令时实现如权利要求1-17任一项所述的混合CPU架构设备的微服务测试方法的步骤。
PCT/CN2022/121642 2021-12-31 2022-09-27 混合cpu架构设备的微服务测试方法、系统及相关装置 WO2023124314A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111675291.0A CN114461465A (zh) 2021-12-31 2021-12-31 混合cpu架构设备的微服务测试方法、系统及相关装置
CN202111675291.0 2021-12-31

Publications (1)

Publication Number Publication Date
WO2023124314A1 true WO2023124314A1 (zh) 2023-07-06

Family

ID=81407244

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/121642 WO2023124314A1 (zh) 2021-12-31 2022-09-27 混合cpu架构设备的微服务测试方法、系统及相关装置

Country Status (2)

Country Link
CN (1) CN114461465A (zh)
WO (1) WO2023124314A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114461465A (zh) * 2021-12-31 2022-05-10 广东浪潮智慧计算技术有限公司 混合cpu架构设备的微服务测试方法、系统及相关装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200174915A1 (en) * 2017-11-20 2020-06-04 International Business Machines Corporation Emulation-based testing of a microservices architecture
CN112333096A (zh) * 2020-10-16 2021-02-05 济南浪潮数据技术有限公司 一种微服务流量调度方法及相关组件
CN112765030A (zh) * 2021-01-22 2021-05-07 中信银行股份有限公司 测试方法、装置、电子设备及计算机存储介质
CN113157577A (zh) * 2021-04-27 2021-07-23 中国工商银行股份有限公司 一种PaaS云平台故障测试方法及装置
CN114461465A (zh) * 2021-12-31 2022-05-10 广东浪潮智慧计算技术有限公司 混合cpu架构设备的微服务测试方法、系统及相关装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200174915A1 (en) * 2017-11-20 2020-06-04 International Business Machines Corporation Emulation-based testing of a microservices architecture
CN112333096A (zh) * 2020-10-16 2021-02-05 济南浪潮数据技术有限公司 一种微服务流量调度方法及相关组件
CN112765030A (zh) * 2021-01-22 2021-05-07 中信银行股份有限公司 测试方法、装置、电子设备及计算机存储介质
CN113157577A (zh) * 2021-04-27 2021-07-23 中国工商银行股份有限公司 一种PaaS云平台故障测试方法及装置
CN114461465A (zh) * 2021-12-31 2022-05-10 广东浪潮智慧计算技术有限公司 混合cpu架构设备的微服务测试方法、系统及相关装置

Also Published As

Publication number Publication date
CN114461465A (zh) 2022-05-10

Similar Documents

Publication Publication Date Title
US10489283B2 (en) Software defect reporting
CN105099811B (zh) 一种接口测试方法和装置
US20170300402A1 (en) Mock server and extensions for application testing
CN102419729B (zh) 并行测试执行
CN107241315B (zh) 银行网关接口的接入方法、装置及计算机可读存储介质
CN105389256A (zh) 一种单元测试方法及系统
CN104765678A (zh) 对移动终端设备上的应用进行测试的方法及装置
US10452522B1 (en) Synthetic data generation from a service description language model
WO2020086969A1 (en) Methods and systems for performance testing
CN110955409B (zh) 在云平台上创建资源的方法和装置
WO2023024251A1 (zh) 模块验证方法、uvm验证平台、电子设备及存储介质
CN113572726B (zh) 一种多模态网络控制-数据平面一致性校验方法及装置
CN108459850B (zh) 生成测试脚本的方法、装置及系统
US10552306B2 (en) Automated test generation for multi-interface and multi-platform enterprise virtualization management environment
CN111859832B (zh) 一种芯片仿真验证方法、装置及相关设备
CN108111364B (zh) 一种业务系统的测试方法及装置
WO2023124314A1 (zh) 混合cpu架构设备的微服务测试方法、系统及相关装置
CN112650689A (zh) 测试方法、装置、电子设备及存储介质
CN113485927A (zh) 一种测试数据生成方法、装置、设备及存储介质
CN109388420A (zh) 应用升级测试方法、装置、计算机设备及存储介质
CN116056126A (zh) 仿真测试方法、装置、计算机设备和计算机可读存储介质
CN110888800A (zh) 服务交互功能的测试方法、装置、存储介质及测试系统
US9329960B2 (en) Methods, systems, and computer readable media for utilizing abstracted user-defined data to conduct network protocol testing
CN117873858A (zh) 用于前端页面测试的模拟数据生成方法及计算设备
Lübke Unit testing BPEL compositions

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22913579

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE