Spring application non-stop update method based on container-level hot replacement

Abstract

The application provides a Spring application non-stop updating method based on container-level hot replacement, which comprises the following sub-steps: S1, system initialization; S2, starting a container instance to enter an updating state and providing formal external service; S3, performing container-level hot updating; S4, performing atomic container switching; S5, starting an asynchronous resource recycling thread; and S6, cleaning JAR files and class loaders. The method takes a complete Spring container as a replacement unit, supports full modification of various components and class structures, atomically switches after a new context is created, completes Bean assembly, AOP and routing refreshing, adapts to a Spring native mechanism, is developed based on a standard specification, does not depend on commercial tools, has good ecological compatibility and low landing cost.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method for non-stop updating of Spring applications based on container-level hot replacement. Background Technology

[0002] With the rapid development of internet businesses, the requirements for continuous and stable operation of online services are constantly increasing. System downtime and maintenance due to version updates can directly lead to a decline in user experience, business interruption, and economic losses. Spring Boot, as a mainstream enterprise-level web development framework, is widely used to build high-concurrency backend services, but its traditional update method heavily relies on restarting the entire JVM process, which has the following drawbacks in actual production: (1) Service interruption: During the restart process, the Servlet container and Spring container stop synchronously, and all business requests cannot be responded to, resulting in the service being completely unavailable; (2) Cold start delay: After restarting, all classes need to be reloaded, Spring Beans need to be fully initialized, and database and middleware connections need to be rebuilt. System recovery takes a long time and the initial response delay is high. (3) Difficulty in gray-scale release: It does not support gradual switching of traffic and parallel operation of versions, and cannot achieve smooth version upgrades and rollbacks, and the release risk is uncontrollable; To mitigate downtime issues, most existing hot update technologies employ class-level bytecode replacement schemes, attempting to modify code without restarting the JVM. However, these schemes have the following drawbacks: 1. Limited scope of support: It can only modify the method logic of existing classes, does not support changes to class structure, cannot add or delete components, and does not support structural adjustments such as annotations, fields, and interfaces; 2. Incompatible with Spring container mechanism: It cannot handle scenarios such as Bean definition refresh, dependency injection rebuild, AOP proxy generation, and MVC route mapping update within the Spring container. After the update, problems such as component not working, route failure, and transaction exception are likely to occur. 3. High cost and poor compatibility: Existing solutions are mostly commercial tools with high licensing costs, and they are often deeply bound to specific IDEs and development environments, resulting in insufficient compatibility with the standard Spring ecosystem and strong intrusion. Summary of the Invention

[0003] The purpose of this invention is to address the shortcomings of existing technologies by proposing a non-downtime update method for Spring applications based on container-level hot replacement.

[0004] To achieve the above objectives, the present invention adopts the following technical solution: S1: System initialization; S11: Creation and configuration of embedded Servlet container instances; An embedded Servlet container instance is created using the embedded Servlet container factory component, and the corresponding basic runtime parameters are configured. These basic runtime parameters include the HTTP listening port and the temporary working directory. S12: Spring Web Application Context Instance Creation; Call the generic web application context implementation class provided by the Spring framework to create an initial Spring web application context instance as a placeholder context; S13: Create the application scheduling Servlet and complete its registration and path mapping; Create a custom application dispatch Servlet instance that inherits from the DispatcherServlet class of the Spring framework; During the construction and initialization of the application dispatch Servlet instance, access permissions to the web application context fields inside the parent class DispatcherServlet are preserved; Register the application scheduling Servlet instance to the ServletContext of the embedded Servlet container instance created in step S11, and map the application scheduling Servlet instance to the default URL pattern; S14: Create and update the Servlet and complete its registration and path mapping; Create an updated Servlet instance, which holds a strong reference to the application scheduling Servlet instance; register it with the ServletContext of the embedded Servlet container instance created in step S11, and map the updated Servlet instance to a specific management path.

[0005] S2: Start the container instance to enter the pending update state and provide official external services; Start the embedded Servlet container instance created in step S11; The application scheduling Servlet instance uses the Spring Web application context instance created in step S12 to handle HTTP requests and returns the default maintenance page; The Servlet instance is ready to be updated and is waiting to receive the hot update command; the system enters the pending update state. Once the new Spring Web application context instance is loaded, all HTTP requests are routed and processed by the application scheduling Servlet instance based on the currently valid Web application context instance.

[0006] S3: Perform container-level hot updates; When a full update of online business logic is required, container-level hot replacement can be completed using the following steps: S31: Upload the JAR file to the management path for updating the Servlet instance; Operations personnel or automated deployment systems upload a JAR file containing complete new business code to the management path corresponding to the registered update Servlet instance; The JAR file contains the compiled business class files, resource files, and the META-INF / MANIFEST.MF file; S32: Receives the JAR file and generates the absolute path and a unique update task ID; The Servlet instance receives the uploaded JAR file in step S31 and generates a unique temporary filename; the JAR file is written to the system's temporary working directory; the system is a Spring application non-stop update system based on container-level hot replacement. The absolute path of this JAR file is obtained by concatenating the temporary working directory with the unique temporary file name, and a unique update task ID is generated at the same time. S33: Create an instance named HotUpdateClassLoader; Retrieve the context class loader bound to the currently executing thread as the parent loader, and create a URL class loader instance named "Hot Update Class Loader" based on the absolute path of the JAR file obtained in step S32. S34: Parse the file and load the main configuration class; The hot-update class loader instance parses the META-INF / MANIFEST.MF file in the JAR file and reads the Start-Class property value generated by the Maven plugin in the META-INF / MANIFEST.MF file; the Start-Class property value points to the main configuration class with annotations. Use a hot-reload class loader instance to load the main configuration class pointed to by the Start-Class attribute value; S35: Create and configure a web application context instance; Create a web application context instance of type AnnotationConfigServletWebServerApplicationContext, and configure the web application context instance as follows: Set the hot-update class loader instance as the class loader of the web application context instance; Register the main configuration class obtained in step S34 to the Web application context instance; The refresh method is called to initialize the web application context instance. The main configuration class reads the relevant business classes in the JAR file and registers the relevant components. The relevant components are configured with corresponding access path information. After configuration, the new Web application context instance is built.

[0007] S4: Perform an atomic-level container switch; Get the Web application context field contained in the application scheduling Servlet instance, and read the original legacy Web application context instance bound to the Web application context field; Under lock protection, the original old version of the Web application context instance bound to the Web application context field is switched to the new version of the Web application context instance built in step S35; Call the application dispatcher Servlet.init method to load the relevant components registered in step S35 and force the reconstruction of the dispatch components. The access path mapping corresponding to the relevant components will take effect immediately. The distribution components include HandlerMappings, HandlerAdapters, etc.

[0008] S5: Start the asynchronous resource reclamation thread; Create a thread instance, call the setDaemon function to mark the thread instance as a daemon thread, start the daemon thread and wait for a preset time until all requests processed based on the original old version of the web application context instance (such as long polling, asynchronous Servlet processing) have been completed. After the delay period ends, the daemon thread calls the close method of the original old web application context instance to safely reclaim the relevant business resources. S6: Clean up JAR files and class loaders; After the resources of the original old web application context instance are reclaimed, delete the JAR files generated by this update; Assigning a reference variable pointing to a hot-update class loader instance to null will cause the JVM garbage collector to unload the hot-update class loader instance and its loaded old business classes that are no longer associated with the reference.

[0009] Compared with the prior art, the beneficial effects of the present invention are as follows: This method uses a complete Spring container as the replacement unit, supports adding, deleting, and modifying any business component, supports full changes to annotations, fields, interfaces, class structures, etc., and achieves business version-level hot updates; By completely rebuilding the Spring application context and performing atomic container switching, Bean registration, dependency injection, AOP proxy generation, and MVC route mapping reconstruction are completed. This ensures full compatibility with the native Spring container runtime mechanism, guarantees that all core Spring features take effect normally, and avoids problems such as route failure, transaction exceptions, and component failure. This method is based on the standard Spring and Servlet specifications, requires no commercial tools, is not bound to a specific IDE, does not intrude on business code, is compatible with the native Spring ecosystem, and has low integration cost, strong versatility, and high stability. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating the steps of the container-level hot-swap-based Spring application non-downtime update method proposed in this invention. Detailed Implementation

[0011] To provide a further understanding of the purpose, structure, features, and functions of the present invention, detailed descriptions are provided below with reference to specific embodiments.

[0012] Please refer to the reference. Figure 1 This invention provides a method for non-downtime updates of Spring applications based on container-level hot-swapping; The non-downtime update method for Spring applications based on container-level hot replacement includes the following sub-steps: S1: System initialization; S11: Creation and configuration of embedded Servlet container instances; An embedded Servlet container instance is created using the embedded Servlet container factory component, and the corresponding basic runtime parameters are configured. These basic runtime parameters include the HTTP listening port, temporary working directory, context path, session management strategy, etc. Specifically, when Tomcat is used as the underlying embedded Servlet container, the TomcatEmbeddedServletContainerFactory factory component is used to create an embedded Servlet container instance; When using Jetty as the underlying embedded Servlet container, the JettyEmbeddedServletContainerFactory component is used to create an instance of the embedded Servlet container. S12: Spring Web Application Context Instance Creation; Call the generic web application context implementation class provided by the Spring framework to create an initial Spring web application context instance as a placeholder context; S13: Create and configure an application dispatch Servlet instance; Create a custom application dispatch Servlet instance that inherits from the DispatcherServlet class of the Spring framework; During the construction and initialization of the application dispatch Servlet instance, access permissions to the web application context fields inside the parent class DispatcherServlet are preserved through the protected setter assignment method; Register the application scheduling Servlet instance to the ServletContext of the embedded Servlet container instance created in step S11, and map the application scheduling Servlet instance to the default URL pattern; S14: Create and update the Servlet and complete its registration and path mapping; Create an update Servlet instance, which holds a strong reference to the application scheduling Servlet instance; register it in the ServletContext of the embedded Servlet container instance created in step S11, and map the update Servlet instance to a specific management path (such as / hotswap / update).

[0013] S2: Start the container instance to enter the pending update state and provide official external services; Start the embedded Servlet container instance created in step S11; The application scheduling Servlet instance uses the Spring Web application context instance created in step S12 to handle HTTP requests and returns the default maintenance page; The Servlet instance is ready to be updated and is waiting to receive the hot update command; the system enters the pending update state. Once the new Spring Web application context instance is loaded, all HTTP requests are routed and processed by the application scheduling Servlet instance based on the currently valid Web application context instance.

[0014] S3: Perform container-level hot updates; When a full update of online business logic is required (without stopping the application or restarting the JVM), container-level hot replacement can be performed using the following steps: S31: Upload the JAR file to the management path for updating the Servlet instance; Operations personnel or automated deployment systems upload a JAR file containing complete new business code to the management path (i.e., management endpoint, such as / hotswap / update) corresponding to the registered update Servlet instance; The JAR file contains the compiled business class files, resource files, and the META-INF / MANIFEST.MF file; S32: Receives the JAR file and generates the absolute path and a unique update task ID; The Servlet instance receives the uploaded JAR file in step S31 and generates a unique temporary filename; the JAR file is written to the system's temporary working directory; the system is a Spring application non-stop update system based on container-level hot replacement. The absolute path of this JAR file is obtained by concatenating the temporary working directory with the unique temporary file name, and a unique update task ID is generated at the same time. S33: Create an instance named HotUpdateClassLoader; Retrieve the context class loader bound to the currently executing thread as the parent loader, and create a URL class loader instance named "Hot Update Class Loader" based on the absolute path of the JAR file obtained in step S32. (Among them, the hot update class loader instance is used to load the complete new business code of the JAR file, while the parent class loader is used to load the application's original framework code;) S34: Parse the file and load the main configuration class; The hot-reload class loader instance parses the META-INF / MANIFEST.MF file in the JAR file and reads the Start-Class property value generated by the Maven plugin in the META-INF / MANIFEST.MF file; the Start-Class property value points to the main configuration class with the annotation (@SpringBootApplication); Use a hot-reload class loader instance to load the main configuration class pointed to by the Start-Class attribute value; S35: Create and configure a web application context instance; Create a web application context instance of type AnnotationConfigServletWebServerApplicationContext, and configure the web application context instance as follows: Set the hot-update class loader instance as the class loader of the web application context instance; Register the main configuration class obtained in step S34 to the Web application context instance; The refresh method is called to initialize the web application context instance. The main configuration class reads the relevant business classes in the JAR file and registers the relevant components. The relevant components are configured with corresponding access path information. After configuration, the new Web application context instance is built.

[0015] S4: Perform an atomic-level container switch; Obtain the Web application context field contained in the application scheduling Servlet instance, wherein the Web application context field is a protected attribute; Read the legacy web application context instance bound to the web application context field; Under lock protection, the original old version of the Web application context instance bound to the Web application context field is switched to the new version of the Web application context instance built in step S35; Call the application dispatcher Servlet.init method to load the relevant components registered in step S35 and force the reconstruction of the dispatch components. The access path mapping corresponding to the relevant components will take effect immediately. The distribution components include HandlerMappings, HandlerAdapters, etc.

[0016] By ensuring that business logic switching is completed in an extremely short time (microseconds), only a very small number of requests may be briefly blocked or retried due to the context switching interval, without affecting the overall service continuity.

[0017] S5: Start the asynchronous resource reclamation thread; Create a thread instance, call the setDaemon function to mark the thread instance as a daemon thread, start the daemon thread and wait for a preset time until all requests processed based on the original old version of the web application context instance (such as long polling, asynchronous Servlet processing) have been completed. After the delay period ends, the daemon thread calls the close method of the original old web application context instance to safely reclaim the relevant business resources. S6: Clean up JAR files and class loaders; After the resources of the original old web application context instance are reclaimed, delete the JAR files generated by this update; Assigning a reference variable pointing to a hot-update class loader instance to null will cause the JVM garbage collector to unload the hot-update class loader instance and its loaded old business classes that are no longer associated with the reference.

[0018] This invention allows updates to be initiated simply by uploading a JAR file via an HTTP interface, adapting to automated release processes and offering convenient deployment and maintenance. It utilizes an independent class loader to isolate old and new business code, avoiding class version conflicts and static pollution issues. Combined with a delayed garbage collection mechanism, it prevents memory leaks in the metaspace, improving system stability. The update process does not require restarting the container or JVM, and long-lived connections and asynchronous requests can be continuously executed, adapting to high-availability, long-connection business scenarios and broadening the applicability of the solution.

[0019] The present invention has been described by the above-described embodiments; however, these embodiments are merely examples for implementing the present invention. It must be noted that the disclosed embodiments do not limit the scope of the present invention. Conversely, any modifications and refinements made without departing from the spirit and scope of the present invention are within the scope of patent protection of the present invention.

Claims

1. A non-downtime update method for Spring applications based on container-level hot-swapping, characterized in that: Includes the following sub-steps: S1: System initialization; S11: Creation and configuration of embedded Servlet container instances; S12: Spring Web Application Context Instance Creation; S13: Create the application scheduling Servlet and complete its registration and path mapping; S14: Create and update the Servlet and complete its registration and path mapping; S2: Start the instance, the system enters the pending update state and provides official external services; S3: Perform container-level hot updates; S31: Upload the JAR file to the management path for updating the Servlet instance; S32: Receives the JAR file and generates the absolute path and a unique update task ID; S33: Create an instance named HotUpdateClassLoader; S34: Parse the file and load the main configuration class; S35: Create and configure a web application context instance; S4: Perform an atomic-level container switch; S5: Start the asynchronous resource reclamation thread; S6: Clean up JAR files and class loaders.

2. The Spring application non-downtime update method based on container-level hot replacement as described in claim 1, characterized in that: The specific details of step S1 are as follows: S11: Creation and configuration of embedded Servlet container instances; An embedded Servlet container instance is created using the embedded Servlet container factory component, and the corresponding basic runtime parameters are configured. These basic runtime parameters include the HTTP listening port and the temporary working directory. S12: Spring Web Application Context Instance Creation; An initial Spring Web Application Context instance is created as a placeholder context through the generic Web Application Context implementation class; S13: Create the application scheduling Servlet and complete its registration and path mapping; Create a custom application dispatch Servlet instance that inherits from the DispatcherServlet class of the Spring framework; During the construction and initialization of the application dispatch Servlet instance, access permissions to the web application context fields inside the parent class DispatcherServlet are preserved; Register the application scheduling Servlet instance to the ServletContext of the embedded Servlet container instance created in step S11, and map the application scheduling Servlet instance to the default URL pattern; S14: Create and update the Servlet and complete its registration and path mapping; Create an updated Servlet instance, which holds a strong reference to the application scheduling Servlet instance; register it with the ServletContext of the embedded Servlet container instance created in step S11, and map the updated Servlet instance to a specific management path.

3. The Spring application non-downtime update method based on container-level hot replacement as described in claim 1, characterized in that: In step S2, the embedded Servlet container instance created in step S11 is started; The application scheduling Servlet instance uses the Spring Web application context instance created in step S12 to handle HTTP requests and returns the default maintenance page; The Servlet instance is ready to be updated and is waiting to receive the hot update command; the system enters the pending update state. Once the new Spring Web application context instance is loaded, all HTTP requests are routed and processed by the application scheduling Servlet instance based on the currently valid Web application context instance.

4. The Spring application non-downtime update method based on container-level hot replacement as described in claim 1, characterized in that: The specific details of step S3 are as follows: S31: Upload the JAR file to the management path for updating the Servlet instance; Operations personnel or automated deployment systems upload a JAR file containing complete new business code to the management path corresponding to the registered update Servlet instance; The JAR file contains the compiled business class files, resource files, and the META-INF / MANIFEST.MF file; S32: Receives the JAR file and generates the absolute path and a unique update task ID; Update the Servlet instance to receive the uploaded JAR file in step S31, generate a unique temporary filename, and write the JAR file to the system's temporary working directory; The system is a container-level hot-swap Spring application non-stop update system; The absolute path of this JAR file is obtained by concatenating the temporary working directory with the unique temporary file name, and a unique update task ID is generated at the same time. S33: Create an instance named HotUpdateClassLoader; Retrieve the context class loader bound to the currently executing thread as the parent loader, and create a URL class loader instance named "Hot Update Class Loader" based on the absolute path of the JAR file obtained in step S32. S34: Parse the file and load the main configuration class; The hot-update class loader instance parses the META-INF / MANIFEST.MF file in the JAR file and reads the Start-Class property value generated by the Maven plugin in the META-INF / MANIFEST.MF file; the Start-Class property value points to the main configuration class with annotations. Use a hot-reload class loader instance to load the main configuration class pointed to by the Start-Class attribute value; S35: Create and configure a web application context instance; Create a web application context instance of type AnnotationConfigServletWebServerApplicationContext, and configure the web application context instance as follows: Set the hot update class loader instance as the class loader of the Web application context instance; register the main configuration class obtained in step S34 to the Web application context instance; complete the initialization of the Web application context instance, read the relevant business classes in the JAR file through the main configuration class and register the relevant components, and the relevant components are configured with corresponding access path information; After configuration, the new Web application context instance is built.

5. The Spring application non-downtime update method based on container-level hot replacement as described in claim 1, characterized in that: In step S4, the Web application context field contained in the application scheduling Servlet instance is obtained; Read the legacy web application context instance bound to the web application context field; Under lock protection, the original old version of the Web application context instance bound to the Web application context field is switched to the new version of the Web application context instance built in step S35; The application dispatcher Servlet.init method is called to load the relevant components registered in step S35 and force the reconstruction of the dispatch components. The access path mapping corresponding to the relevant components takes effect immediately.

6. The method for non-downtime update of Spring applications based on container-level hot replacement as described in claim 1, characterized in that: In step S5, a thread instance is created, the thread instance is marked as a daemon thread, the daemon thread is started and waits for a preset time until all requests processed based on the original old version of the web application context instance have been completed; after the delay ends, the daemon thread calls the close method of the original old version of the web application context instance to complete the safe reclamation of related business resources.

7. The Spring application non-downtime update method based on container-level hot replacement as described in claim 1, characterized in that: In step S6, after the resources of the original old version of the Web application context instance have been recycled, the JAR file generated by this update is deleted; Assigning a reference variable pointing to a hot-update class loader instance to null will cause the JVM garbage collector to unload the hot-update class loader instance and its loaded old business classes that are no longer associated with the reference.

Images