Modularized system dynamic deployment method and system based on lightweight architecture

Abstract

The invention provides a modular system dynamic deployment method and system based on a lightweight architecture. The method comprises the following steps: configuring the system into a plurality of independent functional modules according to a service boundary; setting a uniform configuration file for defining a target deployment mode of the system; dynamically configuring a parameter group according to a specified target deployment mode in the configuration file; a standardized communication interface is defined for each function module, and service calling is carried out among the function modules in a dependency injection mode based on the configuration parameter set; and according to the configuration parameter group, when the system is started or operated, dynamic adaptation of a communication mechanism between the function modules is realized, so that dynamic deployment switching of the system between a single architecture and a distributed architecture is completed. According to the method, the system can be flexibly switched between the single architecture and the distributed architecture according to actual use requirements, the deployment form conversion can be completed only by modifying configuration, source codes do not need to be modified, and the development and deployment complexity of the modular system is effectively reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a modular system dynamic deployment method and system based on light architecture. BACKGROUND

[0002] With the continuous expansion of enterprise-level software systems, the traditional monolithic architecture has performance bottlenecks, maintenance difficulties and other problems when dealing with high concurrency and large-scale user access. In order to improve the scalability of the system, the industry generally uses distributed solutions such as micro-service architecture. However, these solutions usually introduce higher complexity, operation and maintenance costs, and development thresholds. For example: Traditional monolithic architecture: structure composition: all functional modules are concentrated in one application; running mode: local call, no service registration and discovery mechanism; disadvantages: poor scalability, difficult to deal with high concurrency scenarios.

[0003] Typical micro-service architecture: structure composition: multiple independent services + service registry + configuration center; running mode: each module is independently deployed and communicates through remote calls; disadvantages: complex deployment, high learning cost, and difficult migration. SUMMARY

[0004] In view of the above situation, the main purpose of the present application is to provide a modular system dynamic deployment method and system based on light architecture to solve the above technical problems.

[0005] The present application provides a modular system dynamic deployment method based on light architecture, which comprises the following steps: Step 1, according to the business boundary, configure the system into multiple independent functional modules; Step 2, set a unified configuration file to define the target deployment mode of the system; and according to the target deployment mode specified in the configuration file, dynamically configure a parameter group; Step 3, define a standardized communication interface for each functional module, and based on the configuration parameter group, perform service calls between functional modules through dependency injection; Step 4, according to the configuration parameter group, dynamically adapt the communication mechanism between functional modules when the system starts or runs, thereby completing the dynamic deployment switching of the system between monolithic architecture and distributed architecture.

[0006] The present application also provides a modular system dynamic deployment system based on light architecture, wherein the system applies the modular system dynamic deployment method based on light architecture as described above, and the system comprises: A module division unit is configured to configure the system into multiple independent functional modules according to the business boundary; An interface definition unit is configured to define a standardized communication interface for each functional module. A configuration management unit is configured to set a unified configuration file for defining a target deployment mode of the system. A deployment adaptation unit is configured to dynamically configure a parameter group according to the target deployment mode specified in the configuration file. A communication execution unit is configured to realize dynamic adaptation of a communication mechanism between functional modules according to the configuration parameter group when the system is started or running, so as to complete dynamic deployment switching between the monolithic architecture and the distributed architecture.

[0007] Compared with the prior art, the present application has the following advantages: 1. The present application defines a module group and its deployment mode through a unified configuration file, so that the system can be flexibly switched between a monolithic architecture and a distributed architecture according to actual use requirements, and the conversion of the deployment form can be completed by modifying the configuration only, without modifying the source code, thereby effectively reducing the development and deployment complexity of the modular system. The same code supports two deployment modes, greatly simplifying the system operation (DevOps) complexity in different stages, and avoiding the trouble of maintaining multiple code branches to adapt to different architectures. When the user traffic is small, the monolithic architecture mode is used for deployment, and all functional modules are aggregated in a JVM process for running. There is no need to deploy multiple application instances and Nacos middleware clusters, thereby greatly saving server resources, reducing hardware costs and energy consumption. When the business grows and the user traffic increases, the code does not need to be reconstructed, and only the configuration needs to be changed to switch to the distributed architecture mode, so that multiple servers and load balancing capabilities can be used to cope with high-concurrency scenarios, realizing the elastic scaling of the system.

[0008] 2. The present application requires strict adherence to the separation of concerns principle within each functional module, and divides the module into three standardized sub-modules, namely api, core and server, and communicates based on dependency injection (such as @DubboReference) and standardized interfaces. The forced module division makes the system structure clear, and enhances the readability and maintainability of the code. Developers can focus on the development of specific business modules, improving the parallel development efficiency. The business logic is decoupled from the communication protocol and the deployment mode. Developers do not need to care about whether the future service is a local call or a remote call when writing business code, reducing the complexity of coding and reducing the possibility of errors. And from development, testing to production, the same code can be used, and only the deployment mode is distinguished by configuration, effectively avoiding deployment and running problems caused by environmental differences, and ensuring the consistency of development and operation.

[0009] 3. In monolithic architecture mode, by pointing the URL to a local loopback address, the local call optimization features of RPC frameworks such as Dubbo are utilized. This eliminates the overhead of network serialization / deserialization and transmission required for remote calls, optimizing remote procedure calls into local method calls, significantly reducing call latency, improving system performance, and achieving the goal of lightweight deployment.

[0010] 4. This invention integrates a distributed transaction processing component and, through its architectural design, ensures consistency across all deployment modes, provided there are cross-module business data operations. In distributed mode, Seata safeguards distributed transactions. In monolithic mode, although calls are completed within the JVM, Seata can still manage cross-module data source transactions, providing a unified and reliable transaction solution. This avoids the complexity of introducing two different transaction mechanisms in each mode, enhancing system reliability and data accuracy.

[0011] 5. This invention provides a smooth technology evolution path for enterprise architecture. When transforming legacy monolithic systems into microservices, the system can be modularly decomposed according to the pattern of this invention. Initially, the system is run in monolithic mode to verify the correctness of business logic. After stabilization, the system can be gradually switched to distributed deployment by modifying configurations, greatly reducing the risks associated with refactoring. If unpredictable performance or stability issues are encountered in the distributed deployment mode, the configuration can be quickly modified to switch back to monolithic mode, ensuring system availability and buying time for troubleshooting. This is an efficient fault tolerance and recovery mechanism.

[0012] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by means of embodiments of the invention. Attached Figure Description

[0013] Figure 1 This is a flowchart of the modular system dynamic deployment method based on lightweight architecture proposed in this invention; Figure 2 This is a schematic diagram of the modular system dynamic deployment system based on lightweight architecture proposed in this invention. Detailed Implementation

[0014] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0015] These and other aspects of embodiments of the present application will become clear from the following description and the accompanying drawings. In the description and drawings, particular embodiments of the application are disclosed in connection with specific details to provide a thorough understanding of embodiments of the application. It will be apparent, however, to one skilled in the art that embodiments of the application can be practiced without many of these specific details. In other instances, well-known structures and functions have not been described in detail in order to avoid obscuring the understanding of the embodiments of the application.

[0016] Referring to the following description and drawings, these and other aspects of embodiments of the present application will become clear. In these descriptions and drawings, some specific implementations of embodiments of the present application are specifically disclosed to represent some ways of implementing embodiments of the present application, but it should be understood that the scope of embodiments of the present application is not limited thereto. Figure 1 The present embodiment provides a dynamic deployment method based on a lightweight architecture modular system, which comprises the following steps: Step 1, according to the business boundary, the system is configured into multiple independent functional modules, each independent functional module includes an api interface submodule, a core business submodule and a server startup submodule; wherein the api interface submodule is used to define and encapsulate the service interface provided by the functional module, does not contain any business logic implementation, and is depended on by other functional modules to make service calls; the core business submodule is used to implement all the core business logic of the functional module, depends on and implements the interface defined in the api interface submodule, and at the same time provides the internal domain model, data access object and business rules of the functional module; the server startup submodule is used as the starting entry of the application, depends on the core business submodule to obtain all the business functions, and itself does not contain any business logic, its responsibility is to provide the deployment and initialization ability of the whole functional module at runtime; Step 2, set a unified configuration file to define the target deployment mode of the system; and according to the target deployment mode specified in the configuration file, dynamically configure the parameter group; Wherein, the target deployment mode includes monolithic architecture mode or distributed architecture mode; the configuration file configures a parameter group for each service call interface, and the parameter group at least includes service group (group) parameter, version (version) parameter and uniform resource locator (url) parameter.

[0017] As a preferred embodiment of the present application, according to the target deployment mode specified in the configuration file, the dynamic configuration of the parameter group specifically includes the following steps: If the target deployment mode is distributed architecture mode, the service group (group) parameter and the version (version) parameter are matched with the information registered by the service provider, and the uniform resource locator (url) parameter is empty, so that the service call is routed through the service registration and discovery center; in the distributed architecture mode, each functional module is registered to the service registration and discovery center through the corresponding api interface submodule, the system depends on the service registration and discovery center for service registration and discovery, and the service registration and discovery center is Nacos.

[0018] If the target deployment mode is a monolithic architecture mode, a uniform resource locator (url) parameter of all independent function modules is configured to point to a local loopback address, and a service group (group) parameter and a version (version) parameter are left empty, so that service calling is directly completed in a local JVM process. In the monolithic architecture mode, a plurality of function modules are packaged into a unified aggregation module by a construction tool to make a service call point to a local loopback address through a uniform resource locator parameter, and the service call is optimized to a method call in a local JVM process by a remote procedure call framework. The construction tool is Maven.

[0019] Step 3, defining a standardized communication interface for each function module, and based on the configuration parameter group, performing service calling between the function modules through a dependency injection mode; As a preferred embodiment of the application, the dependency injection mode is specifically that a reference to a service provider is declared in the code of a service calling party by using an annotation. The annotation is a @DubboReference annotation, and a service group (group), a version (version) and a uniform resource locator (url) parameter are configured as configurable variables for service addressing in the @DubboReference annotation.

[0020] Step 4, according to the configuration parameter group, realizing dynamic adaptation of a communication mechanism between function modules at system startup or running, so as to complete dynamic deployment switching of the system between a monolithic architecture and a distributed architecture.

[0021] As a preferred embodiment of the application, a distributed transaction processing component is further included, which is used to ensure data consistency in a distributed deployment mode and a monolithic deployment mode when there is cross-module business data operation between function modules. The distributed transaction processing component is Seata.

[0022] The main technical stack used in the application is Java Development Kit (JDK) 8, a Spring Boot framework, a Spring Cloud Alibaba suite (including Nacos and Seata), a Dubbo framework and a MySQL database.

[0023] Embodiment 1 In order to more specifically describe the technical concept and principle of the application, two independent function modules, function module A and function module B, are taken as examples below: The function module A mainly includes three modules, namely module-a-server, module-a-core and module-a-api. The functions of each module are introduced as follows. module-a-api (i.e. the api interface submodule of function module A): used to define and encapsulate the service interface provided by module A to the outside, for calling by other function modules.

[0024] module-a-core (i.e. the core business submodule of function module A): used to implement the overall core business logic of module A; the submodule depends on module-a-api and is responsible for implementing the interface defined therein.

[0025] module-a-server (i.e. the server startup submodule of function module A): dependent on module-a-core, it serves as the application startup entry of module A and does not contain core business logic code itself.

[0026] Function module B mainly consists of three modules, namely module-b-server, module-b-core, and module-b-api, and the following introduces the role of each module: module-b-api (i.e. the api interface submodule of function module B): used to define and encapsulate the service interface provided by module B to the outside, for calling by other function modules.

[0027] module-b-core (i.e. the core business submodule of function module B): used to implement the overall core business logic of module B; the submodule depends on module-b-api and is responsible for implementing the interface defined therein.

[0028] module-b-server (i.e. the server startup submodule of function module B): dependent on module-b-core, it serves as the application startup entry of module B and does not contain core business logic code itself.

[0029] Communication between modules is achieved by introducing the api interface submodule of the target function module (for example, when module A calls module B, module-b-api is introduced) and calling the interface defined therein. The specific implementation of the communication is based on the Dubbo remote procedure call framework.

[0030] Service invoker: The specific code implementation is in the Service layer of the core business submodule (for example, module-a-core) of the invoker function module. By referencing the interface defined in the api interface submodule of the service provider function module, and using the @DubboReference annotation to complete service dependency injection. When using the @DubboReference annotation, the service group (group), version, and uniform resource locator (url) parameters need to be extracted as configurable variables, and subsequent mode switching between monolithic architecture and distributed architecture can be completed by filling in the corresponding values in the configuration file. Among them, in the distributed architecture mode, the values of group and version need to be configured, and url is empty.

[0031] In the monolithic architecture mode, the url variable value needs to be configured as the local loopback address (such as 127.0.0.1:2880), and group and version are set to empty.

[0032] Example: In all subsequent modules, the @DubboReference annotation used to call other modules needs to extract the above three values into variables. When the order module calls the inventory module, the example code is as follows: @DubboReference(group=“${stock.group}”,version=”${stock.version}”,url=”${stock.url}”) private IStockApi stockApi; Distributed deployment scenario: The server startup submodule (such as module-a-server, module-b-server) of each function module is independently run. Each module registers the services it provides to the service registration and discovery center (Nacos is used in the embodiment of the present application) through its api interface submodule. The system relies on the service registration and discovery center for service registration and discovery. When a function module is deployed with multiple instance nodes, the service invoker locates the service provider in the service registration and discovery center through the configured group and version parameters, and the Dubbo framework implements load balancing of service calls.

[0033] Monolithic version deployment scenario: The scenario is suitable for a small user traffic. The build tool (Maven is used in the embodiment of the application) is used to aggregate and reference core business submodules (such as module-a-core and module-b-core) of different functional modules, and package them into a unified deployment package. The Dubbo service consumption URL address of the configuration file for calling other modules is set to 127.0.0.1:2880 (or other specified ports). All functional modules are deployed in the same Java virtual machine (JVM) process, and the Dubbo remote procedure call framework optimizes them into internal method calls of the JVM, thereby realizing monolithic architecture deployment.

[0034] Service provider: The scenario is suitable for a small user traffic. The build tool (Maven is used in the embodiment of the application) is used to aggregate and reference core business submodules (such as module-a-core and module-b-core) of different functional modules, and package them into a unified deployment package. The Dubbo service consumption URL address of the configuration file for calling other modules is set to 127.0.0.1:2880 (or other specified ports). All functional modules are deployed in the same Java virtual machine (JVM) process, and the Dubbo remote procedure call framework optimizes them into internal method calls of the JVM, thereby realizing monolithic architecture deployment.

[0035] (1) Detailed introduction of configuration parameters in different deployment modes Lightweight architecture distributed deployment mode: This mode needs to deploy Nacos as a service registration and discovery center. Each business functional module registers the service interface exposed to the outside on the Nacos. The calls between different modules are specified by the group and version variable values on the @DubboReference annotation to specify the target service, thereby completing the interaction between modules.

[0036] Example: The following configuration is performed in the configuration file of each functional module: stock.url=null; stock.group=prod_stock_group; stock.version=1.0.0; Lightweight architecture monolithic mode deployment: without relying on nacos (distributed registry center), modify the project object model file Pom.xml through the build tool (such as Maven) to remove pom dependencies, and package the core business submodules of each functional module into an aggregate module. Through the configuration file, set the url parameter value in the @DubboReference annotation of the call to other business modules to 127.0.0.1:2880 (or other specified ports), and set the group and version parameters to null, Example configuration: dubbo.registry.protocol=dubbo; dubbo.address.protocol=N / A # dubbo does not use the registry center; dubbo.stock.url=dubbo: / / localhost:2880; stock.group=null; stock.version=null; Through the above configuration, all functional modules can be deployed to the same Web container, and cross-module Dubbo calls will be converted into internal method calls in JVM, thereby completing the interaction between modules under the monolithic architecture.

[0037] In the coding process, if a business process operation involves modification of business data of multiple functional modules, a distributed transaction processing component (Seata is used in the embodiment of the application) is used to ensure the data consistency of the business operation. The component is deployed and configured in the system in advance. Whether in monolithic or distributed deployment mode, as long as there is cross-module transaction, it needs to rely on the component.

[0038] Embodiment 2 This embodiment takes a trade system as an example and divides two core modules based on business boundaries: I. System module division: Order service module (Order Module) order-api: used to define and encapsulate the service interface provided by the order module to the outside.

[0039] order-core: used to implement all core business logic of the order module.

[0040] order-server: as the application startup entry of the order module.

[0041] Inventory service module (Stock Module) stock-api: Used to define and encapsulate the service interfaces provided by the inventory module.

[0042] stock-core: Used to implement all the core business logic of the inventory module.

[0043] stock-server: Serves as the application startup entry point for the inventory module.

[0044] Modules communicate with each other via Dubbo, and API calls are injected using the @DubboReference annotation.

[0045] II. Inter-module communication mechanism: In the business logic of the order-core submodule of the order service module, OrderService contains the following code, which is used to call the inventory module interface to deduct inventory after a user successfully creates an order: @DubboReference(group="${stock.group}", version="${stock.version}",url="${stock.url}") private IStockApi stockApi; Public void createOrder(){ / / After the order is created, start deducting inventory. StockApi.deductStock() }; After a user successfully creates an order, the code begins to call the inventory module's API to perform inventory deduction operations.

[0046] III. Switching deployment modes by modifying configuration files: (1) When the system is determined to be deployed in a distributed manner: This mode requires Nacos to be installed and deployed as a service registry and discovery center. Assuming four servers with the following specifications (2 CPU cores, 8GB RAM, 1TB hard drive) and deployment plan:

[0047] The order module configuration file is as follows: stock.group: prod_stock_group; stock.version: 1.0.0; stock.url: null; dubbo.registry.address: nacos: / / localhost:8848; The inventory module configuration file is as follows: dubbo.registry.address: nacos: / / localhost:8848; dubbo.registry.protocol=nacos; dubbo.registry.address=localhost:8848; dubbo.scan.base-packages=com.jxcc; dubbo.protocol.name=dubbo; dubbo.protocol.port=-1; dubbo.provider.group=prod_stock_group; dubbo.provider.version=1.0.0; After deployment, when a user requests and reaches the order module, after order creation, the order configuration tock.group=prod_stock_group and stock.version=1.0.0 are used to initiate a remote call through the @DubboReference annotation. The Dubbo framework queries the Nacos service registration and discovery center, locates the corresponding inventory service instance according to the specified group and version, completes the remote process call, and further completes the business logic processing.

[0048] When multiple instances of the inventory service are deployed, multiple instances providing the same service (same group and version) exist on Nacos. The Dubbo framework uses a round robin (Round Robin) load balancing strategy by default to select an instance for calling to achieve load balancing in the service calling process.

[0049] (2) When it is determined to be a monolithic deployment mode: Suppose there are three servers, their information (2-core CPU, 8GB memory, 1TB hard disk) and deployment plan are as follows:

[0050] 1. Modify the order-server (as an aggregation module) of the order module Project Object Model (POM) configuration file, add a dependency on the stock-core submodule of the inventory module, and package the core business submodules of the two modules into a unified deployment package through Maven.

[0051] <dependencies> <dependency> <groupid>com.jxcc.demo< / groupid> <artifactid>order-core< / artifactid> <version>1.0.0-SNAPSHOT< / version> <type>jar< / type> < / dependency> <dependency> <groupid>com.jxcc.demo< / groupid> <artifactid>stock-core< / artifactid> <version>1.0.0-SNAPSHOT< / version> <type>jar< / type> < / dependency> < / dependencies> 2. Package the order module and the inventory module into a jar and run it, as follows (at this time, Nacos does not need to be deployed).

[0052] stock.group: null; stock.version: null; stock.url: dubbo: / / 127.0.0.1:2880; dubbo.registry.address: N / A; When the order module calls the inventory module, it communicates through the specified IP address (127.0.0.1) and port (2880). Since the service provider and consumer are located in the same JVM process, Dubbo framework will optimize this call to a local call, thus realizing inter-module calls under monolithic architecture.

[0053] Detailed explanation of Dubbo local call conversion principle: I. Basic mechanism of Dubbo call: 1. Normal distributed call flow: Order module (consumer) → Dubbo proxy → network transmission → Dubbo proxy → inventory module (provider); Call link: order module → query Nacos to get provider address → network RPC call → inventory module.

[0054] 2. Call conversion when deployed in a monolithic: Order module (consumer) → Dubbo local call optimization → direct local call → inventory module (provider); Call link: order module → Dubbo framework detects that the provider is in the same JVM → direct method call within JVM → inventory module; JVM internal optimization mechanism: When the service provider and consumer are located in the same JVM process, and the url points to the local loopback address (127.0.0.1) and the same port, Dubbo framework will recognize this situation and optimize the call flow.

[0055] II. Dubbo internal logic: if (service provider is in the current JVM) { Directly call local object methods; / / Skip network serialization } else { Follow the remote network call process; / / Normal RPC call.

[0056] Please refer to Figure 2 This embodiment also provides a modular system dynamic deployment system based on a lightweight architecture, wherein the system applies the modular system dynamic deployment method based on a lightweight architecture as described above, and the system includes: Module partitioning unit, used to: configure the system into multiple independent functional modules according to business boundaries; The interface definition unit is used to define a standardized communication interface for each functional module. The configuration management unit is used to: set a unified configuration file to define the system's target deployment mode; The deployment adaptation unit is used to: dynamically configure parameter groups according to the target deployment mode specified in the configuration file; The communication execution unit is used to dynamically adapt the communication mechanism between functional modules according to the configuration parameter group during system startup or runtime, thereby completing the dynamic deployment switching of the system between monolithic and distributed architectures.

[0057] It should be understood that although the steps in the flowcharts of the various embodiments of the present invention are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the various embodiments may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0058] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0059] In the description of the present specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" and the like means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0060] The above-described embodiments only express several implementation manners of the present application, which are described in a more specific and detailed manner, but cannot be understood as a limitation on the patent scope of the present application. It should be noted that, for those of ordinary skill in the art, several modifications and improvements can be made without departing from the concept of the present application, which are all within the protection scope of the present application. Therefore, the protection scope of the patent of the present application should be subject to the appended claims.

Claims

1. A dynamic deployment method of a modular system based on a lightweight architecture, characterized in that, The method comprises the following steps: Step 1, configure the system into multiple independent functional modules according to business boundaries; Step 2, set a unified configuration file for defining the target deployment mode of the system; and dynamically configure parameter groups according to the target deployment mode specified in the configuration file; Step 3, define a standardized communication interface for each functional module, and perform service calling between functional modules through dependency injection based on the configuration parameter groups; Step 4, dynamically adapt the communication mechanism between functional modules at system startup or runtime according to the configuration parameter groups, thereby completing the dynamic deployment switching of the system between monolithic architecture and distributed architecture.

2. The dynamic deployment method of a modular system based on a lightweight architecture according to claim 1, characterized in that, In the step 1, each independent functional module comprises an api interface submodule, a core business submodule and a server startup submodule; wherein the api interface submodule is used to define and encapsulate the service interface provided by the functional module to the outside; the core business submodule is used to implement all core business logic of the functional module; and the server startup submodule is used as the startup entry of the application.

3. The dynamic deployment method of a modular system based on a lightweight architecture according to claim 2, characterized in that, In the step 2, the target deployment mode comprises a monolithic architecture mode or a distributed architecture mode; the configuration file configures parameter groups for each service calling interface, and the parameter groups at least comprise service group parameters, version parameters and uniform resource locator parameters.

4. The dynamic deployment method of a modular system based on a lightweight architecture according to claim 3, characterized in that, In the step 2, dynamically configuring parameter groups according to the target deployment mode specified in the configuration file comprises the following steps: If the target deployment mode is the distributed architecture mode, configure the service group parameters and the version parameters, and set the uniform resource locator parameters to null, so that the service calling is routed through the service registration and discovery center; If the target deployment mode is the monolithic architecture mode, configure the uniform resource locator parameters to point to the local loopback address, and set the service group parameters and the version parameters to null, so that the service calling is directly completed in the local JVM process.

5. The dynamic deployment method of a modular system based on a lightweight architecture according to claim 4, characterized in that, In the distributed architecture mode, the server startup submodule of each functional module runs independently, and registers its own service through the corresponding api interface submodule to the service registration and discovery center, so that the system relies on the service registration and discovery center for service registration and discovery, and the service registration and discovery center is Nacos.

6. The dynamic deployment method of a modular system based on a lightweight architecture according to claim 5, characterized in that, In the monolithic architecture mode, the core business submodules of multiple functional modules are packaged into a unified aggregation module by a build tool and deployed in the same running environment, so that the service calling is optimized to the method calling in the local JVM process due to the uniform resource locator parameters pointing to the local loopback address, and the build tool is Maven.

7. The dynamic deployment method of a modular system based on a lightweight architecture according to claim 6, characterized in that, In the step 3, the dependency injection mode is specifically: in the code of the core business submodule of the service calling party, the reference to the interface in the api interface submodule of the service provider is declared using an annotation.

8. The dynamic deployment method of a modular system based on a lightweight architecture according to claim 7, characterized in that, The annotation is @DubboReference annotation, and the service group, version and uniform resource locator parameters are configured as configurable variables for service addressing in the @DubboReference annotation.

9. The dynamic deployment method of a modular system based on a lightweight architecture according to claim 8, characterized in that, The distributed transaction processing component is used for guaranteeing data consistency in the distributed deployment mode and the monomer deployment mode when there is cross-module business data operation between the functional modules, and the distributed transaction processing component is Seata.

10. A dynamic deployment system for a modular system based on a lightweight architecture, characterized in that, The system applies the dynamic deployment method of the modular system based on the lightweight architecture according to any one of claims 1 to 9, and the system comprises: a module division unit configured to configure the system into a plurality of independent functional modules according to business boundaries; an interface definition unit configured to define a standardized communication interface for each functional module; a configuration management unit configured to set a unified configuration file for defining a target deployment mode of the system; a deployment adaptation unit configured to dynamically configure a parameter group according to the target deployment mode specified in the configuration file; and a communication execution unit configured to realize dynamic adaptation of a communication mechanism between the functional modules according to the configuration parameter group when the system is started or running, so as to complete dynamic deployment switching of the system between the monomer architecture and the distributed architecture.

Images