软件架构风格

架构风格：描述某一特定应用领域中系统组织方式的惯用模式，反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

一个架构定义一个词汇表和一组约束。

词汇表：包含一些构件和连接件类型。

约束：指出系统是如何将这些构件和连接件组合起来的。

对架构风格的研究和实践促进对设计的重用。

通用的架构风格：1. 数据流风格：批处理序列；管道-过滤器。2. 调用-返回风格：主程序/子程序；面向对象风格；层次结构；客户端/服务器。3. 独立构件风格：进程通信；事件系统。4. 虚拟机风格：解释器；基于规则的系统。
5. 仓库风格：数据库系统；超文本系统；黑板系统。

 架构风格

**架构风格 **	定义	**代表 **
1. 数据流	面向数据流，按照一定的顺序从前向后执行	批处理序列管道-过滤器
**2. 调用/返回 **	构件之间存在显式的互相调用关系， 在系统启动时加载，已经在系统内编码，可直接运行。 容易实现并发处理和多任务。 树型结构，削弱了对计算的控制能力。	主程序/子程序面向对象层次结构客户端/服务器
**3. 独立构件 **	独立构件之间无直接交互(不直接调用一个过程)，而是触发/广播一个或多个事件，通过事件驱动的方式实现通信和协作。	进程通信基于事件的隐式调用
** 4. 虚拟机 **	自定义规则：将业务逻辑中频繁变化的部分（用户级别、折扣规则、机器学习流程）定义为可动态改变的规则，通过灵活的 自定义规则， 实现规则的重组。 基于这个规则来开发构件，能够跨平台适配，业务逻辑随时改变，规则灵活定义、灵活组合。 解释器可以解释执行用户自定义的规则。	解释器基于规则的系统
**5. 仓库 **	以数据为中心，所有的操作都是围绕建立的数据中心进行的	数据库系统超文本系统黑板系统

 架构风格的比较与分析** **

架构风格	灵活性	可扩展性	性能
** 解释器**	将用户级别、折扣规则定义为可动态改变的规则，通过灵活的 自定义规则， 实现规则的重组。 基于这个规则来开发构件，能够跨平台适配，业务逻辑随时改变，规则灵活定义、灵活组合。 解释器可以解释执行用户灵活自定义的规则(个性化折扣)。	折扣规则是独立的语法规则，可动态改变，由解释器对变化的规则进行解析，修改更容易。加入新的用户级别和折扣规则时，通过定义新的规则实现可扩展性。	解释器是运行期动态绑定执行。 需要对用户级别与折扣规则进行实时解释,性能较差。
** 基于规则**
** 面向对象**	面向对象的实现相对固定****，高度模块化，将用户级别、折扣规则等封装为对象，业务有变化需要修改具体的类/对象。	业务逻辑有变化需要修改具体的类/对象。 加入新的用户级别和折扣规则时，需要重新定义新的对象，并需要重启系统。	在系统启动时加载，用户级别和折扣规则已经在系统内编码，可直接运行，性能较好。
** 隐式调用**	独立构件之间无直接交互、不直接调用一个过程，而是触发/广播一个或多个事件，通过事件驱动的方式实现通信和协作。 ** 解耦**构件之间的依赖关系，降低耦合度，提升灵活性。	支持构件的动态添加和移除。当系统需要新增功能时，可以通过添加监听器或订阅者的方式来扩展系统的功能。	能够实现异步、非阻塞的事件处理。 通过处理函数的并发调用，提高系统处理性能。性能较好 ** 事件发布者将事件发布到事件总线上，事件订阅者可以异步处理这些事件，从而提高**系统的并发性和性能。
** 管道-过滤器**	流式数据结构，数据驱动机制,处理流程事先确定，顺序或有限循环的交互方式，交互性差。 每个构件都有一组输入和输出，构件读取输入的数据流，经过内部处理产生输出数据流。 数据处理组件之间有依赖关系，前一个构件的输出作为后一个构件的输入，前后数据流关联，灵活性差。	数据与处理紧密关联，调整处理流程需要重新启动系统。 接口适配的扩展方法。	需要数据格式转换，性能降低。 支持过滤器并发调用，性能提高。
** 仓库**	数据存储在中央仓库，处理流程独立，独立构件之间无直接交互，通过数据仓库间接交互。 独立构件对中央数据进行操作，支持交互式处理。	数据与处理解耦合，可动态添加和删除处理组件。 独立构件与数据仓库进行数据适配。	数据与处理分离，需要加载数据，性能降低。 数据处理组件之间一般无依赖关系，可并发调用，提高性能。

**比较因素 **	**管道-过滤器风格 **	**数据仓储风格 **
**数据结构 **	流式数据	文件或模型
**控制结构 **	数据驱动	业务功能驱动
**交互方式 **	顺序结构、有限循环结构	独立构件之间无直接交互，通过数据仓库间接交互
数据处理	数据驱动机制，处理流程事先确定，交互性差。	数据存储在中央仓库，处理流程独立，独立构件对中央数据进行操作，支持交互式处理。
可扩展性	数据与处理紧密关联，调整处理流程需要重新启动系统。	数据与处理解耦合，可动态添加和删除处理组件。
扩展方法	接口适配	与数据仓库进行数据适配
处理性能	需要数据格式转换，性能降低。 支持过滤器并发调用，性能提高。	数据与处理分离，需要加载数据，性能降低。 数据处理组件之间一般无依赖关系，可并发调用，提高性能。

架构案例分析历年真题考点2022      解释器、面向对象2021      解释器、隐式调用、管道-过滤器2020      管道-过滤器、仓库风格
2019      基于规则、面向对象2016      管道-过滤器、仓库风格

**架构风格 **	**具体风格名 **	**常考案例 **
** 数据流**	批处理	传统的编译器，词法分析、语法分析等处理过程以独立功能模块的形式存在，程序源代码作为一个整体，依次在不同模块中进行传递。
管道-过滤器	1. 数据输入某个构件，经过内部处理，产生数据输出。 2. 传统的编译器包括词法分析、语法分析、语义分析、代码生成等，每个阶段产生的结果作为下一个阶段的输入。
调用-返回	主程序/子程序
面向对象
层级结构	物联网系统
独立构件	进程通信
基于事件的隐式调用	1.根据用户的注册兴趣，向用户推送其感兴趣的新闻内容； 2.修改代码后，触发语法高亮、语法错误提示、代码格式化
** 虚拟机 **	解释器	1. 游戏设计支持自行创建地图，定义游戏对象的行为； 2. 业务灵活组合：将现有的业务功能进行多种组合，形成新的业务功能。 3. 在线游戏系统支持用户自定义游戏对象和行为。 4. 通过拖拽算法组件灵活定义机器学习流程。
基于规则	1.社保金的计算方式随国家经济的变化而动态改变； 2.不定期更新VIP会员的审核标准、更新VIP折扣系统； 3.扫地机器人响应突发事件，根据自身状态进行动态调整； 4.针对不同等级的用户提供相应的折扣方案。
** 仓库**	数据仓储	针对某编程语言的集成开发环境IDE：代码编辑、语法高亮、运行调试，能够实现不同工具之间的信息交互。
黑板	语音识别、知识推理、语音搜索:基于先验知识的条件判断;
超文本
闭环	过程控制	轿车巡航定速，持续测量车辆的实时速度，设定期望速度，控制油门和刹车。
** C2风格**	通过连接件绑定在一起，按照一组规则运作的并行构件。 系统中的构件和连接件都有一个顶部和一个底部，顶部 — 底部。

 1. 数据流架构风格** **

批处理架构风格

每个处理步骤是一个单独的程序，每一步必须在前一步结束后才能开始，数据必须是完整的，以整体为单位传递。构件：一系列固定顺序的独立应用程序，构件之间只通过数据传递交互。连接件：某种类型的媒介。

管道-过滤器架构风格

流式数据结构，数据驱动机制, 处理流程事先确定，顺序或有限循环的交互方式，交互性差。每个构件都有一组输入和输出，构件读取输入的数据流，经过内部处理产生输出数据流。数据处理组件之间有依赖关系，前一个构件的输出作为后一个构件的输入，前后数据流关联，灵活性差。前面执行到部分可以开始下一个的执行。数据与处理紧密关联，调整处理流程需要重新启动系统，接口适配的扩展方法。

需要数据格式转换，性能降低。支持过滤器并发调用，性能提高。

不适用于交互性强的应用，对于存在关系的数据流必须进行协调。

适合于系统可划分模块，有清晰的模块接口，具有并发性的场景。

构件：过滤器。

连接件：管道。

 2. 调用-返回架构风格** **

---

主程序/子程序的架构风格

单线程控制，显式调用，主程序直接调用子程序，过程调用作为交互机制，调用关系具有层次性。容易实现并发处理和多任务。树型结构，削弱了对计算的控制能力。

构件：主程序、子程序。连接件：过程调用。

面向对象的架构风格

面向对象的实现相对固定，高度模块化，将数据和相应的操作封装在对象中，例如将用户级别、折扣规则等封装为对象，业务逻辑有变化需要修改具体的类/对象。加入新的用户级别和折扣规则时，需要重新定义新的对象，并需要重启系统。在系统启动时加载，用户级别和折扣规则已经在系统内编码，可直接运行，性能较好。

构件：对象，通过对象调用封装的方法和属性。连接件：过程调用。

层次型架构风格

层次之间具有调用关系，每层为上一层提供服务，使用下一层的服务，只能见到与自己相邻的层接口。修改某一层，最多只影响其相邻的两层，通常只能影响上层。

划分的层次越多，系统的性能越差。

适合不同层次之间低耦合的系统。

「优点」1. 基于可增加抽象层的设计，分而治之的策略。2. 不同的层次处于不同的抽象级别，核心层封装通用的方法，与业务无关。

3. 允许每层用不同的方法实现，为软件复用提供支持。

「缺点」1. 很难找到一个合适且正确的层次抽象方法，系统划分层次不容易。2. 层次越多，性能越差。
构件：组成一个层次结构。连接件：通过决定层间如何交互的协议来定义。

客户端/服务器架构风格

胖客户端C/S1. 客户机（前台）完成与用户的交互。2. 服务器（后台）负责数据管理。
瘦客户端C/S1. 表示层：客户机负责与应用逻辑间的对话功能，是应用的用户接口。
2. 功能层：应用服务器是应用的主体，负责具体的业务处理逻辑。3. 数据层：数据库管理系统。

 3. 独立构件架构风格** **

进程通信架构风格

构件通常是命名过程，独立的进程间消息传递的方式可以是点对点、同步异步、远程过程调用。

构件：独立的进程。连接件：消息传递。

基于事件的隐式调用风格

独立构件不直接调用一个过程，而是触发/广播一个或多个事件，通过事件驱动的方式实现通信和协作。构件中的过程在一个/多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。

解耦构件之间的依赖关系，降低耦合度，提升灵活性。

支持构件的动态添加和移除，当系统需要新增功能时，可以通过添加监听器或订阅者的方式来扩展系统的功能。

能够实现异步、非阻塞的事件处理：事件发布者将事件发布到事件总线上，事件订阅者可以异步处理这些事件，从而提高系统的并发性和性能。

构件：一些模块（过程、事件的集合）。连接件：在事件中注册一些过程，当发生这些事件时，过程被调用。

 4. 虚拟机架构风格** **

「灵活性」****将业务逻辑中频繁变化的部分(用户级别、折扣规则、机器学习流程)定义为可动态改变的规则，通过灵活的自定义规则， 实现规则的重组。基于这个规则来开发构件，能够跨平台适配，业务逻辑随时改变，规则灵活定义、灵活组合。解释器可以解释执行用户自定义的规则(个性化折扣)。
「 ****可扩展性」折扣规则是独立的语法规则，可动态改变，由解释器对变化的规则进行解析，修改更容易。加入新的用户级别和折扣规则时，通过定义新的规则实现可扩展性。
「****性能」****解释器是运行期动态绑定执行。需要对用户级别与折扣规则进行实时解释，性能较差。
「 特点」****系统核心是虚拟机，可以用多种操作来解释一个句子，灵活应对自定义场景。
**「**适用场景」****适合于特定领域，如模式匹配系统、语言编译器。

解释器架构风格

解析与运行自定义的规则/业务/语言，通常被用来建立一种虚拟机，以弥合程序语义与硬件语义之间的差异，但执行效率低。

基于规则的架构风格

基于规则的系统包括：规则集、规则解释器、规则/数据选择器、工作内存。
规则定义：根据具体需求，设计和定义一系列规则，形成规则集。
数据输入：数据输入至工作内存，并进行预处理。规则匹配：通过规则选择器，将输入数据与规则集中的规则进行匹配。操作执行：当规则匹配成功，由规则解释器根据规则定义的操作执行相应的动作。输出生成：根据执行结果生成输出数据。

 5. 仓库/数据共享架构风格** **

数据仓储风格

中央共享数据源+多个独立处理的构件。

• 中央数据结构：说明当前状态。
• 独立构件：在中央数据存储上执行。

数据存储在中央仓库，处理流程独立，独立构件之间无直接交互，通过数据仓库间接交互。

独立构件对中央数据进行操作，支持交互式处理。数据与处理解耦合，可动态添加和删除处理组件。独立构件与数据仓库进行数据适配。数据与处理分离，需要加载数据，性能降低。数据处理组件之间一般无依赖关系，可并发调用，提高性能。

黑版系统

适用于解决复杂的非结构化问题，解空间很大，求解过程不确定，对于解决问题没有确定性算法，求解过程中综合运用多种不同的知识源。1. 知识源：独立计算的不同单元2. 黑板：全局数据库3. 控制：通过黑板状态的变化来控制应用于信号处理、语音识别、问题规划、编译器优化、知识推理、松耦合代理数据共享存取。

超文本系统

适用于互联网领域，网状链接，构件之间任意跳转。连接件：通过决定层间如何交互的协议来定义。

 6. 闭环控制架构风格** **

发出控制命令并接收反馈，通过不断的测量被控对象，循环往复达到平衡，设定参数，不断调整。
适合于嵌入式系统，涉及连续的动作与状态。软件与硬件之间可以表示为一个反馈。汽车巡航定速。连接件：通过决定层间如何交互的协议来定义。

 7. C2架构风格** **

通过连接件绑定在一起，按照一组规则运作的并行构件。系统中的构件和连接件都有一个顶部和一个底部，构件的顶部 — 连接件的底部，构件的底部 — 连接件的顶部，构件和构件之间不允许直接连接。