A system for microservice interface testing

Abstract

The application belongs to the technical field of software testing, and particularly relates to a micro-service interface test system. The system comprises a container sharing unit, a control module, a shared storage module and a Mock service module; the container sharing unit is provided with a service listening module and a heartbeat module; the service listening module listens to the requests received by the specified interface in the measured micro-service; the heartbeat module communicates with the control module; the control module manages relevant rules; the shared storage module is used for storing the listening rules and listening information; and the Mock service module simulates the surrounding dependent services interacting with the measured service. The application can effectively reduce the deployment cost, save the micro-service cluster resources, and is non-invasive to the program code of the measured service, so that the measured service can be put online to the formal environment after the test is completed, and the production failure caused by the test modification of the configuration and the hard coding does not need to be worried.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of software testing, and particularly relates to a system for microservice interface testing. BACKGROUND

[0002] Microservice architecture is a more and more popular method for building complex distributed systems. In this architecture, large applications are divided into smaller, independent services that can be deployed, upgraded and scaled independently, and communicate with each other over the network. As more and more organizations adopt microservices, microservice testing is a critical step to ensure that these services work seamlessly together, so how to test microservices has become an important topic.

[0003] In traditional monolithic applications, testing is usually done within the application. But in microservice architecture, testing must be done in the individual part of each service. This is because each service in the microservice architecture is responsible for performing part of the functionality of the application, and these services communicate with each other through APIs (Application Programming Interface). If one of the services fails, the entire application can be affected. Therefore, microservice testing is more complex and challenging than testing traditional applications. Despite this, testing is essential to detect problems and errors in the system, improve performance, and ensure the reliability, scalability and maintainability of microservice-based applications.

[0004] The same microservice can have many dependencies, which makes testing complex and time-consuming. In order to better test a single microservice, the common practice is to isolate its surrounding dependencies and simulate the requests of upstream services and the responses of downstream services.

[0005] However, doing so either causes other services associated with the service to be unable to function properly, messages to be unable to flow normally, and the cost of communication with other microservice development or testing teams to increase, or requires the deployment of an additional set of services to be tested and their operating environments, such as databases and caches, which requires additional operation and maintenance and expenses.

[0006] The present application provides a method that, when testing a single microservice, neither affects the normal message flow of the surrounding associated services nor achieves the purpose of comprehensive testing of the microservice itself. SUMMARY

[0007] The present application provides a system for microservice interface testing, comprising:

[0008] a container sharing unit, a control module, a shared storage module and a Mock service module;

[0009] The container sharing unit is provided with a service monitoring module and a heartbeat module;

[0010] The service monitoring module monitors the requests received by the specified interface in the microservice under test, saves the monitored requests and responses from the downstream to the shared storage module, or sends the requests to the Mock service module, receives the responses of the Mock service module and sends the response messages back to the microservice under test;

[0011] The heartbeat module communicates with the control module, and according to the task issued by the control module, informs the service monitoring component to perform the operation corresponding to the task;

[0012] The control module manages related rules, monitors the state of the service monitoring module and issues tasks;

[0013] The shared storage module is used to store monitoring rules and monitoring information.

[0014] The Mock service module simulates the surrounding dependent services interacting with the service under test, receives the requests sent by the service monitoring module, and gives the corresponding response messages.

[0015] Preferably, the container sharing unit is a Pod.

[0016] Preferably, the heartbeat module is used to communicate with the control module, including: the heartbeat module reports the running state and environment settings of the container sharing unit to the control module; and receives the instructions issued by the control module.

[0017] Preferably, the running state and environment settings include IP address, container name and namespace.

[0018] Preferably, the control module monitors the state of the service monitoring module, including updating the monitoring rules, monitoring mounting and monitoring unloading.

[0019] Preferably, the rules in the control module are divided into interception rules and monitoring rules.

[0020] Preferably, the control module manages related rules, including adding, deleting, modifying and querying operations on the rules.

[0021] Preferably, the control module is used to establish communication with the heartbeat module, including monitoring the state of the service monitoring in the container sharing unit and issuing instructions.

[0022] Preferably, the shared storage module stores devices including disks, databases or caches.

[0023] Preferably, the service monitoring module and the heartbeat module are both run in a JVM sandbox environment and are packed in a compressed package.

[0024] From the above technical solution, the present application has the following advantages:

[0025] 1. When performing interface testing on a single microservice in a microservice cluster, the microservice does not need to be additionally deployed, which can effectively reduce deployment cost and save microservice cluster resources.

[0026] 2. The tested microservice is completely decoupled, and the program code of the tested service is not intruded, so that the service can be put online to the formal environment after testing is completed, without worrying about production failure caused by testing modification of configuration and hard coding. BRIEF DESCRIPTION OF DRAWINGS

[0027] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without creative labor.

[0028] Figure 1 A schematic diagram of a system architecture of a microservice interface testing method provided by the embodiment of the present application;

[0029] Figure 2 A schematic diagram of a JVM sandbox structure of a microservice interface testing method provided by the embodiment of the present application;

[0030] Figure 3 A schematic diagram of horizontal expansion of a microservice interface testing method provided by the embodiment of the present application;

[0031] Figure 4 A flowchart of a microservice interface testing method provided by the embodiment of the present application;

[0032] Figure 5 A flowchart of step S1 of a microservice interface testing method provided by the embodiment of the present application;

[0033] Figure 6 A schematic diagram of step S2 architecture of a microservice interface testing method provided by the embodiment of the present application;

[0034] Figure 7 A schematic diagram of step S3 architecture of a microservice interface testing method provided by the embodiment of the present application;

[0035] Figure 8A schematic diagram of the method steps S4 architecture for microservice interface testing provided by the embodiment of the present application. DETAILED DESCRIPTION

[0036] The specific embodiments of the present application are described in detail below. The present application can be implemented in many different ways than described herein, and those skilled in the art can make similar improvements without departing from the spirit of the present application, therefore the present application is not limited to the disclosed specific embodiments.

[0037] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terms used are only for describing specific embodiments, not for limiting the present application.

[0038] First, the terms related to the embodiment of the present application are explained.

[0039] Pod: a container sharing unit composed of one or more containers, which share storage, network and namespace. Pod as a logical host provides a consistent environment for containers, so that containers can run in the same shared context. Each Pod has its own IP address and port space.

[0040] Mock: in the testing process, for some objects that are not easy to construct or not easy to obtain, a virtual object is created for testing.

[0041] Nginx: a lightweight web server / reverse proxy server and email (IMAP / POP3) proxy server, which has the characteristics of small memory occupation and strong concurrency. In fact, the concurrency of Nginx is better than that of the same type of web server.

[0042] Figure 1 It is a system architecture diagram of a method for microservice interface testing provided by the embodiment of the present application, which includes the following modules:

[0043] Service listening module 101: the main functions include setting according to the listening rules, responsible for listening to the requests received in the specified interface and method of the tested microservice. If Mock processing is needed, the request will be sent to Mock service 105, the Mock response will be received and the response message will be sent back to the tested service. If Mock processing is not needed, only the requests and responses from the real downstream service will be saved to shared storage 104. Receive instructions from heartbeat module 102, mount and uninstall the listening, when the listening rules change, need to download the newly updated listening rules from shared storage 104.

[0044] Heartbeat module 102: responsible for communication with external control module 103 in the Pod. Report the running state of the Pod and the environment settings, such as IP address, container name, namespace, etc.; through the change of the information returned by the control module 103, the service listening module 101 is notified to execute the corresponding operation, such as updating the listening rule, listening to the mounting or unloading, etc.

[0045] Control module 103: responsible for managing listening rules, adding, deleting, modifying, and querying listening rules. Establish communication with the heartbeat module 102, monitor the state of service listening in the Pod and perform task delivery.

[0046] Shared storage module 104: used for storing listening rules and listening data outside the Pod, storage can be disk, database or cache and other devices, facilities for data storage. Will not cause the loss of listening rules or data due to the destruction of the Pod.

[0047] Mock service module 105: simulate the surrounding dependent services interacting with the service under test, receive the request information sent by the service listening module 101, and give the corresponding response message.

[0048] It should be noted that for a microservice that originally handles user requests, when the user request volume increases and the system pressure increases, instead of optimizing the performance of a single service instance (vertical expansion), multiple instances of the same microservice are deployed (horizontal expansion). These newly added service instances work together with the original instances to share the task of processing requests. However, the newly added service instances may conflict with the original instances in terms of resource competition, configuration management, etc. The JVM sandbox environment can isolate and control program execution, and the access permission to system resources can be strictly controlled.

[0049] Therefore, in order to adapt to the characteristics of microservice horizontal expansion, and to facilitate the decoupling of the JVM sandbox environment and the microservice image and reduce the size of the image file, the entire JVM sandbox environment, service listening module and heartbeat module are packaged into a compressed package in the present application, and the http method is used for remote downloading, as shown in Figure 2 When the Pod is horizontally expanded, the new Pod is started, and the download of the JVM sandbox environment is automatically triggered without human operation, as shown in Figure 3 That is, after the JVM sandbox environment is downloaded from the remote server to the Pod, it will be unpacked to the specified directory in the Pod, such as / tmp / , and then the heartbeat module and the service listening module will automatically start running.

[0050] Figure 4 is a flowchart of a microservice interface test method provided by an embodiment of the present application, comprising:

[0051] S1: The module is made into a compressed file and deployed on a server. When the Pod is started, it is automatically downloaded and decompressed, the module is started, and parameters are set to ensure that the Pods related to the microservice under test are monitored.

[0052] Figure 5 The specific steps of S1 include:

[0053] S11: The service listening module, heartbeat module and running JVM sandbox environment are made into a zip compressed file and deployed on an Nginx server to provide an http download method.

[0054] S12: The javaagent parameter is set in the Pod startup parameter, triggering the Pod deployment script to send an http request to the Nginx server to download the compressed file of the JVM sandbox running environment.

[0055] S13: After the compressed file of the JVM sandbox running environment is downloaded into the Pod, it is automatically decompressed to the specified directory / tmp. When the Pod starts the microservice, the service listening module and heartbeat module in the JVM sandbox environment are activated and run.

[0056] S14: A custom parameter is set in the startup parameter to indicate the software to which the currently running microservice belongs. The heartbeat module carries this parameter when reporting information to the control module, and the software is associated with the Pod.

[0057] There is also a custom parameter in the startup parameter to indicate the software to which the currently running microservice belongs, such as app=APP1. The heartbeat module carries this parameter when reporting information to the control module, thereby associating the software with the Pod. When pulling the rule file from the shared storage later, it will also be implemented based on the software dimension. If manual expansion or dynamic expansion of the microservice is required, this embodiment supports horizontal expansion of the service under test. The above steps will be automatically executed, thereby ensuring that all Pods related to the microservice under test are monitored by the service listening module.

[0058] S2: The rule management function is provided on the front-end interface. After the user operates, the control module modifies the response message, the heartbeat module notifies the service listening module to update the rules, and the service listening module pulls the rules from the shared storage.

[0059] Figure 6 The relationship diagram of the specific steps of S2 includes:

[0060] S21: The rule management function is provided for the user on the front-end interface, including adding, deleting, modifying and querying rules. The rules are divided into interception rules and listening rules.

[0061] Intercept rule: used to listen to the request of the specified interface or method in the microservice under test to the external service such as other microservices, databases, operating systems or middleware, etc. Intercept it to avoid real call with the real external service. And send the request to the Mock service, at the same time get the simulated response from the Mock service and send it back to the interface or method in the microservice under test used to receive external response information.

[0062] Listen rule: used to listen to the request of the specified interface or method in the microservice under test to the external service such as other microservices, databases, operating systems or middleware, etc. At the same time, listen to the interface or method in the microservice used to receive the response message of the external service.

[0063] The rules can be distinguished by software, interface or method, etc. for easy maintenance.

[0064] S22: After the user publishes or updates the rules in the control module, the control module modifies the response message content of the corresponding heartbeat module.

[0065] When the user publishes or updates the rules in the control module, the control module will modify the response message content of the corresponding heartbeat module corresponding to the software, interface or method, and wait for the request from the heartbeat module.

[0066] S23: When the heartbeat module reports the status to the control module, the control module returns the corresponding rule update time.

[0067] When the heartbeat module reports the status to the control module, the control module returns the corresponding rule update time of the corresponding software, interface or method to the heartbeat module.

[0068] S24: The heartbeat module compares the rule update time, and sends a rule update notification to the service listening module when they are inconsistent.

[0069] After receiving the response from the control module, the heartbeat module compares it with its current rule summary. When it finds that the times are inconsistent, it sends a rule update notification to the service listening module.

[0070] S25: The service listening module updates the rule package, and if there is no updated rule in the Pod, it pulls from the shared storage.

[0071] S3: The service listening module intercepts the request of the microservice under test according to the intercept rule and sends it to the Mock service. After getting the simulated response, it returns to the microservice under test, and finally replies to the test request caller.

[0072] Figure 7 The relationship diagram of the specific steps of S3, which includes:

[0073] S31: When the service monitoring module is started or the rules are updated, pull the interception rules from the shared storage to the Pod and load them into the service monitoring module to monitor the specified interface or method of the microservice under test.

[0074] After the service monitoring module is started or the rules are updated, the interception rules are pulled from the shared storage to the Pod, and then loaded into the monitoring module to monitor the specified interface or method such as interface1 or method1 in the microservice under test.

[0075] S32: Send a test request to the microservice under test, which will send the request to the external system through the specified interface or method.

[0076] Send a test request to the microservice under test, which will send the request to the external system through interface1 or method1 after internal processing.

[0077] S33: The service monitoring module intercepts the request and sends it to the Mock service.

[0078] After the service monitoring module detects that interface1 or method1 is called, it intercepts the request sent by it and sends the intercepted request to the Mock service.

[0079] S34: The Mock service obtains the simulated response message according to the matching rules and sends it to the service monitoring module.

[0080] When the Mock service receives the request transmitted by the service monitoring module, it obtains the simulated response message according to the matching rules and sends it back to the service monitoring module.

[0081] It should be noted that there are two sources of response messages for the Mock service. One is manually configured by the development or testing personnel according to specific requirements to set specific response content. The second is obtained from S43 (record request) and S44 (record response) by matching the current request with the content of S43 to find the corresponding response message in S44, which is then sent back to the service monitoring module to simulate the response of the actual system, facilitating testing and other work.

[0082] S35: The service monitoring module returns the response to the microservice under test.

[0083] The service monitoring module returns the response to the interface1 or method1 in the microservice under test that receives the external system response.

[0084] S36: The microservice under test replies to the test request caller.

[0085] S4: The service monitoring module writes the request and response of the measured microservice into the shared storage according to the monitoring rule, achieving the purpose of message recording.

[0086] Figure 8 is a relationship diagram of the specific steps of S4, and the specific steps include:

[0087] S41: When the service monitoring module is started or the rule is updated, the monitoring rule is pulled from the shared storage to the Pod and loaded into the monitoring module to monitor the specified interface or method of the measured microservice.

[0088] After the service monitoring module is started or the rule is updated, the monitoring rule is pulled from the shared storage to the Pod and loaded into the monitoring module to monitor the specified interface or method such as interface1 or method1 in the measured microservice.

[0089] S42: A test request is sent to the measured microservice, and the microservice sends the request to an external system through a specified interface or method, and the external system returns a response result after processing.

[0090] A test request is sent to the measured microservice, and the microservice sends the request to an external system through a specified interface or method, and the external system returns a response result after processing.

[0091] S43: The service monitoring module writes the request into the shared storage.

[0092] After the service monitoring module monitors that interface1 or method1 is called, it writes the request sent by interface1 or method1 into the shared storage.

[0093] S44: The service monitoring module writes the response into the shared storage.

[0094] After the service monitoring module monitors that interface1 or method1 receives a response message, it writes the response received by interface1 or method1 into the shared storage, and establishes an association with the request in step S43 through an ID used to uniquely identify the business triggered by interface1 or method1.

[0095] It should be noted that the monitored interface and method in the request and response can be the same or different.

Claims

1. A system for microservice interface testing, characterized in that: The system includes: a container sharing unit, a control module, a shared storage module and a Mock service module; The container sharing unit is provided with a service monitoring module and a heartbeat module; The service monitoring module monitors requests received by the specified interface of the microservice under test; saves the monitored requests and responses from downstream to the shared storage module, or sends the requests to the mock service module, receives the responses from the mock service module and sends the response messages back to the microservice under test; The heartbeat module communicates with the control module and, based on the task issued by the control module, notifies the service monitoring component to perform an operation corresponding to the task issued; The control module manages relevant rules, monitors the status of the service monitoring module and issues tasks; The shared storage module is used to store monitoring rules and monitoring information; The Mock service module simulates the peripheral dependent services that interact with the tested service, receives the request sent by the service monitoring module, and gives a corresponding response message.

2. The system for microservice interface testing according to claim 1, characterized in that: The container sharing unit is Pod.

3. The system for microservice interface testing according to claim 1, characterized in that: The heartbeat module is used to communicate with the control module, including: the heartbeat module reporting the operating status and environment settings of the container sharing unit to the control module; and receiving instructions issued by the control module.

4. The system for microservice interface testing according to claim 3, characterized in that: The running status and environment settings include: IP address, container name and namespace.

5. The system for microservice interface testing according to claim 1, characterized in that: The control module monitors the status of the service monitoring module, including updating monitoring rules, monitoring mounting and monitoring unmounting.

6. The system for microservice interface testing according to claim 1, characterized in that: The rules in the control module are divided into interception rules and monitoring rules.

7. The system for microservice interface testing according to claim 1, characterized in that: Managing relevant rules in the control module includes adding, deleting, modifying and querying rules.

8. The system for microservice interface testing according to claim 1, characterized in that: The control module is used to establish communication with the heartbeat module, including monitoring the status of service monitoring in the container sharing unit and issuing instructions.

9. The system for microservice interface testing according to claim 1, characterized in that: The devices stored in the shared storage module include disks, databases or caches.

10. The system for microservice interface testing according to claim 1, characterized in that: The service monitoring module and the heartbeat module both run in a JVM sandbox environment and are packaged in a compressed package.

Images