Sandbox-based microservice testing method, device, equipment and storage medium

Abstract

The present invention discloses a sandbox-based microservice testing method, which can solve the problems of low system resource utilization and low sandbox deployment efficiency in the prior art. The method includes: when receiving a test request for testing a microservice under test, determining the private sandbox to which the microservice under test belongs; obtaining a public sandbox associated with the private sandbox, wherein the public sandbox stores other microservices that the microservice under test depends on when testing the microservice under test; determining the request link of the test request in the private sandbox and / or the public sandbox; and determining the test result of the microservice under test according to the request link. The present invention also discloses a sandbox-based microservice testing device, a computer device, and a computer-readable storage medium.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a sandbox-based microservice testing method, device, computer equipment, and computer-readable storage medium. Background Art

[0002] At present, most products are deployed using microservice architecture. When testing products deployed using microservice architecture, the disadvantages of traditional testing models are exposed. For example, traditional testing models cannot meet the quality and efficiency requirements of testing. In this context, a sandbox testing model based on Kubernetes cluster was hatched. This sandbox testing model solves many problems in the traditional testing model based on cloud-native deployment.

[0003] However, during the research process, the inventor discovered that in the process of testing products with a microservice architecture, the existing sandbox testing model usually deploys a microservice to be tested of the product and the upstream and downstream microservices of the microservice to be tested in one sandbox. When N microservices to be tested of the product need to be tested, N sandboxes need to be deployed, and some sandboxes may need to deploy multiple identical upstream and downstream microservices, which results in low system resource utilization and low sandbox deployment efficiency. Summary of the invention

[0004] The purpose of the present invention is to provide a sandbox-based microservice testing method, device, computer equipment and computer-readable storage medium, which can solve the problems of low system resource utilization and low sandbox deployment efficiency in the prior art.

[0005] One aspect of the present invention provides a sandbox-based microservice testing method, the method comprising: when receiving a test request for testing a microservice under test, determining a private sandbox to which the microservice under test belongs; obtaining a public sandbox associated with the private sandbox, wherein the public sandbox stores other microservices that the microservice under test depends on when testing the microservice under test; determining a request link of the test request in the private sandbox and / or the public sandbox; and determining a test result of the microservice under test according to the request link.

[0006] Optionally, the step of determining the private sandbox to which the tested microservice belongs includes: parsing a request header of the test request; detecting whether the request header carries a sandbox tag; if so, using a sandbox associated with the sandbox tag carried by the request header as the private sandbox; if not, parsing a source address of the test request, querying a sandbox tag associated with the source address, and using a sandbox associated with the queried sandbox tag as the private sandbox.

[0007] Optionally, determining the request link of the test request in the private sandbox and / or the public sandbox includes: parsing the destination address of the test request; determining a sandbox for receiving the test request according to the destination address; when the sandbox for receiving the test request is the private sandbox, using the destination address as a node in the request link, and sending the test request to the destination address; when the sandbox for receiving the test request is the public sandbox, determining an actual address in the public sandbox for receiving the test request according to the destination address, using the actual address as a node in the request link, and sending the test request to the actual address.

[0008] Optionally, the step of determining the sandbox for receiving the test request based on the target address includes: when the destination address is an IP address, determining the process set under the destination address; determining the sandbox label associated with the process set; and using the sandbox associated with the determined sandbox label as the sandbox for receiving the test request.

[0009] Optionally, the step of determining the process set under the destination address includes: determining a cluster space that carries the private sandbox and the public sandbox; judging whether the space pointed to by the destination address is located in the cluster space; if so, determining the process set under the destination address in the cluster space.

[0010] Optionally, the step of determining the sandbox used to receive the test request based on the target address includes: when the destination address is a domain name address, obtaining the domain name addresses of each microservice in the private sandbox in the cluster space; determining whether the obtained domain name address contains the destination address; if contained, determining that the sandbox used to receive the test request is the private sandbox.

[0011] Optionally, the step of determining the sandbox for receiving the test request based on the target address also includes: if the acquired domain name address does not contain the destination address, obtaining in the private sandbox a pre-backed-up access entry corresponding to each microservice in the public sandbox; determining whether the acquired access entry contains the destination address; if so, determining that the sandbox for receiving the test request is the public sandbox.

[0012] Optionally, when the sandbox used to receive the test request is the public sandbox, the actual address in the public sandbox for receiving the test request is determined according to the destination address, the actual address is used as a node in the request link, and the test request is sent to the actual address. The step includes: when the sandbox used to receive the test request is the public sandbox, obtaining in the private sandbox the pre-backed-up service names and actual addresses corresponding to each microservice in the public sandbox; determining the service name associated with the destination address from the obtained service name; filtering out the actual address associated with the determined service name from the obtained actual address, using the filtered actual address as a node in the request link, and sending the test request to the filtered actual address.

[0013] Optionally, the step of determining the service name associated with the destination address from the obtained service names includes: when the destination address is an IP address, determining the microservice mounted on the process set; and determining a service name with the same name as the microservice mounted on the process set from the obtained service names.

[0014] Optionally, the step of determining the service name associated with the destination address from the acquired service names includes: when the destination address is a domain name address, filtering out access entries containing the destination address from the acquired access entries; and determining the service name associated with the filtered access entry from the acquired service names.

[0015] Another aspect of the present invention provides a sandbox-based microservice testing device, the device comprising: a first determination module, used to determine the private sandbox to which the microservice under test belongs when receiving a test request for testing the microservice under test; an acquisition module, used to acquire a public sandbox associated with the private sandbox, wherein the public sandbox stores other microservices that the microservice under test depends on when testing the microservice under test; a second determination module, used to determine a request link of the test request in the private sandbox and / or the public sandbox; and a third determination module, used to determine a test result of the microservice under test based on the request link.

[0016] Another aspect of the present invention provides a computer device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the sandbox-based microservice testing method described in any one of the above embodiments when executing the computer program.

[0017] Another aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the sandbox-based microservice testing method described in any of the above embodiments is implemented.

[0018] The sandbox-based microservice testing method provided by the present invention provides two types of sandboxes: a private sandbox and a public sandbox. When testing the microservice under test, it is only necessary to rely on the pre-configured public sandbox to complete the testing purpose, and other microservices that depend on each microservice under test only need to be arranged once in the public sandbox, and the same microservices that different microservices under test depend on do not need to be arranged repeatedly, and then the final test result can be determined by testing the request link of the request in the private sandbox and / or the public sandbox, which solves the problems of low system resource utilization and low sandbox deployment efficiency in the prior art. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present invention. Moreover, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0020] Figure 1 A flow chart of a sandbox-based microservice testing method provided in Embodiment 1 of the present invention is shown;

[0021] Figure 2 A schematic diagram showing the interaction between the first sandbox and the second sandbox provided in the first embodiment of the present invention is shown;

[0022] Figure 3 A schematic diagram of a sandbox-based microservice testing solution provided in Embodiment 1 of the present invention is shown;

[0023] Figure 4 A block diagram of a sandbox-based microservice testing device provided in Embodiment 2 of the present invention is shown;

[0024] Figure 5 A block diagram of a computer device suitable for implementing a sandbox-based microservice testing method provided in Embodiment 3 of the present invention is shown. DETAILED DESCRIPTION

[0025] In order to make the purpose, technical scheme and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0026] It should be noted that, in this article, the terms "include", "comprises" or any other variations 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 sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0027] Embodiment 1

[0028] In order to solve the problems existing in the prior art, the present invention provides two types of sandboxes: private sandboxes and public sandboxes, wherein each microservice system corresponds to several private sandboxes and one public sandbox, each private sandbox contains several microservices under test, and the public sandbox contains other microservices on which each microservice under test in the corresponding private sandbox depends, such as the public sandbox contains the upstream microservices and / or downstream microservices of each microservice under test in the corresponding private sandbox. For example, each private sandbox under the microservice system includes an unstable version of the microservice of the microservice system, such as the front-end microservice and / or the middle-end microservice; the public sandbox under the microservice system includes the stable version of the microservice of the microservice system, such as the back-end microservice, and the public sandbox is used to provide for all private sandboxes under the microservice system. Based on the above structure, in the process of testing different tested microservices under the same microservice system, you only need to rely on the pre-configured public sandbox to complete the testing purpose. The upstream microservices and downstream microservices corresponding to each tested microservice only need to be deployed once in the public sandbox, and the same upstream microservices and the same downstream microservices corresponding to different tested microservices do not need to be deployed repeatedly, which solves the problems of low system resource utilization and low sandbox deployment efficiency in the prior art.

[0029] Figure 1 A flow chart of a sandbox-based microservice testing method provided in Embodiment 1 of the present invention is shown. Figure 1 As shown, the sandbox-based microservice testing method includes steps S1 to S4, wherein:

[0030] Step S1: When a test request for testing a microservice under test is received, determine the private sandbox to which the microservice under test belongs.

[0031] When a product is deployed in a microservice architecture mode, the product is a microservice system, and several functional modules of the product are microservices in the microservice system. In this embodiment, when a microservice of a microservice system needs to be tested, the microservice can be called a microservice under test, and the microservice under test can be deployed in a private sandbox, and the upstream microservices and / or downstream microservices that the microservice under test depends on can be deployed in a public sandbox, wherein a private sandbox can include several microservices under test, and the microservices included in the public sandbox, in addition to those belonging to the corresponding microservice system, can also include microservices outside the corresponding microservice system, as long as they are upstream and downstream microservices that the microservice under test depends on, they can all be deployed in the public sandbox. Figure 2 As shown in the figure, the same microservice system corresponds to two private sandboxes and one public sandbox, and both private sandboxes can access the microservices in the public sandbox.

[0032] Optionally, each microservice of the microservice system is deployed in a Kubernetes cluster, each microservice corresponds to multiple process sets (process sets are also called pods), each process set has an endpoint (i.e., IP address and port), and each microservice also has a unique service (i.e., service name) and ingress (i.e., access entry). Before implementing the test, you can create a private sandbox, deploy a process set of the microservice under test into the private sandbox, and inject a sandbox label corresponding to the private sandbox into the process set; create a public sandbox, determine the upstream microservices and / or downstream microservices of the microservice under test, and deploy any process set corresponding to each determined microservice into the public sandbox.

[0033] Receiving a test request for testing the microservice under test includes: receiving a pop signal of the test request in the first hop of the test process; receiving a test request sent by other microservices in the Nth hop of the test process, where N is greater than or equal to 2. Specifically, in the first hop of the test process, a test request is generated by a microservice in the private sandbox, and when the pop signal of the test request is detected, the test request is intercepted, and the private sandbox to which the microservice under test belongs is determined, such as: determining the process set associated with the source IP address of the test request, querying the sandbox label associated with the process set, and then injecting the sandbox label into the request header, and using the sandbox corresponding to the queried sandbox label as the private sandbox to which the microservice under test belongs. In the subsequent test process, the request header will also be transparently transmitted, so that the private sandbox to which the microservice under test belongs can be determined later according to the sandbox label carried in the request header. In the Nth hop of the test process, a microservice in a private sandbox or a public sandbox receives a test request sent by other microservices, and then determines the private sandbox to which the tested microservice belongs, such as obtaining a sandbox label from the request header, and then using the sandbox associated with the sandbox label carried in the request header as the private sandbox to which the tested microservice belongs. Specifically, step S1 includes steps S11 to S13, or step S1 includes steps S11, S12, and S14, wherein:

[0034] Step S11, parsing the request header of the test request;

[0035] Step S12, detecting whether the request header carries a sandbox tag;

[0036] Step S13: If carried, the sandbox associated with the sandbox tag carried by the request header is used as the private sandbox;

[0037] Step S14: If not carried, parse the source address of the test request, query the sandbox tag associated with the source address, use the sandbox associated with the queried sandbox tag as the private sandbox, and inject the queried sandbox tag into the request header.

[0038] The test request may be any request during the test of the microservice under test, such as an access request, a query request, a traversal request, or a read request.

[0039] Step S2: obtaining a public sandbox associated with the private sandbox, wherein the public sandbox stores other microservices that are dependent on when testing the tested microservice.

[0040] Specifically, the microservice under test belongs to the target microservice system, and the public sandbox stores other microservices that the various microservices under test under the target microservice system depend on when testing. For example, the public sandbox stores upstream microservices and / or downstream microservices that the various microservices under test under the target microservice system depend on when testing.

[0041] In the Kubernetes cluster, private sandboxes and public sandboxes corresponding to multiple microservice systems are deployed. In this embodiment, it is necessary to obtain a public sandbox that serves the same microservice system together with the private sandbox in step S1.

[0042] Step S3: determine a request link of the test request in the private sandbox and / or the public sandbox.

[0043] When each microservice is deployed, all IP addresses corresponding to the microservice will be written into the registry corresponding to the Kubernetes cluster. When a microservice accesses another microservice, one of the IP addresses of the microservice will be obtained from the registry, and then a request will be sent to the corresponding microservice based on the IP address. Since each microservice corresponds to multiple IP addresses, when a microservice in a sandbox accesses a microservice in another sandbox, the IP address obtained from the registry may not be in the sandbox requested for access. Therefore, this embodiment needs to find the actual address for receiving the test request based on the destination address, use the actual address as a node in the request link, and send the test request to the actual address.

[0044] Specifically, step S3 includes steps S31 to S33, or step S3 includes step S31, step S32 and step S34, wherein:

[0045] Step S31, parsing the destination address of the test request;

[0046] Step S32, determining a sandbox for receiving the test request according to the target address;

[0047] Step S33, when the sandbox for receiving the test request is the private sandbox, taking the destination address as a node in the request link, and sending the test request to the destination address, transparently transmitting the request header of the test request;

[0048] Step S34, when the sandbox used to receive the test request is the public sandbox, determine the actual address in the public sandbox for receiving the test request according to the destination address, use the actual address as a node in the request link, and send the test request to the actual address, transparently transmitting the request header of the test request.

[0049] When the sandbox used to receive the test request is a private sandbox, it indicates that the destination address is in the private sandbox, and the connectivity of the request link can be ensured by directly sending the test request to the destination address. When the sandbox used to receive the test request is a public sandbox, it is uncertain whether the destination address is in the public sandbox. It is possible that the destination address is another IP address of the microservice used to receive the test request. In order to ensure the smooth flow of the link, the actual address in the public sandbox used to receive the test request needs to be determined based on the destination address, and then the test request is sent to the actual address.

[0050] Optionally, when the destination address in the test request is an IP address or a domain name address, step S32 has different processing logic, specifically:

[0051] Solution 1 (destination address is IP address)

[0052] Step S32 includes steps S321 to S323, wherein:

[0053] Step S321, when the destination address is an IP address, determining a process set under the destination address;

[0054] Step S322, determining a sandbox tag associated with the process set;

[0055] Step S323: Use the sandbox associated with the determined sandbox tag as the sandbox for receiving the test request.

[0056] Step S321 includes:

[0057] Determine a cluster space that carries the private sandbox and the public sandbox;

[0058] Determine whether the space pointed to by the destination address is within the cluster space;

[0059] If so, determine the process set under the destination address in the cluster space.

[0060] When the destination address is an IP address, you can first determine whether the destination address is located in the Kubernetes cluster. If not, it indicates that the test request may be used for other purposes, and you can directly send the test request to the destination address; if it is, further determine the sandbox label associated with the process set under the destination address. If the determined sandbox label is consistent with the sandbox label in the request header, the sandbox associated with the determined sandbox label is a private sandbox, indicating that the sandbox used to receive the test request is a private sandbox; if the determined sandbox label is inconsistent with the sandbox label in the request header, the sandbox associated with the determined sandbox label is a public sandbox, indicating that the sandbox used to receive the test request is a public sandbox.

[0061] Solution 2 (destination address is domain name address)

[0062] Step S32 includes steps S321 to S323, wherein:

[0063] Step S321, when the destination address is a domain name address, obtaining the domain name address of each microservice in the private sandbox in the cluster space;

[0064] Step S322, determining whether the acquired domain name address contains the destination address;

[0065] Step S323: If included, determine that the sandbox used to receive the test request is the private sandbox.

[0066] Step S32 may further include step S321, step S322, and steps S324 to S326, wherein:

[0067] Step S324: if the acquired domain name address does not include the destination address, obtaining in the private sandbox the pre-backed up access entries corresponding to the respective microservices in the public sandbox;

[0068] Step S325, determining whether the obtained access entry contains the destination address;

[0069] Step S326: If included, determine that the sandbox used to receive the test request is the public sandbox.

[0070] When the destination address is a domain name address, each microservice in the private sandbox corresponds to an internally resolved domain name address. If these domain name addresses contain the destination address, it is determined that the sandbox used to receive the test request is a private sandbox; if these domain name addresses do not contain the destination address, it is further determined whether the sandbox used to receive the test request is a public sandbox. Specifically: the configuration information of the access entry of each microservice contains the domain name address of the corresponding microservice. Since the access entry of each microservice in the public sandbox is backed up in the private sandbox in advance, it is possible to determine whether the backed-up access entry contains the destination address. If it does, it is determined that the sandbox used to receive the test request is a public sandbox. If not, it indicates that the test request may be used for other purposes, and the test request can be directly sent to the destination address.

[0071] Optionally, step S34 includes steps S341 to S343, wherein:

[0072] Step S341: when the sandbox used to receive the test request is the public sandbox, obtaining in the private sandbox the pre-backed-up service names and actual addresses corresponding to the various microservices in the public sandbox;

[0073] Step S342, determining a service name associated with the destination address from the obtained service names;

[0074] Step S343, filtering out the actual address associated with the determined service name from the acquired actual addresses, using the filtered out actual address as the end point of the request link, and sending the test request to the filtered out actual address.

[0075] The actual address refers to the IP address of the process set deployed in the public sandbox. When the sandbox used to receive the test request is a public sandbox, the request link can be unblocked only by sending the test request to the IP address in the public sandbox.

[0076] Optionally, when the destination address in the test request is an IP address or a domain name address, step S342 has different processing logic, specifically:

[0077] Solution 1 (destination address is IP address)

[0078] Step S342 includes:

[0079] When the destination address is an IP address, determine the microservice mounted on the process set;

[0080] A service name having the same name as the microservice mounted on the process set is determined from the obtained service names.

[0081] In order to improve operating efficiency, in general, multiple process sets are started for each microservice on the Kubernetes cluster. Each process set can run a microservice independently. Regardless of which process set it is, the microservice mounted on the process set can be determined, and the service name with the same name as the microservice mounted on the process set can be determined from the backup service name, and the microservice corresponding to the determined service name in the public sandbox is used as the microservice for receiving test requests.

[0082] Solution 2 (destination address is domain name address)

[0083] Step S342 includes:

[0084] When the destination address is a domain name address, filtering out the access entry containing the destination address from the obtained access entries;

[0085] A service name associated with the filtered access entry is determined from the obtained service names.

[0086] The configuration information of the access entry includes the domain name address of the corresponding microservice. The access entry containing the destination address is filtered out from the backup access entry, and then the service name associated with the access entry is determined in the private sandbox. The microservice corresponding to the determined service name in the public sandbox is used as the microservice for receiving the test request.

[0087] Step S4: determining a test result of the tested microservice according to the request link.

[0088] After the request link is determined, the test parameters at each node in the request link can also be obtained during the test process, and the final test result of the tested microservice can be determined based on the test parameters of each node on the request link.

[0089] like Figure 3 As shown, the entire process of the sandbox-based microservice testing solution includes steps A1 to A15, where:

[0090] Step A1, create a private sandbox, deploy the process set of the microservice under test in the private sandbox, inject the sandbox label of the private sandbox into each process set, and inject the sidecar method into each microservice under test, where the sidecar method is used to intercept upstream and downstream requests (such as test requests), modify the destination address and forward the test request to the correct microservice.

[0091] Step A2: create a public sandbox, deploy the upstream microservices and / or downstream microservices of the microservice under test in the private sandbox in the public sandbox, and inject the sidecar method into each microservice under test in the public sandbox.

[0092] Step A3, obtaining the access entry, service name and actual address of each microservice in the public sandbox.

[0093] Step A4: back up the access entry, service name, and actual address of each microservice in the public sandbox in the private sandbox.

[0094] Step A5: When a test request is received, the sidecar method intercepts the test request and checks whether the request header carries a sandbox tag.

[0095] Step A6: If the sandbox tag is not carried, call the k8s API to query the sandbox tag associated with the process set under the source address of the test request, and inject the queried sandbox tag into the request header; if the sandbox tag is carried, directly obtain the sandbox tag in the request header.

[0096] Step A7, determine whether the destination address of the test request is an IP address or a domain name address, if it is an IP address, execute steps A8 to A10, if it is a domain name address, execute steps A11 to A15.

[0097] Step A8: When the destination address is an IP address, the k8s API is called to query the sandbox label associated with the process set under the destination address.

[0098] Step A9: If the sandbox tag matches the sandbox tag in the request header, the test request is sent to the destination address and the request header is transparently transmitted.

[0099] Step A10: If the sandbox label does not match the sandbox label in the request header, call the k8s API to query the service name of the microservice to which the process set under the destination address belongs, query the actual address associated with the service name with the same name as the microservice name in the private sandbox, send the test request to the actual address, and pass the request header through.

[0100] Step A11, when the destination address is a domain name address, call the k8s API to query whether the destination address is the domain name address corresponding to each microservice in the private sandbox;

[0101] Step A12: If yes, send the test request to the destination address and transparently transmit the request header.

[0102] Step A13: If not, call the k8s API to query whether the access entry corresponding to the public sandbox pre-backed up in the private sandbox contains the destination address.

[0103] Step A14, if not included, the test request will be sent to the destination address and the request header will be transparently transmitted.

[0104] Step A15, if included, call the k8s API to query the service name associated with the access entry containing the destination address, query the actual address corresponding to the service name in the private sandbox, send the test request to the actual address, and pass the request header through.

[0105] Embodiment 2

[0106] Embodiment 2 of the present invention further provides a sandbox-based microservice testing device, which corresponds to the sandbox-based microservice testing method provided in the above embodiment 1. The corresponding technical features and technical effects are not described in detail in this embodiment, and the relevant parts can refer to the above embodiment 1. Specifically, Figure 4 FIG. 1 is a block diagram of a sandbox-based microservice testing device provided in Embodiment 2 of the present invention. Figure 4 As shown, the sandbox-based microservice testing device 400 may include a first determination module 401, an acquisition module 402, a second determination module 403, and a third determination module 404, wherein:

[0107] A first determination module 401 is used to determine the private sandbox to which the microservice under test belongs when receiving a test request for testing the microservice under test;

[0108] An acquisition module 402 is used to acquire a public sandbox associated with the private sandbox, wherein the public sandbox stores other microservices that are relied upon when testing the tested microservice;

[0109] A second determination module 403 is used to determine a request link of the test request in the private sandbox and / or the public sandbox;

[0110] The third determination module 404 is used to determine the test result of the tested microservice according to the request link.

[0111] Optionally, when executing the step of determining the private sandbox to which the tested microservice belongs, the first determination module is specifically used to: parse the request header of the test request; detect whether the request header carries a sandbox tag; if so, use the sandbox associated with the sandbox tag carried by the request header as the private sandbox; if not, parse the source address of the test request, query the sandbox tag associated with the source address, and use the sandbox associated with the queried sandbox tag as the private sandbox.

[0112] Optionally, when executing the step of determining the request link of the test request in the private sandbox and / or the public sandbox, the second determination module is specifically used to: parse out the destination address of the test request; determine the sandbox used to receive the test request according to the target address; when the sandbox used to receive the test request is the private sandbox, use the destination address as a node in the request link and send the test request to the destination address; when the sandbox used to receive the test request is the public sandbox, determine the actual address in the public sandbox for receiving the test request according to the destination address, use the actual address as a node in the request link, and send the test request to the actual address.

[0113] Optionally, when the second determination module executes the step of determining the sandbox for receiving the test request according to the target address, it is specifically used to: when the destination address is an IP address, determine the process set under the destination address; determine the sandbox label associated with the process set; and use the sandbox associated with the determined sandbox label as the sandbox for receiving the test request.

[0114] Optionally, when executing the step of determining the process set under the destination address, the second determination module is specifically used to: determine the cluster space that carries the private sandbox and the public sandbox; determine whether the space pointed to by the destination address is located in the cluster space; if so, determine the process set under the destination address in the cluster space.

[0115] Optionally, when executing the step of determining the request link of the test request in the private sandbox and / or the public sandbox, the second determination module can also be specifically used to: when the destination address is a domain name address, obtain the domain name address of each microservice in the private sandbox in the cluster space; determine whether the obtained domain name address contains the destination address; if contained, determine that the sandbox used to receive the test request is the private sandbox.

[0116] Optionally, when the second module executes the step of determining the sandbox for receiving the test request according to the target address, it is specifically used to: if the obtained domain name address does not contain the destination address, obtain in the private sandbox the pre-backed-up access entries corresponding to each microservice in the public sandbox; determine whether the obtained access entry contains the destination address; if it does, determine that the sandbox for receiving the test request is the public sandbox.

[0117] Optionally, when the second determination module executes the steps of determining the actual address in the public sandbox for receiving the test request according to the destination address, taking the actual address as a node in the request link, and sending the test request to the actual address when the sandbox for receiving the test request is the public sandbox, it is specifically used for: when the sandbox for receiving the test request is the public sandbox, obtaining in the private sandbox the pre-backed-up service names and actual addresses corresponding to each microservice in the public sandbox; determining the service name associated with the destination address from the obtained service name; filtering out the actual address associated with the determined service name from the obtained actual address, taking the filtered actual address as a node in the request link, and sending the test request to the filtered actual address.

[0118] Optionally, when the third determination module executes the step of determining the service name associated with the destination address from the acquired service names, it is specifically used to: when the destination address is an IP address, determine the microservice mounted on the process set; and determine from the acquired service names a service name with the same name as the microservice mounted on the process set.

[0119] Optionally, when executing the step of determining the service name associated with the destination address from the acquired service names, the third determination module can also be specifically used to: when the destination address is a domain name address, filter out the access entry containing the destination address from the acquired access entries; and determine the service name associated with the filtered access entry from the acquired service name.

[0120] Embodiment 3

[0121] Figure 5 A block diagram of a computer device suitable for implementing a sandbox-based microservice testing method provided in Embodiment 3 of the present invention is shown. In this embodiment, the computer device 500 may be a smart phone, tablet computer, laptop computer, desktop computer, rack server, blade server, tower server or cabinet server (including an independent server or a server cluster composed of multiple servers) that executes a program. Figure 5 As shown, the computer device 500 of this embodiment includes at least but is not limited to: a memory 501, a processor 502, and a network interface 503 that can be interconnected through a system bus. It should be noted that Figure 5 Only computer device 500 is shown with components 501 - 503 , but it should be understood that implementing all of the components shown is not a requirement, and more or fewer components may alternatively be implemented.

[0122] In this embodiment, the memory 503 includes at least one type of computer-readable storage medium, and the readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (for example, SD or DX memory, etc.), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 501 can be an internal storage unit of the computer device 500, such as a hard disk or memory of the computer device 500. In other embodiments, the memory 501 can also be an external storage device of the computer device 500, such as a plug-in hard disk equipped on the computer device 500, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. Of course, the memory 501 can also include both the internal storage unit of the computer device 500 and its external storage device. In this embodiment, the memory 501 is generally used to store an operating system and various application software installed on the computer device 500, such as program codes of a sandbox-based microservice testing method.

[0123] In some embodiments, the processor 502 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 502 is generally used to control the overall operation of the computer device 500. For example, the processor 502 performs control and processing related to data interaction or communication with the computer device 500. In this embodiment, the processor 502 is used to run the program code of the steps of the sandbox-based microservice testing method stored in the memory 501.

[0124] In this embodiment, the sandbox-based microservice testing method stored in the memory 501 can also be divided into one or more program modules and executed by one or more processors (processor 502 in this embodiment) to complete the present invention.

[0125] The network interface 503 may include a wireless network interface or a wired network interface, and the network interface 503 is generally used to establish a communication link between the computer device 500 and other computer devices. For example, the network interface 503 is used to connect the computer device 500 to an external terminal through a network, and to establish a data transmission channel and a communication link between the computer device 500 and the external terminal. The network may be a wireless or wired network such as an intranet, the Internet, the Global System of Mobile communication (GSM), Wideband Code Division Multiple Access (WCDMA), 4G network, 5G network, Bluetooth, Wi-Fi, etc.

[0126] Embodiment 4

[0127] This embodiment also provides a computer-readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (for example, SD or DX memory, etc.), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, server, App application store, etc., on which a computer program is stored, and when the computer program is executed by a processor, the steps of the sandbox-based microservice testing method are implemented.

[0128] Obviously, those skilled in the art should understand that the modules or steps of the above-mentioned embodiments of the present invention can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, and optionally, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order from that here, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. In this way, the embodiments of the present invention are not limited to any specific combination of hardware and software.

[0129] It should be noted that the serial numbers of the embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0130] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method.

[0131] The above are only preferred embodiments of the present invention, and are not intended to limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made using the contents of the present invention specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A sandbox-based microservice testing method, characterized in that: The method comprises: When receiving a test request for testing a microservice under test, determining a private sandbox to which the microservice under test belongs; Obtain a public sandbox associated with the private sandbox, wherein the public sandbox stores other microservices that the tested microservice depends on when testing the tested microservice; Determine a request link of the test request in the private sandbox and / or the public sandbox; Determine a test result of the tested microservice according to the request link; Wherein, determining the request link of the test request in the private sandbox and / or the public sandbox includes: Parsing the destination address of the test request; Determine a sandbox for receiving the test request according to the destination address; When the sandbox for receiving the test request is the private sandbox, taking the destination address as a node in the request link, and sending the test request to the destination address; The step of determining a sandbox for receiving the test request according to the destination address includes: When the destination address is an IP address, determining a cluster space carrying the private sandbox and the public sandbox; Determine whether the space pointed to by the destination address is within the cluster space; If so, a process set under the destination address is determined in the cluster space, a sandbox label associated with the process set is determined, and a sandbox associated with the determined sandbox label is used as a sandbox for receiving the test request.

2. The method according to claim 1, characterized in that The step of determining the private sandbox to which the microservice under test belongs includes: Parsing the request header of the test request; Detect whether the request header carries a sandbox tag; If carried, the sandbox associated with the sandbox tag carried by the request header is used as the private sandbox; If not, the source address of the test request is parsed, a sandbox tag associated with the source address is queried, and the sandbox associated with the queried sandbox tag is used as the private sandbox.

3. The method according to claim 1, characterized in that The determining a request link of the test request in the private sandbox and / or the public sandbox includes: When the sandbox used to receive the test request is the public sandbox, an actual address in the public sandbox used to receive the test request is determined according to the destination address, the actual address is used as a node in the request link, and the test request is sent to the actual address.

4. The method according to claim 1, characterized in that: The step of determining a sandbox for receiving the test request according to the destination address comprises: When the destination address is a domain name address, obtaining the domain name address of each microservice in the private sandbox in the cluster space; Determine whether the acquired domain name address contains the destination address; If included, determine that the sandbox used to receive the test request is the private sandbox.

5. The method according to claim 4, characterized in that The step of determining a sandbox for receiving the test request according to the destination address further includes: If the obtained domain name address does not contain the destination address, obtain the pre-backed access entry corresponding to each microservice in the public sandbox in the private sandbox; Determine whether the obtained access entry contains the destination address; If included, determine that the sandbox used to receive the test request is the public sandbox.

6. The method according to claim 3, characterized in that When the sandbox for receiving the test request is the public sandbox, determining the actual address in the public sandbox for receiving the test request according to the destination address, using the actual address as a node in the request link, and sending the test request to the actual address comprises: When the sandbox used to receive the test request is the public sandbox, obtaining in the private sandbox the pre-backed-up service names and actual addresses corresponding to the respective microservices in the public sandbox; Determining a service name associated with the destination address from the obtained service names; The actual address associated with the determined service name is filtered out from the acquired actual addresses, the filtered out actual address is used as a node in the request link, and the test request is sent to the filtered out actual address.

7. The method according to claim 6, characterized in that The step of determining the service name associated with the destination address from the acquired service names comprises: When the destination address is an IP address, determine the microservice mounted on the process set; A service name having the same name as the microservice mounted on the process set is determined from the obtained service names.

8. The method according to claim 6, characterized in that The step of determining the service name associated with the destination address from the acquired service names comprises: When the destination address is a domain name address, the access entry containing the destination address is screened out from the access entries corresponding to the microservices in the public sandbox that are pre-backed up in the private sandbox; A service name associated with the filtered access entry is determined from the obtained service names.

9. A sandbox-based microservice testing device, characterized in that: The device comprises: A first determination module is used to determine the private sandbox to which the microservice under test belongs when receiving a test request for testing the microservice under test; An acquisition module, configured to acquire a public sandbox associated with the private sandbox, wherein the public sandbox stores other microservices that the tested microservice depends on when testing the tested microservice; A second determining module is used to determine a request link of the test request in the private sandbox and / or the public sandbox; A third determination module is used to determine the test result of the tested microservice according to the request link; When executing the step of determining the request link of the test request in the private sandbox and / or the public sandbox, the second determining module is specifically configured to: Parsing the destination address of the test request; Determine a sandbox for receiving the test request according to the destination address; When the sandbox for receiving the test request is the private sandbox, taking the destination address as a node in the request link, and sending the test request to the destination address; When executing the step of determining the sandbox for receiving the test request according to the destination address, the second determination module is specifically used to: When the destination address is an IP address, determining a cluster space carrying the private sandbox and the public sandbox; Determine whether the space pointed to by the destination address is within the cluster space; If so, a process set under the destination address is determined in the cluster space, a sandbox label associated with the process set is determined, and a sandbox associated with the determined sandbox label is used as a sandbox for receiving the test request.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images