Embedded software may experience coupling between drivers and applications due to hardware resource limitations. However, for large projects with abundant resources, complex business logic, and the need for future expansion and maintenance, a layered and modular approach must be adopted. This thinking is known as architectural patterns.
Common architectural patterns in the market include the following:
1. Layered Architecture
2. Multi-layer Architecture
3. Pipe-Filter Architecture
4. Client-Server Architecture
5. Model-View-Controller Architecture
6. Event-Driven Architecture
7. Microservices Architecture
The bolded parts are what I personally consider suitable architectural patterns for embedded systems. In actual development, various patterns are generally nested to ensure software isolation and decoupling.
1. **Layered Architecture**
The most common architectural pattern is the layered architecture, which mainly consists of four layers: presentation layer, business layer, persistence layer, and database layer, as shown in the following diagram:
1. Context
Complex systems will go through independent development and the evolution of various parts. For this reason, system developers need to clearly and logically separate concerns so that each module of the system can be developed and maintained independently.
2. Problem
Software needs to be divided in such a way that each module can be developed and evolved independently, with very little interaction between parts, supporting portability, modifiability, and reusability.
3. Solution
To achieve separation of concerns, the layered pattern divides the software into various units (called "layers"). Each layer is a set of modules that provide a set of highly cohesive services. Its usage must be one-way. A set of software is treated as a complete partition, with each partition exposing a public interface.
✪ The first concept is that each layer has specific roles and responsibilities. For example, the presentation layer is responsible for handling all user interfaces. This separation of concerns in layered architecture makes it very simple to construct efficient roles and responsibilities.
✪ The second concept is that the layered architecture pattern is a technical partitioning architecture, rather than a domain partitioning architecture. They are composed of components, not domains.
✪ The last concept is that each layer in a layered architecture is marked as closed or open. A closed layer means that requests moving from one layer to another must go through the layer directly below it to reach the next lower layer. Requests cannot skip any layers.
4. Weakness
Layering can lead to performance degradation. This pattern is not suitable for high-performance applications, as the efficiency of processing a business request through multiple layers in the architecture is not high. It also increases the initial cost and complexity of the system.
5. Usage
We should apply this method to small, simple applications.
Review
The original text is aimed at internet software, but for embedded systems, it can be divided into business layer, public component layer, system adaptation layer, and hardware driver layer. The software layering concept is a fundamental idea. Perhaps it is not very obvious in embedded software due to hardware resource limitations.
2. **Multi-layer Pattern**
Many systems' execution structures are organized into a series of logically grouped components, each group referred to as a layer.
1. Context
In a distributed deployment, it is often necessary to divide the system's infrastructure into different subsets.
2. Problem
How do we split the system into multiple independently executed structures: groups of software and hardware connected by some communication medium?
3. Weakness
High initial costs and complexity.
4. Usage
Used in distributed systems.
Review
Due to personal capability limitations, I do not yet understand the usage and scope of application in embedded software.
3. **Pipe-Filter Architecture**
A recurring pattern in software architecture is the pipe-filter pattern.
1. Context
Many systems need to transform discrete data flows from input to output. Many types of transformations occur repeatedly in practice, so it is ideal to create them as independent reusable parts.
2. Problem
These systems need to be divided into reusable loosely coupled components, with simple common interaction mechanisms between components. This allows them to flexibly combine with each other. These common loosely coupled components are easy to reuse. Independent components can be executed in parallel.
3. Solution
In this architecture, pipes form the communication channels between filters. The first concept is that, for performance reasons, each pipe is undirected and point-to-point, accepting input from one source and often directly outputting to another source.
In this pattern, there are four types of filters:
✪ Producer (source): the starting point of a process.
✪ Transformer (map): transforms some or all data.
✪ Tester (reduce): tests one or more conditions.
✪ Consumer (sink): the endpoint.
4. Weakness
Not very suitable for interactive systems due to their transformation nature.
Excessive parsing and un-parsing can lead to performance loss and increase the complexity of writing the filters themselves.
5. Usage
Pipe-filter architecture is used in various applications, especially to simplify tasks of single-direction processing.
Review
It looks quite similar to the broadcast and receive model, which can be used in bare-metal development without an operating system message queue mechanism. All time-sharing tasks share a broadcast queue, and during reception, they choose to process what they are interested in, or delete the broadcast message to truncate subsequent operations.
4. **Client-Filter Architecture**
1. Context
Many shared resources and services are distributed, and a large number of clients wish to access them, hoping to control access or service quality.
2. Problem
By managing a set of shared resources and services, we can improve modifiability and reusability by decomposing common services and modifying them in a single or a few locations. We want to improve scalability and availability by concentrating control of these resources and services while distributing the resources themselves across multiple physical servers.
3. Solution
In the client-server model, components and connectors have specific behaviors. The component called “client” sends requests to the component called “server” and then waits for a reply. The server component receives the client’s request and sends a reply back to it.
4. Weakness
The server can become a performance bottleneck and a single point of failure. After the system is built, decisions about the functional location (whether on the client or server) are often complex and have high variable costs.
5. Usage
For systems where many components (clients) send requests to other components (servers) providing services, we can use the client-server model to model part of this system: online applications such as email, shared documents, or banking services.
Review
This seems to only be suitable for internet software.
5. **Model-View-Controller Architecture (MVC)**
1. Context
The user interface is often the part of an interactive application that is modified most frequently. Users often want to view data from different perspectives, such as bar graphs or pie charts. These representations should reflect the current state of the data.
2. Problem
How can user interface functionality be independent of application functionality while still responding to user input or changes in underlying application data?
When changes occur in the underlying application data, how can multiple views of the user interface be created, maintained, and coordinated?
3. Solution
The Model-View-Controller (MVC) pattern divides application functionality into the following three types of components:
✪ Model, which contains the application data.
✪ View, which displays part of the underlying data and interacts with the user.
✪ Controller, which mediates between the model and the view and manages notifications of state changes.
4. Weakness
For simple user interfaces, the complexity may not be worth it.
The abstractions of model, view, and controller may not apply to certain user interface toolkits.
5. Usage
MVC is a commonly used architectural pattern for developing user interfaces in websites or mobile applications.
Review
This pattern is generally used in scenarios that support display, separating the maintenance management of underlying data from the interface display. This way, when business requirements or display parts change, the impact on the underlying infrastructure is minimal, making it seem like a special case of the software layering pattern.
6. **Event-Driven Architecture**
1. Context
It is necessary to provide computing and information resources to handle incoming independent asynchronous events generated by applications, which can scale with increasing demand.
2. Problem
Building distributed systems that can serve asynchronously arriving event-related information and can scale from simple small systems to complex large systems.
3. Solution
Deploy independent event processes or processors for event handling. Incoming events enter a queue. The scheduler pulls events from the queue based on scheduling policies and assigns them to appropriate event processors.
4. Weakness
Performance and error recovery can be problematic.
5. Usage
An e-commerce application using this solution will work as follows:
The Order Service creates an Order, which is in a pending state, and then publishes an OrderCreated event.
✪ The Customer Service receives this event and tries to deduct credit for this Order, then publishes a Credit Reserved event or a CreditLimitExceeded event.
✪ The Order Service receives the event sent by the Customer Service and changes the order status to approved or canceled.
Review
This is easily understood in embedded software, where an event is the hardware detecting interrupt information. Embedded software generally embodies this idea, such as a while loop waiting for an event trigger, like external button interrupts, serial port reception interrupts, or internal timer timeout interrupts. This framework is beneficial for peripheral expansion, theoretically allowing them to operate independently of each other.
7. **Microservices Architecture**
1. Context
Deploy server-based enterprise applications that support various browsers and native mobile clients. The application processes client requests by executing business logic, accessing databases, exchanging information with other systems, and returning responses. This application may expose a third-party API.
2. Problem
Integrated applications can become too large and complex to be effectively supported and deployed for optimal distributed resource utilization, such as in cloud environments.
3. Solution
Build the application into a suite of services. Each service is independently deployable and scalable, with its own API boundary. Different services can be written in different programming languages, manage their own databases, and be developed by different teams.
4. Weakness
System design must tolerate service failures and require more system monitoring. Service orchestration and event collaboration overhead can be significant.
5. Usage
Many scenarios can apply microservices architecture, especially those involving large data pipelines. For example, a microservice system for reporting sales from a retail store would be ideal. Each step in the data presentation process would be handled by a microservice: data collection, cleaning, normalization, condensation, aggregation, reporting, etc.
Review
In embedded software development, this is suitable for a relatively independent function. After adapting its basic interface, a complex functional module can be modularized, with external input parameters, internal execution, and outputs or callbacks, making the interface simple and allowing external parties to focus less on internal implementations, facilitating software decoupling and maintenance.
(Transferred from Embedded Systems)
Disclaimer: This article's material comes from the internet, and the copyright belongs to the original author. If there are any copyright issues, please contact me for deletion.
