CN112835865A - Application hot deployment system, method and device - Google Patents
Application hot deployment system, method and device Download PDFInfo
- Publication number
- CN112835865A CN112835865A CN202110346752.3A CN202110346752A CN112835865A CN 112835865 A CN112835865 A CN 112835865A CN 202110346752 A CN202110346752 A CN 202110346752A CN 112835865 A CN112835865 A CN 112835865A
- Authority
- CN
- China
- Prior art keywords
- file
- class
- container
- files
- directory
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
- G06F16/1824—Distributed file systems implemented using Network-attached Storage [NAS] architecture
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
Abstract
The embodiment of the specification provides an application thermal deployment system, method and device, which can be applied to the technical field of big data processing. The system comprises: the file transmission device is used for uploading the class files to a specified directory of a file directory of the distributed file system; the container cluster is used for monitoring the change condition of the class files in the file directory of the distributed file system through a monitoring program; under the condition that class files in a file directory of the distributed file system change, calling a custom class loader to load the changed target class files into a container so as to replace the old version class files corresponding to the target class files in the container; and under the condition of receiving a user request, using the target class file to instantiate the object so as to solve the problem that the use of the user is interrupted due to the redeployment of the container and improve the deploying efficiency of the container application.
Description
Technical Field
The embodiment of the specification relates to the technical field of big data processing, in particular to a system, a method and a device for application hot deployment.
Background
With the deep popularization of the application on the containerized cloud, more and more applications use JavaWeb application programs based on a Spring framework and a Spring Boot framework to realize containerized cloud application, and the multi-container deployment mode solves the performance bottleneck problem of traditional single-case deployment.
Based on the current mainstream front-end and back-end separation technology, a front-end program and a JavaWeb back-end application program are respectively deployed in different containers, a containerization deployment mode requires a complete deployment mirror image, container application integration is good and independent, and each container is a complete operating environment.
However, a production run application inevitably encounters troublesome system problems that need to be addressed immediately, and may not be addressed quickly due to certain circumstances, including: the container deployment is based on the packing deployment of the whole mirror image, the whole online flow is long, and the quick response is difficult to realize, such as the following steps: compiling and packaging, walking a release assembly line, producing and receiving a mirror image package, and producing and deploying a mirror image. For some problems, a temporary solution may be quickly provided, which does not actually need to exist as the complete content of the container, and subsequently still provides a complete version deployment. When a user requests and accesses the current container, the redeployment of the container can cause the interruption of the use of the user, and the user experience is influenced.
Disclosure of Invention
An object of the embodiments of the present specification is to provide an application hot deployment system, method, and apparatus, so as to solve the problem that the relocation of a container may cause interruption of user use, and improve the deployment efficiency of the container application.
To solve the above problem, an embodiment of the present specification provides an application thermal deployment system, including: the file transmission device is used for uploading the class files to a specified directory of a file directory of the distributed file system; the container cluster is used for monitoring the change condition of the class files in the file directory of the distributed file system through a monitoring program; under the condition that class files in a file directory of the distributed file system change, calling a custom class loader to load the changed target class files into a container so as to replace the old version class files corresponding to the target class files in the container; instantiating an object using the target class file in the event a user request is received.
To solve the above problem, an embodiment of the present disclosure further provides an application heat deployment method, including: monitoring the change condition of class files in a file directory of the distributed file system; under the condition that class files in a file directory of the distributed file system change, calling a custom class loader to load the changed target class files into a container so as to replace the old version class files corresponding to the target class files in the container; instantiating an object using the target class file in the event a user request is received.
To solve the above problem, an embodiment of the present specification further provides an application heat deployment apparatus, including: the monitoring module is used for monitoring the change condition of the class files in the file directory of the distributed file system; the loading module is used for calling a custom class loader to load a changed target class file into a container to replace an old version class file corresponding to the target class file in the container under the condition that the class file in a file directory of the distributed file system is changed; and the instantiation module is used for instantiating the object by using the target class file under the condition of receiving a user request.
As can be seen from the technical solutions provided in the embodiments of the present specification, the system may include: the file transmission device is used for uploading the class files to a specified directory of a file directory of the distributed file system; the container cluster is used for monitoring the change condition of the class files in the file directory of the distributed file system through a monitoring program; under the condition that class files in a file directory of the distributed file system change, calling a custom class loader to load the changed target class files into a container so as to replace the old version class files corresponding to the target class files in the container; instantiating an object using the target class file in the event a user request is received. The system provided by the embodiment of the present specification is based on a Java class loader technology, and monitors a directory in which class files are stored outside a container, for example, a distributed file system is used to store the class files, a custom class loader is used to dynamically load the class files, and the class files are read from the directory of the distributed file system and replace the original class files in the container, so that the problem that the use of a user is interrupted due to the redeployment of the container is solved, and the deployment efficiency of container application is improved.
Drawings
In order to more clearly illustrate the embodiments of the present specification or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the specification, and other drawings can be obtained by those skilled in the art without creative efforts.
FIG. 1 is a schematic diagram of an example of one scenario herein;
fig. 2 is a schematic structural diagram of a system for deploying heat according to an embodiment of the present disclosure;
FIG. 3 is a schematic structural diagram of a class file encryption apparatus according to an embodiment of the present disclosure;
FIG. 4 is a schematic diagram illustrating steps performed by a monitoring program according to an exemplary scenario herein;
FIG. 5 is a flow chart of a method of applying thermal deployment herein;
fig. 6 is a functional structure diagram of an application thermal deployment apparatus according to an embodiment of the present disclosure.
Detailed Description
The technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the drawings in the embodiments of the present disclosure, and it is obvious that the described embodiments are only a part of the embodiments of the present disclosure, and not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present specification without any creative effort shall fall within the protection scope of the present specification.
In the embodiments of the present specification, a container is a process collection of view-isolated, resource-limitable, independent file systems. The view isolation is to see part of the process and have an independent host name and the like; the control of the resource utilization rate can limit the memory size and the number of used CPUs. Briefly, a container contains the complete runtime environment: all dependencies, class libraries, other binaries, configuration files, etc. required by the application, except the application itself, are uniformly typed into a package called a container image. By abstracting the differences between the application itself, and its dependencies, operating system release and other underlying environments
The container has an independent file system, and because the resources of the system are used, the kernel-related code or tools do not need to be provided in the independent file system, and only the binary files, the configuration files and the dependencies needed by the container need to be provided. A container can be run as long as the set of files needed by the container to run is available.
However, a production run application inevitably encounters troublesome system problems that need to be addressed immediately, and may not be addressed quickly due to certain circumstances, including: the container deployment is based on the packing deployment of the whole mirror image, the whole online flow is long, and the quick response is difficult to realize, such as the following steps: compiling and packaging, walking a release assembly line, producing and receiving a mirror image package, and producing and deploying a mirror image. For some problems, a temporary solution may be quickly provided, which does not actually need to exist as the complete content of the container, and subsequently still provides a complete version deployment. When a user requests and accesses the current container, the redeployment of the container can cause the interruption of the use of the user, and the user experience is influenced.
Considering that if the Class loader technology based on Java can be used, by monitoring the directory in which the Class file is stored outside the container, for example, the Class file is stored by using a distributed file system, the Class file is dynamically loaded by using a custom Class loader, and the Class file is read from the directory of the distributed file system and replaces the original Class file in the container, the problem that the relocation of the container in the prior art causes interruption of the use of a user is expected to be solved, and under the condition that the application is not restarted, the Class in the container application on production is rapidly updated, the continuity of the use of the user is maintained, and the deployment efficiency of the container application is improved. Based on this, the embodiment of this specification provides an application heat deployment method, device and storage medium.
Referring to fig. 1, an example of a scenario in the present specification is presented. Fig. 1 is a flowchart of an application heat deployment method in the scenario example. Specifically, the following steps may be included.
Step A1: and uploading class files by using a file transmission device, wherein the storage positions of the class files are distributed file system disks mounted in the container and can be accessed from the inside and the outside of the container.
Class files, which are files that are generated by a javac compiler, have a well-defined format. The Class file is a group of binary streams with 8-bit byte as a base unit, and the data items are compactly arranged in the Class file strictly according to the sequence without adding separators in the middle, so that the content stored in the whole Class file is almost all necessary data for program operation. When a data item which needs to occupy more than 8-bit bytes is encountered, the data item is divided into a plurality of 8-bit bytes for storage according to a mode that high order bits are in the front.
Specifically, the file transmission device can upload the Class file in various modes such as a foreground page, production line file transmission, manual uploading by a system administrator and the like. For example, a foreground page uploading mode is adopted to upload a Class file, a page supports multi-file uploading and designates each file uploading path, and a distributed file system records information logs such as uploaded Class file names and paths and provides the information logs for a monitoring program to dynamically monitor file changes each time.
In this scenario example, based on a scenario of multi-container deployment, an upload operation is performed only on a single container in a single node, and therefore, after the file is uploaded, the file needs to be stored on a distributed file system disk mounted in the container for shared use by other nodes and containers.
In order to prevent the Class file from being illegally tampered, the credibility of the Class file on the distributed file system needs to be ensured, the uploaded Class file can be uploaded to the distributed file system after being encrypted by the encryption device, and the encrypted Class file can be suffixed with Class x. The Class file is firstly encrypted by the encryption device and then uploaded by the file transmission device.
Step A2: and adding a monitoring program in the container to monitor the distributed file system directory.
Specifically, the monitoring program can be integrated in an application program in the container, and since the change of the distributed file system directory consumes resources, the monitoring program can monitor logs of file change in the distributed file system directory in real time, the change logs are updated when files are uploaded, and when the files change, the monitoring program calls the Class loader to dynamically load the Class files.
Step A3: and self-defining a class loader in the container, and loading class files in the distributed file system directory.
The class loader (ClassLoader) is part of the Java runtime environment and is responsible for dynamically loading Java classes into the memory space of the Java virtual machine. The loading of classes is done by class loaders, which are typically provided by the JVM (Java virtual Machine), which are also the basis for all previous programs to run. The loader provided by the JVM can be classified into a ClassLoader subclass and a non-ClassLoader subclass if classified according to inheritance, or can be classified into these three classes if classified according to a hierarchical structure:
root class loader (bootstrap class loader): it is used to load the core class of Java, which is implemented in native code and is not inherited from Java.
Extension class loader (extensions class loader): it is responsible for loading the extended directory of the JRE, the class of the JAR package in the lib/ext or directory specified by the java. Implemented in the Java language, the parent loader is null.
System class loader (system class loader): called the system (also called application) class loader, which is responsible for loading the-CLASSPATH option, Java. The program may obtain the system class loader by the static method getSystemClassLoader () of ClassLoader. If not specified, the user's custom class loader has such loader as the parent loader. The system class loader is realized by Java language, and the parent class loader is ExtClassLoader.
Due to characteristics of Java, Class files loaded by different Class loaders are different and belong to different instances in the JVM, and each time a Class loader loads a Class file, a new instance is generated. In the scenario example, the custom class loader only loads the class and does not initialize the class, and the class is initialized only when the application needs to instantiate the object.
In this scenario example, the custom class loader uses a full disk responsibility delegation mechanism when loading classes. That is, when the custom class loader loads a class file, the other classes associated with the class are also loaded by the class loader. When the custom class loader loads the class file, the parent loader is loaded first, and the parent loader is loaded by the self when the parent loader is not loaded.
In this scenario example, when the custom class loader loads a class, it needs to verify whether the loaded class file has a correct structure. Specifically, before the class file is loaded, it is checked whether the method input and output of the loaded class are consistent with the old class, so as to avoid other normal functions.
In this scenario example, when the current user usage amount of the container where the Class loader is located is large and there is a Class file currently being updated, as a standby scheme for real-time loading, the current container notifies the PaaS platform to start a new container to load a new Class file, and the current container executes an elegant shutdown instruction, no new user request is received, and when the operation currently being executed is completed, the current container is deleted, so that smooth switching between the new container and the old container is achieved.
Step A4: when a user requests a related function, a class file is used for instantiation.
In particular, an object may be instantiated using a loaded class file upon receiving a user request. Instantiation refers to the process of creating objects with classes in object-oriented programming. The instantiation process is generally composed of a class name object name (new class name) (parameter 1, parameter 2.. parameter n).
Please refer to fig. 2. The embodiment of the specification provides an application thermal deployment system. The system includes a container cluster B1 and a file transfer device B3.
The file transmission device B3 is used for uploading the class files to the designated directory of the file directory of the distributed file system B2. The file transmission device B3 can upload the class files in various modes such as a foreground page, production line file transmission, manual uploading by a system administrator and the like.
The Distributed File System (DFS) refers to that physical storage resources managed by the File System are not necessarily directly connected to a local node, but are connected to the node through a computer network; or a complete hierarchical file system formed by combining several different logical disk partitions or volume labels. DFS provides a logical tree file system structure for resources distributed at any position on the network, so that users can access shared files distributed on the network more conveniently.
In some embodiments, the file transmission device may provide a class file upload page, so that a user can upload a class file to a specified directory of the distributed file system through the class file upload page; the class file uploading page supports multi-file uploading and specifies each file uploading path. Specifically, the user may select one or more class files to be uploaded on the class file upload page, and specify an upload path of each file, thereby implementing the upload of the class files. In a specific example, a user may select one or more class files to be uploaded from local files, specify an upload path of each file in an upload path selection box, and click an upload button, where the class file upload page may upload the selected one or more class files to a file directory of the distributed file system according to the upload path in response to an upload operation triggered by the user. By uploading the class files in the mode, the uploading efficiency can be improved, and the class files can be shared by other nodes and containers.
In some embodiments, the system may further include class file encryption means B4. The class file encryption device B4 is used for reading a class file generated by compiling the development environment; encrypting the class file through an encryption algorithm; correspondingly, the file transfer device B3 is configured to upload the encrypted class file to a specified directory of the distributed file system.
The structure of the class file encryption device B4 is shown in fig. 3. The class file encryption device B4 may include a class file reading module, configured to read a class file generated by compiling a development environment, and obtain binary information; and an encryption module. The encryption device is used for encrypting the read file information through an encryption algorithm; and the encrypted file storage module is used for storing the encrypted binary information into a classx file. Specifically, the Encryption process may be implemented by using a preset Encryption Algorithm, for example, a symmetric Encryption Algorithm such as des (data Encryption standard), 3des (triple des), or an asymmetric Encryption Algorithm such as RSA (rivest-Shamir-Adleman), DSA (Digital Signature Algorithm). The Class files are encrypted in the mode, and the encrypted Class files are uploaded to the designated directory of the distributed file system, so that the Class files can be prevented from being illegally tampered, and the credibility of the Class files on the distributed file system is ensured.
The container cluster B1 may be configured to monitor a change of class files in a file directory of the distributed file system through a monitoring program; under the condition that class files in a file directory of the distributed file system change, calling a custom class loader to load the changed target class files into a container so as to replace the old version class files corresponding to the target class files in the container; instantiating an object using the target class file in the event a user request is received. The container cluster B1 may be composed of a plurality of containers, which may be provided by a PaaS (Platform as a Service) Platform.
In some embodiments, the monitoring program may be integrated into an application in the container. The monitoring program can monitor the change condition of the class files in the file directory of the distributed file system in a mode of analyzing the log of the distributed file system. The method specifically comprises the following steps: acquiring a log of the distributed file system; and determining the change condition of the class files in the file directories of the distributed file system according to the file directory change information in the log. Specifically, in the process of uploading the class files by the file transmission device, the distributed file system may generate logs based on file change information in a file directory, and the monitoring program may obtain the logs of the distributed file system; and determining the change condition of the class files in the file directories of the distributed file system according to the file directory change information in the log. The change condition of the class files in the file directory of the distributed file system is monitored by analyzing the log of the distributed file system, and compared with the method of directly monitoring the file change in the file directory, the method can reduce the consumption of resources.
In some embodiments, the file directory change information may include an identifier of an uploaded class file and an upload path, and accordingly, a target class file that changes is determined according to the identifier of the uploaded class file, so that the custom class loader loads the target class file from a file directory of the distributed file system into a container according to the upload path. Specifically, the monitoring program may determine the class file that has changed according to the identifier of the uploaded class file, determine the class file as a target class file, and then provide the identifier of the target class file and the upload path to the custom loader. By the method, the monitoring program can accurately identify the class files which are changed in transmission, and the efficiency of loading the class files by the follow-up custom loader is improved.
In some embodiments, the custom class loader uses a full disk responsibility delegation mechanism when loading the target class file. Wherein, the full-disk responsible delegation mechanism is that when one class loader is responsible for loading a class file, other classes depended on and referring to the class file will also be loaded by the class loader unless another class loader is used for loading. When the user-defined class loader loads the class file, the parent loader is also loaded firstly, and the parent loader is loaded by the user when not loaded. The loading mode can avoid repeated loading of the class files and improve the loading efficiency of the class files.
In some embodiments, before the custom class loader loads the target class file, the method includes: verifying the target class file, and loading the target class file under the condition that the verification is passed; wherein the verification comprises at least one of file format verification, metadata verification, byte code verification and symbol reference verification.
The file format verification mainly verifies whether the byte stream conforms to the Class file format specification or not and can be loaded and processed by the current virtual machine. For example: whether the major and minor version numbers are within the processing range of the current virtual machine. And verifying whether the constant type which is not supported exists in the constant pool, and whether the index value in the constant is not existed or is not consistent with the constant of the type.
The metadata verification comprises the steps of carrying out semantic analysis on the information described by the byte codes and analyzing whether the information conforms to the specification of java language grammar.
The bytecode verification includes analyzing the data stream and controls to determine that the semantics are legal and logical. The method mainly aims at the verification of the method body after the metadata verification. And ensuring that the class method does not have harm during operation.
The symbol reference verification: the method mainly aims at the situation that the access type and the like relate to the reference when the symbolic reference is converted into the direct reference, so that the reference can be accessed, and the problem that the class and the like cannot be accessed can be solved.
Through the verification method, whether the loaded class has a correct internal structure or not can be verified, and the loaded class is coordinated with other classes and consistent with the other classes, so that the application in the container is prevented from being maliciously invaded, and the safety of the container is improved.
In some embodiments, for the case that the file transfer apparatus is configured to upload the encrypted class files to a specified directory of the distributed file system, the container cluster is further configured to decrypt the changed target class files, and invoke the custom class loader to load the decrypted target class files into the container. Specifically, the class file decryption device can be called by the monitoring program to decrypt the object class file, and the information of the decrypted object class file is transmitted to the custom class loader, so that the custom class loader loads the decrypted object class file into the container.
The monitoring program is explained with a scenario example. In this scenario example, the execution steps of the monitoring program are shown in fig. 4, and may include:
and (3) reading the class file change log at regular time: the file directory change log of the distributed file system is read, file changes in the directory are monitored, and simultaneous change of a plurality of files can be supported.
Reading the class file: and finding a corresponding directory traversal read class file according to the change log, and acquiring binary information.
Decrypting the class file: and decrypting the file information through encryption algorithm encryption to obtain the original Class file information.
Calling a class loader: and transferring the Class file information to a custom Class loader, and dynamically loading classes through the custom Class loader.
In some embodiments, the container cluster may further be configured to, when the current user usage amount of the container in which the custom class loader is located is greater than a preset threshold, start a new container, so as to load the target class file using the custom class loader in the new container. Specifically, when the current user usage amount of the container where the Class loader is located is large and a Class file currently being updated is present, as a standby scheme for real-time loading, the current container notifies the PaaS platform to start a new container to load a new Class file, and executes an elegant shutdown instruction, the current container does not receive a new user request any more, and the current container is deleted after the currently executing operation is completed, so that smooth switching between a new container and an old container is realized, and the deployment efficiency of the container application is further improved.
In this embodiment, the system may include: the file transmission device is used for uploading the class files to a specified directory of the distributed file system; the container cluster is used for monitoring the change condition of the class files in the file directory of the distributed file system through a monitoring program; under the condition that class files in a file directory of the distributed file system change, calling a custom class loader to load the changed target class files into a container so as to replace the old version class files corresponding to the target class files in the container; instantiating an object using the target class file in the event a user request is received. The system provided by the embodiment of the present specification is based on a Java class loader technology, and monitors a directory in which class files are stored outside a container, for example, a distributed file system is used to store the class files, a custom class loader is used to dynamically load the class files, and the class files are read from the directory of the distributed file system and replace the original class files in the container, so that the problem that the use of a user is interrupted due to the redeployment of the container is solved, and the deployment efficiency of container application is improved.
Please refer to fig. 5. Based on the application heat deployment system, the embodiment of the present specification provides an application heat deployment method. In the embodiments of the present specification, the subject performing the application heat deployment method may be a container cluster formed of a plurality of containers. The method may include the following steps.
S510: and monitoring the change condition of the class files in the file directory of the distributed file system.
In some embodiments, the file transfer apparatus may upload the class file to a specified directory of the distributed file system, the distributed file system stores the class file in the specified directory when receiving the class file, and the container cluster may monitor a change of the class file in the file directory of the distributed file system through the monitoring program.
The file transmission device can provide a class file uploading page so that a user can conveniently upload the class file to a specified directory of the distributed file system through the class file uploading page; the class file uploading page supports multi-file uploading and specifies each file uploading path. Specifically, the user may select one or more class files to be uploaded on the class file upload page, and specify an upload path of each file, thereby implementing the upload of the class files. In a specific example, a user may select one or more class files to be uploaded from local files, specify an upload path of each file in an upload path selection box, and click an upload button, where the class file upload page may upload the selected one or more class files to a file directory of the distributed file system according to the upload path in response to an upload operation triggered by the user.
In some embodiments, monitoring the change of class files in the file directory of the distributed file system may be implemented by analyzing the log of the distributed file system. The method specifically comprises the following steps: acquiring a log of the distributed file system; and determining the change condition of the class files in the file directories of the distributed file system according to the file directory change information in the log. Specifically, in the process of uploading the class files by the file transmission device, the distributed file system may generate logs based on file change information in a file directory, and the monitoring program may obtain the logs of the distributed file system; and determining the change condition of the class files in the file directories of the distributed file system according to the file directory change information in the log. The change condition of the class files in the file directory of the distributed file system is monitored by analyzing the log of the distributed file system, and compared with the method of directly monitoring the file change in the file directory, the method can reduce the consumption of resources.
In some embodiments, the file directory change information may include an identifier of an uploaded class file and an upload path, and accordingly, a target class file that changes is determined according to the identifier of the uploaded class file, so that the custom class loader loads the target class file from a file directory of the distributed file system into a container according to the upload path. Specifically, the monitoring program may determine the class file that has changed according to the identifier of the uploaded class file, determine the class file as a target class file, and then provide the identifier of the target class file and the upload path to the custom loader. By the method, the monitoring program can accurately identify the class files which are changed in transmission, and the efficiency of loading the class files by the follow-up custom loader is improved.
S520: and under the condition that class files in a file directory of the distributed file system change, calling a custom class loader to load the changed target class files into a container so as to replace the old version class files corresponding to the target class files in the container.
In some embodiments, the custom class loader uses a full disk responsibility delegation mechanism when loading the target class file. Wherein, the full-disk responsible delegation mechanism is that when one class loader is responsible for loading a class file, other classes depended on and referring to the class file will also be loaded by the class loader unless another class loader is used for loading. When the user-defined class loader loads the class file, the parent loader is also loaded firstly, and the parent loader is loaded by the user when not loaded. The loading mode can avoid repeated loading of the class files and improve the loading efficiency of the class files.
In some embodiments, before the custom class loader loads the target class file, the method includes: verifying the target class file, and loading the target class file under the condition that the verification is passed; wherein the verification comprises at least one of file format verification, metadata verification, byte code verification and symbol reference verification.
The file format verification mainly verifies whether the byte stream conforms to the Class file format specification or not and can be loaded and processed by the current virtual machine. For example: whether the major and minor version numbers are within the processing range of the current virtual machine. And verifying whether the constant type which is not supported exists in the constant pool, and whether the index value in the constant is not existed or is not consistent with the constant of the type.
The metadata verification comprises the steps of carrying out semantic analysis on the information described by the byte codes and analyzing whether the information conforms to the specification of java language grammar.
The bytecode verification includes analyzing the data stream and controls to determine that the semantics are legal and logical. The method mainly aims at the verification of the method body after the metadata verification. And ensuring that the class method does not have harm during operation.
The symbol reference verification: the method mainly aims at the situation that the access type and the like relate to the reference when the symbolic reference is converted into the direct reference, so that the reference can be accessed, and the problem that the class and the like cannot be accessed can be solved.
Through the verification method, whether the loaded class has a correct internal structure or not can be verified, and the loaded class is coordinated with other classes and consistent with the other classes, so that the application in the container is prevented from being maliciously invaded, and the safety of the container is improved.
In some embodiments, when the target class file is an encrypted file, the changed target class file may be decrypted, and a custom class loader is invoked to load the decrypted target class file into the container. Specifically, the class file decryption device can be called by the monitoring program to decrypt the object class file, and the information of the decrypted object class file is transmitted to the custom class loader, so that the custom class loader loads the decrypted object class file into the container.
In some embodiments, when the current user usage amount of the container in which the custom class loader is located is greater than a preset threshold, a new container is started, so that the target class file is loaded by using the custom class loader in the new container. Specifically, when the current user usage amount of the container where the Class loader is located is large and a Class file currently being updated is present, as a standby scheme for real-time loading, the current container notifies the PaaS platform to start a new container to load a new Class file, and executes an elegant shutdown instruction, the current container does not receive a new user request any more, and the current container is deleted after the currently executing operation is completed, so that smooth switching between a new container and an old container is realized, and the deployment efficiency of the container application is further improved.
S530: instantiating an object using the target class file in the event a user request is received.
In particular, an object may be instantiated using a loaded class file upon receiving a user request. Instantiation refers to the process of creating objects with classes in object-oriented programming. The instantiation process is generally composed of a class name object name (new class name) (parameter 1, parameter 2.. parameter n).
The method provided by the embodiment of the specification can monitor the change condition of the class file in the file directory of the distributed file system; under the condition that class files in a file directory of the distributed file system change, calling a custom class loader to load the changed target class files into a container so as to replace the old version class files corresponding to the target class files in the container; instantiating an object using the target class file in the event a user request is received. The method provided by the embodiment of the specification is based on a class loader technology of Java, and is characterized in that a directory for storing class files outside a container is monitored, for example, a distributed file system is used for storing the class files, a user-defined class loader is used for dynamically loading the class files, the class files are read from the directory of the distributed file system and replace the original class files in the container, so that the problem that the use of a user is interrupted due to the redeployment of the container is solved, and the deployment efficiency of container application is improved.
Fig. 6 is a functional structure diagram of an application thermal deployment apparatus according to a first embodiment of the present disclosure, where the apparatus may specifically include the following structural modules.
The monitoring module 610 is configured to monitor a change condition of a class file in a file directory of the distributed file system;
a loading module 620, configured to, when class files in a file directory of the distributed file system change, invoke a custom class loader to load the changed target class files into a container, so as to replace old version class files corresponding to the target class files in the container;
an instantiation module 630, configured to instantiate an object using the target class file in case of receiving a user request.
It should be noted that the application hot deployment system, method and apparatus provided in the embodiments of the present specification can be applied to the technical field of big data processing. Of course, the present invention may also be applied to the financial field, or any field other than the financial field, and the application field of the thermal deployment system, method, and apparatus is not limited in the embodiments of the present specification.
It should be noted that, in the present specification, each embodiment is described in a progressive manner, and the same or similar parts in each embodiment may be referred to each other, and each embodiment focuses on differences from other embodiments. In particular, as for the apparatus embodiment and the apparatus embodiment, since they are substantially similar to the method embodiment, the description is relatively simple, and reference may be made to some descriptions of the method embodiment for relevant points.
After reading this specification, persons skilled in the art will appreciate that any combination of some or all of the embodiments set forth herein, without inventive faculty, is within the scope of the disclosure and protection of this specification.
In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Language Description Language), traffic, pl (core unified Programming Language), HDCal, JHDL (Java Hardware Description Language), langue, Lola, HDL, laspam, hardbyscript Description Language (vhr Description Language), and vhjhd (Hardware Description Language), which is currently used by most popular version-software. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
From the above description of the embodiments, it is clear to those skilled in the art that the present specification can be implemented by software plus a necessary general hardware platform. Based on such understanding, the technical solutions of the present specification may be essentially or partially implemented in the form of software products, which may be stored in a storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and include instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments of the present specification.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The description is operational with numerous general purpose or special purpose computing system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet-type devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
This description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
While the specification has been described with examples, those skilled in the art will appreciate that there are numerous variations and permutations of the specification that do not depart from the spirit of the specification, and it is intended that the appended claims include such variations and modifications that do not depart from the spirit of the specification.
Claims (10)
1. An applied heat deployment system, the system comprising:
the file transmission device is used for uploading the class files to a specified directory of a file directory of the distributed file system;
the container cluster is used for monitoring the change condition of the class files in the file directory of the distributed file system through a monitoring program; under the condition that class files in a file directory of the distributed file system change, calling a custom class loader to load the changed target class files into a container so as to replace the old version class files corresponding to the target class files in the container; instantiating an object using the target class file in the event a user request is received.
2. The system of claim 1, wherein the file transfer device provides a class file upload page, so that a user can upload the class file to a specified directory of the distributed file system through the class file upload page; the class file uploading page supports multi-file uploading and specifies each file uploading path.
3. The system of claim 1, further comprising:
the class file encryption device is used for reading a class file generated by compiling the development environment; encrypting the class file through an encryption algorithm;
correspondingly, the file transmission device is used for uploading the encrypted class files to a specified directory of the distributed file system;
the container cluster is also used for decrypting the changed target class files and calling the custom class loader to load the decrypted target class files into the container.
4. The system of claim 1, wherein the monitoring for changes to class files in file directories of the distributed file system comprises:
acquiring a log of the distributed file system;
and determining the change condition of the class files in the file directories of the distributed file system according to the file directory change information in the log.
5. The system according to claim 4, wherein the file directory change information includes an identification of the uploaded class file and an upload path;
correspondingly, the changed target class file is determined according to the identifier of the uploaded class file, so that the user-defined class loader loads the target class file into a container from the file directory of the distributed file system according to the uploading path.
6. The system of claim 1, wherein the custom class loader uses a full disk responsibility delegation mechanism when loading a target class file.
7. The system of claim 1, wherein before the custom class loader loads the target class file, the system comprises:
verifying the target class file, and loading the target class file under the condition that the verification is passed; wherein the verification comprises at least one of file format verification, metadata verification, byte code verification and symbol reference verification.
8. The system of claim 1, wherein the container cluster is further configured to launch a new container to facilitate loading the target class file using the custom class loader in the new container if a current user usage of the container in which the custom class loader is located is greater than a preset threshold.
9. A method of applying thermal deployment, the method comprising:
monitoring the change condition of class files in a file directory of the distributed file system;
under the condition that class files in a file directory of the distributed file system change, calling a custom class loader to load the changed target class files into a container so as to replace the old version class files corresponding to the target class files in the container;
instantiating an object using the target class file in the event a user request is received.
10. An applied heat deployment device, the device comprising:
the monitoring module is used for monitoring the change condition of the class files in the file directory of the distributed file system;
the loading module is used for calling a custom class loader to load a changed target class file into a container to replace an old version class file corresponding to the target class file in the container under the condition that the class file in a file directory of the distributed file system is changed;
and the instantiation module is used for instantiating the object by using the target class file under the condition of receiving a user request.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110346752.3A CN112835865A (en) | 2021-03-31 | 2021-03-31 | Application hot deployment system, method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110346752.3A CN112835865A (en) | 2021-03-31 | 2021-03-31 | Application hot deployment system, method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112835865A true CN112835865A (en) | 2021-05-25 |
Family
ID=75930664
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110346752.3A Pending CN112835865A (en) | 2021-03-31 | 2021-03-31 | Application hot deployment system, method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112835865A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113221077A (en) * | 2021-05-31 | 2021-08-06 | 平安科技（深圳）有限公司 | Class file encryption method and equipment based on spring container |
-
2021
- 2021-03-31 CN CN202110346752.3A patent/CN112835865A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113221077A (en) * | 2021-05-31 | 2021-08-06 | 平安科技（深圳）有限公司 | Class file encryption method and equipment based on spring container |
| CN113221077B (en) * | 2021-05-31 | 2023-11-14 | 平安科技（深圳）有限公司 | Class file encryption method and equipment based on spring container |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9983891B1 (en) | Systems and methods for distributing configuration templates with application containers | |
| US10824716B2 (en) | Executing native-code applications in a browser | |
| US9864600B2 (en) | Method and system for virtualization of software applications | |
| KR102255767B1 (en) | Systems and methods for virtual machine auditing | |
| US9779111B2 (en) | Method and system for configuration of virtualized software applications | |
| US8739147B2 (en) | Class isolation to minimize memory usage in a device | |
| US6519594B1 (en) | Computer-implemented sharing of java classes for increased memory efficiency and communication method | |
| US20100205604A1 (en) | Systems and methods for efficiently running multiple instances of multiple applications | |
| US10146942B2 (en) | Method to protect BIOS NVRAM from malicious code injection by encrypting NVRAM variables and system therefor | |
| US10574524B2 (en) | Increasing reusability of and reducing storage resources required for virtual machine images | |
| US11556348B2 (en) | Bootstrapping profile-guided compilation and verification | |
| KR20000053113A (en) | Information appliance architecture | |
| US20240078116A1 (en) | Just-in-Time Containers | |
| US8893272B2 (en) | Method and device for recombining runtime instruction | |
| EP3518116A1 (en) | Method and apparatus for layered access of file in virtualization instance | |
| CN112835865A (en) | Application hot deployment system, method and device | |
| CN112231384A (en) | Distributed application localization transformation method and device adaptive to multiple data sources | |
| US8745605B2 (en) | Execution contexts with polymorphic type implementations | |
| US10169113B2 (en) | Storage and application intercommunication using ACPI | |
| CN115016862A (en) | Kubernetes cluster-based software starting method, device, server and storage medium | |
| US11726922B2 (en) | Memory protection in hypervisor environments | |
| Tang et al. | Basic Knowledge of Firmware | |
| US20240152371A1 (en) | Dynamic re-execution of parts of a containerized application pipeline | |
| US20240012666A1 (en) | Protecting container images and runtime data | |
| De Clercq | Lightweight container alternatives for deploying |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |