系统架构师 —— 系统架构设计

目录

[一、软件架构基本概念与架构描述语言 ADL](#一、软件架构基本概念与架构描述语言 ADL)

[1.1 软件架构基本概念](#1.1 软件架构基本概念)

[1.1.1 软件架构的核心构成：构件与连接件](#1.1.1 软件架构的核心构成：构件与连接件)

[1.1.1.1 构件Component](#1.1.1.1 构件Component)

[1.1.1.2 连接件 Connector](#1.1.1.2 连接件 Connector)

[1.1.2 架构配置 Configuration](#1.1.2 架构配置 Configuration)

[1.1.3 接口 Interface](#1.1.3 接口 Interface)

[1.1.4 小结](#1.1.4 小结)

[1.2 架构描述语言 （ADL，Architecture Description Language）](#1.2 架构描述语言 （ADL，Architecture Description Language）)

[1.3 真题](#1.3 真题)

[1.3.1 （2013 年）软件系统架构 = 结构 + 行为 + 属性](#1.3.1 （2013 年）软件系统架构 = 结构 + 行为 + 属性)

[1.4 总结](#1.4 总结)

[1.4.1 易错点](#1.4.1 易错点)

[二 、经典软件架构风格](#二 、经典软件架构风格)

[2.1 数据流体系结构风格](#2.1 数据流体系结构风格)

[2.1.1 批处理 Batch Sequential](#2.1.1 批处理 Batch Sequential)

[2.1.2 管道---过滤器 Pipe and Filter](#2.1.2 管道—过滤器 Pipe and Filter)

[2.1.3 数据流风格真题题眼](#2.1.3 数据流风格真题题眼)

[2.2 调用/返回体系结构风格](#2.2 调用/返回体系结构风格)

[2.2.1 主程序---子程序](#2.2.1 主程序—子程序)

[2.2.2 面向对象风格](#2.2.2 面向对象风格)

[2.3 层次型 Layered](#2.3 层次型 Layered)

[2.3.1 C/S：Client / Server](#2.3.1 C/S：Client / Server)

[2.4 以数据为中心的体系结构风格](#2.4 以数据为中心的体系结构风格)

[2.4.1 仓库风格（Repository）](#2.4.1 仓库风格（Repository）)

[2.4.2 黑板风格（Blackboard）](#2.4.2 黑板风格（Blackboard）)

[2.5 虚拟机风格](#2.5 虚拟机风格)

[2.5.1 解释器风格（Interpreter）](#2.5.1 解释器风格（Interpreter）)

[2.5.2 规则系统（Rule-based System）](#2.5.2 规则系统（Rule-based System）)

[2.5.3 解释器风格与规则系统区分](#2.5.3 解释器风格与规则系统区分)

[2.6 独立构件体系结构风格](#2.6 独立构件体系结构风格)

[2.6.1 进程通信（Process Communication）](#2.6.1 进程通信（Process Communication）)

[2.7 C2 体系结构风格（高频考点）](#2.7 C2 体系结构风格（高频考点）)

[2.8 总结](#2.8 总结)

[2.8.1 真题题眼总结](#2.8.1 真题题眼总结)

三、基于体系结构的软件设计（ABSD）

[3.1 ABSD 的驱动源与三大基础](#3.1 ABSD 的驱动源与三大基础)

[3.2 ABSD 中的视角与视图](#3.2 ABSD 中的视角与视图)

[3.3 ABSD 的生命周期六大子过程（ABSDM）](#3.3 ABSD 的生命周期六大子过程（ABSDM）)

[3.3.1 体系结构需求](#3.3.1 体系结构需求)

[3.3.2 体系结构设计](#3.3.2 体系结构设计)

[3.3.3 体系结构文档化](#3.3.3 体系结构文档化)

[3.3.4 体系结构复审](#3.3.4 体系结构复审)

[3.4 易错点总结](#3.4 易错点总结)

[四、Kruchten 4+1 视图模型及多视图演进](#四、Kruchten 4+1 视图模型及多视图演进)

[4.1 Kruchten 经典 4+1 视图映射矩阵](#4.1 Kruchten 经典 4+1 视图映射矩阵)

[4.2 其它多视图流派（考辨析）](#4.2 其它多视图流派（考辨析）)

[4.2.1 Hofmeister 4 视图模型](#4.2.1 Hofmeister 4 视图模型)

[4.2.2 CMU-SEI Views and Beyond (V&B)](#4.2.2 CMU-SEI Views and Beyond (V&B))

[4.2.3 总结](#4.2.3 总结)

[4.3 真题](#4.3 真题)

[4.3.1（ 2014年）"4+1"视图模型 及 UML 建模工具](#4.3.1（ 2014年）"4+1"视图模型 及 UML 建模工具)

五、软件质量属性与质量属性场景

[5.1 软件质量属性](#5.1 软件质量属性)

[5.1.1 开发期质量属性](#5.1.1 开发期质量属性)

[5.1.2 运行期质量属性](#5.1.2 运行期质量属性)

[5.1.3 易混淆点](#5.1.3 易混淆点)

[（1）可扩展性 vs 可伸缩性](#（1）可扩展性 vs 可伸缩性)

[（2）可移植性 vs 互操作性](#（2）可移植性 vs 互操作性)

（3）可靠性、可用性、鲁棒性

[（4）可维护性 vs 可修改性](#（4）可维护性 vs 可修改性)

[（5）性能 vs 可用性](#（5）性能 vs 可用性)

[5.2 质量属性场景](#5.2 质量属性场景)

场景举例

（1）以购物系统写一个完整性能场景

（2）以购物系统写一个可用性场景

（3）以购物系统写一个可修改性场景

[5.3 真题（属性和应对策略）](#5.3 真题（属性和应对策略）)

核心质量属性与高频架构战术对应表

六、架构评估方法

[6.1 评估的核心技术概念](#6.1 评估的核心技术概念)

[6.2 三类架构评估方法](#6.2 三类架构评估方法)

[6.2.1 基于调查问卷/检查表的方法（Questionnaire/Checklist-based）](#6.2.1 基于调查问卷/检查表的方法（Questionnaire/Checklist-based）)

[6.2.2 基于场景的方法（Scenario-based，核心主流）](#6.2.2 基于场景的方法（Scenario-based，核心主流）)

[（1）软件体系结构分析方法（SAAM，Scenario-Based Architecture Analysis Method）](#（1）软件体系结构分析方法（SAAM，Scenario-Based Architecture Analysis Method）)

[（2）架构权衡分析方法（ATAM，Architecture Tradeoff Analysis Method）](#（2）架构权衡分析方法（ATAM，Architecture Tradeoff Analysis Method）)

[（3）成本效益分析方法（CBAM，Cost Benefit Analysis Method）](#（3）成本效益分析方法（CBAM，Cost Benefit Analysis Method）)

[6.2.3 基于度量的方法（Metrics-based，2024.11 考点）](#6.2.3 基于度量的方法（Metrics-based，2024.11 考点）)

[6.2.4 评估方法对比](#6.2.4 评估方法对比)

[6.3 其他架构评估方法](#6.3 其他架构评估方法)

七、软件架构复用

[7.1 两种复用类型：机会复用 vs 系统复用](#7.1 两种复用类型：机会复用 vs 系统复用)

[7.2 软件架构复用的三个基本过程](#7.2 软件架构复用的三个基本过程)

[7.3 真题考察点](#7.3 真题考察点)

[八、特定领域软件体系结构 DSSA](#八、特定领域软件体系结构 DSSA)

[8.1 特定领域软件架构（DSSA，Domain-Specific Software Architecture）](#8.1 特定领域软件架构（DSSA，Domain-Specific Software Architecture）)

总结

[8.2 DSSA 与软件架构复用](#8.2 DSSA 与软件架构复用)

[九、面向服务架构 SOA](#九、面向服务架构 SOA)

[9.1 SOA 的主要设计原则](#9.1 SOA 的主要设计原则)

[9.2 Web Service](#9.2 Web Service)

[9.3 ESB](#9.3 ESB)

[9.4 微服务](#9.4 微服务)

[9.4.1 微服务断路器模式（Circuit Breaker）](#9.4.1 微服务断路器模式（Circuit Breaker）)

[9.4.2 SOA 与微服务区别](#9.4.2 SOA 与微服务区别)

[9.57 总结](#9.57 总结)

十、现代计算架构

[10.1 云计算](#10.1 云计算)

[10.2 云原生](#10.2 云原生)

云原生七项架构原则：

[10.3 Kubernetes](#10.3 Kubernetes)

[10.4 Service Mesh](#10.4 Service Mesh)

[10.5 Serverless](#10.5 Serverless)

[10.6 Edge Computing](#10.6 Edge Computing)

[10.7 大数据 Lambda 架构](#10.7 大数据 Lambda 架构)

[10.8 总结](#10.8 总结)

[10.9 真题](#10.9 真题)

[10.9.1 （2025年）OGSA](#10.9.1 （2025年）OGSA)

---

一、软件架构基本概念与架构描述语言 ADL

1.1 软件架构基本概念

软件架构并不是代码本身，也不是某一个类、函数或算法，而是站在更高抽象层次上描述整个软件系统：

• 系统由哪些主要部分构成；
• 这些部分之间如何连接和交互；
• 系统整体具有怎样的结构和行为；
• 系统如何满足性能、安全性、可修改性等质量要求。

可以把软件开发中的不同抽象层次理解为：

用户需求 → 系统功能与质量属性 →软件架构 → 构件 / 连接件 / 接口 / 配置 → 模块、类、对象 → 具体代码

软件架构核心 = 结构（Structure）+ 行为（Behavior）+ 属性（Property）

• 结构：系统由什么组成，各个模块在系统中的位置
• 行为：各模块之间是如何协作的
  • 真题中考到：架构设计关注软件组件的结构、属性和什么？
    • 软件架构设计关注组件的结构、属性和交互作用 ，并通过多个视图从不同角度描述体系结构。
• 属性：整个系统的能力要求如何

1.1.1 软件架构的核心构成：构件与连接件

早期体系结构建模主要关注构件以及模块间互联机制；随后构件之间的互联机制被独立出来，形成与构件同等重要的实体------连接件（Connector）。

1.1.1.1 构件Component

什么是构件？ ------ 系统中相对独立、承担某种计算或功能职责的软件单元。

• 例如：订单服务、用户认证模块、日志模块、数据库访问模块、编译器词法分析器
• 构件不等于"类"，一个构件可能由若干类、若干对象、若干模块、独立进程组成。

1.1.1.2 连接件 Connector

连接件描述：构件之间如何发生交互。

• 例如：过程调用、RPC、消息传递、事件、管道、共享数据访问

不同架构风格的区别，本质上往往是：构件是什么 + 连接件是什么 + 如何组织

1.1.2 架构配置 Configuration

配置 Configuration：用于说明构件和连接件之间具体怎样组织成完整的软件体系结构。

使用的构件可能相同，但配置不同，形成的架构也不同，如下：

Component A Component A

│ / \

Connector Connector Connector

│ ↓ ↓

Component B Component B Component C

│

Connector

│

Component C

配置一是链式连接；配置二是以组件A为中心。

1.1.3 接口 Interface

接口 描述 构件与外部世界发生交互时所暴露的服务或交互点。

例如：

UserService

• createUser()

• getUser()

• deleteUser()

架构关注的是 UserService 提供哪些服务，其他构件通过什么接口调用，而不是函数的具体实现。

1.1.4 小结

以在线购物系统为例进行整体理解：

           REST API
用户 ─────────────→ OrderService
                         │
                         │ RPC
                         ↓
                   PaymentService
                         │
                         │ SQL
                         ↓
                     Database

内容	架构概念
OrderService	构件 Component1
PaymentService	构件 Component2
Database	构件 Component3/数据构件
REST / RPC / SQL访问机制	连接件 Connector
对外暴露的服务	接口 Interface
三者如何连接	配置 Configuration

因此我们可以得到的关系是：Component1 提供 Interface 通过 Connector 与其他 Compone进行交互，整体组织关系形成Configuration。

1.2 架构描述语言 （ADL，Architecture Description Language）

支持构件、连接件及其配置描述的语言称为体系结构描述语言，ADL 对连接件的强调也是其区别于一般建模语言的重要特征。

ADL = 组件 + 组件接口 + 连接件 + 架构配置

将 ADL 与多视图结合有助于体系结构理解、交流、一致性检查以及质量属性评估。

• 软件架构需要被描述 → 构件 + 连接件 → ADL → 一个角度难以描述复杂系统 → 多视图 → 4+1 视图

1.3 真题

1.3.1 （2013 年）软件系统架构 = 结构 + 行为 + 属性

软件系统架构是关于软件系统的结构、（）和属性的高级抽象。在描述阶段，主要描述直接构成系
统的抽象组件以及各个组件之间的连接规则，特别是相对细致地描述组件的（）。在实现阶段，这
些抽象组件被细化为实际的组件，比如具体类或者对象。软件系统架构不仅指定了软件系统的组织
和（）结构，而且显示了系统需求和组件之间的对应关系，包括设计决策的基本方法和基本原理。
问题（1）
（A）行为
（B）组织
（C）性能
（D）功能
问题（2）
（A）交互关系
（B）实现关系
（C）数据依赖
（D）功能依赖
问题（3）
（A）进程
（B）拓扑
（C）处理
（D）数据
（正确答案）A,A,B

问题（3）解析：

A选项进程：进程属于操作系统层面的实现细节，不是架构组织的抽象层次，错误。

B选项拓扑：软件系统架构需要指定组织结构和拓扑结构，即组件之间的连接模式，这是正确的。

• 组织结构： 关注有哪些构件、层、子系统，如何组织
• 拓扑结构：关注构件之间采用什么连接模式

C选项处理：处理描述的是运行机制，而非架构组织形式，错误。

D选项数据：数据结构不是架构组织层次的抽象，错误。

1.4 总结

概念	回答的问题	示例
构件 Component	谁承担功能	OrderService
接口 Interface	对外提供什么能力	createOrder()
连接件 Connector	构件如何通信	HTTP、RPC、消息传递
配置 Configuration	构件如何组合	A→B→C
架构风格 Architecture Style	系统采用什么组织模式	分层、管道
视图 View	从哪个角度看系统	逻辑、进程、开发、物理物理、开发
质量属性 Quality Attribute	系统表现得怎么样	性能、安全性

1.4.1 易错点

（1） 软件架构主要不是描述具体算法和代码实现，选择题要注意选项所在的阶段。

• 架构描述对象：抽象组件、连接规则、组件通信、组件结构、拓扑结构

（2）组件之间的连接规则和通信本身是架构描述的重要内容。

---

二 、经典软件架构风格

软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式；它定义一组构件、连接件类型以及这些构件和连接件如何组合的约束。

2.1 数据流体系结构风格

核心思想：数据单向流动，构件按顺序处理数据

2.1.1 批处理 Batch Sequential

• 机制 ：每个处理单元是一个独立的程序 。数据作为一个完整的整体 一次性传递给下一个程序。必须等前一步完全结束 ，后一步才能开始，不支持并行执行 。
  • 构件是 独立应用程序，比如验证程序、更新程序等；连接件是 数据在步骤之间传递所使用的媒介，比如磁带、中间数据文件等。
• 典型场景：传统编译器的早期离线处理、传统的对账批处理任务。

2.1.2 管道---过滤器 Pipe and Filter

• 机制 ：每个处理单元是过滤器（Filter） ，只负责局部的数据转换；通道是管道（Pipe），充当数据流缓冲。

  • 基本构件是 Filter，连接件是负责数据流传输的 Pipe。

• 并发性 ：支持并行执行。当上游过滤器处理完第一批字节流放入管道时，下游过滤器可以立刻从管道读取并开始处理，形成类似流水线（Pipeline）的并发处理。

• 技术缺陷（脆弱性） ：不适合交互式系统；各过滤器之间若数据格式不一致，会导致频繁的数据序列化/反序列化，增加通信开销。

• 典型场景 ：Unix 管道命令（cat log | grep ERROR | wc -l）、现代编译器流水线（词法 → 语法 → 语义 → 代码生成）。

2.1.3 数据流风格真题题眼

题干	判断
整批数据完整传递	批处理
前一步全部结束才能下一步	批处理
上一步输出是下一步输入	管道---过滤器
数据连续产生	管道---过滤器
Filter	管道---过滤器
Pipe	管道---过滤器
编译：词法→语法→语义→代码生成	管道---过滤器

批处理 vs 管道---过滤器 关键区别在于是否必须等待整批数据处理完毕才能进行下一步。

2.2 调用/返回体系结构风格

一种分而治之策略：把复杂系统拆成若干子系统，通过调用和返回组织执行。

2.2.1 主程序---子程序

• 构件是主程序和子程序，过程调用作为交互机制，即连接件。

Main

/ | \

/ | \

A B C

/ \

D E

• 特点：调用关系具有明显层次

2.2.2 面向对象风格

• 对象或者抽象数据类型实例

Order Object

│

│ 方法调用

▼

Payment Object

• 核心关键词：对象、数据封装、操作封装、方法调用

2.3 层次型 Layered

**每一层为上一层提供服务，同时作为下一层的客户。**在典型层次结构中，内部层接口主要对相邻层开放，连接件由层间交互协议定义，拓扑约束体现在相邻层的交互约束上。

• 分层架构脆弱性：

  • 级联崩溃：底层发生故障，所有依赖它的上层都会瘫痪。

  • 通信性能损耗：数据跨越每一层边界都需要调用通信与格式转换，层数越多，性能越低。

2.3.1 C/S：Client / Server

C/S 是：基于资源不对等，为实现资源共享而提出。

• 两层 vs 三层 C/S 结构：

  • 两层 C/S（胖客户端）：客户端（表示层 + 部分业务逻辑）、数据库服务器（数据层）。业务逻辑散落在客户端，导致客户端笨重、网络带宽压力大、升级必须去每台电脑重新安装。

  • 三层 C/S（瘦客户端） ：客户端（表示层 ）、应用服务器（功能层/业务逻辑层） 、数据库服务器（数据层）。

  • B/S 架构 ：本质上是一种特殊的三层 C/S 架构（表示层统一换成了标准浏览器，极大降低了部署维护成本）。

注意： 按教材经典 Garlan/Shaw 风格分类：C/S 属于 调****用/返回； 但三层 C/S 本身又具有明显的分层结构。因此 如果题目明确引用经典五类，优先按教材分类； 如果题目给的是特定结构场景，要结合题干和选项判断。

2.4 以数据为中心的体系结构风格

核心思想：中心有一个共享的数据存储区，多个独立构件对其进行访问

2.4.1 仓库风格（Repository）

• 构成 ：中央数据结构 （保存并说明当前系统状态） + 独立构件（对中央数据执行操作的独立模块）。

  • 控制权：控制权在外部。外部用户输入事务或事件，驱动独立构件去读写中央数据仓库（被动访问）。

• 典型场景 ：现代 IDE（集成开发环境）。IDE 的中心是抽象语法树（AST）、符号表、工程元数据（中央数据结构），周围的编辑器、调试器、代码高亮器、语法检查器都是围绕这个中心数据操作的独立构件。

2.4.2 黑板风格（Blackboard）

• 构成（共享问题状态 + 多个知识源 + 状态驱动控制）

  • 黑板（Blackboard）：全局共享的数据结构，记录求解过程中的中间状态和候选假说。

  • 知识源（Knowledge Sources, KS） ：各自独立的专家求解模块。它们之间绝对互不通信、完全解耦。

  • 控制组件（Controller）：监控黑板上的状态变化，评估各个知识源的触发条件，动态调度最合适的知识源执行推理。

• 技术应用 ：适用于求解过程不确定、解空间巨大、规则非线性的复杂问题（如语音识别、知识推理、复杂图像信号分析）。

2.5 虚拟机风格

人为构造一个执行环境，在这个环境中解析和执行某种语言或规则。

2.5.1 解释器风格（Interpreter）

• 机理：系统自身包含一个虚拟的执行引擎，负责把用户输入的 DSL（领域专用语言）或脚本，解析为内部抽象语法树（AST）并解释执行。

• 典型场景 ：支持玩家自定义游戏战役地图与单位交互规则的游戏引擎；业务工作流引擎解析 XML 流程。

• 技术优势：拥有极高的业务灵活性。用户不重新编译程序，即可动态修改业务流程或策略。

• 性能瓶颈与解法 ：逐行解释效率低，业界常用 JIT（即时编译） 或部分预编译技术提升运行性能。

2.5.2 规则系统（Rule-based System）

• 构成 ：规则集（Rule Base） + 规则解释/推理机（Inference Engine） + 工作内存（Working Memory）。

• 机理 ：业务以 IF (条件) THEN (动作) 的规则沉淀在规则库中。工作内存存放当前的环境数据，推理机负责将环境数据与规则进行模式匹配（如 Rete 算法），一旦命中则触发执行。

• 典型场景 ：社保金计算（规则随国家政策每年动态调整）、商场 VIP 动态折扣系统、扫地机器人 / 智能家居环境感知与自适应避障。

2.5.3 解释器风格与规则系统区分

• 解释器风格：关注的是 下一条指令是什么？如何解释执行？

• 规则系统：关注 当前事实满足哪条规则？

2.6 独立构件体系结构风格

核心思想：构件本身具有较高独立性，通过特定通信机制发生协作。

2.6.1 进程通信（Process Communication）

• 构件与连接件 ：构件是独立的进程 （拥有独立的内存空间与上下文）；连接件是消息传递（Message Passing）机制。

• 技术特性：支持跨机器网络通信，可以是同步阻塞（RPC）或异步非阻塞（消息传递）。

2.6.2 事件驱动系统（隐式调用 / 发布-订阅）

• 机理：构件不直接调用目标对象的方法，而是发布一个或多个事件。其他构件向系统注册对该事件的监听。

• 技术优势：极高的时间解耦与空间解耦，易于扩展插件。

• 技术缺陷（脆弱性） ：事件触发顺序不可控，系统调试困难，无法保证原子事务。

• 真题题眼：广播、触发事件、注册事件、订阅、发布、不知道接收者是谁、隐式调用

2.7 C2 体系结构风格（高频考点）

• 定义 ：通过连接件绑定在一起、按照一组严格拓扑规则运作的并行构件网络。

• 拓扑约束四要素：

  • 构件和连接件都有顶部（Top）和底部（Bottom）。

  • 构件的顶部必须连到连接件的底部；构件的底部必须连到连接件的顶部。

  • 构件与构件之间绝对不允许直接相连（必须通过连接件隔离）。

  • 连接件与连接件直接相连时，必须是一个的底部连接到另一个的顶部。

2.8 总结

大类	核心思想	典型 Component	典型 Connector	题眼
数据流	数据顺序转换	程序 / Filter	数据媒介 / Pipe	输出→输入
调用/返回	调用后返回	程序、对象、层	Procedure Call / Protocol	谁调用谁
数据中心	围绕共享数据协作	独立构件/知识源	对共享数据的访问	中央数据
虚拟机	建立解释运行环境	Interpreter / Rule Engine 等	解释、规则匹配机制	指令/规则
独立构件	独立运行、松耦合协作	Process / Event Module	Message / Event	消息、事件

2.8.1 真题题眼总结

关键词	架构风格
完整、整批、前一步结束	Batch
流、Filter、Pipe、阶段输出作为下一阶段输入	Pipe-and-Filter
主程序、子程序、过程调用	Main/Subroutine
数据+操作封装、对象	Object-Oriented
上层、下层、相邻层、服务	Layered
Client 请求、Server 服务	C/S
中央数据结构、独立构件、数据共享	Repository
知识源、部分解、语音识别	Blackboard
解释执行、自定义语言	Interpreter
规则集、工作内存、IF-THEN	Rule-Based
独立进程、消息传递	Process Communication
广播、订阅、事件、隐式调用	Event System
Top、Bottom、构件不能直接连接	C2

---

三、基于体系结构的软件设计（ABSD）

ABSD（Architecture-Based Software Design/Development）是一种由体系结构驱动 的软件设计方法，由构成体系结构的商业需求、质量需求和功能需求的组合共同驱动。

架构风格 ------ 一种设计手段

ABSD ------ 一套架构驱动的软件设计方法

3.1 ABSD 的驱动源与三大基础

• 驱动源 ：由商业、质量和功能需求三者的组合共同驱动。

  • 驱动源 ≠ 体系结构需求

    • ABSD 方法整体由【商业需求 + 质量需求 + 功能需求】驱动

    • ABSD 的体系结构需求一般来自于【系统的质量目标 + 系统的商业目标 +系统开发人员的商业目标】

• 细化深度 ：ABSD是一个自顶向下、递归细化 的过程，顶层系统首先被分解为概念子系统 ，逐步细化，直到能产生具体的软件构件（Component）和类（Class）。

  • ABSD 是递归且迭代的；设计活动甚至可以在需求抽取和分析尚未全部完成时开始，需求分析与设计可以并行推进。

• ABSD 的三大技术基石：

  • 功能分解 ：使用成熟的模块高内聚、低耦合技术对系统功能进行分解。

    • 把大问题逐步拆成更容易管理的小问题。、

  • 选择架构风格：通过匹配架构风格来支撑非功能性的质量需求与商业需求。

  • 软件模板的使用：采用预定义好的结构骨架来组织软件设计。

• 用例用于捕获功能需求；质量场景用于捕获质量需求，而且质量场景应包括预期和非预期场景。

• ABSD 中的设计元素 ：顶层系统被分解为若干概念子系统和软件模板；下一层概念子系统继续被分解为概念构件和模板。

3.2 ABSD 中的视角与视图

• ABSD要从不同的视角看体系结构：
  • 静态角度 → 系统如何组织
  • 动态角度 →系统运行时怎样交互
  • 部署角度 → 软件如何映射到运行环境
• 多种视图用于全面考虑体系结构
  • 逻辑视图、进程视图、实现视图、配置视图

3.3 ABSD 的生命周期六大子过程（ABSDM）

子过程	核心问题	真题题眼
体系结构需求	我们需要什么架构？	质量目标、商业目标、标识构件
体系结构设计	架构到底怎么组织？	风格、映射构件、相互作用
体系结构文档化	怎么准确表达架构？	两个输出文档
体系结构复审	这个架构有没有问题？	风险、缺陷、用户代表、领域专家
体系结构实现	怎么把抽象架构变成真实系统？	构件实现、构件库、组装、测试
体系结构演化	需求改变以后怎么办？	增删改构件、更新相互作用

3.3.1 体系结构需求

需求来源为三方------系统的质量目标、系统的商业目标、开发组织的商业目标。表达工具：用例（功能）+ 质量场景（质量属性）。

3.3.2 体系结构设计

• 映射为构件和连接件，产出设计草案。

• 五步过程：提出体系结构模型 → 映射构件 → 分析构件相互作用 → 产生体系结构 → 设计评审

  • 提出体系结构模型 ------ 选择合适的架构风格

    • 比如 需求强调数据流 ------ 管道与过滤风格 ，需求强调共享数据 ------ 仓库风格 ， 需求强调松耦合事件 ------ 事件驱动风格

  • 映射构件 ------ 判断选定的架构风格分别位于哪

  • 分析构件相互作用 ------ 构件之间如何连接

  • 产生体系结构 ------ 把前面得到的构件、交互 、架构风格 组合并进一步细化，形成真正的软件体系结构

  • 设计评审 ------ 设计完成后邀请独立于开发工作的外部人员参与评审

    • 注意：这里是"体系结构设计过程内部的设计评审"，后面还有独立的"体系结构复审"子过程。

3.3.3 体系结构文档化

• 输出两个法定文档------《体系结构规格说明》 和 《测试体系结构需求的质量设计说明书》。
• 文档化原则 ：从使用者角度书写；针对不同背景人员采用不同视角视图；绝不是"随时保持文档最新" （架构频繁变动，随时修改会造成极高的维护代价，应在里程碑版本更新）。

3.3.4 体系结构复审

在早期发现潜在风险与设计缺陷。核心决策者是用户代表与领域专家。

3.3.5 体系结构实现

将文档落实为代码、构件与类的组装部署。

3.3.6 体系结构演化

当需求发生变化时进行的自适应调整。

• 需求变化归类 → 制订体系结构演化计划 → 修改、增加或删除构件 → 更新构件的相互作用 → 构件组装与测试 → 技术评审
• （整体逻辑是 先知道要变化什么 → 做计划 → 改构件 → 构件发生了变化那么对应的连接件/拓扑/交互也需要发生修改 → 重新组装测试 → 最后评审）

3.4 易错点总结

题目问什么	正确反应	常见干扰
ABSD 由什么驱动	商业+质量+功能需求	只有功能需求
三大基础	功能分解+架构风格+软件模板	项目管理
顶层分解为什么	概念子系统	功能/逻辑子系统
方法方向	自顶向下	自底向上
方法性质	递归+迭代	严格线性
功能需求怎么捕获	用例	质量场景
质量需求怎么捕获	质量场景	用例
六个子过程最后一个	演化	测试/部署/运维
发现架构风险	复审	实现
文档化两个主要输出	架构规格+质量设计说明	测试报告
演化中构件改变以后	更新构件相互作用	直接技术评审

---

四、Kruchten 4+1 视图模型及多视图演进

多视图建模的核心指导思想是关注点分离（Separation of Concerns）。

4.1 Kruchten 经典 4+1 视图映射矩阵

视图名称	核心问题	高频关键词	面向角色	常用 UML 表达模型
逻辑视图 (Logical)	系统功能结构是什么？	类、对象、功能、职责	最终用户、系统分析师	类图 、对象图 、状态图（定义对象内部行为）
进程视图 (Process)	系统运行时怎样工作？	并发、线程、进程、同步、通信	系统集成人员、性能调优工程师	活动图 、顺序图/时序图（并发进程交互）
开发视图 (Development)	代码怎样组织？	模块、包、代码、依赖	程序员、配置管理员	包图 、组件/构件图、工程目录树
物理视图 (Physical)	软件部署在哪里？ 软件 → 硬件节点映射	服务器、节点、网络、拓扑	运维工程师、系统网络工程师	部署图（Deployment Diagram）
场景 / 用例 (+1 Scenarios)	系统怎样满足具体用例？	Actor、Use Case、场景	所有项目干系人	用例图（Use Case Diagram）

购物系统的 4+1视图示例：

注意区分

（1）逻辑视图看"设计对象怎么组织"，开发视图看"代码模块怎么组织"。

（2）为什么类图（Class Diagram）既出现在逻辑视图，又出现在开发视图？

• 逻辑视图中的类图（分析期）：

  • 关注领域概念和业务职责 。类图只画出业务实体类（如 Customer、Order）和概念关联，不包含具体的编程语言数据类型、私有成员变量或框架注解。

• 开发视图中的类图（实现期，2019.11 考法）：

  • 关注源码模块的静态组织结构 。当类图细化到代码层面，标注了具体的字段类型（如 Integer、float）、具体的工程方法签名（如 dispatch()、stateChange()）以及模块间包依赖时，它表达的是程序员在 IDE 里的静态代码组织骨架，因此属于开发视图（实现视图）。

（3） 经典 Kruchten 4+1 与 RUP 中的 4+1 会有点区别

• 关系：4+1 视图模型由 Philippe Kruchten 提出，RUP 后来采用了这种多视图思想。
• 区别
  • 经典 Kruchten 4+1 ：逻辑、进程、开发、物理、场景
  • RUP 中的 4+1 : 逻辑、进程、实现、部署、用例

4.2 其它多视图流派（考辨析）

4.2.1 Hofmeister 4 视图模型

• 概念视图（Conceptual）：高层功能与概念结构
• 模块视图（Module）：静态模块组织
• 执行视图（Execution）：运行时执行结构
• 代码视图（Code）：源码与实现组织

4.2.2 CMU-SEI Views and Beyond**(V&B)**

• 模块视图：软件静态上由哪些模块组成
• 构件和连接子视图： 系统运行时，构件和连接件如何交互
• 分配视图：软件结构与外部环境之间的映射

4.2.3 总结

关注维度	Kruchten 经典 4+1 视图	Hofmeister 4 视图	CMU-SEI (V&B) 3 视图
静态结构与类接口	逻辑视图（Logical）	概念视图 + 模块视图	模块视图（Module）
代码组织与编译打包	开发/实现视图（Development）	代码视图（Code）	模块视图之实现子视图
并发与运行时通信	进程视图（Process）	执行视图（Execution）	构件和连接子视图（C&C）
软硬件部署与分配	物理/部署视图（Physical）	（体现在执行与环境中）	分配视图（Allocation
	+1 统一场景（Scenarios）	---	---

4.3 真题

4.3.1（ 2014年）"4+1"视图模型 及 UML 建模工具

"4+1"视图主要用于描述系统逻辑架构，最早由 Philippe Kruchten 于1995年提出。其中（）视图
用于描述对象模型，并说明系统应该为用户提供哪些服务。当采用面向对象的设计方法描述对象模
型时，通常使用（）表达类的内部属性和行为，以及类集合之间的交互关系；采用（）定义对象的
内部行为。
问题（1）
（A）逻辑
（B）过程
（C）开发
（D）物理
问题（2）
（A）对象图
（B）活动图
（C）状态图
（D）类图
问题（3）
（A）对象图
（B）活动图
（C）状态图
（D）类图
（正确答案）A,D,C
问题1 ：
题眼 "用于描述对象模型，并说明系统应该为用户提供哪些服务" ------ 为用户提供哪些功能 ------ 逻辑视图
A选项 逻辑 ：逻辑视图用于描述系统的对象模型，展示系统应为用户提供的功能和服务，符合题干
描述，正确。
B选项 过程 ：过程视图侧重并发和交互进程的设计，与对象模型无关，错误。
C选项 开发 ：开发视图用于描述软件的模块化结构，错误。
D选项 物理 ：物理视图描述系统的物理部署结构，错误。
问题2 ：
A选项 对象图 ：用于展示某一时刻对象及其关系的快照，不是主要用来表达类的静态结构，错误。
B选项 活动图 ：描述控制流与数据流的动态过程，不是表达类的结构，错误。
C选项 状态图 ：用于建模对象的动态行为，不是描述类的属性与关系，错误。
D选项 类图 ：用于描述类的属性、方法以及类之间的关系，是逻辑视图中表达对象模型结构的主要
工具，正确。
问题3 ：
A选项 对象图 ：是对象快照，不适合表示对象的内部行为，错误。
B选项 活动图 ：是动态过程建模，但强调控制流，不是内部状态变化，错误。
C选项 状态图 ：用于定义对象的内部状态以及状态变化规则，符合题干描述，正确。
D选项 类图 ：静态结构图，不适合表示对象的内部行为，错误。

---

五、软件质量属性与质量属性场景

5.1 软件质量属性

质量属性分为：开发期质量属性 与 运行期质量属性

5.1.1 开发期质量属性

开发期质量属性关注：软件在设计、开发、修改、测试和迁移过程中是否容易处理。

质量属性	核心问题	题眼
易理解性 Understandability	开发人员容易理解吗？	理解设计、代码、结构
可扩展性 Extensibility	容易增加新功能吗？	新需求、新功能
可重用性 Reusability	构件能重复使用吗？	复用、组件共享
可测试性 Testability	容易测试吗？	构造测试、观察结果
可维护性 Maintainability	容易定位并修改问题吗？	修复缺陷、修改
可移植性 Portability	容易迁移到其他环境吗？	OS、硬件、平台

5.1.2 运行期质量属性

运行期属性关注：系统真正运行以后表现如何。

质量属性	核心问题	典型题眼
性能 Performance	快不快、能处理多少？	响应时间、吞吐量
安全性 Security	非法用户能否访问？	授权、攻击、加密
可伸缩性 Scalability	数据/用户增加还能扛住吗？	用户数增长、扩容
互操作性 Interoperability	能否和其他系统协作？	数据交换、服务调用
可靠性 Reliability	多长时间不出故障？	连续无故障运行
可用性 Availability	有多少时间真正可服务？	正常运行比例、恢复
鲁棒性 Robustness	异常情况下还能正确处理吗？	非法输入、异常环境

5.1.3 易混淆点

（1）可扩展性 vs 可伸缩性

• 可扩展性 关注：功能能不能扩展？
• 可伸缩性 关注：规模变大以后还能不能维持服务质量？

（2）可移植性 vs 互操作性

• 可移植性 关注：软件部署环境的切换
• 互操作性 关注：与其他系统交换数据以及相互调用服务的难易程度

（3）可靠性、可用性、鲁棒性

• 可靠性 关注：正常情况下能够稳定运行多久
• 可用性 关注：一定时间内系统正常工作的时间所占比例 / 故障后多快能够恢复服务
• 鲁棒性 关注：异常情况下能够妥善处理

（4）可维护性 vs 可修改性

• 可维护性 关注：发现问题之后，能否容易定位并修复 ------ 重点在修复
• 可修改性 关注：系统发生某种变化时，修改代价是否低 ------ 重点在修改

（5）性能 vs 可用性

• 区分方式：题中描述的时间是在衡量请求处理，还是故障恢复？
  • 衡量请求处理 ------ 性能
  • 故障恢复能力 ------ 可用性

5.2 质量属性场景

质量属性场景是一个具体的质量属性需求，是利益相关者与系统交互的简短陈述。

质量属性场景（6 要素） ： 刺激源 → 刺激 → 环境 → 制品 → 响应 → 响应度量。

• 制品：受到刺激作用的组件或系统。

• 响应 ：在刺激到达之后所采取的行动。

• 响应度量：对行动结果的量化指标（如：30 秒内恢复、延时 < 1s）。

场景举例

（1）以购物系统写一个完整性能场景

需求：系统要响应快

场景元素	内容
刺激源	用户
刺激	提交订单查询请求
环境	正常运行、1000 用户并发
制品	订单查询服务
响应	返回订单信息
响应度量	95% 请求在 1 秒内完成

最终就得到：系统正常运行且有 1000 个并发用户时，用户向订单查询服务发起查询请求，系统应返回订单信息，其中 95% 的请求应在 1 秒内完成。

（2）以购物系统写一个可用性场景

需求：系统要高可用

元素	内容
刺激源	Payment Server
刺激	支付服务实例崩溃
环境	系统正常运行
制品	Payment Service
响应	检测故障并切换备用实例
响应度量	5 秒内恢复支付服务

最终得到：系统正常运行期间，如果支付服务实例发生崩溃，系统应检测故障并切换到备用实例，在 5 秒内恢复支付能力。

（3）以购物系统写一个可修改性场景

需求：系统以后要容易修改

元素	内容
刺激源	开发人员
刺激	将消息中间件从 RabbitMQ 替换为 Kafka
环境	系统维护阶段
制品	消息通信子系统
响应	替换实现且不修改业务模块
响应度量	修改限定在 3 个模块以内、5 人日完成

最终得到：维护阶段，当开发人员需要将 RabbitMQ 替换为 Kafka 时，应仅修改消息通信相关构件，不影响订单和支付业务逻辑，并在 5 人日以内完成。

5.3 真题（属性和应对策略）

核心质量属性与高频架构战术对应表

质量属性	典型场景题眼	软考高频架构设计战术（Tactics）
性能 (Performance)	• 1000 并发下响应时间 < 0.5s • 数据传递时延不大于 1s • 单位时间内吞吐量与请求处理个数	• 资源调度（线程池、任务调度队列） • 资源仲裁（优先级队列调度） • 增加计算资源（垂直加 CPU/内存、水平扩展） • 减少计算开销 / 引入并发机制
可用性 (Availability)	• 遭遇断电后 15s 内切换到备用站点恢复运行 • 节点断连后在 30s 内自动重连成功 • 关注正常工作时间比例与 MTBF、MTTR	• 主动冗余（Active Redundancy / 双机热备） • 心跳机制（Heartbeat / Ping-Echo 探测） • 快速故障转移与主从选举
安全性 (Security)	• 抵御恶意入侵、防重放攻击 • 能够阻止未授权用户使用，为合法用户服务 • 对操作报警与追溯	• 追踪审计（Audit Trail / 日志追踪） • 检测攻击（入侵检测系统 IDS） • 认证与授权（RBAC、数字签名） • 数据高强度加密
可修改性 (Modifiability)	• 替换消息中间件工作量在 5 人/月内完成 • 增加新的业务功能不影响旧模块 • 降低维护成本	• 接口与实现分离 / 抽象接口 • 信息隐藏（Information Hiding） • 限制通信路径（使用中间层、适配器）
可测试性 (Testability)	• 衡量系统测试用例构造的难易度 • 支持远程控制与调试模式	• 记录/回放（Record and Playback） • 暴露专用测试接口 / Mock 适配接口
可移植性 (Portability)	• 一套系统可编译运行在不同 OS、硬件架构和编译器上	• 硬件抽象层（HAL） • 平台无关的虚拟机与跨平台运行时

---

六、架构评估方法

架构评估是在系统开发之前对架构草案进行的定性/定量分析，旨在降低系统失败的风险。

注意：请不要把"架构评估"理解成项目完成后的验收。很多架构评估发生在系统尚未完全实现之前，其目的恰恰是尽早发现架构决策中的风险和质量属性冲突。

6.1 评估的核心技术概念

• 敏感点（Sensitivity Point） ：对单一质量属性有决定性影响的某个构件特性或架构决策（如：采用 Memcached 会大幅提高响应性能）。

• 权衡点（Tradeoff Point） ：同时影响多个质量属性 ，且通常存在冲突制约的设计决策（如：提升加密算法强度提升了安全性，却拖慢了响应性能；加密级别就是一个权衡点）。

  • 权衡点本质上是多个质量属性共同的敏感点

• **风险点：**当前架构决策是否可能导致某个重要质量目标无法满足

• 非风险点：架构能够实现特定优先级质量属性的优势

6.2 三类架构评估方法

6.2.1 基于调查问卷/检查表的方法（Questionnaire/Checklist-based）

• 原理：利用专家经验判断架构，评估专家组利用预先编制好的一组标准化问题或检查表，与设计团队逐项核对。

• 特点：简单、主观性较强，依赖评估人员的经验，适用于开发极早期的粗粒度审查。

6.2.2 基于场景的方法（Scenario-based，核心主流）

• 原理：将非功能性质量属性转化为具体的"交互场景"，通过分析构件对刺激的响应来评估架构。

代表 ：SAAM （鼻祖）、ATAM （集大成者）、CBAM（经济扩展）。

（1）**软件体系结构分析方法（SAAM，**Scenario-Based Architecture Analysis Method）

• SAAM 将质量属性具体化为场景，而可修改性是其主要分析质量属性之一。

• SAEM → 软件架构评估模型 → 外部质量属性 + 内部质量属性

• SAAM 评估过程：场景开发 → 架构描述 → 单个场景评估 → 场景交互评估 → 总体评估

• **真题题眼：**场景技术、可修改性、最终架构、早于详细设计、比较不同架构、五个步骤

（2）架构权衡分析方法（ATAM，Architecture Tradeoff Analysis Method）

• ATAM 是在 SAAM 基础上进一步发展而来，SAAM 更强调架构对场景支持程度如何；ATAM 更进一步关注多个质量属性之间有没有冲突，架构是否有需要权衡的地方。

• ATAM 用于分析多个相互竞争的质量属性，重点包括：可修改性、安全性、性能、可用性

• ATAM 最重要的工具：质量属性效用树（Utility Tree）

  • 结构层级 （从根到叶）：树根（Utility） → 质量属性 → 属性分类 → 质量属性场景（叶子节点）。

  • 评估两维坐标 ：每个场景的优先级不是系统预设的，而是沿着 重要性（Importance: H/M/L） 与 实现难度（Difficulty: H/M/L） 两个维度评估排序。（先按重要性，再按照场景实现难易度）

• ATAM 中头脑风暴的三类场景

  • 用例场景：描述系统正常情况下的典型功能有哪些

  • 增长场景：描述系统未来比较合理的扩展和变化 ------ 重点考察 架构能否应对演化

  • 探测场景 / 探索性场景：描述极端变化

• ATAM 评估九步法与 4 大阶段

  ATAM（基于架构权衡分析方法）在工程实施中分为 4 个大阶段、9 个具体步骤，下午案例分析与上午选择题常考顺序与阶段职责：

  阶段划分	对应步骤（1~9 步）	核心活动与关键细节
  阶段 1：描述与介绍	1. 介绍 ATAM 方法 2. 介绍商业动机 3. 介绍架构设计	• 评估小组介绍评估规则与流程。 • 项目业务负责人介绍系统商业目标。 • 架构师讲解当前架构的视图与机制。
  阶段 2：调查与分析	4. 识别架构方法/风格 5. 生成质量属性效用树 6. 分析架构方法	• 识别出系统采用的架构模式（如分层、管道、微服务）。 • 核心团队构建效用树（Utility Tree），并对场景按 (重要性, 难度) 赋予优先级（H/M/L）。 • 分析场景的满足度，识别出敏感点、权衡点、风险点、非风险点。
  阶段 3：测试与验证	7. 动员利益相关者头脑风暴 8. 形成场景优先列表 9. 重新分析架构方法	• 引入更大范围干系人（开发、测试、运维、用户），头脑风暴提出三类场景：用例场景、增长场景、探索性场景。 • 将头脑风暴场景与第 5 步效用树场景进行比对、合并与重新排序。
  阶段 4：报告结果	输出最终评估报告	• 汇总敏感点、权衡点、风险清单与架构决策建议。

（3）成本效益分析方法（CBAM，Cost Benefit Analysis Method）

• CBAM 在 ATAM 结果基础上，对架构设计决策的成本和收益进行建模，并根据投资回报 ROI 选择架构策略。 ------ CBAM = ATAM + 经济分析
• 核心逻辑
  • 架构策略 → 改善质量属性 → 产生效益 → 结合成本 → 计算ROI → 选择方案
• 真题题眼：成本、收益、经济价值、投资回报（ROI）

6.2.3 基于度量的方法（Metrics-based，2024.11 考点）

• 原理：制定一套客观量化的公式和规则。

• 核心执行三步法：

  建立质量属性与度量映射原则 → 从架构文档中提取度量数据射原则 → 分析推导得出质量属性水平

• 典型度量指标：模块扇入扇出数、圈复杂度、代码耦合度与内聚度。

6.2.4 评估方法对比

评估方法	核心理念与技术特征	核心关注点
SAAM (基于场景的架构分析)	输入包含：问题描述、需求声明、体系结构描述。关注最终架构而非详细设计，主要用于架构比较和场景分析。	可修改性 / 演化性
ATAM (架构权衡分析方法)	在 SAAM 基础上发展而来，核心工具是**效用树，**适用于开发前对架构设计进行定性分析。	性能、安全性、可用性、可修改性 的权衡与折中
CBAM (成本效益分析法)	在 ATAM 的基础上引入经济学原理，不仅看质量权衡，更通过计算 投资回报率（ROI） 来决策方案。	成本、收益与经济可行性 (ROI)
SASAM （软件架构静态分析）	通过工具解析架构模型，比对"预期架构"与"实际实现"之间的偏差。	静态分析（Static Analysis）

总结：SAAM（能不能使用这个架构） ，ATAM（怎么权衡），CBAM（值不值）

先用质量属性场景把需求说清楚 → 再通过架构评估判断设计是否支持这些场景 → 找到风险点和敏感点 → 当多个质量属性冲突时识别权衡点 → ATAM 帮助做技术权衡 → CBAM 再进一步判断这种架构投入在经济上是否值得。

6.3 其他架构评估方法

方法	关键词
软件架构评估模型 SAEM	外部质量属性 + 内部质量属性；建立度量准则
软件架构评估信念网络 SAABNet	BBN（贝叶斯信念网） + 不确定知识 + 定性架构评估
软件架构变化度量方法 SACMM	度量两个架构之间的修改/差异
软件架构静态评估方法 SASAM	预期架构 vs 实际架构、映射、比较、静态评估
架构级可靠性风险分析 ALRRA	架构可靠性风险、FMEA、组件/连接件、动态复杂度与耦合
层次分析法 AHP	层次、两两比较、权重、方案排序、多准则决策
COSMIC+UML	基于度量评估 UML 构件架构可维护性
基于场景的架构再工程 SBAR	场景评估 + 架构再工程
架构级软件维护预测 ALPSM	预测架构级维护工作量

---

七、软件架构复用

软件架构复用：系统化地识别、开发、分类、获取和修改可复用的软件资产，使这些资产能够在不同系统开发过程中重复使用。

7.1 两种复用类型：机会复用 vs 系统复用

• 机会复用 Opportunity Reuse：开发过程中碰到了可以复用的东西，于是拿来使用。
• 系统复用 Systematic Reuse ： 开发之前就规划哪些需要复用。

**什么可以被复用？ ------**复用可以发生在整个生命周期

可复用对象	示例
需求	银行柜面交易与网上银行的共性需求
架构设计	已验证的分层架构、微服务骨架
元素	构件、模块、接口
建模与分析	性能模型、容错方案、负载均衡方案
测试	测试用例、测试数据、工具、测试计划

7.2 软件架构复用的三个基本过程

• 构造 / 获取可复用资产

• 管理可复用资产：构件库 + 分类 + 检索

• 使用可复用资产

7.3 真题考察点

题眼	答案
开发过程中发现可复用资产就用	机会复用
开发前规划哪些资产复用	系统复用
复用三阶段	获取 → 管理 → 使用
可复用资产的管理设施	构件库
管理阶段两个关键问题	分类 + 检索
复用对象	需求、架构、元素、分析模型、测试等
一系列相关产品共用核心资产	软件产品线

八、特定领域软件体系结构 DSSA

8.1 特定领域软件架构（DSSA，Domain-Specific Software Architecture）

• 定义：在特定应用领域中，为一组应用（系统族）提供组织结构参考的标准软件体系结构。

• DSSA 的四个必备特征

  • 严格定义的问题域和解域

  • 具有普遍性

  • 对构件组织模型进行恰当抽象

  • 包含典型可复用元素

• 三大基本要素

  • 领域模型（Domain Model）：表达该领域内所有系统的共性业务需求与可变点。

  • 参考架构（Reference Architecture）：针对该领域模型提出的标准化、通用的架构解决方案。

  • 参考需求（Reference Requirements）：系统族必须满足的通用需求规约。

• 域的两个技术方向：

  • 垂直域 ：定义一个特定的系统族及通用架构（如：专门针对银行信贷系统的全生命周期通用架构）。

  • 水平域 ：定义跨越多个不同行业系统族的公共子系统服务（如：通用的分布式日志认证子系统）。

• DSSA 的 4 类人员角色：

  • 领域专家 ：提供领域知识、现有系统经验与需求规约，负责复审领域模型与 DSSA 架构的正确性。

  • 领域分析师 ：控制领域分析过程，抽取共性与可变点，输出领域模型。

  • 领域设计人员 ：依据领域模型设计出通用的 DSSA 架构，并设计可复用模块的接口规范。

  • 领域实现人员：开发并组织可复用构件，实现基础软件平台。

• DSSA 开发的三大阶段与产物：

  • 领域分析 → 产出 领域模型

  • 领域设计 → 产出 特定领域软件架构（DSSA）

  • 领域实现 → 产出 可重用构件库与参考实现

  • 过程特性 ：并发的、递归的、反复迭代的。

DSSA 活动	核心问题	主要产物
领域分析	这个领域有哪些共同需求？	领域模型
领域设计	用什么通用架构满足这些需求？	DSSA
领域实现	怎样把架构变成真正可复用资产？	可重用信息/构件

• DSSA 建立五个阶段， 建立过程特性是【并发、递归、反复】

  • 定义领域范围 ------ 确定领域边界

  • 定义领域特定元素 ------ 建领域词汇、识别共性与差异

  • 定义领域特定设计和实现需求约束 ------ 描述解空间中的约束

  • 定义领域模型和体系结构 ------ 建立领域模型与通用架构

  • 产生/搜集可重用产品单元 ------ 为DSSA补充构件和可复用资产

• **三层次系统模型 ------**领域级资产如何经过具体应用开发，最终进入应用执行环境

  • 第 1 层 领域开发环境 ：由领域架构师在此环境中工作，负责定义通用的参考架构、模式与可复用构件。

  • 第 2 层 应用开发环境 ：由应用工程师在此环境中工作，利用第 1 层产出的领域资产，拼装开发具体的行业软件。

  • 第 3 层 应用执行环境：操作员和最终用户在实际硬件上运行系统的环境。

总结

维度	内容	回答的问题
三个基本活动	领域分析、领域设计、领域实现	做什么？
四类人员	专家、分析人员、设计人员、实现人员	谁来做？
五阶段建立过程	范围→元素→约束→模型/架构→产品单元	具体怎样建立？
三层系统模型	领域开发→应用开发→应用执行	建立出的资产怎样用于具体应用？

8.2 DSSA 与软件架构复用

DSSA 是一种面向特定领域、系统化实现架构复用的方法。

软件架构复用 → 希望多个系统共享资产 → 如果这些系统属于同一个领域 → 对领域共性进行抽象 → 建领域模型 → 设计DSSA → 形成可复用资产

九、面向服务架构 SOA

核心思想：将可以独立提供业务能力的功能封装为服务，通过标准接口和消息进行交互，再将多个服务组合完成业务。 ------ SOA解决企业级系统集成

9.1 SOA 的主要设计原则

服务应该足够独立、接口足够稳定、内部足够隐藏、外部足够容易复用

原则	核心理解	题眼
无状态 Stateless	服务请求尽量不依赖前一次请求，降低调用者与服务端上下文耦合	无状态
单一实例	避免功能重复	功能冗余
明确定义接口	使用者依赖接口而非内部实现	WSDL、契约
自包含、模块化	服务独立完成完整业务能力	独立
粗粒度	对外提供稳定的完整业务能力，而不是泄露大量内部细节	粗粒度服务
松耦合	调用者尽量不知道服务位置、技术实现及内部状态	松耦合
可重用	同一个服务可以被多个业务复用	重用
互操作与策略声明	跨技术平台协作，并明确策略要求	互操作性

9.2Web Service

SOA 是架构思想；Web Service 是 SOA 的一种典型技术实现。

现在企业中可能有很多服务可以进行调用，那么SOA 怎么让这么多服务真正协作？这里就需要Web Service 技术体系 去确认谁找服务、接口怎么描述、不同语言怎么通信、调用顺序怎么组织

Web Service 的四个高频技术：

• UDDI ：基于标准的注册与发现机制（描述、发现、集成）。 ------ 找服务
• WSDL ：接口描述语言（用 XML 描述服务做些什么、如何访问、位于何处，绝不透露服务内部如何实现）。 ------ 找接口
• SOAP：Web Service 的消息通信机制，用来实现远程服务调用。 ------ 消息传递
• BPEL：把多个 Web Service 编排成一个完整业务流程
  • 真题：将分散、功能单一的 Web Service 组织成复杂有机应用 → BPEL

9.3 ESB

问题：如果有 20 个服务，每两个服务直接连接，那么系统会出现非常复杂的点到点集成，怎么办？

SOA 常引入 企业服务总线（ESB，Enterprise Service Bus）来进行解决

ESB（企业服务总线） ：通过消息总线做协议转换和消息路由，消除服务调用者与提供者之间的直接网络耦合。 ------ ESB 的核心价值是降低异构系统之间直接耦合

9.4 微服务

微服务：将SOA 思想进一步细粒度化和去中心化的发展，并强调独立进程、RESTful 接口和分布式部署。

9.4.1 微服务断路器模式（Circuit Breaker）

• 关闭（Closed）：正常状态，流量全量放行。

• 打开（Open / 熔断）：故障率达到阈值，立即熔断拒绝，执行降级逻辑。

• 半打开（Half-Open）：休眠期过后放行少量探测请求，成功则自动闭合恢复，失败则重新打开。

9.4.2 SOA 与微服务区别

SOA 集中式，微服务去中心化

SOA	微服务
重点解决企业系统集成	重点解决大型应用快速演化
强调业务能力复用	更强调服务自治
服务通常相对粗粒度	服务粒度更细
常借助 ESB 集成	更倾向去中心化
企业级异构系统常见	互联网、云原生应用常见
部署耦合相对更强	强调独立部署和独立扩缩容

9. 6 表述性状 态转移(REST,Representational State Transfer)

REST：以资源为中心，利用 URI 标识资源，并通过 HTTP 方法实现状态转移；解决 Web 系统怎样用一套统一、简单的方法表达对资源的操作 的问题。

REST 是一种设计风格，而不是某个具体软件产品。

• 以资源为中心，URI 对应资源。一个资源可以设计多个 URI，但一个具体 URI 只对应一种资源。

• HTTP 方法语义 ：GET（只读获取）、POST（创建资源）、PUT（已知 URI 时的整体替换更新 ）、PATCH（部分更新）。

9.57 总结

企业内部随着业务发展逐渐形成大量彼此孤立的异构系统，为复用已有业务能力并实现跨系统集成，提出了面向服务架构（SOA） ，即将稳定的业务能力封装为可复用的Service ，并通过 Web Service 技术体系实现服务的描述、发现、通信与组合，再借助 ESB 完成异构服务的统一集成。随着互联网业务对快速迭代、独立部署和弹性扩展的要求提高，SOA 的服务进一步向细粒度、自治和去中心化方向演化为微服务，而 REST 则成为微服务对外提供轻量级、跨语言接口的常见方式。

企业产生大量孤立异构系统
↓
需要复用并整合业务能力
↓
SOA
↓
把稳定业务能力封装为 Service
↓
服务需要被描述、发现、调用、组合
↓
Web Service
UDDI / WSDL / SOAP / BPEL
↓
大量异构服务需要统一集成
↓
ESB
↓
互联网业务要求更快迭代和独立部署
↓
Microservices
↓
分布式调用带来级联故障
↓
Circuit Breaker 等治理机制
↓
服务需要轻量、跨语言接口
↓
REST

十、现代计算架构

10.1 云计算

传统企业买服务器可能会有资源浪费、采购慢、扩容慢、运维成本高的问题，因此提出云计算（把计算、存储、平台甚至软件能力作为服务按需提供）

• 三种服务模式
  • SaaS 软件服务 ------ 直接用软件
  • PaaS 平台 ------ 写程序，平台帮你运行
  • IaaS 基础设施 ------ 给你机器，你自己搭环境
• 四种部署模式 ------ 云资源由谁拥有、谁可以使用、怎样组合
  • 公有云 Public Cloud
  • 私有云 Private Cloud
  • 社区云 Community Cloud
  • 混合云 Hybrid Cloud

10.2 云原生

云原生架构通过一组架构原则和设计模式，把应用中大量与业务无关的非功能性能力，例如弹性、韧性、安全、可观测性、灰度等，从业务代码中剥离，并尽可能交给云基础设施和平台承担。

以购物系统为例：

传统应用可能需要自己完成所有的功能：

OrderService
│
├─ 订单业务
├─ Retry
├─ HealthCheck
├─ Failover
├─ Metrics
├─ LoadBalance
└─ Security

但是云原生希望业务和平台能力分离：

OrderService
└─ 订单业务

        +

Cloud Platform
├─ 自动扩容
├─ 自动恢复
├─ 服务发现
├─ 流量治理
├─ Metrics
├─ Tracing
└─ Security

云原生七项架构原则：

• 服务化 ：不同生命周期、不同业务职责的模块分离
• 弹性 ：系统规模可以随着业务负载自动改变
• 可观测 ： 用日志、链路追踪和度量来解释云原生可观测性
• 韧性：系统依赖发生异常时，仍应尽可能继续提供业务
  • 常见手段：重试、熔断、反压、集群、跨区域容灾
• 所有过程自动化
• 零信任 ：默认不信任网络内部或外部任何主体
• 架构持续演进

不可变基础设施提出：已部署实例不直接修改。

10.3 Kubernetes

Kubernetes 要解决的是：如何自动管理大量容器化应用

10.4 Service Mesh

Service Mesh ：把服务间通信、安全、流量治理和可观测能力从业务进程中剥离到平台基础设施。Mesh 可以承担熔断、限流、降级、重试、反压等分布式治理能力。

**微服务 做业务，Mesh Proxy 管通信 ------**非侵入式服务治理

10.5 Serverless

Serverless ： 一种把部署和服务器运维进一步交给云平台的模式，典型特征包括全托管、自动弹性和按量计费，因此 Serverless 适合短时、事件驱动型任务，而长期有状态或 I/O 很重的任务未必适合。

10.6 Edge Computing

边缘计算：把计算、存储和应用能力部署到靠近数据源的网络边缘侧，就近提供服务；用于解决 云距离数据源太远时产生的时延、带宽和隐私问题。

• 云计算和边缘计算的关系：互补协同
  • 比如 云端训练模型，边缘节点执行推理
  • 云计算 全局、海量、长期分析；边缘计算 本地、实时、快速响应

10.7 大数据 Lambda 架构

解决大数据系统怎样同时兼顾历史数据的准确计算和最新数据的实时处理的问题。

• 批处理层（Batch Layer）：全量历史数据跑批，保证离线计算的高准确性。

• 加速层（Speed Layer）：处理实时增量流数据，换取超低延迟响应。

• 服务层（Serving Layer）：合并批处理与加速层视图，对外暴露统一查询

Lambda 用额外复杂度换取"历史准确性 + 实时性"

10.8 总结

技术	实际解决的问题
SOA	企业业务能力如何服务化和集成
Microservices	大型应用怎样拆分成自治服务
Cloud Computing	计算资源如何按需服务化
Cloud Native	应用如何充分利用云平台能力
Kubernetes	大规模容器怎样自动编排
Service Mesh	微服务通信治理怎样平台化
Serverless	如何进一步隐藏服务器管理
Edge Computing	计算如何靠近数据源
Lambda Architecture	大数据实时性与准确性如何兼顾
OGSA	网格资源如何服务化和互操作
Transformer	神经网络如何处理序列

10.9 真题

10.9.1 （2025年）OGSA

OGSA（开放网格服务架构）中，如何通过标准化 WebService 实现网格资源服务化与互操作（）。
问题（1）
（A）计算池模型、五层沙漏
（B）计算池模型 、开放式 WebService
（C）五层沙漏、开放式 WebService
（D）五层沙漏、网格服务化
（正确答案）D
解析：题眼 标准化 Web Service + 网格资源服务化 + 异构资源互操作
题目想问的是 OGSA 用什么架构思想把原本异构、分散的网格资源统一抽象并暴露出来？
原始网格环境（包含 不同计算机、不同存储系统、不同网络、不同操作系统、不同机构资源） → 资源高度异构 → 需要统一访问方式 → OGSA → 将网格资源抽象成Service → 通过标准 Web Service 接口访问 → 实现资源共享与互操作

这个思路和 SOA 的思路很像 ，SOA 是"业务能力服务化"；OGSA 是"网格资源服务化"。

网格体系结构

• 核心思想：资源共享 + 异构屏蔽 + 跨组织协同 + 标准化访问
• 网格体系结构的特征 ：五层沙漏
  • 构造层 Fabric ------ 提供真实计算、存储、数据等资源
  • 连接层 Connectivity ------ 提供通信、认证和安全连接到资源
  • 资源层 Resource ------ 管理和控制单个资源
  • 汇聚层 Collective ------ 协调和管理多个资源
  • 应用层 Application ------ 利用网格资源运行实际应用

五层沙漏

各种各样的应用

\ | | | /

\ | | | /

\ | | | /

标准协议接口 ← 沙漏最窄处

/ | | | \

/ | | | \

CPU GPU Storage DB Instrument