软件架构选型是系统设计过程中最具战略意义的决策之一,直接影响系统的质量属性、开发效率和长期可维护性
要想进行选型,首先就要弄清楚里面的包含元素:架构风格,架构模式,设计模式。
1.概念层次与关系
-
架构风格:最高层抽象,定义系统组织原则(如“数据流”或“调用-返回”)。
-
架构模式:在某种风格下的具体实现方式(如“微服务”属于“独立组件风格”)。
-
设计模式:解决局部问题的代码级方案(如“工厂模式”)。
2.核心特征对比
维度 | 架构风格 | 架构模式 | 设计模式 |
抽象层级 | 最高层,系统级 | 中层,子系统或模块级 | 底层,代码级 |
关注点 | 组件交互方式、数据流控制 | 子系统的结构化方案 | 对象/模块间的协作方式 |
范围 | 整个系统 | 特定子系统或功能域 | 单个类或模块 |
变更影响 | 影响全局架构 | 影响局部架构 | 影响代码实现 |
示例 | 数据流风格、仓库风格 | MVC、微服务、分层架构 | 工厂模式、观察者模式 |
3.具体类型及核心特征
(1) 架构风格(Architectural Styles)
风格类型 | 核心特征 | 典型应用 |
数据流风格 | - 组件为过滤器,数据通过管道单向流动 - 无状态,高复用性 | Unix管道、批处理系统 |
仓库风格 | - 中央数据仓库 + 独立组件 - 组件通过仓库交互(主动/被动) | 编译器、IDE、黑板系统 |
调用-返回风格 | - 分层调用,同步通信 - 控制流显式传递 | 传统单体应用、操作系统 |
独立组件风格 | - 组件自治,异步通信(事件/消息) - 松耦合 | 微服务、事件驱动系统 |
虚拟机风格 | - 解释器/规则引擎执行自定义逻辑 - 动态行为 | 游戏脚本引擎、规则引擎 |
(2) 架构模式(Architectural Patterns)
模式类型 | 核心特征 | 所属风格 | 典型应用 |
分层架构 | - 垂直分层(表现层/业务层/数据层) - 每层仅依赖下一层 | 调用-返回风格 | Spring MVC、企业级应用 |
MVC | - 分离模型(数据)、视图(UI)、控制器(逻辑) - 解耦UI与业务逻辑 | 调用-返回风格 | Web框架(Ruby on Rails) |
微服务 | - 小型独立服务,轻量通信(REST/gRPC) - 独立部署+数据自治 | 独立组件风格 | 云原生应用(Netflix) |
事件驱动 | - 组件通过事件发布/订阅交互 - 异步、松耦合 | 独立组件风格 | 实时数据处理(Kafka) |
黑板模式 | - 共享数据仓库 + 知识源协作 - 动态决策 | 仓库风格 | 语音识别、诊断系统 |
(3) 设计模式(Design Patterns)
模式类型 | 核心特征 | 所属架构模式 | 典型应用 |
工厂模式 | - 封装对象创建逻辑 - 解耦客户端与具体类 | 通用(任何架构) | 依赖注入框架(Spring) |
观察者模式 | - 一对多依赖,状态变更自动通知 - 事件处理基础 | 事件驱动架构 | GUI框架(React/Vue状态管理) |
策略模式 | - 封装算法族,运行时切换 - 避免条件分支 | 通用 | 支付网关(多支付方式) |
适配器模式 | - 转换接口兼容性 - 复用旧组件 | 分层架构 | 系统集成(旧API适配新系统) |
单例模式 | - 全局唯一实例访问 - 控制资源占用 | 通用(需谨慎使用) | 配置管理器、日志服务 |
4.最后总结:
风格决定系统整体结构(如“独立组件风格”),模式是其具体实现(如“微服务”),设计模式解决实现中的细节问题(如“服务发现用观察者模式”)。