During the evolution from monolithic architecture to service-oriented architecture (SOA), some intermediate products and architectural patterns have emerged to help organizations gradually decompose applications and achieve better modularity and scalability.
1. Chimney structure
Chimney Architecture (Silos Architecture) is an intermediate product that usually occurs during the transition from monolithic architecture to service-oriented architecture (SOA).
It refers to the splitting of different functions or modules of a monolithic application into independent "chimneys", each of which focuses on a specific business domain or functional area.
Each chimney can be an independent module or subsystem, which internally contains its own business logic, data storage and user interface.
Advantage
- Modularity: Chimneyed architecture enables better modularity by decomposing a monolithic application into modules. Different modules can be developed, tested and deployed independently.
- Team autonomy: Each chimney is typically owned by an independent team, enabling teams to develop, maintain, and deploy their functional areas autonomously.
- Reusability: Some common functional modules can be reused in different chimneys, improving code reusability.
- Scalability: Since each chimney is independent, it can be expanded for modules that need to be expanded to achieve better scalability.
- Technology Diversity: Different chimneys can use different technology stacks to suit their specific needs.
disadvantage
- Coupling: There may be some degree of coupling between different chimneys, especially in terms of sharing data or communication.
- Data Consistency: Data consistency across chimneys can be complicated by considerations of data synchronization and cross-chimney transactions.
- Deployment complexity: As the number of chimneys increases, deployment and version management can become more complex.
- System Integration: If not properly designed and managed, different chimneys can be difficult to integrate, leading to disconnects between systems.
Summarize
Chimney Architecture (Silos Architecture) is an intermediate product that usually occurs during the transition from monolithic architecture to service-oriented architecture (SOA).
It refers to the splitting of different functions or modules of a monolithic application into independent "chimneys", each of which focuses on a specific business domain or functional area.
Each chimney can be an independent module or subsystem, which internally contains its own business logic, data storage and user interface.
But
the chimney architecture is usually still a monolithic application. Although it may be divided into different functional modules internally, they are still a whole and need to be deployed as a whole.
2. Microkernel architecture (plug-in architecture)
Microkernel Architecture (Microkernel Architecture) is a software architectural pattern, which aims to separate the core functions of an application from additional functions, so as to achieve better modularization and scalability.
The core idea of the microkernel architecture is to use the core business logic as a microkernel, and integrate other functions into the system in the form of plug-ins .
Advantage
- Modularity: The microkernel architecture achieves better modularity by separating core business logic from other functional modules. Each module can be developed, tested and deployed independently.
- Customizability: Additional functional modules are considered plug-ins that can be added, removed or replaced as required, allowing for a greater degree of customizability.
- Extensibility: New functional modules can be added to the system relatively easily without affecting the core business logic. This makes the system more scalable.
- Technology diversity: Different functional modules can use different technology stacks to suit their specific needs.
- Reduced coupling: The coupling between the core business logic and other functional modules is low, which helps reduce the complexity of the system.
disadvantage
- Plug-in interface design: The design of the plug-in interface needs to take flexibility and compatibility into consideration, so that different plug-ins can be seamlessly integrated into the system.
- Data sharing: Plugins may need to share data, so data sharing and data consistency issues need to be handled carefully.
- System management and deployment: Managing and deploying systems with multiple plugins can be more complex and requires certain management strategies and tools.
- Performance impact: The plugin architecture may introduce some additional performance overhead, especially in terms of communication between plugins.
Summarize
A microkernel architecture can help achieve better modularity and customizability in some cases, especially if the system requires frequent additions, modifications, or differences between several different functional areas.
However, choosing to adopt a microkernel architecture also needs to take into account the specific needs of the system, the technical capabilities of the team, and maintainability.
Microkernel architecture is usually still a monolithic application, but the core business logic is separated from other functional modules.
3. Event-driven architecture
Event-driven architecture is a software architecture pattern whose core idea is to communicate and collaborate different components or services of the system through events, so as to achieve loosely coupled, highly scalable and flexible system design.
In the event-driven architecture, each component in the system can respond to and trigger events independently of each other, so as to realize the collaborative work of system functions.
Main Components and Roles
- Event: Indicates a state change or action within the system, which can be user operation, external trigger, data update, etc.
- Publisher: Responsible for generating events and publishing them to the event bus or message queue, usually a component or service in the system.
- Subscriber (Subscriber): Subscribers register interest in specific events, and when events occur, subscribers will receive notifications and perform corresponding operations.
- Event Bus (Event Bus): An intermediary mechanism for passing events between different components, which can be an object in memory or a message queue.
Advantage
- Loose coupling: The event-driven architecture communicates through events, and the coupling between components is reduced. This makes the system more flexible, allowing individual components to be developed, deployed and maintained independently.
- Scalability: Since each component is independent of each other, it is relatively easy to add new components, thereby realizing the scalability of the system. New components can handle new event types as needed.
- Flexibility: Event-driven architecture allows components to be modified or replaced without affecting other components. This flexibility makes the system easier to maintain and evolve.
- Autonomy: Each component can respond to and process events independently, thus achieving a high degree of autonomy. Each component can make decisions on its own without direct interaction with other components.
- Real-time: An event-driven architecture usually involves publishing and subscribing to asynchronous events, enabling real-time responses. This is very beneficial for scenarios where events need to be processed quickly.
- Business decoupling: Different business logic can be decoupled by abstracting into events, which makes the system easier to maintain and understand. Components can be more focused on their domain.
disadvantage
- Complexity: Designing and managing an event-driven architecture can be complex, especially when multiple event types and interactions between multiple components are involved.
- Error handling: Event-driven architecture can lead to the propagation of errors, a wrong event may affect multiple components. Therefore, an effective error handling mechanism is required.
- Maintainability: When dealing with multiple event types and multiple components, higher testing, debugging, and maintenance costs may be required, especially when the system is large in size.
- Data consistency: Multiple components processing events may lead to data consistency problems, which require reasonable design and handling.
- Asynchronous communication: Although asynchronous communication helps to achieve real-time performance, it may also increase system complexity, and related issues of asynchronous communication, such as sequentiality and concurrency, need to be considered.
Applicable scene
- Complex systems: Applicable to large and complex systems, functions can be decomposed into independent components, coordinated and communicated through events.
- Real-time requirements: Applicable to scenarios that require real-time response and event processing, such as financial transactions, Internet of Things, etc.
- High scalability: Suitable for scenarios that require frequent expansion and modification of system functions, because the event-driven architecture can well support the addition and replacement of components.
Summarize
The event-driven architecture has great advantages in building large-scale, flexible, and scalable applications, but it also needs to design and manage the delivery, processing, and subscription of events reasonably.
Event-driven architecture focuses on communication and collaboration between components, and can involve components of different granularities, including entire applications, modules, services, etc.