Micro-service deployment method and device, equipment and storage medium

Abstract

The invention relates to the technical field of low-code platforms, and provides a micro-service deployment method, device and equipment and a storage medium, and the method comprises the steps: in a class loading process of an integrated service process, obtaining class definition data of a current to-be-loaded class, the integrated service process being a single operation instance containing a plurality of micro-services; identifying the class definition data to obtain a remote proxy class for realizing remote procedure call; replacing a remote call instruction pointing to a network communication layer in the remote proxy class with a local method call instruction pointing to a target service instance in the same process to obtain a modified remote proxy class; and loading the modified remote agent class into an integration service process, so that the integration service process runs based on a local method calling instruction in the modified remote agent class, and deployment of the multiple micro-services is completed. The method effectively solves the problems that an existing low-code platform is high in deployment cost in a privatized or lightweight scene, and the system fluency is restricted by a network.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of low-code platforms, and in particular to a micro-service deployment method, device, equipment and storage medium. BACKGROUND

[0002] With the development of software development technology, low-code platforms are usually built using Java language and Spring Boot framework, and micro-service architecture is commonly used to achieve business decoupling.

[0003] Currently, applications are usually split into multiple independent micro-services for deployment, and communicate through Remote Procedure Call (RPC). However, fine-grained service splitting results in large deployment resource requirements, increasing hardware costs, and network communication latency between micro-services restricts system smoothness. In addition, multiple independent environments are usually established to achieve environmental isolation, further increasing deployment costs. If micro-services are rolled back to monolithic applications to reduce costs, a large amount of code refactoring work is often involved, resulting in uncontrollable development and testing scope. SUMMARY

[0004] The present application provides a micro-service deployment method, device, equipment and storage medium to solve the defects in the prior art.

[0005] The present application provides a micro-service deployment method, comprising the following steps: In the class loading process of the integrated service process, the class definition data of the current class to be loaded is obtained, and the integrated service process is a monolithic running instance containing multiple micro-services; A remote proxy class for implementing remote procedure calls is identified from the class definition data; The remote call instruction in the remote proxy class pointing to the network communication layer is replaced with a local method call instruction pointing to the target service instance in the same process to obtain a modified remote proxy class; The modified remote proxy class is loaded into the integrated service process, so that the integrated service process runs based on the local method call instruction in the modified remote proxy class, and the deployment of the multiple micro-services is completed.

[0006] According to the micro-service deployment method provided by the present application, the remote call instruction in the remote proxy class pointing to the network communication layer is replaced with a local method call instruction pointing to the target service instance in the same process to obtain a modified remote proxy class, comprising: Parsing the class structure of the remote proxy class, and determining the target method node for executing remote calls from the class structure according to the parsing result; obtaining reference information of a target service instance matching the remote call in the integration service process; generating a local call instruction based on the reference information, and replacing remote call instruction pointing to a network communication layer in the target method node with the local call instruction to obtain the modified remote proxy class.

[0007] According to the microservice deployment method provided by the application, the class structure of the remote proxy class is parsed, and a target method node for executing a remote call is determined from the class structure according to a parsing result, including: traversing a method list in the class structure, and matching the target method node from the method list according to a method signature of a remote interface.

[0008] According to the microservice deployment method provided by the application, before obtaining class definition data of a current class to be loaded, the method further includes: adding the build products corresponding to the plurality of microservices to dependency items of the integration service project; performing a packaging operation on the integration service project to obtain an integration service deployment package; embedding the build products in the form of internal dependency packages under a class path of the integration service deployment package according to the dependency items, and specifying a main startup class of the integration service project as a startup entrance in the integration service deployment package to obtain a runnable integration service deployment package; starting the integration service process by using the runnable integration service deployment package.

[0009] According to the microservice deployment method provided by the application, the packaging operation is performed on the integration service project to obtain an integration service deployment package, including: scanning third-party dependency libraries corresponding to each microservice respectively, and calculating a public dependency intersection between the microservices based on a scanning result; promoting third-party dependency libraries belonging to the public dependency intersection to a parent dependency path of the integration service project, and removing the public dependency set from dependency configurations of each microservice in the integration service project to obtain a governance service project; performing a packaging operation on the governance service project to obtain the integration service deployment package.

[0010] According to the microservice deployment method provided by the application, before the packaging operation is performed on the governance service project, the method further includes: extracting public configuration items declared in each microservice, and generating a public configuration file in the governance service project based on the public configuration items; configuring the public configuration file as a default loading configuration of the governance service project; Obtain a root package path of a build product corresponding to each microservice, and modify a component scanning path of a main startup class of the governance service project based on the root package path, so that the modified component scanning path covers the root package path.

[0011] According to the microservice deployment method provided in the application, in the process of starting the integrated service process, the method further comprises: reading a deployment mode configuration parameter from the executable integrated service deployment package; in the case where the deployment mode configuration parameter indicates a single-machine deployment mode, initializing a local memory component; injecting an interface implementation of the initialized local memory component into a dependency injection container of the integrated service process.

[0012] According to the microservice deployment method provided in the application, the starting of the integrated service process by using the executable integrated service deployment package further comprises: obtaining a loading manifest of a business module from the executable integrated service deployment package; based on the identification of each microservice in the loading manifest, determining enabled microservices and disabled microservices from the microservices; in the process of starting the integrated service process, loading class definition data corresponding to the enabled microservices, and skipping the initialization process of the disabled microservices.

[0013] According to the microservice deployment method provided in the application, after the deployment of the plurality of microservices is completed, the method further comprises: constructing a sandbox running domain isolated from a production running domain in the integrated service process; establishing a data synchronization pipeline connecting the sandbox running domain and the production running domain; in response to a debugging instruction in the sandbox running domain, receiving business change metadata through the data synchronization pipeline, and hot loading the business change metadata in the production running domain.

[0014] The application further provides a microservice deployment device comprising the following modules: an obtaining module, configured to obtain class definition data of a current class to be loaded in a class loading process of an integrated service process, the integrated service process being a monolithic running instance containing a plurality of microservices; an identifying module, configured to identify a remote proxy class for implementing remote procedure calling from the class definition data; a replacing module, configured to replace a remote calling instruction in the remote proxy class pointing to a network communication layer with a local method calling instruction pointing to a target service instance in the same process, to obtain a modified remote proxy class; The deployment module is used to load the modified remote proxy class into the integration service process, so that the integration service process runs based on the local method call instructions in the modified remote proxy class to complete the deployment of the multiple microservices.

[0015] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the microservice deployment method described above.

[0016] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the microservice deployment method as described above.

[0017] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the microservice deployment method as described above.

[0018] The microservice deployment method, apparatus, device, and storage medium provided by this invention identify proxy classes used for remote calls during the class loading process of the integrated service process. They transparently replace time-consuming instructions originally pointing to the network communication layer with efficient local method call instructions pointing to the target service instance within the same process, and run based on the modified classes. This allows for the conversion of a distributed architecture to a monolithic architecture without modifying the original microservice business code. By eliminating network transmission overhead and serialization costs between microservices, this effectively solves the problems of high deployment costs and network-dependent system smoothness in private or lightweight scenarios of existing low-code platforms. It also avoids the enormous code refactoring workload and uncontrollable testing risks faced when reverting microservices to monolithic applications. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the microservice deployment method provided by the present invention.

[0021] Figure 2 This is a schematic diagram of microservice invocation provided by the present invention.

[0022] Figure 3 This is a schematic diagram of the integrated service process provided by the present invention.

[0023] Figure 4 This is a schematic diagram illustrating the construction process of the integrated service deployment package provided by this invention.

[0024] Figure 5 This is a schematic diagram of the microservice deployment device provided by the present invention.

[0025] Figure 6 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0027] In low-code application scenarios, users modify application metadata while editing the application. If the application is used online, problems may arise during the adjustment process. Therefore, some low-code platforms introduce version control. Because low-code platforms are relatively complex systems, they are typically developed using Java, and the Spring Boot framework is commonly used. To achieve system decoupling, existing low-code platforms usually adopt a microservice architecture, breaking the system down into multiple independent microservices.

[0028] However, as the granularity of microservice architecture increases and the number of microservices grows, the resources required for deployment also increase. As microservice systems become larger, business stakeholders are often reluctant to deploy too many microservices due to cost considerations. While a pluggable design can deploy a small number of microservices to ensure the main business process runs smoothly in scenarios with low coupling, highly coupled systems still require a large number of microservices to work together, failing to achieve the goals of resource saving and performance improvement. Furthermore, regarding environment isolation, existing platforms primarily adopt a pre-set approach with multiple environments for development, testing, and production, each with independent data sources and configuration parameters, or by incorporating built-in debug buttons for version comparison. These environment isolation solutions are costly to deploy, and complex inter-microservice calls involve network transmission, limiting system smoothness due to network conditions. Built-in debug buttons often only test single-point functions and cannot fundamentally solve the problem of users wanting to perform overall connectivity testing from development to production. If microservices are transformed into general monolithic applications in order to reduce costs and network overhead, the amount of code that needs to be modified is often huge, and sometimes the entire microservices need to be scrapped and rebuilt, resulting in uncontrollable development and testing scope. Therefore, the industry rarely considers this approach.

[0029] To address this, the present invention provides a microservice deployment method. During the class loading process of an integrated service process, the method obtains the class definition data of the class to be loaded, identifies a remote proxy class for implementing remote procedure calls from the class definition data, and replaces the remote call instructions pointing to the network communication layer in the remote proxy class with local method call instructions pointing to the target service instance within the same process. This allows the modified remote proxy class to be loaded into the integrated service process for execution. This method enables the merging of multiple microservices into a single running instance without extensive code modifications, effectively reducing deployment resource consumption and eliminating network transmission overhead between microservices, thereby improving system performance and deployment flexibility.

[0030] in, Figure 1 This is a flowchart illustrating the microservice deployment method provided by the present invention, as follows: Figure 1 As shown, the method includes steps 110, 120, 130 and 140.

[0031] Step 110: During the class loading process of the integration service process, obtain the class definition data of the class to be loaded. The integration service process is a monolithic running instance containing multiple microservices.

[0032] Specifically, the integrated service process can be understood as a unified service carrier that aggregates multiple microservices that would otherwise be deployed independently into a single process space. Unlike related technologies that deploy each microservice as an independent operating system process, the integrated service process can significantly reduce the overall resource consumption of the system by sharing the underlying runtime environment.

[0033] Specifically, in complex business scenarios such as low-code platforms, microservice architecture is typically used for decoupling. The more microservices there are, the more deployment resources are required. The Integrating Service Process, as a monolithic running instance containing multiple microservices, aims to solve the high cost problem caused by the large scale of microservice architectures, enabling business users to deploy systems at a lower cost without sacrificing the integrity of business functions.

[0034] During the startup and initialization phase of the integration service process, class loading is involved. The class loading process refers to the process by which the Java Virtual Machine loads the data describing the class from the Class file into memory, and performs verification, conversion, parsing, and initialization on the data, ultimately forming a Java type that can be directly used by the virtual machine.

[0035] The class definition data of the currently loaded class can be understood as a binary byte stream describing the corresponding class structure. The class definition data includes information such as the class version, constant pool, access flags, current class index, parent class index, interface index set, field table set, method table set, and attribute table set.

[0036] Step 120: Identify the remote proxy class used to implement remote procedure calls from the class definition data.

[0037] Specifically, the remote proxy class used to implement remote procedure calls can be understood as a client stub used in a microservice architecture to perform network communication on behalf of a remote service.

[0038] Because the integration process incorporates multiple microservices, the interfaces originally defined in the code for inter-service calls are dynamically generated as proxy classes by the RPC framework at runtime. These proxy classes will still attempt to initiate network requests even without modification. Therefore, it is necessary to identify the remote proxy classes from the class definition data obtained in step 110.

[0039] As an optional implementation, remote proxy classes can be identified based on features in the class definition data. For example, it can be checked whether the class uses specific RPC framework annotations, or whether the class implements a specific RPC interface, or whether the class's naming conventions conform to the generation rules for RPC proxy classes.

[0040] Step 130: Replace the remote call instruction pointing to the network communication layer in the remote proxy class with the local method call instruction pointing to the target service instance within the same process, and obtain the modified remote proxy class.

[0041] Given that the integrated service process is a monolithic instance containing multiple microservices—meaning that service providers and consumers, originally distributed across different servers, now reside within the same process address space—continuing to make calls through the network communication layer would not only incur unnecessary network serialization or deserialization overhead but could also lead to call failures due to port conflicts or network loops, thus failing to achieve the desired resource savings and performance improvements.

[0042] Based on this, this embodiment replaces the remote call instruction pointing to the network communication layer in the remote proxy class with the local method call instruction pointing to the target service instance within the same process, thus obtaining the modified remote proxy class.

[0043] Here, remote method invocation instructions pointing to the network communication layer can be understood as a sequence of instructions that invoke the underlying network sending method of the RPC framework at the bytecode level. Local method invocation instructions pointing to a target service instance within the same process can be understood as instructions that directly invoke the target method through an object reference at the bytecode level.

[0044] Specifically, this step modifies the remote proxy class, replacing the original complex instruction logic of "encapsulating the request → serialization → sending over the network → waiting for a response" with a simpler instruction logic of "obtaining the local singleton object → directly calling the method". Since this embodiment dynamically modifies the class definition at the underlying level using bytecode technology during the class loading phase, rather than modifying the source code during the compilation phase, this replacement is transparent. That is, the original business logic does not require any modification, but at runtime, its underlying execution logic undergoes a fundamental change.

[0045] Step 140: Load the modified remote proxy class into the integration service process so that the integration service process runs based on the local method call instructions in the modified remote proxy class, thus completing the deployment of multiple microservices.

[0046] After modifying the remote proxy class, the modified remote proxy class needs to be returned to the class loader, which will then complete the subsequent linking and initialization steps and generate the corresponding Class object in memory.

[0047] Once the integration service process is running, business interactions between microservices will no longer go through the network protocol stack, but will be completed directly in the process's heap memory. This means that although the system still maintains the decoupled characteristics of microservices from a code structure perspective (each service code is independent and its responsibilities are separated), from a runtime performance perspective, the system behaves like a highly efficient monolithic application.

[0048] Furthermore, deploying multiple microservices involves more than just starting the process; it also includes ensuring that each microservice can correctly discover each other and work together. Through these steps, the originally complex distributed microservice environment is compressed into a lightweight monolithic process, eliminating strong dependencies on heavy middleware such as external service registries and configuration centers, thus achieving lightweight deployment.

[0049] In summary, the microservice deployment method provided in this embodiment identifies the proxy class used for remote calls during the class loading process of the integrated service process. It transparently replaces the time-consuming instructions originally pointing to the network communication layer with efficient local method call instructions pointing to the target service instance within the same process, and runs based on the modified class. This allows the distributed architecture to be converted into a monolithic architecture without modifying the original microservice business code. By eliminating the network transmission overhead and serialization costs between microservices, it effectively solves the problems of high deployment costs and network-dependent system smoothness in private or lightweight scenarios of existing low-code platforms. It also avoids the enormous code refactoring workload and uncontrollable testing risks faced when reverting microservices to monolithic applications.

[0050] in, Figure 2 This is a diagram illustrating microservice calls provided by the present invention, such as... Figure 2As shown, at the business logic level, microservice A needs to initiate a remote procedure call (RPC call) to microservice B. At this point, both microservice A and microservice B have been packaged and are running in the same integrated service process. Microservice A originally attempted to initiate the network request by holding a remote proxy class of microservice B.

[0051] Then, during the class loading process of the integrated service process, bytecode processing technology was used to intercept the class definition data of the remote proxy class in microservice A that is used to call microservice B, and the class was identified from the data as a proxy class used to implement remote procedure calls.

[0052] Next, the bytecode of the remote proxy class is modified, replacing the remote call instruction that originally pointed to the network communication layer with the local method call instruction that points to the target service instance corresponding to microservice B in the same process, thus obtaining the modified remote proxy class.

[0053] Finally, the integration service process loads and runs based on the modified remote proxy class. When microservice A initiates a call, it actually executes a local method call instruction, directly accessing the target service instance of microservice B in the process's memory, thus converting the original RPC call into a local memory call and skipping the network transmission stage.

[0054] Figure 3 This is a schematic diagram of the integrated service process provided by the present invention, such as... Figure 3 As shown, in the integration service process, firstly, the integration service process is started. This process, as a monolithic running instance containing microservice A and microservice B, begins loading the code for microservice A and microservice B. The ASM Agent, as a bytecode enhancement proxy probe, is configured to monitor the class loading process of this process.

[0055] Then, during the class loading process of the integration service, the ASM Agent intercepts the class definition data of the remote proxy class in microservice A, which was originally used to remotely call microservice B over the network. The ASM Agent identifies these classes as RPC proxy classes from the intercepted data and modifies their bytecode.

[0056] Next, the ASM Agent replaces the remote call instructions in the remote proxy class that originally pointed to the network communication layer with local method call instructions that point to the target service instance corresponding to microservice B within the same process. Finally, the integration service process loads the modified class and runs it. In runtime, microservice A directly accesses microservice B through local method calls. Both share the same process space and do not need to go through an external network protocol stack, thus completing the lightweight deployment and efficient interaction of multiple microservices.

[0057] Simply identifying the remote proxy class is insufficient to achieve the communication mechanism conversion; the specific calling logic must be precisely located, and accurate modifications and reorganizations must be made at the bytecode level to ensure that the business logic flows correctly within the monolithic process without disrupting the original parameter passing. To achieve this, it is necessary to deeply analyze the internal structure of the class and find the correct local instance for interface operation.

[0058] Specifically, the modified remote proxy class is obtained by replacing the remote call instructions pointing to the network communication layer in the remote proxy class with local method call instructions pointing to the target service instance within the same process, including: Parse the class structure of the remote proxy class, and determine the target method node for executing the remote call from the class structure based on the parsing results; Obtain reference information for the target service instance that matches the remote call within the integration service process; Based on the reference information, a local invocation instruction is generated, and the remote invocation instruction pointing to the network communication layer in the target method node is replaced with the local invocation instruction to obtain the modified remote proxy class.

[0059] Specifically, the class structure of a remote proxy class can be understood as an organization based on the Java bytecode format, which includes a constant pool, interface table, field table, method table, and attribute table, etc.

[0060] A target method node can be understood as a bytecode fragment in the class structure that corresponds to a business interface method. For example, if microservice A calls the getUser(Long id) interface of microservice B, then the bytecode block of the getUser method generated in the proxy class is the target method node.

[0061] Furthermore, considering that all microservices have been merged during the integration service process, the implementation class of the target service must reside in the memory container of the same process. Therefore, it is also necessary to obtain the reference information of the target service instance within the integration service process that matches the remote call. This reference information of the target service instance can be understood as the identifier or acquisition method of the local seed object in memory.

[0062] As an optional implementation, the dependency injection container running in the integration service process can be queried to find the reference information of the target service instance that matches the remote call within the integration service process, based on the type or name of the remote interface.

[0063] After obtaining the reference information, since the target instance is already ready in local memory, there is no need to go through the network communication path. Therefore, local invocation instructions can be generated based on the reference information. Local invocation instructions refer to the bytecode instruction sequence that directly manipulates the object's memory address to make a method call. Local invocation instructions can include load instructions, parameter load instructions, method invocation instructions, etc.

[0064] Finally, by replacing the remote call instruction pointing to the network communication layer in the target method node with a local call instruction, the original complex RPC network sending logic in the modified remote proxy class is simplified into efficient in-process direct call logic.

[0065] Since the modified instructions directly point to the target service instance in local memory, the modified remote proxy class, when loaded and executed, actually executes the newly generated local call instructions, thus realizing the conversion of distributed calls into direct in-process method calls at the underlying level without changing the source code.

[0066] Considering that a Java class typically contains multiple methods, including business-defined interface methods, compiler-generated constructors, and methods inherited from the parent class, not all methods in a class need to be replaced by RPC. Indiscriminate modification could disrupt the class's fundamental structure or lead to runtime errors. Therefore, this embodiment establishes a precise filtering mechanism to accurately identify the target method that truly carries the remote call logic from among numerous methods.

[0067] Specifically, the above-mentioned parsing of the class structure of the remote proxy class, and determining the target method node for executing the remote call from the class structure based on the parsing results, includes: Traverse the method list in the class structure and match the target method node from the method list based on the method signature of the remote interface.

[0068] Specifically, the method list stores metadata for all methods defined in the class. This metadata includes information such as method access permissions, method name, descriptor, and code attributes containing specific instruction codes.

[0069] Because the method list comprehensively describes all the behavioral capabilities of a class, each operation within the class can be examined individually by traversing the method list. During the traversal of the method list, the method item that perfectly matches the remote interface definition is selected based on the method signature of the remote interface, and this successfully matched method item is taken as the target method node.

[0070] This embodiment, through a precise matching mechanism based on method signatures, ensures that only business-related remote call logic is modified locally, without accidentally affecting the basic functional methods of the class, thereby guaranteeing the stability and correctness of the modified class.

[0071] To achieve lightweight deployment of microservices towards a monolithic architecture, the first step is to address the physical code aggregation issue. In a microservice architecture, each service typically consists of independent code projects and build artifacts. Simply placing them together can lead to problems such as chaotic class paths and conflicting startup entry points. Therefore, an engineering approach is needed to organize these disparate artifacts into a single executable unit.

[0072] Specifically, before obtaining the class definition data of the currently loaded class, the above process also includes: Add the build artifacts of multiple microservices to the dependencies of the integration service project; Perform a packaging operation on the integrated service project to obtain the integrated service deployment package; Based on the dependencies, the build artifacts are embedded into the classpath of the integrated service deployment package as internal dependency packages, and the main startup class of the integrated service project is specified as the startup entry point in the integrated service deployment package to obtain a runnable integrated service deployment package; Start the integration service process using the runnable integration service deployment package.

[0073] Specifically, the build artifacts for multiple microservices typically refer to the JAR files generated after compiling and packaging each microservice. The integration service project is a specially created shell project used to aggregate all business modules. Dependencies refer to the coordinates referenced in the build configuration file of the integration service project.

[0074] In order to bring together the microservice code logic scattered in different code repositories or modules into the same build context, this embodiment adds the build artifacts corresponding to multiple microservices to the dependencies of the integration service project, thereby establishing the reference relationship between the integration project and each microservice, enabling the build tool to identify and process these resources.

[0075] After adding the build artifacts of multiple microservices to the dependencies of the integration service project, the build tool triggers a compilation and packaging task to perform a packaging operation on the integration service project, resulting in the integration service deployment package. This integration service deployment package can be understood as an archive file containing the project's basic structure and metadata. To ensure that all dependent resources are handled correctly, a build plugin can be invoked during the packaging process to execute specific resource copying and manifest generation logic.

[0076] Next, based on the dependencies, the build artifacts are embedded into the classpath of the integrated service deployment package as internal dependency packages, and the main startup class of the integrated service project is specified as the startup entry point in the integrated service deployment package to obtain a runnable integrated service deployment package.

[0077] Here, internal dependency packages refer to the structure of sub-JAR packages nested within a specific directory inside the main JAR package. The classpath refers to the path where the Java Virtual Machine searches for class files. By embedding the build artifacts as internal dependency packages into the classpath of the integrated service deployment package, a custom class loader can be used to identify and load these nested JAR packages at runtime, achieving isolation and management of multiple logical modules within a single physical file.

[0078] Furthermore, to resolve the entry point conflict issue caused by multiple microservices potentially having their own startup classes, this embodiment specifies the main startup class of the integrated service project as the startup entry point in the integrated service deployment package. This ensures that the resulting runnable integrated service deployment package has a unique and clearly defined program execution starting point. Since the runnable integrated service package contains all business code, dependency libraries, and the necessary runtime bootloader, it can run independently without relying on a complex external container environment.

[0079] Finally, in the deployment environment, the above-mentioned runnable integration service deployment package can be run with a simple command to start the integration service process.

[0080] Figure 4 This is a schematic diagram of the construction process of the integrated service deployment package provided by the present invention, as shown below. Figure 4 As shown, firstly, the build artifacts corresponding to microservices A, B, and C are used as the base materials. Then, through inner dependencies (inner-jar), the build artifacts corresponding to microservices A, B, and C are added to the dependencies of the integrated service project. During this process, automated scripts control the packaging version number and perform dependency management to remove duplicate dependency libraries, ensuring that lightweight project code is introduced.

[0081] Next, the integrated service project is packaged. During the packaging process, based on the dependencies mentioned above, the build artifacts of microservices A, B, and C are embedded as internal dependency packages into the classpath of the generated integrated service deployment package, resulting in the integrated service deployment package (fat-jar). This fat-jar, as a runnable integrated service deployment package, physically aggregates the originally scattered microservices and specifies a unified main startup class as the startup entry point, thus enabling the direct startup of the integrated service process containing these three microservices.

[0082] Given that each microservice is typically developed independently, they often import a large number of identical basic dependency libraries. If they are directly merged and packaged, these duplicate dependency libraries will exist separately in the JAR file of each microservice, causing the final deployment package size to drastically increase. For example, if microservices A and B both depend on a 10MB Spring library, merging them directly would result in a 20MB package. This not only wastes disk space and network bandwidth but also increases the burden on the class loader and may even cause class conflicts due to version inconsistencies. Therefore, a thorough dependency slimming and management process is necessary before packaging.

[0083] Specifically, the above-mentioned packaging operation on the integrated service project yields an integrated service deployment package, which includes: Scan the third-party dependency libraries corresponding to each microservice, and calculate the common dependency intersection between the microservices based on the scan results; Third-party dependency libraries that belong to the intersection of common dependencies are promoted to the parent dependency path of the integration service project, and the common dependency set is removed from the dependency configuration of each microservice in the integration service project to obtain the governance service project. The governance service project is packaged to obtain an integrated service deployment package.

[0084] Specifically, the third-party dependency libraries corresponding to each microservice refer to the external open-source components or JAR files declared and referenced by the build tools in the microservice project. Since third-party dependency libraries typically have clear coordinates, scanning them allows for accurate identification and comparison of whether the library files referenced by different microservices are identical. When scanning third-party dependency libraries, the dependency tree of all microservices can be traversed, and the frequency and version information of each dependency can be counted to determine the common dependency intersections between microservices. Here, the common dependency intersection refers to the set of dependencies that exist simultaneously in two or more microservices and are version-compatible.

[0085] If the common dependencies of each microservice are stored in their respective internal JAR files, it will inevitably lead to a significant waste of disk space and runtime memory redundancy, resulting in an excessively large deployment package and slower startup speed. Therefore, this embodiment elevates the third-party dependency libraries belonging to the common dependency intersection to the parent dependency path of the integrated service project, so that only one copy of the common dependency intersection needs to be loaded at runtime for all microservices to share.

[0086] In addition, in order to completely eliminate redundant copies within microservices and prevent class loading conflicts, this embodiment also removes the common dependency set from the dependency configuration of each microservice in the integration service project, so that the resulting governance service project contains only pure business code and microservice-specific non-common dependencies.

[0087] The governance service project features an optimized dependency structure and minimized resource consumption, thus serving as the foundation for the final deployment. Based on this, this embodiment packages the governance service project to obtain an integrated service deployment package.

[0088] As can be seen, this embodiment effectively eliminates redundant dependencies through dependency governance, thereby significantly reducing the deployment package size, achieving significant savings in deployment resources and improving system startup performance.

[0089] Given that microservices operate independently, each service has its own independent configuration file, which often contains a large amount of duplicate basic configurations. Simply merging these configurations would not only make them difficult to maintain but also prone to overwrite conflicts. Therefore, in addition to dependency governance, unified governance at the configuration level is also necessary.

[0090] Specifically, the above-mentioned procedures before bundling the governance services project include: Extract the common configuration items declared in each microservice, and generate a common configuration file in the governance service project based on the common configuration items; Configure the public configuration file as the default loading configuration for the governance service project; Obtain the root package path of the corresponding build artifact for each microservice, and modify the component scanning path of the main startup class of the governance service project based on the root package path so that the modified component scanning path overrides the root package path.

[0091] Specifically, common configuration items refer to configuration entries that exist in the configuration files of multiple microservices and whose values ​​are the same or should be consistent. Considering that common configuration items determine the basic operating environment of the system, if these configurations are inconsistent, it will cause different modules to connect to different services or even fail to connect. Therefore, in the integration service project, a standardized configuration source must be established to ensure that all modules run in the same environment.

[0092] Based on this, this embodiment generates a public configuration file in the governance service project based on public configuration items. Here, the public configuration file refers to an independently stored format file, which is used to characterize the global environment parameters and infrastructure connection information shared by the entire monolithic application.

[0093] As an optional implementation, a script can be used to parse the configuration files of all microservices, identify configuration sections with identical key names and values, and treat these key-value pairs as common configuration items. These items are then written into a new file in the governance service project resource directory to generate a common configuration file.

[0094] To ensure the new configuration file takes effect at system startup, it's necessary to guarantee that the newly generated common configuration file is loaded by the main program. Specifically, this can be done by importing the generated common configuration file into the main configuration file of the integration service project, or by directly merging the common configuration content into the main configuration file. This way, all microservices will share this configuration during runtime, avoiding the hassle of maintaining it in multiple places.

[0095] Considering that frameworks like Spring Boot use a convention-over-configuration scanning strategy by default, scanning only the package containing the main startup class and its sub-packages, if the package path of a microservice is outside the main startup class's package path, the Spring container may fail to discover and instantiate components within the microservice, leading to exceptions and system startup failure. Therefore, this embodiment obtains the root package path of the corresponding build artifact for each microservice and modifies the component scanning path of the main startup class of the governance service project based on the root package path, so that the modified component scanning path overrides the root package path.

[0096] The root package path refers to the top-level Java package name where the microservice business code resides, while the component scan path refers to the baseline scope for the dependency injection container to perform classpath scanning during startup. Since the root package path explicitly indicates the physical location of each business module's code, it can be explicitly added to the scan configuration annotation of the main startup class. This ensures that the modified component scan path overrides the root package path, preventing component initialization failures due to missed scan scope.

[0097] The core objective of lightweight deployment is not only to reduce the number of processes but also to significantly reduce dependence on external infrastructure. In traditional microservice architectures, business operations often heavily rely on heavyweight middleware services. Requiring users to deploy these massive middleware clusters even in small-scale, single-machine scenarios would drastically increase hardware costs and operational complexity. Therefore, this embodiment provides a mechanism to replace expensive external middleware with low-cost local memory components in a lightweight mode.

[0098] Specifically, the process of initiating the integration service also includes: Read deployment mode configuration parameters from the runnable integrated service deployment package; If the deployment mode configuration parameters indicate a single-machine deployment mode, initialize the local memory component; The interface implementation of the initialized local memory component is injected into the dependency injection container of the integration service process to replace the microservices' dependency on external middleware calls.

[0099] Specifically, the deployment mode configuration parameter can be understood as a switch flag, used to indicate whether the current system is running in distributed cluster mode or single-machine lightweight mode. This parameter can be preset in the configuration file of the integrated service deployment package.

[0100] If the deployment mode configuration parameter indicates a single-machine deployment mode, it means that the user expects to run the system with minimal resource consumption and does not require distributed collaboration capabilities. In order to ensure the integrity of business functions in an environment without external middleware support, this embodiment initializes the local memory component, that is, creates a data structure object with cache storage or message buffering functions in the heap memory space of the JVM process.

[0101] After initializing the local memory component, considering that microservice business code is typically interface-oriented and relies on a container to obtain specific implementation classes, this embodiment also injects the interface implementation of the initialized local memory component into the dependency injection container of the integration service process. This replaces the dependency calls of each microservice to external middleware, allowing the business logic layer to seamlessly access the local memory component through the original interface call method without being aware of changes in the underlying infrastructure, thus ensuring the compatibility and operational stability of the business code. The dependency injection container is a runtime environment responsible for managing the lifecycle of Java objects and the dependencies between objects. It can automatically assemble specific implementation class instances to the dependency points of the business code according to the configuration.

[0102] In summary, this embodiment achieves hot-swapping of middleware dependencies through dynamic control of deployment mode parameters. In standalone mode, lightweight memory components replace heavy external middleware, greatly reducing the system deployment threshold and resource consumption, and truly realizing a lightweight, out-of-the-box experience.

[0103] In real-world delivery scenarios, different customers often purchase different functional modules. For example, customer A might purchase the entire system M, while customer B might only purchase module N from system M, excluding modules P and Q. Although the integrated service deployment package physically contains the code for all microservices, loading all modules indiscriminately on every startup would not only waste memory but also slow down startup, potentially causing startup errors due to missing configurations for unpurchased modules. Therefore, a dynamic mechanism is needed to load business modules on demand based on configuration.

[0104] Specifically, the above-mentioned method of starting the integration service process using a runnable integration service deployment package also includes: Obtain the loading list of business modules from the runnable integrated service deployment package; Based on the identifiers of each microservice in the loading list, determine which microservices are enabled and which are not. During the startup of the integration service process, the class definition data corresponding to the enabled microservice is loaded, and the initialization process of the unenabled microservice is skipped.

[0105] Here, the business module loading manifest can be understood as a configuration file that records which microservice modules should be activated in the current runtime environment. This manifest is usually located in the external configuration directory of the deployment package, or it is specified by the operations and maintenance personnel through parameters in the startup script.

[0106] In addition, the load list typically contains identifiers for each microservice, which are used to uniquely identify each independent business functional unit in the system. If the identifier of a microservice exists in the load list, it indicates that the corresponding microservice is enabled; if the identifier of a microservice does not exist in the load list, it indicates that the corresponding microservice is disabled.

[0107] After distinguishing between enabled and disabled microservices, the initialization behavior of the class loader and container context can be selectively controlled during the startup of the integration service process. This avoids allocating memory resources and executing initialization logic for unnecessary business functions. Specifically, it loads the class definition data corresponding to enabled microservices and skips the initialization process of disabled microservices. This saves system resources, significantly improves system startup speed, and prevents runtime errors caused by loading unauthorized or unconfigured modules.

[0108] In low-code development scenarios, users often need to modify and test simultaneously. Modifying code or configuration directly in the production environment could lead to errors that impact real business operations; building a completely independent testing environment presents challenges such as high costs and difficulties in data synchronization. Therefore, it is necessary to achieve secure isolation and efficient synchronization between development and runtime environments within the same process, ensuring both production safety and the need for rapid debugging.

[0109] Specifically, after completing the deployment of multiple microservices, the above also includes: During the service integration process, a sandbox operating domain is built that is logically isolated from the production operating domain; Establish a data synchronization pipeline connecting the sandbox operation domain and the production operation domain; In response to debugging commands within the sandbox runtime domain, it receives business change metadata through the data synchronization pipeline and hot-loads the business change metadata in the production runtime domain.

[0110] Specifically, the production runtime domain refers to the runtime environment that processes real business requests and operates on the real database. The sandbox runtime domain refers to an isolated environment used to handle user debugging requests and run temporary code.

[0111] During the service integration process, a sandbox runtime domain is built that is logically isolated from the production runtime domain. This ensures that user debugging actions and temporary code changes only take effect within the sandbox, preventing the production environment's memory state and business data from being contaminated due to code errors or configuration conflicts.

[0112] Furthermore, considering that the validated business logic needs to be applied to the production environment after debugging, or that basic configuration information of the production environment needs to be obtained during debugging, the sandbox operating domain and the production operating domain also need to have controllable data interaction capabilities. Therefore, this embodiment also establishes a data synchronization pipeline connecting the sandbox operating domain and the production operating domain. This data synchronization pipeline can efficiently transmit control commands and business data packets between isolated operating domains.

[0113] When a user clicks the debug button in the low-code editor, a debug command is triggered within the sandbox runtime domain. Responding to this command, business change metadata is received via a data synchronization pipeline and hot-loaded in the production runtime domain. This enables real-time updates to the business logic without system downtime, achieving a WYSIWYG (What You See Is What You Get) rapid iteration effect. The business change metadata refers to the description information of the modified business logic.

[0114] The microservice deployment apparatus provided by the present invention is described below. The microservice deployment apparatus described below and the microservice deployment method described above can be referred to in correspondence.

[0115] Based on any of the above embodiments Figure 5 This is a schematic diagram of the microservice deployment device provided by the present invention, as shown below. Figure 5 As shown, the device includes: The acquisition module 510 is used to obtain the class definition data of the class to be loaded during the class loading process of the integration service process. The integration service process is a monolithic running instance containing multiple microservices. The identification module 520 is used to identify the remote proxy class used to implement remote procedure calls from the class definition data; Replacement module 530 is used to replace the remote call instructions pointing to the network communication layer in the remote proxy class with local method call instructions pointing to the target service instance in the same process, so as to obtain the modified remote proxy class; Deployment module 540 is used to load the modified remote proxy class into the integration service process, so that the integration service process runs based on the local method call instructions in the modified remote proxy class to complete the deployment of multiple microservices.

[0116] Figure 6 This is a schematic diagram of the structure of the electronic device provided by the present invention, such as... Figure 6As shown, the electronic device may include a processor 610, a communications interface 620, a memory 630, and a communication bus 640. The processor 610, communications interface 620, and memory 630 communicate with each other via the communication bus 640. The processor 610 can invoke logical instructions stored in the memory 630 to execute microservice deployment methods.

[0117] Furthermore, the logical instructions in the aforementioned memory 630 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a 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 the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0118] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer is able to execute the microservice deployment methods provided by the above methods.

[0119] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the microservice deployment methods provided by the methods described above.

[0120] The device embodiments described above are merely illustrative. 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 modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0121] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0122] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A microservice deployment method, characterized by, The method comprises the following steps: In the class loading process of the integration service process, the class definition data of the current class to be loaded is obtained, and the integration service process is a monolithic running instance containing multiple microservices; A remote proxy class used to implement remote procedure calling is identified from the class definition data; Remote calling instructions in the remote proxy class pointing to a network communication layer are replaced with local method calling instructions pointing to a target service instance in the same process, to obtain a modified remote proxy class; The modified remote proxy class is loaded into the integration service process, so that the integration service process runs based on the local method calling instructions in the modified remote proxy class, and the deployment of the multiple microservices is completed.

2. The microservice deployment method of claim 1, wherein, The remote calling instructions in the remote proxy class pointing to a network communication layer are replaced with local method calling instructions pointing to a target service instance in the same process, to obtain a modified remote proxy class, which comprises the following steps: The class structure of the remote proxy class is parsed, and a target method node used to execute remote calling is determined from the class structure according to the parsing result; Reference information of a target service instance matching the remote calling in the integration service process is obtained; Local calling instructions are generated based on the reference information, and the remote calling instructions in the target method node pointing to a network communication layer are replaced with the local calling instructions, to obtain the modified remote proxy class.

3. The microservice deployment method of claim 2, wherein, The class structure of the remote proxy class is parsed, and a target method node used to execute remote calling is determined from the class structure according to the parsing result, which comprises the following steps: Method list in the class structure is traversed, and the target method node is matched from the method list according to the method signature of a remote interface.

4. The microservice deployment method of any one of claims 1 to 3, wherein, Before obtaining the class definition data of the current class to be loaded, the method further comprises the following steps: The build products corresponding to the multiple microservices are added to the dependency of the integration service project; A packaging operation is performed on the integration service project to obtain an integration service deployment package; The build products are embedded into the class path of the integration service deployment package in the form of internal dependency packages according to the dependency, and the main startup class of the integration service project is specified as a startup entry in the integration service deployment package, to obtain a runnable integration service deployment package; The integration service process is started by using the runnable integration service deployment package.

5. The microservice deployment method of claim 4, wherein, The packaging operation is performed on the integration service project to obtain an integration service deployment package, which comprises the following steps: Third-party dependency libraries corresponding to each microservice are scanned, and a public dependency intersection between the microservices is calculated based on the scanning result; Third-party dependency libraries belonging to the public dependency intersection are promoted to the parent dependency path of the integration service project, and the public dependency set is removed from the dependency configuration of each microservice in the integration service project, to obtain a governance service project; A packaging operation is performed on the governance service project to obtain the integration service deployment package.

6. The microservice deployment method of claim 5, wherein, Before the packaging operation is performed on the governance service project, the method further comprises the following steps: Public configuration items declared in each microservice are extracted, and a public configuration file is generated in the governance service project based on the public configuration items; The public configuration file is configured as the default loading configuration of the governance service project; Obtain a root package path of a build product corresponding to each microservice, and modify a component scanning path of a main startup class of the governance service project based on the root package path, so that the modified component scanning path covers the root package path.

7. The microservice deployment method of claim 4, wherein, In the process of starting the integration service process, further comprising: reading a deployment mode configuration parameter from the executable integration service deployment package; in the case where the deployment mode configuration parameter indicates a single-machine deployment mode, initializing a local memory component; injecting an interface implementation of the initialized local memory component into a dependency injection container of the integration service process.

8. The microservice deployment method of claim 4, wherein, The starting the integration service process using the executable integration service deployment package further comprises: obtaining a loading manifest of business modules from the executable integration service deployment package; based on the identification of each microservice in the loading manifest, determining enabled microservices and non-enabled microservices from the microservices; in the process of starting the integration service process, loading class definition data corresponding to the enabled microservices, and skipping the initialization process of the non-enabled microservices.

9. The microservice deployment method of any one of claims 1 to 3, wherein, After completing the deployment of the plurality of microservices, further comprising: building a sandbox running domain logically isolated from the production running domain in the integration service process; establishing a data synchronization pipeline connecting the sandbox running domain and the production running domain; in response to a debugging instruction in the sandbox running domain, receiving business change metadata through the data synchronization pipeline, and hot loading the business change metadata in the production running domain.

10. A microservice deployment apparatus, characterized by, comprising: an acquisition module, configured to acquire class definition data of a current class to be loaded in a class loading process of an integration service process, the integration service process being a monolithic running instance containing a plurality of microservices; an identification module, configured to identify a remote proxy class for implementing remote procedure calls from the class definition data; a replacement module, configured to replace a remote call instruction in the remote proxy class pointing to a network communication layer with a local method call instruction pointing to a target service instance in the same process, to obtain a modified remote proxy class; a deployment module, configured to load the modified remote proxy class into the integration service process, so that the integration service process runs based on the local method call instruction in the modified remote proxy class to complete the deployment of the plurality of microservices.

11. An electronic device comprising a memory, a processor, and a computer program stored on the memory and running on the processor, characterized in that, The processor executes the computer program to implement the microservice deployment method of any one of claims 1 to 9.

12. A non-transitory computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the microservice deployment method of any one of claims 1 to 9.

Images