Microservice testing method, system and related device for hybrid CPU architecture device

Abstract

The present application provides a microservice testing method for a hybrid CPU architecture device, including: receiving a test request; parsing the test request to determine the CPU architecture corresponding to the node to which the test request belongs; determining 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 delays, and the fault delay parameter is used to simulate the fault handling of error reports; injecting the fault code and / or fault delay parameter into the agent of the microservice on the CPU node; hijacking the traffic after the microservice on the CPU node is injected, and performing fault handling detection based on the traffic. The implementation process of the present application is convenient, and there is no need to make any modifications to the container microservice application system deployed on different CPU architectures, so as to achieve fast chaos testing, which greatly saves manpower and time costs. The present application also provides a microservice testing system, a computer-readable storage medium and a server for a hybrid CPU architecture device, which have the above-mentioned beneficial effects.

Description

Technical Field

[0001] The present application relates to the field of servers, and in particular to a microservice testing method, system and related apparatus for a hybrid CPU architecture device. Background Art

[0002] With the continuous development of cloud-native technology, microservices are further decoupled. More and more application systems are constantly undergoing microservice transformation and deployed on container cloud platforms represented by Kubernetes. However, microservice systems are inherently interdependent and prone to errors. Improper handling can easily lead to business damage or other unexpected abnormal behaviors. Especially with the launch of CPU chips with various architectures in recent years, more and more users hope to deploy their applications on platforms with various CPU architectures through microservices. Different CPU architectures increase the risk of unpredictable anomalies in communications between different microservices, posing greater challenges to the stable operation of the service system. Summary of the invention

[0003] The purpose of this application is to provide a microservice testing method, a microservice testing system, a computer-readable storage medium and a server for a hybrid CPU architecture device, which can perform microservice testing on a hybrid CPU architecture device to ensure the stability of the hybrid CPU architecture device running microservices.

[0004] In order to solve the above technical problems, the present application provides a microservice testing method for a hybrid CPU architecture device, and the specific technical solution is as follows:

[0005] Receive test requests;

[0006] Parsing the test request to determine the CPU architecture corresponding to the node to which the test request belongs;

[0007] 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, and the fault delay parameter is used to simulate the fault handling of error reporting;

[0008] Injecting the fault code and / or fault delay parameter into the agent of the microservice on the CPU node;

[0009] Hijack the traffic of the microservice injected on the CPU node, and perform fault handling detection based on the traffic.

[0010] Optionally, determining the CPU architecture corresponding to the node to which the test request belongs includes:

[0011] Determine the corresponding CPU architecture based on the properties of the image corresponding to the current microservice;

[0012] If the image supports multiple architectures and the microservice performs node selection, the selected proxy image is used as the injection target;

[0013] If the image supports multiple architectures and the microservice does not perform node selection, select a proxy image that supports multiple architectures as the injection target;

[0014] If the image supports a single architecture, a proxy image with the same architecture as the single architecture is used as an injection target.

[0015] Optionally, hijacking the traffic injected by the microservice on the CPU node and performing fault processing detection based on the traffic includes:

[0016] Hijacking the flow of the microservice injected into the CPU node after the fault code and / or fault delay parameter is injected by using a proxy image;

[0017] Using the filter to read the traffic policy of the traffic;

[0018] The fault code and / or fault delay parameter are processed according to the traffic strategy.

[0019] Optionally, processing the fault code and / or fault delay parameter according to the traffic strategy includes:

[0020] For the fault code, generate corresponding error information and return it to the downstream component;

[0021] For the fault delay parameter, the traffic is delayed and then forwarded to an upstream component, and the device stability is determined based on the processing behavior of the upstream component or the downstream component on the traffic.

[0022] Optionally, before determining the fault code and / or fault delay parameter corresponding to the CPU architecture, the method further includes:

[0023] a ratio of the number of requests for configuring the fault code and / or the fault delay parameter;

[0024] When injecting the fault code and / or fault delay parameter into the agent of the microservice on the CPU node, it also includes:

[0025] The number of times the fault code and / or fault delay parameter are actually injected is configured according to the number of times the test request is received and the ratio of the number of requests.

[0026] Optionally, after hijacking the traffic injected by the microservice on the CPU node and performing fault processing detection based on the traffic, the method further includes:

[0027] The traffic topology diagram shows the traffic status after fault injection.

[0028] Optionally, the method of hijacking the CPU node after the fault code and / or fault delay parameter is injected and before the traffic of the microservice is injected by using a proxy image, further includes:

[0029] The proxy image is determined from an image repository according to the CPU architecture type corresponding to the server.

[0030] The present application also provides a microservice testing system for a hybrid CPU architecture device, including:

[0031] A request receiving module, used for receiving a test request;

[0032] An architecture determination module, used to parse the test request and determine the CPU architecture corresponding to the node to which the test request belongs;

[0033] A fault preparation module, 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 network delay, and the fault delay parameter is used to simulate the fault handling of error reporting;

[0034] A fault injection module, used to inject the fault code and / or fault delay parameter into the agent of the microservice on the CPU node;

[0035] The fault testing module is used to hijack the traffic after the microservice is injected on the CPU node, and perform fault processing detection based on the traffic.

[0036] The present application also provides a computer-readable storage medium having a computer program stored thereon, and the computer program implements the steps of the method described above when executed by a processor.

[0037] The present application also provides a server, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps of the above-mentioned method when calling the computer program in the memory.

[0038] The present application provides a microservice testing method for a hybrid CPU architecture device, comprising: receiving a test request; parsing the test request to determine the CPU architecture corresponding to the node to which the test request belongs; determining a fault code and / or a fault delay parameter corresponding to the CPU architecture; the fault code is used to simulate fault handling of network delays, and the fault delay parameter is used to simulate fault handling of error reports; injecting the fault code and / or fault delay parameter into an agent of a microservice on the CPU node; hijacking the traffic of the microservice on the CPU node after it is injected, and performing fault handling detection based on the traffic.

[0039] This application, by receiving a test request, first determines 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 based on agents with different CPU architectures, and set different fault strategies for chaos testing. At the same time, the microservice can be tested as a separate process, and the fault can be injected for chaos testing after the proxy hijacks the traffic. This method can be injected into microservices on different CPU architectures without modifying the business logic of the proxy, and the fault simulation of the business can be achieved without intrusion into the business itself. At the same time, the implementation process is convenient and simple, and rapid chaos testing can be achieved, which greatly saves manpower and time costs.

[0040] The present application also provides a microservice testing system, a computer-readable storage medium and a server for a hybrid CPU architecture device, which have the above-mentioned beneficial effects and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0042] Figure 1 A flowchart of a microservice testing method for a hybrid CPU architecture device provided in an embodiment of the present application;

[0043] Figure 2 A flowchart of a microservice testing method for a hybrid CPU architecture device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0044] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0045] Please refer to Figure 1 , Figure 1 A flowchart of a microservice testing method for a hybrid CPU architecture device provided in an embodiment of the present application, the method comprising:

[0046] S101: receiving a test request;

[0047] Usually, container microservices are run on different CPU architectures, and different microservices are deployed in a Kubernetes cluster composed of machines with different CPU architectures to form a complete application system. Users can select microservices to deploy applications on different CPU architectures through the page to perform microservice governance and testing functions.

[0048] This step is intended to receive a test request, which is a test request for a microservice, usually for a microservice on a hybrid CPU architecture device, to detect the fault handling capability of the microservice. This embodiment can perform chaos testing, which is a testable, system-based method to verify and test chaos problems in large-scale microservice systems. A test method similar to "fault drills" helps microservice application systems in production environments run more stably through empirical verification methods.

[0049] S102: parsing the test request to determine a CPU architecture corresponding to the node to which the test request belongs;

[0050] This step requires determining the CPU architecture corresponding to the node to which the test request belongs. Specifically, determine the corresponding CPU architecture based on the properties of the image corresponding to the current microservice:

[0051] If the image supports multiple architectures and the microservice performs node selection, the selected proxy image is used as the injection target;

[0052] If the image supports multiple architectures and the microservice does not perform node selection, select the proxy image that supports multiple architectures as the injection target;

[0053] If the image supports a single architecture, use the proxy image of the same architecture as the single architecture as the injection target.

[0054] S103: Determine a fault code and / or a fault delay parameter corresponding to the CPU architecture;

[0055] This step requires determining the fault code and / or fault delay parameter corresponding to the CPU architecture, wherein the fault code is used to simulate the fault handling of network delays, and the fault delay parameter is used to simulate the fault handling of error reports, both of which are used as fault simulations for injection.

[0056] This step may include a configuration process for fault codes and / or fault delay parameters. For example, the fault codes and / or fault delay parameters corresponding to the CPU architecture may be determined based on the user's operating instructions in the UI interface, or the relevant instructions may be directly received to parse and obtain the fault codes and / or fault delay parameters.

[0057] S104: Injecting the fault code and / or fault delay parameter into the agent of the microservice on the CPU node;

[0058] This step requires injecting the fault code and / or fault delay parameters into the microservice proxy.

[0059] S105: hijacking the traffic of the microservice injected on the CPU node, and performing fault processing detection based on the traffic.

[0060] After injecting a fault, it is necessary to hijack the traffic and forward it to the upstream and downstream components to verify whether the fault handling mechanisms of the upstream and downstream components are sound, thereby completing the chaos test.

[0061] As a preferred implementation method, an executable method of this step can be as follows:

[0062] The first step is to use the proxy image to hijack the traffic of the microservice injected on the CPU node after the fault code and / or fault delay parameters are injected;

[0063] Step 2: Using the filter to read the traffic strategy of the traffic;

[0064] Step 3: Process the fault code and / or fault delay parameter according to the traffic strategy.

[0065] The proxy image is used to hijack the traffic passing through the microservice after the fault injection. Before executing the first step, you can first determine the proxy image from the image repository according to the CPU architecture type corresponding to the server. When you need to inject the proxy, select the proxy image that is adapted to the CPU architecture type from the image repository and then inject it. The difference between different proxy architectures lies in the different compilation methods, so as to adapt to the instruction sets of different CPU architecture types.

[0066] The filter is used to simulate faults in hijacked traffic. It should be noted that the fault code and / or fault delay parameter needs to be injected into the proxy of the microservice, and the proxy has a fixed CPU architecture, so faults can be injected simultaneously for a single microservice that does not involve CPUs of different architectures. The fault here is equivalent to the fault code and / or fault delay parameter described above. The filter can be software or a computer program generated in advance by a person skilled in the art to implement the above process.

[0067] Before hijacking traffic, you can first request the application service to create traffic passing through the microservice where the fault has been injected, and use the traffic to verify whether the upstream and downstream of the microservice handle the fault.

[0068] In the third step, the corresponding processing methods are adopted for different traffic strategies. For fault codes, the corresponding error information is generated and returned to the downstream component. For fault delay parameters, the traffic is delayed and forwarded to the upstream component, and the device stability is determined based on the processing behavior of the upstream component or downstream component on the traffic. If the traffic strategy contains both fault codes and fault delay parameters, the processing methods described above can be executed at the same time.

[0069] In particular, after hijacking the traffic injected into the microservice on the CPU node, the traffic status after the fault injection can also be displayed through the traffic topology diagram. Specifically, the UI interface can be used to display the traffic topology diagram of the entire microservice application system, which can not only display the configuration and distribution of the fault strategy, but also display the detailed information of the traffic changes passing through each microservice after the fault is injected in real time. More preferably, different colors can be used to identify the degree of processing of the fault simulation by different components, so that for the components that do not handle the fault, the business logic can be optimized in a targeted manner to improve the system's ability to handle sudden faults.

[0070] The embodiment of the present application, by first determining the CPU architecture corresponding to the node to which the test request belongs upon receiving the test request, thereby determining the corresponding fault code and / or fault delay parameter for the CPU architecture, can automatically identify the CPU architecture of the node where the microservice is located, automatically implement differential injection based on agents with different CPU architectures, and set different fault strategies for chaos testing. At the same time, the microservice can be tested as a separate process, and the fault can be injected for chaos testing after the proxy hijacks the traffic. This method can be injected into microservices on different CPU architectures without modifying the business logic of the proxy, and the fault simulation of the business can be achieved without any intrusion into the business itself. At the same time, the implementation process is convenient and simple, and rapid chaos testing can be achieved, which greatly saves manpower and time costs.

[0071] On the basis of the above embodiment, as a preferred implementation mode of the present application, before determining the fault code and / or fault delay parameter corresponding to the CPU architecture, the request number ratio of the fault code and / or fault delay parameter may be configured in advance;

[0072] When injecting the fault code and / or fault delay parameter into the proxy of the microservice on the CPU node, the actual number of times the fault code and / or fault delay parameter is injected can be configured according to the number of times the test request is received and the ratio of the number of requests. For example, if the ratio of the number of requests is configured to 40%, and 100 test requests are received, then 40 of the requests will be injected with faults and returned to verify whether the application's fault handling logic is sound. In other words, if the ratio of the number of requests is configured, each time a test request is received, the judgment of the ratio of the number of requests is performed first. If it does not exceed the current ratio of the number of requests, the test request can be executed. And the test request does not have to be executed in chronological order, it is only required to meet the ratio of the number of requests.

[0073] The following is a supplementary explanation of an executable process of this application from a user's perspective:

[0074] 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;

[0075] Step 2. Perform microservice testing and use the proxy differential injection device to differentially inject the proxy into the component in sidecar mode according to the CPU architecture of the node where the component is located;

[0076] Step 3. Register the filter with fault simulation capability to the agent in step 2;

[0077] Step 4. Configure the fault strategy through the UI, that is, the fault code and / or fault delay parameters, and send them to the agent;

[0078] Step 5. When traffic passes through the microservice component, the proxy containing the filter is used to hijack the traffic. The filter simulates failures according to the configured failure ratio and strategy to perform chaos testing;

[0079] Step 6. Use the UI to display the complete traffic topology of the application, and view the traffic change details of the upstream and downstream components after the simulated failure displayed on the UI interface in real time.

[0080] In this embodiment, the proxy differential injection device and the filter can be in software form, for example, running in the form of a computer program or script. The Sidecar mode is a design mode that separates a part of the application function from the application itself and runs it as a separate process. This design mode allows many functions to be added to the application without the configuration of additional third-party components and the modification of the application code itself.

[0081] The following is an introduction to the microservice testing system of the hybrid CPU architecture device provided in an embodiment of the present application. The microservice testing system described below and the microservice testing method of the hybrid CPU architecture device described above can be referenced to each other.

[0082] See also Figure 2 ,This application also provides a microservice testing system for a hybrid CPU architecture device, a packet request receiving module, for receiving a test request;

[0083] An architecture determination module, used to parse the test request and determine the CPU architecture corresponding to the node to which the test request belongs;

[0084] A fault preparation module, 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 network delay, and the fault delay parameter is used to simulate the fault handling of error reporting;

[0085] A fault injection module, used to inject the fault code and / or fault delay parameter into the agent of the microservice on the CPU node;

[0086] The fault testing module is used to hijack the traffic after the microservice is injected on the CPU node, and perform fault processing detection based on the traffic.

[0087] Based on the above embodiment, as a preferred embodiment, the architecture determination module includes:

[0088] The architecture determination unit is used to determine the corresponding CPU architecture according to the properties of the image corresponding to the current microservice; if the image supports multiple architectures and the microservice performs node selection, the selected proxy image is used as the injection target; if the image supports multiple architectures and the microservice does not perform node selection, the proxy image supporting multiple architectures is selected as the injection target; if the image supports a single architecture, the proxy image with the same architecture as the single architecture is used as the injection target.

[0089] Based on the above embodiment, as a preferred embodiment, the fault testing module includes:

[0090] A hijacking unit, used for hijacking the traffic of the microservice injected into the CPU node after the fault code and / or fault delay parameter is injected by using a proxy image;

[0091] A policy reading unit, used for reading the traffic policy of the traffic using a filter;

[0092] A fault setting unit is used to process the fault code and / or fault delay parameter according to the traffic strategy.

[0093] Based on the above embodiment, as a preferred embodiment, the fault setting unit is a unit for performing the following steps:

[0094] For the fault code, generate corresponding error information and return it to the downstream component;

[0095] For the fault delay parameter, the traffic is delayed and then forwarded to an upstream component, and the device stability is determined based on the processing behavior of the upstream component or the downstream component on the traffic.

[0096] Based on the above embodiments, as a preferred embodiment, it also includes:

[0097] A request ratio setting module is used to configure the request number ratio of the fault code and / or the fault delay parameter.

[0098] Based on the above embodiments, as a preferred embodiment, it also includes:

[0099] The display module is used to display the flow status after the fault is injected through a flow topology relationship diagram.

[0100] Based on the above embodiment, as a preferred embodiment, the fault testing module further includes:

[0101] The image selection unit is used to determine the proxy image from the image warehouse according to the CPU architecture type corresponding to the server.

[0102] The present application also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed, the steps provided in the above embodiment can be implemented. The storage medium may include: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and other media that can store program codes.

[0103] The present application also provides a server, which may include a memory and a processor, wherein a computer program is stored in the memory, and when the processor calls the computer program in the memory, the steps provided in the above embodiment may be implemented. Of course, the server may also include various network interfaces, power supplies and other components.

[0104] The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other. For the system provided in the embodiment, since it corresponds to the method provided in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

[0105] Specific examples are used herein to illustrate the principles and implementation methods of the present application, and the description of the above embodiments is only used to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

[0106] It should also be noted that, in this specification, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the statement "comprises a ..." does not exclude the presence of other identical elements in the process, method, article or device including the element.

Claims

1. A microservice testing method for a hybrid CPU architecture device, characterized in that: include: Receive test requests; Parsing the test request to determine a CPU architecture corresponding to the node to which the test request belongs; 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, and the fault delay parameter is used to simulate the fault handling of error reporting; Injecting the fault code and / or the fault delay parameter into an agent of the microservice on the CPU node; Hijacking the traffic injected into the microservice on the CPU node, and performing fault handling detection based on the traffic; Wherein, determining the CPU architecture corresponding to the node to which the test request belongs includes: Determine the corresponding CPU architecture based on the properties of the image corresponding to the current microservice; If the image supports multiple architectures and the microservice performs node selection, the selected proxy image is used as the injection target; If the image supports multiple architectures and the microservice does not perform node selection, select a proxy image that supports multiple architectures as the injection target; If the image supports a single architecture, a proxy image with the same architecture as the single architecture is used as an injection target.

2. The microservice testing method according to claim 1, characterized in that: Hijacking the traffic injected by the microservice on the CPU node and performing fault processing detection based on the traffic includes: Hijacking the flow of the microservice injected into the CPU node after the fault code and / or fault delay parameter is injected by using a proxy image; Using the filter to read the traffic policy of the traffic; The fault code and / or fault delay parameter are processed according to the traffic strategy.

3. The microservice testing method according to claim 2, characterized in that: Processing the fault code and / or fault delay parameter according to the traffic strategy includes: For the fault code, generate corresponding error information and return it to the downstream component; For the fault delay parameter, the traffic is delayed and then forwarded to an upstream component, and the device stability is determined based on the processing behavior of the upstream component or the downstream component on the traffic.

4. The microservice testing method according to claim 1, characterized in that: Before determining the fault code and / or fault delay parameter corresponding to the CPU architecture, the method further includes: a ratio of the number of requests for configuring the fault code and / or the fault delay parameter; When injecting the fault code and / or fault delay parameter into the agent of the microservice on the CPU node, it also includes: The number of times the fault code and / or fault delay parameter are actually injected is configured according to the number of times the test request is received and the ratio of the number of requests.

5. The microservice testing method according to claim 1, characterized in that: After hijacking the traffic injected by the microservice on the CPU node and performing fault processing detection based on the traffic, it also includes: The traffic topology diagram shows the traffic status after fault injection.

6. The microservice testing method according to claim 2, characterized in that: Hijacking the fault code and / or fault delay parameter by using a proxy image before the flow of the microservice injected into the CPU node, further comprising: The proxy image is determined from an image repository according to a CPU architecture type corresponding to the micro server.

7. A microservice testing system for a hybrid CPU architecture device, characterized in that: include: A request receiving module, used for receiving a test request; An architecture determination module, used to parse the test request and determine the CPU architecture corresponding to the node to which the test request belongs; A fault preparation module, used to determine a fault code and / or a fault delay parameter corresponding to the CPU architecture; The fault code is used to simulate the fault handling of network delay, and the fault delay parameter is used to simulate the fault handling of error reporting; A fault injection module, used to inject the fault code and / or fault delay parameter into the agent of the microservice on the CPU node; A fault testing module, used to hijack the traffic of the microservice injected on the CPU node, and perform fault processing detection based on the traffic; Among them, the architecture determination module includes: an architecture determination unit, which is used to determine the corresponding CPU architecture according to the properties of the image corresponding to the current microservice; if the image supports multiple architectures and the microservice executes node selection, the selected proxy image is used as the injection target; if the image supports multiple architectures and the microservice does not execute node selection, the proxy image that supports multiple architectures is selected as the injection target; if the image supports a single architecture, the proxy image with the same architecture as the single architecture is used as the injection target.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the microservice testing method for a hybrid CPU architecture device as described in any one of claims 1 to 6 are implemented.

9. A server, characterized in that: It includes a memory and a processor, wherein a computer program is stored in the memory, and when the processor calls the computer program in the memory, the steps of the microservice testing method of the hybrid CPU architecture device as described in any one of claims 1 to 6 are implemented.

Images