系统架构设计-①软件架构风格
目的：
软件体系结构，另一个名叫软件架构（Software Architecture，SA），所以下文中提到的“体系结构”==“架构”。
软件体系结构设计的一个重要核心目标是达到体系结构级的复用，所以需要研究透彻各个软件体系结构风格的特点才能更好的复用。
体系结构两个重要属性：
软件体系结构风格是描述某一个特定应用领域中系统组织方式的惯用模式，一个体系结构风格定义了一个词汇表和一组约束。
1. 词汇表中包含一些构件和连接件类型；
2. 约束指出系统是如何将这些构件和连接件组合起来的。
词汇表和约束
软件体系结构风格 = 一套固定的 “专业名词” + 一套必须遵守的 “规矩”。（业界公认的一套套路）
词汇表 = 名词、角色、构件叫什么。（规定了系统由哪些零件组成）
约束 = 必须遵守的规则、不能乱搞。（规定了零件之间怎么组合、不能乱来）
👉词汇表：就是这套风格里的 “专业术语”，用了这个风格，大家就统一用这几个词说话，大家不用废话多解释，不会歧义，一提就都知道。
举个最熟的：分层架构，它的词汇表就是：
- 表示层
- 业务逻辑层
- 数据访问层
- 数据库
大家一听到这几个词，就知道：“哦，你们用的是分层架构。”再比如：管道 - 过滤器，词汇表就是：
- 过滤器
- 管道
- 数据流
再比如：事件驱动，词汇表就是：
- 事件
- 发布者
- 订阅者
👉约束：就是 “必须遵守的规则、不能违反”，用了这个风格，就必须按它的规矩来，不然就不是这个风格。
继续用分层架构举例，它的约束是：
- 上层可以调用下层
- 下层不能反过来调用上层
- 同层之间一般不直接调用
- 每一层只对相邻层暴露接口
你违反一条，就不是标准分层架构，再比如管道 - 过滤器，约束是：
- 每个过滤器独立，不共享状态
- 数据只能从管道流过去
- 过滤器之间不能直接互相调用
再比如事件驱动，约束是：
- 发布者不知道谁订阅
- 订阅者不知道谁发布
- 不直接调用，只通过事件通信
常用的软件体系结构（架构）风格：
| 体系结构风格大类 | 具体体系结构风格 | 词汇表（零件/术语） | 约束（必须遵守的规矩） | 具体实现 | 场景关键词 |
|---|---|---|---|---|---|
| ①数据流风格 | 批处理体系结构风格 | 批处理任务、数据集、处理步骤、输出结果 | 1. 数据以“批次”为单位整体处理，无实时交互；2. 处理步骤按固定顺序执行，前一步完成后再执行下一步；3. 不支持中途修改数据或中断处理；4. 专注于离线数据处理，不依赖实时输入。 | 数据统计报表生成、历史数据归档、批量数据导入/导出、离线ETL处理 | 全量数据、固定顺序、一次性批量执行、无实时流 |
| 管道-过滤器体系结构风格 | 过滤器（Filter）、管道（Pipe）、数据流 | 1. 过滤器独立，不维护全局状态；2. 数据仅通过管道在过滤器间流转；3. 过滤器之间不直接调用，仅通过数据流通信；4. 过滤器仅负责“输入→处理→输出”。 | 编译器（词法分析→语法分析→语义分析）、日志处理系统、实时ETL数据清洗、图像处理流程 | 流水线、分步处理、流式输入输出、模块独立可替换、无状态 | |
| ②调用/返回风格 | 主程序/子程序风格 | 主程序、子程序、调用指令、返回值 | 1. 单线程执行，主程序统一调度所有子程序；2. 子程序仅能被主程序或其他子程序调用，不能主动调用；3. 执行流程自上而下，按顺序调用，完成后返回结果；4. 子程序之间不直接通信，通过主程序传递数据。 | 小型控制台程序、简单工具类程序、传统C语言程序 | 集中控制、固定流程、主程序调度子程序、结构化顺序调用 |
| 面向对象体系结构风格 | 对象、类、封装、继承、多态、消息 | 1. 数据与行为封装在类中，仅通过接口对外暴露；2. 类通过继承实现复用，通过多态实现灵活调用；3. 对象之间通过发送消息进行通信，不直接操作内部数据；4. 类的修改不影响其他关联类（遵循开闭原则）。 | JavaWeb项目（实体类、服务类封装）、APP开发（页面/业务对象封装）、组件化开发 | 封装、继承、多态、对象交互、实体与行为绑定 | |
| 层次型体系结构风格 | 层（Layer）、接口、调用、返回 | 1. 上层依赖下层，下层不依赖上层；2. 仅允许相邻层调用，禁止跨层调用；3. 同层构件之间不直接调用；4. 每层仅对上层提供服务，对下层进行调用。 | 企业Web应用（表示层→业务逻辑层→数据访问层→数据库）、桌面应用（界面层→逻辑层→数据层） | 分层隔离、上层依赖下层、单向调用、解耦、可替换层级 | |
| 客户端/服务器体系结构风格（C/S） | 客户端、服务器、请求、响应、网络通信 | 1. 客户端负责用户交互和局部处理，服务器负责核心业务和数据存储；2. 客户端主动向服务器发送请求，服务器接收后处理并返回响应；3. 服务器可同时响应多个客户端请求，客户端之间不直接通信；4. 依赖网络连接，客户端需安装专用程序。 | 桌面版管理系统（如OA客户端）、游戏客户端、数据库客户端（如Navicat） | 客户端、服务端、两端分离、请求响应、一对多、客户端界面交互、服务端集中存数据、共享中心资源、远程调用访问后台 | |
| ③以数据为中心的风格 | 仓库体系结构风格 | 仓库（中央数据库）、访问构件、数据接口 | 1. 所有构件共享同一个中央仓库（数据库）；2. 构件之间不直接通信，仅通过读写仓库数据交互；3. 仓库统一管理数据，构件仅负责数据的访问和处理；4. 数据一致性由仓库统一维护。 | 传统信息管理系统（如学生管理系统）、企业ERP系统、数据中台 | 中央共享数据仓库、组件只读写、互不直接通信、无中央调度 |
| 黑板体系结构风格 | 黑板（共享数据区）、知识源、控制器、推理规则 | 1. 黑板为核心共享数据区，所有知识源可读写黑板；2. 知识源独立，异步修改黑板数据，无需相互依赖；3. 控制器协调知识源的访问顺序和数据处理优先级；4. 知识源根据黑板数据变化触发自身处理逻辑。 | 语音识别系统、信号处理系统、复杂决策系统（如医疗诊断专家系统） | 黑板 + 知识源 + 调度器、不确定问题、多轮迭代推理、逐步求解 | |
| ④虚拟机风格 | 解释器体系结构风格 | 虚拟机、解释引擎、源代码、指令集 | 1. 程序由解释引擎逐句解释执行，不直接编译为机器码；2. 源代码无需编译，可直接运行，跨平台性强；3. 解释引擎负责解析指令，控制执行流程；4. 执行效率低于编译型程序，依赖解释环境。 | 脚本语言运行环境（Python/JavaScript解释器）、HTML解析引擎、简单脚本执行工具 | 自定义脚本、规则引擎、指令解释执行、动态配置规则 |
| 规则系统体系结构风格 | 规则库、事实库、推理引擎、规则解释器 | 1. 业务逻辑以“规则”形式存储在规则库，不硬编码；2. 推理引擎根据事实库中的数据，匹配规则库中的规则并执行；3. 规则可动态添加、修改，无需修改推理引擎；4. 推理过程由引擎统一调度，构件仅负责提供事实数据。 | 业务规则配置系统、保险理赔规则引擎、电商优惠券规则系统、专家系统 | 有规则库 + 推理引擎，按条件匹配触发逻辑判定，就是规则系统风格 | |
| ⑤独立构件风格 | 进程通信体系结构风格 | 进程、线程、IPC（进程间通信）、消息、共享内存 | 1. 每个构件对应一个独立进程/线程，可并发执行；2. 构件之间通过IPC（消息队列、共享内存等）进行通信；3. 构件独立部署、独立故障隔离，一个构件异常不影响其他构件；4. 通信方式由系统统一管理，构件专注自身业务逻辑。 | 分布式系统中的进程交互、多线程应用（如后台任务进程）、操作系统中进程通信 | 多独立进程、彼此通过消息 / IPC 交互协作，就是进程通信架构风格 |
| 事件系统体系结构风格（事件驱动/隐式调用） | 构件、事件、事件源（发布者）、事件处理者（订阅者）、事件总线 | 1. 构件间不直接调用，通过事件总线传递事件触发通信；2. 发布者不知道订阅者，订阅者不知道发布者，松耦合；3. 事件触发顺序不由调用者控制，由事件总线调度；4. 一个事件可被多个处理者响应，支持异步处理。 | GUI界面（按钮点击/菜单触发事件）、消息队列（MQ）订阅发布模式、实时通知系统、微服务异步通信 | 事件触发、异步解耦、发布订阅、无需硬编码调用 |
企业 & 互联网架构风格
| 架构风格 | 场景关键词 | 典型场景 |
|---|---|---|
| MVC/MVVM | 视图、模型、控制器分离、界面与业务解耦 | Web、桌面端、移动端 UI 架构 |
| SOA 面向服务架构 | ESB 企业服务总线、粗粒度服务、系统集成、服务复用 | 传统企业异构系统整合、遗留系统对接 |
| 微服务架构 | 服务自治、独立部署、去中心化、API 网关、故障隔离、弹性扩容 | 电商、互联网平台、大型分布式业务系统 |
| 闭环反馈控制 | 采集-比对-调节-反馈、动态修正、自动控制 | 工业控制、自动驾驶、温控调速系统 |