System for testing micro-service interface

Abstract

The invention belongs to the technical field of software testing, and particularly relates to a system for testing a micro-service interface. The system comprises a container sharing unit, a control module, a shared storage module and a Mock service module, a service monitoring module and a heartbeat module are arranged in the container sharing unit; the service monitoring module is used for monitoring a request received by a specified interface in the tested micro-service; the heartbeat module communicates with the control module; the control module manages related rules; the shared storage module is used for storing the monitoring rule and the monitoring information; and the Mock service module is used for simulating a peripheral dependent service interacting with the tested service. According to the method, the deployment cost can be effectively reduced, micro-service cluster resources are saved, program codes of the tested service are not invaded, the tested service can be online to a formal environment after the test is completed, and production faults caused by configuration modified by the test and hard codes do not need to be worried about.

Description

Technical Field

[0001] The present invention belongs to the technical field of software testing, and in particular relates to a system for microservice interface testing. Background Art

[0002] Microservice architecture is an increasingly popular approach to 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 key step to ensure that these services work seamlessly together, so how to conduct microservice testing has become an important topic.

[0003] In traditional monolithic applications, testing is usually done within the application. But in a microservices architecture, testing must be done in separate parts of each service. This is because each service in a microservices architecture is responsible for performing a part of the application's functionality, and these services communicate with each other through an API (Application Programming Interface). If one of the services fails, the entire application may be affected. Therefore, microservices testing is more complex and challenging than testing traditional applications. Nevertheless, testing is essential to detect problems and errors in the system, improve performance, and ensure the reliability, scalability, and maintainability of microservices-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, it is common to isolate its surrounding dependencies and simulate the requests of upstream services and the responses of downstream services.

[0005] However, doing so will either cause other services associated with this service to be unable to be used normally, messages to not flow normally, and increase the cost of communicating with other microservice development or testing teams; or it will be necessary to deploy an additional set of tested services and their operating environments, such as databases, caches, etc., which will require additional operation and maintenance and expenses.

[0006] The present invention provides a method, which enables the microservice itself to be fully tested without affecting the normal message flow of surrounding associated services when testing a single microservice. Summary of the invention

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

[0008] Container sharing unit, control module, shared storage module and 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 the responses from the 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;

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

[0012] The control module manages relevant rules, monitors the status 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 peripheral dependent services that interact with the tested service, receives the request sent by the service monitoring module, and gives a corresponding response message.

[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 status and environment settings of the container sharing unit to the control module; and receives instructions issued by the control module.

[0017] Preferably, the operating status and environment settings include: IP address, container name and namespace.

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

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

[0020] Preferably, the management of relevant rules in the control module includes adding, deleting, modifying and querying the rules.

[0021] Preferably, 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.

[0022] Preferably, the device stored in the shared storage module includes a disk, a database or a cache.

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

[0024] It can be seen from the above technical solutions that the present invention has the following advantages:

[0025] 1. When performing interface testing on a single microservice in a microservice cluster, there is no need to deploy the microservice additionally, which can effectively reduce deployment costs and save microservice cluster resources.

[0026] 2. It is completely decoupled from the microservice being tested, without intrusion into the program code of the service being tested. Once the test is completed, it can be put online in the formal environment without worrying about production failures caused by configuration modifications and hard coding during the test. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order to more clearly illustrate the embodiments of the present invention 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 some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

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

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

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

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

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

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

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

[0035] Figure 8A schematic diagram of the architecture of step S4 of a method for microservice interface testing provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0036] The specific implementation of the present invention is described in detail below. The present invention can be implemented in many other ways than those described herein, and those skilled in the art can make similar improvements without violating the connotation of the present invention, so the present invention is not limited by the specific embodiments disclosed.

[0037] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which the present invention belongs. The terms used are only for describing specific embodiments and are not intended to limit the present invention.

[0038] First, the terms involved in the embodiments of the present invention are explained.

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

[0040] Mock: During the testing process, for some objects that are not easy to construct or obtain, a virtual object is used to create a test method for testing.

[0041] Nginx: A lightweight web server / reverse proxy server and email (IMAP / POP3) proxy server, which is characterized by small memory usage and strong concurrency. In fact, Nginx's concurrency performance is better than that of similar web servers.

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

[0043] Service monitoring module 101: The main function is to monitor the requests received in the specified interface and method of the microservice under test according to the monitoring rule settings. If Mock processing is required, the request will be sent to the Mock service 105, the Mock response will be received and the response message will be sent back to the service under test. If Mock processing is not required, only the monitored request and the response from the real downstream service will be saved in the shared storage 104. Receive instructions from the heartbeat module 102, mount and uninstall the monitoring, and when the monitoring rules change, it is necessary to download the newly updated monitoring rules from the shared storage 104.

[0044] Heartbeat module 102: responsible for communicating with external control module 103 in Pod. Reports Pod running status and environment settings, such as IP address, container name, namespace, etc.; through the change of information returned by control module 103, notifies service monitoring module 101 to perform corresponding operations, such as updating monitoring rules, mounting or unmounting monitoring, etc.

[0045] Control module 103: responsible for managing monitoring rules, adding, deleting, modifying and querying monitoring rules. Establishing communication with heartbeat module 102, monitoring the status of service monitoring in Pod and issuing tasks.

[0046] Shared storage module 104: used to store monitoring rules and monitoring data outside the Pod. The storage may be a disk, database, cache, or other equipment or facilities for data storage. The monitoring rules or data will not be lost due to the destruction of the Pod.

[0047] Mock service module 105: simulates the peripheral dependent services that interact with the tested service, receives the request information sent by the service monitoring module 101, and gives a corresponding response message.

[0048] It should be noted that for a microservice that originally handles user requests, when the number of user requests continues to increase and the system pressure increases, instead of optimizing the performance of a single service instance (vertical expansion), multiple identical microservice instances 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 the execution of programs, and the access rights to system resources can be strictly controlled.

[0049] Therefore, in order to adapt to the characteristics of horizontal expansion of microservices, and to facilitate the decoupling of the JVM sandbox environment from the microservice image and reduce the size of the image file, the present invention packs the entire JVM sandbox environment, the service monitoring module, and the heartbeat module into a compressed package, and provides remote downloading via http, such as 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 manual operation, as shown in the figure below. Figure 3 As shown. That is, when the JVM sandbox environment is downloaded from the remote server to the Pod, it will be decompressed to the directory specified in the Pod, such as / tmp / , and then the heartbeat module and service monitoring module will automatically start running.

[0050] Figure 4 This is a flowchart of a method for microservice interface testing provided by an embodiment of the present invention, including:

[0051] S1: Make the module into a compressed file and deploy it on the server. When the Pod starts, it will automatically download and decompress it, start the module, and set parameters to ensure that the Pods related to the microservice under test are under monitoring.

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

[0053] S11: Make the service monitoring module, the heartbeat module and the running JVM sandbox environment into a zip compressed file, deploy it on the Nginx server, and provide an http download method.

[0054] S12: Set the javaagent parameter in the Pod startup parameter to trigger the Pod deployment script to send an http request to the Nginx server to download the compressed file of the JVM sandbox operating environment.

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

[0056] S14: Set custom parameters in the startup parameters to indicate the software to which the currently running microservice belongs. The heartbeat module carries the parameters when reporting information to the control module, and associates the software with the Pod.

[0057] When starting the parameters, there is also a custom parameter to indicate the software to which the currently running microservice belongs, such as app=APP1. The heartbeat module will carry this parameter when reporting information to the control module, thereby establishing an association between the software and the Pod. When the rule file is subsequently pulled from the shared storage, it will also be implemented based on the software dimension. If the microservice is to be manually expanded or dynamically expanded to add Pods, this embodiment supports the horizontal expansion of the tested service, and the above steps will be automatically executed to ensure that all Pods related to the tested microservice are under the monitoring of the service monitoring module.

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

[0059] Figure 6 It is a relationship diagram of the specific steps of S2, which include:

[0060] S21: Provide users with rule management functions on the front-end interface, including adding, deleting, modifying, and querying rules. Rules are divided into interception rules and monitoring rules.

[0061] Interception rules: used to monitor the requests sent by the specified interface or method in the tested microservice to external services such as other microservices, databases, operating systems or middleware services, intercept them, and avoid real calls to real external services. The request is sent to the Mock service, and the simulated return from the Mock service is obtained and sent back to the interface or method in the tested microservice for receiving external response information.

[0062] Monitoring rules: used to monitor the requests sent by the specified interface or method in the tested microservice to external services such as other microservices, databases, operating systems, or middleware services, and at the same time monitor the interface or method used by the microservice to receive external service response messages.

[0063] Rules can be differentiated by dimensions such as software, interface or method 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 heartbeat module corresponding to the corresponding software, interface or method, and wait for the request sent by 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 monitoring module if there is a mismatch.

[0069] After receiving the feedback from the control module, the heartbeat module compares it with its current rule summary. When it finds that the time is inconsistent, it sends a rule update notification to the service monitoring module.

[0070] S25: The service monitoring module updates the rule package. If there is no updated rule in the Pod, it is pulled from the shared storage.

[0071] S3: The service monitoring module intercepts the request of the microservice under test according to the interception rules and sends it to the Mock service. After obtaining the simulated response, it returns it to the microservice under test and finally replies to the caller of the test request.

[0072] Figure 7 This is a diagram of the specific steps of S3, which include:

[0073] S31: When the service monitoring module is started or the rules are updated, the interception rules are pulled from the shared storage to the Pod and loaded 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, loaded into the monitoring module, and the specified interface or method such as interface1 or method1 in the microservice under test is monitored.

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

[0076] Send a test request to the microservice under test. After internal processing, the microservice sends the request to the external system through interface1 or method1.

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

[0078] After detecting that interface1 or method1 is called, the service monitoring module intercepts the request issued 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 rule 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 for the response message of the Mock service. One is that it can be manually configured, and the developer or tester can set the specific response content according to specific requirements. The other is that it can be obtained from S43 (record request) and S44 (record response). By matching the current request with the content of S43, the corresponding response message in S44 is found, and then sent to the service monitoring module as a return to simulate the response of the actual system, which is convenient for testing and other work.

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

[0083] The service monitoring module sends the return back to the interface1 or method1 in the microservice under test, which is used to receive the return from the external system.

[0084] S36: The microservice under test returns a response to the test request caller.

[0085] S4: The service monitoring module writes the request and response of the tested microservice into the shared storage according to the monitoring rules to achieve the purpose of message recording.

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

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

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

[0089] S42: Send a test request to the microservice under test. The microservice sends the request to the external system through the specified interface or method. The external system returns the response result after processing.

[0090] Send a test request to the microservice under test. After internal processing, the microservice sends the request to the external system through interface1 or method1, and returns the response result to interface1 or method1 after being processed by the external system.

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

[0092] After detecting that interface1 or method1 is called, the service monitoring module writes the request issued by it to the shared storage.

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

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

[0095] It should be noted that the interfaces and methods monitored 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 the requests received by the specified interface in the microservice under test; saves the monitored requests and the responses from the 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, according to 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 a 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 reports the running status and environment settings of the container sharing unit to the control module; and receives 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: The management of relevant rules in the control module includes adding, deleting, modifying and querying the 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