乐于分享
好东西不私藏

【软件系统架构】系列十三:系统架构设计——软件架构风格

【软件系统架构】系列十三:系统架构设计——软件架构风格

1.软件架构风格(Software Architecture Style)

1.1 定义

软件架构风格是一类应用系统的组织方式的通用模式。它描述了系统构件如何组织及它们之间的交互方式,提供了一种架构级别的设计语言

核心组成:

(1)词汇表(Vocabulary)
  • 构件(Component):系统中的基本模块或单元,如服务、处理器、数据库等。
  • 连接件(Connector):描述构件之间交互的机制,如消息传递、调用、事件、管道等。
(2)约束规则(Constraints)
  • 描述构件和连接件如何组合、组织,以及它们的交互规则。
  • 例如,数据流架构风格要求信息只能沿单向管道流动。

1.2 作用与价值

(1)反映结构 & 语义特征
  • 不同风格强调不同关注点,如性能、可扩展性、可维护性等。
  • 例:客户端-服务器风格强调分布式服务与资源共享,事件驱动风格强调异步响应和解耦。
(2)提供设计复用
  • 经过验证的架构风格可以在多个系统中复用,降低设计风险。
  • 例:REST 风格可用于大规模 Web 服务系统;MVC 风格可用于 GUI 应用。
(3)构成架构复用基础
  • 架构模式(Architecture Pattern)往往基于一种或多种架构风格。
  • 复用风格可以加速系统开发,同时保证质量属性的满足。

1.3 典型架构风格示例

架构风格主要特点适用场景例子
分层(Layered)
系统分为多个层,每层只与相邻层交互
企业应用、操作系统
OSI 模型、Spring MVC
客户端-服务器(Client-Server)
客户端请求,服务器响应
Web 服务、数据库服务
HTTP、SMTP
事件驱动(Event-Driven)
事件触发系统响应,解耦生产者与消费者
GUI、实时系统、微服务
Node.js EventEmitter
管道-过滤(Pipe-and-Filter)
数据流通过一系列处理模块
流处理、编译器
Unix 命令管道
共享存储(Shared Repository)
多个模块共享同一数据存储
CAD 系统、数据仓库
Git、数据库系统
微内核(Microkernel)
核心提供最小功能,扩展通过插件实现
插件型应用、IDE
Eclipse、OS 内核模块
微服务(Microservices)
系统由独立服务组成,服务通过 API 通信
大规模分布式应用
Netflix、Amazon

1.4 深度解析

(1)可组合性
  • 架构风格不是孤立使用的,常常可以混合使用,如微服务 + 事件驱动。
(2)质量属性驱动
  • 风格选择应考虑非功能需求(性能、可维护性、安全性等)。
(3)演化与适应性
  • 风格可以随着系统需求演化进行调整,但核心约束通常保持不变。
(4)验证与复用
  • 一个被广泛应用的风格,其可复用性和设计安全性已经得到验证。

2.基本架构风格分类

2.1 数据流风格(Data Flow)

核心思想:系统中的数据沿着预定路径流动,每个处理单元只关注数据的处理,不关注控制流程。

子类核心机制优点缺点典型案例
批处理序列(Batch Sequential)
数据以批次顺序传递,每个处理阶段独立完成后交给下一个阶段
简单、易于理解和实现;适合离线处理
数据延迟高,不适合实时系统
传统编译器:词法分析 → 语法分析 → 语义分析 → 目标代码生成
管道-过滤器(Pipe & Filter)
数据边生成边传递,每个过滤器独立处理数据流
易于扩展和组合;支持并行处理
处理顺序固定,错误处理复杂;调试困难
Unix 命令行工具链(grep、sort、awk)、流处理框架(Apache Flink)

2.2 调用/返回风格(Call/Return)

核心思想:系统由调用关系驱动,上层模块通过调用下层模块实现功能。

子类核心机制优点缺点典型案例
主程序/子程序
上层程序控制流程,下层程序完成特定任务
控制清晰;易于结构化程序设计
模块间耦合较高,复用性有限
C 语言程序
面向对象(Object-Oriented)
对象封装数据与行为,通过消息传递协作
模块封装、复用性高;易于扩展
对象设计复杂,性能开销可能大
Java、C++ 系统设计
层次结构(Layered)
系统分层,层与层之间只允许与邻层交互
易于分工和维护;安全性可控
性能可能受限于层间调用
OSI 七层网络模型、操作系统内核
客户端/服务器(Client/Server)
客户端请求服务,服务器提供响应
清晰的功能分离;支持分布式
网络依赖,单点服务器故障可能影响全局
数据库系统、Web 服务

2.3 独立构件风格(Independent Component)

核心思想:构件独立存在,通过消息或事件进行协作,强调松耦合。

子类核心机制优点缺点典型案例
进程通信(Process Communication)
进程间通过消息传递通信,可同步或异步
松耦合,支持分布式
编程复杂,通信延迟
MPI 并行计算、分布式系统
事件驱动 / 隐式调用(Event-driven / Implicit Invocation)
构件被动响应事件,由事件触发
松耦合,灵活,可异步处理
难以追踪调用链,调试困难
GUI 系统(按钮点击、菜单事件)、发布/订阅系统

2.4 虚拟机风格(Virtual Machine)

核心思想:通过虚拟执行环境或规则推理系统,实现抽象层的功能控制。

子类核心机制优点缺点典型案例
解释器(Interpreter)
虚拟机解释执行指令或代码
跨平台、动态执行
性能低于编译型
Python 解释器、JVM
基于规则系统(Rule-based System)
规则库 + 推理机,根据事实匹配规则执行
可解决复杂逻辑问题;易于修改规则
推理复杂度高;性能受规则数量影响
专家系统、决策支持系统(DSS)

2.5 以数据为中心风格(Data-Centric)

核心思想:系统围绕数据组织,处理模块围绕统一数据存储进行操作。

子类核心机制优点缺点典型案例
仓库风格(Repository)
统一数据中心,模块独立操作数据
数据集中管理,易于共享
数据库瓶颈,更新复杂
IDE(如 Eclipse)、大型企业系统
黑板风格(Blackboard)
共享知识源(黑板),各模块根据黑板状态合作求解
适合复杂问题求解;模块可独立发展
控制复杂,性能开销大
语音识别、AI 推理系统

分析

  • 数据流风格适合顺序处理或流式处理任务,关注数据传递路径。
  • 调用/返回风格强调控制流和模块层次结构,适合有明确调用关系的系统。
  • 独立构件风格强调松耦合和异步协作,适合分布式、事件驱动系统。
  • 虚拟机风格适合解释执行或基于规则的复杂逻辑推理。
  • 以数据为中心风格以数据为核心,适合知识密集型或大型企业系统。 暂时无法在飞书文档外展示此内容

3.层次结构风格扩展

3.1 基本思想

  • 层次结构风格通过分层组织系统,每层只与上下相邻层交互,强调模块化、封装与职责分离
  • 每层只关注自身职责,简化开发、维护和扩展。

3.2 常见层次结构分类

  • 两层 C/S:客户端 + 服务器
  • 三层 C/S:表现层 + 应用层 + 数据层
  • 三层 B/S:浏览器 + Web 服务器 + 数据库
  • 混合架构:C/S + B/S 结合
  • RIA(富互联网应用):增强 B/S 用户体验(典型:小程序、Flash、Silverlight)
类型架构层核心特点典型应用
两层 C/S
客户端 + 服务器
客户端直接请求服务器处理业务
早期数据库应用
三层 C/S
表现层 + 应用层 + 数据层
清晰分离界面、业务逻辑和数据访问
企业应用系统
三层 B/S
浏览器 + Web 服务器 + 数据库
浏览器作为轻客户端,服务器处理业务逻辑
Web 应用
混合架构
C/S + B/S
结合两种架构优点,客户端部分处理逻辑,Web 提供轻量访问
ERP、OA 系统
RIA(富互联网应用)
前端增强层 + Web 服务器 + 数据库
丰富前端交互体验,增强 B/S 用户体验
小程序、Flash、Silverlight

3.3 经典模式:MVC / MVP / MVVM

  • MVC / MVP / MVVM
  • MVC:Model-View-Controller
  • MVP:Presenter 作为中介,隔离 View-Model
  • MVVM:双向数据绑定(前端框架 Vue/React 常用)
模式组成核心特点典型应用
MVC
Model + View + Controller
Controller 控制业务流程,Model 保存数据,View 显示界面
Web 框架:Rails、Spring MVC
MVP
Model + View + Presenter
Presenter 中介隔离 View 与 Model,实现更好测试性
WinForms、Android MVP
MVVM
Model + View + ViewModel
双向数据绑定,ViewModel 封装 UI 状态与逻辑
Vue、React(Hooks/State)

深入解析

  • MVC:强调控制器驱动,UI 被动渲染。
  • MVP:Presenter 处理逻辑并直接操作 View,实现解耦。
  • MVVM:数据绑定自动同步 Model 与 View,前端框架支持响应式 UI,减少手动 DOM 操作。

3.4 层次结构风格 示例(竖向树形表示)

4.面向服务架构(SOA)

4.1 核心思想

  • 粗粒度(Coarse-grained):服务封装完整业务功能,而非微小操作。
  • 松耦合(Loosely Coupled):服务之间低依赖,调用方式统一。
  • 标准化接口(Standardized Interface):通过规范协议实现跨语言、跨平台调用。

4.2 特征

特征说明
服务可重用
相同服务可在不同应用场景重复调用,降低开发成本
服务可组合
业务流程可通过组合多个服务完成,实现灵活业务编排
语言无关
服务通过标准协议调用,不依赖底层语言
标准化接口
WSDL(Web Services Description Language)、SOAP、XML 等标准化描述和传输数据

4.3 实现方式

(1) Web Service
  • UDDI(Universal Description, Discovery and Integration):服务注册与发现。
  • WSDL:服务接口描述,包括方法、参数、返回值、协议。
  • SOAP:消息传输协议,XML 格式封装请求和响应。
  • 特征:平台无关、可跨网络调用,典型用于企业系统集成。
(2) 企业服务总线(ESB)
  • 核心作用:实现企业内部服务的统一总线通信。
  • 功能
  • 消息路由与转换
  • 协议适配(HTTP、JMS、SOAP 等)
  • 安全、事务、监控管理
  • 优点:集中管理服务,支持业务流程编排,提高可扩展性。

4.4 SOA  图示

5.其他补充风格

  • 闭环/过程控制风格:典型于控制系统(空调、汽车巡航)。
  • C2 风格:构件-连接件,按规则组合(多用于学术研究)。

6.总结表

架构风格关键特征典型应用
数据流-批处理
整体传递,顺序执行
传统编译器
数据流-管道过滤器
前一输出即下一输入,可并行
编译器流水线、Unix Shell
调用/返回-主程序子程序
过程调用,层次关系
FORTRAN 程序
调用/返回-面向对象
对象封装,消息交互
Java 程序
调用/返回-层次结构
只影响邻接层,支持抽象复用
OSI 模型、操作系统
独立构件-进程通信
消息传递,同步/异步
分布式系统
独立构件-事件驱动
隐式调用,事件触发
GUI 框架、IDE 提示
虚拟机-解释器
解释执行
JVM、Python
虚拟机-规则系统
规则集+推理机
专家系统
仓库风格
中央数据库+操作模块
IDE、数据库系统
黑板风格
知识源+黑板+控制
语音识别、AI 推理
闭环风格
反馈控制
自动温控、巡航系统
SOA
服务松耦合,标准接口
企业级系统、微服务雏形