Hot deployment method and device based on cloud native, computer equipment and storage medium

Abstract

The embodiment of the invention discloses a hot deployment method and device based on cloud native, computer equipment and a storage medium. The method comprises the following steps: when an application is transformed in a POM, tiling a JAR packet of a service by using a shade plug-in; configuring an agent, a script and an environment variable required by hot deployment in the Docker file, compiling a Java file as. Class, and performing product management by taking construction time as a version number; judging whether the selected mode is restarted after Pod drifting or not; if yes, the incremental version is pulled from the OSS, the construction time of the incremental version and the construction time of the mirror image are compared, and when the incremental version is not expired, the content of the JAR package is replaced, and the application is started; and if not, executing the hot deployment script through the agent, comparing the construction time of the product version and the mirror image, and if the product version is not expired, performing hot update and loading the product version into the JVM. By implementing the method provided by the embodiment of the invention, the consistency of service states is ensured, and the high availability of services is ensured.

Description

Technical Field

[0001] The present invention relates to, more specifically, a cloud-native based hot deployment method, apparatus, computer equipment and storage medium. Background Art

[0002] Cloud native is a concept for cloud application design that aims to maximize the advantages of cloud computing. It helps enterprises build elastic, reliable, loosely coupled, easy to manage, and observable application systems, improve delivery efficiency, and reduce operation and maintenance complexity.

[0003] As more and more companies adopt cloud-native technologies such as Kubernetes and Docker, applications have automatic recovery, fault tolerance, and fault isolation capabilities, ensuring the continuous availability of applications. However, this approach also increases the application startup time because in addition to the original code build and application cold start, it is also necessary to deal with steps such as image building, pushing and pulling, which increases the release time. In an emergency, a fast way to go online is needed, that is, hot deployment, but the existing hot deployment method cannot be implemented in a cloud-native environment, nor can it ensure that all Pods remain consistent after Pod drift, and thus cannot guarantee high service availability.

[0004] Therefore, it is necessary to design a new method to implement hot deployment in a cloud-native environment to ensure that all Pods remain in the same state after Pod drift, thereby ensuring high service availability. Summary of the invention

[0005] The purpose of the present invention is to overcome the defects of the prior art and provide a cloud-native based hot deployment method, device, computer equipment and storage medium.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: a cloud-native based hot deployment method, comprising:

[0007] When the application is transformed in POM, the shade plug-in is used to flatten the JAR package of the business;

[0008] Configure the agent, scripts, and environment variables required for hot deployment in Dockerfile, compile Java files into .class, and use the build time as the version number for product management;

[0009] Determine whether the selected mode is restart after Pod drift;

[0010] If the selected mode is restart after Pod drift, the incremental version is pulled from OSS, the incremental version is compared with the build time of the image, and if the incremental version is not expired, the JAR package content is replaced and the application is started;

[0011] If the selected mode is not restart after Pod drift, the hot deployment script is executed through the agent to compare the product version and the build time of the image. If the product version is not expired, it is hot updated and loaded into the JVM.

[0012] The further technical solution is: when the application is transformed in POM, the JAR package of the business is flattened using the shade plug-in, including:

[0013] When the application is transformed in POM, the shade plug-in is used to flatten the business JAR package so that the subsequently updated .class files are placed in the classes folder.

[0014] The further technical solution is: configuring the agent, scripts, and environment variables required for hot deployment in the Dockerfile, compiling the Java file into .class, and using the build time as the version number for product management, including:

[0015] Add the agent, scripts, and environment variables required for hot deployment in Dockerfile;

[0016] Build the application, compile the Java file into a .class file, and manage the artifacts, using the timestamp at the time of build as the version number to form the artifact version.

[0017] A further technical solution is: the environment variables include the application code and the build time of the image.

[0018] The further technical solution is: pulling the incremental version from OSS, comparing the incremental version with the build time of the image, replacing the JAR package content when the incremental version is not expired, and starting the application, including:

[0019] Pull the published incremental version from OSS to obtain the pull result;

[0020] Determine whether the pull result is a released incremental version that can be pulled;

[0021] If the pull result is that the released incremental version can be pulled, compare the effective time of the incremental version with the build time of the image to determine whether the incremental version is expired;

[0022] If the incremental version is not expired, the incremental version replaces the original application JAR package content;

[0023] Start the application JAR package;

[0024] If the incremental version is expired, executing the startup application JAR package;

[0025] If the pulling result is not a released incremental version, the startup application JAR package is executed.

[0026] The further technical solution is: the agent is used to execute the hot deployment script, compare the product version and the build time of the image, and if the product version is not expired, perform hot update and load it into the JVM, including:

[0027] Execute hot deployment scripts through agent;

[0028] Compare the validity period of the product version with the build time of the image to determine whether the product version is expired;

[0029] If the product version is not expired, the .class files are loaded into the JVM one by one through the hot update script.

[0030] The present invention also provides a cloud-native based hot deployment device, including:

[0031] The tiling unit is used to flatten the JAR package of the business using the shade plug-in when the application is transformed in the POM;

[0032] Management unit, used to configure the agent, scripts, and environment variables required for hot deployment in Dockerfile, compile Java files into .class, and manage products using the build time as the version number;

[0033] A judgment unit, used to judge whether the selected mode is restart after Pod drift;

[0034] The restart unit is used to pull the incremental version from OSS if the selected mode is restart after Pod drift, compare the incremental version with the build time of the image, replace the JAR package content when the incremental version is not expired, and start the application;

[0035] The hot deployment unit is used to execute the hot deployment script through the agent if the selected mode is not restart after Pod drift, compare the product version and the build time of the image, and perform hot update and load it into the JVM if the product version is not expired.

[0036] A further technical solution is: the tiling unit is used to tile the JAR package of the business using the shade plug-in when the application is transformed in the POM, so that the subsequently updated .class files are placed in the classes folder.

[0037] The present invention further provides a computer device, which includes a memory and a processor. The memory stores a computer program, and the processor implements the above method when executing the computer program.

[0038] The present invention also provides a storage medium, wherein the storage medium stores a computer program, and the computer program implements the above method when executed by a processor.

[0039] Compared with the prior art, the beneficial effects of the present invention are as follows: the present invention flattens the JAR package of the business by using the shade plug-in, configures the agent, scripts, and environment variables required for hot deployment through Dockerfile, and pulls the incremental version from OSS for replacement, thereby realizing hot deployment in the container pod in a cloud-native environment, and ensuring that the re-started pod can also automatically load the incremental hot update package, thereby ensuring consistent service status and high service availability.

[0040] The present invention is further described below in conjunction with the accompanying drawings and specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying any creative work.

[0042] Figure 1 A schematic diagram of a process of a cloud-native based hot deployment method provided in an embodiment of the present invention;

[0043] Figure 2 A schematic diagram of a sub-process of a cloud-native based hot deployment method provided in an embodiment of the present invention;

[0044] Figure 3 A schematic diagram of a sub-process of a cloud-native based hot deployment method provided in an embodiment of the present invention;

[0045] Figure 4 A schematic diagram of a sub-process of a cloud-native based hot deployment method provided in an embodiment of the present invention;

[0046] Figure 5 A schematic block diagram of a cloud-native based hot deployment device provided in an embodiment of the present invention;

[0047] Figure 6 A schematic block diagram of a management unit of a cloud-native based hot deployment device provided in an embodiment of the present invention;

[0048] Figure 7 A schematic block diagram of a restart unit of a cloud-native based hot deployment device provided in an embodiment of the present invention;

[0049] Figure 8 A schematic block diagram of a hot deployment unit of a cloud-native based hot deployment device provided in an embodiment of the present invention;

[0050] Fig. 9 A schematic block diagram of a computer device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0051] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0052] It should be understood that when used in this specification and the appended claims, the terms "include" and "comprises" indicate the presence of described features, integers, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or combinations thereof.

[0053] It should also be understood that the terms used in this specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention. As used in the specification of the present invention and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" are intended to include plural forms.

[0054] It should be further understood that the term "and / or" used in the present description and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0055] See also Figure 1 , Figure 1 A schematic flow chart of a cloud-native based hot deployment method provided in an embodiment of the present invention. The cloud-native based hot deployment method is applied to a server that interacts with a terminal for data, and is suitable for scenarios where fast and flexible application updates and deployments need to be implemented in a containerized environment. In particular, in a microservice architecture or continuous integration / continuous deployment (CI / CD) process, dynamic updates and management of applications can be effectively implemented.

[0056] Figure 2 Schematic diagram of the process of the cloud-native based hot deployment method provided by an embodiment of the present invention. Figure 2 As shown, the method includes the following steps S110 to S150.

[0057] S110. When the application is transformed in POM, the shade plug-in is used to flatten the JAR package of the business.

[0058] In this embodiment, when the application is modified in the POM, the shade plug-in is used to flatten the JAR package of the business so that the subsequently updated .class files are placed in the classes folder.

[0059] First, the application's POM is transformed, and the shade plug-in is used to "flatten" the business JAR package, that is, to merge the dependent JAR packages into a single JAR package instead of nesting them. In this way, all dependencies can be packaged into one JAR, which simplifies the deployment process and avoids the management and reference of various dependencies. It avoids class loading conflicts that may be caused by dependencies of different versions, and improves the stability and reliability of the application. It reduces the IO overhead during class loading because all classes are packaged into one JAR, which improves the performance of the application. The subsequently updated .class files are placed in the classes folder, so that class files can be easily replaced and updated during hot deployment, realizing fast application updates.

[0060] In general, using the shade plug-in to flatten the business JAR package can simplify the deployment process, improve the stability and performance of the application, and facilitate subsequent hot deployment.

[0061] S120. Configure the agent, scripts, and environment variables required for hot deployment in the Dockerfile, compile the Java file into .class, and use the build time as the version number for product management.

[0062] In one embodiment, see Figure 2 , the above-mentioned step S120 may include steps S121 to S122.

[0063] S121. Add the agent, scripts, and environment variables required for hot deployment in Dockerfile.

[0064] In this embodiment, the environment variables include the application code and the build time of the image.

[0065] S122, build the application, compile the Java file into a .class file, and manage the product, using the timestamp at the time of building as the version number to form a product version.

[0066] In this embodiment, the agent, scripts and environment variables required for hot deployment are first configured in Dockerfile. The environment variables mainly include the application code and the build time of the image; then the application is built, the Java file is compiled into a .class file, and the product is managed, in which the timestamp at the time of the build is used as the version number to form the product version.

[0067] By adding agents, scripts, and environment variables to Dockerfile, the necessary infrastructure and environment support are provided for subsequent hot deployment, allowing hot deployment to proceed smoothly; the timestamp at the time of construction is used as the version number to achieve product version management, so that different versions of the application can be clearly tracked and managed, facilitating version control and backtracking; by using the build time as the version number, it can be ensured that each built image has a unique identifier, thereby improving the traceability and manageability of the deployment, and facilitating troubleshooting and rollback operations.

[0068] In general, the refinement and implementation of this step provides a basis for subsequent application deployment and hot updates, and improves the reliability and maintainability of the system through a reasonable version management strategy.

[0069] S130: Determine whether the selected mode is restart after Pod drift.

[0070] In this embodiment, restarting after Pod drift means that when an application is updated or a configuration change is made, the main idea is to first create a new Pod (a new version of the application), then gradually switch traffic from the old Pod to the new Pod, and finally stop the old Pod. During this process, the application may experience a short interruption or downtime because the new Pod needs to be restarted to apply the changes.

[0071] Hot deployment refers to dynamically applying new code or configuration to a running application without stopping the currently running application. This method can avoid application downtime, but it is necessary to ensure that the hot deployment process does not affect the normal operation of the application. Hot deployment usually requires special technical support, such as using a specific hot deployment tool or framework.

[0072] Choosing which deployment mode to use depends on your specific needs and environment. If your application can tolerate a short downtime and the update process is simple, then restarting after Pod drift may be a simpler and more reliable option. If you need to avoid downtime and have the ability to implement hot deployment, then consider using hot deployment for application updates.

[0073] S140. If the selected mode is restart after Pod drift, an incremental version is pulled from OSS, and the build time of the incremental version and the image is compared. If the incremental version is not expired, the JAR package content is replaced and the application is started.

[0074] In one embodiment, see Figure 3 , the above-mentioned step S140 may include steps S141 to S145.

[0075] S141. Pull the published incremental version from OSS to obtain a pull result.

[0076] In this embodiment, the pull result refers to whether the published incremental version can be pulled.

[0077] Access the object storage service (OSS) to obtain the published incremental version to obtain updated content.

[0078] S142: Determine whether the pulling result is capable of pulling a published incremental version.

[0079] In this embodiment, it is ensured that the published incremental version is successfully pulled from OSS so as to facilitate subsequent updates of the application.

[0080] S143. If the pull result is that the released incremental version can be pulled, compare the validity period of the incremental version with the build time of the image to determine whether the incremental version is expired.

[0081] In this embodiment, the validity period of the pulled incremental version is compared with the build time of the image to determine whether the incremental version is still valid. This can prevent the application from using an expired incremental version and ensure the stability and security of the application.

[0082] S144. If the incremental version is not expired, the incremental version replaces the original application JAR package content.

[0083] In this embodiment, if the incremental version is still valid, its content replaces the JAR package content of the original application to implement the update of the application program.

[0084] S145. Start the application JAR package.

[0085] In this embodiment, the updated application is started to make the update effective.

[0086] If the incremental version is expired, executing step S145;

[0087] If the pulling result does not indicate that a published incremental version can be pulled, step S145 is executed.

[0088] The above steps can quickly obtain the latest application updates by pulling incremental versions from OSS, reducing the time cost of updates; checking the validity of incremental versions avoids the use of expired versions and ensures the stability and security of applications; automating update steps reduces the possibility of manual intervention, reduces the probability of human errors, and improves the reliability and consistency of deployment; downloading only incremental versions instead of the entire application saves bandwidth and storage space and improves the efficiency and speed of updates.

[0089] S150. If the selected mode is not restart after Pod drift, the hot deployment script is executed through the agent to compare the product version and the build time of the image. If the product version is not expired, hot update is performed and loaded into the JVM.

[0090] In one embodiment, see Figure 4 , the above-mentioned step S150 may include steps S151 to S153.

[0091] S151. Execute the hot deployment script through the agent.

[0092] Specifically, an agent is used to execute hot deployment scripts to achieve seamless updates of applications without restarting the entire application or server.

[0093] S152: Compare the validity period of the product version with the build time of the image to determine whether the product version is expired.

[0094] Specifically, the validity period of the product version is compared with the build time of the image to determine whether the product version is still valid. This can avoid using expired versions and ensure the stability and security of the application.

[0095] S153. If the product version is not expired, the .class files are loaded into the JVM one by one through the hot update script.

[0096] Specifically, if the product version is still valid, the updated .class files are loaded into the JVM one by one through the hot update script to implement the hot update of the application.

[0097] The above steps implement application updates through hot deployment scripts without restarting the entire application or server, reducing downtime during the update process and improving system availability and stability. Hot updates are loaded into the JVM, making the update process fast and efficient, allowing users to quickly obtain the latest features and fixed bugs, improving user experience. The validity of the product version is checked to avoid using expired versions and ensure the normal operation of the application. Updated .class files are loaded into the JVM one by one, ensuring the controllability and stability of the update process and avoiding system crashes or performance degradation that may be caused by one-time loading.

[0098] The above-mentioned cloud-native hot deployment method uses the shade plug-in to flatten the JAR package of the business, configures the agent, script, and environment variables required for hot deployment through Dockerfile, and pulls the incremental version from OSS for replacement. While implementing hot deployment in the container pod in a cloud-native environment, it ensures that the re-started pod can also automatically load the incremental hot update package, thereby ensuring consistent service status and high service availability.

[0099] Figure 5 is a schematic block diagram of a cloud-native based hot deployment device 300 provided in an embodiment of the present invention. Figure 5 As shown, corresponding to the above cloud-native based hot deployment method, the present invention also provides a cloud-native based hot deployment device 300. The cloud-native based hot deployment device 300 includes a unit for executing the above cloud-native based hot deployment method, and the device can be configured in a server. Figure 5 The cloud-native-based hot deployment device 300 includes a tiling unit 301 , a management unit 302 , a judgment unit 303 , a restart unit 304 and a hot deployment unit 305 .

[0100] The tiling unit 301 is used to tile the JAR package of the business using the shade plug-in when the application is transformed in the POM; the management unit 302 is used to configure the agent, script, and environment variables required for hot deployment in the Dockerfile, compile the Java file into .class, and manage the product with the build time as the version number; the judgment unit 303 is used to judge whether the selected mode is restart after Pod drift; the restart unit 304 is used to pull the incremental version from OSS if the selected mode is restart after Pod drift, compare the incremental version with the build time of the image, replace the JAR package content when the incremental version is not expired, and start the application; the hot deployment unit 305 is used to execute the hot deployment script through the agent if the selected mode is not restart after Pod drift, compare the build time of the product version and the image, and perform hot update and load it into the JVM if the product version is not expired.

[0101] In one embodiment, the tiling unit 301 is used to flatten the JAR package of the business using the shade plug-in when the application is modified in the POM, so that the subsequently updated .class files are placed in the classes folder.

[0102] In one embodiment, if Figure 6 As shown, the management unit 302 includes an adding subunit 3021 and a product version forming subunit 3022 .

[0103] Add subunit 3021, which is used to add the agent, scripts and environment variables required for hot deployment in Dockerfile; the product version formation subunit 3022 is used to build the application, compile the Java file into .class file, and manage the product, using the timestamp at the time of construction as the version number to form the product version.

[0104] In one embodiment, if Figure 7 As shown, the restart unit 304 includes a pulling subunit 3041 , a pulling determination subunit 3042 , a first comparing subunit 3043 , a replacing subunit 3044 and a starting subunit 3045 .

[0105] The pulling subunit 3041 is used to pull the published incremental version from the OSS to obtain a pulling result; the pulling judgment subunit 3042 is used to judge whether the pulling result is able to pull the published incremental version; if the pulling result is not able to pull the published incremental version, the startup application JAR package is executed; the first comparison subunit 3043 is used to compare the effective time of the incremental version and the build time of the image to judge whether the incremental version is expired if the pulling result is able to pull the published incremental version; if the incremental version is expired, the startup application JAR package is executed; the replacement subunit 3044 is used to replace the original application JAR package content with the incremental version if the incremental version is not expired; the startup subunit 3045 is used to start the application JAR package.

[0106] In one embodiment, if Figure 8 As shown, the hot deployment unit 305 includes an execution subunit 3051 , a second comparison subunit 3052 , and a hot update subunit 3053 .

[0107] The execution subunit 3051 is used to execute the hot deployment script through the agent; the second comparison subunit 3052 is used to compare the effective time of the product version and the build time of the image to determine whether the product version is expired; the hot update subunit 3053 is used to load the .class files one by one into the JVM through the hot update script if the product version is not expired.

[0108] It should be noted that technical personnel in the relevant field can clearly understand that the specific implementation process of the above-mentioned cloud-native hot deployment device 300 and each unit can refer to the corresponding description in the aforementioned method embodiment, and for the convenience and conciseness of the description, it will not be repeated here.

[0109] The cloud-native based hot deployment device 300 can be implemented in the form of a computer program. Fig. 9 Runs on the computer device shown.

[0110] See also Fig. 9 , Fig. 9 5 is a schematic block diagram of a computer device provided in an embodiment of the present application. The computer device 500 may be a server, wherein the server may be an independent server or a server cluster composed of multiple servers.

[0111] See also Fig. 9 The computer device 500 includes a processor 502 , a memory and a network interface 505 connected via a system bus 501 , wherein the memory may include a non-volatile storage medium 503 and an internal memory 504 .

[0112] The non-volatile storage medium 503 may store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions, and when the program instructions are executed, the processor 502 may execute a cloud-native-based hot deployment method.

[0113] The processor 502 is used to provide computing and control capabilities to support the operation of the entire computer device 500 .

[0114] The internal memory 504 provides an environment for the operation of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a cloud-native-based hot deployment method.

[0115] The network interface 505 is used to communicate with other devices over the network. Fig. 9 The structure shown in the figure is merely a block diagram of a portion of the structure related to the solution of the present application, and does not constitute a limitation on the computer device 500 to which the solution of the present application is applied. The specific computer device 500 may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0116] The processor 502 is used to run the computer program 5032 stored in the memory to implement the following steps:

[0117] When the application is transformed in POM, the shade plug-in is used to flatten the JAR package of the business; the agent, script, and environment variables required for hot deployment are configured in Dockerfile, the Java file is compiled into .class, and the product management is performed with the build time as the version number; it is determined whether the selected mode is restart after Pod drift; if the selected mode is restart after Pod drift, the incremental version is pulled from OSS, the build time of the incremental version and the image is compared, and when the incremental version is not expired, the JAR package content is replaced and the application is started; if the selected mode is not restart after Pod drift, the hot deployment script is executed through the agent, the build time of the product version and the image is compared, and if the product version is not expired, it is hot updated and loaded into the JVM.

[0118] In one embodiment, when the processor 502 implements the step of transforming the application in the POM and flattening the JAR package of the business using the shade plug-in, the processor 502 specifically implements the following steps:

[0119] When the application is transformed in POM, the shade plug-in is used to flatten the business JAR package so that the subsequently updated .class files are placed in the classes folder.

[0120] In one embodiment, the processor 502 implements the following steps when configuring the agent, script, and environment variables required for hot deployment in the Dockerfile, compiling the Java file into .class, and using the build time as the version number to manage the product:

[0121] Add the agent, scripts, and environment variables required for hot deployment in Dockerfile; build the application, compile the Java file into a .class file, and manage the product, using the timestamp at the time of the build as the version number to form the product version.

[0122] The environment variables include the application code and the build time of the image.

[0123] In one embodiment, the processor 502 implements the following steps when implementing the steps of pulling the incremental version from the OSS, comparing the incremental version with the build time of the image, replacing the JAR package content when the incremental version is not expired, and starting the application:

[0124] Pull the published incremental version from OSS to obtain a pull result; determine whether the pull result is able to pull the published incremental version; if the pull result is able to pull the published incremental version, compare the effective time of the incremental version with the build time of the image to determine whether the incremental version is expired; if the incremental version is not expired, replace the original application JAR package content with the incremental version; start the application JAR package; if the incremental version is expired, execute the startup application JAR package; if the pull result is not able to pull the published incremental version, execute the startup application JAR package.

[0125] In one embodiment, the processor 502 specifically implements the following steps when executing the hot deployment script through the agent, comparing the product version and the build time of the image, and performing hot update and loading into the JVM if the product version is not expired:

[0126] Execute the hot deployment script through the agent; compare the effective time of the product version and the build time of the image to determine whether the product version is expired; if the product version is not expired, load the .class files one by one into the JVM through the hot update script.

[0127] It should be understood that in the embodiment of the present application, the processor 502 may be a central processing unit (CPU), and the processor 502 may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0128] It can be understood by those skilled in the art that all or part of the processes in the method for implementing the above embodiment can be completed by instructing the relevant hardware through a computer program. The computer program includes program instructions, and the computer program can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiment of the above method.

[0129] Therefore, the present invention also provides a storage medium. The storage medium may be a computer-readable storage medium. The storage medium stores a computer program, wherein when the computer program is executed by a processor, the processor executes the following steps:

[0130] When the application is transformed in POM, the shade plug-in is used to flatten the JAR package of the business; the agent, script, and environment variables required for hot deployment are configured in Dockerfile, the Java file is compiled into .class, and the product management is performed with the build time as the version number; it is determined whether the selected mode is restart after Pod drift; if the selected mode is restart after Pod drift, the incremental version is pulled from OSS, the build time of the incremental version and the image is compared, and when the incremental version is not expired, the JAR package content is replaced and the application is started; if the selected mode is not restart after Pod drift, the hot deployment script is executed through the agent, the build time of the product version and the image is compared, and if the product version is not expired, it is hot updated and loaded into the JVM.

[0131] In one embodiment, when the processor executes the computer program to implement the step of transforming the application in the POM and flattening the JAR package of the business using the shade plug-in, the following steps are specifically implemented:

[0132] When the application is transformed in POM, the shade plug-in is used to flatten the business JAR package so that the subsequently updated .class files are placed in the classes folder.

[0133] In one embodiment, when the processor executes the computer program to configure the agent, script, and environment variables required for hot deployment in the Dockerfile, compile the Java file into .class, and use the build time as the version number to perform product management steps, the following steps are specifically implemented:

[0134] Add the agent, scripts, and environment variables required for hot deployment in Dockerfile; build the application, compile the Java file into a .class file, and manage the product, using the timestamp at the time of the build as the version number to form the product version.

[0135] The environment variables include the application code and the build time of the image.

[0136] In one embodiment, when the processor executes the computer program to implement the steps of pulling the incremental version from the OSS, comparing the incremental version with the build time of the image, replacing the JAR package content when the incremental version is not expired, and starting the application, the following steps are specifically implemented:

[0137] Pull the published incremental version from OSS to obtain a pull result; determine whether the pull result is able to pull the published incremental version; if the pull result is able to pull the published incremental version, compare the effective time of the incremental version with the build time of the image to determine whether the incremental version is expired; if the incremental version is not expired, replace the original application JAR package content with the incremental version; start the application JAR package; if the incremental version is expired, execute the startup application JAR package; if the pull result is not able to pull the published incremental version, execute the startup application JAR package.

[0138] In one embodiment, when the processor executes the computer program to implement the steps of executing the hot deployment script through the agent, comparing the product version and the build time of the image, and performing hot update and loading into the JVM if the product version is not expired, the processor specifically implements the following steps:

[0139] Execute the hot deployment script through the agent; compare the effective time of the product version and the build time of the image to determine whether the product version is expired; if the product version is not expired, load the .class files one by one into the JVM through the hot update script.

[0140] The storage medium may be a USB flash drive, a mobile hard disk, a read-only memory (ROM), a magnetic disk, or an optical disk, etc., which are computer-readable storage media that can store program codes.

[0141] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0142] In the several embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of each unit is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed.

[0143] The steps in the method of the embodiment of the present invention can be adjusted in order, combined and deleted according to actual needs. The units in the device of the embodiment of the present invention can be combined, divided and deleted according to actual needs. In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0144] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, terminal, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention.

[0145] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present invention, and these modifications or replacements should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. A hot deployment method based on cloud native, characterized in that: include: When the application is transformed in POM, the shade plug-in is used to flatten the JAR package of the business; Configure the agent, scripts, and environment variables required for hot deployment in Dockerfile, compile Java files into .class, and use the build time as the version number for product management; Determine whether the selected mode is restart after Pod drift; If the selected mode is restart after Pod drift, the incremental version is pulled from OSS, the incremental version is compared with the build time of the image, and if the incremental version is not expired, the JAR package content is replaced and the application is started; If the selected mode is not restart after Pod drift, the hot deployment script is executed through the agent to compare the product version and the build time of the image. If the product version is not expired, it is hot updated and loaded into the JVM.

2. The cloud-native based hot deployment method according to claim 1, characterized in that: When the application is transformed in POM, the shade plug-in is used to flatten the JAR package of the business, including: When the application is transformed in POM, the shade plug-in is used to flatten the business JAR package so that the subsequently updated .class files are placed in the classes folder.

3. The cloud-native based hot deployment method according to claim 1, characterized in that: The agent, scripts, and environment variables required for hot deployment are configured in the Dockerfile, the Java file is compiled into .class, and the product management is performed using the build time as the version number, including: Add the agent, scripts, and environment variables required for hot deployment in Dockerfile; Build the application, compile the Java file into a .class file, and manage the artifacts, using the timestamp at the time of build as the version number to form the artifact version.

4. The cloud-native based hot deployment method according to claim 3, characterized in that: The environment variables include the application code and the build time of the image.

5. The cloud-native based hot deployment method according to claim 4, characterized in that: Pulling the incremental version from OSS, comparing the incremental version with the build time of the image, replacing the JAR package content when the incremental version is not expired, and starting the application include: Pull the published incremental version from OSS to obtain the pull result; Determine whether the pull result is a released incremental version that can be pulled; If the pull result is that the released incremental version can be pulled, compare the effective time of the incremental version with the build time of the image to determine whether the incremental version is expired; If the incremental version is not expired, the incremental version replaces the original application JAR package content; Start the application JAR package; If the incremental version is expired, executing the startup application JAR package; If the pulling result is not a released incremental version, the startup application JAR package is executed.

6. The cloud-native based hot deployment method according to claim 4, characterized in that: The hot deployment script is executed by the agent to compare the product version and the build time of the image. If the product version is not expired, hot update is performed and loaded into the JVM, including: Execute hot deployment scripts through agent; Compare the validity period of the product version with the build time of the image to determine whether the product version is expired; If the product version is not expired, the .class files are loaded into the JVM one by one through the hot update script.

7. A hot deployment device based on cloud native, characterized in that: include: The tiling unit is used to flatten the JAR package of the business using the shade plug-in when the application is transformed in the POM; Management unit, used to configure the agent, scripts, and environment variables required for hot deployment in Dockerfile, compile Java files into .class, and manage products using the build time as the version number; A judgment unit, used to judge whether the selected mode is restart after Pod drift; The restart unit is used to pull the incremental version from OSS if the selected mode is restart after Pod drift, compare the incremental version with the build time of the image, replace the JAR package content when the incremental version is not expired, and start the application; The hot deployment unit is used to execute the hot deployment script through the agent if the selected mode is not restart after Pod drift, compare the product version and the build time of the image, and perform hot update and load it into the JVM if the product version is not expired.

8. The cloud-native based hot deployment device according to claim 7, characterized in that: The tiling unit is used to tile the JAR package of the business using the shade plug-in when the application is transformed in the POM, so that the subsequently updated .class files are placed in the classes folder.

9. A computer device, characterized in that: The computer device comprises a memory and a processor, the memory stores a computer program, and the processor implements the method according to any one of claims 1 to 6 when executing the computer program.

10. A storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images