系统架构师-一文搞定架构风格

架构风格分类

五大架构风格	简介	子风格
数据流风格	面向数据流，按照一定的顺序从前向后执行程序	批处理、管道-过滤器
调用/返回风格	构件与构件之间存在相互调用的关系，一般是显示的调用	主程序/子程序、面向对象、层次结构（层次型架构风格）
独立构件风格	构件之间是相互独立的，不存在显式的调用关系，而是通过事件触发、异步的方式执行	进程通信、事件驱动系统（隐式调用）
虚拟机风格	自定义了一套规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台适配	解释器、规则系统
以数据为中心（仓库风格）	以数据为中心，所有的操作都是围绕建立的数据中心进行	数据库系统、黑板系统、超文本系统
其他未分类风格		闭环-过程控制：反馈循环，接收一定的输入，确定一系列的输出，最终使环境达到一个新的状态C2风格：通过连接件绑定在一起的按照一组规则运行的并行构件网络

常考风格

不全是教材内容，主要理解并区分各种架构风格，如何选用正确的架构风格。以前爱考案例对比几种风格的优缺点，最近两次没考（改版后），以后不确定还考不考，可以看一下

1. 管道/过滤器

将数据处理分为多个处理程序（过滤器），每个过滤器负责独立的处理逻辑，处理结果通过管道传给下一个过滤器

• 可修改性：高。每个过滤器相互独立，修改某个过滤器不会影响其他过滤器，容易调整。
• 灵活性：高。通过调整过滤器的顺序或组合新的过滤器，可以灵活修改数据流和处理方式。
• 性能：高。适合并行处理数据流，但多个过滤器间的数据传递可能带来性能开销。
• 可扩展性：高。可以通过增加或替换过滤器来扩展系统功能。
• 交互性：低。过滤器之间通过数据流进行交互，没有直接通信，交互性较弱。

2. 面向对象风格

将软件设计成对象，封装数据和行为，支持继承和多态

• 可修改性：中高。通过封装和继承机制，类和对象可以独立修改，但复杂的对象继承结构可能增加修改难度。
• 灵活性：高。通过多态和继承等特性，系统可以灵活扩展和适应变化，但复杂的继承关系可能带来维护难度。
• 性能：中。性能取决于对象之间的调用频率和层次深度，可能有性能开销。
• 可扩展性：高。可以通过扩展类、继承和实现接口来增加功能，具备良好的可扩展性。
• 交互性：中高。对象通过方法调用进行交互，但过于复杂的对象关系可能导致交互困难。

3. 事件驱动风格

系统行为由事件触发，通过事件处理程序响应不同的事件

• 可修改性：高。事件处理器是松耦合的，可以独立修改不影响其它模块
• 灵活性：高。异步和解耦使得事件处理器可以灵活添加或删除，适合应对动态变化的需求
• 性能：高。通常采用异步处理，但事件复杂或过多事件会导致性能瓶颈
• 可扩展性：高。可以通过添加新的事件处理器或修改事件流来扩展系统
• 交互性：高。通过事件发布和订阅机制实现松耦合的组件交互，交互灵活且动态

4. 分层风格

将系统分为多个层次，每个层次只与相邻层交互

• 可修改性：中高。某一层的修改不影响其它层，但跨层修改时会产生较大的变动
• 灵活性：中。各层职责分明，但修改可能需要跨层修改，限制了系统的灵活性
• 性能：中。多层之间的调用会引入额外的性能开销，特别是在跨层次操作频繁时。
• 可扩展性：中高。可以通过增加或修改某一层的功能来扩展系统，但过多的层次可能导致复杂性增加。
• 交互性：中。交互通常是上下层之间的调用，跨层交互较为复杂。

5. 仓库风格

仓库风格是一种特定的数据共享风格，通常用于实现持久化数据存储。它强调一个中央数据仓库（或数据库）作为系统所有组件的数据源。

• 可修改性：较高，仓库接口和数据独立，支持局部修改
• 灵活性：中等，仓库结构固定，但接口可以灵活调用。
• 性能：较高，集中式存储支持高效数据访问，但并发访问时可能有瓶颈。
• 可扩展性：中等，可通过接口扩展访问能力，但仓库负载可能限制扩展。
• 交互性：中等，各模块通过仓库交互，但交互模式较单一。

6. 数据共享风格

多组件共享一个数据存储，组件之间通过读取和修改共享数据进行通信

• 可修改性：低。由于多个组件依赖同一个共享数据，数据结构的修改会影响所有组件。
• 灵活性：低。系统高度依赖共享数据，灵活性较差，系统变更时难以快速适应
• 性能：中低。集中式数据访问可以提升一致性，但高并发访问会引起竞争和瓶颈，降低系统性能
• 可扩展性：低。由于多个模块共用一个数据源，扩展新的功能或组件时需要重新设计数据结构
• 交互性：中低。组件之间通过共享数据进行间接交互，依赖数据的一致性

7.解释器风格

对输入数据（如编程语言）进行解析为指令并执行，通常用于实现特定的语言或格式

• 可修改性：高。可以通过修改解释器或脚本语言来轻松改变系统行为，无需重新编译整个系统。
• 灵活性：高。系统可以在运行时动态解释新规则或指令
• 性能：中低。解释执行的性能通常低于编译执行，特别是在处理复杂指令时性能瓶颈较为明显
• 可扩展性：高。通过增加新的指令或规则集扩展解释器功能
• 交互性：低。解释器通常执行线性指令，交互性较弱，但可以通过扩展语言功能增强交互

8.基于规则的系统风格

系统通过一组“if-else”规则进行推理和决策，根据输入条件匹配相应的规则并执行相应的操作。

• 可修改性：高。规则可以独立添加、修改和删除，不影响系统的整体模块
• 灵活性：高。可以动态调整或扩展规则集，灵活应对需求变化
• 性能：中。规则数量如果较多则会面临性能瓶颈
• 可扩展性：高。可以通过添加新的规则和推理机制来扩展系统功能
• 交互性：中。规则间的交互通过推理引擎间接实现，规则之间的依赖性可能影响交互效率

9. 闭环控制风格

系统通过监测输出并根据反馈调整输入，形成一个闭环控制

• 可修改性：低。控制回路通常固定，修改一个环节可能影响整个系统的稳定性和性能
• 灵活性：低。闭环控制系统具有固定的反馈结构，调整和扩展的灵活性较差
• 性能：高。通常注重快速响应和系统稳定，性能出色
• 可扩展性：低。扩展新功能或添加新控制回路可能需要重新设计系统
• 交互性：中。交互通常局限在传感器和控制器之间，交互方式单一

这个看熟了，如果出到论文也可以应对一番，不过改版后架构风格的权重低了