面向期末 - 架构复习

架构复习

考试形式：英文卷面，中文作答。复习目标：看到英文题干能识别考点，中文能写出结构化答案，案例题能说明架构决策、质量属性权衡和图中元素。

最高优先级速背

一页纸总表

考点	必背句
软件架构定义	软件架构是系统的一个或多个结构，包括软件元素、元素外部可见属性以及元素之间的关系；也包括指导系统设计和演化的原则。
Architecture vs Design	所有架构都是设计，但不是所有设计都是架构；架构关注高层、系统级、重要且难以改变的设计决策。
质量属性场景	用六要素 source、stimulus、artifact、environment、response、response measure 结构化描述质量需求。
ASR	ASR 是对架构产生重大影响的需求，包括关键质量属性、关键约束、核心功能和高风险需求。
Tactic	战术是影响某个质量属性响应控制方式的设计决策。
Architecture Pattern	架构模式是宏观结构级的可复用解决方案，通常组合多个战术。
Views	多视图用于服务不同利益相关者和关注点；单个视图无法表达完整架构。
ATAM	ATAM 用质量属性场景分析架构决策，识别风险、非风险、敏感点和权衡点。
ADD	ADD 以架构驱动因素为输入，通过迭代选择驱动因素、细化元素、选择设计概念、记录决策来生成架构。
C&C	C&C style 描述运行时组件和连接器的交互结构。
SOA	SOA 通过服务契约、封装、复用、组合、自治、无状态等原则提高企业系统互操作和复用。
Microservices	微服务围绕业务能力拆分服务，服务独立开发、部署、扩展和演进。

英文题干识别

题干关键词	立刻想到
stimulus-response / six elements	质量属性场景六要素
response measure	质量需求可测试、可量化
ASR / architecturally significant	架构显著需求及来源
utility tree	质量属性逐层拆解、重要性和风险排序
views / viewpoints	多视图文档化
implementation units	Module views
runtime behavior and interactions	C&C views
non-software environment	Allocation views
4+1	Logical、Process、Physical、Development、Scenarios
ATAM	风险、非风险、敏感点、权衡点、utility tree
ADD 3.0	七步迭代式架构设计方法
design strategies	decomposition、abstraction、divide and conquer、generate and test、iteration、reuse
C&C style	components、connectors、attachments、ports、roles
SOA	service contract、ESB、interoperability
microservices	business capabilities、decentralization、smart endpoints and dumb pipes
Strangler Fig	遗留系统逐步替换
Broker	分布式对象/服务解耦、中介、动态发现
Pipe-and-Filter	Filter + Pipe，数据流处理

质量属性场景

定义与六要素

质量属性场景是描述质量需求的标准模板。它把“系统要高可用、性能好、易修改”这类模糊要求，写成可分析、可测试的结构。

Element	中文	含义
Source of Stimulus	刺激源	谁产生刺激，例如用户、外部系统、攻击者、开发人员
Stimulus	刺激	发生了什么，例如请求、故障、攻击、变更请求
Artifact	制品 / 受影响对象	哪部分系统受到影响，例如服务、组件、数据、接口
Environment	环境	刺激发生时系统处于什么状态，例如正常运行、峰值负载、开发时
Response	响应	系统如何反应，例如处理请求、检测故障、拒绝访问、完成修改
Response Measure	响应度量	如何量化响应是否达标，例如 2 秒内、99.9%、3 人天内

默写模板：

一个质量属性场景包括六个部分：刺激源、刺激、受影响制品、环境、响应和响应度量。
它描述在某个环境下，某个刺激源对系统某部分发出刺激，系统应产生什么响应，以及用什么量化指标判断响应是否满足要求。

考试常考质量属性场景表

这张表可以直接当作 quality attribute scenario 的填空模板。考试如果让你画 stimulus-response 图，就从表中选对应质量属性，把六要素展开即可。

质量属性	刺激源	刺激	工件	环境	响应	响应度量	对应 tactic / 设计理由
Availability	Heartbeat 监视器	服务器无响应	进程	正常操作	通知操作者，并继续运行	没有停机时间	heartbeat 用于 detect faults；process monitor / failover 用于自动恢复或继续服务
Interoperability	本车车辆信息系统	发送当前位置	路况监控系统	系统在运行前已知	路况监控系统将当前位置与其他信息结合，叠加到 Google Maps 上，并进行广播	我们的信息在 99.9% 的时间被正确包含	discovery service 用于 locate；orchestrate / tailor interface 用于管理多个系统接口和响应处理
Modifiability	开发者	希望修改 UI	代码	设计时	修改完成并进行单元测试	在 3 小时内完成	encapsulate / use an intermediary 降低 UI 与业务逻辑耦合；defer binding 让 UI 变化更局部
Performance	用户	发起事务	系统	正常操作	事务被处理	平均延迟为 2 秒	prioritize events / reduce overhead 控制资源需求；introduce concurrency / caching 管理资源
Security	来自远程地点、心怀不满的员工	尝试修改薪酬标准	系统内数据	正常操作	系统维护审计追踪	正确数据在 1 天内恢复，并识别篡改来源	authenticate / authorize actors 控制访问；verify message integrity / audit log 追踪篡改
Testability	单元测试者	代码单元完成	代码单元	开发时	结果被捕获	3 小时内达到 85% 的路径覆盖	specialized interfaces 控制和观察状态；record/playback 记录测试过程和结果
Usability	用户	下载新应用	系统	运行时	用户高效地使用应用	经过 2 分钟试用 / 探索即可达到	maintain task model / user model 提供引导；cancel、undo、feedback 降低误操作成本

General Scenario vs Concrete Scenario

• General scenario：通用场景，与具体系统无关，是质量属性需求的模板。
• Concrete scenario：具体场景，针对某个具体系统，必须包含具体刺激、具体环境和可度量指标。

答题句：

General scenario 用来帮助生成需求，concrete scenario 才是真正可用于某个系统架构设计和评估的质量属性需求。

质量属性场景图模板

对应往年题

• 2015：How to model quality attribute scenarios? Graphically model availability and performance.
• 2017：Graphically model availability and modifiability.
• 2018：Graphically model availability and modifiability.
• 2019：Graphically model interoperability and modifiability.
• 2025：如何描述质量属性场景，描述互操作性和性能的质量属性场景。

质量属性

这一节按单个质量属性复习。每个质量属性都要掌握四类内容：

• 定义：这个属性到底衡量什么；
• 识别词：英文题干里出现什么词要想到它；
• 场景：六要素怎么填；
• 战术：架构上通常怎么实现或改善它。

Availability 可用性

定义：

系统在需要使用时能够提供服务的比例。

常见指标：

Availability = MTBF / (MTBF + MTTR)

其中：

• MTBF = Mean Time Between Failures，平均故障间隔时间。
• MTTR = Mean Time To Repair，平均修复时间。
• MTBF 越大、MTTR 越小，可用性越高。
• 有计划的关闭状态通常不计入不可用时间。

影响不可用时间的阶段：

• detect failure：检测故障。
• correct failure：修复故障。
• restart application：重启应用。

Fault、Error、Failure 区分：

Fault -> Error -> Failure
故障根因 -> 内部错误状态 -> 对外服务失效

概念	含义	例子
Fault	故障根因，导致错误的原因	代码缺陷、硬件损坏、配置错误
Error	系统内部出现的错误状态	内存中算出了错误结果、状态变量异常
Failure	系统对外没有提供预期服务	用户看到错误页面、请求超时、服务不可用

Outage 是服务中断。Recoverability 可恢复性会影响 Availability，它指系统在发生故障后恢复到原有或可接受状态，并找回或修复受影响数据的能力。

FMECA：

FMECA = Failure Mode, Effects, and Criticality Analysis
故障模式、影响和严重性分析

它用来分析系统可能以什么方式失败、失败造成什么影响、这个失败有多关键。架构设计不能假设系统永远不坏，而要提前考虑检测、隔离、恢复和降级。

六要素	可用性典型内容
Source	内部组件、外部系统、运维人员
Stimulus	fault、crash、omission、incorrect response
Artifact	进程、服务、通信通道、存储、节点
Environment	正常运行、降级模式、过载模式
Response	检测、记录、通知、切换、恢复、降级服务
Measure	检测时间、恢复时间、可用性百分比、丢失请求数

可直接写的场景：

当系统正常运行时，某个服务实例发生崩溃，故障检测机制应在 5 秒内发现故障，并在 30 秒内将请求切换到备用实例，使 99% 的用户请求不失败。

核心战术：

• Detect faults 检测故障：
  • ping / echo：主动询问组件是否仍有响应。
  • heartbeat：组件定期发送“我还活着”的信号，超时未收到就认为组件故障。
  • voting：多个冗余组件计算结果后投票，偏离多数结果的组件可能出错。
  • exception：通过异常机制检测运行时错误，如超时、连接失败、非法输入。
• Recover from faults 故障恢复：
  • active redundancy：所有冗余组件并行响应并保持相同状态，故障后快速切换。
  • passive redundancy：主组件响应请求并同步状态给备用组件，主故障后备组件接管。
  • spare：准备备用计算平台，成本较低但恢复较慢。
  • shadow operation：修复组件先影子运行，确认行为正确后再恢复服务。
  • state re-synchronisation：恢复组件上线前先同步到最新状态。
  • checkpoint / rollback：保存稳定状态，故障后回滚。
• Prevent faults 预防故障：
  • removal from service：在组件可能故障前先移出服务进行维护。
  • transaction：多个步骤绑定成一个整体，失败时整体撤销。
  • process monitor：监控进程故障并自动创建新进程实例。

Performance 性能

定义：

性能关注时间以及软件系统满足时序要求的能力。

所有系统都有性能需求，即使题目没有显式写出来。

响应时间由两部分构成：

• processing time：处理时间，系统正在处理响应。
• blocked time：阻塞时间，系统无法响应或等待资源。

常见响应度量：

度量	含义
latency	从请求发出到响应返回的延迟
deadline	必须完成响应的最后期限
throughput	单位时间内处理的请求数或事务数
jitter	响应时间波动
miss rate	未满足 deadline 或响应要求的比例

六要素	性能典型内容
Source	用户、外部系统、定时器
Stimulus	请求到达、事件流、周期事件
Artifact	服务、组件、队列、数据库
Environment	正常负载、峰值负载、过载
Response	处理请求、返回结果、调整优先级、降级
Measure	latency、deadline、throughput、jitter、miss rate

可直接写的场景：

在系统处于正常负载时，用户提交查询请求，查询服务应处理该请求并在 2 秒内返回结果，95% 的请求满足该响应时间。

核心战术：

• Control resource demand 控制资源需求：
  • manage sampling rate：降低采样频率，减少需要处理的数据量。
  • limit event response：事件到达过快时排队或限制响应，避免压垮系统。
  • prioritize events：关键事件优先处理，低优先级事件延后、降级或丢弃。
  • reduce overhead：减少重复计算、数据转换、通信和中间层开销。
• Manage resources 管理资源：
  • increase resources：增加 CPU、内存、网络、机器等资源。
  • introduce concurrency：通过多线程、多进程、异步任务提高吞吐量。
  • maintain multiple copies of computations：多个计算副本配合负载均衡。
  • maintain multiple copies of data：缓存或数据复制，提高读取性能，但要处理一致性。

Modifiability 可修改性

定义：

可修改性关注进行修改所需要的时间或金钱成本，以及修改会影响到的范围。

修改成本不仅包括代码修改，也包括理解、测试、部署和风险。

规划可修改性的四个问题：

• What can change? 什么可能变化？
• What is the likelihood of the change? 变化可能性多大？
• When is the change made and who makes it? 何时变化，由谁变化？
• What is the cost of the change? 变化成本是多少？

Environment 常写变化发生的生命周期阶段：

• design time：设计时。
• compile time：编译时。
• build time：构建时。
• deployment time：部署时。
• runtime：运行时。

Response measure 常写：修改时间、修改成本、影响模块数、引入缺陷数。

六要素	可修改性典型内容
Source	开发人员、管理员、业务人员、外部系统
Stimulus	变更请求，例如新增功能、修改接口、改变数据模型
Artifact	模块、接口、数据、配置、组件
Environment	设计时、编译时、部署时、运行时
Response	定位修改点、完成修改、测试、部署
Measure	修改时间、成本、影响模块数、引入缺陷数

可直接写的场景：

在设计时，开发人员提出新增支付方式的变更请求，系统应只修改支付模块并新增一个支付适配器，在 3 人天内完成修改和回归测试。

核心战术：

• Reduce size of a module（减小模块规模）：
  • split module：大模块包含太多功能时，把它拆成更小、更专一的模块。
• Increase cohesion（提高内聚）：
  • increase semantic coherence：模块内部职责应服务同一目的，不相关职责应拆开。
• Reduce coupling（降低耦合）：
  • encapsulate：通过稳定接口访问模块，而不是依赖内部实现。
  • use an intermediary：用适配器、代理、服务层、消息队列等中介打断直接依赖。
  • refactor：移动职责、提取公共逻辑、重新划分边界，降低变化传播。
• Defer binding（推迟绑定 / 延迟绑定）：
  • 把参数、配置或实现选择推迟到部署、启动或运行时再决定。
  • 常见方式：配置文件、插件机制、依赖注入、运行时参数、服务发现。

Interoperability 互操作性

定义：

两个或多个系统在特定上下文中，通过接口有用地交换信息的程度。

两个层面：

• syntactic interoperability 语法互操作：能交换数据，格式、协议、接口能对上。
• semantic interoperability 语义互操作：能正确解释数据，双方对字段含义和业务语义理解一致。

互操作性需要识别：

with whom, with what, under what circumstances
和谁、交换什么、在什么情况下交换

两个重要方面：

• Discovery：服务消费者发现服务位置、身份和接口。
• Handling of response：响应是报告给请求者、发送给其他系统，还是广播给感兴趣方。

六要素	互操作性典型内容
Source	另一个系统、第三方服务
Stimulus	请求交换信息或调用服务
Artifact	接口、服务、协议、数据格式
Environment	运行时、服务发现时、集成时
Response	定位服务、交换信息、解释信息、返回结果
Measure	正确交换比例、延迟、新系统接入成本

核心战术：

• Locate：
  • discovery service：通过目录服务或注册中心定位服务，客户端不直接依赖具体服务地址。
• Manage interfaces：
  • orchestrate：用控制机制协调多个服务的调用顺序，例如订单流程中依次调用库存、支付、物流。
  • tailor interface：向接口中添加或移除能力，使接口更适合特定调用方，避免暴露过多功能。

Security 安全性

定义：

安全性衡量系统保护数据和信息、防止未授权访问，同时仍为授权用户提供访问的能力。

CIA = Confidentiality + Integrity + Availability

CIA 三要素：

要素	含义
Confidentiality 机密性	数据和服务免受未授权访问
Integrity 完整性	数据和服务不被未授权篡改
Availability 可用性	系统可供合法用户使用

六要素	安全性典型内容
Source	攻击者、授权用户、恶意内部人员
Stimulus	访问、修改、删除、拒绝服务攻击、伪造消息
Artifact	数据、服务、通信链路、账户
Environment	正常运行、被攻击、离线、维护
Response	认证、授权、加密、检测、记录、拒绝、恢复
Measure	检测概率、检测时间、受损数据量、攻击阻止比例

核心战术：

• Detect attacks 检测攻击：
  • detect intrusion：通过流量、请求模式、日志等检测入侵。
  • detect service denial：检测拒绝服务攻击，如请求量异常升高、资源被耗尽。
  • verify message integrity：用哈希、校验和等验证消息是否被篡改。
• Resist attacks 抵抗攻击：
  • identify actors：识别请求来源。
  • authenticate actors：认证身份，回答“你是谁”。
  • authorize actors：授权访问，回答“你能做什么”。
  • limit access：最小权限、访问控制列表、角色权限控制。
  • limit exposure：减少攻击面，如关闭端口、隐藏内部服务、隔离敏感模块。
  • encrypt data：加密传输或存储数据。
• React to attacks 响应攻击：
  • revoke access：禁用异常账号、吊销 token、关闭会话。
• Recover from attacks 从攻击中恢复：
  • restore、audit、recover state：恢复数据和服务，审计攻击影响。

Testability 可测试性

定义：

软件通过测试展示其故障的容易程度。

如果系统要可测试，就必须能够：

• control inputs：控制输入。
• observe outputs：观察输出。

可测试性不只是测试人员的问题，它受到架构结构、接口、依赖、状态可观察性和复杂度的影响。

六要素	可测试性典型内容
Source	测试人员、开发人员、测试工具
Stimulus	执行测试、完成单元测试、注入测试输入
Artifact	系统、组件、单元、测试代码
Environment	开发时、构建时、部署前、运行时
Response	控制状态、记录结果、观察输出、隔离组件
Measure	覆盖率、测试运行时间、故障发现概率

核心战术：

• Control and observe system state 控制并观察系统状态：
  • specialized interfaces：为测试提供专用接口，用来控制组件状态或捕获内部值。
  • record / playback：记录输入序列或状态，之后回放以复现故障。
  • sandbox：隔离测试环境，避免影响真实用户、真实数据或生产系统。
• Limit complexity 限制复杂度：
  • limit structural complexity：减少组件依赖、限制继承深度、降低动态调用复杂度。
  • limit nondeterminism：固定随机种子、控制时间来源、减少并发不确定性、隔离外部环境。

Usability 易用性

定义：

用户完成目标任务有多容易，以及系统提供何种用户支持。

易用性包括：

• learning system features：学习系统功能。
• using a system efficiently：高效使用系统。
• minimizing the impact of errors：减少错误影响。
• adapting the system to user’s needs：适配用户需求。
• increasing confidence and satisfaction：提高用户信心和满意度。

六要素	易用性典型内容
Source	最终用户
Stimulus	学习、操作、下载新应用、误操作、恢复
Artifact	系统、用户界面、交互流程
Environment	首次使用、正常使用、错误状态、运行时
Response	反馈、帮助、撤销、取消、恢复、减少步骤
Measure	完成时间、错误率、操作步数、满意度

核心战术：

• Support user initiative 支持用户主动性：
  • cancel：允许用户取消当前操作，如取消上传、搜索、提交。
  • undo：保存足够历史状态，让用户撤销误操作。
  • pause / resume：允许长时间任务暂停和恢复。
  • aggregate：把多个低层对象聚合成组，用户可批量操作。
• Support system initiative 支持系统主动性：
  • maintain task model：系统理解用户当前任务，并给出下一步建议。
  • maintain user model：系统理解用户经验、偏好和习惯，提供个性化帮助。
  • maintain system model：系统理解自身状态，向用户提供进度、忙碌、错误原因等反馈。

需求、质量属性与 ASR

三类需求

类型	英文	核心含义	例子
功能需求	Functional Requirements	系统必须做什么	用户下单、支付、查询订单
质量需求	Quality Requirements	系统做得多好	2 秒内响应、99.9% 可用
约束	Constraints	自由度为 0 的设计决策	必须使用 Oracle、必须部署在校内服务器

答题句：

功能需求描述系统行为，质量需求描述系统行为的质量，约束限制架构师的设计自由度。

ASR 定义

ASR = Architecturally Significant Requirement，架构显著需求。

ASR 是会对架构产生重大影响的需求。如果没有这个需求，系统可能会采用明显不同的架构设计。

ASR 包括：

• 关键质量属性，例如高可用、低延迟、强安全。
• 关键约束，例如必须使用某平台或协议。
• 核心功能，例如决定系统主要分解方式的业务功能。
• 高风险需求，例如新技术、复杂集成、性能瓶颈。

ASR 来源与识别方法

来源 / 方法	中文解释	答题关键词
Requirement documents	从需求文档中识别影响架构的功能、质量属性和约束	文档通常不够精确，需要澄清
Interviewing stakeholders / QAW	访谈利益相关者，进行 Quality Attribute Workshop	业务目标、场景头脑风暴、优先级排序
Business goals	从业务目标反推关键质量属性	上线速度、成本、市场、合规
Utility tree	把 utility 分解为质量属性、子属性、具体场景，并标注重要性和风险	ATAM 常用
Persona-Based / ASP	用有架构意识的人物画像识别不同用户背后的架构关注点	安全、性能、可修改性、工作流

QAW 常见步骤可以这样背：

QAW 介绍 -> 业务使命介绍 -> 架构计划介绍 -> 识别架构驱动因素
-> 场景头脑风暴 -> 场景合并 -> 场景优先级排序 -> 场景细化

Utility tree 模板：

Utility
  -> Performance
      -> 查询响应时间 < 2s (H, M)
  -> Availability
      -> 单个服务故障 30s 内恢复 (H, H)
  -> Modifiability
      -> 新增支付方式 3 人天内完成 (M, L)

其中 (H, M) 可以表示重要性 High、风险 Medium。

ASR、需求、质量属性的关系

Software Requirements
  ├── Functional Requirements
  ├── Quality Requirements
  └── Constraints

ASR 是其中对架构有显著影响的子集。

答题模板：

软件需求是最宽泛的概念，包括功能需求、质量需求和约束。
质量属性是描述系统工作质量的一类需求。
ASR 不是单独一种需求类型，而是所有需求中对架构设计产生重大影响的那部分子集，通常包括关键质量属性、关键约束、核心功能和高风险需求。

对应往年题

• 2017：What are ASRs? List sources and methods for extracting and identifying ASRs.

• 2018：Software requirements、quality attributes、ASRs 的区别和联系。

  • 软件需求包括功能性需求和⾮功能性需求（⼜称质量需求）

  • 质量属性是由软件的业务⽬标所决定，在功能性需求的基础上提供的整个系统的合乎需求的特性，是⾮功能需求

    的⼀种反应

  • ASRs架构攸关需求是对于体系结构有着深远影响的需求，肯定是软件需求的⼀部分
• 2019：What are ASRs? List four or more sources and methods.
• 2025：什么需求影响架构，怎么得到。

架构战术

战术定义

Tactic 是影响某个质量属性响应控制方式的设计决策。一组 tactics 可以形成 architectural strategy；architecture pattern 通常内部组合多个 tactics

PPT 2-3 原话：

A tactic is a design decision that influences the control of a quality attribute response.
A collection of tactics is called an architectural strategy.
Tactics are the building blocks of design.

中文背法：

战术是影响质量属性响应控制方式的设计决策；一组战术称为架构策略；战术是设计的构建块。

Tactic 更细粒度，通常针对单个质量属性；
Pattern 更宏观，描述一类上下文中的结构性解决方案。
因此，architecture pattern 可以看作更高层次的结构方案，通常组合多个 tactics 来实现质量属性目标；tactics 可以看作 pattern 内部实现质量属性响应的基本设计手段。

七类架构设计决策

类别	中文
Allocation of responsibilities	职责分配
Coordination model	协调模型
Data model	数据模型
Management of resources	资源管理
Mapping among architecture elements	架构元素映射
Binding time decisions	绑定时机决策
Choice of technology	技术选择

Availability Tactics

三类：检测、恢复、预防。

类别	战术	解释
Detect faults	ping/echo、heartbeat、voting、exception	发现故障
Recover from faults	active redundancy、passive redundancy、spare、shadow operation、checkpoint/rollback	从故障中恢复
Prevent faults	removal from service、transaction、process monitor	防止故障变成 failure

常考解释：

• heartbeat：组件周期性发送“我还活着”的信号，超时未收到则判定故障。
• active redundancy：多个冗余组件同时工作，故障后快速切换。
• passive redundancy：主组件工作并同步状态到备组件，主故障后备组件接管。
• checkpoint/rollback：定期保存状态，故障后回滚到最近检查点。

FMECA：

FMECA = Failure Mode, Effects, and Criticality Analysis。
它用于分析可能的故障模式、故障影响和严重程度，帮助识别可用性风险和需要采用的检测/恢复战术。

Performance Tactics

两类：控制需求侧，管理资源侧。

类别	战术
Control resource demand	manage sampling rate、limit event response、prioritize events、reduce overhead
Manage resources	increase resources、introduce concurrency、multiple copies of computations、multiple copies of data

答题句：

性能战术要么减少或控制进入系统的资源需求，要么增加和更好地管理系统可用资源。

Modifiability Tactics 可修改性战术

目标	战术
Reduce size of a module（减小模块规模）	split module（拆分模块）
Increase cohesion（提高内聚）	increase semantic coherence（提高语义一致性）
Reduce coupling（降低耦合）	encapsulate（封装）、use an intermediary（使用中介）、refactor（重构）
Defer binding（推迟绑定 / 延迟绑定）	configuration（配置文件）、plugin（插件机制）、dependency injection（依赖注入）、runtime binding（运行时绑定）

核心句：

高可修改性的架构应尽量局部化变化，使一个变更影响尽可能少的模块，并把变化点封装在稳定接口之后。

Security Tactics

类别	战术
Detect attacks	detect intrusion、detect service denial、verify message integrity
Resist attacks	identify actors、authenticate actors、authorize actors、limit access、limit exposure、encrypt data
React to attacks	revoke access
Recover from attacks	restore、audit、recover state

Interoperability、Testability、Usability Tactics

Interoperability：

• locate：discovery service，服务发现。
• manage interfaces：orchestrate、tailor interface。

Testability：

• control and observe system state：specialized interfaces、record/playback、sandbox。
• limit complexity：limit structural complexity、limit nondeterminism。

Usability：

• support user initiative：cancel、undo、pause/resume、aggregate。
• support system initiative：maintain task model、user model、system model。

对应往年题

• 2015：Describe relationships between architecture patterns and tactics. List four tactics and describe usage.
• 往年多次：质量属性场景图题会要求同时说明相关 tactics。

架构基本概念

软件架构定义

SEI 定义：

软件架构是系统的一个或多个结构，这些结构包括软件元素、元素的外部可见属性以及元素之间的关系

IEEE 1471 定义：

软件架构是系统的基本组织结构，体现在组件、组件之间关系、组件与环境之间关系，以及指导系统设计和演化的原则中

Architecture vs Design vs Structure

Architecture 和 design 的关系：

• Architecture 是 software design 的一部分
• architecture 关注的是 high-level design，是一组对系统整体结构和关键质量属性有重要影响的 design decisions

Architecture 和 structure 的关系：

• Structure 更强调把系统分解为 components、modules、subsystems
• Architecture 包含 structure / organization，但比简单分解更进一步：它定义 component interfaces，即组件能做什么；定义 component communications and dependencies，即组件如何通信、如何依赖；还定义 component responsibilities，即当请求某个组件时，它具体应该完成什么

What Does a Software Architect Do

英文	中文	解释
liaison	沟通协调 / 联络	在客户、技术团队和业务 / 需求分析人员之间；与管理层或市场人员之间
software engineering	软件工程	软件工程最佳实践
technical knowledge	技术知识	对技术领域的深入理解
risk management	风险管理	与设计、技术选择相关的风险；以及其他风险

速记：架构师 = 对外联络，对内按工程做，用技术判断，管架构风险

Where Do Architectures Come From

英文	中文	对架构的影响
NFRs	非功能需求	描述系统“做得多好”，如性能、可用性、安全性、易用性，通常直接驱动架构决策
ASRs	架构显著需求	对架构有重大影响的需求，是架构设计最直接的驱动因素
QRs	质量需求 / 质量属性需求	具体化质量属性要求，常用质量属性场景表达
stakeholders	利益相关者	提供业务目标、关注点、约束和质量属性优先级
organizations	组织因素	团队结构、开发流程、预算、进度、治理方式会限制或塑造架构
technical environments	技术环境	平台、框架、基础设施、已有系统、部署环境和技术约束会影响架构选择

速背

• 需求类：NFRs、ASRs、QRs
• 人：stakeholders
• 组织：organizations
• 技术环境：technical environments

为什么架构重要

作用	说明
沟通工具	让客户、架构师、开发者、测试人员围绕同一设计讨论
最早设计决策	决定系统难以改变的核心结构和技术方向
影响组织结构	团队划分、任务分配、集成计划往往跟架构结构一致
影响质量属性	架构促进或阻碍性能、可用性、安全、可修改性等
帮助讨论变化	判断一个变更会影响哪些架构元素，以及是否会改变基本结构
可复用抽象	一个架构可用于多个相似系统，支持产品线工程和 CBSE

架构帮助讨论变化：

软件系统大量工作发生在部署之后，架构图和架构决策可以帮助判断一个变更的影响范围。考试如果问“为什么架构重要”，可以把这一点作为展开句：清晰的架构能帮助区分局部变化、非局部变化和架构级变化。

变化类型	含义
Local change	只影响单个元素内部
Non-local change	影响多个元素，但不改变基本结构
Architectural change	改变系统基本结构、通信机制、协调机制或核心设计原则

例子：

• 修改某个模块内部算法，接口不变，是 local change。
• 修改订单模块接口，导致支付模块、库存模块都要调整，是 non-local change。
• 从单体系统改为微服务，或从同步调用改为事件驱动，是 architectural change。

软件架构生命周期

PPT 中的生命周期概括：

活动	含义
Architecture Analysis	分析架构关注点和上下文，形成 ASR
Architecture Synthesis	根据 ASR 创建候选架构方案
Architecture Evaluation	用 ASR 评价候选架构
Architecture Implementation	通过详细设计和开发实现架构
Architecture Maintenance	演化架构以适应修正和扩展

软件架构过程的一般活动

对应往年题：

Briefly describe the general activities in a software architecture process, and the major inputs and outputs at each activity.

活动	图中英文	输入	图中输出
识别 ASRs	Specifying ASRs	/	Prioritized Quality Attribute Scenarios（按优先级排序的质量属性场景）
架构设计	Architecture design	Prioritized Quality Attribute Scenarios（按优先级排序的质量属性场景）；Requirements, constraints（需求、约束）；Patterns and tactics（模式和战术）	“Sketches” of candidate views, Determined by patterns（由模式决定的候选视图草图）
文档化	Documenting	“Sketches” of candidate views, Determined by patterns（由模式决定的候选视图草图）	Chosen, combined views ，documentations beyond views
架构评估	Architecture Evaluation	Prioritized Quality Attribute Scenarios（按优先级排序的质量属性场景），Chosen, combined views ，documentations beyond views	Chosen, combined views ，documentations beyond views

Stakeholders 参与

• Specifying ASRs
• Documenting
• Architecture Evaluation

Fault、Error、Failure

Fault -> Error -> Failure
故障根因 -> 内部错误状态 -> 对外服务失效

例子：代码缺陷是 fault；运行时变量算错是 error；用户看到错误结果是 failure。

对应往年题

这一节既可能作为基础概念简答题出现，也常作为下面几类题的开头定义、判断依据或支撑句出现。

• 课程重点 / 幕布重点：What Does a Software Architect Do?
  • 对应考点：liaison、software engineering、technical knowledge、risk management。
• 课程重点 / 幕布重点：Where Do Architectures Come From?
  • 对应考点：NFRs、ASRs、QRs；stakeholders、organizations、technical environments。
• 2015：Why should a software architecture be documented using different views? Give the name and purposes of four example views.
  • 对应考点：软件架构是多个结构的集合；单一结构无法表达所有 stakeholder 关心的问题，所以需要多视图。
• 2017 / 2019：What should be included in a typical software architecture documentation package?
  • 对应考点：架构不仅是结构图，还包括外部可见属性、关系、约束、设计原则和演化依据。
• 2015 / 2017：Briefly describe the general activities in a software architecture process, and the major inputs and outputs at each activity.
  • 对应考点：软件架构过程的一般活动，以及每个活动的主要输入和输出。
• 2017 / 2019 / 2022：What are generic design strategies applied in designing software? Give a concise working example with software architecture for each strategy.
  • 对应考点：architecture 是高层设计，是一组重要、系统级、难以改变的 design decisions。
• 2017 / 2019：What are ASRs? List sources and methods for extracting and identifying ASRs.
  • 对应考点：Architecture Analysis 通过分析 concern、context、stakeholder 和 quality attributes 得到 ASR。
• 2015 / 2017 / 2018：Graphically model quality attribute scenarios in stimulus-response format.
  • 对应考点：fault、error、failure 常用于 Availability 场景；MTBF、MTTR、failure detection/recovery 需要建立在这个区分上。

Views and Beyond

为什么要多视图

• 不同视图支持不同目标和用途，服务不同利益相关者
• 不同视图突出不同系统元素和关系
• 不同视图也会以不同维度暴露质量属性问题

常见 Views 比较

复习时可以把 Module Views、C&C Views、Allocation Views、Quality Views 放在一起比较。前三个主要回答“系统结构是什么”，Quality Views 主要回答“为了分析某个质量属性，需要把哪些相关结构集中起来看”。

类别	回答问题	Elements	Relations	典型 views
Module Views	代码和实现单元如何组织	modules	is part of、depends on、is a	decomposition、uses、generalization、layered、domain、data model
C&C Views	系统运行时组件如何交互	components、connectors	attachments、interface delegation	pipe-and-filter、client-server、peer-to-peer、SOA、publish-subscribe、shared-data
Allocation Views	软件元素如何映射到环境	software elements、environmental elements	allocated to	deployment、installation、work assignment
Quality Views	为分析某个质量属性，应集中查看哪些相关结构	来自 module、C&C、allocation views 中与某个质量属性相关的元素	取决于被抽取的基础视图	security view、performance view、reliability view、communications view

Quality view 不是从零创造新元素，而是从 module、C&C、allocation views 中抽取与某个质量属性相关的元素，重新组织成面向质量属性分析的视图。

例子：

• Security view：认证、授权、敏感数据、信任边界。
• Performance view：请求路径、队列、缓存、瓶颈、延迟。
• Reliability view：冗余、故障检测、切换、恢复。
• Communications view：通信链路、协议、QoS。

连线题速记：

implementation units -> Module
runtime behavior and interactions -> C&C
non-software environment -> Allocation

中文速记：

实现单元怎么组织 -> Module Views
运行时组件怎么交互 -> C&C Views
软件元素如何映射到非软件环境 -> Allocation Views
分析某个质量属性需要集中看哪些结构 -> Quality Views

Architecture Documentation Package

架构文档包 = views + information beyond views。

Information beyond views 包括： 口诀：路法概映理目

英文	中文	作用
Documentation Roadmap	文档路线图	告诉读者文档有什么、在哪里找
How a View Is Documented	视图文档化说明	说明视图写法标准和符号约定
System Overview	系统概览	简要说明系统功能、用户、上下文、关键约束
Mapping Between Views	视图之间的映射	说明不同视图中的元素如何对应
Rationale	设计理由 / 决策依据	记录适用于多个 view 的架构决策，以及导致这些决策的背景、组织约束、重大需求和基础架构模式选择
Directory	参考材料目录	帮助读者快速找到更多信息，包括术语索引、术语表和缩略语表

单个 View 的 5 个部分

主录境变理

英文	中文	作用
Primary Presentation	主要表示 / 主图	主图或主表，展示主要元素和关系，必须有图例
Element Catalog	元素目录	解释元素、关系、接口、行为和属性
Context Diagram	上下文图	说明该 view 的边界和外部环境
Variability Guide	可变性指南	说明哪些地方允许变化以及如何变化
Rationale	设计理由 / 决策理由	说明为什么这样设计

Documenting Behavior

• 结构文档：说明系统有哪些元素、元素之间如何连接。
• 行为文档：说明运行时元素如何交互。

两类行为记法：

• Trace-oriented languages：描述某一次具体路径，如 sequence diagram、activity diagram、use case。
• Comprehensive languages：描述元素完整行为，如 state machine。

对应往年题

• 2015：Why should a software architecture be documented using different views? Give 4 example views.
• 2015/2017/2018/2019：Map each question with the architectural style/view and list four views.
• 2017/2019：What should be included in a typical software architecture documentation package?

4+1 View Model

Kruchten 的 4+1 视图模型包括四个结构视图和一个场景视图。

View	中文	关注点
Logical View	逻辑视图	功能需求如何由主要抽象、类、对象、子系统实现
Process View	进程视图	并发、进程、线程、通信、同步、运行时行为
Physical View	物理视图	软件如何部署到硬件节点、网络和物理环境
Development View	开发视图	软件在开发环境中的组织，如模块、库、包、团队分工
Architecture use cases/Scenarios	场景 / 架构用例	捕获架构需求，并验证和串联其他四个视图

逻辑视图：系统“做什么” 开发视图：代码“怎么组织” 进程视图：运行时“怎么动” 物理视图：部署时“放哪里” 场景视图：用例“怎么串起来验证”

逻辑视图决定代码怎么组织，也决定运行时怎么执行； 开发视图和进程视图最终都要落到物理部署； 场景视图在中间，用具体用例验证四个视图是否一致

对应往年题：

• 2017：Describe 4+1 view.
• 2019：介绍 4+1 视图并画图。

ATAM（已被删，往年ppt有）

ATAM 是什么

ATAM = Architecture Tradeoff Analysis Method，架构权衡分析方法。它通过质量属性场景来分析架构决策，识别 risks、non-risks、sensitivity points、trade-off points。

答题模板：

ATAM 是一种基于场景的架构评价方法。它关注架构决策如何影响多个质量属性，尤其关注质量属性之间的权衡。
ATAM 的主要输出包括优先级质量属性场景、utility tree、风险、非风险、敏感点、权衡点、风险主题和最终评价报告。

ATAM 输出

输出	含义
Concise architecture presentation	架构的简洁陈述
Business goals	业务目标
Prioritized QA scenarios	优先级排序后的质量属性场景
Utility tree	质量属性树，按重要性和风险排序
Risks	可能导致不良后果的架构决策
Non-risks	经分析确认不是风险的决策
Sensitivity points	某质量属性对某设计参数特别敏感
Trade-off points	一个设计决策同时影响多个质量属性且方向不同
Risk themes	多个风险背后的共同主题
Final evaluation report	最终评价报告

如果题目问 “outputs generated from each phase”，可以按阶段写：

阶段	典型输出
Phase 0 Preparation	评估范围、评估计划、参与者、已有架构材料
Phase 1 Evaluation	业务目标、架构陈述、已识别架构方法、utility tree、初步 risks / non-risks / sensitivity points / trade-off points
Phase 2 Evaluation	利益相关者新增场景、优先级场景、对新增场景的架构分析结果、更新后的 risks 和 risk themes
Phase 3 Follow-up	最终评估报告、风险主题、改进建议、后续跟踪项

Stakeholders 与阶段

阶段	主要参与者	工作
Phase 0 Preparation	评估团队、项目决策者	确定评估范围、准备材料、安排人员
Phase 1 Evaluation	评估团队、架构师	陈述业务目标和架构，识别架构方法，构建 utility tree，分析架构方法
Phase 2 Evaluation	评估团队、架构师、利益相关者	利益相关者头脑风暴场景，分析场景与架构决策
Phase 3 Follow-up	评估团队、项目团队	汇总风险、形成报告、跟踪改进

Risk、Sensitivity Point、Trade-off Point

概念	定义	例子
Risk	某架构决策可能导致不希望的结果	单数据库节点导致单点故障，影响可用性
Non-risk	经分析确认不会造成问题的决策	已验证负载均衡可支持 10 倍流量
Sensitivity Point	某质量属性对某设计参数敏感	响应时间对线程池大小敏感
Trade-off Point	一个决策同时正面影响一个质量属性、负面影响另一个质量属性	加密提高安全性但降低性能

对应往年题

• 2015/2017/2021：Describe outputs generated from each phase of ATAM process.
• 2018：risks、sensitivity points、trade-off points 是什么？各举例。
• 2019：描述 ATAM 每个阶段有哪些 stakeholders 和职责。

ADD 3.0

ADD 是什么

ADD = Attribute-Driven Design。它是一种以架构驱动因素为输入、通过迭代做架构决策的方法

ADD 3.0 七步

• Step1 Review Inputs
  • 确保本轮设计输入可用且正确，包括 Design Purpose、Primary functionality、Quality attribute scenarios、Architectural constraints、Concerns、Existing architecture design，并确认 drivers 及其优先级
• Step2 Establish the Iteration Goal by Selecting Drivers
  • 选择本轮要处理的 drivers，建立大小合适的迭代目标，可以解决一个重要 driver，也可以满足一组相关 drivers
• Step3 Choose One or More Elements of the System to Refine
  • 选择要细化的系统元素，refinement 可以是分解为更细粒度元素、组合为更粗粒度元素，或改进之前已识别的元素
• Step4 Choose One or more Design Concepts that Satisfy the Selected Drivers
  • 先识别候选 design concepts，再选择能满足本轮 drivers 的概念，例如 reference architectures、deployment patterns、architectural/design patterns、tactics、frameworks
• Step5 Instantiate Architectural Elements，Allocate Responsibilities，and Define Interfaces
  • 将选定的 design concepts 实例化为具体架构元素，为元素分配职责，并定义元素之间的接口
• Step 6 Sketch Views and Record Design Decisions
  • 草拟相关 views 并记录设计决策、理由、元素职责和接口，这些草图是架构的初始文档
• Step7 Perform Analysis of Current Design and Review Iteration Goal and Achievement of Design Purpose
  • 分析当前设计，审查迭代目标和设计目的是否达成，并决定是否需要更多迭代（回到step2）

Design Process Termination Criteria

• 设计过程会跨越多次迭代持续进行，直到至少满足下面三种其中之一
  • 已经为所有驱动性的架构需求做出设计决策，即达到设计目标
  • 最重要的技术风险已经得到缓解
  • 分配给架构设计的时间或预算被耗尽

记忆：先看输入，定目标；选对象，挑方案；再落地，写文档；最后评估 终止：做完了、风险稳了、钱/时间没了

不同系统类型下的 ADD

• Design of a greenfield system for a mature domain
  • 适用于 well-known domains，例如 desktop、mobile、web enterprise apps、microservices
  • Initial iteration goal：establish overall system structure，选择 reference architectures、patterns、frameworks，并优先考虑 non-functional constraints 和 quality attributes
  • Next iteration goal：identify structures for primary functionality，把 use cases 分配给 elements，分解 reference architecture elements，并规划 team assignments
  • Subsequent iterations：refine structures for remaining drivers，使用 tactics、patterns、components 和 best practices，例如 modularity、low coupling
  • Roadmap benefits：指导初始设计，帮助早期估算，用已知组件降低风险，并从一开始支持 quality goals
• Design of a greenfield system for a novel domain
  • 适用于 less established infrastructure and knowledge base 的新领域
  • Start without reference architecture：没有现成模型或可复用组件，设计需要从 first principles 开始
  • Use prototyping and general concepts：用 patterns、tactics 和 quality attribute-focused prototypes 指导设计
  • Address emerging challenges：重点关注 performance、scalability、security，并保持 flexible iteration goals
• Design for making changes to an existing system (Brownfield)
  • Brownfield architecture design 常由 maintenance、refactoring 或 resolving quality issues 驱动
  • Understand existing architecture first：先识别系统元素及其 interactions，再进行 decomposition 或 iteration planning
  • Design iterations post-assessment：理解现有架构后，ADD 步骤类似 greenfield design，但以增量方式处理新的 drivers
• Design to replace a legacy application
  • Legacy tech and technical debt：旧系统可能依赖 obsolete technology，或存在难以管理的 technical debt
  • Use the Strangler Fig Pattern：引入 proxy，把调用路由到 legacy systems，同时逐步替换 components
  • Iterative replacement：每轮 ADD 的设计目标针对要迁移的 specific services or components

Design Concepts

类别	说明
Reference Architectures	领域化蓝图，比 architecture style 更具体
Deployment Patterns	物理部署组织方式，如 3-tier、cluster、failover
Patterns	反复出现设计问题的可复用方案
Tactics	影响质量属性响应的细粒度设计决策
Externally Developed Components	外部组件和框架，如 Spring、Hibernate

对应往年题：

• 2018/2025：描述 ADD / ADD 3.0 过程。
• 2021：架构一般设计策略是什么？以 ADD 为例说明。
• 2025：ADD 3.0 过程。

C&C Style 与架构模式

C&C Style 的本质

C&C = Component and Connector。它描述系统运行时结构，即运行时组件如何通过连接器交互。

概念	含义
Component	运行时处理单元或数据存储单元，通过 ports 与外部交互
Connector	交互路径，定义通信、协调、转换等机制
Port	组件对外交互点
Role	连接器中的参与角色
Attachment	component port 与 connector role 之间的连接
Interface delegation	外部 port 委托给内部 port

关键约束：

• Component 不直接连 Component，必须通过 Connector。
• Connector 连接 Component。
• 只有兼容的 port 和 role 才能 attachment。

常见 C&C Styles

Style	结构	适用
Pipe-and-Filter	Filter 处理数据，Pipe 传递数据	编译器、文本处理、数据流水线
Client-Server	Client 请求，Server 提供服务	Web 系统、数据库系统
Peer-to-Peer	节点既是客户端也是服务端	分布式共享、协作系统
SOA	服务提供者、消费者、契约、注册/总线	企业系统集成
Publish-Subscribe	发布者发布事件，订阅者异步接收	事件通知、缓存更新、消息系统
Shared-Data	多组件共享数据仓库	数据中心、黑板系统

用 MVC 说明 C&C

如果题目要求用 MVC 说明 C&C style，可以这样映射：

C&C 概念	MVC 中的对应
Component	Model、View、Controller
Connector	方法调用、事件通知、观察者通知
Port	Model 的数据访问接口、View 的更新接口、Controller 的输入处理接口
Attachment	Controller 调用 Model，Model 通知 View，View 将用户事件交给 Controller

说明句：

MVC 可以从 C&C 角度理解为运行时组件之间的交互结构。Controller 处理用户输入并更新 Model；Model 状态变化后通过通知机制更新 View；View 展示结果并接收新的用户操作。

Architecture Pattern vs Tactic

对比	Tactic	Architecture Pattern
粒度	小	大
关注	单个质量属性响应控制	某类上下文中的整体结构
内容	设计决策	context、problem、solution、consequences
关系	可组合成策略	通常包含多个 tactics

答题句：

Tactics are simpler than patterns. A pattern is a more complex, reusable architectural solution that often uses several tactics internally.

Broker Pattern

• Context：分布式系统中多个客户端和服务需要通信，直接耦合会降低可修改性、互操作性和可扩展性。
• Solution：引入 Broker 作为中介，客户端通过 Broker 查找、调用和访问服务。
• Benefits：客户端和服务端解耦；位置透明；支持动态发现；提高互操作性和可修改性。
• Limitations：Broker 可能成为单点故障和性能瓶颈；增加通信延迟；增加系统复杂度。

Pipe-and-Filter

• Filter：独立处理输入数据并产生输出。
• Pipe：连接 filter，传递数据流。
• 优点：Filter 可复用、可替换、可重组；支持并行处理。
• 缺点：不适合需要复杂共享状态或强交互的系统。

综合题写法：

输入文件 -> TokenizeFilter -> NormalizeFilter -> SortFilter -> UniqueFilter -> OutputFilter
Pipe 负责在 Filter 之间传递数据。每个 Filter 独立完成一步处理，符合高内聚、低耦合。

对应往年题

• 2015：architecture patterns and tactics 的关系；Broker Pattern 的 context、benefits、limitations。
• 2018：C&C style 的本质，以 MVC 举例。
• 2021：C&C style 的本质，以 SOA 举例。
• 2022：分布式缓存更新，用 Observer / Publish-Subscribe 映射组件，画 sequence diagram，并讨论 connector/web services。
• 2025：C&C 风格的性质，以 SOA 举例。

SOA

SOA 基本概念

SOA = Service-Oriented Architecture，面向服务架构。它把系统能力封装成服务，通过标准契约和通信机制供服务消费者使用。

典型 C&C 元素：

• Components：service provider、service consumer、service registry、ESB。
• Connectors：SOAP/HTTP、REST call、message queue、service invocation。
• Constraints：服务通过契约交互，消费者不依赖服务内部实现。

SOA 基本原则

原则	中文解释
Service Contract	服务通过契约描述接口、消息格式和行为
Service Encapsulation	服务隐藏内部实现
Service Reuse	服务应被设计成可复用能力
Service Composition	服务可以组合成更复杂业务流程
Service Autonomy	服务对自身逻辑和资源有自治权
Service Statelessness	服务尽量不保存跨调用状态
Service Discoverability	服务可被发现和定位
Service Interoperability	服务使用标准协议和数据格式交互

SOA 对质量属性影响

质量属性	正面影响	负面影响
Interoperability	标准契约和协议提高异构系统集成能力	契约治理和版本兼容复杂
Scalability	服务可分开扩展	ESB 或中心治理可能成为瓶颈
Security	可集中认证、授权、审计	分布式服务增加攻击面
Modifiability	服务封装实现，降低消费者对实现依赖	共享契约修改需要协调多个系统

对应往年题

• 2015：Briefly describe fundamental principles of SOA and discuss impact on interoperability、scalability、security.
• 2021/2025：C&C style 以 SOA 举例说明。

Microservices

微服务定义

微服务架构把系统拆成一组围绕业务能力组织的小服务。每个服务可以独立开发、部署、扩展和演进，通常拥有自己的数据，并通过轻量级通信机制协作。

微服务主要特征

特征	解释
Componentization via Services	以服务作为组件单元，而不是以库或类作为部署单元
Organized around Business Capabilities	围绕业务能力和限界上下文拆分，而不是按技术层次拆分
Cohesion and Decoupling	服务内部高内聚，服务之间低耦合
Decentralization	去中心化治理、去中心化数据管理、技术栈可不同
Infrastructure Automation	自动化构建、测试、部署、监控，依赖 DevOps / CI/CD
Design for Service Evolution	服务可独立演进，智能端点和哑管道

Smart Endpoints and Dumb Pipes

微服务主张业务逻辑在服务端点中，通信管道只负责简单消息传递。与 SOA 中重量级 ESB 相比，微服务避免把大量路由、转换和编排逻辑放在管道中。

答题句：

Smart endpoints mean services contain business logic. Dumb pipes mean communication mechanisms are lightweight and do not contain heavy business orchestration.

SOA vs Microservices

维度	SOA	Microservices
目标	企业级集成和复用	快速迭代、独立部署、弹性扩展
服务粒度	通常较粗	通常较细
通信	ESB、SOAP、企业级中介较常见	REST、消息队列、轻量协议
管道	智能管道，ESB 负责转换和编排	哑管道，服务端点负责业务逻辑
数据	可能共享数据模型	每个服务拥有自己的数据库
治理	集中治理	去中心化治理
部署	服务可能仍共享发布周期	服务独立部署

相同点：

• 都以服务作为抽象。
• 都强调服务契约、服务封装、服务复用。
• 都用于降低系统间直接耦合，提高互操作性。

微服务挑战

• 服务拆分粒度难把握。
• 分布式系统复杂性增加：网络延迟、超时、部分失败。
• 数据一致性困难，跨服务事务复杂。
• 运维和监控要求高。
• 调试、日志追踪和故障定位复杂。
• 服务间 API 版本和依赖管理复杂。

微服务拆分方法

考试案例题可以按这个流程写：

1. 从用户故事中提取关键名词，建立领域对象。
2. 从动词中识别系统操作。
3. 按业务能力 / 子域 / bounded context 划分服务。
4. 为每个服务分配数据所有权。
5. 定义服务之间 API 或事件协作关系。
6. 说明质量属性影响和风险。

外卖平台示例：

系统操作	可能服务	说明
用户注册/登录	User Service	用户资料、认证
浏览商家和菜单	Restaurant Service / Menu Service	商家、菜品、价格
创建订单	Order Service	订单生命周期
支付	Payment Service	支付渠道、支付状态
商家接单	Merchant Service	商家端操作
骑手配送	Delivery Service	派单、路线、配送状态
通知用户	Notification Service	短信、邮件、App 推送
优惠券	Promotion Service	优惠规则、活动

服务关系可以写：

Order Service 调用 User / Restaurant / Menu 校验信息；
Order Service 创建订单后发布 OrderCreated 事件；
Payment Service 处理支付并发布 PaymentSucceeded；
Delivery Service 订阅支付成功事件并创建配送任务；
Notification Service 订阅订单、支付和配送事件通知用户。

部署模式

• 多服务单主机多实例。
• 单主机单服务实例。
• 每服务虚拟机。
• 每服务容器。
• 服务部署平台，如 Kubernetes。
• Serverless。

对应往年题

• 2019：微服务和 SOA 的区别、相同点。
• 2025：微服务架构的主要特征。
• 2025：外卖平台为什么适合微服务；识别操作、服务和关系。

架构模式演化

核心句：

架构风格的演化，本质是在不同历史约束下对质量属性做优先级排序。
每种架构都会优先保障某些质量属性，同时牺牲另一些质量属性。

阶段	主要矛盾	结构抓手	优先保障	相对牺牲
批处理	计算资源稀缺	作业统一输入系统	吞吐量、稳定性	交互性
主机/终端	多用户共享核心事务	强中心、弱终端	一致性、安全、可靠	易用性、局部灵活性
C/S	桌面交互需求增强	胖客户端 + 数据服务器	交互体验、响应性	部署和维护
三层/分层	职责混乱、部署复杂	表示层、业务层、数据层	可维护、可修改、安全	极致性能
SOA	企业系统集成	契约、服务、ESB、治理	互操作、复用、组合	简单性、响应性能
微服务	快速迭代与独立部署	服务边界 = 业务边界	可部署、可扩展、演进	一致性、运维简单性
事件驱动/云原生	大规模与流量波动	事件、弹性基础设施	弹性、可用、韧性	可理解性、调试性
AI 增强	自然语言与语义能力	传统系统 + AI 能力层	易用性、知识获取	可预测性、测试性
AI 原生	长链路非确定任务	模型 + 工具 + 记忆 + 状态	适应性、任务完成	确定性、安全边界

Generic Design Strategy

策略	含义	架构例子
Decomposition	拆分复杂系统	电商拆成用户、订单、库存、支付服务
Abstraction	忽略细节，保留关键接口	用 Repository 接口隐藏数据库
Stepwise: Divide and Conquer	分而治之	编译器拆成词法、语法、语义、代码生成
Generate and Test	生成候选方案并分析	比较 active redundancy 和 passive redundancy
Iteration ：Incremental Refinement	多轮迭代细化	ADD 每轮处理一组 drivers
Reusable Elements	复用已有模式、框架、组件	使用 MVC、Spring、消息队列

记忆：用一个电商系统串起来记

• Decomposition 先把电商系统拆成：用户、商品、订单、库存、支付、物流
• Abstraction 不让订单模块直接知道数据库细节，而是通过：OrderRepository 接口访问数据
• **Stepwise / Divide and Conquer **下单流程太复杂，就分步处理：创建订单 → 锁库存 → 支付 → 发货 → 通知
• Generate and Test 为了提高可用性，提出多个方案，再分析比较
• Iteration / Incremental Refinement 第一轮先设计订单主流程，第二轮补异常处理，第三轮优化性能：
• **Reusable Elements **不要自己从零写所有东西，复用：MVC、Spring Boot、Redis、Kafka、OAuth、设计模式

Design Strategies 在 ADD 中的体现

策略	在 ADD 中如何体现
Decomposition	Step 3 选择元素并逐步分解
Abstraction	用模块、组件、接口抽象隐藏细节
Divide and Conquer	Step 2 每次选择一组 drivers，拆成可处理的子问题
Generate and Test	设计决策是 hypothesis，Step 7 分析并修正
Iteration	ADD 通过多轮迭代逐步完善架构
Reuse	Step 4 使用参考架构、模式、战术、框架

对应往年题：

• 2017/2019/2022：What are generic design strategies applied in designing software? Give a concise working example with software architecture for each strategy.

综合设计题专项

质量属性图题

答题结构：

先写六要素表，再画 stimulus-response 图，最后写 response measure 为什么可测试。

示例框架：

Source: user
Stimulus: sends query request
Artifact: query service
Environment: normal load
Response: processes request and returns result
Response Measure: 95% requests return within 2 seconds

C&C / SOA 图题

答题结构：

Components: service consumer, service provider, service registry, ESB
Connectors: service invocation, message queue, HTTP/SOAP/REST
Attachments: consumer port attaches to invocation connector role; connector attaches to provider port
Constraints: services communicate through contracts; consumers do not depend on implementations

分布式缓存更新题

适合映射为 Observer / Publish-Subscribe。

Database / Data Service = Subject / Publisher
Cache Nodes = Observers / Subscribers
Message Broker = Connector
Update Event = Notification

可写 sequence：

DataService updates data
DataService publishes DataChanged event to MessageBroker
MessageBroker forwards event to CacheNodeA/B/C
Each CacheNode invalidates or refreshes cached data
CacheNode sends ack or logs failure

设计理由：

• 发布者不需要知道具体缓存节点，降低耦合。
• 新增缓存节点只需订阅事件，符合可修改性。
• 异步消息提高可扩展性，但带来最终一致性和故障重试问题。

Pipe-and-Filter 程序题

题型：输入文本文件，输出排序去重单词列表。

组件图：

InputFile
  -> ReadFilter
  -> SplitWordsFilter
  -> NormalizeFilter
  -> SortFilter
  -> UniqueFilter
  -> OutputFilter

说明：

• Filter 是独立处理单元。
• Pipe 是数据传输通道。
• 每个 Filter 只做一步转换，便于替换、复用和测试。

外卖平台微服务拆分题

答题结构：

为什么适合微服务：
外卖平台业务边界清晰，订单、支付、配送、商家、用户等能力可以独立演进；
系统需要高并发、弹性扩展和独立部署，因此适合微服务。

微服务划分：
User、Restaurant/Menu、Order、Payment、Delivery、Notification、Promotion。

关系：
Order 编排下单流程；Payment 处理支付；Delivery 处理配送；Notification 订阅事件通知用户。

权衡：
提高可扩展性和可部署性，但增加分布式一致性、运维、监控和故障定位复杂性。

架构文档化补充

三种 Notation

类型	特点	优缺点
Informal	普通图和文字	易创建、易沟通，但歧义大
Semiformal	UML 等标准符号	有统一规则，但语义不完全严格
Formal	ADL、数学语义	精确、可分析，但成本高

趋势：

越正式，精确性和可分析性越高，但创建和理解成本也越高。

敏捷架构文档

原则：just enough documentation。

• 只有某个 view 有明确 stakeholder 需求时才写。
• 信息什么时候可用什么时候补。
• 白板图可以拍照作为 primary presentation。
• 不必先写完整架构文档再开发。

架构变化快于文档怎么办

• 记录 invariants：所有版本都必须满足的不变量。
• 记录 allowed variability：允许怎样变化、在哪里变化、通过什么机制变化。

考前速背清单

2 分钟默写

• 质量属性场景六要素：source、stimulus、artifact、environment、response、response measure。
• 三类 views：Module = implementation units；C&C = runtime interaction；Allocation = non-software environment。
• ASR 定义：会显著影响架构的需求。

5 分钟默写

• 4+1：Logical、Process、Physical、Development、Scenarios。
• ATAM 输出：business goals、prioritized scenarios、utility tree、risks、non-risks、sensitivity points、trade-off points、risk themes、final report。
• ADD 七步：review inputs、select drivers、choose elements、choose concepts、instantiate/allocate/define interfaces、sketch views/record decisions、analyze/review。
• SOA 原则：contract、encapsulation、reuse、composition、autonomy、statelessness。
• 微服务特征：services、business capabilities、cohesion/decoupling、decentralization、automation、evolution。

10 分钟默写

• Availability / Performance / Modifiability / Interoperability 的质量属性场景模板。
• ATAM 中 risk、sensitivity point、trade-off point 的定义和例子。
• SOA vs Microservices 表格。
• ADD 如何体现六种通用设计策略。
• 外卖平台微服务拆分：User、Restaurant/Menu、Order、Payment、Delivery、Notification、Promotion。

必练往年题

• How to model quality attribute scenarios? Graphically model availability and modifiability in stimulus-response format.
• What are ASRs? List sources and methods for extracting and identifying ASRs.
• Why should a software architecture be documented using different views? Give four example views.
• Describe 4+1 view model and draw the diagram.
• Describe outputs generated from each phase of ATAM process.
• What are risks, sensitivity points, and trade-off points? Give examples.
• Describe ADD 3.0 process.
• What are generic design strategies applied in designing software? Give examples.
• What is the nature of component-connector style? Explain with SOA.
• Briefly describe SOA principles and impact on interoperability, scalability and security.
• Compare SOA and microservices.
• Design microservices for a food delivery platform.