• 周六. 5 月 25th, 2024

你的项目适合哪种嵌入式软件架构模式

来源:嵌入式系统

 

由于硬件资源的限制,嵌入式软件可能存在驱动和应用的耦合性,但对于大型项目,资源丰富、业务逻辑复杂,且需要后续扩展和维护,必须采用分层、模块化的思维。 想法是建筑模式。 一般分为7种架构模式:

① 分层架构

②多层架构

③管道-过滤器架构

④客户端-服务器架构

⑤模型-视图-控制器架构

⑥事件驱动架构

⑦微服务架构

其中,加粗部分属于我认为适合在嵌入式系统中应用的架构(模式)。 实际开发中,一般会嵌套多种模式,以保证软件隔离和解耦。

1、分层架构模式

最常见的架构模式是分层架构。 大多数分层架构主要由四层组成:表示层、业务层、持久层和数据库层,如下图所示:

嵌入式软件体系_嵌入式系统软件_嵌入式软件体系包括/

1. 背景

复杂系统独立发展并衍生出系统各部分的需求。 因此,系统开发人员需要清晰、一致的关注点分离,以便系统的各个模块可以独立开发和维护。

2. 问题

软件需要以这样的方式进行划分:每个模块都可以独立开发和派生,各个部分之间几乎没有交互,支持可移植性、可修改性和可重用性。

3. 程序

为了实现关注点分离,分层模式将软件划分为单独的单元(称为“层”)。 每一层都是一组模块,提供一组高度内聚的服务。 它的使用必须是单向的。 一层将一组软件视为一个完整的分区,每个分区都暴露一个公共接口。

✪ 第一个概念是每一层都有特定的角色和职责。 例如,表示层负责所有用户界面处理。 分层架构中的这种关注点分离使得构建高效的角色和职责变得简单。

✪第二个概念是分层架构模式是技术分区架构而不是领域分区架构。 它们由组件而不是域组成。

✪最后一个概念是分层架构中的每一层都被标记为封闭或开放。 封闭层意味着请求从一层移动到另一层,并且必须经过其正下方的层才能到达其下方的下一层。 该请求不能跳过任何层。

嵌入式软件体系包括_嵌入式系统软件_嵌入式软件体系/

4. 弱点

分层可能会导致性能下降。 这种模式不适合高性能应用程序,因为通过架构中的多个层来实现业务请求效率不高。 它还增加了系统的前期成本和复杂性。

5. 目的

我们应该将这种方法用于小型和简单的应用程序。

原文是针对互联网软件,嵌入式可以分为业务层、公共组件层、系统适配层、硬件驱动层。 软件分层的思想是一个基本概念。 由于硬件资源的限制,在嵌入式软件中可能并不明显。

2. 多层模式

计划:

嵌入式软件体系_嵌入式系统软件_嵌入式软件体系包括/

许多系统的执行结构被组织成一系列逻辑组件组。 每个分组称为一个层。

1. 背景

在分布式部署中,通常需要将系统的基础设施划分为不同的子集。

2. 问题

我们如何将系统划分为多个计算独立的执行结构:通过某种通信介质连接的软件和硬件组?

3. 弱点

大量的前期成本和复杂性。

4. 目的

用于分布式系统。

由于个人能力限制,不太了解嵌入式软件中的用法和使用范围。

3. 管道过滤器架构

软件架构中反复出现的模式是管道过滤器模式。

嵌入式系统软件_嵌入式软件体系包括_嵌入式软件体系/

1. 背景

许多系统需要将离散数据流从输入转换为输出。 许多类型转换在实践中是重复的,因此将它们创建为独立的可重用部分是理想的。

2. 问题

这些系统需要划分为可重用的松散耦合组件,组件之间具有简单且通用的交互机制。 这样它们就可以灵活地相互组合。 这些常见的松散耦合组件很容易重用。 独立的组件可以并行执行。

3. 计划

该架构中的管道形成过滤器之间的通信通道。 第一个概念是,出于性能原因,每个管道都是无向且点对点的,接受来自一个源的输入并通常直接输出到另一个源。

在此模式下,有以下四个过滤器。

✪ 生产者(来源):流程的起点。

✪ 转换器(映射):转换部分或全部数据。

✪ 测试器(reduce):测试一个或多个条件。

✪ 消费者(Sink):终点。

4. 弱点

由于其切换性质,不太适合交互式系统。

过多的解析和反解析可能会导致性能损失,还会增加编写过滤器本身的复杂性。

5. 目的

管道过滤器架构可用于多种应用,特别是简化单个项目的处理的任务。

看起来和广播接收的方式类似。 可以在没有操作系统消息队列机制且基于单片机裸机开发时使用。 所有分时任务共享一个广播队列。 接收时,选择您感兴趣的内容进行处理,或者广播消息。 删除会截断后续操作。

4. 客户端过滤器架构

嵌入式软件体系_嵌入式软件体系包括_嵌入式系统软件/

1. 背景

有许多共享资源和服务,大量分布式客户端希望访问并希望控制访问或服务质量。

2. 问题

通过管理一组共享资源和服务,我们可以通过分解公共服务并在单个位置或少量位置进行修改来提高可修改性和可重用性。 我们希望通过集中控制资源和服务,同时将资源本身分布在多个物理服务器上来提高可扩展性和可用性。

3. 计划

在客户端-服务器模式下,组件和连接器具有特定的行为。

称为“客户端”的组件向称为“服务器”的组件发送请求并等待回复。

服务器组件接收客户端的请求并向其发送回复。

4. 弱点

服务器可能成为性能瓶颈和单点故障。 构建系统后,有关应将功能放置在何处(在客户端或服务器上)的决策通常很复杂且更改成本高昂。

5. 目的

对于具有许多组件(客户端)向提供服务的其他组件(服务器)发送请求的系统,我们可以使用客户端-服务器模式对系统的一部分进行建模:在线应用程序,例如电子邮件、共享文档或银行服务。

这个好像只适合互联网软件。

5. 模型-视图-控制器架构(MVC)

嵌入式软件体系包括_嵌入式系统软件_嵌入式软件体系/

1. 背景

用户界面通常是交互式应用程序中修改最频繁的部分。 用户经常希望从不同的角度查看数据,例如条形图或饼图。 这些表示应该反映数据的当前状态。

2. 问题

用户界面功能如何独立于应用程序功能,同时仍然响应用户输入或底层应用程序数据的更改?

当底层应用程序数据发生变化时,如何创建、维护和协调用户界面的多个视图?

3. 计划

模型-视图-控制器 (MVC) 模式将应用程序功能划分为三种类型的组件:

✪ 模型,包含应用程序数据。

✪View,显示部分底层数据并与用户交互。

✪在模型和视图之间进行协调并管理状态更改通知的控制器。

4. 弱点

对于简单的用户界面来说,复杂性是不值得的。

模型、视图和控制器抽象可能不适用于某些用户界面工具包。

5. 目的

MVC 是一种常用于开发网站或移动应用程序用户界面的架构模式。

该模式一般用于支持显示的场景。 底层数据的维护和管理与界面展示是分离的。 这样,当业务需求和展示部分的变化对底层影响不大时,就显得是软件分层模型的一种特例了。

6. 事件驱动架构

1. 背景

需要提供计算和信息资源来处理传入的应用程序生成的独立异步事件,其方式可以随着需求的增加而扩展。

2. 问题

构建一个分布式系统,可以提供异步到达的事件相关信息,并可以从简单到大型再到复杂。

3. 计划

嵌入式软件体系_嵌入式软件体系包括_嵌入式系统软件/

部署单独的事件进程或处理程序来进行事件处理。 到达的事件已排队。 调度程序从队列中提取事件,并根据调度策略将它们分配给适当的事件处理程序。

4. 弱点

性能和错误恢复可能是问题。

5. 目的

使用此解决方案的电子商务应用程序将按如下方式工作:

订单服务创建一个处于挂起状态的订单,然后发布 OrderCreated 事件。

✪ 客户服务收到此事件并尝试扣除此订单的积分。 然后发布 Credit Reserve 事件或 CreditLimitExceeded(超出信用限额)事件。

✪ 订单服务接收客户服务发送的事件,并将订单状态更改为已批准或已取消。

这在嵌入式软件中很容易理解。 所谓事件就是硬件检测到中断信息。 嵌入式软件基本体现了这个思想,一段while死循环,等待事件触发,比如外部按键中断、串口接收中断、或者内部定时器超时中断等。这种框架有利于外设扩展,理论上不会互相干扰其他。

7. 微服务架构

1. 背景

部署支持各种浏览器和本机移动客户端的基于服务器的企业应用程序。 应用程序通过执行业务逻辑、访问数据库、与其他系统交换信息以及返回响应来处理客户端请求。 此应用程序可能会公开第三方 API。

2. 问题

单体应用程序可能变得太大、太复杂,无法有效支持和部署以优化分布式资源的利用,例如在云环境中。

3. 计划

嵌入式系统软件_嵌入式软件体系包括_嵌入式软件体系/

将应用程序构建为服务套件。 每个服务都可以独立部署和扩展,并具有自己的 API 边界。 不同的服务可以用不同的编程语言编写,管理自己的数据库,并由不同的团队开发。

4. 弱点

系统设计必须能够容忍服务故障,并需要更多的系统监控。 服务编排和事件协作成本高昂。

5. 目的

微服务架构可以应用于许多用例,尤其是涉及大数据管道的用例。 例如,微服务系统对于公司零售店销售的报告系统来说是理想的选择。 数据呈现过程的每个步骤都由微服务处理:数据收集、清理、标准化、集中、聚合、报告等。

在嵌入式软件开发中,比较适合相对独立的功能。 适配其基本接口后,将复杂的功能模块化,外部输入参数在模块内部执行,完成后输出结果或触发回调。 接口简单,外部不需要过多关注内部实现,有利于软件解耦和维护。 (从嵌入式系统转移)