CN111581085B - Joint debugging test system and method - Google Patents
Joint debugging test system and method Download PDFInfo
- Publication number
- CN111581085B CN111581085B CN202010349836.8A CN202010349836A CN111581085B CN 111581085 B CN111581085 B CN 111581085B CN 202010349836 A CN202010349836 A CN 202010349836A CN 111581085 B CN111581085 B CN 111581085B
- Authority
- CN
- China
- Prior art keywords
- service
- container
- request
- debugged
- debugging
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000012360 testing method Methods 0.000 title claims abstract description 35
- 238000000034 method Methods 0.000 title claims description 21
- 238000010998 test method Methods 0.000 claims abstract description 5
- 230000004044 response Effects 0.000 claims description 17
- 238000005516 engineering process Methods 0.000 abstract description 6
- 238000002955 isolation Methods 0.000 abstract description 4
- 230000008569 process Effects 0.000 description 9
- 238000010586 diagram Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 3
- 230000000977 initiatory effect Effects 0.000 description 3
- 238000011160 research Methods 0.000 description 3
- 238000013459 approach Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3664—Environments for testing or debugging software
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
Abstract
The application discloses a joint debugging test system and a joint debugging test method, and relates to the technical field of computers. The system comprises a first container and n second containers, wherein n is a positive integer; k services provided by a target application are deployed in the first container, wherein k is a positive integer; at least one service to be debugged of the k services is deployed in the second container. Aiming at the joint debugging test scene based on the container technology, a basic container containing each service of the target application can be set, each developer can be allocated with a lightweight user container belonging to the developer, and service can be invoked between the user container and the basic container, so that a 1+N container architecture is formed, the environment isolation among the containers is achieved on the premise of reducing the resource consumption as much as possible, and the usability and the stability of the joint debugging test environment are improved.
Description
Technical Field
The embodiment of the application relates to the technical field of computers, in particular to a joint debugging test system and a joint debugging test method.
Background
Container (container) technology is a lightweight virtualization technology. Because the container has the relevant characteristics such as isolation characteristic, portability characteristic and the like, the container technology can be applied to the scenes such as development, test, operation and maintenance of software products and the like.
When a software product reaches a certain scale, it often includes a large number of services (or called processes), there are complex call relationships between the services, and a complete joint debugging environment may reach a level above 100G, and consumption of memory may be a level above 10G. Therefore, due to the limitation of resources, it is difficult to configure a complete joint debugging environment for each developer, and some current practice is that a plurality of developers share a complete container for joint debugging, and the container contains all services of an application to be debugged.
When the joint debugging test is performed, the research personnel need to replace the existing service in the container in order to debug the service of the research personnel, each research personnel is likely to operate the service in the container, and some improper operations or the replaced service have problems, so that the joint debugging test environment is easily unavailable, and the stability of the joint debugging test environment is poor.
Disclosure of Invention
The embodiment of the application provides a joint debugging test system and a method, which can improve the usability and stability of a joint debugging test environment. The technical scheme is as follows:
in one aspect, an embodiment of the present application provides a joint debugging test system, where the system includes a first container and n second containers, where n is a positive integer;
k services provided by a target application are deployed in the first container, wherein k is a positive integer;
at least one service to be debugged in the k services is deployed in the second container.
On the other hand, the embodiment of the application provides a joint debugging test method, which is applied to a joint debugging test system, wherein the system comprises a first container and n second containers, k services provided by a target application are deployed in the first container, at least one service to be debugged in the k services is deployed in the second container, and n and k are positive integers; the method comprises the following steps:
the second container receives a debugging request, wherein the debugging request is used for requesting to debug the service to be debugged in the second container;
the second container determines a first service to be called according to the debugging request;
responding to the service to be debugged deployed in the second container to comprise the first service, and calling the first service in the second container by the second container for debugging;
in response to the service to be debugged deployed in the second container not including the first service, the second container sends an assisted debugging request to the first container, wherein the assisted debugging request is used for requesting to call the first service for debugging;
and the first container determines the first service according to the assisted debugging request, and calls the first service in the first container for debugging.
The technical scheme provided by the embodiment of the application can bring the following beneficial effects:
by providing a joint debugging test system, the system comprises a first container and n second containers, wherein k services provided by a target application are deployed in the first container, and at least one service to be debugged in the k services is deployed in the second container; for the joint debugging test scene based on the container technology, when joint debugging test is required to be carried out on a target application, a basic container (namely the first container) which can contain each service of the target application can be arranged, each developer can be allocated with a lightweight user container (namely the second container) belonging to the developer, the user container can only contain the service developed by a single user, and service calling between the user container and the basic container is realized in a network connection mode, so that a 1+N container architecture is formed, environmental isolation among the containers is carried out on the premise of reducing resource consumption as much as possible, and the usability and the stability of the joint debugging test environment are improved.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a block diagram of a joint debugging test system according to one embodiment of the present application;
FIG. 2 is a schematic illustration of a container deployment approach provided by one embodiment of the present application;
FIG. 3 is a schematic illustration of a container deployment approach provided in accordance with another embodiment of the present application;
FIGS. 4 and 5 are schematic diagrams of service invocation flow provided by one embodiment of the present application;
FIG. 6 is a schematic diagram of container creation and service registration provided by one embodiment of the present application;
fig. 7 is a flowchart of a joint debugging method according to an embodiment of the present application.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the present application more apparent, the embodiments of the present application will be described in further detail below with reference to the accompanying drawings.
Referring to fig. 1, an architecture diagram of a joint debugging system according to an embodiment of the present application is shown. The joint debugging test system may include: a first container 11 and n second containers 12, n being a positive integer.
The first container 11 may be referred to as a base container, in which k services provided by the target application may be deployed, k being a positive integer. The target application may be any software application to be debugged. Optionally, the first container 11 has deployed therein all services provided by the target application. Assuming that the target application provides 100 services in total, all 100 services of the target application are deployed in the first container 11.
The second container 12 may be referred to as a user container, in which second container 12 at least one of the k services of the target application may be deployed for debugging. The services to be commissioned deployed in the different second containers 12 may be the same or different. For example, assume that the services provided by the target application include a service a, a service B, and a service C, the service to be debugged deployed in one second container is a service a, the service to be debugged deployed in the other second container is a service B, and the service to be debugged deployed in the one second container is a service a and a service C. Services to be debugged deployed in each second container 12 may be flexibly added and configured according to needs (e.g., by a creating user (i.e., a developer) of the second container in combination with actual needs), which is not limited in the embodiments of the present application.
Alternatively, the first container 11 and the second container 12 are independent from each other, and the second containers 12 are independent from each other. That is, the first container 11 and the second container 12 are isolated from each other, and any two second containers 12 are also isolated from each other. Each container (including the first container 11 and the second container 12) has its own independent operating environment. The configuration operation authority of the second container 12 may be limited to a specific person, such as a creating user (i.e., a developer) of the second container 12. For example, each developer may be restricted to operating only his own configured second container 12, and registration and initiation of services may be performed in his own configured second container 12. The first container 11 may be maintained by an administrator who may periodically upgrade services contained in the first container 11, and other personnel may not operate the first container 11, so that stability of a container environment of the first container 11 is ensured, and the first container is not easily damaged. In addition, the second containers 12 are isolated from each other, and the container environments among the different second containers 12 are not affected.
In the embodiment of the application, for the joint debugging test scene based on the container technology, when joint debugging test is needed for the target application, a basic container containing all services of the target application can be set, a lightweight user container belonging to each developer can be distributed to each developer, the user container can only contain services developed by a single user, service calling between the user container and the basic container is realized in a network connection mode, so that a 1+N container framework is formed, environment isolation can be achieved, consumption of resources can be reduced, and the usability and stability of the joint debugging test environment are improved.
In addition, the service to be debugged deployed in the second container 12 may be the same as the service deployed in the first container 11, or may be a service obtained by modifying the service deployed in the first container 11, that is, a modified version of the service deployed in the first container 11. For example, the first container 11 includes a service a, a service B, and a service C of the target application, the service to be debugged deployed in the second container 12 is a service a, and the service a in the second container 12 may be the same as the service a in the first container 11, or may be a modified version of the service a obtained by modifying the service a in the first container 11.
In the present embodiment, a service refers to a function provided by a software application. Alternatively, the service may refer to a process, and different processes may be used to implement different functions.
In an exemplary embodiment, the container may be a Docker container. Dock is an open-source application container engine that packages applications and their dependencies in a container for independent operation, where the containers are independent of each other and isolated from each other, and each container may have its own independent file system, namespace, network configuration, etc. Therefore, the Docker can realize the starting operation of the service, and is increasingly used in background development to realize the compiling, configuration, operation and the like of the service.
It should be noted that, as shown in fig. 2, the first container 11 and the second container 12 may be disposed in the same computer device (e.g., the computer device 0 in fig. 2); alternatively, as shown in fig. 3, the first container 11 and the second container 12 may be disposed in a plurality of different computer devices, for example, the first container 11 may be disposed in the computer device 0 shown in fig. 3, and the plurality of second containers 12 may be disposed in a plurality of different computer devices (including the computer devices 1, 2, …, n) respectively, where different computer devices may communicate through a network or other manners. Of course, the deployment illustrated in fig. 2 and 3 above is merely exemplary and illustrative, and in other possible implementations, a portion of the second container 12 and the first container 11 may be deployed in the same computer device, another portion of the second container 12 may be deployed in another computer device or devices different from the computer device described above, and one or more second containers 12 may be deployed in each computer device.
The computer device is an electronic device having data calculation and storage capabilities, such as a server or a PC (Personal Computer ). In addition, the joint debugging test system provided by the embodiment of the application can be applied to a back-end architecture of a C/S (client/server) product to provide a joint debugging test function for the C/S product. Illustratively, the C/S product may be any application program product based on a C/S architecture, such as a live application, a video application, a social application, a payment application, a game application, and the like, which is not limited by the embodiments of the present application.
Next, a process of debugging a service to be debugged using the joint debugging test system will be described with reference to the joint debugging test system shown in fig. 1.
The second container 12 is for: receiving a debug request for requesting to debug a service to be debugged in the second container 12; determining a first service to be called according to the debugging request; in response to the service to be debugged deployed in the second container 12 including the first service, the first service in the second container 12 is invoked for debugging.
The second container 12 mentioned here may be any one of the n second containers described above, and one or more services to be debugged of the target application may be deployed in the second container 12.
In one example, the debug request may be initiated by a client of the target application. Optionally, a client access service may also be included in the second container 12, for receiving debug requests from clients. In another example, the debug request may also be initiated by the container node itself, e.g. the container node performs a timed debug task, initiating the debug request. Wherein a container node refers to a computer device provided with containers, and one or more containers can be configured in one container node. Thus, a container node configured with the second container 12 may perform timed debug tasks, initiating a debug request to the second container 12.
The second container 12, after receiving the debug request, may determine the first service to be invoked according to the debug request. Optionally, the first service refers to a first service to be invoked. The service to be debugged deployed in the second container 12 may or may not include the first service. The second container 12 may detect whether the first service is included in its deployed services to be debugged. In response to the service to be debugged disposed in the second container 12 including the first service, i.e., if the service to be debugged disposed in the second container 12 includes the first service, the second container 12 invokes the first service in the second container 12 for debugging.
Optionally, the second container 12 is further configured to send an assisted debugging request to the first container 11 in response to the service to be debugged deployed in the second container 12 not including the first service, i.e. if the service to be debugged deployed in the second container 12 does not include the first service, the assisted debugging request is used to request to invoke the first service for debugging. Accordingly, the first container 11 is configured to determine the first service according to the assisted debugging request, and call the first service in the first container 11 for debugging.
Optionally, the auxiliary debug request includes identification information of the first service, where the identification information of the service may be used to play a role of unique identification on the service, and different services may have different identification information, where the identification information of the first service may be a service name of the first service, or other identifiers, which is not limited in this embodiment of the present application. After receiving the assisted debugging request from the second container 12, the first container 11 may determine the first service according to the identification information of the first service included in the assisted debugging request, and then call the first service in the first container 11 for debugging. Optionally, the debug assisting request further includes identification information of the second container 12, where the identification information of the container may be used to uniquely identify the container, and different containers may have different identification information.
Optionally, the first container 11 is further configured to determine, according to the service registration information, whether a second service is included in the second container 12, where the second service is a service next to the first service in a service call chain corresponding to the debug request. Thereafter, the first container 11 is further configured to send, to the second container 12, a callback instruction for instructing the second container 12 to debug the second service, in response to the second service being included in the second container 12. Accordingly, the second container 12 is further configured to determine a second service according to the callback instruction, and call the second service in the second container 12 to debug. Optionally, the callback instruction includes identification information of the second service.
The first container 11 may determine, during the process of debugging the first service, or after the first service is debugged, a service that needs to be invoked next to the first service (i.e. the second service described above). The first container 11 may then determine whether the second service is included in the second container 12 in combination with the service registration information. The second container 12 here is still the one second container 12 that sends the debug request to the first container 11, and is not the other second container 12. The service registration information may record the service to be debugged deployed in each second container of the whole joint debugging system, and the registration process may be described in the following embodiments. Thus, the first container 11 can determine whether the second service is included in the second container 12 in combination with the service registration information.
Optionally, the first container 11 is used for: detecting whether the second service, which is marked with the identification information of the second container 12, is included in the service registration information; determining that the second service is included in the second container 12 in response to the second service including the identification information marked with the second container 12 in the service registration information; in response to the second service not including the identification information marked with the second container 12 in the service registration information, it is determined that the second service is not included in the second container. If the identification information of a certain service is marked with the identification information of the second container 12, for example, the identification information of a certain service includes the identification information of the second container 12, it may be stated that the service is deployed in the second container 12. For example, assuming that the identification information of the second container 12 is u1, if the identification information of a certain service (such as a service name) is u1_service, it may be explained that the service is deployed in the second container 12. Alternatively, when the identification information of the second container 12 is added to the original identification information of the service, the identification information of the second container 12 may be added before the original identification information of the service as a prefix, which helps to improve the efficiency of information retrieval, so that the first container 11 can quickly detect whether the second service including the identification information of the second container 12 is included in the service registration information.
Optionally, the first container 11 is further configured to invoke the second service in the first container 11 for debugging in response to not including the second service in the second container 12.
In addition, the first container 11 may determine, according to the service call chain corresponding to the debug request, a service to be called next to the first service (i.e. the second service described above). The joint debugging test system can support one service call chain and also can support a plurality of service call chains.
If the joint debugging test system only supports one service call chain, all the service call chains corresponding to the debugging requests are identical, the service call chain can be recorded in the first container 11, and then the second service which is called next to the first service is determined according to the service call chain. For example, a complete service call chain includes service a, service B, service C, and service D, and the call sequence of the 4 services is service a, service B, service C, and service D in sequence. Then the next invoked service for service a is service B, the next invoked service for service B is service C, and so on.
If the joint debugging test system supports multiple service call chains, the service call chains corresponding to different debugging requests may be different, in which case, the assisted debugging request sent by the second container 12 to the first container 11 may further include the service call chain corresponding to the debugging request, or include the identification information of the service call chain corresponding to the debugging request, so that the first container 11 can learn the service call chain corresponding to the debugging request.
In this embodiment, the service call chain includes determining the service to be invoked according to a predefined service call rule, where the service call rule specifies a call sequence between services, based on the service call rule, it may be determined whether, after a certain service is invoked, a next service needs to be invoked, and in a case where it is determined that the next service needs to be invoked, it is further determined which service is specifically the next service. For example, a certain service call chain includes a service a, a service B, and a service C, and the call order among the 3 services is a service a, a service B, and a service C in order.
In addition, the second container 12 and the first container 11 can make service calls to each other. For example, based on network communication between the second container 12 and the first container 11, cross-container invocation of services may be implemented in the form of RPCs (Remote Procedure Call, remote procedure invocations). The second container 12 may send an assisted debug request to the first container 11 based on the RPC, requesting to invoke a service in the first container 11. The first container 11 may send a callback request to the second container 12 on an RPC basis requesting to invoke a service in the second container 12.
Optionally, for the ith service and the (i+1) th service included in the service call chain corresponding to the debug request (the (i+1) th service is a service to be invoked next to the ith service, i is a positive integer), if the ith service is located in the second container 12 and the (i+1) th service is located in the first container 11, executing the ith service in the second container 12, after the execution of the ith service is completed, the second container 12 sends an assisted debug request to the first container 11, the assisted debug request being used for requesting to invoke the (i+1) th service in the first container 11, and then executing the (i+1) th service in the first container 11; if the ith service is located in the first container 11 and the (i+1) th service is located in the second container 12, the ith service is executed in the first container 11, and after the execution of the ith service is completed, the first container 11 sends a callback request to the second container 12 for requesting to call the (i+1) th service in the second container 12, and then the (i+1) th service is executed in the second container 12.
Referring to fig. 4 and 5 in combination, the basic container includes a complete service call chain, where the service call chain includes a service a, a service B, a service C, and a service D, and the call sequence of the 4 services is a service a, a service B, a service C, and a service D in sequence. The user container 1 includes a service a and a service C to be debugged, and names thereof are denoted as u1_service a and u1_service C, respectively. The user container 2 includes a service B to be debugged, and the name of the service B is denoted as u2_service B. When a client initiates a debugging request to the user container 1 and requests to debug a service to be debugged in the user container 1, u1_service a, service B, u1_service C and service D are sequentially called for debugging (as a service call link marked by a triangle dashed line in the figure). When a client initiates a debugging request to the user container 2 and requests to debug a service to be debugged in the user container 2, the service A, u2 _service B, the service C and the service D are sequentially called for debugging (as a service call link marked by a circular dotted line in the figure).
In the embodiment of the application, the cross-container call of the service is realized through the mutual call between the first container and the second container, so that a complete call link is completed, and the effective implementation of joint debugging test of the service to be debugged is ensured.
In addition, the first container can determine that the second container includes the second service by detecting whether the second service marked with the identification information of the second container is included in the service registration information, thereby realizing accurate and efficient determination of the service included in the second container.
The creation of the second container and the service registration process will be described with reference to the joint debugging system shown in fig. 1. In an exemplary embodiment, the system further comprises a container node for:
receiving a container generation request for requesting generation of a second container;
generating a second container according to the container generation request;
acquiring service configuration information corresponding to the second container, wherein the service configuration information is used for configuring the service to be debugged in the second container;
and adding the service to be debugged in the second container according to the service configuration information.
When a developer needs to debug his own developed service, a second container can be created that is self-contained. Alternatively, the developer may log into a page corresponding to the container creation platform on a container node (e.g., a PC), where a second container is created according to the hint request. After the second container is generated, the developer may further configure the services to be debugged contained therein, as well as related configuration files, client access services, and the like. After the service configuration information is obtained, the container creation platform adds the service to be debugged, the related configuration file, the client access service and the like in the second container according to the service configuration information.
Optionally, after adding the service to be debugged in the second container, the second container may also register the added service to be debugged with the service registry. In an exemplary embodiment, the second container is further configured to send a service registration request to a service registry, where the service registration request is used to request registration of a service to be debugged; the service registration center is used for generating service registration information, the service registration information comprises a service to be debugged, and the service to be debugged is marked with the identification information of the second container. The first container is also for receiving service registration information from a service registry. For example, the service registry may add the identification information of the second container to the identification information (such as a name) of the service to be debugged, form the above-mentioned tag, and add the identification information of the service to be debugged with the tag to the service registration information. In addition, the service registry may synchronize the service registration information to the first container, so that the first container knows whether a certain service is included in the second container according to the service registration information.
As shown in fig. 6, after a user (e.g., a developer) writes the code of the service to be debugged, the code of the service to be debugged is compiled, and then the service to be debugged is published to the package publishing platform. When the developer needs to debug the service to be debugged, the user container can be generated by one-key start, and the service to be debugged, the configuration file, the client access service and the like are added in the user container. And then, the created second container initiates a service registration request to a service registration center, and the service to be debugged is registered in the service registration center. After the service to be debugged is successfully registered, the service to be debugged can be called and debugged. In the debugging process, service call can be performed between the user container and the basic container, own service to be debugged of the user is executed in the user container, other services related to the service to be debugged are executed in the basic container, and the joint debugging test of the service to be debugged is realized by calling and executing each service in sequence. In addition, the base container may be initiated, managed, and maintained by an administrator, such as by periodically upgrading services in the base container, which other users typically cannot operate.
In the embodiment of the application, the identification information of the second container is marked for the service to be debugged in the second container in the service registration process, and corresponding service registration information is generated and provided for the first container, so that the first container can accurately and efficiently determine the service included in the second container according to the service registration information.
Referring to fig. 7, a flowchart of a joint debugging method according to an embodiment of the present application is shown. The joint debugging test method can be applied to the joint debugging test system shown in fig. 1. As shown in fig. 7, the joint debugging method may include the following steps (701 to 706):
in step 701, a second container receives a debug request for requesting a debug of a service to be debugged in the second container.
In step 702, the second container determines a first service to be invoked according to the debug request.
In step 703, in response to the service to be debugged deployed in the second container including the first service, the second container invokes the first service in the second container for debugging.
In response to the service to be debugged deployed in the second container not including the first service, the second container sends an assisted debug request to the first container requesting to invoke the first service for debugging, step 704.
Step 705, the first container determines a first service according to the assisted debug request.
In step 706, the first container invokes the first service in the first container to debug.
Optionally, after receiving the request for assistance in debugging, the first container may further perform the following steps:
the first container determines whether a second service is included in the second container according to the service registration information, wherein the second service is the next service of the first service in a service call chain corresponding to the debugging request;
responsive to the second container including the second service, the first container sends a callback instruction to the second container, the callback instruction being used to instruct the second container to debug the second service;
and the second container determines a second service according to the callback instruction, and calls the second service in the second container to debug.
Optionally, the first container determines whether the second container includes the second service according to the service registration information, including:
the first container detects whether the service registration information includes a second service marked with the identification information of the second container;
responsive to the second service including the identification information tagged with the second container in the service registration information, the first container determines that the second service is included in the second container;
in response to the second service not including the identification information marked with the second container in the service registration information, the first container determines that the second service is not included in the second container.
Optionally, after adding the service to be debugged in the second container, the following steps may also be performed:
the second container sends a service registration request to a service registration center, wherein the service registration request is used for requesting registration of the service to be debugged; the service registration center is used for generating service registration information, the service registration information comprises a service to be debugged, and the service to be debugged is marked with the identification information of the second container;
the first container receives service registration information from a service registry.
Since the content of the above-described method embodiments corresponds to the system embodiments, reference may be made to the above-described system embodiments for details not described in detail in this method embodiment.
The foregoing description of the exemplary embodiments of the present application is not intended to limit the invention to the particular embodiments disclosed, but on the contrary, the intention is to cover all modifications, equivalents, alternatives, and alternatives falling within the spirit and scope of the invention.
Claims (8)
1. The joint debugging test system is characterized by comprising a first container and n second containers, wherein k services provided by a target application are deployed in the first container, at least one service to be debugged in the k services is deployed in the second container, and n and k are positive integers;
the second container is used for receiving a debugging request, and the debugging request is used for requesting to debug the service to be debugged in the second container;
the second container is further used for determining a first service to be called according to the debugging request;
the second container is further used for calling the first service in the second container for debugging in response to the service to be debugged deployed in the second container comprising the first service;
the second container is further configured to send an assisted debugging request to the first container in response to the service to be debugged deployed in the second container not including the first service, where the assisted debugging request is used to request to invoke the first service to debug;
the first container is used for determining the first service according to the assisted debugging request, and calling the first service in the first container for debugging.
2. The system of claim 1, wherein said first container and said second container are isolated from each other and any two of said second containers are also isolated from each other.
3. The system of claim 1, wherein the system further comprises a controller configured to control the controller,
the first container is further configured to determine, according to service registration information, whether a second service is included in the second container, and send a callback instruction to the second container in response to the second service being included in the second container, where the second service is a next service of the first service in a service call chain corresponding to the debug request, and the callback instruction is configured to instruct the second container to debug the second service;
and the second container is also used for determining the second service according to the callback instruction, and calling the second service in the second container for debugging.
4. A system according to claim 3, wherein the first container is for:
detecting whether the service registration information comprises a second service marked with the identification information of the second container;
determining that the second service is included in the second container in response to the second service including the identification information marked with the second container in the service registration information;
and determining that the second service is not included in the second container in response to the second service not including the identification information marked with the second container in the service registration information.
5. The system of claim 1, further comprising a client access service in the second container, the client access service configured to receive the debug request from a client.
6. The system of any one of claims 1 to 5, further comprising a container node for:
receiving a container generation request for requesting generation of the second container;
generating the second container according to the container generation request;
acquiring service configuration information corresponding to the second container, wherein the service configuration information is used for configuring the service to be debugged in the second container;
and adding the service to be debugged in the second container according to the service configuration information.
7. The system of claim 6, wherein the system further comprises a controller configured to control the controller,
the second container is further configured to send a service registration request to a service registry, where the service registration request is used to request registration of the service to be debugged; the service registration center is used for generating service registration information, the service registration information comprises the service to be debugged, and the service to be debugged is marked with the identification information of the second container;
the first container is also for receiving the service registration information from the service registry.
8. The joint debugging test method is characterized by being applied to a joint debugging test system, wherein the system comprises a first container and n second containers, k services provided by a target application are deployed in the first container, at least one service to be debugged in the k services is deployed in the second container, and n and k are positive integers; the method comprises the following steps:
the second container receives a debugging request, wherein the debugging request is used for requesting to debug the service to be debugged in the second container;
the second container determines a first service to be called according to the debugging request;
responding to the service to be debugged deployed in the second container to comprise the first service, and calling the first service in the second container by the second container for debugging;
in response to the service to be debugged deployed in the second container not including the first service, the second container sends an assisted debugging request to the first container, wherein the assisted debugging request is used for requesting to call the first service for debugging;
and the first container determines the first service according to the assisted debugging request, and calls the first service in the first container for debugging.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010349836.8A CN111581085B (en) | 2020-04-28 | 2020-04-28 | Joint debugging test system and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010349836.8A CN111581085B (en) | 2020-04-28 | 2020-04-28 | Joint debugging test system and method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111581085A CN111581085A (en) | 2020-08-25 |
| CN111581085B true CN111581085B (en) | 2023-06-20 |
Family
ID=72124533
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010349836.8A Active CN111581085B (en) | 2020-04-28 | 2020-04-28 | Joint debugging test system and method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111581085B (en) |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105701010A (en) * | 2015-12-31 | 2016-06-22 | 北京元心科技有限公司 | Method and device for accelerating software testing |
| CN108121654B (en) * | 2016-11-30 | 2020-11-06 | 中国科学院声学研究所 | Software large-scale test method based on Docker |
| US20180285247A1 (en) * | 2017-03-29 | 2018-10-04 | The Travelers Indemnity Company | Systems, methods, and apparatus for automated code testing |
| CN110647469B (en) * | 2019-09-24 | 2023-09-08 | 广州荔支网络技术有限公司 | Micro-service testing method and device, computer equipment and storage medium |
| CN110765026B (en) * | 2019-10-31 | 2023-08-01 | 望海康信(北京)科技股份公司 | Automatic test method, device, storage medium and equipment |
-
2020
- 2020-04-28 CN CN202010349836.8A patent/CN111581085B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN111581085A (en) | 2020-08-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108830720B (en) | Intelligent contract running method, device, system and computer readable storage medium | |
| CN108415795A (en) | A kind of container Dockerfile, container mirror image rapid generation and system | |
| US20100242031A1 (en) | Systems and Methods for Dynamically Linking Application Software into a Running Operating System Kernel | |
| CN112416524A (en) | Implementation method and device of cross-platform CI/CD (compact disc/compact disc) based on docker and kubernets offline | |
| CN111610978B (en) | Applet conversion method, device, equipment and storage medium | |
| JPH1083308A (en) | Subsystem, method, and recording medium for stab retrieval and loading | |
| US11886302B1 (en) | System and method for execution of applications in a container | |
| CN111880987A (en) | Dynamic monitoring method and device of application program, storage medium and electronic device | |
| US11531526B1 (en) | Creating portable serverless applications | |
| RU2359316C2 (en) | Method of managing software components integrated into portable system | |
| CN114721719A (en) | Method and system for containerized deployment of heterogeneous applications in cluster | |
| CN113419818B (en) | Basic component deployment method, device, server and storage medium | |
| US11494184B1 (en) | Creation of transportability container files for serverless applications | |
| De Iasio et al. | A framework for microservices synchronization | |
| CN111522623B (en) | Modularized software multi-process running system | |
| CN113467931A (en) | Computing task processing method, device and system | |
| CN111581085B (en) | Joint debugging test system and method | |
| CN110928545A (en) | Component distribution method, single-page application development method, device and storage medium | |
| CN115525396A (en) | Application management method and device based on cloud protogenesis | |
| US11513833B1 (en) | Event listener interface for container-based execution of serverless functions | |
| US20060010421A1 (en) | Methods and apparatus for portable object-oriented components | |
| CN114443215A (en) | Service application deployment method and device, computer equipment and storage medium | |
| JP2006146434A (en) | Distributed application test method and distributed application test equipment | |
| KR102485154B1 (en) | Power Communication Service | |
| Piotrowski et al. | Software agents mobility using process migration mechanism in distributed Erlang |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20231012 Address after: 31a, 15 / F, building 30, maple mall, bangrang Road, Brazil, Singapore Patentee after: Baiguoyuan Technology (Singapore) Co.,Ltd. Address before: 511402 5-13 / F, West Tower, building C, 274 Xingtai Road, Shiqiao street, Panyu District, Guangzhou City, Guangdong Province Patentee before: GUANGZHOU BAIGUOYUAN INFORMATION TECHNOLOGY Co.,Ltd. |