Modular system dynamic deployment method and system based on lightweight architecture

Abstract

The application provides a modular system dynamic deployment method and system based on a lightweight architecture, which comprises the following steps: configuring a system into multiple independent functional modules according to a business boundary; setting a unified configuration file for defining a target deployment mode of the system; dynamically configuring parameter groups according to the target deployment mode specified in the configuration file; defining a standardized communication interface for each functional module, and performing service calling between the functional modules through a dependency injection mode based on the configuration parameter groups; and dynamically adapting a communication mechanism between the functional modules at the system startup or running according to the configuration parameter groups, so as to complete the dynamic deployment switching between a monolithic architecture and a distributed architecture. The application can flexibly switch between the monolithic architecture and the distributed architecture according to actual use requirements, and can complete the conversion of the deployment form by modifying the configuration only, without modifying the source code, so that 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, 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:

[0003] Traditional monolithic architecture: structure composition: all function 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.

[0004] 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

[0005] 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.

[0006] The present application provides a modular system dynamic deployment method based on light architecture, which comprises the following steps:

[0007] Step 1, according to the business boundary, the system is configured as multiple independent function modules;

[0008] 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;

[0009] Step 3, define a standardized communication interface for each function module, and based on the configuration parameter group, perform service calls between function modules through dependency injection;

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

[0011] 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:

[0012] a module division unit, configured to divide the system into a plurality of independent functional modules according to service boundaries;

[0013] an interface definition unit, configured to define a standardized communication interface for each functional module;

[0014] a configuration management unit, configured to set a unified configuration file for defining a target deployment mode of the system;

[0015] a deployment adaptation unit, configured to dynamically configure a parameter group according to the target deployment mode specified in the configuration file;

[0016] a communication execution unit, configured to realize dynamic adaptation of a communication mechanism between functional modules according to the parameter group when the system is started or running, so as to complete dynamic deployment switching of the system between monolithic architecture and distributed architecture.

[0017] Compared with the prior art, the present application has the following advantages:

[0018] 1、The present application defines the module composition and its deployment mode through a unified configuration file, so that the system can be flexibly switched between monolithic architecture and 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 DevOps complexity in different stages, and avoiding the trouble of maintaining multiple code branches to adapt to different architectures. Moreover, 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 cost 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.

[0019] 2、The application requires strict adherence to the separation of concerns principle inside each functional module, divided into api, core, server three standardized sub-modules, and communicates based on dependency injection (such as @DubboReference) and standardized interface. Through mandatory module division, the system structure is clear, and the code readability and maintainability are enhanced. Developers can focus on the development of specific business modules, improving parallel development efficiency. Business logic is decoupled from communication protocol and deployment method. Developers do not need to care about whether the future service is local call or remote call when writing business code, reducing the complexity of coding and reducing the possibility of error. And from development, testing to production, the same set of code can be used, only through configuration to distinguish the deployment mode, effectively avoiding deployment and running problems caused by environment differences, ensuring the consistency of development and operation.

[0020] 3、In the monolithic architecture mode, by pointing the url to the local loopback address, the local call optimization function of the RPC framework such as Dubbo is used. The network serialization / deserialization, transmission and other overheads required for remote call are saved, the remote procedure call is optimized to local method call, the call delay is significantly reduced, the system performance is improved, and the purpose of lightweight deployment is achieved.

[0021] 4、The application integrates a distributed transaction processing component, and ensures consistency in any deployment mode as long as there is cross-module business data operation. In the distributed mode, the distributed transaction is guaranteed by Seata. In the monolithic mode, although the call is completed in the JVM, the cross-module data source transaction can still be managed by Seata, providing a unified and reliable transaction solution, avoiding the complexity of introducing two different transaction mechanisms in the two modes, and enhancing the reliability and data accuracy of the system.

[0022] 5、The application provides a smooth technical evolution path for the technical architecture of an enterprise. When performing micro-service transformation on a legacy monolithic system, the system can be modularized and split according to the mode of the application first. Initially, the system is run in monolithic mode to verify the correctness of the business logic, and after stabilization, it is gradually switched to distributed deployment by modifying the configuration, greatly reducing the risk of reconstruction. If performance or stability problems are encountered in the distributed deployment mode, the configuration can be quickly modified to switch back to the monolithic mode, ensuring the availability of the system and gaining time to troubleshoot problems. This is an efficient fault tolerance and recovery mechanism.

[0023] Additional aspects and advantages of the application will be partially given in the following description, partially will become obvious from the following description, or will be understood by embodiments of the application. BRIEF DESCRIPTION OF DRAWINGS

[0024] Figure 1 A flow chart of a dynamic deployment method of a modular system based on a lightweight architecture according to the present application is shown in FIG. 1.

[0025] Figure 2 A structural schematic diagram of a dynamic deployment system of a modular system based on a lightweight architecture according to the present application is shown in FIG. 2. DETAILED DESCRIPTION

[0026] Embodiments of the present application are described in detail below with reference to the attached drawing figures, wherein the same or like designations indicate the same or like elements or elements having the same or similar function throughout the attached drawing figures. The embodiments described below are merely exemplary for the purpose of explanation and are not to be understood as limiting the present application.

[0027] These and other aspects of embodiments of the present application will be more apparent from the following description and accompanying drawings, wherein:

[0028] Referring to the following description and drawings, these and other aspects of embodiments of the present application will become apparent. Figure 1 The present embodiment provides a dynamic deployment method of a modular system based on a lightweight architecture, which comprises the following steps:

[0029] Step 1, configuring the system into a plurality of independent functional modules according to the business boundary, each independent functional module comprising 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, does not contain any business logic implementation, and is relied on by other functional modules to make service calls; the core business submodule is used to implement all core business logic of the functional module, relies 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, relies on the core business submodule to obtain all business functions, and does not contain any business logic itself, and its responsibility is to provide the deployment and initialization capability of the entire functional module at runtime;

[0030] Step 2, setting a unified configuration file for defining the target deployment mode of the system; and dynamically configuring parameter groups according to the target deployment mode specified in the configuration file;

[0031] The target deployment mode includes a monolithic architecture mode or a distributed architecture mode; the configuration file configures a parameter group for each service calling interface, and the parameter group at least includes a service group (group) parameter, a version (version) parameter and a uniform resource locator (url) parameter.

[0032] As a preferred embodiment of the application, according to the target deployment mode specified in the configuration file, the dynamic configuration parameter group specifically includes the following steps:

[0033] If the target deployment mode is the 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 set to null, so that the service calling 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, and the system relies on the service registration and discovery center for service registration and discovery, and the service registration and discovery center is Nacos.

[0034] If the target deployment mode is the monolithic architecture mode, the uniform resource locator (url) parameter of all independent functional modules is directed to the local loopback address, and the service group (group) parameter and the version (version) parameter are set to null, so that the service calling is directly completed in the local JVM process. In the monolithic architecture mode, the core business submodule of multiple functional modules is packaged into a unified aggregation module by a build tool and deployed, so that the service calling is directed to the local loopback address by the uniform resource locator parameter, and is optimized to a method call in the local JVM process by the remote procedure call framework. The build tool is Maven.

[0035] Step 3, defining a standardized communication interface for each functional module, and based on the configuration parameter group, performing service calling between functional modules through a dependency injection mode;

[0036] As a preferred embodiment of the application, the dependency injection mode specifically includes: declaring a reference to the service provider in the code of the service calling party by using an annotation. The annotation is a @DubboReference annotation, and the service group (group), version (version) and uniform resource locator (url) parameters are configured as configurable variables for service addressing in the @DubboReference annotation.

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

[0038] As a preferred embodiment of the application, a distributed transaction processing component is further included for ensuring data consistency in a distributed deployment mode and a single deployment mode when there is a cross-module business data operation between the functional modules, and the distributed transaction processing component is Seata.

[0039] 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.

[0040] Embodiment 1

[0041] To more clearly illustrate the technical concept and principle of the application, two independent functional modules, functional module A and functional module B, are taken as examples below:

[0042] Functional module A mainly consists of three modules, namely module-a-server, module-a-core, and module-a-api, and the functions of each module are introduced as follows:

[0043] module-a-api (i.e., the api interface submodule of functional module A): used for defining and encapsulating the service interface provided by module A to the outside, for calling by other functional modules.

[0044] module-a-core (i.e., the core business submodule of functional module A): used for implementing all core business logic of module A; this submodule depends on module-a-api and is responsible for implementing the interfaces defined therein.

[0045] module-a-server (i.e., the server startup submodule of functional 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.

[0046] Functional module B mainly consists of three modules, namely module-b-server, module-b-core, and module-b-api, and the functions of each module are introduced as follows:

[0047] module-b-api (i.e., the api interface submodule of functional module B): used for defining and encapsulating the service interface provided by module B to the outside, for calling by other functional modules.

[0048] module-b-core (i.e. the core business submodule of functional module B): used to implement all core business logic of module B; this submodule depends on module-b-api and is responsible for implementing the interfaces defined therein.

[0049] module-b-server (i.e. the server startup submodule of functional 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.

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

[0051] Service calling party: the specific code is implemented in the Service layer of the core business submodule (e.g. module-a-core) of the calling party functional module. The service dependency injection is completed by referencing the interfaces defined in the api interface submodule of the service providing party functional module and using the @DubboReference annotation. When using the @DubboReference annotation, the service group (group), version, and uniform resource locator (url) parameters need to be extracted as configurable variables, and the subsequent mode switching between monolithic architecture and distributed architecture can be completed by filling in the corresponding values in the configuration file.

[0052] Among them, in the distributed architecture mode, the values of group and version need to be configured, and url is empty.

[0053] 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.

[0054] 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:

[0055] @DubboReference(group=“${stock.group}”,version=”${stock.version}”,url=”${stock.url}”)

[0056] private IStockApi stockApi;

[0057] In a distributed deployment scenario:

[0058] The server starting sub-module of each functional module (such as module-a-server, module-b-server) is independently run. Each module registers the service provided by itself to a service registration and discovery center (Nacos is used in the embodiment of the present application) through the api interface sub-module thereof. The system relies on the service registration and discovery center for service registration and discovery. When multiple instance nodes of a functional module are deployed, the service invoker locates the service provider in the service registration and discovery center through the configured group and version parameters, and the load balancing of service invocation is realized by the Dubbo framework.

[0059] In a monomer version deployment scenario:

[0060] This scenario is suitable for a case where user traffic is small. The core business sub-modules (such as module-a-core, module-b-core) of different functional modules are aggregated and referenced by a build tool (Maven is used in the embodiment of the present application), and are packaged into a unified deployment package. The Dubbo service consumption URL address for calling other modules is set to 127.0.0.1:2880 (or other specified ports) through a configuration file. All functional modules are deployed in the same Java virtual machine (JVM) process, and the Dubbo remote procedure call framework will optimize it into a method call within the JVM, thereby realizing monomer architecture deployment.

[0061] Service provider: This scenario is suitable for a case where user traffic is small. The core business sub-modules (such as module-a-core, module-b-core) of different functional modules are aggregated and referenced by a build tool (Maven is used in the embodiment of the present application), and are packaged into a unified deployment package. The Dubbo service consumption URL address for calling other modules is set to 127.0.0.1:2880 (or other specified ports) through a configuration file. All functional modules are deployed in the same Java virtual machine (JVM) process, and the Dubbo remote procedure call framework will optimize it into a method call within the JVM, thereby realizing monomer architecture deployment.

[0062] (1) Detailed introduction of configuration parameters in different deployment modes:

[0063] Lightweight architecture distributed deployment mode: This mode needs to deploy Nacos as a service registration and discovery center. Each business function module registers its exposed service interface to Nacos. The call between different modules specifies the target service by configuring the group and version variable values on the @DubboReference annotation, thereby completing the interaction between modules.

[0064] Example: Configure as follows in the configuration file of each function module:

[0065] stock.url=null;

[0066] stock.group=prod_stock_group;

[0067] stock.version=1.0.0;

[0068] Lightweight architecture monolithic mode deployment: No need to rely 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 sub-module of each function module as an aggregate module. Through the configuration file, set the url parameter value in the @DubboReference annotation that calls other business modules to 127.0.0.1:2880 (or other specified ports), and set the group and version parameters to null,

[0069] Example configuration:

[0070] dubbo.registry.protocol=dubbo;

[0071] dubbo.address.protocol=N / A # dubbo does not use the registry center;

[0072] dubbo.stock.url=dubbo: / / localhost:2880;

[0073] stock.group=null;

[0074] stock.version=null;

[0075] Through the above configuration, all function modules can be deployed to the same Web container, and cross-module Dubbo calls will be converted into JVM internal method calls, thereby completing the interaction between modules under the monolithic architecture.

[0076] In the encoding 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 present application) is used to ensure data consistency of the business operation. The group event is deployed and configured in the system in advance. Whether in monolithic or distributed deployment mode, as long as there is a cross-module transaction, it needs to rely on the component.

[0077] Embodiment 2

[0078] This embodiment takes a trade system as an example, which is divided into two core modules based on business boundaries:

[0079] I. System module division:

[0080] Order service module (Order Module)

[0081] order-api: used to define and encapsulate the service interface provided by the order module to the outside.

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

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

[0084] Inventory service module (Stock Module)

[0085] stock-api: used to define and encapsulate the service interface provided by the inventory module to the outside.

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

[0087] stock-server: as the application startup entry of the inventory module.

[0088] Modules communicate with each other through Dubbo, and interface calls are injected through @DubboReference annotation.

[0089] II. Communication mechanism between modules:

[0090] In the business code of the order-core submodule of the order service module, OrderService contains the following code for calling the inventory module interface to deduct inventory after the user successfully creates an order:

[0091] @DubboReference(group="${stock.group}", version="${stock.version}",url="${stock.url}")

[0092] private IStockApi stockApi;

[0093] Public void createOrder(){

[0094] / / After the order is created, start deducting inventory.

[0095] StockApi.deductStock()

[0096] };

[0097] After a user successfully creates an order, the code begins to call the inventory module's API to perform inventory deduction operations.

[0098] III. Switching deployment modes by modifying configuration files:

[0099] (1) When the system is determined to be deployed in a distributed manner:

[0100] 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:

[0101]

[0102] The order module configuration file is as follows:

[0103] stock.group: prod_stock_group;

[0104] stock.version: 1.0.0;

[0105] stock.url: null;

[0106] dubbo.registry.address: nacos: / / localhost:8848;

[0107] The inventory module configuration file is as follows:

[0108] dubbo.registry.address: nacos: / / localhost:8848;

[0109] dubbo.registry.protocol=nacos;

[0110] dubbo.registry.address=localhost:8848;

[0111] dubbo.scan.base-packages=com.jxcc;

[0112] dubbo.protocol.name=dubbo;

[0113] dubbo.protocol.port=-1;

[0114] dubbo.provider.group=prod_stock_group;

[0115] dubbo.provider.version=1.0.0;

[0116] After deployment, when a user requests the order module, the order creation is completed, and the tock.group=prod_stock_group and stock.version=1.0.0 dependencies configured by the order 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.

[0117] When multiple instances of the inventory service are deployed, multiple instances that provide the same service (the same group and version) exist on Nacos. The Dubbo framework uses a load balancing strategy such as Round Robin to select one instance for calling to achieve load balancing in the service calling process.

[0118] (2) When it is determined to be a monolithic deployment mode:

[0119] Suppose there are three servers, and their information (2-core CPU, 8-GB memory, 1-TB hard disk) and deployment plan are as follows:

[0120]

[0121] 1. Modify the project object model (POM) configuration file of the order module order-server (as an aggregation module) to add a dependency on the stock-core submodule of the inventory module. Pack the core business submodules of the two modules into a unified deployment package through Maven.

[0122] <dependencies>

[0123] <dependency>

[0124] <groupid>com.jxcc.demo< / groupid>

[0125] <artifactid>order-core< / artifactid>

[0126] <version>1.0.0-SNAPSHOT< / version>

[0127] <type>jar< / type>

[0128] < / dependency>

[0129] <dependency>

[0130] <groupid>com.jxcc.demo< / groupid>

[0131] <artifactid>stock-core< / artifactid>

[0132] <version>1.0.0-SNAPSHOT< / version>

[0133] <type>jar< / type>

[0134] < / dependency>

[0135] < / dependencies>

[0136] 2. Pack the order module and the inventory module into a jar and run it. The configuration file is as follows (Nacos does not need to be deployed at this time).

[0137] stock.group: null;

[0138] stock.version: null;

[0139] stock.url: dubbo: / / 127.0.0.1:2880;

[0140] dubbo.registry.address: N / A;

[0141] 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 optimizes this call to a local call, thus realizing inter-module calls in monolithic architecture.

[0142] Detailed explanation of Dubbo local call conversion principle:

[0143] I. Basic mechanism of Dubbo call:

[0144] 1. Normal distributed call process:

[0145] Order module (consumer) → Dubbo agent → network transmission → Dubbo agent → inventory module (provider);

[0146] Call link: order module → query Nacos to get provider address → network RPC call → inventory module.

[0147] 2. Call conversion when deployed in monolithic:

[0148] Order module (consumer) → Dubbo local call optimization → direct local call → inventory module (provider);

[0149] Call link: order module → Dubbo framework detects that the provider is in the same JVM → direct method call within JVM → inventory module.

[0150] 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 process.

[0151] II. Dubbo internal logic:

[0152] if (service provider is in the current JVM) {

[0153] Directly call the local object method; / / Skip network serialization

[0154] } else {

[0155] GoRemoteProcedureCallFlow; / / Normal RPC call.

[0156] Referring to Figure 2 The embodiment further provides a modular system dynamic deployment system based on a lightweight architecture, wherein the system applies the modular system dynamic deployment method based on the lightweight architecture, and the system comprises:

[0157] a module division unit configured to divide a system into a plurality of independent functional modules according to a business boundary;

[0158] an interface definition unit configured to define a standardized communication interface for each functional module;

[0159] a configuration management unit configured to set a unified configuration file for defining a target deployment mode of the system;

[0160] a deployment adaptation unit configured to dynamically configure a parameter group according to the target deployment mode specified in the configuration file;

[0161] a communication execution unit configured to realize dynamic adaptation of a communication mechanism between functional modules according to the configuration parameter group when the system is started or run, so as to complete dynamic deployment switching of the system between a monolithic architecture and a distributed architecture.

[0162] It should be understood that although each step in the flowchart of each embodiment of the present application is displayed in sequence according to the arrow, these steps are not necessarily executed in sequence according to the arrow. Unless otherwise specified herein, the execution of these steps is not strictly limited in sequence, and these steps can be executed in other sequences. Moreover, at least part of the steps in each embodiment can include multiple sub-steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution sequence of these sub-steps or stages is not necessarily sequential, but can be executed in rotation or alternation with at least part of other steps or sub-steps or stages of other steps.

[0163] It should be appreciated that parts of the present application can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, several steps or methods can be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented in hardware, and as in another embodiment, any of the following technologies, or a combination thereof, can be used: discrete logic circuitry having logic gates for implementing logic functions upon an application of data signals, application specific integrated circuits having appropriate combinational logic gates, programmable gate arrays (PGA), field programmable gate arrays (FPGA), and the like.

[0164] 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. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0165] 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 skilled 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 patent protection scope 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 a plurality of independent functional modules according to the business boundary; 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 for defining and encapsulating the service interface provided by the functional module to the outside; the core business submodule is used for implementing the whole core business logic of the functional module; and the server startup submodule is used as the starting entry of the application; Step 2, set a unified configuration file for defining the target deployment mode of the system; and dynamically configure the parameter group according to the target deployment mode specified in the configuration file; the target deployment mode comprises a monolithic architecture mode or a distributed architecture mode; the configuration file configures the parameter group for each service calling interface, and the parameter group at least comprises a service group parameter, a version parameter and a uniform resource locator parameter; If the target deployment mode is the distributed architecture mode, the service group parameter and the version parameter are configured, and the uniform resource locator parameter is set as 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, the uniform resource locator parameter is configured to point to the local loopback address, and the service group parameter and the version parameter are set as null, so that the service calling is directly completed in the local JVM process; In the distributed architecture mode, the server startup submodule of each functional module independently runs, and registers the self-service to the service registration and discovery center through the corresponding api interface submodule, so that the system depends on the service registration and discovery center for service registration and discovery, and the service registration and discovery center is Nacos; In the monolithic architecture mode, the core business submodules of the plurality of functional modules are packaged into a unified aggregation module by a construction tool and deployed in the same running environment, so that the service calling is pointed to the local loopback address by the uniform resource locator parameter, when the service provider and the consumer are located in the same JVM process, and the url is pointed to the local loopback address and the same port, the remote process calling framework is optimized to the method calling in the local JVM process, and the construction tool is Maven; Step 3, define the standardized communication interface for each functional module, and perform service calling between the functional modules by the dependency injection mode based on the configuration parameter group; Step 4, dynamically adapt the communication mechanism between the functional modules according to the configuration parameter group when the system is started or running, so as to complete the dynamic deployment switching of the system between the monolithic architecture and the 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 3, the dependency injection mode is specifically that 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 by using an annotation.

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

4. The dynamic deployment method of a modular system based on a lightweight architecture according to claim 3, 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.

5. 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 4, 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