软件架构设计总结

一、Linux 平台的软件架构设计方案

方案 A：分层架构（最常用）

┌─────────────────────────────────┐│        应用层 (App Layer)        │  ← 业务逻辑├─────────────────────────────────┤│       中间件层 (Middleware)       │  ← 协议栈、算法库、数据库├─────────────────────────────────┤│     系统服务层 (System Service)   │  ← systemd/dbus/udev├─────────────────────────────────┤│       内核层 (Linux Kernel)       │  ← 驱动、文件系统、网络栈├─────────────────────────────────┤│          硬件层 (Hardware)        │└─────────────────────────────────┘

特点：进程隔离、多线程、虚拟内存、丰富的开源生态

方案 B：微服务/多进程架构

功能模块拆分为独立进程，通过 IPC 通信（D-Bus、Unix Socket、共享内存、MQTT Broker）

优势：模块解耦、崩溃隔离、独立升级
典型场景：智能座舱、工业网关、边缘计算

方案 C：容器化架构

使用 Docker/LXC 隔离不同功能模块
适合复杂嵌入式系统（如自动驾驶域控制器）

二、RTOS 平台的软件架构设计方案

方案 A：经典分层架构

┌───────────────────────────────┐│       应用任务 (Tasks)         │  ← 业务逻辑任务├───────────────────────────────┤│     中间件 (Middleware)        │  ← 文件系统、网络协议栈├───────────────────────────────┤│     RTOS 内核 (Kernel)         │  ← 调度、IPC、内存管理├───────────────────────────────┤│    HAL / BSP (硬件抽象/板级支持) │  ← 驱动抽象层├───────────────────────────────┤│        硬件 (Hardware)         │└───────────────────────────────┘

方案 B：事件驱动架构

所有业务逻辑基于事件/消息队列驱动
任务之间通过队列、信号量、事件组解耦
优势：确定性高、适合实时控制场景

方案 C：Super Loop + 中断（极简方案）

适用于资源极度受限的 MCU（如 Cortex-M0、8位MCU）
主循环轮询 + 中断处理关键事件
无 RTOS 开销，但扩展性差

方案 D：混合架构

RTOS 处理实时任务 + 轻量级脚本引擎（如 MicroPython、Lua）
兼顾实时性和灵活性

三、LinuxVSRTOS 架构设计核心差异

维度	Linux 平台	RTOS 平台
进程模型	多进程，MMU 隔离	单进程，多任务，无 MMU 隔离
内存管理	虚拟内存、动态分配灵活	静态分配为主、需严格控制
驱动模型	标准驱动框架（字符/块/网络设备）	自定义 HAL/BSP 抽象
IPC 机制	Socket、Pipe、D-Bus、共享内存	队列、信号量、事件组、消息邮箱
调试手段	GDB、coredump、strace	JTAG/SWD、逻辑分析仪、Trace
OTA 策略	A/B 分区、双备份	通常单分区 + Bootloader
安全机制	SELinux/AppArmor、user namespace	MPU（内存保护单元）、TrustZone

四、设计一个软件架构，需要考虑的因素

1. 需求分析维度

实时性要求：硬实时还是软实时？中断响应延迟要求？
功能复杂度：是单一功能设备还是多功能融合设备？
资源约束：Flash/RAM 大小、CPU 主频、功耗预算
产品生命周期：是否需要长期维护和功能迭代？

2. 技术选型维度

OS 选型：Linux（Buildroot/Yocto）还是 RTOS（FreeRTOS/RT-Thread/Zephyr）？
通信协议：内部 IPC 机制选型、外部通信协议栈
文件系统：是否需要持久化存储？ext4 vs LittleFS vs SPIFFS
升级方案：OTA 策略（全量/差分/A/B分区）

3. 质量属性维度（非功能性需求）

可靠性：看门狗策略、异常恢复、coredump/故障日志
可测试性：模块化程度、HIL/SIL 测试支持、Mock 能力
可维护性：日志分级、远程诊断、配置管理
安全性：安全启动链、固件签名、通信加密、密钥管理
可扩展性：新功能的接入成本、接口设计的前瞻性

4. 工程实践维度

团队能力：团队对哪个平台更熟悉？
开发效率：编译-烧录-调试的迭代速度
第三方依赖：开源协议合规性（GPL/LGPL 等）
成本控制：BOM 成本、认证成本、维护成本

以上，作为一个嵌入式系统开发工程师来说，绝对是一个基础概念。那如果作为一个嵌入式应用软件开发工程师，我们在设计应用软件架构时，又应该考虑哪些因素呢？

五、上层应用软件架构的核心理念

“上层应用架构的核心是用分层和分模块来管理复杂度，让代码可读、可测、可维护、可扩展。”

六、主流架构模式

1. 分层架构

┌──────────────────────────┐│     表现层 (UI/API)       │  ← View / Controller├──────────────────────────┤│     业务逻辑层 (Service)   │  ← 核心业务规则├──────────────────────────┤│     数据访问层 (DAO)       │  ← 数据库/网络/文件操作├──────────────────────────┤│     基础设施层 (Infra)     │  ← 日志、配置、缓存、消息队列└──────────────────────────┘

适用场景：大多数业务系统、管理后台、API 服务

核心原则：

上层依赖下层，下层不感知上层

每层只做自己职责范围内的事

跨层调用通过接口解耦

2. 六边形架构 / 端口适配器模式（Hexagonal Architecture）

         ┌──────────────────────┐         │                      │   HTTP ◄─┤    ┌──────────┐    ├─► 数据库         │    │  核心业务  │    │   MQTT ◄─┼────┤  领域模型  ├────┼─► 缓存         │    │          │    │   gRPC ◄─┤    └──────────┘    ├─► 文件系统         │                      │         └──────────────────────┘         端口(Port)     适配器(Adapter)

核心思想：业务核心与外部依赖完全解耦，通过”端口”定义接口，”适配器”连接外部。

优势：换数据库、换通信协议，核心代码零改动。

3. 整洁架构（Clean Architecture）

┌─────────────────────────────────┐│      框架层 (Frameworks)         │  ← 具体框架、UI库│  ┌───────────────────────────┐  ││  │   接口适配层 (Adapters)     │  │  ← Controller/Presenter│  │  ┌─────────────────────┐  │  ││  │  │   用例层 (Use Cases)  │  │  │  ← 应用层业务逻辑│  │  │  ┌───────────────┐  │  │  ││  │  │  │ 领域层 (Domain)│  │  │  │  ← 核心实体、业务规则│  │  │  └───────────────┘  │  │  ││  │  └─────────────────────┘  │  ││  └───────────────────────────┘  │└─────────────────────────────────┘

依赖方向：外圈 → 内圈，内圈不依赖外圈

4. 微服务架构（Microservices）

┌──────────┐   ┌──────────┐   ┌──────────┐│ 用户服务  │   │ 订单服务  │   │ 支付服务  ││ (独立部署) │◄──┤ (独立部署) │◄──┤ (独立部署) │└──────────┘   └──────────┘   └──────────┘      │              │              │      └──────────────┼──────────────┘                     │              ┌──────┴──────┐              │   消息队列    │  ← 异步解耦              └─────────────┘

适用场景：大型系统、多团队协作、需要独立扩缩容

七、应用软件设计架构时需要考虑的关键因素

第一层：业务维度

业务复杂度：简单 CRUD 还是复杂工作流？
变更频率：哪些模块最常变？隔离变化点
团队规模：多人协作如何避免冲突？

第二层：技术维度

技术栈选型：语言、框架、数据库、中间件
通信方式：同步（REST/gRPC）vs 异步（消息队列/事件）
数据一致性：强一致性 vs 最终一致性（CAP 权衡）

第三层：质量属性

可测试性：能否方便地写单元测试？依赖是否可 Mock？
可扩展性：加一个新功能需要改多少地方？（开闭原则）
性能：瓶颈在哪？是否需要缓存、异步、分库分表？
安全性：认证鉴权、数据加密、防注入攻击

第四层：运维维度

可观测性：日志、监控、链路追踪
部署方式：单体部署、容器化、CI/CD 流水线
灰度发布：能否做到平滑升级和回滚？

总结：

核心设计理念是高内聚、低耦合和依赖倒置。具体来说：

第一，业务逻辑和框架解耦——核心业务代码不依赖任何具体框架。比如业务逻辑里不 import Spring、不 import Express，框架只是外围的适配器。这样做的好处是，即使未来换框架，核心代码几乎不用改。

第二，面向接口编程，而非面向实现编程——模块之间通过接口通信，而不是直接依赖具体类。这让单元测试变得简单（Mock 接口即可），也让替换实现变得容易。

第三，关注点分离——把变化频率不同的代码分开。业务规则很少变，但 UI、数据库、第三方服务经常变。把它们隔离在不同层，改一处不影响另一处。

第四，不过度设计——架构要匹配当前业务的复杂度。一个只有 3 张表的内部工具，用分层架构就够了，不要为了’看起来高级’而上微服务。