软件架构风格

1. 概述

1. 核心目标：重复的体系结构模式（软件复用/重用）
2. 软件体系结构（架构）风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义一个系统家族（一类架构所共有的特征），即一个体系结构定义一个词汇表和一组约束。主要包括以下三部分：
   1. 架构定义：
   2. 架构词汇表：包含构件和连接件
   3. 架构约束：约束定义构件和连接件的组合方式
3. 体系结构风格反映了领域中众多系统所 共有的结构和语义特性，强调对 架构设计 的重用，并指导如何将各个模块和子系统有效地组织成一个完整的系统

2. 数据流体系结构风格（Data Flow）

2.1 批处理

1. 概念：
   1. 作业一次性提交，按照既定的顺序，批量地处理数据，每个处理步骤都是独立的程序（中间的每次结果都会落盘）每一步必须在前一步结束后才能开始，且数据必须完整，以整体的方式传递
   2. 构件：独立的应用程序
   3. 连接件：某种类型的媒介
2. 特点：数据驱动，成批提交，大量整体数据，没有人工干预，实时性差
3. 例子：分布式大数据的离线作业、银行的审批系统（夜间跑批）、传统的编译器（各阶段按顺序批处理）

2.2 管道 - 过滤器

1. 概念：
   1. 把系统分为几个序贯的处理步骤，每个步骤之间通过数据流连接，一个步骤的输出是另一个步骤的输入， 每个步骤都有输入和输出，并且 可以独立存储。
   2. 基本构件：过滤器（用于缓冲、同步）
   3. 连接件：数据流传输通道
2. 流程：「读端口」获取需要处理的信息，通过管道传递给过滤器链，每个过滤器自行判断是否需要对信息进行处理，一个过滤器处理完后通过管道将消息传递给下一个或多个过滤器，直到所有的过滤器全部处理完毕，通过写端口，将处理完成的信息写出到目标位置。
3. 特点：
   1. 优点：高内聚低耦合，良好的重用性和复用性，支持并行
   2. 缺点：交互性差，复杂度较高，性能较差
4. 例子：网络报文处理、传统编译器

3. 调用 / 返回体系结构风格

3.1 主程序 / 子程序

1. 概念：
   1. 单线程控制，主程序显式的调用若干子程序来完成计算
   2. 构件：主程序和子程序
   3. 连接件：过程调用作为交互机制，即充当连接件
2. 原理：调用栈 会保存返回的地址，参数按值或引用传递
3. 特点：调用关系具有层次性（跟栈的调用层次一样），适合 静态、预定义 的处理过程
4. 例子：编程语言的 main 函数

3.2 面向对象

1. 概念：
   1. 系统由封装了 数据 和 行为 的对象组成，通过 消息 进行协作
   2. 构件：对象，或者是抽象数据类型的实例
   3. 连接件：过程调用
2. 特点：利用类对象，通过封装、继承、多态，实现复用与扩展
3. 例子：Java 电商系统

3.3 层次型（Layered System）

1. 概念：
   1. 将系统按照 抽象级别 分为若干层（越宏观越抽象），各层只会依赖它的下层。每一层为上层服务，并作为下层的客户。处理特殊的输出函数外，内部的层接口只对相邻的层可见
   2. 构件：每层的层次系统
   3. 连接件：决定层间交互的协议
2. 特点：良好的 可复用性
3. 缺点：每一层都依赖上一层，数据需逐层传递，增加了通信和处理的开销，可能造成性能下降
4. 例子：TCP/IP 五层协议，Spring（Web、Service、DAO 三层）

3.4 客户端 / 服务器（C/S）

3.4.1 二层 C/S 模式

1. 概念：基于资源不对等，且为实现共享而提出的
2. 组成部分：
   1. 数据库服务器：作为后台，负责数据管理
   2. 客户应用程序：作为前台，完成与用户的交互任务
   3. 网络：
3. 特点：
   1. 胖客户机，瘦服务器
   2. 优点：客户应用和服务器构件分别运行在不同的计算机上
   3. 缺点：开发成本高，客户端设计复杂，移植成本高，软件维护和升级困难

3.4.2 三层 C/S 模式

1. 概念：增加一个应用服务器
2. 组成部分：
   1. 数据库服务器
   2. 应用服务器
   3. 工作站
   4. 网络
3. 应用功能分为三层：
   1. 表示层：用户接口与应用逻辑层的交互，不影响业务逻辑，通常使用图形用户界面
   2. 功能层：实现具体的业务处理逻辑
   3. 数据层：数据库管理系统
4. 特点：
   1. 瘦客户机
   2. 整个应用逻辑在应用服务器上，只有表示层在客户机上

3.5 浏览器 / 服务器（B/S）

1. 概念：
   1. 是三层应用结构的实现方式，是一种特殊的三层 C/S 架构
   2. 三层结构分别为：浏览器、Web 服务器、数据库服务器
2. 特点：
   1. 相比于 C/S 的不足：动态页面的支持能力弱，系统拓展能力差，安全性难以控制，响应速度不足，数据交互性不强
3. 例子：Web 网站

3.6 SOA 风格

1. 概念：
   1. 面向服务的架构（Service Oriented Architecture）
   2. 系统由自制可复用的服务组成，通过标准的契约进行交互
2. 特点：集中式管理，

3.7 微服务

1. 概念：
   1. 把一个整体拆成一小组各种各样的服务
2. 特点：去中心化，容器化，自动部署服务网络，每个服务都有自己独立的进程和独立的数据库
3. 例子：复杂的电商系统

3.8 REST

1. 概念：
   1. Represent tational state transfer，表述性状态传递
   2. 面向资源的一种架构风格，用统一接口去操作资源
2. 原理：无状态，可缓存资源，URL 唯一，超媒体驱动

4. 以数据为中心的体系结构风格（仓库风格）

4.1 数据库系统（仓库体系）

1. 概念：
   1. 所有的构件都围绕一个 共享数据库 进行 CRUD 操作，构件之间没有直接调用。仓库 是存储和维护数据的中心场所
   2. 构件：
      1. 中央数据结构：是系统中的核心仓库，用于保存和说明当前的数据状态，是所有操作的共享数据中心
      2. 一组独立构件：是一组对中央数据进行读写操作的模板，它们之间不直接通信，只通过中央数据结构进行协作
   3. 连接件：仓库与独立构件之间的交互
2. 特点：也称 数据共享 风格，共享工程数据
3. 例子：ERP 系统，各种数据库，IDE（集成开发环境，其中心数据是程序的语法树）

4.2 黑板风格

1. 概念：
   1. 核心机制是所有模块通过一个公共的数据结构——“黑板”进行通信与协作
   2. 一种 问题求解 模型，通过共享黑板上的数据，多个知识源去异步地读写黑板上的东西
   3. 每个 知识模块 是自治的，能够在某一层次的信息基础上生成其他层的信息，完成部分问题求解
2. 原理：控制模块 监控 黑板上的变化，协调知识源何时读写黑板，实现并行推理
3. 特点：对于特定应用问题，可通过选取各种黑板、知识源和控制模块的构件来设计，也可以利用预先定制的黑板体系结构的编程环境
4. 缺点：依赖于多个知识源协同工作解决问题，若某些关键知识源缺失，可能导致系统无法做出决策或得出结果
5. 例子：信号处理领域，语音识别 和 模式识别，知识推理等复杂问题，松耦合代理数据共享存取

4.3 超文本系统

1. 概念：
   1. 类似于网页的超链接，信息都是以节点和链接的方式组织的，用户可以非线性浏览
2. 例子：HTML、URL

5. 虚拟机体系结构风格

认为构建一个运行环境，可以解析与运行自定义的一些语言，增加架构的灵活性。

5.1 解释器

1. 概念：
   1. 用软件引擎去解释执行高级语言或脚本
   2. 通常被用来建立一种虚拟机以弥合程序语义与硬件语义之间的差异
2. 定义：解释器风格是一种动态解析并执行特定语言或规则的软件架构风格，它是在程序运行的时候逐行或逐段地去解析代码的语法语义，再转化为可执行操作，并实时执行。
3. 原理：类似于词法分析、语法分析、语义分析，逐条地解释字节码的过程
4. 特点：
   1. 执行效率低，可以 自定义规则，更灵活，满足 业务功能灵活组合 的需求
   2. 适合 系统需要解析执行用户 自定义规则 的场景，具备一定的 可拓展性与动态行为解析能力。
5. 例子：JVM，Python 解释器，专家系统，游戏系统

5.2 规则系统（Rule-based System）

1. 概念：
   1. 把规则给具象地写成各种各样的机器执行规则，由推理机执行
2. 组成部分：
   1. 规则集，规则解释器，规则/数据选择器，工作内容（程序运行存储区）
3. 原理：正向或反向的链式推理，包括各种匹配、冲突解决、执行循环等过程
4. 特点：
   1. 在解释器的基础上增加经验规则，更适用于专家系统
   2. 通过规则解释机，根据预定义规则和运行时环境，动态 决策任务执行顺序，适合 需要响应环境变化和突发事件 的系统
5. 例子：Drois 规则引擎，专家系统，医疗专家系统
6. 既定条件对应某种策略，类似 if ... else ... 规则系统或专家系统

6. 独立构件体系结构风格（事件/消息）

强调系统中的每个构件都是相对独立的个体，它们之间不直接通信，以降低耦合度，提升灵活性。

6.1 事件驱动系统（隐式调用）

1. 概念：
   1. 构件发布事件，其他构件通过注册 监听 器被动地响应
   2. 思想：构件不直接调用一个过程，而是 触发或广播 一个或多个事件
   3. 构件：一些模块，可以是一些过程，也可以是一些事件的集合
   4. 连接件：事件管理器，用于分发或通知消息
2. 原理：基于事件的 隐式调用风格 的思想，松耦合调用关系，调用关系由事件总线在运行时动态绑定
3. 特点：事件的触发者并不知道哪些构件会被这些事件影响
4. 缺点：事件的触发顺序可能不可控，容易引发状态不一致或难以调试等问题
5. 例子：发布订阅机制

6.2 进程通信

1. 概念：
   1. 系统由多个独立的进程（构件）组成，进程之间通过 显式的消息传递 进行协作。
   2. 构件：独立的进程，具备自主执行的能力，运行于不同的上下文
   3. 连接件：消息传递，是实现进程间通信的机制，支持进程之间通过发送和接收消息来实现数据交换与协同工作。消息传递的方式可以是同步或异步、点对点或广播、本地或远程
2. 原理：OS 提供 IPC 机制，指各种可以传递消息的东西（管道、消息队列、共享内存、Socket）
3. 特点：构件通常是命名过程，消息传递的方式可以是点到点、异步或同步的方式及远程过程调用等
4. 例子：微服务之间用 GRPC（HTTP）调用，服务器与数据库之间的调用

7. 闭环控制风格

7.1 过程控制

1. 概念：
   1. 持续地检测被控对象，通过 反馈算法 去调整它的输出
2. 原理：先传感器采样控制，接着控制器计算，然后执行器输出，再次采样形成一个闭环
3. 特点：
   1. 通过左右协调系统中的变量，让系统达成一个稳定的状态
   2. 适用于嵌入式系统，用于解决简单闭环控制系统（变量少）
4. 例子：空调温控，定速巡航

8. C2 风格

1. 概念：
   1. 一种并行构件网络架构风格，构件通过连接件按照一组规则绑定在一起运行
   2. 构件仅通过连接件通信，禁止构件间直接依赖
2. 原理：顶部和底部接口分离，实现动态增删构件
3. 特点：
   1. 构件和连接件都有一个顶部和一个底部
   2. 构件的顶部连接到连接件底部，构件的底部连接到连接件顶部，构件之间不允许直连
   3. 一个连接件可以连接多个构件或其他连接件
   4. 当两个连接件直接连接时，必须一个的底部连接到另一个的顶部
4. 例子：GUI 可视化操作界面中的可视化控件和事件总线做分离

9. 架构模式

9.1 概念

1. 架构风格：是指出一种反复出现的架构设计，与模式相反，他的存在并不是为了“解决”某个问题
2. 架构模式：用于解决一种反复出现的与 架构风格相关的问题。是软件设计中的 高层决策，反映了开发软件系统过程中所作的基本设计决策。
3. 设计模式：主要关注 软件系统的设计，与具体的实现语言无关。解决的问题更局限。

模式：是一种针对反复出现的问题的固有的解决方案

9.2 关系

1. 架构风格是一种抽象而架构模式是抽象的一种具体实现
2. 一个单体架构可以包含多种架构风格，而每种架构风格可以使用多种架构模式
3. 一种架构模式也可以使用多种设计模式

名称	解释	作用范围
架构风格	抽象级别最高的应用程序设计	广
架构模式	实现架构风格的一种方式	一般
设计模式	解决局部问题的一种方式	窄

9.3 惯用法

1. 是实现时通过某种特定的程序设计语言来描述构件与构件之间的关系，最低层次。

9.4 包装器外观（Wrapper Facade）架构模式

1. 解决操作系统的差异问题。
   1. 具体来说，服务端程序应该在包装器外观的实例上调用需要的方法，然后将请求和请求的参数发送给操作系统 API 函数，调用成功后将结果返回。
   2. 使用该模式提高了底层代码访问的一致性，但降低了服务端程序的调用性能。
2. 特点：封装统一请求，增加调用层级