Java micro-service deployment and debugging method of k8s cluster

Abstract

The invention discloses a java micro-service deployment and debugging method of a k8s cluster, the k8s cluster deploys a java container, the java container comprises a plurality of business services, the method specifically comprises a deployment step and a debugging step, the deployment step comprises: adding jdwp protocol configuration in a start command in the java container deployed by the k8s cluster, the jdwp protocol configuration is used for starting the java container in a debugging mode, and the java container is used for starting the java container in a debugging mode; meanwhile, proxy service is set in the k8s cluster; the debugging step comprises the following steps: configuring an agency service and a configured connection port, opening a source code consistent with the debugged business service in the agency service and setting a breakpoint, starting debugging, and checking each variable or program running logic in a program running process. The debugging process is simplified, the problem analysis efficiency is improved, and the requirements for human experience and ability are reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud native technology and Java microservice development technology, and in particular to a Java microservice deployment and debugging method for a k8s cluster. Background Art

[0002] At present, cloud native technology is prevalent and microservice applications are emerging. Kubernetes (k8s), as a core component of cloud native technology, has become the mainstream microservice container operation platform because it supports automated deployment, expansion and management of containerized applications. When a service running in a K8s cluster environment needs to be debugged, the main process is as follows: Preliminarily determine the fault point and add log output to the application; Compile the application into a jar package and create an image; Upload the image to the k8s cluster server and push it to the image warehouse; Deploy the application to the K8s cluster, simulate business requests, collect application output logs, and analyze the logs to locate the problem.

[0003] In the above process, human experience and work ability have a great impact on the accuracy of problem location. If the location of the debug log output is incorrect, the above process needs to be repeated, which increases the complexity of the application debugging process. Secondly, there are dependencies between microservice modules. Local debugging requires the running of related services at the same time. The host resources of non-ordinary developers are limited, so the application cannot be run and debugged locally. It can only be located through logs afterwards, which greatly reduces the efficiency of problem location, resulting in low business debugging efficiency.

[0004] In general, the current status of debugging Java applications based on k8s containers is that the process is cumbersome, the processing speed is slow, and a lot of human resources are invested. Summary of the invention

[0005] The purpose of the present invention is to overcome the defects in the prior art that when a service running in k8s needs to be debugged, the debugging process is cumbersome and the problem location is difficult, and a java microservice deployment and debugging method for a k8s cluster is provided.

[0006] The purpose of the present invention is achieved through the following technical solutions: A method for deploying and debugging java microservices of a k8s cluster, wherein the k8s cluster deploys a java container, and the java container includes several business services. The method is characterized in that the method includes a deployment step and a debugging step, and the deployment step includes: Add the jdwp (java debug wire protocol) protocol configuration to the startup command of the java container deployed in the k8s cluster. The jdwp protocol configuration is used to start the java container in debug mode and set up the proxy service in the k8s cluster. The debugging steps include: Configure a proxy service and a connection port. Open the source code consistent with the business service being debugged in the proxy service and set breakpoints. Start debugging and view the variables or program operation logic during program operation.

[0007] Preferably, in the deployment step, a proxy service is set in the k8s cluster, specifically: the proxy service provides a UI management interface, the UI management interface is used to view the business services deployed in the k8s cluster, and select the business service to be debugged and configure the connection port.

[0008] Preferably, the proxy service includes a user authentication step to determine whether the user is an authenticated user. If the user is an authenticated user, the debugging function of the debugged service is enabled; if the user is not an authenticated user, the debugging function of the debugged service is disabled. Through user authentication, it can be ensured that only authenticated users can access and debug business services in the k8s cluster, effectively preventing unauthorized users from illegally accessing and potentially damaging sensitive services or data. At the same time, through authentication, it can be clarified which users have the authority to debug specific services. This helps to track responsibility when problems arise and ensure the traceability and manageability of debugging activities.

[0009] Preferably, in the debugging step, after debugging is started, breakpoints are dynamically added, modified and deleted, and the breakpoint information before debugging is started is updated. The design of this solution allows the user to adjust breakpoints in real time according to actual needs during the debugging process without interrupting the current debugging session or restarting the debugging process, thereby improving the flexibility and accuracy of debugging.

[0010] Preferably, in the debugging step, the business service being debugged is executed by a single user or by multiple users.

[0011] Preferably, if the debugged business service is jointly executed by multiple users, the following steps are included: Perform user authentication steps for each user to determine whether the user is an authenticated user. If the user is an authenticated user, the debugging function of the debugged service is enabled for viewing and starting. If the user is not an authenticated user, the debugging function of the debugged service is disabled for viewing and starting. Determine the breakpoints set by each user. If the breakpoints set by each user are different, each user executes their own debugging steps separately. If there are repeated breakpoints set by users, remind the relevant users that there are repeated breakpoints set.

[0012] The design of this solution allows multiple users to perform debugging steps together, and different parts or problems can be processed in parallel, thus speeding up the entire debugging process. At the same time, multiple users analyze problems from different angles and may discover potential problems or solutions that are difficult for a single user to detect. At the same time, if repeated breakpoints are found, reminders will be issued to avoid conflicting debugging operations.

[0013] Preferably, if there are repeated breakpoints set by users, an allocation step is performed, and the allocation step is specifically: for the repeated breakpoints, a user is randomly selected to execute the debugging step, and other users do not execute the debugging step for this breakpoint, or each endpoint is allocated on the principle of allocating the number of breakpoints to each user as evenly as possible; or the allocation step is specifically: for each repeated breakpoint, all users execute the debugging step, and the result of each user executing the debugging step is obtained. If the results are the same, it is determined that the debugging of this breakpoint is completed; if the results are different, the relevant users repeat the debugging steps until the results of the debugging steps are the same, or the debugging result with the largest number of identical results is selected as the debugging result of the breakpoint.

[0014] When multiple users debug the same breakpoint, you can verify the accuracy and consistency of debugging by comparing the debugging results of different users. By debugging multiple times and comparing the results, you can reduce the risk of misjudgment that may occur due to a single debugging.

[0015] The beneficial effects of the present invention are: The proxy service has a visual interface that provides login authentication, cluster service query, debugging service selection, and debugging port preset management.

[0016] Simplify the debugging process: When debugging a Java program running in a k8s cluster, you can directly perform single-step debugging in the development tool, just like running the program locally, and increase or decrease debugging breakpoints at any time according to the analysis situation.

[0017] Improve problem analysis efficiency: By connecting to the real operating environment and viewing the program running logic and related variables in real time, the cause of the problem can be quickly located, greatly improving the speed of problem debugging and locating.

[0018] The demand for human experience and capabilities is reduced: Troubleshooting does not require key developers, and ordinary R&D can also complete the analysis and location of core codes based on single-step debugging. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 It is a flow chart of the present invention. DETAILED DESCRIPTION

[0020] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this application will be more comprehensive and complete and fully convey the concept of the example embodiments to those skilled in the art.

[0021] In addition, described feature, structure or characteristic can be combined in one or more embodiments in any suitable manner. In the following description, many specific details are provided to provide a full understanding of the embodiments of the present application. However, those skilled in the art will appreciate that the technical scheme of the present application can be put into practice without one or more of the specific details, or other methods, components, devices, steps, etc. can be adopted. In other cases, known methods, devices, realizations or operations are not shown or described in detail to avoid blurring the various aspects of the application.

[0022] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0023] Embodiment 1: A method for deploying and debugging Java microservices in a k8s cluster. The k8s cluster deploys a Java container, which includes several business services, such as Figure 1 As shown, it includes deployment steps and debugging steps, and the deployment steps include: Add jdwp protocol configuration to the startup command of the java container deployed in the k8s cluster. The jdwp protocol configuration is used to start the java container in debug mode and set up the proxy service in the k8s cluster. The debugging steps include: Configure a proxy service and a connection port. Open the source code consistent with the business service being debugged in the proxy service and set breakpoints. Start debugging and view the variables or program operation logic during program operation.

[0024] In the deployment steps, a proxy service is set in the k8s cluster, specifically: the proxy service provides a UI management interface, the UI management interface is used to view the business services deployed in the k8s cluster, and select the business service to be debugged and configure the connection port.

[0025] The proxy service includes a user authentication step to determine whether the user is an authenticated user. If the user is an authenticated user, the debugging function of the debugged service is enabled; if the user is not an authenticated user, the debugging function of the debugged service is disabled. Through user authentication, it can be ensured that only authenticated users can access and debug the business services in the k8s cluster, effectively preventing unauthorized users from illegally accessing and potentially damaging sensitive services or data. At the same time, through authentication, it can be clarified which users have the authority to debug specific services. This helps to track responsibility when problems arise and ensure the traceability and manageability of debugging activities.

[0026] In the debugging steps, after debugging is started, breakpoints are dynamically added, modified, and deleted, and the breakpoint information before debugging is started is updated. The design of this solution allows users to adjust breakpoints in real time according to actual needs during the debugging process without interrupting the current debugging session or restarting the debugging process, which improves the flexibility and accuracy of debugging.

[0027] Specifically, in one implementation of this solution, the specific steps are as follows: Deploy the debugging proxy service in the k8s cluster, provide user authentication for enabling debugging functions, cluster information query and configuration, and open the TCP port for debugging.

[0028] Add the jdwp (java debug wire protocol) protocol configuration parameter to the java container startup command: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=25006 to start the java service container in debug mode.

[0029] Use the browser to access the proxy service, enter the account password and log in to the proxy service, query all pods in the current k8s cluster and display them to the front-end web page.

[0030] Select the Java service to be debugged, configure the TCP connection listening port and start the debugging listening process. The developer configures the IP address of the proxy service and the configured connection port in the local idea development tool, opens the source code consistent with the debugged service and sets a breakpoint, clicks the debug button to start debugging, and views the variables or program operation logic in real time during the program running process to find out the Java service bug information.

[0031] By implementing the management and configuration of the k8s cluster pod service through the proxy service and providing real-time remote debugging of faulty java services, it reduces the complexity of developers debugging cluster services and the difficulty of problem location, which will greatly improve the efficiency of troubleshooting and reducing manpower investment.

[0032] Embodiment 2: A java microservice deployment and debugging method for a k8s cluster, whose principle and implementation method are basically the same as those of Example 1, except that: in the debugging step, the debugged business service is executed by a single user or by multiple users.

[0033] If the business service being debugged is executed by multiple users, the following steps are included: Perform user authentication steps for each user to determine whether the user is an authenticated user. If the user is an authenticated user, the debugging function of the debugged service is enabled for viewing and starting. If the user is not an authenticated user, the debugging function of the debugged service is disabled for viewing and starting. Determine the breakpoints set by each user. If the breakpoints set by each user are different, each user executes their own debugging steps separately. If there are repeated breakpoints set by users, remind the relevant users that there are repeated breakpoints set.

[0034] The design of this solution allows multiple users to perform debugging steps together, and different parts or problems can be processed in parallel, thus speeding up the entire debugging process. At the same time, multiple users analyze problems from different angles and may discover potential problems or solutions that are difficult for a single user to detect. At the same time, if repeated breakpoints are found, reminders will be issued to avoid conflicting debugging operations.

[0035] If there are repeated breakpoints set by users, an allocation step is performed. The allocation step is specifically as follows: for the repeated breakpoints, a user is randomly selected to execute the debugging step, and other users do not execute the debugging step for this breakpoint, or each endpoint is allocated on the principle of allocating the number of breakpoints to each user as evenly as possible; or the allocation step is specifically as follows: for each repeated breakpoint, all users execute the debugging step, and the result of each user executing the debugging step is obtained. If the results are the same, it is determined that the debugging of this breakpoint is completed. If the results are different, the relevant users repeat the debugging steps until the results of the debugging steps are the same, or the debugging result with the largest number of identical results is selected as the debugging result of the breakpoint.

[0036] When multiple users debug the same breakpoint, you can verify the accuracy and consistency of debugging by comparing the debugging results of different users. By debugging multiple times and comparing the results, you can reduce the risk of misjudgment that may occur due to a single debugging.

[0037] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the embodiments disclosed herein. The present application is intended to cover any variations, uses or adaptations of the present application, which follow the general principles of the present application and include common knowledge or customary technical means in the art that are not disclosed in the present application.

[0038] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A method for deploying and debugging java microservices in a k8s cluster. The k8s cluster deploys a java container, which includes several business services. The characteristics are: The method includes deployment steps and debugging steps. The deployment steps include: Add jdwp protocol configuration to the startup command of the java container deployed in the k8s cluster. The jdwp protocol configuration is used to start the java container in debug mode and set up the proxy service in the k8s cluster. The debugging steps include: Configure a proxy service and a connection port. Open the source code consistent with the business service being debugged in the proxy service and set breakpoints. Start debugging and view the variables or program operation logic during program operation.

2. According to claim 1, a java microservice deployment and debugging method for a k8s cluster is characterized in that: In the deployment steps, a proxy service is set in the k8s cluster, specifically: the proxy service provides a UI management interface, the UI management interface is used to view the business services deployed in the k8s cluster, and select the business service to be debugged and configure the connection port.

3. According to a k8s cluster java microservice deployment and debugging method according to claim 1, it is characterized in that: The proxy service includes a user authentication step to determine whether the user is an authenticated user. If the user is an authenticated user, the debugging function of the debugged service is enabled; if the user is not an authenticated user, the debugging function of the debugged service is disabled.

4. According to a k8s cluster java microservice deployment and debugging method according to claim 1, it is characterized in that: In the debugging steps, after debugging is started, breakpoints are dynamically added, modified and deleted, and the breakpoint information before debugging is started is updated.

5. According to a k8s cluster java microservice deployment and debugging method according to claim 1, it is characterized in that: In the debugging step, the business service being debugged is executed by a single user or by multiple users.

6. According to claim 5, a java microservice deployment and debugging method for a k8s cluster is characterized in that: If the business service being debugged is executed by multiple users, the following steps are included: Perform user authentication steps for each user to determine whether the user is an authenticated user. If the user is an authenticated user, the debugging function of the debugged service is enabled; if the user is not an authenticated user, the debugging function of the debugged service is disabled; Determine the breakpoints set by each user. If the breakpoints set by each user are different, each user will perform their own debugging steps respectively. If the breakpoints set by a user are repeated, the relevant users will be reminded that there are repeated breakpoints set.

7. According to claim 6, a java microservice deployment and debugging method for a k8s cluster is characterized in that: If there are repeated breakpoints set by users, an allocation step is performed. The allocation step is specifically as follows: for the repeated breakpoints, a user is randomly selected to execute the debugging step, and other users do not execute the debugging step for this breakpoint, or each endpoint is allocated on the principle of allocating the number of breakpoints to each user as evenly as possible; or the allocation step is specifically as follows: for each repeated breakpoint, all users execute the debugging step, and the result of each user executing the debugging step is obtained. If the results are the same, it is determined that the debugging of this breakpoint is completed. If the results are different, the relevant users repeat the debugging steps until the results of the debugging steps are the same, or the debugging result with the largest number of identical results is selected as the debugging result of the breakpoint.

Images