系统架构-软件架构设计-软件架构风格

架构风格定义了用于描述系统的术语表和一组指导构建系统的规则

五大架构风格

数据流风格

数据——>第一步处理——>第二步处理——>第n步处理

分步处理，前一步的处理结果是后一步的输入内容【数据驱动】

优点：

1. 松耦合【高内聚-低耦合】
2. 良好的重用性/可维护性
3. 可扩展性【标准接口适配】
4. 良好的隐蔽性
5. 支持并行

缺点：

1. 交互性较差
2. 复杂性较高
3. 性能较差（每个过滤器都需要解析与合成数据） 

典型实力：传统编译器、网络报文处理

两大子风格：

• 批处理序列：大量整体数据、无需用户交互
• 管道-过滤器：流式数据、弱用户交互

 独立构建风格

类似于事件监听

优点：

1. 松耦合
2. 良好的重用性/可修改性/可扩展性 

缺点：

1. 构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应。而且不能保证这些过程被调用的顺序
2. 数据交换的问题
3. 既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理就存在问题。 

特点：

• 系统由若干子系统构成且成为一个整体；
• 系统有统一的目标；
• 子系统有主从之分；
• 每一子系统有自己的事件收集和处理机制。  

调用/返回风格

构建之间直接交互 

虚拟机风格

优点：

可以灵活应对自定义场景

缺点：

复杂度较高 

子风格：

• 解释器：适用于需要“自定义规则”的场合
• 规则为中心：在解释器的基础上增加经验规则，适用于专家系统

仓库风格

黑板系统：

 

主要区别：触发机制

当黑板的共享数据发生变动时，会通知所有知识源

优点（黑板风格）：

1. 可更改性和可维护性；
2. 可重用的知识源；
3. 容错性和健壮性

缺点（黑板风格）：

1. 不能保证有好的解决方案；
2. 难以建立好的控制策略；
3. 低效；
4. 开发困难；
5. 缺少并行机制 

子风格：

• 数据库风格：以数据为中心
• 黑板风格：在以数据为中心的基础上，使用中心数据触发业务逻辑部件，典型实例有语音识别、模式识别、图像处理、知识推理

其他风格

闭环控制风格

 适合于嵌入式系统，用于解决简单闭环控制问题

C2风格

基本规则：

• 构件和连接件都有有一个顶部和底部。
• 构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连
• 一个连接件可以和任意数目的其他构件和连接件连接
• 当两个连接件进行直接连接时，必须其中一个的底部到另一个的顶部 

层次架构风格

两层C/S架构

客户端和服务器都有处理功能，现在已经不常用

 

三层C/S架构

将处理数据的功能独立出来，表示层和数据层都变得简单。表示层在客户机上，功能层在应用服务器上，数据层在数据库服务器上。各层在逻辑上保持相对独立

三层B/S架构

是三层C/S架构的变种，将客户端变为用户客户端上的浏览器，将应用服务器变为网络上的WEB服务器，又称为0客户端架构。

混合架构风格

内外有别模型：企业内使用C/S，外部人员访问使用B/S

查改有别：采用B/S查询，采用C/S修改

富互联网应用RIA

从三层B/S架构演化而来，RIA是一种用户接口，比用HTML实现的接口更加健壮，本质还是网站模式。但还是会在用户第一次打开时，利用高速网络传输在本地下载轻量的客户端。典型应用是小程序

面向服务的架构风格

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。

SOA并不仅仅是一种开发方法，还具有管理上的优点，管理员可直接管理开发人员所构建的相同服务。多个服务通过企业服务总线进行调用。

图片均来自于网络