在嵌入式系统开发中，由于硬件资源限制，驱动层与应用层常常存在紧密耦合的情况。然而，对于大型项目，在资源允许的条件下，为了处理复杂的业务逻辑并确保系统的可扩展性和可维护性，采用分层和模块化的架构思维至关重要。
常见的嵌入式软件架构模式主要包括以下几种：
① 分层架构
② 多层架构
③ 管道-过滤器架构
④ 客户端-服务器架构
⑤ 模型-视图-控制器架构
⑥ 事件驱动架构
⑦ 微服务架构
分层架构模式
分层架构是最常见的架构模式之一，通常由展现层、业务层、持久层和数据库层四部分组成，具体结构如下图所示：
上下文
复杂系统往往需要各个部分独立发展和演化。因此，开发者必须实现关注点的清晰分离，以便各模块能够独立开发与维护。
核心问题
软件需要被分割成多个模块，每个模块可以独立开发和演进，模块间交互尽可能少，以支持可移植性、可修改性和复用性。
解决方案
分层模式通过将软件划分为不同的层来实现关注点分离。每一层都是一组高内聚的模块，提供特定的服务，并且层之间的调用必须是单向的。
- 角色与职责：每一层都有明确的角色，例如展现层负责用户界面处理。这种分离使得构建高效的职责分配变得简单。
- 技术分区：分层架构是一种技术性分区，而非领域性分区，由组件而非业务领域构成。
- 封闭与开放层：在封闭层中，请求必须逐层传递，不能跳过任何中间层。
潜在弱点
分层可能导致性能下降，不适合高性能应用，因为业务请求需要经过多层处理。此外，它会增加系统前期成本和复杂性。
适用场景
适用于小型或简单的应用程序。
多层架构模式
许多系统的执行结构被组织成一系列逻辑组件分组，每个分组称为一个层。
上下文
在分布式部署中，通常需要将系统基础设施分配到不同的子集中。
核心问题
如何将系统分割成多个计算上独立的执行结构，这些结构由通信媒介连接的软件和硬件组组成？
潜在弱点
前期成本和复杂性较高。
适用场景
主要用于分布式系统。
管道-过滤器架构
管道-过滤器模式在软件架构中反复出现，适用于数据流转换场景。
上下文
许多系统需要处理从输入到输出的离散数据流，常见转换类型适合创建为独立可复用组件。
核心问题
系统需要被分割成松耦合的可复用组件，组件间交互简单通用，以支持灵活组合和并行执行。
解决方案
管道构成过滤器之间的通信通道，通常是非定向和点对点的。过滤器类型包括：
- 生产者：数据流的起点。
- 转换器：对数据进行转换。
- 测试器：测试条件。
- 消费者：数据流的终点。
潜在弱点
不适合交互性系统，过多的解析和反解析会导致性能损失，并增加过滤器编写的复杂性。
适用场景
适用于简化单项处理任务的各种应用程序。
客户端-服务器架构
上下文
大量分布式客户端需要访问共享资源和服务，同时要求控制访问质量。
核心问题
通过集中管理共享服务，提高可修改性和复用性，同时通过分布式资源部署提升可伸缩性和可用性。
解决方案
客户端组件向服务器组件发送请求并等待回复，服务器接收请求后返回响应。
潜在弱点
服务器可能成为性能瓶颈和单点故障点，功能位置的决策复杂且变动成本高。
适用场景
适用于在线应用程序，如电子邮件、共享文档或银行服务。
模型-视图-控制器架构（MVC）
上下文
用户界面是交互应用程序中最常修改的部分，用户需要从不同视角查看数据，且视图应实时反映数据状态。
核心问题
如何使用户界面功能独立于应用程序功能，同时响应用户输入或底层数据更改？如何协调多个视图以反映数据变化？
解决方案
MVC模式将应用程序功能分为三种组件：
- 模型：包含应用程序数据。
- 视图：显示部分数据并与用户交互。
- 控制器：在模型和视图之间中介，管理状态更改通知。
潜在弱点
对于简单用户界面，复杂性不值得；某些工具包可能不适用这些抽象。
适用场景
广泛用于网站或移动应用程序的用户界面开发。
事件驱动架构
上下文
需要处理异步到达的事件，并支持从简单到复杂的扩展。
核心问题
如何构建分布式系统，以服务异步事件并实现可扩展性？
解决方案
部署独立的事件处理器，事件进入队列后由调度程序根据策略分配到合适处理器。
潜在弱点
可能存在性能和错误恢复问题。
适用场景
例如在电商应用中：订单服务创建订单并发布事件，客户服务处理信用检查并发布响应事件。
微服务架构
上下文
企业应用程序需要支持多种客户端，处理业务逻辑、数据库访问和系统交互。
核心问题
一体化应用程序过于庞大复杂，难以在分布式环境（如云平台）中有效支持和部署。
解决方案
将应用程序构建为独立部署和扩展的服务套件，每个服务拥有自己的API边界，可能使用不同编程语言和数据库，由不同团队开发。
潜在弱点
系统需容忍服务失败，监控要求高，服务编排和事件协作开销大。
适用场景
适用于大量数据管道场景，可在云原生环境中高效部署。
发表于 2025-11-28 01:57:56
|
查看: 44|
回复: 0
