Java application lightweight deployment system and method based on dependency stability grading

Abstract

The invention discloses a Java application lightweight deployment system and method based on dependency stability grading, and relates to the technical field of software deployment, and the method comprises the following steps: collecting dependency metadata, and generating a dependency list description file; packaging the Java application service code and the internal runtime library into a service code file, forming a service code ciphertext file, and generating a lightweight application deployment package; constructing a basic container mirror image, pulling the basic container mirror image and a lightweight application deployment package, decrypting a service code ciphertext file, downloading missing dependency and verifying a dependency fingerprint, and starting a SpringBoot application; and collecting dependency operation data, generating and issuing an incremental updating plan, executing the incremental updating plan, and updating the dependency stability score and the dependency stability level. And the stability of the deployment carrier and the operation reliability of the Java application are improved.

Description

Technical Field

[0001] This invention relates to the field of software deployment technology, and in particular to a lightweight deployment system and method for Java applications based on dependency stability grading. Background Technology

[0002] In cloud-native and microservice architectures, Java applications typically use Maven tools for building and dependency management, and are deployed using Spring Boot executables and container images. The container orchestration platform is responsible for elastic scaling and multi-replica scheduling. To improve delivery efficiency, a complete set of dependencies is pre-configured in the image. A unified artifact repository and dependency management center are used to centrally maintain dependency version information and metadata, providing support for continuous integration delivery and cross-environment deployment of large-scale business applications.

[0003] Conventional deployment schemes still have room for improvement. On the one hand, conventional deployment schemes organize dependencies from the perspective of application functions, select dependency combinations based on version numbers and experience, and lack quantitative assessment and grading strategies for dependency stability. As a result, it is difficult to effectively control the phenomenon of image size expansion and dependency redundancy. On the other hand, there is a lack of a closed-loop adjustment mechanism based on runtime data between the build and runtime phases. The dependency update strategy cannot be linked with observation data such as exception logs and rollback records, which is not conducive to achieving lightweight deployment and improving operation and maintenance efficiency. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a lightweight deployment method for Java applications based on dependency stability grading to solve the problems of existing technologies lacking quantitative grading and selection mechanisms for dependency stability and the difficulty in achieving synergy between incremental dependency updates and lightweight deployment.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, the present invention provides a lightweight deployment method for Java applications based on dependency stability grading, which includes, Collect dependency metadata, calculate dependency stability scores, classify dependency stability levels, and generate dependency manifest description files; Based on the dependency stability level in the dependency manifest description file, a lightweight packaging plan is generated, which packages the Java application business code and internal runtime libraries into a business code file, forms a business code encrypted file, and generates a lightweight application deployment package. Build a base container image, pre-configure dependency files, pull the base container image and lightweight application deployment package, decrypt the encrypted business code file, download missing dependencies and verify dependency fingerprints according to the dependency manifest description file, start the Spring Boot application, and form a runtime instance. In the runtime instance, dependency runtime data is collected, an incremental update plan is generated and distributed, and when the application restarts, the ClientPreparer program executes the incremental update plan to update the dependency stability score and dependency stability level.

[0007] As a preferred embodiment of the lightweight deployment method for Java applications based on dependency stability grading described in this invention, the collection of dependency metadata includes, during the build process, collecting dependency release behavior statistics, reference scope statistics, and fault behavior statistics through an enhanced lightweight packaging Maven plugin, and combining these with dependency identification information to form dependency metadata.

[0008] As a preferred embodiment of the lightweight deployment method for Java applications based on dependency stability grading described in this invention, the specific steps for calculating dependency stability scores, classifying dependency stability levels, and generating dependency manifest description files are as follows: The stability score calculation program calculates the dependency stability score based on the dependency metadata; Dependency stability levels are determined based on dependency stability scores. Based on dependency identifiers and stability levels in the dependency metadata, dependency list entries are generated and written to the dependency list description file.

[0009] As a preferred embodiment of the lightweight deployment method for Java applications based on dependency stability grading described in this invention, the step of generating a lightweight packaging plan according to the dependency stability levels in the dependency manifest description file, and packaging the Java application business code and internal runtime libraries into a business code file, specifically includes the following steps: Read the dependency stability level of each dependency in the dependency manifest description file, divide the dependencies into base container image pre-built dependencies and on-demand dependencies pulled during container startup, and generate a lightweight packaging plan. The enhanced lightweight packaging Maven plugin filters the bytecode and resources to be packaged based on the lightweight packaging plan and encapsulates them into business code files.

[0010] As a preferred embodiment of the lightweight Java application deployment method based on dependency stability grading described in this invention, the specific steps for forming the encrypted business code file and generating the lightweight application deployment package are as follows: The obfuscation tool is called to obfuscate the business code file, and the key is obtained by calling the Key Management Service (KMS). The obfuscated business code file is then encrypted to generate a ciphertext file of the business code. Based on the encrypted business code file and the dependency manifest description file, a lightweight application deployment package is generated according to the preset packaging format.

[0011] As a preferred embodiment of the lightweight Java application deployment method based on dependency stability grading described in this invention, the specific steps of building a base container image, pre-setting dependency files, pulling the base container image and the lightweight application deployment package, and decrypting the encrypted business code file are as follows: Build a base container image, pre-configure dependency files, create a local dependency cache directory and a local dependency cache index file, pre-configure the ClientPreparer program, and pull the base container image and lightweight application deployment package during deployment; Start the ClientPreparer program, read the dependency manifest description file, parse the dependency stability level, identify the dependencies that need to be dynamically pulled, obtain the key identifier, decrypt the encrypted business code file, and obtain the decrypted business code file.

[0012] As a preferred embodiment of the lightweight deployment method for Java applications based on dependency stability grading described in this invention, the steps of downloading missing dependencies and verifying dependency fingerprints according to the dependency manifest description file, starting the Spring Boot application, and forming a runtime instance are as follows: Based on the local dependency cache index file, identify the missing local dependencies, download the missing dependencies from the dependency management center and verify their dependency fingerprints, write the missing dependencies to the local dependency cache directory and update the local dependency cache index file; Based on the local dependency cache directory and the decrypted business code files, build the runtime classpath, start the Spring Boot application, and form a runtime instance.

[0013] As a preferred embodiment of the lightweight deployment method for Java applications based on dependency stability grading described in this invention, the step of collecting dependency runtime data, generating incremental update plans and distributing them in the runtime instance refers to the lightweight monitoring component collecting dependency runtime data in the runtime instance, reporting it to the dependency management center, and the dependency management center generating and distributing incremental update plans.

[0014] As a preferred embodiment of the lightweight deployment method for Java applications based on dependency stability grading described in this invention, wherein: when the application restarts, the ClientPreparer program executes an incremental update plan to update the dependency stability score and dependency stability level, specifically through the following steps: When the application restarts, the ClientPreparer program updates dependencies according to the incremental update plan, gradually replacing or fully replacing the target dependencies in the local dependency cache, verifying dependency fingerprints, and the lightweight monitoring component collects new data on the updated dependencies and reports it to the dependency management center. The stability score calculation program updates the dependency stability score and dependency stability level based on the new dependency runtime data provided by the dependency management center.

[0015] Secondly, this invention provides a lightweight deployment system for Java applications based on dependency stability grading, including: The dependency stability grading module is used to collect dependency metadata, calculate dependency stability scores, classify dependency stability levels, and generate dependency list description files. The lightweight packaging generation module is used to generate a lightweight packaging plan based on the dependency stability level in the dependency manifest description file, package the Java application business code and internal runtime library into business code files, form encrypted business code files, and generate a lightweight application deployment package. The container pre-built startup module is used to build the base container image, pre-build dependency files, pull the base container image and lightweight application deployment package, decrypt the encrypted business code files, download missing dependencies according to the dependency manifest description file and verify the dependency fingerprint, start the Spring Boot application, and form a runtime instance. The incremental update module is used to collect dependency runtime data, generate incremental update plans and distribute them in the runtime instance. When the application restarts, the ClientPreparer program executes the incremental update plan to update the dependency stability score and dependency stability level.

[0016] The beneficial effects of this invention are as follows: By reading the dependency stability level through the enhanced lightweight packaging Maven plugin, a lightweight packaging plan is generated, enabling hierarchical screening and combination of dependencies, effectively reducing redundant dependencies entering the lightweight application deployment package and deployment carrier; by collecting dependency runtime data through the lightweight monitoring component, an incremental update plan is generated, and the stability score calculation program adjusts the dependency stability score and dependency stability level, realizing a closed-loop linkage between dependency version evolution and runtime observation, thereby improving the stability of the deployment carrier and the runtime reliability of Java applications. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart of a lightweight deployment method for Java applications based on dependency stability grading.

[0019] Figure 2 This is a schematic diagram of a lightweight deployment system for Java applications based on dependency stability grading.

[0020] Figure 3A flowchart for obtaining the dependency manifest description file.

[0021] Figure 4 A flowchart for generating a lightweight application deployment package. Detailed Implementation

[0022] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0023] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0024] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0025] Reference Figures 1-4 This is one embodiment of the present invention, which provides a lightweight deployment method for Java applications based on dependency stability grading, including the following steps: S1. Collect dependency metadata, calculate dependency stability score, classify dependency stability level, and generate dependency list description file.

[0026] During the build process, the enhanced lightweight packaging Maven plugin collects statistics on dependency release behavior, reference scope, and failure behavior, which, combined with dependency identification information, form dependency metadata.

[0027] Configure the Enhanced Lightweight Packaging Maven plugin in the build environment and attach it to the standard build process of the build tool. When the developer triggers the build command, the Enhanced Lightweight Packaging Maven plugin automatically parses the dependency configuration of the current Java application and generates a dependency list including dependency identification information, such as the organization name, dependency name, dependency version, and dependency scope.

[0028] The enhanced lightweight packaging Maven plugin collects metadata for each dependency in the dependency list. This metadata includes, but is not limited to, publishing behavior statistics, reference scope statistics, and failure behavior statistics.

[0029] Specifically, the collection of release behavior statistics involves the enhanced lightweight packaging Maven plugin calling the interface provided by the artifact repository to query the records of target dependencies being released to the artifact repository during historical builds, counting the cumulative number of releases of target dependencies within a preset time range, and using the cumulative number of releases as the release behavior statistics of target dependencies.

[0030] Collect reference scope statistics. Specifically, retrieve the number of other Java application entries that use the dependency in the artifact repository, and use this as the number of times the target dependency is referenced by different Java applications to generate reference scope statistics for the target dependency.

[0031] Collect fault behavior statistics. Specifically, call the interfaces of the dependency management center and the fault ticket platform, retrieve the rollback records and critical defect records directly associated with the target dependency based on the dependency identification information of the target dependency, and use the sum of the number of rollback records and the number of critical defect records as the fault behavior statistics of the target dependency.

[0032] The enhanced lightweight packaging Maven plugin encapsulates the dependency identification information, release behavior statistics, reference scope statistics, and failure behavior statistics of the target dependency into dependency metadata.

[0033] The stability score calculation program calculates the dependency stability score based on the dependency metadata; classifies the dependency stability level based on the dependency stability score; and generates dependency list entries based on the dependency identifier information and dependency stability level in the dependency metadata, and writes them into the dependency list description file.

[0034] The stability score calculation program receives dependency metadata and calculates a dependency stability score for each dependency.

[0035] Specifically, the dependency stability score is expressed as: ; in, Indicate dependency Dependency stability score Indicate dependency The number of times it is referenced by different Java applications in the artifact repository. This indicates the dependencies recorded in the artifact warehouse. The cumulative number of posts within a preset time range. Representation and Dependency The sum of the number of directly associated rollback records and the number of critical defect records. Indicates dependency identifier, This indicates a parameter related to the number of references. This indicates a parameter related to the number of times a post has been published. This indicates the identifier of parameters related to the fault record.

[0036] The stability score calculation program sorts all dependencies by stability score from largest to smallest, generating a dependency list with sorted numbers. It then counts the total number of dependencies and divides the sorted dependency list into four equal segments from top to bottom. The baseline capacity of each segment is the total number of dependencies divided by 4 and rounded down. Dependencies whose sorted numbers fall into the first segment are marked as dependency stability level L0, those in the second segment as L1, those in the third segment as L2, and the remaining dependencies as L3.

[0037] It should be noted that if the total number of dependencies is not divisible by 4, the dependencies corresponding to the remainders after dividing the total number of dependencies by 4 will be added to dependency stability level L3, dependency stability level L2 and dependency stability level L1 in order of sorting number from back to front.

[0038] It should be noted that dependencies with high stability scores have a stability level concentrated in L0 and L1, dependencies with medium stability scores have a stability level concentrated in L2, and dependencies with low stability scores have a stability level concentrated in L3.

[0039] The stability score calculation program constructs the dependency list entries required for the dependency list description file. The stability score calculation program writes the dependency identifier information, dependency stability score and corresponding dependency stability level of each dependency in the dependency list with sorted sequence number, forming the dependency list description file.

[0040] S2. Based on the dependency stability level in the dependency manifest description file, generate a lightweight packaging plan, package the Java application business code and internal runtime libraries into a business code file, form a business code encrypted file, and generate a lightweight application deployment package.

[0041] The dependency stability level of each dependency in the dependency manifest description file is read, and the dependencies are divided into the base container image pre-built dependencies and the dependencies pulled on demand during the container startup phase, and a lightweight packaging plan is generated. The enhanced lightweight packaging Maven plugin selects the bytecode and resources to be packaged according to the lightweight packaging plan and encapsulates them into business code files.

[0042] The build project declares the Enhanced Lightweight Packaging Maven plugin in the project configuration file, and configures the Enhanced Lightweight Packaging Maven plugin to be executed in the packaging phase of the Maven build lifecycle. When entering the packaging phase, the Enhanced Lightweight Packaging Maven plugin is loaded, and the source code directory, compilation output directory, resource directory, and dependency manifest description file storage path of the current project are passed as input parameters.

[0043] After receiving a packaging trigger command, the enhanced lightweight packaging Maven plugin reads the dependency manifest description file, parses the dependency identification information and corresponding dependency stability levels in the dependency manifest description file using a JSON parsing library, and generates a lightweight packaging plan. Dependencies with stability levels of L0 and L1 are marked as pre-built dependencies of the base container image, while dependencies with stability levels of L2 and L3 are marked as dependencies to be pulled on demand during container startup. The lightweight packaging plan and the set of dependencies that do not need to be packaged into the lightweight application deployment package are generated in memory.

[0044] The enhanced lightweight packaging Maven plugin calls the Maven compilation plugin or the built-in compilation call logic to compile the Java application business source code and internal runtime library source code according to the source code path set in the lightweight packaging plan. The generated bytecode file is then output to the build output directory.

[0045] The build output directory is traversed, and the bytecode files, resource files, and configuration files in the build output directory are packaged. The packaging library is called to create the business code file app-classes.jar, and the bytecode files, resource files, and configuration files are written into the business code file, without writing any third-party dependency files.

[0046] It should be noted that the enhanced lightweight packaging Maven plugin excludes third-party dependency files when generating business code files, and only uses the set of files marked as business code scope in the lightweight packaging plan, ensuring that the business code files only contain Java application business code and internal runtime libraries.

[0047] The obfuscation tool is invoked to obfuscate the business code files, and the key is obtained by calling the Key Management Service (KMS). The obfuscated business code files are then encrypted to generate ciphertext business code files. Based on the ciphertext business code files and the dependency manifest description files, a lightweight application deployment package is generated according to the preset packaging format.

[0048] The enhanced lightweight packaging Maven plugin calls the pre-configured code obfuscation tool to rearrange and rename class names, method names, and field names in the business code files; it generates a new class structure mapping based on the obfuscation configuration, generates obfuscated business code files, outputs the obfuscated business code files to a temporary directory, and deletes the unobfuscated business code files in the temporary directory.

[0049] The system calls the Key Management Service (KMS) via a network interface, submits application identification information and build identification information, requests the symmetric encryption key used in the current build task, obtains the symmetric encryption key identifier and corresponding symmetric encryption key data, loads the symmetric encryption library using the enhanced lightweight packaging Maven plugin, and uses the symmetric encryption key data to perform block reading and writing and streaming encryption on the obfuscated business code file to generate a ciphertext file of the business code.

[0050] Write a key identifier field in the dependency manifest description file to obtain the decryption key from the Key Management Service (KMS) using the key identifier.

[0051] The enhanced lightweight packaging Maven plugin removes all dependency files from the dependency list of the current build project based on the set of dependencies that do not need to be packaged into the lightweight application deployment package, as recorded in the lightweight packaging plan. It does not write any dependency files into the deployment artifacts, but only selects the encrypted business code file and the dependency manifest description file. It calls the packaging library to create a new deployment package file and creates two entries in the deployment package file, one for storing the encrypted business code file and the other for storing the dependency manifest description file.

[0052] It should be noted that the enhanced lightweight packaging Maven plugin does not include the ClientPreparer program, startup script, or third-party dependency library files in the lightweight application deployment package.

[0053] Output the lightweight application deployment package to the artifact repository or build artifact catalog, and record the path of the encrypted business code file and the path of the dependency manifest description file in the build log.

[0054] S3. Build the base container image, pre-configure dependency files, pull the base container image and lightweight application deployment package, decrypt the encrypted business code file, download missing dependencies according to the dependency manifest description file and verify the dependency fingerprint, start the Spring Boot application, and form a runtime instance.

[0055] Build a base container image, pre-configure dependency files, create a local dependency cache directory and a local dependency cache index file, pre-configure the ClientPreparer program, and pull the base container image and lightweight application deployment package during deployment; start the ClientPreparer program, read the dependency manifest description file, parse the dependency stability level, identify the dependencies that need to be dynamically pulled, obtain the key identifier, decrypt the encrypted business code file, and obtain the decrypted business code file.

[0056] Furthermore, a base container image is built and high-stability dependency files are pre-configured. Specifically, during the construction of the base container image, high-stability dependency files with stability levels of L0 and L1 are specified in the dependency manifest description file, downloaded from the artifact repository, and stored in the local dependency cache directory of the base container image.

[0057] The base container image includes a local dependency cache index file and a ClientPreparer program. The local dependency cache index file records the identification information of the dependency files, including but not limited to coordinates, version numbers, and fingerprint information. When the ClientPreparer program starts in the target environment, it reads the dependency manifest description file, decrypts the business code files, and dynamically pulls the missing dependency files.

[0058] During the deployment phase, the container orchestration platform pulls the base container image from the container image repository and mounts the lightweight application deployment package into the container. The lightweight application deployment package only includes encrypted business code files and dependency manifest description files, and does not include any dependency files.

[0059] It should be noted that Kubernetes is selected as the container orchestration platform in this embodiment.

[0060] When the container starts, the ClientPreparer program begins execution, reads the dependency manifest description file in the mounted lightweight application deployment package, parses the dependency stability level information, and, based on the dependency manifest description file, marks dependencies with stability levels of L0 and L1 as pre-built dependencies, and marks dependencies with stability levels of L2 and L3 as dependencies to be pulled.

[0061] The ClientPreparer program requests and obtains a decryption key from the key management service, uses the decryption key to decrypt the encrypted business code file, and obtains the decrypted business code file.

[0062] It should be noted that the ClientPreparer program processes the decrypted business code file app-classes.jar only in memory and does not store the business code file app-classes.jar on disk.

[0063] Based on the local dependency cache index file, identify the missing local dependencies, download the missing dependencies from the dependency management center and verify their fingerprints, write the missing dependencies to the local dependency cache directory and update the local dependency cache index file; based on the local dependency cache directory and the decrypted business code files, build the runtime classpath, start the Spring Boot application, and form a runtime instance.

[0064] Read the local dependency cache index file and check whether the low-stability-level dependency files marked as L2 and L3 in the dependency manifest description file exist in the local dependency cache directory.

[0065] If the low-stability-level dependency files of stability levels L2 and L3 exist in the local dependency cache directory, the ClientPreparer program directly uses the low-stability-level dependency files of stability levels L2 and L3; if the low-stability-level dependency files of stability levels L2 and L3 are missing from the local dependency cache directory, the ClientPreparer program dynamically pulls the missing low-stability-level dependency files of stability levels L2 and L3 through the API of the dependency management center.

[0066] For each downloaded dependency file with low stability levels of L2 and L3, perform fingerprint verification to ensure that the downloaded low stability level dependency file has not been tampered with; if the fingerprint verification result is a match, save the low stability level dependency file with low stability levels of L2 and L3 that passed the fingerprint verification to the local dependency cache directory and update the relevant records in the local dependency cache index file.

[0067] It should be noted that dependency fingerprinting is used to ensure the integrity and security of dependencies during application deployment. Specifically, an enhanced lightweight packaging Maven plugin parses all dependencies requiring fingerprint calculation from the dependency manifest description file, including external third-party dependency libraries. For each class in each external dependency, the fully qualified class name is extracted, and a cryptographically secure hash function, such as SHA-256, is used to hash the fully qualified class name to obtain a class-level fingerprint. For the same external dependency, all class-level fingerprints within the external dependency are XORed to generate a dependency fingerprint for that external dependency. The dependency fingerprint uniquely identifies the dependency and is unaffected by the class loading order. The generated dependency fingerprint is written to the dependency manifest description file and the local dependency cache index file. During application deployment or runtime, for each dependency file downloaded from the dependency management center, the ClientPreparer program compares and verifies it based on the dependency fingerprint. Only when the fingerprint matches is the dependency file written to the local dependency cache directory and included in the runtime classpath build.

[0068] The ClientPreparer program uses all downloaded and fingerprint-verified dependency files of low stability levels L2 and L3, along with decrypted business code files, to build the runtime classpath of the Java application and start the Spring Boot application based on the runtime classpath of the Java application.

[0069] It should be noted that after the Spring Boot application starts, all low-stability-level dependencies (stability levels L2 and L3) have been loaded into the runtime classpath. After the business code executes according to the predetermined logic, the Spring Boot application starts successfully and forms a runtime instance.

[0070] S4. In the runtime instance, collect dependency runtime data, generate an incremental update plan and distribute it. When the application restarts, the ClientPreparer program executes the incremental update plan to update the dependency stability score and dependency stability level.

[0071] In the runtime instance, the lightweight monitoring component collects dependency runtime data and reports it to the dependency management center, which then generates and distributes incremental update plans.

[0072] During application runtime, the lightweight monitoring component periodically collects dependency runtime data, including but not limited to dependency load counts, exception log frequency, rollback counts, performance data, and version change information. Specifically, it records the number of exception logs triggered by the dependency during runtime, obtains the exception log frequency to reflect the dependency's stability, records the number of rollback operations caused by the dependency, records the dependency's loading time, memory usage, etc., generates performance data, and assesses the dependency's performance bottlenecks, and records the dependency's version update frequency to identify frequently updated dependencies and obtain version change information.

[0073] It should be noted that the lightweight monitoring component integrates the collected dependency runtime data into a report, which includes the runtime status and performance of each dependency. The report is then submitted to the dependency management center via a secure API.

[0074] Based on the received dependency runtime data, the dependency management center evaluates the stability of each dependency. Specifically, if the number of exceptions triggered by a dependency during runtime exceeds the exception log frequency threshold, the dependency is marked as unstable; if the number of rollbacks caused by a dependency exceeds the preset rollback number, the dependency is marked as needing to be updated; if the loading time or memory usage of a dependency exceeds the set loading time threshold or memory usage threshold, it is marked as a performance bottleneck and performs poorly; if the version of a dependency is updated frequently and has not been fully verified, the dependency is marked as having unstable factors.

[0075] Generate an incremental update plan, which includes a list of dependencies that need to be updated, update priorities, and update methods.

[0076] It should be noted that the abnormal log frequency threshold ranges from (5, 20) times per hour. Specifically, the abnormal log frequency threshold is set based on historical data, performance requirements, and industry standards. For example, by analyzing historical log data, assessing the distribution of abnormal logs during normal operation, determining the common abnormal frequency range, and using the number of abnormal logs during stable operation in the past as a reference, an appropriate abnormal log frequency threshold can be set. The threshold can also be set according to the application's load and performance requirements. For instance, for high-performance tasks, the tolerance for abnormal log frequency is lower, while for some low-priority, higher-tolerance batch processing tasks, the abnormal log frequency threshold is set higher. Finally, a suitable threshold can be selected by referring to known stability scoring models and based on experience with similar environments and scenarios.

[0077] The system acquires the preset rollback count, collects and stores historical rollback data for all dependencies, statistically analyzes the rollback count for each dependency, calculates the rollback frequency for each dependency per month, and analyzes the impact of rollbacks on stability and service availability. If the rollback count for a dependency exceeds the set number, such as 3 times / month, the preset rollback count is set to 3 times / month. If the rollback count is low, but each rollback causes severe service interruption, the preset rollback count is set to 2 times / month for faster response to potential issues. If rollbacks are frequent but have a small impact, the preset rollback count is set to 5 times / month to avoid excessive triggering of update operations. The preset rollback count is not fixed and can be dynamically adjusted according to actual conditions. During operation, the dependency management center can periodically adjust the preset rollback count based on changes in rollback data, stability requirements, and customer fault tolerance requirements.

[0078] The loading time threshold ranges from (50, 200) milliseconds. Based on actual load and requirements, a response time within 50 milliseconds ensures extremely high speed, while the (50, 200) millisecond range balances performance and business needs, ensuring that the loading time of most application dependencies is within an acceptable range. To obtain the loading time threshold, specifically, during the development phase or performance testing, performance testing tools are used to test the loading time of each dependency in the application, and the average loading time of each dependency is recorded. The 90th percentile of the maximum loading time is selected as the loading time threshold. The threshold can effectively reflect the normal time range of dependency loading and ensure that the loading time of most dependencies is within a reasonable range.

[0079] The memory usage threshold ranges from (80, 500) MB. 80 MB is for dependencies with low memory requirements, suitable for lightweight microservices and small applications. 500 MB is suitable for complex applications or big data processing tasks with high memory requirements. (80, 500) MB can cover different application scenarios, optimize dependencies with excessive memory usage in a timely manner, and avoid performance bottlenecks and resource waste. The memory usage threshold is set based on historical running data. Specifically, the dependency management center uses the monitoring tool Prometheus to collect memory usage data for each dependency over 30 days, calculates the average memory usage of each dependency, and sets 1.5 times the average memory usage of the dependency as the memory usage threshold.

[0080] Dependencies are prioritized based on their performance, with poorly performing dependencies being updated first. Specifically, each dependency is recorded with four flags: whether it exceeds an exception log frequency threshold, whether it exceeds a preset rollback count, whether it exceeds a load time threshold or memory usage threshold, and whether its version update frequency is high and has not been sufficiently verified. The number of "yes" flags among the four flags is counted to determine update priorities. If a dependency has at least two "yes" flags, and at least one of them indicates that the exception log frequency exceeds the threshold or the rollback count exceeds the preset rollback count, the dependency is classified as first priority and processed first in the incremental update plan. If only one of the four flags is "yes," the dependency is classified as second priority and processed second-highest priority in the incremental update plan. If all four flags are "no," the dependency is classified as third priority and will be updated only after the first-priority and second-priority dependencies have been updated and resources allow.

[0081] When generating an incremental update plan, the dependency identifier, update method, and corresponding update priority are written into the incremental update plan. The ClientPreparer program updates the dependencies in the order of first priority, second priority, and third priority when the application restarts.

[0082] It should be noted that the update method is determined based on the update priority and trigger flag. Specifically, for first-priority dependencies, those with anomaly log frequency exceeding the anomaly log frequency threshold or rollback count exceeding the preset rollback count will have their update method set to full replacement and will need to be updated immediately. For first-priority dependencies marked due to performance data or version changes, and all second-priority dependencies, the update method will be set to gradual replacement and will need to be updated gradually. Third-priority dependencies will be updated gradually when the first-priority and second-priority dependencies have been updated and resources allow.

[0083] Furthermore, the generated incremental update plan is distributed to the ClientPreparer program in the target environment via a secure channel.

[0084] When the application restarts, the ClientPreparer program updates dependencies according to the incremental update plan, gradually replacing or fully replacing the target dependencies in the local dependency cache, verifying dependency fingerprints, and the lightweight monitoring component collects new runtime data of the updated dependencies and reports it to the dependency management center. The stability score calculation program updates the dependency stability score and dependency stability level based on the new runtime data of the dependencies provided by the dependency management center.

[0085] Furthermore, when the application restarts, the ClientPreparer program retrieves the latest incremental update plan from the dependency management center and performs dependency updates. Specifically, for dependencies that need to be updated gradually, the ClientPreparer program updates the dependencies in some application instances first to ensure that the new version of the dependencies runs stably in a small number of instances; if the new version of the dependencies performs well in the instances, the update scope is expanded to update all instances to the new version of the dependencies; for dependencies that need to be updated immediately, the ClientPreparer program will perform a full replacement in all application instances to ensure that the new version of the dependencies is used in all instances.

[0086] It should be noted that when performing dependency updates, the ClientPreparer program uses the dependency fingerprint in the dependency manifest description file to verify the downloaded dependency files. If the dependency fingerprint matches, the update operation continues; if the fingerprint does not match, the update is aborted to avoid using tampered dependencies.

[0087] Furthermore, after the dependency update is completed and the application starts successfully, the ClientPreparer program collects new dependency runtime data during application operation. This new dependency runtime data includes the number of newly added rollback records, the number of newly added critical defect records, the frequency of exception logs, the average loading time, and the average memory usage. This data forms new dependency runtime data and is forwarded to the stability score calculation program through the dependency management center.

[0088] The stability score calculation program receives new data from the dependency runtime and calculates the number of new rollback records, the number of new critical defect records, the frequency of abnormal logs, the average loading time, and the average memory usage for each target dependency in the current statistical period. It then establishes a one-to-one comparison relationship with the thresholds for abnormal log frequency, loading time, and memory usage.

[0089] If any target dependency has a new rollback record count greater than 0, an anomaly log frequency greater than the anomaly log frequency threshold, an average load time greater than the load time threshold, or an average memory usage greater than the memory usage threshold in the current statistical period, the target dependency's running status is judged as poor performance. The number of new rollback records and the number of new critical defect records in the current statistical period are added to the fault behavior statistics to form updated fault behavior statistics.

[0090] If the number of new rollback records added to the target dependency in the current statistical period is 0, and the frequency of exception logs is less than or equal to half of the exception log frequency threshold, the average loading time is less than or equal to the loading time threshold, and the average memory usage is less than or equal to the memory usage threshold, the target dependency's running status is judged as good, and no fault behavior statistics are added.

[0091] Update reference scope statistics and release behavior statistics based on the latest product warehouse records and dependency management center records.

[0092] For each target dependency, the dependency stability score is recalculated using the dependency stability scoring formula. All target dependencies are sorted from largest to smallest according to the updated dependency stability score values ​​to obtain a target dependency sequence with a sorting number. The sorted target dependency sequence is divided into four consecutive segments according to the total number of target dependencies, in the same way as the dependency stability levels L0, L1, L2, and L3. The dependency stability level is then updated.

[0093] The stability score calculation program updates the stability score of dependencies based on the feedback data, adjusts the stability level of dependencies, and writes the updated dependency stability level into the dependency manifest description file. The dependency manifest description file serves as a reference for dependency selection during subsequent build processes.

[0094] The dependency stability levels in the dependency manifest description file will be used in the next build process to guide dependency packaging and distribution strategies. During the base container image build phase, dependencies with higher stability will be cached or pre-configured first, while during the container startup phase, dependencies with lower stability will be pulled as needed and written to the local dependency cache directory.

[0095] This embodiment also provides a lightweight deployment system for Java applications based on dependency stability grading, including: a dependency stability grading module, used to collect dependency metadata, calculate dependency stability scores, classify dependency stability levels, and generate dependency list description files.

[0096] The lightweight packaging generation module is used to generate a lightweight packaging plan based on the dependency stability level in the dependency manifest description file, package the Java application business code and internal runtime libraries into business code files, form encrypted business code files, and generate a lightweight application deployment package.

[0097] The container pre-built startup module is used to build the base container image, pre-build dependency files, pull the base container image and lightweight application deployment package, decrypt the encrypted business code files, download missing dependencies according to the dependency manifest description file and verify the dependency fingerprint, start the Spring Boot application, and form a runtime instance.

[0098] The incremental update module is used to collect dependency runtime data, generate incremental update plans and distribute them in the runtime instance. When the application restarts, the ClientPreparer program executes the incremental update plan to update the dependency stability score and dependency stability level.

[0099] In summary, this invention uses an enhanced lightweight packaging Maven plugin to read dependency stability levels and generate a lightweight packaging plan, enabling hierarchical filtering and combination of dependencies. This effectively reduces redundant dependencies entering the lightweight application deployment package and deployment carrier. Furthermore, a lightweight monitoring component collects dependency runtime data, generates an incremental update plan, and a stability score calculation program adjusts dependency stability scores and levels. This achieves a closed-loop linkage between dependency version evolution and runtime observation, improving the stability of the deployment carrier and the operational reliability of Java applications.

[0100] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A lightweight deployment method for Java applications based on dependency stability grading, characterized by: include, Collect dependency metadata, calculate dependency stability scores, classify dependency stability levels, and generate dependency manifest description files; Based on the dependency stability level in the dependency manifest description file, a lightweight packaging plan is generated, which packages the Java application business code and internal runtime libraries into a business code file, forms a business code encrypted file, and generates a lightweight application deployment package. Build a base container image, pre-configure dependency files, pull the base container image and lightweight application deployment package, decrypt the encrypted business code file, download missing dependencies and verify dependency fingerprints according to the dependency manifest description file, start the Spring Boot application, and form a runtime instance. In the runtime instance, dependency runtime data is collected, an incremental update plan is generated and distributed, and when the application restarts, the ClientPreparer program executes the incremental update plan to update the dependency stability score and dependency stability level.

2. The lightweight deployment method for Java applications based on dependency stability grading as described in claim 1, characterized in that: The collected dependency metadata includes, during the build process, the collection of dependency release behavior statistics, reference scope statistics, and fault behavior statistics through the enhanced lightweight packaging Maven plugin, combined with dependency identification information to form dependency metadata.

3. The lightweight deployment method for Java applications based on dependency stability grading as described in claim 2, characterized in that: The specific steps for calculating dependency stability scores, classifying dependency stability levels, and generating dependency list description files are as follows: The stability score calculation program calculates the dependency stability score based on the dependency metadata; Dependency stability levels are determined based on dependency stability scores. Based on dependency identifiers and stability levels in the dependency metadata, dependency list entries are generated and written to the dependency list description file.

4. The lightweight deployment method for Java applications based on dependency stability grading as described in claim 3, characterized in that: The step involves generating a lightweight packaging plan based on the dependency stability levels in the dependency manifest description file, and packaging the Java application business code and internal runtime libraries into a business code file. The specific steps are as follows: Read the dependency stability level of each dependency in the dependency manifest description file, divide the dependencies into base container image pre-built dependencies and on-demand dependencies pulled during container startup, and generate a lightweight packaging plan. The enhanced lightweight packaging Maven plugin filters the bytecode and resources to be packaged based on the lightweight packaging plan and encapsulates them into business code files.

5. The lightweight deployment method for Java applications based on dependency stability grading as described in claim 4, characterized in that: The specific steps for generating the encrypted business code file and the lightweight application deployment package are as follows: The obfuscation tool is called to obfuscate the business code file, and the key is obtained by calling the Key Management Service (KMS). The obfuscated business code file is then encrypted to generate a ciphertext file of the business code. Based on the encrypted business code file and the dependency manifest description file, a lightweight application deployment package is generated according to the preset packaging format.

6. The lightweight deployment method for Java applications based on dependency stability grading as described in claim 5, characterized in that: The specific steps for building the base container image, pre-configuring dependency files, pulling the base container image and lightweight application deployment package, and decrypting the encrypted business code files are as follows: Build a base container image, pre-configure dependency files, create a local dependency cache directory and a local dependency cache index file, pre-configure the ClientPreparer program, and pull the base container image and lightweight application deployment package during deployment; Start the ClientPreparer program, read the dependency manifest description file, parse the dependency stability level, identify the dependencies that need to be dynamically pulled, obtain the key identifier, decrypt the encrypted business code file, and obtain the decrypted business code file.

7. The lightweight deployment method for Java applications based on dependency stability grading as described in claim 6, characterized in that: The steps for downloading missing dependencies and verifying their fingerprints based on the dependency manifest description file, starting the Spring Boot application, and creating a runtime instance are as follows: Based on the local dependency cache index file, identify the missing local dependencies, download the missing dependencies from the dependency management center and verify their dependency fingerprints, write the missing dependencies to the local dependency cache directory and update the local dependency cache index file; Based on the local dependency cache directory and the decrypted business code files, build the runtime classpath, start the Spring Boot application, and form a runtime instance.

8. The lightweight deployment method for Java applications based on dependency stability grading as described in claim 7, characterized in that: The process of collecting dependency runtime data, generating incremental update plans, and distributing them in the runtime instance refers to the lightweight monitoring component collecting dependency runtime data, reporting it to the dependency management center, and then the dependency management center generating and distributing incremental update plans.

9. The lightweight deployment method for Java applications based on dependency stability grading as described in claim 8, characterized in that: When the application restarts, the ClientPreparer program executes an incremental update plan to update the dependency stability score and dependency stability level. The specific steps are as follows: When the application restarts, the ClientPreparer program updates dependencies according to the incremental update plan, gradually replacing or fully replacing the target dependencies in the local dependency cache, verifying dependency fingerprints, and the lightweight monitoring component collects new data on the updated dependencies and reports it to the dependency management center. The stability score calculation program updates the dependency stability score and dependency stability level based on the new dependency runtime data provided by the dependency management center.

10. A lightweight deployment system for Java applications based on dependency stability grading, based on the lightweight deployment method for Java applications based on dependency stability grading as described in any one of claims 1 to 9, characterized in that: include, The dependency stability grading module is used to collect dependency metadata, calculate dependency stability scores, classify dependency stability levels, and generate dependency list description files. The lightweight packaging generation module is used to generate a lightweight packaging plan based on the dependency stability level in the dependency manifest description file, package the Java application business code and internal runtime library into business code files, form encrypted business code files, and generate a lightweight application deployment package. The container pre-built startup module is used to build the base container image, pre-build dependency files, pull the base container image and lightweight application deployment package, decrypt the encrypted business code files, download missing dependencies according to the dependency manifest description file and verify the dependency fingerprint, start the Spring Boot application, and form a runtime instance. The incremental update module is used to collect dependency runtime data, generate incremental update plans and distribute them in the runtime instance. When the application restarts, the ClientPreparer program executes the incremental update plan to update the dependency stability score and dependency stability level.

Images