A method and system for local service debugging based on micro-service architecture and containerization

Abstract

The application relates to the technical field of micro-service development, and discloses a local service debugging method and system based on a micro-service architecture and containerization, which comprises the following steps: configuring a service end and a client through an intranet penetration tool, and updating registration information configuration of a local service in a registration center; adding a Node Port to all container nodes in a Swarm cluster, and configuring registration information of the container nodes in the registration center; adding a routing label to a machine instance corresponding to a service in the registration center; configuring a browser plug-in; setting a breakpoint; initiating a debugging request in a browser; routing the request to an adaptive machine instance according to a request label configured by the debugging request through a Ribbon load balancer; accessing a target service through a Node Port mapped by the target service in the Swarm cluster; accessing a local sub-service through an intranet penetration domain name and a random port of the server, and entering a code breakpoint for debugging; and calling a corresponding service through a Swarm node IP and a Node Port mapped by the sub-service.

Description

Technical Field

[0001] This invention relates to the field of microservice development technology, and more specifically, to a method and system for debugging local services based on microservice architecture and containerization. Background Technology

[0002] In a microservice architecture, a typical system consists of service providers, consumers, and a service registry. Service providers register themselves with the registry; consumers discover service providers from the registry; and then invoke the service based on the provider's address in the registry. In a distributed system based on a microservice architecture, a user request requires the participation of multiple services simultaneously. For example, when a user requests to view a product, it needs to call the product service, review service, inventory service, and promotional service. The user's request first reaches the product service, which then calls the review service, inventory service, and promotional service, aggregates and processes this data, and returns it to the user. If any link in this chain fails, the entire request will fail. Therefore, during local service debugging, when debugging a specific section of code, several related services need to be started, consuming significant machine resources. Furthermore, configuring the parameters required to start services also requires substantial human effort.

[0003] Currently, for debugging a service in a distributed system, one approach involves adding code to the corresponding location in the service code to be debugged to print logs, then deploying the new code to the development environment, triggering the corresponding code in the development environment, and then using the printed logs to troubleshoot the problem. However, this method requires adding temporary code to print logs and can only observe partial information. When the problem is not found, the logging and observation process needs to be repeated, resulting in low debugging efficiency. Another approach involves starting all services locally, including the front-end page and back-end services, then triggering code on the page and setting breakpoints in the IDE for debugging. However, this method requires starting a large number of services, has high device configuration requirements, and also suffers from low debugging efficiency. Furthermore, this method requires the front-end to be started locally so that the locally running page and services can be opened in the local browser. During debugging, whenever the front-end code is modified, the latest front-end page needs to be repackaged and deployed. Summary of the Invention

[0004] To overcome the shortcomings of the prior art in local service debugging, such as low debugging efficiency and the need for a large amount of machine resources, this invention provides a local service debugging method and system based on microservice architecture and containerization.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0006] A method for debugging local services based on microservice architecture and containerization includes the following steps:

[0007] Configure the server and client using an intranet penetration tool, configure a random port for the server and inform the client, and update the registration information of the local service in the registry center.

[0008] Add Node Ports to all container nodes in the Swarm cluster, and configure registration information for all container nodes in the Swarm cluster in the registry center; the container nodes include several services;

[0009] Add route tags to the registry center for the local machine instance and Swarm cluster machine instance corresponding to any service;

[0010] Configure a browser plugin to add request tags to requests sent from the browser;

[0011] Set breakpoints in the local development environment;

[0012] Initiating a debug request in the browser, the Ribbon load balancer routes the request to the appropriate machine instance based on the request tag configured in the debug request, and accesses the target service through the Node Port mapped to the target service in the Swarm cluster. The target service accesses the local sub-service by calling the intranet penetration domain name and the random port of the server and enters the code breakpoint for debugging, and calls the corresponding service through the Swarm node IP and the Node Port mapped to the sub-service.

[0013] Furthermore, this invention also proposes a local service debugging system, applying the local service debugging method proposed in this invention. The system includes a registration center, a server, and a client, and further includes:

[0014] The intranet penetration configuration module is used to configure the server and client through the intranet penetration tool, configure a random port for the server and inform the client, and update the registration information configuration of the local service in the registry center.

[0015] The port configuration module is used to add Node Ports to all container nodes in the Swarm cluster, and to configure the registration information of all container nodes in the Swarm cluster in the registry center; the container nodes include several services.

[0016] The tag configuration module is used to add route tags to the local machine instance and Swarm cluster machine instance corresponding to any service in the registry center; and to add request tags to requests sent from the browser via browser plugins.

[0017] The Ribbon load balancer is used to route requests to appropriate machine instances based on the request tags configured for the debug request.

[0018] During local service debugging, breakpoints are first preset in the local development environment, and then a debugging request is initiated in the browser. The Ribbon load balancer routes the request to the appropriate machine instance according to the request tag configured in the debugging request, and accesses the target service through the Node Port mapped to the target service in the Swarm cluster. The target service accesses the local sub-service by calling the intranet penetration domain name and the random port of the server and enters the code breakpoint for debugging, and calls the corresponding service through the Swarm node IP and the Node Port mapped to the sub-service.

[0019] Furthermore, the present invention also proposes an apparatus including a memory and a processor, wherein the memory stores computer-readable instructions, which, when executed by the processor, cause the processor to perform the steps of the local service debugging method proposed in the present invention.

[0020] Furthermore, the present invention also proposes a storage medium storing computer-readable instructions thereon, which, when executed by a processor, implement the steps of the local service debugging method proposed in the present invention.

[0021] Compared with the prior art, the beneficial effects of the technical solution of the present invention are as follows: The present invention enables the development environment machine to call local services by combining with intranet penetration, enables the local machine to call the development environment machine by adding Node Port to the nodes in the Swarm cluster, and enables the debugging request to be routed to the local machine by configuring matching tags. This enables the accurate invocation of the local debugging machine during the execution of local service debugging, without the need to start all services. The target service is called through port mapping, which can effectively improve debugging efficiency and effectively reduce machine resource consumption costs. Attached Figure Description

[0022] Figure 1 A flowchart for debugging methods for local services.

[0023] Figure 2 This is an architecture diagram for a microservices architecture.

[0024] Figure 3 This is a diagram illustrating access after configuring intranet penetration.

[0025] Figure 4 This is a schematic diagram of a Swarm cluster.

[0026] Figure 5 A flowchart illustrating the process of debugging local services. Detailed Implementation

[0027] The accompanying drawings are for illustrative purposes only and should not be construed as limiting the scope of this patent; it is understandable that some well-known descriptions in the drawings may be omitted in order to better illustrate this embodiment.

[0028] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments.

[0029] Example 1

[0030] This embodiment proposes a local service debugging method based on microservice architecture and containerization, such as... Figure 1 The diagram shown is a flowchart of the local service debugging method in this embodiment.

[0031] The local service debugging method based on microservice architecture and containerization proposed in this embodiment includes the following steps:

[0032] S1. Configure the server and client using an intranet penetration tool, configure a random port for the server and inform the client, and update the registration information of the local service in the registry center.

[0033] S2. Add Node Ports to all container nodes in the Swarm cluster, and configure the registration information of all container nodes in the Swarm cluster in the registry center.

[0034] The container node in this embodiment contains services.

[0035] S3. Add route tags to the registry center for the local machine instance and Swarm cluster machine instance corresponding to any service.

[0036] S4. Configure a browser plugin to add request tags to requests sent from the browser.

[0037] S5. Set breakpoints in the local development environment.

[0038] S6. Initiate a debugging request in the browser. The Ribbon load balancer routes the request to the appropriate machine instance based on the request tag configured in the debugging request. The target service is accessed through the Node Port mapped to the target service in the Swarm cluster. The target service accesses the local sub-service by calling the intranet penetration domain name and the random port of the server and enters the code breakpoint for debugging. The corresponding service is called through the Swarm node IP and the Node Port mapped to the sub-service.

[0039] This embodiment applies to a microservice architecture, and its architecture diagram is as follows: Figure 2As shown, it consists of a server, a client, and a registry center. The server registers with the registry center, the client discovers the server from the registry center, and then makes service calls based on the address provided by the registry center.

[0040] As an example, this embodiment adopts the Spring Cloud microservice architecture and uses Eureka as the registry center in the Spring Cloud microservice architecture.

[0041] Furthermore, this embodiment uses an intranet penetration tool to configure the server and client, which exposes the application running on the local machine to the public network, allowing external development environment machines to call local services.

[0042] In an optional embodiment, configuring the server and client using the intranet penetration tool includes the following steps:

[0043] Configure a domain name that can be accessed from the external network and then pass through the internal network;

[0044] Generate and update server and client certificates for the domain name;

[0045] Generate server-side and client-side executable files;

[0046] Run the client on the local machine and specify a configuration file to configure a tunnel for communicating with the server, and use the port used by the tunnel as the port on the local machine.

[0047] Start the client; the server will assign a random port and inform the client.

[0048] In practice, when a request is made to access a random port of an intranet-penetrating domain, the request is forwarded to the client on the local machine, and then forwarded to the port on the local machine.

[0049] As an example, Ngrok can be optionally used as an intranet penetration tool. It should be noted that when using Ngrok, both its server and client need to be configured.

[0050] Furthermore, as an example, such as Figure 3The diagram illustrates access after configuring a network tunnel. A tunnel named "comment" is configured for communication between the client and the server, representing the comment service. This tunnel uses port 8080, which is the port of the Java program running on the local machine. When Ngrok starts, the Ngrok server assigns a random server port and informs the client; in this example, it's 10000. When accessing port 10000 of ngrok.my-domain.com, the request is forwarded to the Ngrok client on the local Mac machine, and then forwarded to port 8080 of the Java program running on the local Mac machine. Clearly, the Java program on the local Mac machine is exposed to the public internet.

[0051] Furthermore, after completing the intranet penetration configuration, it is necessary to update the registration information configuration of the local service in the registry center.

[0052] In an optional embodiment, updating the registration information configuration of the local service in the registry center includes: enabling the microservice locally, configuring the registry center service address of the development environment for the local service, and registering the local service to the registry center development environment.

[0053] When a microservice is started locally, in order to be able to borrow other services from the development environment, the registry service address of the development environment is configured for the local service.

[0054] Furthermore, in an optional embodiment, the process of updating the registration information configuration of the local service in the registry center further includes: configuring the IP of the local service as the domain name of the intranet penetration server, and configuring the port of the local service as the port mapped by the intranet penetration server and the local machine.

[0055] This embodiment configures the IP address and port of the local service, thus making the local service's IP address and port the same as the IP address and port for intranet penetration, enabling the development environment machine to call the local machine's services. When other services discover and call the target service through the registry center, they can achieve normal calls by calling the local service's IP address and port.

[0056] As an example, the code for updating the registration information configuration of a local service in the registry center is shown below:

[0057] `eureka.client.service-url.defaultZone = http: / / 192.168.201.3:8999 / eureka / ;` indicates the address of Eureka in the development environment, registering itself in the development environment so that it can be discovered and called by other services in the development environment.

[0058] `eureka.instance.ip-address = ngrok.my-domain.com;` indicates that the address registered for the local service is the public IP address of Ngrok.

[0059] `eureka.instance.non-secure-port=10000;` indicates that the port registered for the local service is the Ngrok server's port 10000.

[0060] Furthermore, in the microservice architecture of this embodiment, there are a large number of local services, which are run as containers. To manage the large number of containers in the microservice architecture, this embodiment uses Swarm as a container orchestration tool.

[0061] It's important to note that Swarm has its own network environment. Each container in a Swarm cluster is assigned a dynamic IP address, and these IPs are private, used only for intra-cluster access and cannot be directly accessed from outside the Swarm cluster. To enable external access, this embodiment adds a Node Port to all container nodes in the Swarm cluster, mapping a port on a Node node to a port on a container. After adding Node Ports to all container nodes in the Swarm cluster, access can be achieved through the IP address of any machine instance in the Swarm cluster plus the Node Port.

[0062] As an example, such as Figure 4The diagram shows a Swarm cluster. This Swarm cluster consists of two nodes with IPs 192.168.0.100 and 192.168.0.101, and each node is a physical machine or virtual machine with a fixed IP address. The cluster contains services A, B, and C. Node ports 9001, 9002, and 9003 are added to these three services, and each of these three Node ports is mapped to port 8080 of a container. When a Node port is added to a service, the Swarm cluster adds port mappings to all container nodes in the cluster. For example, if Node port 9001 is added for service A, then corresponding port mappings will be added to the cluster container nodes 192.168.0.100 and 192.168.0.101 to map Node port 9001 to port 8080 in the container corresponding to service A. This allows access to containers within the cluster via the IP address of the Swarm node. As shown in the diagram, the container node of service A can be accessed through Swarm node IP+9001, the container node of service B can be accessed through Swarm node IP+9002, and the container node of service C can be accessed through Swarm node IP+9003.

[0063] Furthermore, in an optional embodiment, the process of configuring the registration information of all container nodes in the Swarm cluster in the registry center includes: all container nodes in the Swarm cluster registering their instance IPs and ports in the registry center.

[0064] As an example, the code for configuring the registration information of all container nodes in the Swarm cluster in the registry center is as follows:

[0065] `eureka.instance.ip-address = 192.168.201.3;` indicates the IP address configured for instance registration with the registry center, where 192.168.201.3 is a container node in the Swarm cluster.

[0066] `eureka.instance.non-secure-port=9001;` indicates the port configured for instance registration with the registry center, where 9001 is the Node Port assigned to the corresponding service.

[0067] During implementation, for example, when the comment service calls the inventory service, the comment service queries the registry center Eureka, including how many inventory services there are, their IP addresses, and ports. The registry center Eureka returns the IP address and port registered by the instance itself.

[0068] Furthermore, in an optional embodiment, the process of adding route tags to the local machine instance and Swarm cluster machine instance corresponding to any service in the registry center includes: obtaining the metadata name-value pair associated with the local machine instance and Swarm cluster machine instance as the route tag, and sending it to the registry center.

[0069] It's important to note that when a service is started locally and registered in the development environment, there will be two comment service instances in the development environment: one on the Swarm cluster machine in the remote Swarm cluster, and the other on the local machine. Requests will be load-balanced across these two machine instances. However, when a code breakpoint is reached, nearly half of the requests will hit the breakpoint, which will affect the normal use by other users in the development environment.

[0070] In this embodiment, by adding routing tags to the local machine instance and the Swarm cluster machine instance, debugging requests initiated by the instance itself are directed to the local machine instance, while other normal requests are directed to the normal development environment machine instance, thus avoiding affecting the use of other users.

[0071] Furthermore, this embodiment uses a Ribbon load balancer to route requests, and the Ribbon load balancer is configured with a load balancing strategy for routing based on route labels.

[0072] The Ribbon load balancer is also a component of the Spring Cloud microservice architecture. For example, when service A calls service B, if there are multiple instances of service B, the load balancer selects one instance of service B to call. The Ribbon load balancer in this embodiment can optionally use different algorithms, including random, round-robin, and consistent hashing.

[0073] As an example, the code for adding route tags to the registry center for any service's corresponding local machine instance and Swarm cluster machine instance is as follows:

[0074] `eureka.instance.metadata-map.Call-Version:A;` indicates that the label for configuring dynamic routing is A, and this label only needs to be unique for each developer.

[0075] When adding a route tag in the registry, metadata is added to the route tag. This metadata will be stored in the registry center Eureka, specifically the Eureka registry center which stores the machine instance's IP address and port number.

[0076] Call-Version.

[0077] Furthermore, in an alternative embodiment, the browser plugin includes ModHeader.

[0078] The browser plugin adds an HTTP header as a request tag to any request sent from the browser; the request tag is matched with the metadata name value contained in the route tag.

[0079] In practice, the Ribbon load balancer routes requests to machine instances containing the corresponding metadata name values ​​based on the request tags added to the request.

[0080] In this embodiment, an HTTP header is added to the debugging request initiated in the browser through a browser plugin, and the request is routed according to the tag by the Ribbon load balancer, so that the request enters the code breakpoint in the local development environment.

[0081] As an example, a flowchart of a specific implementation process is shown below. Figure 5 As shown, the front-end browser, as well as the product service, inventory service, and promotion service, are all deployed in the Swarm cluster. The comment service is a target debugging service that runs on the developer's local computer. Specifically:

[0082] 1) The debugging personnel initiate a request to the product service through the front-end browser in the development environment. The request carries the request tag Call-Version=A;

[0083] 2) Access the product service via the Swarm node IP address and the Node Port mapped to the product service:

[0084] 3) The Ribbon load balancer routes the request to a local machine instance with the same route label containing metadata A, based on the request label;

[0085] 4) The product service calls the Ngrok domain name and port to access the local comment service, and a breakpoint is set in the target code;

[0086] 5) The product service calls the inventory service through the Swarm node IP + the Node Port mapped to the inventory service to complete the service debugging.

[0087] In this embodiment, by combining intranet penetration, the development environment machine can call local services. By adding Node Port to the nodes in the Swarm cluster, the local machine can call the development environment machine. By configuring matching tags, the debugging request can be routed to the local machine. This enables precise invocation of the local debugging machine during the local service debugging process, without having to start all services. By calling the target service through port mapping, debugging efficiency can be effectively improved and machine resource consumption costs can be effectively reduced.

[0088] Example 2

[0089] This embodiment proposes a local service debugging system based on microservice architecture and containerization, applying the local service debugging method proposed in Embodiment 1.

[0090] The local service debugging system proposed in this embodiment includes a registry center, a server, and a client, and also includes:

[0091] The intranet penetration configuration module is used to configure the server and client through the intranet penetration tool, configure a random port for the server and inform the client, and update the registration information configuration of the local service in the registry center.

[0092] The port configuration module is used to add Node Ports to all container nodes in the Swarm cluster, and to configure the registration information of all container nodes in the Swarm cluster in the registry center; the container nodes include several services.

[0093] The tag configuration module is used to add route tags to the local machine instance and Swarm cluster machine instance corresponding to any service in the registry center; and to add request tags to requests sent from the browser via browser plugins.

[0094] The Ribbon load balancer is used to route requests to appropriate machine instances based on the request tags configured for the debug request.

[0095] During implementation, breakpoints are preset in the local development environment, and then a debugging request is initiated in the browser. The Ribbon load balancer routes the request to the appropriate machine instance according to the request tag configured in the debugging request, and accesses the target service through the Node Port mapped to the target service in the Swarm cluster. The target service accesses the local sub-service by calling the intranet penetration domain name and the random port of the server and enters the code breakpoint for debugging, and calls the corresponding service through the Swarm node IP and the Node Port mapped to the sub-service.

[0096] It is understood that the system in this embodiment corresponds to the method in Embodiment 1 above, and the options in Embodiment 1 above are also applicable to this embodiment, so they will not be described again here.

[0097] Example 3

[0098] This embodiment proposes a device including a memory and a processor. The memory stores computer-readable instructions, which, when executed by the processor, cause the processor to perform the steps of the local service debugging method proposed in Embodiment 1.

[0099] Example 4

[0100] This embodiment proposes a storage medium storing computer-readable instructions, which, when executed by a processor, implement the steps of the local service debugging method proposed in Embodiment 1.

[0101] By way of example, the storage medium includes, but is not limited to, USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks or optical disks, and other media capable of storing program code.

[0102] By way of example, the instructions, programs, code sets or instruction sets may be implemented in programming languages ​​such as G, Java, Python, C++, R, or Golang.

[0103] By way of example, the processor includes, but is not limited to, smartphones, personal computers, servers, network devices, etc., for performing all or part of the steps of the local service debugging method described in Example 1.

[0104] The descriptive terms used in the accompanying drawings are for illustrative purposes only and should not be construed as limiting the scope of this patent.

[0105] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the present invention, and are not intended to limit the implementation of the present invention. Those skilled in the art can make other variations or modifications based on the above description. It is neither necessary nor possible to exhaustively describe all embodiments here. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. A local service debugging method based on microservice architecture and containerization, characterized in that, Includes the following steps: Configure the server and client using an intranet penetration tool, configure a random port for the server and inform the client, and update the registration information of the local service in the registry center. Add Node Ports to all container nodes in the Swarm cluster, and configure the registration information of all container nodes in the Swarm cluster in the registry center; Add route tags to the registry center for the local machine instance and Swarm cluster machine instance corresponding to any service; Configure a browser plugin to add request tags to requests sent from the browser; Set breakpoints in the local development environment; Initiating a debug request in the browser, the Ribbon load balancer routes the request to the appropriate machine instance based on the request tag configured in the debug request, and accesses the target service through the Node Port mapped to the target service in the Swarm cluster. The target service accesses the local sub-service by calling the intranet penetration domain name and the random port of the server and enters the code breakpoint for debugging, and calls the corresponding service through the Swarm node IP and the Node Port mapped to the sub-service.

2. The local service debugging method according to claim 1, characterized in that, Configuring the server and client using an intranet penetration tool includes the following steps: Configure a domain name that can be accessed from the external network and then pass through the internal network; Generate and update server and client certificates for the domain name; Generate server-side and client-side executable files; Run the client on the local machine and specify a configuration file to configure a tunnel for communicating with the server, and use the port used by the tunnel as the port on the local machine. Start the client; the server will assign a random port and inform the client of it. Specifically, when a request is made to access a random port of an intranet-penetrating domain, the request is forwarded to the client on the local machine, and then forwarded to the port on the local machine.

3. The local service debugging method according to claim 2, characterized in that, The process of updating the registration information configuration of the local service in the registry center includes the following steps: Enable microservices locally, configure the registry service address of the development environment for the local service, and register the local service in the registry development environment.

4. The local service debugging method according to claim 3, characterized in that, The update of the local service's registration information configuration in the registry center also includes: Configure the IP address of the local service to be the IP address of the intranet penetration server, and configure the port of the local service to be the port mapped by the intranet penetration server and the local machine.

5. The local service debugging method according to claim 1, characterized in that, The registration information configured in the registry center for all container nodes in the Swarm cluster includes: All container nodes in a Swarm cluster register their instance IPs and ports in the registry.

6. The local service debugging method according to claim 1, characterized in that, The step of adding route tags to the local machine instance and Swarm cluster machine instance corresponding to any service in the registry center includes: Obtain the metadata name-value pairs associated with the local machine instance and the Swarm cluster machine instance as routing tags and send them to the registry center.

7. The local service debugging method according to claim 6, characterized in that, The browser plugin includes a ModHeader; the browser plugin adds an HTTP header as a request tag to any request issued from the browser; the request tag is matched with the metadata name value contained in the route tag, and the Ribbon load balancer routes to the machine instance containing the corresponding metadata name value according to the request tag added to the request.

8. A system applying the local service debugging method according to any one of claims 1 to 7, characterized in that, Including the registration center, server, and client, and also: The intranet penetration configuration module is used to configure the server and client through the intranet penetration tool, configure a random port for the server and inform the client, and update the registration information configuration of the local service in the registry center. The port configuration module is used to add Node Ports to all container nodes in the Swarm cluster, and to configure the registration information of all container nodes in the Swarm cluster in the registry center; the container nodes include several services. The tag configuration module is used to add route tags to the local machine instance and Swarm cluster machine instance corresponding to any service in the registry center; and to add request tags to requests sent from the browser via browser plugins. Ribbon load balancer is used to route requests to appropriate machine instances based on the request tags configured for the debug request. In this process, breakpoints are preset in the local development environment, and then a debugging request is initiated in the browser. The Ribbon load balancer routes the request to the appropriate machine instance according to the request tag configured in the debugging request, and accesses the target service through the Node Port mapped to the target service in the Swarm cluster. The target service accesses the local sub-service by calling the intranet penetration domain name and the random port of the server and enters the code breakpoint for debugging, and calls the corresponding service through the Swarm node IP and the Node Port mapped to the sub-service.

9. A device comprising a memory and a processor, wherein the memory stores computer-readable instructions, characterized in that, When the computer-readable instructions are executed by the processor, the processor performs the steps of the local service debugging method as described in any one of claims 1 to 7.

10. A storage medium having computer-readable instructions stored thereon, characterized in that, When the computer-readable instructions are executed by the processor, they implement the steps of the local service debugging method as described in any one of claims 1 to 7.

Images