S06 · 软件架构设计

第 6 周｜主打科目：论文 + 案例分析 + 综合知识｜对应知识域：软件架构设计（13–16%）、中间件与构件｜主打基本问题：Q2（怎么证明一个架构是”好的”？）｜本阶段产出：架构设计说明书骨架（4+1 视图 + 质量属性场景表 + 架构风格选型论证 + ADR-001）

项目宪法见 00-课程总纲.md；架构方向是唯一在三个科目里同时占高分值的方向，见 02-考点地图.md。

一、情境开场（Hook）

S05 的数据模型评审第二天，CIO 把生产部、质量部、设备部、IT 运维的负责人一起叫进会议室，问了一个听起来很普通的问题：**”这套系统，架构怎么定？”**

设备部先说：”老设备改造不动，得有个能适配各种协议的采集层，别让我换 PLC。”
生产部说：”看板秒级刷新，报工不能卡，早班两百人同时点。”
质量部说：”数据一条都不能丢，追溯链条必须完整，断一层我们就不认。”
IT 运维——只有两个人——说：”太复杂的架构我们运维不了，出事我们扛不住。”

你说：”我们用微服务吧，扩展性好。”

CIO 没接话，停了两秒，问：**”为什么不是三层架构？为什么不用 SOA？微服务解决的是我刚才听到的哪一个问题？”**

你答：”扩展性好、技术异构、独立部署。”

CIO 说：”这四个部门刚才提的问题里，没有一个叫’扩展性’。我在问的是：你怎么向我证明，你选的这个架构是好的？ 你要是说不出来，那它跟掷骰子有什么区别？”

会议室安静了。那一刻你意识到：架构评审真正的考题不是”你选了什么”，而是”你凭什么说它是对的”。而”凭什么”这件事，恰恰是可以被结构化、被写下来、被别人复核的——它有一个名字叫质量属性场景，有一套流程叫 ATAM，有一种文档叫 ADR。

本周要做的，就是把”我觉得这样挺好”翻译成”在 X 条件下，系统对 Y 刺激做出 Z 响应，用 M 度量，达到 N“——没有度量就没有架构，只有审美。

二、为什么学这一周（Where & Why）

1. 质量属性场景六要素：综合知识 2–3 题；案例”补充质量属性场景””指出某场景缺哪个要素”约 6–10 分；论文里”非功能需求”部分几乎全部靠它撑起来——写不出六要素，论文必然空泛。
2. 质量属性战术（Tactics）：综合知识 2–4 题（”下列属于可修改性战术的是”这类归类题年年有）；案例”针对某质量属性给出改进措施”约 8–12 分；论文”采取了哪些措施”这一段的唯一素材来源。
3. 架构风格谱系与选型：综合知识 3–5 题；案例”某需求应采用哪种架构风格并说明理由”约 10–15 分，这是架构类案例最固定的问法。
4. ATAM 与敏感点 / 权衡点 / 风险 / 非风险：综合知识 2–3 题，四个概念的区分是年年考的送分题也是年年栽的失分题；案例”指出哪些是权衡点”约 6–8 分。
5. ADR：论文”架构设计类”与”应用系统集成”方向的加分项；本项目交付物硬性要求不少于 6 份，写不好直接影响 GRASPS 的”架构论证”维度评级。
6. 4+1 视图、中间件与构件标准、SOAP vs REST：综合知识 3–5 题，纯记忆为主，属”背了就拿分”的部分。

三、核心讲义（Equip）

3.1 软件架构的定义与 4+1 视图模型

定义：软件架构（Software Architecture）是系统的一个或多个结构，包括软件构件（Component）、构件的外部可见属性以及它们之间的相互关系。

“架构 = 构件 + 连接件 + 约束”视角：

• 构件：具有某种功能的可重用软件单元（模块、类、服务、进程、子系统）
• 连接件：构件之间的交互机制（过程调用、消息、事件、管道、共享数据、RPC）
• 约束：构件与连接件的组合规则与限制（分层不能跨层、服务必须无状态、协议必须兼容）

判定：题目问”架构的本质/组成部分”，答构件、连接件、约束三元组；问”架构关注什么”，答结构、行为与质量属性，而非算法细节。

4+1 视图模型（Kruchten，1995）——用五个视角完整描述一个架构，重点是”不同涉众看不同的视图“：

视图	回答什么问题	面向谁	主要 UML 图	本项目落点
逻辑视图（Logical）	系统为最终用户提供哪些功能	最终用户、业务方	类图、对象图、状态图	领域模型（批次、工单、检验记录、追溯报告）
进程视图（Process）	并发、同步、分布、性能、可伸缩	系统集成人员、性能工程师	活动图、时序图、通信图	采集的并发与异步、边缘网关与中心的同步、看板推送
开发视图（Development）	软件在开发环境中如何组织（模块、库、层次、构建依赖）	开发人员、构建与发布工程师	包图、组件图	采集服务 / 追溯服务 / 主数据服务的包结构与构建单元
物理视图（Physical / 部署视图）	软件如何映射到硬件，拓扑与通信	系统工程师、运维	部署图	3 厂区 + 边缘网关 + 中心机房 + 灾备
场景（Scenarios / 用例视图）	把前四个视图串起来并验证它们	全体涉众	用例图、活动图	“批次追溯查询 3 秒”等质量属性场景

“4+1”的”+1”为什么重要：场景是”驱动器”也是”检验器”——前四个视图画完之后，用场景去逐条跑，跑不通就说明视图之间有矛盾。考题爱问”哪个视图不是 4+1 的四个技术视图之一”→ 答”场景”（它是 +1）。

3.2 质量属性与质量属性场景六要素

定义：质量属性（Quality Attribute）是系统非功能性的、影响涉众满意度的特性。它是架构设计真正的驱动因素——功能决定能不能用，质量属性决定好不好用、能不能长期用。

质量属性	关心的度量	本项目指标
性能（Performance）	响应时间、吞吐量、并发数、资源利用率	追溯查询 ≤ 3 秒；看板刷新 ≤ 1 秒；峰值 300 并发
可用性（Availability）	正常运行时间占比、MTBF、MTTR	生产时段可用性 ≥ 99.9%；计划外停机 ≤ 8 小时/年
可靠性（Reliability）	不失效的概率、容错与恢复能力	采集数据零丢失；断网期间本地缓存，恢复后自动补传
安全性（Security）	机密性、完整性、可用性、可审计	检验记录不可篡改；操作全程留痕；按角色授权
可修改性（Modifiability）	变更的成本与影响范围	新增一种设备协议不改核心代码；新增一种报表格式 ≤ 3 人日
可测试性（Testability）	暴露缺陷的难易、测试成本	采集适配可脱离真实设备做契约测试
易用性（Usability）	学习成本、操作效率、出错率	操作工 2 小时培训即可独立报工
可移植性（Portability）	迁移到新环境的成本	支持从私有云迁移到信创环境

质量属性场景六要素（Quality Attribute Scenario）——本周最重要的工具，必须能默写模板：

要素	定义	本项目示例
① 刺激源（Source of Stimulus）	产生刺激的实体（人、系统、设备、外部机构）	质检员
② 刺激（Stimulus）	到达系统、需要系统做出响应的条件或事件	提交批次追溯查询请求
③ 环境（Environment）	刺激发生时系统所处的状态	正常运行，峰值 300 并发，数据量已达 5000 万条检验记录
④ 制品（Artifact）	被刺激到的系统或系统的一部分	追溯服务 + 追溯数据库
⑤ 响应（Response）	刺激到达后系统采取的行为	检索链条、组装报告、返回结果并记录审计日志
⑥ 响应度量（Response Measure）	对响应的量化度量，用于判定是否满足需求	3 秒内返回；99% 请求 ≤ 3 秒；失败率 < 0.1%

通用模板（论文与案例直接套用）：

在【环境】下，【刺激源】产生【刺激】，作用于【制品】，系统做出【响应】，并满足【响应度量】。

分层：一般场景 vs 具体场景：

• 一般质量属性场景（General Scenario）：与系统无关，用于生成需求清单（如”系统在高负载下收到请求，应在 X 秒内响应”）。
• 具体质量属性场景（Concrete Scenario）：与特定系统绑定，用于评估架构（上面那张六要素表就是具体场景）。

失分重灾区：考生写”系统响应时间要快””可靠性要高”——没有度量的场景不是场景，只是愿望。案例里”补充响应度量”是固定空位，必须有数字。

3.3 质量属性战术（Tactics）

定义：战术（Tactic）是影响质量属性响应的设计决策；架构策略（Architectural Strategy）是战术的集合。战术是架构师的”工具箱”——先定质量属性目标，再从箱里选战术。

性能战术：

分类	战术	本项目落点
资源需求（减少所需资源）	提高计算效率（改进算法）、降低计算开销（减少中间对象）、管理事件率（降低采样频率）、控制采样频率、限制执行时间（限定队列大小）	非关键设备参数采样从 1 秒降为 5 秒；追溯深度默认限制为 5 层
资源管理（用好现有资源）	引入并发、维持数据/计算的多个副本（缓存）、增加可用资源、提高资源利用率（负载均衡、调度）	采集引入异步并发；热点批次追溯结果缓存 5 分钟
资源仲裁（解决竞争）	调度策略：FIFO、固定优先级（抢占）、动态优先级（轮转、时限驱动/最早截止时间优先）、静态调度	报警消息优先级高于统计上报；看板推送采用轮询 + 服务端推送混合

可用性战术：

分类	战术	本项目落点
错误检测	心跳 / Ping-Echo、异常（Exception）检测、表决 / 冗余比较（Voting）	边缘网关 30 秒心跳；采集进程异常捕获上送
错误恢复	主动冗余（热备）、被动冗余（暖备/冷备）、备用（Spare）、影子操作、状态再同步、检查点/回滚	中心数据库主备热切换；边缘侧断网续传 = 状态再同步
错误预防	从服务中删除（重启）、事务、进程监视器、移除	采集进程守护与自动拉起；关键写入走事务

安全性战术：

分类	战术	本项目落点
抵抗攻击	身份验证、授权、数据机密性（加密）、数据完整性（哈希/校验和）、限制暴露（关闭端口）、限制访问（防火墙、白名单）	检验记录行级哈希链防篡改；边缘网关仅开放出站连接
检测攻击	入侵检测（IDS）、日志与审计追踪、模式比较	全量操作审计日志，保留 3 年
从攻击中恢复	恢复状态（冗余子集）、识别攻击者（审计追踪）	检验记录只读归档副本，可比对恢复

可修改性战术：

分类	战术	本项目落点
局部化变更	维持语义一致性（抽象、隐藏信息）、预期期望的变更（泛化模块）、限制可能的选择、防止连锁反应	IDeviceAdapter 抽象隐藏 30 多种协议差异
防止连锁反应	隐藏信息、维持现有接口、限制通信路径、使用仲裁者（外观、中介者、代理、桥接、数据中介）	新增协议不改核心；追溯服务对外提供外观接口
推迟绑定时间	运行时注册、配置文件、多态、组件更换、遵守已定义协议	采集适配器运行时注册（插件式），新增协议只需部署一个 jar

其他两个常考战术族：

• 可测试性战术：记录/回放、将接口与实现分离、特化访问路线/接口（提供内部状态查询接口）。
• 易用性战术：分离用户界面（MVC/MVP/MVVM）、支持用户主动（取消、撤销、聚合、暂停/恢复）、用户模型（用户画像、自适应）。

记忆法：三族战术的分类骨架——性能 = 需求 / 管理 / 仲裁；可用性 = 检测 / 恢复 / 预防；安全性 = 抵抗 / 检测 / 恢复；可修改性 = 局部化 / 防连锁 / 推迟绑定。考题常把某一族的战术混入另一族的选项里，用骨架逐一排除。

3.4 架构风格谱系与选型

五大经典风格族（Garlan & Shaw） + 现代衍生风格：

风格族	风格	核心构件	连接件	优点	缺点	典型应用
数据流	批处理序列	独立程序	数据流（文件/磁带）	吞吐量大、易管理	无交互、无并发、延迟大	日终结算、报表生成
	管道-过滤器	过滤器	管道（数据流）	高内聚低耦合、可复用、可并行	不适合交互；数据格式转换开销；错误处理难	编译器、日志处理、数据清洗
调用/返回	主程序-子程序	主程序、子程序	过程调用	简单直观	可修改性差、共享数据耦合高	小型程序
	面向对象	对象	方法调用	封装、继承、多态，可复用	对象标识耦合；分布式调用开销	业务系统
	分层（Layers）	层	层间调用	职责清晰、可替换、易维护	性能损失（层间转发）；易出现跨层耦合	网络协议栈、企业应用
独立构件	进程通信	独立进程	消息传递	分布、并发、容错	编程复杂、调试难	分布式计算
	事件驱动 / 隐式调用	构件	事件	松耦合、易扩展、支持异步	响应顺序不确定；难测试与调试；数据交换需共享仓库	GUI、EDA、本项目报警与看板
虚拟机	解释器	解释引擎、被解释程序	解释执行	灵活、可动态改变行为	性能差	脚本引擎、规则引擎
	规则系统	规则库、规则解释器、工作内存	推理	知识与控制分离、易改	性能、冲突消解复杂	风控、专家系统
仓库 / 以数据为中心	数据库系统	中央数据结构、独立构件	查询	数据集中、完整性好	中央结构成为瓶颈与单点	传统 MIS
	黑板系统	知识源、黑板	直接访问黑板	适合无确定解法的复杂问题、多源协作	控制策略难定、效率低、难测试	语音识别、模式识别
	超文本系统	节点、链	跳转	非线性组织	易迷航	WWW

现代衍生风格：

风格	关键特征	优点	缺点
C/S（两层）	客户端承担业务逻辑，服务器提供数据	交互好、负担分散	升级维护困难（每台客户端都要装）、客户端依赖平台
三层 C/S	表示层 / 功能层（应用服务器）/ 数据层	职责清晰、可集中维护	比两层复杂
B/S	浏览器 + Web 服务器 + 数据库	零客户端安装、易维护、跨平台	交互体验受限、强依赖网络、服务器压力大
SOA	粗粒度服务 + ESB 企业服务总线 + 服务注册	松耦合、可复用、集成能力强	ESB 易成瓶颈与单点；治理复杂；重量级协议
微服务	细粒度、按业务能力/限界上下文拆分、独立数据库、独立部署、”智能端点、哑管道”	独立部署、技术异构、弹性伸缩、团队自治	分布式复杂度（一致性、事务、排错）、运维成本高、网络延迟
事件驱动架构 EDA	事件代理 / 消息中间件，生产者-消费者	极高解耦、天然异步、易扩展	顺序与一致性难保证；可观测性差
云原生	容器（Container）+ 服务网格（Service Mesh） + 无服务器（Serverless）+ 声明式 API	弹性、资源效率、交付快	学习曲线陡、供应商绑定、调试难

三张对比表（高频）：

维度	C/S	B/S
客户端	需安装专用客户端	浏览器，零安装
升级维护	每台客户端都要升级，成本高	只需升级服务器
交互体验	好（可利用本地资源）	较弱（受浏览器限制）
网络依赖	可离线部分工作	强依赖网络
安全	客户端可缓存数据，风险分散	集中在服务器，需重点防护

维度	SOA	微服务
粒度	粗粒度（企业级服务）	细粒度（单一业务能力）
通信	ESB 中心化，智能管道	API 网关 + 轻量协议（REST/gRPC），哑管道
数据	倾向共享数据库	每个服务独立数据库（Database per Service）
治理	集中治理、强规范	去中心化治理、团队自治
部署	整体/大包部署	独立部署、DevOps

维度	管道-过滤器	事件驱动（隐式调用）
控制流	显式的数据流驱动	隐式，由事件触发
构件是否知道对方	过滤器不知道上下游是谁（只认数据格式）	构件不知道谁会响应自己的事件
顺序确定性	确定	不确定
典型用途	数据转换流水线	GUI、告警、异步解耦

选型判定步骤（案例 10–15 分的答题骨架）：① 从需求中提取质量属性优先级（谁是第一位的？）→ ② 列出 2–3 个候选风格 → ③ 用质量属性场景逐一对照，说明每个候选满足什么、牺牲什么 → ④ 结合约束（预算、团队规模、遗留系统、工期）收窄 → ⑤ 给出结论并写明被否决方案的理由 → ⑥ 指出风险与触发重新评估的量化信号。

3.5 架构评估：ATAM、敏感点 / 权衡点、SAAM 与 CBAM

ATAM（Architecture Tradeoff Analysis Method，架构权衡分析法）——由 SEI 提出，用于在架构尚未实现时评估其满足多个质量属性目标的能力，核心是发现权衡点、敏感点与风险。

参与人员（三类，案例爱考）：

• 评估小组（Evaluation Team）：通常是外部的、独立于项目的 3–5 名架构评估专家，负责主持、分析、出报告
• 项目决策者（Project Decision Makers）：项目经理、客户代表、架构师——有权决定如何行动
• 架构涉众（Architecture Stakeholders）：开发、测试、运维、用户代表、安全/性能专家——受架构影响的人

四个阶段与九个步骤：

阶段	步骤	内容
一、演示	1	ATAM 方法表述（向涉众讲清楚流程与产出）
	2	商业动机表述（为什么做这个系统、约束、目标）
	3	架构表述（架构师讲架构，20 分钟内，含视图与约束）
二、调查与分析	4	架构方法分类（识别所用的架构风格与战术）
	5	生成质量属性效用树
	6	架构方法分析（针对高优先级场景，识别敏感点、权衡点、风险、非风险）
三、测试	7	头脑风暴与场景优先级排序（全体涉众提出场景并投票）
	8	架构方法再分析（用第 7 步的场景重复第 6 步）
四、报告	9	结果表述（效用树、风险、非风险、敏感点、权衡点、建议）

效用树（Utility Tree）——把”效用”逐层分解为可评估的具体场景：

效用（Utility）
└── 性能
    └── 延迟
        └── 场景：正常负载下质检员提交追溯查询，3 秒内返回结果　　(H, M)
    └── 吞吐量
        └── 场景：早班高峰期 200 人同时报工，成功率 ≥ 99.9%　　　(H, H)
└── 可用性
    └── 故障恢复
        └── 场景：中心数据库主库宕机，30 秒内切换，数据零丢失　　(M, H)
└── 可修改性
    └── 新增功能
        └── 场景：新增一种设备协议，3 人日内完成且核心代码零改动　(M, M)

每个场景后标注 （优先级，实现难度），优先级与难度用 H / M / L 表示。优先分析 (H,H) 与 (H,M) 的场景——优先级高且难度大的，才是真正的风险所在。

四个核心概念（最高频考点，必须能区分）：

概念	定义	关键区分
敏感点（Sensitivity Point）	一个或多个构件（或构件间关系）的特性，对实现某个特定质量属性的响应至关重要	只涉及一个质量属性
权衡点（Tradeoff Point）	同时影响多个质量属性的架构决策，且是至少一个质量属性的敏感点	多个质量属性敏感点的交集
风险（Risk）	潜在的、有问题的架构决策，可能导致不良后果	以”如果…那么…可能会…”表述
非风险（Non-risk）	经分析认为安全的架构决策	有明确的分析依据支撑”它不会出问题”

判定口诀：**”只动一个质量属性 → 敏感点；一动就动两个及以上 → 权衡点；可能出问题 → 风险；分析过认为没问题 → 非风险。”** 记住：权衡点一定是敏感点，敏感点不一定是权衡点。

本项目一组示例（考试照此写）：

• 敏感点：”追溯结果的缓存有效期”——它显著影响性能（有效期越长命中率越高），但不影响其他质量属性 → 性能敏感点。
• 权衡点：”检验记录是否同步写入中心库”——同步写提高一致性/可靠性（数据零丢失），但降低性能（写入延迟上升）与可用性（中心库故障时无法报工）→ 权衡点。
• 风险：”系统中所有追溯查询都依赖单一的 PostgreSQL 集群，若该集群出现脑裂，可能导致追溯链条读不到部分历史数据” → 风险。
• 非风险：”采集服务无状态设计，任一实例故障后可被任意其他实例接管，已有 3 次真实故障演练验证” → 非风险。

SAAM（Software Architecture Analysis Method）：最早的架构分析方法，以可修改性为主要目标，通过场景评估架构；适用于多个候选架构的粗粒度比较。步骤：场景开发 → 架构描述 → 单个场景评估 → 场景交互评估 → 总体评估。

CBAM（Cost Benefit Analysis Method，成本效益分析法）：在 ATAM 基础上加入经济建模，对每个架构策略估算成本、收益、ROI 与不确定性，回答”该花多少钱、能省多少钱、多久回本“。

维度	SAAM	ATAM	CBAM
主要目标	可修改性	多质量属性的权衡	权衡 + 经济决策
核心工具	场景	效用树 + 敏感点/权衡点/风险	效用树 + 成本/收益/ROI 模型
产出	架构比较结论	风险清单、权衡点	投资回报排序

3.6 ADR、中间件、构件标准与 Web 服务

ADR（Architecture Decision Record，架构决策记录）——把架构决策的”为什么”固化下来的短文档。它的价值不在于记录结论，而在于让半年后的人（包括你自己）知道当时为什么这么选、什么条件下应当推翻它。

ADR 六要素：

要素	内容	写作要点
标题与状态	编号 + 决策主题；状态：提议 / 已接受 / 已否决 / 已废弃 / 被取代（并注明取代者）	状态必须写，被取代的 ADR 要保留并链接到新的
背景（Context）	问题、约束、商业动机、相关质量属性	只写影响该决策的事实
决策（Decision）	明确的一句”我们决定…”	用主动语态，不给第二种解读
备选方案（Alternatives）	至少 2 个被考虑过的方案	必须包含被否决的，否则不构成论证
理由（Rationale）	为什么选它、为什么不选其他的	对照质量属性与约束逐条说明，这是 ADR 的核心
后果（Consequences）	正面、负面、风险、触发重新评估的量化信号	必须有量化信号，否则 ADR 无法被推翻，就不是决策而是教条

【ADR-001 本项目完整示例】

ADR-001：数据采集层采用”边缘网关 + 插件式适配器”而非直连采集
状态：已接受（2026-xx-xx）
背景：3 个厂区共 400 余台设备，其中约 120 台运行超过 10 年，无标准接口，协议涵盖 Modbus RTU/TCP、OPC DA、OPC UA、西门子 S7，以及 12 台只能通过文件导出的专有设备。设备部明确不接受更换 PLC（改造预算为 0）。IT 运维仅 2 人，无法承担复杂的分布式运维。目标可修改性场景：新增一种设备协议，3 人日内完成，核心代码零改动；目标可用性场景：中心网络中断 4 小时内，采集数据零丢失。
决策：在每个厂区部署一台边缘网关，网关上运行插件式协议适配器；适配器实现统一的 IDeviceAdapter 接口，通过运行时注册加入；采集数据先写入本地时序库 + 本地队列，再异步上传中心，网络中断时本地缓存、恢复后自动补传。
备选方案：
① 中心直连采集：中心服务直连设备。否决——设备协议差异全部涌入中心服务，可修改性极差；且中心与厂区之间网络中断即丢失数据，不满足零丢失。
② 购买商业数据采集平台（SCADA/工业网关套件）：否决——一次性许可费用超出本项目预算 40%，且专有平台难以满足”追溯链条可定制”的需求。
③ 更换或加装支持标准接口的 PLC：否决——设备部预算为 0，且停产改造时间与 18 个月工期冲突。
理由：插件式适配器把协议差异局部化在单个插件内（可修改性战术：隐藏信息 + 局部化变更 + 推迟绑定时间），是唯一能在”核心代码零改动”前提下支持 6 类协议的方案；本地队列与断点续传是可用性战术中的状态再同步，直接对应”网络中断零丢失”；边缘网关数量少（3 台），运维复杂度在 2 人团队的可承受范围内。
后果：正面——新增协议不影响中心服务，可并行开发；负面——边缘网关成为单点（单厂区），且需要管理插件版本与灰度发布；风险——若某厂区网关宕机超过本地缓存容量（按当前配置约 72 小时），将发生数据丢失；缓解——每厂区部署 2 台网关做主备（被动冗余），缓存水位超 50% 自动告警。触发重新评估的量化信号：① 单厂区设备数超过 300 台导致单台网关 CPU 持续 > 70%；② 新增协议的适配工作量连续 2 次超过 5 人日；③ 边缘缓存告警月度超过 3 次。

中间件（Middleware）：位于操作系统与网络之上、应用软件之下的系统软件，屏蔽分布环境的异构性，提供通信、事务、安全、数据访问等通用服务。

类别	代表	用途
远程过程调用（RPC）中间件	gRPC、Dubbo、Thrift	像调本地方法一样调远程服务
消息中间件（MOM）	Kafka、RabbitMQ、RocketMQ	异步解耦、削峰填谷、可靠投递
数据访问中间件	ODBC、JDBC	屏蔽数据库差异
事务中间件 / 交易中间件（TP Monitor）	Tuxedo	分布式事务与并发控制
对象请求代理（ORB）	CORBA 的 ORB	跨语言跨平台的对象互操作
Web 应用服务器	Tomcat、WebLogic、JBoss	承载 Web 与 EJB 应用
企业服务总线（ESB）	Mule、WSO2	SOA 中的服务集成与路由

构件（Component）与三大构件标准：

标准	提出方	核心机制	特点
CORBA	OMG	ORB（对象请求代理）+ IDL（接口定义语言）+ IIOP 协议	跨语言、跨平台、跨操作系统，最开放，但复杂
EJB	Sun（Java）	EJB 容器 + 会话 Bean / 实体 Bean / 消息驱动 Bean	运行在 EJB 容器中，限于 Java 生态
COM / DCOM / COM+	Microsoft	组件对象模型，注册表	Windows 平台为主
.NET 程序集（Assembly）	Microsoft	CLR + 程序集	Windows 生态，与 COM 兼容演进

Web 服务：SOAP 体系 vs REST

维度	SOAP / WSDL / UDDI 体系	REST
三核心	WSDL（Web 服务描述语言，描述接口）、SOAP（简单对象访问协议，消息封装与传输）、UDDI（统一描述、发现与集成，服务注册与发现）	无独立标准，依托 HTTP
抽象视角	面向服务/操作（动词）	面向资源（名词）
传输	可绑 HTTP、SMTP、TCP 等	仅 HTTP
消息格式	仅 XML	JSON / XML / 任意
状态	可有状态	无状态
开销	重量级（信封 + WS-* 系列）	轻量级
适用	企业级集成、需强契约与事务的场景	互联网 API、移动后端、轻量集成

本项目立场：对外集成（与 ERP、质量监管平台）用 REST + JSON（轻量、易联调）；对内的采集指令与报警走消息中间件（异步、可靠）；不使用 ESB——运维仅 2 人，ESB 会成为新的瓶颈与单点。

四、典型考法

4.1 综合知识怎么考

题 1：Kruchten 提出的”4+1”视图模型中，不属于四个技术视图、而用于串联与验证其他视图的是（　　）。　A. 逻辑视图　B. 进程视图　C. 开发视图　D. 场景
答案：D。解析：四个技术视图为逻辑、进程、开发、物理；**”+1”是场景（Scenarios / 用例视图）**，用于把前四个视图联系起来并验证其一致性。

题 2：质量属性场景的六要素不包括（　　）。　A. 刺激源　B. 刺激　C. 环境　D. 测试用例
答案：D。解析：六要素为刺激源、刺激、环境、制品、响应、响应度量。测试用例是实现层的产物，不属于场景描述要素。

题 3：下列属于可修改性战术中”防止连锁反应”的是（　　）。　A. 引入并发　B. 使用仲裁者（中介者/外观）　C. 心跳检测　D. 提高计算效率
答案：B。解析：使用仲裁者是可修改性战术中”防止连锁反应”的典型手段；A、D 属性能战术（资源管理 / 资源需求），C 属可用性战术（错误检测）。

题 4：关于 SOA 与微服务，下列说法错误的是（　　）。　A. SOA 通常采用 ESB 作为中心化集成枢纽　B. 微服务强调每个服务拥有独立的数据存储　C. 微服务强调”智能端点、哑管道”　D. 微服务的服务粒度通常比 SOA 更粗
答案：D。解析：微服务粒度比 SOA 更细（SOA 是粗粒度的企业级服务）；A、B、C 均正确。

题 5：ATAM 评估中，某架构决策”提高数据刷新频率”能显著提升数据实时性，但会明显增加系统资源消耗，因而同时影响性能与可用性。该决策属于（　　）。　A. 敏感点　B. 权衡点　C. 风险　D. 非风险
答案：B。解析：同时影响多个质量属性且是其中至少一个的敏感点 → 权衡点。只影响单一质量属性的才是敏感点。

4.2 案例分析怎么考

【案例题】（共 25 分）

承接本项目。系统分析师正在为”生产执行 + 质量追溯一体化”系统做架构设计。已知约束与诉求：
① 3 个厂区、约 400 台设备，其中约 120 台为运行 10 年以上的老设备，无标准接口，协议包括 Modbus RTU/TCP、OPC DA、OPC UA、S7，另有 12 台只能通过文件导出；设备部不接受更换 PLC（改造预算为 0）。
② 生产部要求：看板秒级刷新，早班高峰期约 200 人同时报工。
③ 质量部要求：追溯链条数据零丢失，检验记录不可篡改，追溯查询 3 秒内返回。
④ IT 运维仅 2 人，明确表示”运维不了的架构我们不接受”。
⑤ 预算受限，18 个月内必须上线一期。

【问题 1】（10 分） 请从下列架构风格中选择一种作为本系统的整体架构风格，并写出完整的选型论证：分层 C/S、SOA（含 ESB）、微服务、事件驱动架构（EDA）。要求：至少对比 2 个候选方案，说明各自满足与牺牲了什么质量属性，并结合约束给出结论。
【问题 2】（8 分） 用质量属性场景六要素描述”追溯查询 3 秒”这一需求，并针对”采集数据零丢失”给出至少 3 条具体的可用性战术及在本项目中的落点。
【问题 3】（7 分） 架构评审中，有人提出：”检验记录在写入时同步写入中心库副本，以保证数据绝对不丢。”请判断该决策属于敏感点、权衡点、风险、非风险中的哪一类并说明理由；再结合本项目指出 1 个风险与 1 个非风险各是什么。

采分点拆解：

• 问题 1（10 分）：提取质量属性优先级 1 分；候选方案对比 4 分（至少 2 个，各 2 分，必须说明满足什么 + 牺牲什么）；结合约束 3 分（必须提到设备改造预算为 0、运维仅 2 人、预算受限、18 个月工期中至少 3 项）：结论与理由 2 分。只写结论不对比的，最高得 3 分。
• 问题 2（8 分）：六要素 3 分（每缺一个要素扣 0.5 分，响应度量无数字扣 1 分）；可用性战术 5 分（每条 1.5 分，其中战术名称 0.5 + 本项目落点 1），只写战术名称不写落点的每条只给 0.5 分。
• 问题 3（7 分）：归类判断 2 分 + 理由 2 分（理由必须点明”同时影响了两个及以上质量属性”）；风险 1.5 分；非风险 1.5 分（非风险必须有分析依据，只说”这没问题”不得分）。

标准作答范例

【问题 1】

第一步：提取质量属性优先级。 从②③⑤可提取：第一位是可用性/可靠性（数据零丢失是硬约束，质量部不接受任何丢失）；第二位是性能（看板秒级、追溯 3 秒、200 并发）；第三位是可修改性（6 类协议、边缘适配，必须支持新增协议不改核心）；安全性（不可篡改）为刚性但局部需求；成本与可运维性（②④）是贯穿全局的约束而非目标。

第二步：候选方案对比。

候选	满足什么	牺牲什么	与约束的冲突
A. SOA + ESB	集成能力强（有利于对接 ERP、质量监管平台）；服务可复用	ESB 中心化会成为性能瓶颈与单点故障（看板秒级刷新与 200 并发下首当其冲）；治理复杂	运维仅 2 人，ESB 的运维与调优超出团队能力；许可费用与预算受限冲突
B. 微服务	独立部署、技术异构（有利于按协议做独立适配服务）、弹性伸缩、团队自治	分布式复杂度高（跨服务一致性、链路追踪、排错难）；运维成本最高	运维仅 2 人 + 预算受限 + 18 个月工期三者同时与之冲突；本项目规模（400 台设备、2000 员工）远未达到必须微服务的量级
C. 事件驱动架构 EDA	极高解耦、天然异步、削峰填谷（200 人同时报工）、易扩展	响应顺序不确定，难保证追溯链条的完整性顺序；可观测性差	与”追溯链条必须完整可验证”（③）存在张力；调试难度与”运维 2 人”冲突

第三步：结论。 采用”分层 + 局部事件驱动”的混合架构：整体为分层架构（感知/采集层 → 边缘网关层 → 服务层 → 应用层 → 展现层），在采集与看板推送这两条链路上局部引入事件驱动（消息中间件做异步解耦与削峰），不采用 ESB，不采用全面微服务化。

理由：① 分层职责清晰、可替换、易维护，且运维复杂度最低，直接回应”运维仅 2 人”；② 在采集与看板这两条确实是高并发、强异步的链路上局部用 EDA，既拿到”削峰填谷”的好处，又把”顺序不确定”的风险限制在可控范围内——追溯链条的组装仍走同步请求-响应，保证完整性可验证；③ 拒绝 ESB 是因为它在本项目中收益（集成 ERP，仅 1 个对接点）远小于代价（瓶颈、单点、运维）；④ 拒绝全面微服务化是因为本项目规模远未达到微服务的适用量级，而运维成本是压倒性约束——“用 2 个人运维 30 个微服务”不是架构，是事故。

【问题 2】

（1）”追溯查询 3 秒”的质量属性场景：

要素	内容
刺激源	质检员（或质量监管平台调用）
刺激	提交批次追溯查询请求（指定批次号、追溯方向与深度）
环境	系统正常运行，处于早班高峰（约 300 并发），追溯数据库累计约 5000 万条检验记录
制品	追溯服务 + 追溯数据库（完整系统）
响应	系统按方向与深度检索工单、报工、检验记录、设备参数与原材料信息，组装追溯链条（含时间戳与数字签名），返回报告，并将本次查询写入审计日志
响应度量	99% 的请求在 3 秒内返回结果；失败率 < 0.1%；链条节点不得静默省略（数据缺失须显式标注）

（2）”采集数据零丢失”的可用性战术（≥3 条）：

战术	分类	本项目落点
① 状态再同步（State Resynchronization）	错误恢复	边缘网关在中心网络中断期间把采集数据写入本地时序库 + 本地持久化队列，网络恢复后按时间戳自动补传，中心侧按序号去重；这是”零丢失”的核心机制
② 心跳 / Ping-Echo	错误检测	边缘网关每 30 秒向中心发送心跳；中心连续 3 次未收到即判定该厂区链路异常并告警，把该厂区的”数据完整性”状态在看板上标黄
③ 被动冗余（暖备 / Spare）	错误恢复	每个厂区部署 2 台边缘网关做主备，主网关故障时备用网关接管采集；中心数据库主备热切换，RPO = 0
④ 进程监视器 + 事务	错误预防	采集进程由守护进程监视，异常退出 5 秒内自动拉起；每条采集记录写入本地库时使用事务，保证”采集一半”不会产生半条记录

【问题 3】

（1）归类：该决策属于【权衡点】。

理由：同步写入中心库副本这一决策同时影响多个质量属性——一方面它提高可靠性/一致性（数据零丢失，直接满足质量部诉求），另一方面它降低性能（每次采集写入都要等待中心库往返确认，写延迟上升，200 并发下会拖垮报工响应）并降低可用性（中心库或厂区—中心网络故障时，采集将阻塞甚至失败，反而造成数据丢失，与初衷相反）。因为它同时是可靠性与性能（至少两个）质量属性的敏感点，所以它是权衡点，而不是单纯的敏感点。

我的处理建议：改为**”本地持久化优先 + 异步可靠投递”——先写本地（保证不丢），再异步上传（保证性能），用确认与重传**保证最终一致，把”零丢失”与”低延迟”从二选一变成两者兼得。

（2）一个风险：

边缘网关的单点风险——若某厂区唯一的边缘网关宕机，且本地缓存耗尽（按当前配置约 72 小时），将发生该厂区的数据丢失，而质量部要求”零丢失”。缓解措施：每厂区部署 2 台网关做被动冗余；本地缓存水位超过 50% 触发告警；超过 80% 时自动降低非关键参数的采样频率。

（3）一个非风险：

采集服务无状态设计不构成风险——采集服务被设计为完全无状态（不保存任何会话与中间结果，全部状态在消息队列与数据库中），任一实例故障后可被任意其他实例即时接管，无需状态迁移。依据：已在测试环境完成 3 次故障演练（强制 kill 进程、断网、主机重启），平均恢复时间 8 秒，期间数据零丢失。因此判定为非风险。

五、易错点（Rethink）

错误认知	为什么错	正确理解
“4+1 视图里，场景是四个技术视图之外的那个 +1，可有可无”	忽略了它的驱动与检验作用	场景是唯一能验证四个视图是否自洽的手段；画完视图必须用场景逐条跑一遍
“质量属性场景就是非功能需求”	少了度量就不是场景	六要素缺一不可，响应度量必须有数字；”响应要快”不是场景，是愿望
“敏感点和权衡点差不多”	这是最高频失分点	敏感点只影响一个质量属性；权衡点同时影响多个。权衡点必是敏感点，反之不然
“非风险就是没风险，不用写依据”	非风险是分析结论	非风险必须给出可分析的依据（演练数据、设计论证），只说”没问题”不算
“微服务一定比 SOA 先进、比分层的更好”	架构没有优劣，只有适配	架构风格无绝对好坏，只有与质量属性和约束的匹配度；运维 2 人的团队上 30 个微服务是灾难
“ESB 是 SOA 的核心，所以任何集成都要上 ESB”	忽略瓶颈与单点代价	集成点少、并发高、运维弱的场合，ESB 的代价大于收益；现代做法是 API 网关 + 点对点轻量集成
“管道-过滤器与事件驱动是一回事，都是过滤器串起来”	控制方式不同	管道-过滤器是显式的数据流驱动，过滤器只认数据格式；事件驱动是隐式调用，构件不知谁会响应，顺序不确定
“黑板系统适合有确定解法的常规业务”	用错了场景	黑板适合无确定算法、需多知识源协作的复杂问题（语音识别、模式识别）；常规业务用分层即可
“推迟绑定时间会让系统变慢，所以不用”	只看性能一	推迟绑定是可修改性战术（运行时注册、配置、多态），牺牲少量性能换可扩展性，是权衡不是优劣
“ADR 只要写清楚决策结论就行”	结论最不重要	ADR 的价值在备选方案、理由、以及”什么条件下推翻它”的量化信号；没有触发信号的 ADR 是教条不是决策
“WSDL 是消息传输协议”	三个标准记混	WSDL 描述接口、SOAP 传输消息、UDDI 注册与发现；REST 无独立标准，依托 HTTP，面向资源
“CORBA 是微软的构件标准”	提出方记错	CORBA = OMG（跨语言跨平台）；EJB = Sun/Java；COM/DCOM/COM+ = Microsoft

六、GRASPS 推进（Experience）

本周五前，往交付物「架构设计说明书」里加三块内容，总计 1500–1800 字 + 一张表 + 一份 ADR：

1. 4+1 视图五张图（逻辑 / 进程 / 开发 / 物理 / 场景各一张）。物理视图必须体现 3 厂区 + 边缘网关主备 + 中心机房 + 灾备；进程视图必须至少 1 处异步、1 处并发；场景视图至少 5 个场景，其中 3 个必须写全六要素。
2. 质量属性场景表：不少于 10 个具体场景，覆盖性能、可用性、安全性、可修改性、可测试性 5 个质量属性，每行写全六要素并标注（优先级, 难度）。表下附一段 300 字说明：哪两个场景之间存在冲突，你打算如何权衡。
3. 架构风格选型论证 + ADR-001：选型论证 500 字（至少 2 个候选 + 约束对照 + 结论）；ADR-001 按六要素完整写（照 3.6 示例），必须含至少 3 个被否决方案、至少 3 条触发重新评估的量化信号。

验收标准：把质量属性场景表给生产部、质量部、设备部各看一遍，每个部门至少能认领 2 条场景并说出”这条是我们提的”——认领不出来的场景，说明不是从需求里来的，是你自己编的；ADR-001 里的每一条量化信号，你都能说出”现在的值是多少、到多少就要改”；把 ADR 给一个没参与项目的同事看，他能在 3 分钟内说清”为什么不用 ESB”——说不清，就是理由没写透。

七、自测

1. “4+1”视图模型中，用于描述系统并发与同步的是（　　）。　A. 逻辑视图　B. 进程视图　C. 开发视图　D. 物理视图
2. 质量属性场景六要素中，”系统处于正常运行还是过载/降级状态”对应的是（　　）。　A. 刺激源　B. 环境　C. 制品　D. 响应度量
3. 下列不属于性能战术的是（　　）。　A. 引入并发　B. 缓存　C. 固定优先级调度　D. 使用中介者
4. 可用性战术中，”心跳检测”属于（　　）。　A. 错误检测　B. 错误恢复　C. 错误预防　D. 资源仲裁
5. 可修改性战术中，”运行时注册组件”属于（　　）。　A. 局部化变更　B. 防止连锁反应　C. 推迟绑定时间　D. 错误预防
6. 适合”无确定解法、需多个知识源协作”的复杂问题的架构风格是（　　）。　A. 分层　B. 黑板系统　C. 管道-过滤器　D. 主程序-子程序
7. 关于管道-过滤器风格，下列说法错误的是（　　）。　A. 过滤器之间松耦合，可复用　B. 支持并发执行　C. 适合交互式应用　D. 数据格式转换会带来额外开销
8. ATAM 中，”某决策同时影响性能与安全性”属于（　　）。　A. 敏感点　B. 权衡点　C. 风险　D. 非风险
9. Web 服务三标准中，用于服务注册与发现的是（　　）。　A. WSDL　B. SOAP　C. UDDI　D. REST
10. 下列构件标准中，由 OMG 提出、支持跨语言跨平台互操作的是（　　）。　A. CORBA　B. EJB　C. COM+　D. .NET

题号	1	2	3	4	5
答案	B	B	D	A	C
一句话解析	进程视图管并发、同步、分布、性能、可伸缩；逻辑管功能，开发管模块组织，物理管部署拓扑	环境 = 刺激发生时系统的状态（正常/过载/降级/受攻击）	使用中介者是可修改性战术（防止连锁反应）；并发、缓存、调度均属性能	心跳/Ping-Echo 是错误检测；主动/被动冗余是恢复；进程监视器、事务是预防	运行时注册属推迟绑定时间，与配置文件、多态、组件更换同族

题号	6	7	8	9	10
答案	B	C	B	C	A
一句话解析	黑板系统专为无确定算法、多知识源协作的复杂问题设计（语音识别、模式识别）	管道-过滤器不适合交互式应用（批处理特征、延迟大、错误处理难）	同时影响多个质量属性 → 权衡点；只影响一个才是敏感点	UDDI = 注册与发现；WSDL = 描述接口；SOAP = 消息封装与传输	CORBA = OMG（ORB + IDL + IIOP，跨语言跨平台）；EJB = Sun；COM+/.NET = 微软

八、分档任务（Tailor）

• 保底 45：背熟 3.1 的 4+1 视图表、3.2 的六要素模板、3.3 的四族战术骨架（性能=需求/管理/仲裁，可用性=检测/恢复/预防，安全性=抵抗/检测/恢复，可修改性=局部化/防连锁/推迟绑定）、3.5 的四个概念区分、3.6 的 SOAP/Web 三标准与构件标准归属；完成 4.1 五题与自测十题。
• 冲 60：完成 GRASPS 三件产出；案例 4.2 三问手写完整作答并对照采分点自评；能默写 3.2 的六要素模板并用它改写 5 条你项目里的非功能需求（每条都要补上原本缺失的数字）。
• 冲 70：把本项目换成政务大数据平台场景重做一次架构选型论证（约束改为：数据不出域、等保三级、多委办局共建），要求结论与本项目的”分层 + 局部 EDA”不同并说明为什么约束不同导致结论不同；为”是否引入 ESB”单独写一份 ADR-002，列出 4 个备选与各自成本量级；自命题一道”指出权衡点并说明缓解措施”的案例题并写出采分点。

九、本阶段回答基本问题

Q2（第一次正式回答）：在没有唯一最优解的世界里，怎么证明一个架构是”好的”？决策如何被论证？

第一，架构的”好”不能靠技术先进度证明，只能靠”在特定约束下对特定质量属性的满足程度”证明。 CIO 那句”你怎么向我证明”，答案从来不是”微服务更先进”，而是”在 200 并发、5000 万条记录的环境下，质检员的追溯查询 99% 在 3 秒内返回“。没有度量的架构描述是审美，有度量的才是工程。 这就是为什么质量属性场景的六要素里，响应度量是压轴的那一个——前五个要素讲的是”发生了什么”，第六个才回答”算不算好”。

第二，证明的关键动作是”把冲突摆到桌面上”，而不是”把冲突藏起来”。 架构评估的所有价值都集中在权衡点上：同步写中心库提高可靠性却损害性能、降低采样频率提升性能却损害数据完整性、引入缓存提升性能却损害一致性。一个从不暴露权衡点的架构评审，不是评审通过，是评审失效。 ATAM 之所以要分四阶段、拉三类人、做九步走，就是为了让不同部门把彼此冲突的诉求同时放在一张效用树上，逼着决策者看见”你要的 A 会伤害他的 B”。

第三，决策要被论证，就必须能被推翻——这就是 ADR 存在的全部意义。 一份 ADR 最不重要的部分是”我们决定用 X”，最重要的是”我们否决了 Y 和 Z，理由是……“以及”当出现信号 S1/S2/S3 时，这个决策应当被重新评估“。不能被推翻的决策不是决策，是教条；没有触发信号的 ADR 会在两年后变成无人敢动的技术债。 我在 ADR-001 里写的”边缘缓存告警月度超过 3 次”就是这样一个信号——它让半年后的人不必猜测，只需看数据。

第四，”好的架构”是与组织能力匹配的架构，不是纸面上最优的架构。 本项目的压倒性约束是运维只有 2 人。这个约束一摆出来，微服务和 ESB 就同时出局了——不是它们不好，是我们的组织养不起它们。分层 + 局部事件驱动未必是性能最优解，但它是”2 个人能运维、18 个月能上线、预算能覆盖”的解。架构决策的第一性问题不是”技术上能不能做到”，而是”这个组织能不能长期承受它”。

第五，被记录的权衡才是资产。 半年后新人问”为什么这里不用微服务”，一份 ADR 五分钟解答；没有 ADR，这个问题要靠一次两小时的会议和三个人的记忆来回答，而且答案会随人而异。架构的可追溯性，与需求的可追溯性（S02）同等重要——二者都是”让决策可被复核”的基础设施。

Q2 到此有了第一层答案：用质量属性场景把它量化（六要素），用 ATAM 把冲突暴露出来（敏感点/权衡点/风险），用 ADR 把论证与推翻条件写下来（背景/决策/备选/理由/后果）。 但”架构风格选定”只是开始——接口怎么定、模块怎么拆、模式怎么选，才是让架构落地的关键，那是 S07 的事。而到 S11，当新技术（云原生、边缘计算、中台）进入视野时，Q2 会被第二次追问：同样的权衡方法，面对快速变化的技术环境还够不够用？