Hot deployment method and device of micro-service application, storage medium and electronic equipment

By listening for source code file change events on the target server and automatically identifying the handler based on the file type for hot deployment, the problem of low efficiency in microservice application code modification and deployment is solved, achieving rapid response and efficient development and testing processes.

CN121523712APending Publication Date: 2026-02-13AGRICULTURAL BANK OF CHINA
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511723527.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-11-21
Publication Date
2026-02-13

AI Technical Summary

Technical Problem

In existing technologies, code modifications and deployments of microservice applications depend on the entire deployment pipeline, resulting in low development and testing efficiency.

Method used

By monitoring source code file change events through the application service proxy on the target server, the system automatically identifies and calls the corresponding processor for hot deployment based on the file type, including the processing of class file types, container file types, development framework configuration file types, and database operation statement file types, thereby shortening the code's effective time.

Benefits of technology

It enables real-time automatic identification and hot deployment of code changes in microservice applications, improving development and testing efficiency, reducing reliance on middleware such as configuration centers, and shortening the waiting time of traditional pipeline deployment methods.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121523712A_ABST
    Figure CN121523712A_ABST
Patent Text Reader

Abstract

The invention discloses a hot deployment method and device for a micro-service application, a storage medium and electronic equipment. The method comprises the following steps: monitoring a source code file change event of a target micro-service application through an application service agent end in a target server; under the condition that the source code file change event is monitored, determining a target processor according to the file type of the changed source code file; performing hot deployment processing on the changed source code file through the target processor to obtain a deployment result; the deployment result is returned to the target plug-in end, and the target plug-in end is used for triggering the source code file change event. Through the method and the device, the problem of relatively low development and test efficiency caused by the fact that code modification and deployment of the micro-service application are realized by depending on the whole assembly line deployment link in the related technology is solved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of financial technology, and more specifically, to a method and apparatus for hot deployment of microservice applications, a storage medium, and an electronic device. Background Technology

[0002] With the rapid development of the software industry and the popularity of cloud-native development models, software developers in financial institutions need to frequently add or modify code for application deployment every day. However, each deployment requires going through a long pipeline process, including pulling source code, code compliance checks, image creation and uploading, application service downtime, and deployment of new images, resulting in low development and testing efficiency.

[0003] There is currently no effective solution to the problem that relying on the entire deployment pipeline to modify and deploy microservice applications leads to low development and testing efficiency in related technologies. Summary of the Invention

[0004] The main objective of this application is to provide a method, apparatus, storage medium, and electronic device for hot deployment of microservice applications, in order to solve the problem that relying on the entire deployment pipeline to achieve code modification and deployment of microservice applications in related technologies leads to low development and testing efficiency.

[0005] To achieve the above objectives, according to one aspect of this application, a hot deployment method for a microservice application is provided. The method includes: monitoring source code file change events of the target microservice application through an application service proxy in a target server; upon detecting a source code file change event, determining a target processor based on the file type of the changed source code file; performing hot deployment processing on the changed source code file through the target processor to obtain a deployment result; and returning the deployment result to a target plugin, wherein the target plugin is used to trigger the source code file change event.

[0006] Furthermore, before listening for source code file change events of the target microservice application through the application service agent in the target server, the method also includes: responding to the target object's selected modified source code file to be deployed and the target server through the target plugin; converting the modified source code file into a binary byte stream file, and transmitting the binary byte stream file to the listening directory of the application service agent.

[0007] Furthermore, determining the target processor based on the file type of the changed source code file includes: if the file type is a class file type or a container file type, the first processor is used as the target processor; if the file type is a development framework configuration file type or a database operation statement file type, the second processor is used as the target processor.

[0008] Furthermore, when the file type is a class file type, the target processor performs hot deployment processing on the changed source code file, and the deployment result includes: obtaining a binary byte stream file from the listening directory through the first processor; updating the bytecode information of the corresponding class in the virtual machine based on the binary byte stream file to obtain the updated bytecode information; and determining the deployment result based on the updated bytecode information.

[0009] Furthermore, when the file type is a container file type, the target processor performs hot deployment processing on the changed source code file, and the deployment result includes: determining the class object associated with the binary byte stream file in the container through the first processor; overloading the class object to obtain the overloading result, and determining the deployment result based on the overloading result.

[0010] Furthermore, when the file type is a development framework configuration file, the target processor performs hot deployment processing on the changed source code file, and the deployment result includes: obtaining a binary byte stream file from the listening directory through the second processor; parsing the binary byte stream file to obtain the object tags in the binary byte stream file; reloading all objects and all dependent objects associated with the objects in the binary byte stream file according to the object tags to obtain the reloading result, and determining the deployment result based on the reloading result.

[0011] Furthermore, when the file type is a database operation statement file, the target processor performs hot deployment processing on the changed source code file, and the deployment result includes: obtaining a binary byte stream file from the listening directory through the second processor; updating the database configuration file based on the binary byte stream file to obtain an updated database configuration file; and determining the deployment result based on the updated database configuration file.

[0012] To achieve the above objectives, according to another aspect of this application, a hot deployment apparatus for a microservice application is provided. The apparatus includes: a first processing unit, configured to listen for source code file change events of a target microservice application via an application service proxy in a target server; a first determining unit, configured to determine a target processor based on the file type of the changed source code file upon detecting a source code file change event; a second processing unit, configured to perform hot deployment processing on the changed source code file through the target processor to obtain a deployment result; and a third processing unit, configured to return the deployment result to a target plugin, wherein the target plugin is used to trigger the source code file change event.

[0013] Furthermore, the device also includes: a fourth processing unit, used to respond to the target object's selected modified source code file and target server via the target plugin end before listening for source code file change events of the target microservice application through the application service proxy end in the target server; and a fifth processing unit, used to convert the modified source code file into a binary byte stream file and transmit the binary byte stream file to the listening directory of the application service proxy end.

[0014] Furthermore, the first determining unit includes: a first determining subunit, used to determine the first processor as the target processor when the file type is a class file type or a container file type; and a second determining subunit, used to determine the second processor as the target processor when the file type is a development framework configuration file type or a database operation statement file type.

[0015] Furthermore, when the file type is a class file type, the second processing unit includes: a first processing subunit, used to obtain a binary byte stream file from the listening directory through the first processor; a second processing subunit, used to update the bytecode information of the corresponding class in the virtual machine according to the binary byte stream file, and obtain the updated bytecode information; and a third processing subunit, used to determine the deployment result according to the updated bytecode information.

[0016] Furthermore, when the file type is a container file type, the second processing unit includes: a fourth processing subunit, used to determine the class object associated with the binary byte stream file in the container through the first processor; and a fifth processing subunit, used to overload the class object, obtain the overload result, and determine the deployment result based on the overload result.

[0017] Furthermore, when the file type is a development framework configuration file type, the second processing unit includes: a sixth processing subunit, used to obtain a binary byte stream file from the listening directory through the second processor; a seventh processing subunit, used to parse the binary byte stream file to obtain object tags in the binary byte stream file; and an eighth processing subunit, used to reload all objects and all dependent objects associated with objects in the binary byte stream file according to the object tags, obtain the reload result, and determine the deployment result based on the reload result.

[0018] Furthermore, when the file type is a database operation statement file type, the second processing unit includes: a ninth processing subunit, used to obtain a binary byte stream file from the listening directory through the second processor; a tenth processing subunit, used to update the database configuration file according to the binary byte stream file to obtain the updated database configuration file; and an eleventh processing subunit, used to determine the deployment result according to the updated database configuration file.

[0019] According to another aspect of the present invention, an electronic device is also provided, comprising: a memory storing an executable program; and a processor for running the program, wherein the program executes the hot deployment method of the microservice application described above during runtime.

[0020] According to another aspect of the present invention, a computer-readable storage medium is also provided, the storage medium storing a program, wherein, when the program is running, the device where the storage medium is located executes the microservice application of any of the above-mentioned methods.

[0021] In this embodiment, the following steps are employed: The application service proxy on the target server listens for source code file change events of the target microservice application; upon detecting a source code file change event, a target processor is determined based on the file type of the changed source code file; the target processor performs hot deployment processing on the changed source code file to obtain a deployment result; and the deployment result is returned to the target plugin, where the target plugin is used to trigger the source code file change event. This solves the technical problem in related technologies where relying on the entire deployment pipeline to modify and deploy microservice application code leads to low development and testing efficiency.

[0022] In this solution, by deploying an application service proxy on the target server, we can monitor source code file change events of microservice applications in real time. When a change in the source code file is detected, we can automatically identify the file type and call the corresponding processor for hot deployment. This shortens the time of waiting for the code to take effect in the traditional pipeline deployment method, and does not rely on third-party middleware such as configuration centers, thus effectively improving the efficiency of development and testing. Attached Figure Description

[0023] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0024] Figure 1 A hardware block diagram of a computer terminal for implementing a hot deployment method for microservice applications is shown.

[0025] Figure 2 This is a flowchart of a hot deployment method for microservice applications provided according to an embodiment of this application;

[0026] Figure 3 This is a schematic diagram of a hot deployment system architecture for microservice applications provided according to embodiments of this application;

[0027] Figure 4 This is a schematic diagram of the hot deployment process provided according to an embodiment of this application;

[0028] Figure 5 This is a schematic diagram illustrating the configuration file reloading process of the development framework provided in the embodiments of this application;

[0029] Figure 6 This is a schematic diagram of the database operation statement file reloading process provided in the embodiments of this application;

[0030] Figure 7 This is a schematic diagram of a hot deployment device for microservice applications provided according to an embodiment of this application;

[0031] Figure 8 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0032] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0033] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0034] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding access points are provided for users to choose to authorize or refuse. For example, interfaces are set up between this system and relevant users or organizations, providing users with corresponding access points to choose to agree to or refuse automated decision-making results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0035] Example 1

[0036] According to an embodiment of this application, a method embodiment for hot deployment of microservice applications is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0037] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal (or mobile device) for implementing a hot deployment method for microservice applications is shown. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0038] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0039] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the hot deployment method of microservice applications in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned hot deployment method of microservice applications. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0040] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0041] The display may be a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0042] Under the aforementioned operating environment, this application provides the following: Figure 2 The hot deployment method for microservice applications is shown. Figure 2 This is a flowchart of a hot deployment method for a microservice application according to Embodiment 1 of this application. The hot deployment method for the microservice application includes:

[0043] Step S201: Listen for source code file change events of the target microservice application through the application service proxy in the target server;

[0044] Step S202: Upon detecting a source code file change event, determine the target processor based on the file type of the changed source code file;

[0045] Step S203: Perform hot deployment processing on the modified source code file through the target processor to obtain the deployment result;

[0046] Step S204: Return the deployment result to the target plugin, whereby the target plugin is used to trigger the source code file change event.

[0047] In an alternative embodiment, Figure 3 This is a schematic diagram of a hot deployment system architecture for microservice applications provided in the embodiments of this application, such as... Figure 3 As shown, the system comprises three core components: the application service script side, the application service proxy side, and the integrated development environment (IDE) plugin side. The application service script side includes service restart and hot deployment environment installation. The application service proxy side includes a transport layer (file transfer, deployment logs), a listening layer (class files, Extensible Markup Language (XML) files, and other file types), and a processing layer (class container processors, middleware processors, and custom processors). The application service proxy side also includes instrumentation processors, enhanced class loaders, and class redefiners. The IDE plugin side includes functions such as selecting source code files, selecting deployment machines, updating file uploads, and displaying deployment results.

[0048] By constructing three core components—the application service script side, the application service proxy side, and the integrated development environment (IDE) plugin side—each plays its respective role during the application startup, runtime, and source code development processes, achieving the goal of making microservice application source code modifications take effect within seconds through hot deployment. Specifically, the application service script side is responsible for automating the integration work such as building startup parameters and service startup; the proxy side is responsible for implementing hot deployment functionality upon project startup, including monitoring file changes, reloading source code and development frameworks, and providing feedback on processing results; and the IDE plugin side provides developers with convenient hot deployment operations during code development, including selecting the hot deployment machine, compiling source files, uploading files, and displaying hot deployment results.

[0049] In an alternative embodiment, Figure 4 This is a schematic diagram of the hot deployment process provided in the embodiments of this application, such as... Figure 4As shown, the application service proxy monitors file changes in a specific directory through four different types of listeners (class listener, development framework configuration file listener, class object addition listener, and database operation statement listener). These changes include modifications and additions of class files, changes to development framework configuration files, additions of class objects, and modifications to database operation statement files. When a listener detects a file change, it initiates a hot deployment process, calling the appropriate handler based on the file type to execute the corresponding processing flow. For example, when a class file modification is detected, object instance overloading logic is triggered. Optionally, non-blocking I / O (NIO) can be used to monitor changes to local source code files, triggering file change events.

[0050] Optionally, in the hot deployment method for microservice applications provided in this application embodiment, before listening to source code file change events of the target microservice application through the application service proxy in the target server, the method further includes: responding to the changed source code file to be deployed and the target server selected by the target object through the target plugin end; converting the changed source code file into a binary byte stream file, and transmitting the binary byte stream file to the listening directory of the application service proxy.

[0051] In an optional embodiment, before monitoring source code file change events of the target microservice application via the application service proxy on the target server, two directories ( / extraClasspath and / classes) are predefined on the server where the application is deployed (i.e., the target server). / extraClasspath is a custom extended classpath URL (Uniform Resource Locator), and / classes is the directory to be monitored. When there is a source code change, the deployment machine can be selected through the target plugin (i.e., the integrated development environment plugin), thereby triggering the monitoring directory on the application service proxy. Optionally, the technical implementation of monitoring file changes can utilize the monitoring services natively provided by the development language.

[0052] In an optional embodiment, in response to the user-selected modified source code file to be deployed and the deployment machine (i.e., the target server) on the integrated development environment plugin side, the modified source code file is converted into a binary byte stream file, and the binary byte stream file is transmitted to the beginning of the URL of the listening directory on the application service agent side.

[0053] In an optional embodiment, when the application service agent in the target server detects a source code file change event, it determines the target processor based on the file type of the changed source code file. For example, if the file type is a class file type or a container file type, the target processor is determined to be a class container processor. Then, the changed source code file is hot-deployed through the target processor, and the deployment result is returned to the integrated development environment plugin to display the deployment result to the user.

[0054] In summary, the embodiments of this application employ the following steps: monitoring source code file change events of the target microservice application through an application service proxy on the target server; determining a target processor based on the file type of the changed source code file upon detecting a source code file change event; performing hot deployment processing on the changed source code file through the target processor to obtain a deployment result; and returning the deployment result to the target plugin, where the target plugin is used to trigger the source code file change event. This solves the technical problem in related technologies where relying on the entire deployment pipeline for microservice application code modification and deployment leads to low development and testing efficiency.

[0055] In this solution, by deploying an application service proxy on the target server, we can monitor source code file change events of microservice applications in real time. When a change in the source code file is detected, we can automatically identify the file type and call the corresponding processor for hot deployment. This shortens the time of waiting for the code to take effect in the traditional pipeline deployment method, and does not rely on third-party middleware such as configuration centers, thus effectively improving the efficiency of development and testing.

[0056] Optionally, in the hot deployment method for microservice applications provided in this application embodiment, determining the target processor based on the file type of the changed source code file includes: if the file type is a class file type or a container file type, using the first processor as the target processor; if the file type is a development framework configuration file type or a database operation statement file type, using the second processor as the target processor.

[0057] In an optional embodiment, if the file type is a class file or a container file, the class container processor (i.e., the first processor) is used as the target processor. If the file type is a development framework configuration file or a database operation statement file, the middleware processor (i.e., the second processor) is used as the target processor. For example, for modifications to a class file, the proxy will trigger the class container processor to reload the class file. The class container processor first checks whether the class file has already been loaded by an existing class loader. If not loaded, it uses bytecode enhancement technology to load the new file into the virtual machine, update the classpath, and ensure that the new version of the class file is loaded preferentially on the next call. If it has already been loaded, it calls the class redefiner to update the class definition directly at runtime, making the modifications take effect immediately and achieving hot deployment.

[0058] The file type-based processor selection mechanism can more accurately locate objects that are hot-updated, improve the efficiency and accuracy of hot deployment, and reduce unnecessary resource waste.

[0059] Optionally, in the hot deployment method for microservice applications provided in this application embodiment, when the file type is a class file type, the target processor performs hot deployment processing on the changed source code file to obtain the deployment result, including: obtaining a binary byte stream file from the listening directory through the first processor; updating the bytecode information of the corresponding class in the virtual machine according to the binary byte stream file to obtain the updated bytecode information; and determining the deployment result based on the updated bytecode information.

[0060] In an optional embodiment, when the file type is a class file type, the binary byte stream file is obtained from the listening directory through the class container processor, the bytecode information of the corresponding class in the virtual machine is updated according to the binary byte stream file, the updated bytecode information is obtained, and the deployment result is determined according to the updated bytecode information.

[0061] In an optional embodiment, the class type file overloading process is as follows: First, during application startup, the proxy obtains the user class loader using bytecode enhancement. During application runtime, the class loader retrieves binary byte streams from the listening directory to load class files. The class loader maintains a set of URLs. When a class file is needed during runtime, the virtual machine traverses these URLs sequentially from the corresponding class loader, with the earlier URLs having the highest priority. By instrumenting custom directories during application startup, the virtual machine prioritizes searching for files modified by the developer when looking for and loading class files.

[0062] The above process improves the response speed of code changes, saves a lot of time waiting for deployment to take effect, and enhances the efficiency of software development.

[0063] Optionally, in the hot deployment method for microservice applications provided in this application embodiment, when the file type is a container file type, the target processor performs hot deployment processing on the changed source code file to obtain the deployment result, including: determining the class object associated with the binary byte stream file in the container through the first processor; overloading the class object to obtain the overloading result, and determining the deployment result based on the overloading result.

[0064] In an optional embodiment, when the file type is a container file type, the class object associated with the binary byte stream file in the container is determined by the class container processor, the class object is overloaded to obtain the overload result, and the deployment result is determined based on the overload result.

[0065] In an optional embodiment, after modifying a class file, in addition to reloading the class itself, all objects already instantiated in the container also need to be reloaded to ensure that the instantiated objects held by files referencing that class are up-to-date. For example, class objects injected using the discretionary method are old instances and need to be reloaded to ensure that the class objects held by the container are up-to-date. The object reloading process in the container is as follows: First, at application startup, class objects in annotation format are parsed, and all class objects in the current package that are marked as components are scanned; at startup, bytecode enhancement is performed on the startup class, and the relationship between package path and development framework context metadata is maintained: scanning package path → class scanner → class context. For example, when class object A is modified, all other class objects that depend on A in the development framework path are scanned and destroyed together.

[0066] Through the above process, it is ensured that the class objects in the container that depend on the modified bytecode files can be updated in a timely manner, avoiding application anomalies caused by inconsistent class object versions.

[0067] Optionally, in the hot deployment method for microservice applications provided in this application embodiment, when the file type is a development framework configuration file type, the target processor performs hot deployment processing on the changed source code file to obtain the deployment result, which includes: obtaining a binary byte stream file from the listening directory through a second processor; parsing the binary byte stream file to obtain object tags in the binary byte stream file; reloading all objects and all dependent objects associated with the objects in the binary byte stream file according to the object tags to obtain the reloading result, and determining the deployment result based on the reloading result.

[0068] In an optional embodiment, when the file type is a development framework configuration file type, the middleware processor obtains a binary byte stream file (configuration file) from the listening directory, parses the binary byte stream file to obtain object tags in the binary byte stream file, and then reloads all objects and all dependent objects associated with objects in the binary byte stream file according to the object tags to obtain the reload result, and determines the deployment result based on the reload result.

[0069] In an optional embodiment, when modifying / adding a development framework configuration file, all class objects in the configuration file need to be overloaded, and the microservice needs to be restarted after the overload. Figure 5 This is a schematic diagram illustrating the configuration file reloading process of the development framework provided in the embodiments of this application, such as... Figure 5 As shown, when a change in the development framework configuration file is detected, the object definition reader is found according to the development framework startup registry. The custom object definition reader parses the object tags in all configuration files and reloads all objects in the current configuration file and all other objects that depend on the current object.

[0070] Through the above process, precise control over dependencies is achieved, enabling microservice applications to quickly adapt to changes in source code files during operation.

[0071] Optionally, in the hot deployment method for microservice applications provided in this application embodiment, when the file type is a database operation statement file type, the target processor performs hot deployment processing on the changed source code file to obtain the deployment result, including: obtaining a binary byte stream file from the listening directory through a second processor; updating the database configuration file according to the binary byte stream file to obtain an updated database configuration file; and determining the deployment result based on the updated database configuration file.

[0072] In an optional embodiment, when the file type is a database operation statement file, the middleware processor obtains a binary byte stream file (database operation statement change file) from the listening directory, updates the database configuration file based on the binary byte stream file, obtains the updated database configuration file, and determines the deployment result based on the updated database configuration file.

[0073] In an alternative embodiment, Figure 6 This is a schematic diagram illustrating the database operation statement file reloading process provided in the embodiments of this application, such as... Figure 6As shown, during service startup, all database operation framework configuration paths are first obtained through bytecode enhancement, and their mapping to the development framework context is maintained. After project startup, all configurations are categorized. When a database operation statement file needs to be reloaded, the configuration is matched first, and then the configuration is reloaded to achieve hot deployment. For example, if the database operation statement changes, the loaded SQL resources are cleared and the SQL configuration is re-registered; if the database operation framework annotation changes, the loaded annotation resources are cleared and the microservice is restarted.

[0074] The above process ensures real-time updates of database operation statements, improving development efficiency and system stability.

[0075] The hot deployment method for microservice applications provided in this application includes the following steps: monitoring source code file change events of the target microservice application through an application service proxy on the target server; determining a target processor based on the file type of the changed source code file upon detecting a source code file change event; performing hot deployment processing on the changed source code file through the target processor to obtain a deployment result; and returning the deployment result to the target plugin, where the target plugin is used to trigger the source code file change event. This method solves the technical problem in related technologies where relying on the entire deployment pipeline for microservice application code modification and deployment leads to low development and testing efficiency.

[0076] In this solution, by deploying an application service proxy on the target server, we can monitor source code file change events of microservice applications in real time. When a change in the source code file is detected, we can automatically identify the file type and call the corresponding processor for hot deployment. This shortens the time of waiting for the code to take effect in the traditional pipeline deployment method, and does not rely on third-party middleware such as configuration centers, thus effectively improving the efficiency of development and testing.

[0077] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0078] Example 2

[0079] This application also provides a hot deployment apparatus for microservice applications. It should be noted that the hot deployment apparatus for microservice applications in this application can be used to execute the hot deployment method for microservice applications provided in this application. The following describes the hot deployment apparatus for microservice applications provided in this application.

[0080] According to an embodiment of this application, a hot deployment apparatus for a microservice application, used for implementing the above-described hot deployment method for microservice applications, is also provided, such as... Figure 7 As shown, the device includes: a first processing unit 701, a first determining unit 702, a second processing unit 703, and a third processing unit 704.

[0081] The first processing unit 701 is used to listen for source code file change events of the target microservice application through the application service proxy in the target server.

[0082] The first determining unit 702 is used to determine the target processor based on the file type of the source code file that has been changed when a source code file change event is detected.

[0083] The second processing unit 703 is used to perform hot deployment processing on the modified source code file through the target processor to obtain the deployment result;

[0084] The third processing unit 704 is used to return the deployment result to the target plugin, wherein the target plugin is used to trigger the source code file change event.

[0085] The microservice application hot deployment apparatus provided in this application embodiment monitors source code file change events of the target microservice application through an application service proxy on the target server via a first processing unit 701. Upon detecting a source code file change event, a first determining unit 702 determines a target processor based on the file type of the changed source code file. A second processing unit 703 performs hot deployment processing on the changed source code file using the target processor to obtain a deployment result. A third processing unit 704 returns the deployment result to the target plugin, where the target plugin triggers the source code file change event. By deploying an application service proxy on the target server, real-time monitoring of source code file change events of the microservice application is achieved. This allows for automatic identification and invocation of the corresponding processor for hot deployment based on the file type when a change in the source code file is detected, shortening the waiting time for code to take effect in traditional pipeline deployment methods. It also eliminates the need for third-party middleware such as configuration centers, effectively improving development and testing efficiency.

[0086] Optionally, in the hot deployment apparatus for microservice applications provided in this application embodiment, the apparatus further includes: a fourth processing unit, configured to respond to the target object's selected modified source code file and target server via the target plugin end before listening to the source code file change event of the target microservice application through the application service proxy end in the target server; and a fifth processing unit, configured to convert the modified source code file into a binary byte stream file and transmit the binary byte stream file to the listening directory of the application service proxy end.

[0087] Optionally, in the hot deployment apparatus for microservice applications provided in this application embodiment, the first determining unit includes: a first determining subunit, used to determine the first processor as the target processor when the file type is a class file type or a container file type; and a second determining subunit, used to determine the second processor as the target processor when the file type is a development framework configuration file type or a database operation statement file type.

[0088] Optionally, in the hot deployment apparatus for microservice applications provided in this application embodiment, when the file type is a class file type, the second processing unit includes: a first processing subunit, used to obtain a binary byte stream file from the listening directory through a first processor; a second processing subunit, used to update the bytecode information of the corresponding class in the virtual machine according to the binary byte stream file, to obtain the updated bytecode information; and a third processing subunit, used to determine the deployment result according to the updated bytecode information.

[0089] Optionally, in the hot deployment apparatus for microservice applications provided in this application embodiment, when the file type is a container file type, the second processing unit includes: a fourth processing subunit, used to determine the class object associated with the binary byte stream file in the container through the first processor; and a fifth processing subunit, used to reload the class object, obtain the reload result, and determine the deployment result based on the reload result.

[0090] Optionally, in the hot deployment apparatus for microservice applications provided in this application embodiment, when the file type is a development framework configuration file type, the second processing unit includes: a sixth processing subunit, used to obtain a binary byte stream file from the listening directory through a second processor; a seventh processing subunit, used to parse the binary byte stream file to obtain object tags in the binary byte stream file; and an eighth processing subunit, used to reload all objects and all dependent objects associated with the objects in the binary byte stream file according to the object tags, obtain the reload result, and determine the deployment result based on the reload result.

[0091] Optionally, in the hot deployment apparatus for microservice applications provided in this application embodiment, when the file type is a database operation statement file type, the second processing unit includes: a ninth processing subunit, used to obtain a binary byte stream file from the listening directory through a second processor; a tenth processing subunit, used to update the database configuration file according to the binary byte stream file to obtain an updated database configuration file; and an eleventh processing subunit, used to determine the deployment result according to the updated database configuration file.

[0092] It should be noted that the first processing unit 701, the first determining unit 702, the second processing unit 703, and the third processing unit 704 mentioned above correspond to steps S201 to S204 in Embodiment 1. The four units and the corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above units can also be part of a device and run in the computer terminal 10 provided in Embodiment 1.

[0093] Example 3

[0094] Embodiments of this application may provide an electronic device. Figure 8 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 8 As shown, the electronic device may include: one or more ( Figure 8 (Only one is shown) processor 802, memory 804, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0095] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-described methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0096] The processor can access information and applications stored in memory via a transmission device to perform the following steps: listen for source code file change events of the target microservice application through the application service agent in the target server; if a source code file change event is detected, determine the target processor based on the file type of the changed source code file; perform hot deployment processing on the changed source code file through the target processor to obtain the deployment result; and return the deployment result to the target plugin, whereby the target plugin is used to trigger the source code file change event.

[0097] The processor can invoke information and applications stored in memory through the transmission device to perform the following steps: before listening for source code file change events of the target microservice application through the application service agent in the target server, responding to the target object's selected modified source code file and target server through the target plugin end; converting the modified source code file into a binary byte stream file, and transmitting the binary byte stream file to the listening directory of the application service agent.

[0098] The processor can access information and applications stored in the memory via a transmission device to perform the following steps: if the file type is a class file type or a container file type, the first processor is used as the target processor; if the file type is a development framework configuration file type or a database operation statement file type, the second processor is used as the target processor.

[0099] The processor can access information and applications stored in memory via a transmission device to perform the following steps: obtain a binary byte stream file from the listening directory through the first processor; update the bytecode information of the corresponding class in the virtual machine based on the binary byte stream file to obtain the updated bytecode information; and determine the deployment result based on the updated bytecode information.

[0100] The processor can invoke information and applications stored in the memory through the transmission device to perform the following steps: determine the class object associated with the binary byte stream file in the container through the first processor; overload the class object to obtain the overload result, and determine the deployment result based on the overload result.

[0101] The processor can access information and applications stored in memory via a transmission device to perform the following steps: obtain a binary byte stream file from the listening directory via a second processor; parse the binary byte stream file to obtain object tags in the binary byte stream file; reload all objects and all dependent objects associated with objects in the binary byte stream file according to the object tags to obtain the reload results, and determine the deployment results based on the reload results.

[0102] The processor can access information and applications stored in memory via a transmission device to perform the following steps: obtain a binary byte stream file from the listening directory via a second processor; update the database configuration file based on the binary byte stream file to obtain an updated database configuration file; and determine the deployment result based on the updated database configuration file.

[0103] Those skilled in the art will understand that Figure 8 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 8 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 8 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 8 The different configurations shown.

[0104] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0105] Example 4

[0106] Embodiments of this application also provide a computer-readable storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the hot deployment method for microservice applications provided in Embodiment 1.

[0107] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0108] This application also provides a computer program product that, when executed on a data processing device, is suitable for performing hot deployment method steps for a microservice application.

[0109] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0110] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0111] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0112] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0113] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0114] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0115] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for hot deployment of microservice applications, characterized in that, The method comprises the following steps: listening to a source code file change event of a target microservice application by an application service agent in a target server; determining a target processor according to a file type of the changed source code file when the source code file change event is listened to; performing hot deployment processing on the changed source code file by the target processor to obtain a deployment result; returning the deployment result to a target plug-in end, wherein the target plug-in end is used to trigger the source code file change event.

2. The method of claim 1, wherein, Before listening to the source code file change event of the target microservice application by the application service agent in the target server, the method further comprises the following steps: responding to the target server and the changed source code file to be deployed selected by a target object through the target plug-in end; converting the changed source code file into a binary byte stream file and transmitting the binary byte stream file to a listening directory of the application service agent.

3. The method of claim 1, wherein, Determining a target processor according to a file type of the changed source code file comprises the following steps: in the case that the file type is a class file type or a container file type, a first processor is used as the target processor; in the case that the file type is a development framework configuration file type or a database operation statement file type, a second processor is used as the target processor.

4. The method of claim 3, wherein, In the case that the file type is a class file type, performing hot deployment processing on the changed source code file by the target processor to obtain a deployment result comprises the following steps: acquiring a binary byte stream file from a listening directory by the first processor; updating bytecode information of a corresponding class in a virtual machine according to the binary byte stream file to obtain updated bytecode information; determining the deployment result according to the updated bytecode information.

5. The method of claim 4, wherein, In the case that the file type is a container file type, performing hot deployment processing on the changed source code file by the target processor to obtain a deployment result comprises the following steps: determining a class object associated with the binary byte stream file in a container by the first processor; overloading the class object to obtain an overloading result, and determining the deployment result according to the overloading result.

6. The method of claim 3, wherein, In the case that the file type is a development framework configuration file type, performing hot deployment processing on the changed source code file by the target processor to obtain a deployment result comprises the following steps: acquiring a binary byte stream file from a listening directory by the second processor; parsing the binary byte stream file to obtain an object label in the binary byte stream file; overloading all objects in the binary byte stream file and dependent objects associated with the all objects according to the object label to obtain an overloading result, and determining the deployment result according to the overloading result.

7. The method of claim 3, wherein, In the case that the file type is a database operation statement file type, performing hot deployment processing on the changed source code file by the target processor to obtain a deployment result comprises the following steps: acquiring a binary byte stream file from a listening directory by the second processor; According to the binary byte stream file, a database configuration file is updated to obtain an updated database configuration file; According to the updated database configuration file, the deployment result is determined.

8. A hot deployment device for microservice applications, characterized in that, Comprise: The first processing unit is configured to listen to a source code file change event of a target micro-service application through an application service agent in a target server; The first determining unit is configured to determine a target processor according to a file type of a changed source code file when the source code file change event is listened to; The second processing unit is configured to perform hot deployment processing on the changed source code file through the target processor to obtain a deployment result; The third processing unit is configured to return the deployment result to a target plug-in end, wherein the target plug-in end is configured to trigger the source code file change event.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium comprises a stored executable program, wherein when the executable program is running, the computer readable storage medium controls the device where the computer readable storage medium is located to execute the hot deployment method of the micro-service application in any one of claims 1 to 7.

10. An electronic device, comprising: Comprise: The memory stores an executable program; The processor is configured to run the program, wherein the program executes the hot deployment method of the micro-service application in any one of claims 1 to 7 when the program is running.