Functional module decoupling implementation method and system
Through SpringBootApplicationEvent and interface definition methods, the decoupling and plugging of functional modules are realized, solving the problems of middleware switching and auxiliary function blocking between different projects, and improving the adaptability and performance of the system.
Patent Information
- Application Number
- CN202411245608.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-06
- Publication Date
- 2024-12-24
AI Technical Summary
When using different middleware between different projects in the system, the code needs to be modified, which leads to difficulty and inconvenience in code maintenance. Auxiliary functions such as logging and message sending may block the main business process and affect system performance and availability.
Decoupling of functional modules is achieved through SpringBootApplicationEvent and interface definition, and non-main process services are processed asynchronously, allowing different projects to quickly switch middleware implementations. The main business process only needs to call the interface and does not need to care about specific implementations, so that the module and the main business process are separated from the main business process.
Improves the adaptability and availability of the system, reduces the impact of auxiliary processes on the main business process, enhances system performance and availability, and reduces maintenance costs.
Smart Images
Figure CN119179592A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of software architecture, and in particular to a method and system for realizing decoupling of functional modules. Background Art
[0002] With the development of Internet technology and the full blossoming of technological innovation, the realization of system functions can be satisfied by various types of components, such as message middleware RocketMq, kafka; logging tools rsyslog, Logback, kafka; when the same system is deployed and used in different projects, the corresponding middleware will be selected based on the actual situation of the project. The traditional coding method has the following problems:
[0003] (1) The system needs to modify the code in different projects to adapt to the middleware used by each project. Different implementation codes are different in multiple project groups, making the code difficult to maintain. Pulling branches will also cause inconvenience in code submission and merging. Multiple types of middleware increase the Cartesian product of code branches, increasing maintenance costs.
[0004] (2) Failure of system auxiliary functions such as logging and message sending will block the main business process. System recording and analysis functions such as logging and message sending should minimize the impact on the main business process. Summary of the invention
[0005] The technical task of the present invention is to address the above shortcomings and provide a method and system for implementing decoupling of functional modules, which can realize asynchronous processing of non-main process business functions and pluggability of functional components of the same type. When different projects choose different implementation technologies, fast switching can be achieved without modifying the code.
[0006] The technical solution adopted by the present invention to solve its technical problem is:
[0007] A method for implementing the decoupling of functional modules, which allows the same system to quickly adapt different middleware to different projects, and calls the functions of different middleware to exist in the form of separate modules;
[0008] Decouple non-main process businesses (such as logging) through SpringBootApplicationEvent; ensure that subsequent non-main process failures do not block the main process business;
[0009] Decouple the different component implementations of the main process business (such as the message sending component) through interface definition; the main business process function call is only oriented to the interface, and there is no need to care about the specific implementation of the functional module; when different projects choose different implementation technologies, there is no need to modify the code to achieve quick switching through the interface.
[0010] This method implements the decoupling and plug-in of functional modules based on SpringBootApplicationEvent and interface definition, and can quickly switch the middleware docking by switching the introduced modules. The functional implementation module is separated and independent from the main business process. It increases the adaptability and availability of the system, enhances the availability of the system and also improves the performance of the system.
[0011] Furthermore, SpringBootApplicationEvent decouples non-main processes, and the implementation is as follows:
[0012] 1) Create a custom event:
[0013] Create a custom event class that inherits from ApplicationEvent. In this class, declare the business data needed for subsequent business processes as the source of business data for subsequent processes.
[0014] 2) Create an event listener:
[0015] Create a listener class that implements the ApplicationListene interface and overrides the onApplicationEvent method. The listener class needs to be implemented in different implementation modules, so that the business system only needs to focus on implementing its own business logic and calling the corresponding interface declaration. Who implements the specific declaration depends on the specific implementation module introduced during packaging.
[0016] 3) Publish events:
[0017] The business system publishes events through ApplicationEventPublisher. The business implementation class implements the ApplicationEventPublisherAware interface. EventPublisher publishes Event events through the publishEvent method. The corresponding monitoring implementation module introduced in the project performs subsequent operations after monitoring the events.
[0018] Taking logging as an example, define the log event Event, which contains the log attribute fields to be recorded. The business implementation module inherits the ApplicationEventPublisherAware interface. The main business module assembles logs where they need to be recorded and sends events through the publishEvent method of eventPublisher. New modules are named after the corresponding implementation, such as rsyslog and logback. In these modules, corresponding events are listened to and log recording is completed. Subsequent logging functions are implemented by listening to SpringApplicationEvent. When the project is packaged and deployed, the specific implementation package introduced is determined to determine the specific implementation method of the function. The processing flow after message listening can be synchronous or asynchronous, reducing the impact of non-main processes on the main business process.
[0019] Furthermore, when creating a custom event, BeforeEvent and AfterEvent events are created according to specific business requirements to meet the triggering operations at different times.
[0020] Furthermore, the interface definition declares the interface in the main business process and defines the input and return parameter formats, and then creates an independent implementation module to implement the methods defined in these interfaces.
[0021] When a function has multiple common implementation methods or needs to be connected to different middleware, in order to decouple these functions, it can be implemented through predefined interfaces.
[0022] Furthermore, when the project needs to use RocketMq and kafka to send messages respectively, define the IMsgSender interface in the main business module and declare the send method, and create RocketMq and kafka modules to inherit the main business module to implement the send method respectively; the main business module does not need to care about the specific business implementation when calling, and can directly call the send method through IMsgSender; the specific implementation is determined by the module introduced when packaging and deploying the project.
[0023] Furthermore, the auxiliary business process is configured to be executed asynchronously to minimize the impact on the main business process.
[0024] Furthermore, the introduction of auxiliary business processes is achieved through event monitoring, and multiple implementations can be introduced at the same time, and multiple implementations can be effective and used at the same time.
[0025] The present invention also claims a functional module decoupling implementation system, comprising:
[0026] The non-main process business decoupling module is used to realize asynchronous processing of non-main process business functions. When the main process business is completed, the corresponding Event event is sent, carrying the data required for the subsequent process. The corresponding event monitoring is triggered, and the asynchronous annotation @Async() is added to the corresponding monitoring implementation layer to realize independent thread execution of subsequent processes;
[0027] The interface definition module is used to realize the pluggability of the same type of functional components; in the main process business implementation, the corresponding functions of the middleware are extracted into interfaces, and the implementation of these interfaces is separated into independent modules. These modules inherit the business module and connect to various middleware to implement the interface functions. Taking the message queue sending as an example, when the business system needs to send a message, the main business process only needs to call the send method defined in its own module. Whether it is sent by RocketMQ or Kafka depends on the module that implements the send method introduced during packaging; when switching to implement the middleware, you only need to introduce the required implementation module in the running project;
[0028] The system specifically implements business processing through the above-mentioned functional module decoupling implementation method.
[0029] The present invention also claims a functional module decoupling implementation device, comprising: at least one memory and at least one processor;
[0030] The at least one memory is used to store a machine-readable program;
[0031] The at least one processor is used to call the machine-readable program to implement the above method.
[0032] The present invention also claims protection for a computer-readable medium having computer instructions stored thereon, which implement the above method when executed by a processor.
[0033] Compared with the prior art, the functional module decoupling implementation method and system of the present invention have the following beneficial effects:
[0034] 1. Functional interface, decoupling of function implementation module from main business module: Functional interface realizes the decoupling of main business process and subsequent auxiliary function implementation. Subsequent functions can be introduced into implementation modules as needed to achieve the purpose of fast switching of middleware. The adaptability and availability of the system are increased.
[0035] 2. Auxiliary processes can be asynchronous to reduce the impact of auxiliary process errors on the main business process. For example, auxiliary processes such as logging sometimes fail without blocking the main business process. The event monitoring method can be configured as asynchronous, and auxiliary process errors do not affect the normal use of the system, which enhances the system's availability while also improving the system's performance. BRIEF DESCRIPTION OF THE DRAWINGS
[0036] Figure 1 It is a flowchart of a method for implementing functional module decoupling provided in an embodiment of the present invention. DETAILED DESCRIPTION
[0037] The present invention will be further described below in conjunction with specific embodiments.
[0038] The embodiment of the present invention provides a method for implementing decoupling of functional modules, which provides a system solution for switching implementation of functional modules in different projects of the same system, and realizes docking of different implementation components of the same type in the project by introducing different implementation modules during packaging.
[0039] The same system can quickly adapt to different middleware in different projects, and the functions of calling different middleware are implemented in the form of separate modules, such as: message middleware (RocketMQ, kafka, etc.), logging implementation module (rsyslog, Logback, kafka, etc.).
[0040] Decouple non-main process businesses (such as logging) through SpringBootApplicationEvent; ensure that subsequent non-main process failures do not block the main process business;
[0041] Decouple the different component implementations of the main process business (such as the message sending component) through interface definition; the main business process function call is only oriented to the interface, and there is no need to care about the specific implementation of the functional module; when different projects choose different implementation technologies, there is no need to modify the code to achieve quick switching through the interface.
[0042] This method implements the decoupling and plug-in of functional modules based on SpringBootApplicationEvent and interface definition, and can quickly switch the middleware docking by switching the introduced modules. The functional implementation module is separated and independent from the main business process. It increases the adaptability and availability of the system, enhances the availability of the system and also improves the performance of the system.
[0043] Auxiliary business processes can be configured to be executed asynchronously to minimize the impact on the main business process.
[0044] Auxiliary business process introduction is achieved through event monitoring. Multiple implementations can be introduced at the same time, and multiple implementations can be effective and used at the same time.
[0045] refer to Figure 1 As shown, the specific implementation of this method is as follows:
[0046] 1. SpringBootApplicationEvent decouples non-main processes:
[0047] 1. Create a custom event:
[0048] First, create a custom event class that inherits from ApplicationEvent. In this class, declare the business data needed for subsequent business processes as the source of business data for subsequent processes. When creating an event, create BeforeEvent and AfterEvent events according to specific business requirements to meet different triggering operations.
[0049] 2. Create an event listener:
[0050] Then, create a listener class that implements the ApplicationListene interface and overrides the onApplicationEvent method. The listener class needs to be implemented in different implementation modules, so that the business system only needs to focus on implementing its own business logic and calling the corresponding interface declaration. Who implements the specific declaration depends on the specific implementation module introduced during packaging.
[0051] 3. Release events:
[0052] The business system publishes events through ApplicationEventPublisher. The business implementation class implements the ApplicationEventPublisherAware interface. EventPublisher publishes Event events through the publishEvent method. The corresponding monitoring implementation module introduced in the project performs subsequent operations after monitoring the events.
[0053] Taking logging as an example, define the log event Event, which contains the log attribute fields to be recorded. The business implementation module inherits the ApplicationEventPublisherAware interface. The main business module assembles logs where they need to be recorded and sends events through the publishEvent method of eventPublisher. New modules are named after the corresponding implementation, such as rsyslog and logback. In these modules, corresponding events are listened to and log recording is completed. Subsequent logging functions are implemented by listening to SpringApplicationEvent. When the project is packaged and deployed, the specific implementation package introduced is determined to determine the specific implementation method of the function. The processing flow after message listening can be synchronous or asynchronous, reducing the impact of non-main processes on the main business process.
[0054] 2. Define the interface, and the submodule implements the interface function:
[0055] When a function has multiple common implementation methods or needs to be connected to different middleware, in order to decouple these functions, it can be implemented through predefined interfaces. Declare the interface in the main business process and define the input and return parameter formats, and then create an independent implementation module to implement the methods defined in these interfaces.
[0056] When the project needs to use RocketMq and Kafka to send messages, define the IMsgSender interface in the main business module and declare the send method. Create RocketMq and Kafka modules to inherit the main business module and implement the send method. The main business module does not need to care about the specific business implementation when calling, and can directly call the send method through IMsgSender. The specific implementation is determined by the module introduced when packaging and deploying the project.
[0057] The embodiment of the present invention further provides a functional module decoupling implementation system, including:
[0058] The non-main process business decoupling module is used to realize asynchronous processing of non-main process business functions. When the main process business is completed, the corresponding Event event is sent, carrying the data required for the subsequent process. The corresponding event monitoring is triggered, and the asynchronous annotation @Async() is added to the corresponding monitoring implementation layer to realize independent thread execution of subsequent processes;
[0059] The interface definition module is used to realize the pluggability of the same type of functional components; in the main process business implementation, the corresponding functions of the middleware are extracted into interfaces, and the implementation of these interfaces is separated into independent modules. These modules inherit the business module and connect to various middleware to implement the interface functions. Taking the message queue sending as an example, when the business system needs to send a message, the main business process only needs to call the send method defined in its own module. Whether it is sent by RocketMQ or Kafka depends on the module that implements the send method introduced during packaging; when switching to implement the middleware, you only need to introduce the required implementation module in the running project;
[0060] The system specifically implements business processing through the functional module decoupling implementation method described in the above embodiment:
[0061] 1. SpringBootApplicationEvent decouples non-main processes:
[0062] 1. Create a custom event:
[0063] First, create a custom event class that inherits from ApplicationEvent. In this class, declare the business data needed for subsequent business processes as the source of business data for subsequent processes. When creating an event, create BeforeEvent and AfterEvent events according to specific business requirements to meet different triggering operations.
[0064] 2. Create an event listener:
[0065] Then, create a listener class that implements the ApplicationListene interface and overrides the onApplicationEvent method. The listener class needs to be implemented in different implementation modules, so that the business system only needs to focus on implementing its own business logic and calling the corresponding interface declaration. Who implements the specific declaration depends on the specific implementation module introduced during packaging.
[0066] 3. Release events:
[0067] The business system publishes events through ApplicationEventPublisher. The business implementation class implements the ApplicationEventPublisherAware interface. EventPublisher publishes Event events through the publishEvent method. The corresponding monitoring implementation module introduced in the project performs subsequent operations after monitoring the events.
[0068] Taking logging as an example, define the log event Event, which contains the log attribute fields to be recorded. The business implementation module inherits the ApplicationEventPublisherAware interface. The main business module assembles logs where they need to be recorded and sends events through the publishEvent method of eventPublisher. New modules are named after the corresponding implementation, such as rsyslog and logback. In these modules, corresponding events are listened to and log recording is completed. Subsequent logging functions are implemented by listening to SpringApplicationEvent. When the project is packaged and deployed, the specific implementation package introduced is determined to determine the specific implementation method of the function. The processing flow after message listening can be synchronous or asynchronous, reducing the impact of non-main processes on the main business process.
[0069] 2. Define the interface, and the submodule implements the interface function:
[0070] When a function has multiple common implementation methods or needs to be connected to different middleware, in order to decouple these functions, it can be implemented through predefined interfaces. Declare the interface in the main business process and define the input and return parameter formats, and then create an independent implementation module to implement the methods defined in these interfaces.
[0071] When the project needs to use RocketMq and Kafka to send messages, define the IMsgSender interface in the main business module and declare the send method. Create RocketMq and Kafka modules to inherit the main business module and implement the send method. The main business module does not need to care about the specific business implementation when calling, and can directly call the send method through IMsgSender. The specific implementation is determined by the module introduced when packaging and deploying the project.
[0072] An embodiment of the present invention further provides a functional module decoupling implementation device, comprising: at least one memory and at least one processor;
[0073] The at least one memory is used to store a machine-readable program;
[0074] The at least one processor is used to call the machine-readable program to implement the functional module decoupling implementation method described in the above embodiment.
[0075] The embodiment of the present invention further provides a computer-readable medium, on which computer instructions are stored, and when the computer instructions are executed by a processor, the functional module decoupling implementation method described in the above embodiment is implemented. Specifically, a system or device equipped with a storage medium can be provided, on which a software program code implementing the functions of any of the above embodiments is stored, and a computer (or CPU or MPU) of the system or device reads and executes the program code stored in the storage medium.
[0076] In this case, the program code itself read from the storage medium can realize the function of any one of the above-mentioned embodiments, and thus the program code and the storage medium storing the program code constitute a part of the present invention.
[0077] The storage medium embodiments for providing the program code include a floppy disk, a hard disk, a magneto-optical disk, an optical disk (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), a magnetic tape, a non-volatile memory card, and a ROM. Alternatively, the program code can be downloaded from a server computer by a communication network.
[0078] In addition, it should be clear that the functions of any of the above embodiments can be implemented not only by executing the program code read by the computer, but also by enabling an operating system operating on the computer to complete part or all of the actual operations based on instructions from the program code.
[0079] In addition, it can be understood that the program code read from the storage medium is written to a memory provided in an expansion board inserted into the computer or written to a memory provided in an expansion unit connected to the computer, and then based on the instructions of the program code, a CPU installed on the expansion board or the expansion unit is enabled to perform part or all of the actual operations, thereby realizing the functions of any of the above-mentioned embodiments.
[0080] The present invention is shown and described in detail above through the accompanying drawings and preferred embodiments. However, the present invention is not limited to these disclosed embodiments. Based on the above multiple embodiments, those skilled in the art can know that the code review methods in the above different embodiments can be combined to obtain more embodiments of the present invention, and these embodiments are also within the protection scope of the present invention.
Claims
1. A method for implementing functional module decoupling, characterized in that: The same system can quickly adapt different middleware to different projects, and the functions of calling different middleware can be implemented in the form of separate modules; Decouple non-main process businesses through SpringBootApplicationEvent, so that subsequent non-main process failures do not block the main process business; The different components of the main process business are decoupled through interface definition; the main business process function call is interface-oriented, and different projects can quickly switch through the interface when choosing different implementation technologies.
2. A method for implementing functional module decoupling according to claim 1, characterized in that: SpringBootApplicationEvent decouples non-main processes and is implemented as follows: 1) Create a custom event: Create a custom event class that inherits from ApplicationEvent. In this class, declare the business data needed for subsequent business processes as the source of business data for subsequent processes. 2) Create an event listener: Create a listener class that implements the ApplicationListene interface and overrides the onApplicationEvent method; place the listener class in different implementation modules for implementation; 3) Publish events: The business system publishes events through ApplicationEventPublisher. The business implementation class implements the ApplicationEventPublisherAware interface. EventPublisher publishes Event events through the publishEvent method. The corresponding monitoring implementation module introduced in the project performs subsequent operations after monitoring the events.
3. A method for implementing functional module decoupling according to claim 2, characterized in that: The custom event is created, and BeforeEvent and AfterEvent events are created according to specific business requirements to meet the triggering operations at different times.
4. A method for implementing functional module decoupling according to claim 1 or 2, characterized in that: The interface definition declares the interface in the main business process and defines the input and return parameter formats, and then creates an independent implementation module to implement the methods defined in these interfaces.
5. A method for implementing functional module decoupling according to claim 4, characterized in that: When the project needs to use RocketMq and Kafka to send messages respectively, define the IMsgSender interface in the main business module and declare the send method. Create RocketMq and Kafka modules to inherit the main business module and implement the send method. The main business module does not need to care about the specific business implementation when calling, and can directly call the send method through IMsgSender. The specific implementation is determined by the module introduced when packaging and deploying the project.
6. A method for implementing functional module decoupling according to claim 1, characterized in that: Configure auxiliary business processes to be executed asynchronously.
7. A method for implementing functional module decoupling according to claim 1 or 6, characterized in that: Auxiliary business process introduction is achieved through event monitoring. Multiple implementations can be introduced at the same time, and multiple implementations can be effective and used at the same time.
8. A functional module decoupling implementation system, characterized in that: include: The non-main process business decoupling module is used to realize asynchronous processing of non-main process business functions. When the main process business is completed, the corresponding Event event is sent, carrying the data required for the subsequent process. The corresponding event monitoring is triggered, and the asynchronous annotation @Async() is added to the corresponding monitoring implementation layer to realize independent thread execution of subsequent processes; The interface definition module is used to realize the pluggability of the same type of functional components. In the main process business implementation, the corresponding functions of the middleware are extracted into interfaces, and the implementation of these interfaces is separated into independent modules. These modules inherit the business module and connect to various middleware to realize the interface functions. When switching to implement the middleware, you only need to introduce the required implementation module in the running project. The system specifically implements business processing through the functional module decoupling implementation method described in any one of claims 1 to 7.
9. A functional module decoupling implementation device, characterized in that: include: at least one memory and at least one processor; The at least one memory is used to store a machine-readable program; The at least one processor is configured to call the machine-readable program to implement the method according to any one of claims 1 to 7.
10. A computer-readable medium, characterized in that The computer readable medium stores computer instructions, which, when executed by a processor, implement the method according to any one of claims 1 to 7.