Appearance
软件架构风格概述
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。
架构设计的一个核心问题是能否达到架构级的软件复用。
架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个架构定义、一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，这组约束指出系统如何将这些构件和连接件组合起来。
核心要点：
- 架构风格反映了领域中众多系统所共有的结构和语义特性
- 指导如何将各个模块和子系统有效组织成完整系统
- 架构设计的核心问题是能否达到架构级的软件复用
- 架构风格定义了用于描述系统的术语表和一组指导构建系统的规则
基本架构风格
五大架构风格分类 ★
| 风格类别 | 核心特点 | 代表 |
|---|---|---|
| 数据流风格 | 面向数据流，按顺序从前向后执行 | 批处理序列、管道-过滤器 |
| 调用/返回风格 | 构件间存在显式调用关系 | 主程序/子程序、面向对象、层次结构 |
| 独立构件风格 | 构件独立，通过事件/异步触发 | 进程通信、事件驱动（隐式调用） |
| 虚拟机风格 | 自定义规则供使用者使用，跨平台适配 | 解释器、基于规则的系统 |
| 仓库风格 | 以数据为中心，所有操作围绕数据中心 | 数据库系统、超文本系统、黑板系统 |
数据流风格
批处理序风格
- 构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互
- 每个处理步骤是独立程序，每一步必须在前一步结束后才能开始
- 数据必须是完整的，以整体方式传递
- 前后构件不一定有关联
批处理风格：每个处理步骤是一个单独的程序，每一步必须在前一步结束后才能开始，并且数据必须是完整的，以整体的方式传递。
它的。连接件定义了相应的数据流图，表达拓扑结构。
管道-过滤器
- 每个构件有一组输入输出，读取输入数据流，处理后产生输出数据流
- 前一个构件的输出作为后一个构件的输入，前后数据流关联
- 过滤器 = 构件，管道 = 连接件
- 早期编译器采用此风格
管道-过滤器：把系统分解为几个序贯的处理步骤，这些步骤之间通过数据流连接，。
每个处理步骤由一个过滤器(Filter)实现，处理步骤之间的数据传输由管道(Pipe)负责。，将一个过滤器的输出传到另一过滤器的输入。
二者区别：批处理前后构件不一定关联且作为整体传递（必须前一个执行完）；管道-过滤器是前一个输出作为后一个输入（前面执行到部分即可开始下一个）。
调用/返回风格
主程序/子程序
主程序/子程序： 单线程控制，把问题划分为处理步骤，构件即主程序和子程序，过程调用作为交互机制。
主程序/子程序：单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。。
面向对象
面向对象： 构件是对象（抽象数据类型的实例），连接件是对象间交互方式（函数和过程调用）。
面向对象：构件是对象，对象是抽象数据类型的实例。连接件即使对象间交互的方式，对象是通过函数和过程的调用来交互的。
以数据为中心的架构风格
| 类型 | 组成与特点 | 应用领域 |
|---|---|---|
| 数据库系统 | 中央共享数据源 + 多个独立处理单元 | 通用数据管理 |
| 黑板系统 | 知识源 + 黑板（全局数据库）+ 控制 | 信号处理、问题规划、编译器优化等无确定性算法的场景 |
| 超文本系统 | 网状链接，用户可按联想跳转 | 互联网 |
现代编译器的集成开发环境一般采用数据仓库（以数据为中心的架构风格）进行开发，中心数据即程序的语法树。
仓库架构风格
仓库架构风格：。在仓库体系结构风格中，有两种不同的构件：，仓库与独立构件间的相互作用在系统中会有大的变化。
这种风格的。
黑板架构风格
黑板架构风格：适用于，使得问题的表达、组织和求解变得比较容易。
黑板系统是一种，是组织推理步骤、控制状态数据和问题求解之领域知识的概念框架。
它。各种应用通过不同知识表达方法、推理框架和控制机制的组合来实现。一般包括三部分。
黑板系统的传统应用是。另一应用是。
虚拟机风格
解释器
解释器：通常包括。
具有解释器风格的软件中含有一个虚拟机，可以，缺点是。典型的例子是专家系统。
- 组成：完成解释工作的解释引擎 + 存储被解释代码的存储区 + 记录引擎工作状态的数据结构 + 记录执行进度的数据结构
- 缺点：执行效率低
基于规则的系统
基于规则的系统：包括，一般用在人工智能领域和DSS中。
- 组成：规则集、规则解释器、规则/数据选择器、工作内存
- 一般用在**人工智能领域和 DSS（决策支持系统）**中
- 适合业务规则频繁变化的场景
考题套路：业务灵活组合、自定义规则 → 虚拟机风格。其中规则系统偏向专家系统，解释器偏向自定义逻辑执行。
独立构件风格
进程通信
进程通信： 构件是独立的进程，连接件是消息传递。消息传递方式：点对点、异步/同步、远程过程调用等。
事件驱动系统（隐式调用）
事件驱动系统（隐式调用）：事件系统风格基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册，程。
从架构上说，这种风格的，这些模块既可以是一些过程，又可以是一些事件的集合。，也可以在系统事件中注册一些过程，当发生这些事件时，过程被调用。
主要优点是；缺点是构件。
事件驱动系统（隐式调用）：
- 构件不直接调用过程，而是触发或广播一个或多个事件
- 构件中的过程在事件中注册，事件触发时系统自动调用注册的过程
- 优点：为软件复用提供强大支持，便于构件维护和演化
- 缺点：构件放弃了对系统计算的控制
【理解就是事件，注册事件后，别人直接可以多个地方调用触发】
闭环控制（过程控制）风格
当软件被用来操作一个物理系统时，软件与硬件之间粗略表示为一个反馈循环。通过接受一定输入，确定一系列输出，最终使环境达到新状态。适合于嵌入式系统，涉及连续的动作与状态。
典型场景：空调温控、轿车巡航定速、机器人运动控制等需要持续测量-比较-调节的场景。
C2 体系结构风格
C2 风格概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。
组织规则：
- 系统中的构件和连接件都有一个顶部和一个底部
- 构件的顶部应连接到某连接件的底部，构件底部应连接到某连接件的顶部，构件与构件之间不允许直接连接
- 一个连接件可以和任意数目的其它构件和连接件连接
- 两个连接件直接连接时，必须由其中一个的底部到另一个的顶部
层次结构风格
层次结构：
- 构件组成层次结构，每层为上一层提供服务，使用下一层服务
- 只能见到与自己邻接的层
- 修改某一层，最多影响相邻两层（通常只影响上层）
| 优点 | 缺点 |
|---|---|
| 支持基于可增加抽象层的设计，可将复杂问题分解为增量步骤 | 并非每个系统都可划分为分层模式 |
| 不同层次处于不同抽象级别 | 很难找到合适的层次抽象方法 |
| 只要相邻层接口相同，每层可用不同方法实现，支持软件复用 | 层次通信效率相对较低（需从高到低再回到高） |
分层架构两大脆弱性：底层错误会导致整个系统无法正常运行；层间引入通信机制会造成性能下降。
C/S、B/S 与多层架构
两层 C/S 架构
客户端/服务器架构风格：两层C/S体系结构有3个主要组成部分：数据库服务器、客户应用程序和网络。称为“胖客户机，瘦服务器”
- 客户端和服务器都有处理功能，现已不常用
- 缺点：开发成本高、客户端复杂、维护升级困难、安全性问题、难以复用
三层 C/S 架构
三层C/S结构。整个应用逻辑驻留在应用服务器上，只有表示层存在于客户机上，故称为“瘦客户机”。应用功能分为。
- 表示层（客户机）+ 功能层（应用服务器）+ 数据层（数据库服务器）
- 将处理功能独立出来
| 优点 |
|---|
| 各层逻辑独立，系统结构清晰，提高可维护性和可扩展性 |
| 允许灵活选用相应平台和硬件，良好的可升级性和开放性 |
| 各层可并行开发，可选用各自最适合的开发语言 |
| 功能层有效隔离表示层与数据层，安全管理层次更合理可控 |
三层 C/S 关键在于各层之间的通信效率，要慎重考虑通信方法、通信频度和数据量。
三层 B/S 架构
- 三层 C/S 的变种：客户端变为浏览器，应用服务器变为 WEB 服务器
- 又称0 客户端架构
- 缺点：缺乏动态页面支持、安全性难控制、响应速度远低于 C/S、数据动态交互性不强
混合架构
- 内外有别模型：内部 C/S，外部 B/S
- 查改有别模型：B/S 查询，C/S 修改
- 缺点：实现困难且成本高
富互联网应用（RIA）
- 弥补 B/S 架构问题，本质还是网站模式
- 结合 C/S 反应速度快、交互性强 + B/S 传播范围广
- 数据能缓存在客户端，减少服务器往返
- 本质仍是 0 客户端，借助高速网速实现必要插件本地快速缓存（如小程序）
MVC / MVP / MVVM
MVC
MVC 架构：
| 组件 | 职责 |
|---|---|
| 控制器（Controller） | 处理用户交互，从视图读取数据，控制用户输入，向模型发送数据 |
| 模型（Model） | 处理应用程序数据逻辑，负责数据库存取，表示业务数据和业务逻辑 |
| 视图（View） | 处理数据显示，用户看到并交互的界面，不进行实际业务处理 |
MVP
MVP： 将 MVC 的 Controller 换为 Presenter（呈现），完全切断 View 与 Model 的联系，由 Presenter 充当桥梁。View 非常薄（被动视图），Presenter 非常厚（所有逻辑）。
MVVM
MVVM：
- 低耦合：View 可独立于 Model 变化，一个 ViewModel 可绑定到不同 View
- 可重用性：视图逻辑放在 ViewModel 中，多个 View 重用
- 独立开发：开发人员专注业务逻辑，设计人员专注页面
- 可测试：测试可针对 ViewModel 编写
J2EE 四层结构
- ：J2EE应用程序可以是基于web方式的，也可以是基于传统方式的静态的HTML(标准通用标记语言下的一个应用)页面和Applets是客户层组件
- ：J2 EE web层组件可以是 JSP页面或Servlet。.
- ：业务层代码的逻辑用来满足特定领域的业务逻辑处理。
- ：企业信息系统层处理企业信息系统软件包括企业基础建设系统例如企业资源计划(ERP),大型机事务处理，数据库系统，和其它的遗留信息系统.例如，J2EE应用组件可能为了数据库连接需要访问企业信息系统。
JSP+Servlet+JavaBean+DAO
- JSP:用于显示、收集数据的部分。作为MVC中的视图V。
- Servlet:作为业务逻辑层，用于处理复杂的业务逻辑，如验证数据、实例化JavaBean、调用DAO连接数据库等。作为MVC中的控制器C。在其中会调用Service:方法处理服务。
- JavaBean:用于数据的封装，方便将查询结果在servlet.与jsp页面之间进行传递等。
- DAO:用于连接数据库及进行数据库的操作如：查询、删除、更改等。
- 基本流程：JSP发一个数据到servlet,servlet收到后做下解析再根据数据调用相应的 service去服务，service如果有要调用数据库就通过DAO跟数据库交互，使用 javaBean完成封装，返回结果给 servlet,servleti再返回给 JSP。
面向服务的架构 SOA
SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。
在SOA中，服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。
SOA并不仅仅是一种开发方法，还具有管理上的优点，管理员可直接管理开发人员所构建的相同服务。多个服务通过企业服务总线提出服务请求，由应用管理来进行处理x
SOA（面向服务架构）核心要点
一、实施 SOA 的关键目标
- 。
二、SOA 的典型特征
可从企业外部访问
随时可用（服务请求能被及时响应）
粗粒度接口（粗粒度提供一项特定的业务功能，细粒度服务代表技术构件方法）
服务分级
松散耦合（服务提供者和服务使用者分离）
可重用的服务及服务接口设计管理
支持各种消息模式
精确定义的服务接口
演进趋势：从基于对象 → 基于构件 → 基于服务，架构越来越松散耦合，粒度越来越粗，接口越来越标准。
SOA 关键技术
| 功能 | 协议 |
|---|---|
| 发现服务 | UDDI、DISCO |
| 描述服务 | WSDL、XML Schema |
| 消息格式层 | SOAP、REST |
| 编码格式层 | XML（DOM、SAX） |
| 传输协议层 | HTTP、TCP/IP、SMTP 等 |
1. 发现服务 UDDI
- UDDI：用于，描述服务的概念，定义编程接口，供其他企业调用。
- DISCO：发现公开服务的功能及交互协议。
2. 描述服务 WSDL
- WSDL（Web 服务描述语言）：用于，描述网络服务。
3. 消息格式层 SOAP
- SOAP：。
- REST（表述性状态转移）：只使用 HTTP 和 XML 进行基于 Web 通信的技术，可降低开发复杂性，提高系统可伸缩性。
4. 编码格式层
- XML（可扩展标记语言）：用于标记电子文件使其，是一种允许用户对自己的标记语言进行定义的源语言。
练习题
SOA 的实现方式
Web Service
三个角色：
- 服务提供者
- 服务注册中心（中介，提供交易平台，可有可无）
- 服务请求者
交互流程：
- 服务提供者将服务描述发布到服务注册中心。
- 服务请求者查找服务。
- 服务请求者绑定查找结果，调用服务。
六层协议栈：
| 层次 | 作用 | 协议示例 |
|---|---|---|
| 底层传输层 | 负责底层消息的传输 | HTTP、JMS、SMTP |
| 服务通信协议层 | 描述并定义服务间通信的技术标准 | SOAP、REST |
| 服务描述层 | 描述服务的接口和操作功能 | WSDL |
| 服务层 | 对企业应用系统进行包装，通过 WSDL 定义的标准进行调用 | - |
| 业务流程层 | 支持服务发现、服务调用和点到点的服务调用 | WS-BPEL（原文本写WSDpEL） |
| 服务注册层 | 服务的发布与查找 | UDDI |
服务注册表
- 本质与 Web Service 类似，但使用注册表代替服务注册中心。
- 服务注册：应用开发者（服务提供者）在注册表中公布服务功能。
- 服务位置：服务使用者（服务应用开发者）查询注册服务，寻找符合要求的服务。
- 服务绑定：服务使用者利用检索到的服务接口编写代码，与注册的服务绑定、调用、互动。
企业服务总线（ESB）
组成：客户端（服务请求者）、基础架构服务（中间件）、核心集成服务（提供服务）。
本质：通过网络实现集成。
六大功能：
- 提供位置透明性的消息路由和寻址服务
- 支持多种消息传递范型
- 支持多种可以广泛使用的传输协议
- 支持多种数据格式及其相互转换
- 提供日志和监控功能
软件架构复用
软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的。即围绕核心资产库进行管理、复用、集成新的系统。
软件架构复用的类型包括机会复用和系统复用。
- 机会复用是指开发过程中，只要发现有可复用的资产，就对其进行复用。
- 系统复用是指在开发之前，就要进行规划，以决定哪些需要复用。
可复用的资产包括：需求、架构设计、元素、建模与分析、测试、项目规划、过程方法和工具、人员、样本系统、缺陷消除。
复用的基本过程主要包括3个阶段：首先构造/获取可复用的软件资产，其次管理这些资产（构件库)，最后针对特定的需求，从这些资产中选择可复用的部分，以开发满足需求的应用系统。
其他
专家系统（ES）与决策支持系统（DSS）
🎯 ES 的根本区别于一般计算机系统在于解释推理过程；DSS 主要用于解决半结构化问题。
核心区分：
| 系统 | 解决问题类型 | 核心特征 | 常用架构风格 |
|---|---|---|---|
| 专家系统（ES） | 依赖领域知识推理的复杂问题 | 能解释推理过程 | 规则系统 |
| 决策支持系统（DSS） | 半结构化问题 | 辅助决策而非替代人 | 规则系统 |
⚠️ 常见坑：ES 不是处理确定性知识，而是能解释推理过程。DSS 处理的是半结构化问题（不是纯结构化、不是日常事务处理）。
架构风格与系统性能关系
🎯 核心结论：层次越多性能越差；隐式调用可通过并发调用提高性能；面向对象引入对象管理层会降低性能（不是提高）。
| 风格 | 对性能的影响 | 原因 |
|---|---|---|
| 层次化架构 | 层次划分越多，性能越差 | 每次调用需穿过多个层次 |
| 隐式调用（事件驱动） | 可通过处理函数的并发调用提高性能 | 事件可并行处理 |
| 面向对象 | 引入对象管理层会降低性能 | 增加间接调用层次 |
| 解释器 | 可通过对部分解释代码预先编译提高性能 | 减少运行时解释开销 |
⚠️ 常见坑：" 面向对象风格可通过引入对象管理层提高系统性能"是错误的，实际上会降低性能。