面向期末 - 架构复习

架构复习

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

最高优先级速背

一页纸总表

考点	必背句
软件架构定义	软件架构是系统的一个或多个结构，包括软件元素、元素外部可见属性以及元素之间的关系；也包括指导系统设计和演化的原则。
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：如何描述质量属性场景，描述互操作性和性能的质量属性场景。

质量属性

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

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

Internal vs External Attributes

质量属性可以从内部和外部两个角度理解：

• External attributes：外部可见属性，用户、运维人员或外部系统能够直接感受到，例如 availability、performance、security、usability、interoperability。
• Internal attributes：内部结构属性，主要由开发者、测试者和维护者通过代码、模块结构和依赖关系感受到，例如 modifiability、testability、maintainability、reusability。

考试理解：外部属性更接近“系统对外表现得怎么样”，内部属性更接近“系统内部是否容易开发、测试、维护和演化”。同一个质量属性也可能同时受内部结构和外部行为影响。

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	从需求文档中识别影响架构的功能、质量属性和约束	文档通常不够精确，需要澄清
QA Workshop / interviews	通过 Quality Attribute Workshop 或访谈利益相关者识别 ASR	业务目标、场景头脑风暴、优先级排序
Business goals	从业务目标反推关键质量属性	上线速度、成本、市场、合规
Utility tree	把 utility 分解为质量属性、子属性、具体场景，并按 Importance vs Difficulty 排序	ranked scenarios
Persona-Based approach/ 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 是其中对架构有显著影响的子集。

答题模板：

软件需求包括功能性需求和⾮功能性需求（⼜称质量需求）
质量属性是由软件的业务⽬标所决定，在功能性需求的基础上提供的整个系统的合乎需求的特性，是⾮功能需求的⼀种反应
ASRs架构攸关需求是对于体系结构有着深远影响的需求，肯定是软件需求的⼀部分

对应往年题

• 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 内部实现质量属性响应的基本设计手段。
Style 的抽象层次通常比 pattern 更高，它描述一类系统的总体组织方式；pattern 更具体，解决特定上下文中反复出现的问题。

七类架构设计决策

类别	中文	考试解释
Allocation of responsibilities	职责分配	把功能责任和质量属性责任分配给具体软件元素；responsibility 不只等于功能，也包括为了满足性能、安全、可用性等质量需求而产生的责任
Coordination model	协调模型	说明运行时元素如何交互，包括谁能和谁通信、交互方向、传递数据还是传递控制
Data model	数据模型	说明数据结构、数据关系和生命周期，包括创建、读取、修改、删除、持久化等
Management of resources	资源管理	管理 CPU、内存、网络、存储、线程、连接池等软硬件资源
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，即当请求某个组件时，它具体应该完成什么
• Structure 偏静态，回答系统由哪些部分组成；Architecture 还要说明这些元素在运行时如何交互、依赖和变化，因此同时包含静态结构和动态关系

What Does a Software Architect Do

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

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

答题展开句：架构师要在不同 stakeholders 之间协调，尤其要调和用户和开发者之间的矛盾。用户通常希望 feature 更多、变化更快、体验更好；开发者则要考虑开发时间、成本、风险和后续维护。架构设计就是在这些约束之间做出可实现、可演化的折中。

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	演化架构以适应修正和扩展

Software Architecture Knowledge Areas

软件架构相关知识领域可以按复习课 PPT 这样记：

• Software Design Quality Analysis and Evaluation：软件设计质量分析与评估，包括 quality attributes、质量分析与评估方法、设计评审、静态 / 动态分析、仿真与原型、架构级度量等。
• Design Modeling and Representation：设计建模与表示，包括 architecture and design notations、ADL、UML、Views & Beyond 架构文档，以及 ACME、Rapide 等不同关注点的表示方法。

考试理解：这一页不是让展开背 ATAM 或 ADL 细节，而是知道软件架构知识既包括“如何分析和评价质量”，也包括“如何建模、表示和文档化架构”。

软件架构过程的一般活动

对应往年题：

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 视图并画图。

ADD 3.0

ADD 是什么

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

ADD 3.0 七步

• Step1 Review Inputs
  • 确保本轮设计输入可用且正确，包括 Design Purpose、Primary functionality、Quality attribute 、Architectural Concerns、constrains，并确认 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

Design Driver

functional driver

quality attribute driver

constrain

types of system

Design Purpose/Objectives

Architectural Concerns

对应往年题：

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

微服务架构设计

软件架构演化

单体（Monolithic）架构

单体（Monolithic）应用的全部功能被集成在一起作为一个单一的单元

• 优点
  • 易于开发、修改、测试、部署、伸缩
• 缺点
  • 过度复杂性
  • 开发速度缓慢
  • 部署周期长且易出错
  • 难以扩展
  • 可靠性差
  • 过期技术栈

分层架构

分层架构是对复杂系统进行抽象和分层、结构化设计的架构方案

优点：

• 结构简单
• 易于组织开发、测试和维护

缺点：

• 不易实现持续发布部署
• 有性能代价
• 运行时扩缩容能力较差

SOLID原则

• 单一职责原则（Single Responsibility Principle）
• 开闭原则（Open/Closed Principle)
• 里氏替换原则（Liskov Substitution Principle）
• 接口隔离原则（Interface Segregation Principle）
• 依赖倒置原则（Dependency Inversion Principle)

面向服务架构（SOA 架构）

SOA 是一个分布式组件的集合，这些组件为其他组件提供服务（Provider），或者消费其他组件提供的服务（Consumer），而无需知道其他组件的实现细节

核心概念：

• 企业服务总线 ESB：为服务间相互调用提供支持环境，路由服务间消息，并对消息和数据进行必要转换
• 服务编排引擎 Orchestration Engine：根据预定义脚本对服务消费者与服务提供者之间的交互进行指挥

优点：

• 服务自身高内聚、服务间松耦合，最小化维护影响
• 良好的互操作性，符合开放标准
• 模组化、高重用性
• 服务可以动态识别、注册和调用

缺点：

• 系统复杂性提高
• 难以测试验证
• 各独立服务的演化不可控
• 中间件容易成为性能瓶颈

面向服务架构实现原则

• 服务解耦：服务之间的关系最小化，只是互相知道接口。
• 服务契约：服务按照描述文档所定义的服务契约行事。
• 服务封装：除了服务契约所描述内容，服务将对外部隐藏实现逻辑。
• 服务重用：将逻辑分布在不同的服务中，以提高服务的重用性。
• 服务组合：一组服务可以协调工作，组合起来形成定制组合业务需求。
• 服务自治：服务对所封装的逻辑具有控制权。
• 服务无状态：服务将一个活动所需保存的资讯最小化。

微服务（Microservice）架构风格

什么是微服务

微服务架构是一种将单体应用拆分为细粒度的服务，并使其运行在独立进程中，服务之间采用轻量级通信机制（如 HTTP RESTful API）进行交互的架构风格。这些服务围绕系统的业务能力构建，且可以通过全自动的部署机制进行独立部署。服务可以进行分布式管理，从而支持使用不同的编程语言进行开发，并采用不同的数据存储技术进行存储

微服务架构的六大特性

通过服务组件化

• 组件是可以独立替换或升级的软件单元
• 进程外组件
  • 独立服务
• 进城内组件
  • 类、对象或库的形式

围绕业务能力组织

• 团队是跨职能的
• 开发团队负责软件的整个产品周期，而非开发完解散

内聚和解耦

• 内聚：单一职责，有各自的领域逻辑
• 解耦：微服务间尽量减少直接依赖，独立自治

去中心化

• 去中心化治理：微服务可以有自己的技术栈选择，只需要约定接口；运维只需要知道微服务的部署规范
• 去中心化数据存储：每个服务管理自己的数据库
• 去中心化数据管理：服务间强调无事务协作，最终一致性和补偿策略，需要权衡业务损失和修复代价

基础设施自动化

• 依靠云原生、自动化构建、自动化部署、监控和运维，降低微服务开发和运维成本。

服务设计与演进

• 高可用设计：容忍失败 监控日志 快速发现修复
• 演进式设计：频繁增量变更 解耦

缺点

• 设计复杂性
• 网络延迟
• 联调
• 故障定位和恢复

SOA与MSA对比

挑战问题

• 粒度问题
• 分布式系统带来的复杂性

模式

针对特定上下文中发生的问题的可重用解决方案

拆分模式

目标：高内聚、低耦合

假设：微服务边界大致对应限界上下文（Bounded Context）边界

流程：

• 定义系统操作
  • 输入：需求，用户故事/相关用户场景/源代码恢复等
  • 步骤
    • 分析用户故事中频繁出现的名词，创建领域模型
    • 分析用户故事和场景中的动词，确定系统操作
• 定义微服务
  • 根据业务能力拆分
    • 业务能力是为企业产生价值的商业活动，通常较稳定；业务能力的实现方式相对不稳定；例如在线商店可以拆成订单管理、库存管理、发货等能力
  • 根据子域拆分
    • 根据子域拆分微服务时，先从业务领域出发，将复杂问题域划分为若干子域；每个子域提炼自己的统一语言和领域模型，并识别限界上下文。由于限界上下文定义了领域模型的边界，通常可以将一个限界上下文映射为一个或一组微服务。这样可以使服务边界与业务边界一致，提高高内聚、低耦合和团队自治能力
    • 子域是领域驱动设计方法论的核心，子域是领域的细分
    • DDD （领域驱动设计）通过逐级细分问题域降低理解和实现复杂度，并从业务需求中提炼统一语言
      • 战略设计：构建领域模型，识别限界上下文，确定领域边界；通过上下文映射建立领域间关系；划分微服务的逻辑边界和物理边界
      • 战术设计：在限界上下文内进行领域建模，指导程序设计、编码和重构
  • 根据动静态调用关系拆分：静态调用信息包括用例分析、字节码解析、API 接口；动态调用信息包括调用链路、数据流图、控制流图；之后构建有向带权图并基于聚类算法拆分
• 定义服务 API 和协作方式
  • 将系统操作分配给服务
  • 确定支持协作的 API

微服务架构的核心模式

服务注册与发现 Service Registration and Discovery

• 问题：基于 RPI 的客户端如何在网络上发现服务实例的位置？
• 核心理念：把“服务实例的位置”从客户端业务代码中解耦出来，客户端不直接写死服务地址，而是通过发现机制获得可用服务实例。
• 应用层服务发现模式：
  • 自注册：服务实例调用服务注册表的注册 API 来注册其网络位置。
  • 客户端发现：客户端查询服务注册表以获取服务实例的列表，可配合缓存和负载均衡提高性能。
  • 结果：处理多平台部署的问题，即服务发现机制与具体部署平台无关；但需要为每种语言 / 框架提供服务发现库，开发者也要负责设置和管理服务注册表。
• 平台层服务发现模式：
  • 第三方注册：由第三方负责处理注册，而不是服务本身向服务注册表注册自己。
  • 服务端发现：客户端无需查询服务注册表，而是向 DNS 名称发出请求，之后由路由器查询服务注册表并进行负载均衡。
  • 结果：完全交给部署平台，服务端、客户端代码减负，多语言支持度较高，但存在平台约束。

API Gateway

• 问题：如何处理外部客户端与服务之间的通讯？
• 需求：
  • 支持多种客户端的 API。
  • 细粒度 API，客户端与多项服务交互请求效率低。
  • 不同客户端需要不同的数据，性能要求亦有区别。
  • 缺少封装，影响可修改性，因为服务划分方式可能变化。
  • 服务的实例数量与位置动态变化。
  • 对客户端不友好的进程间通信。
• 解决方案：实现一个服务，外部 API 客户端进入基于微服务应用的入口点，并且针对不同客户端提供不同的 API。
• 结果：封装应用程序内部结构，减少交互次数；确保客户端不受服务实例位置影响；支持 API 组合、协议转换和边缘功能，身份验证；问题：性能和可扩展性、局部故障等

熔断器 / Circuit Breaker

• 问题：同步通信中如何避免由于服务故障或网络中断所引起的故障蔓延到其他服务？
• 核心理念：把可能失败的远程调用包在断路器中，故障时不再不断尝试调用，而是快速返回错误响应，避免故障扩散。
• 三种状态：
  • 闭合状态：对程序的请求能够直接引起方法的调用。
  • 断开状态：对程序的请求会立即返回错误响应。
  • 半断开状态：允许对程序的一定数量的请求可以调用服务；如果调用成功，认为之前导致调用失败的错误已经修正，切换到闭合状态；如果调用失败，则认为问题仍存在，切回断开状态。
• 结果：防止不断地尝试执行可能会失败的操作；使程序能够诊断错误是否已经修正，进而再次尝试调用操作。

微服务部署模式：

问题

• 服务使用各种语言、框架和框架版本编写
• 需要快速构建、独立部署和扩展服务
• 服务实例需相互隔离
• 需限制服务消耗的资源（CPU 和内存）
• 尽可能经济高效地部署应用程序

解决方案

• 单主机部署多个服务实例
  • 优点
    • 资源利用率高
  • 缺点
    • 资源需求/依赖版本冲突；难限制实例资源消耗/监控/隔离
• 单主机部署单个实例
  • 优缺点和上一条完全相反
• 将服务部署到虚拟机
  • 优点
    • 容易增加实例数量来拓展；VM 封装技术细节（如启动和停止方式）；隔离；部署和管理的基础设施丰富（AWS 等 IaaS 解决方案提供 ELB、自动缩放组等）
  • 缺点
    • 资源利用率低；部署速度慢；额外开销（OS、运行补丁）

• 将服务部署到容器

  • 过程

    • 构建 Docker 镜像 Dockerfile

    • 构建容器镜像 docker build

    • 推送到镜像仓库 docker push

    • 运行 Docker 镜像 docker run
  • 优点
    • 容易更改实例数量来增缩；容器封装技术细节；隔离；容易限制资源消耗；构建/启动速度提高
  • 缺点
    • 容器镜像管理工作多；基础设施不丰富
• 无服务器部署
  • 优点
    • 集成简单；消除系统管理任务；自动弹性配置；基于请求定价
  • 缺点
    • 长尾延迟：动态运行代码，花费时间配置和启动；基于有限事件与请求的编程模型：不用于长时间运行的服务
• 服务部署平台
  • 优点
    • 多种后续模式支持；功能强大
  • 缺点
    • 额外的技术学习和资源成本

微服务可观测性模式

日志聚合模式

• 问题：如何理解应用程序的行为并解决问题？
• 需求：任何解决方案都应该具有最小的运行时开销。
• 模式：使用集中式日志记录服务聚合来自每个服务实例的日志；用户可搜索和分析日志；可配置当某些消息出现在日志中时触发的警报。
• 缺点：处理大量日志需要大量的基础设施。

审计日志模式

• 问题：如何理解用户和应用程序的行为并检测定位问题？
• 需求：了解用户最近执行了哪些操作，帮助支持、确保合规性、安全性和可疑行为等。
• 模式：向业务逻辑中添加审计日志代码；创建审核日志条目并保存在数据库中。
• 优点：提供用户操作的记录。
• 缺点：审计代码与业务逻辑交织，使业务逻辑复杂化。

应用程序指标模式

• 问题：如何理解应用程序的行为并检测定位问题？
• 需求：任何解决方案都应该具有最小的运行时开销。
• 模式：检测服务以收集有关各个操作的统计信息，在集中式指标服务中聚合指标，提供报告和警报。
• 聚合指标两种模型：
  • push：服务将指标推送到指标服务。
  • pull：指标服务从服务中提取指标。
• 优点：提供对应用程序行为的深入洞察。
• 缺点：指标代码与业务逻辑交织在一起，使其更加复杂；聚合指标可能需要大量的基础设施。

分布式跟踪模式

• 问题：如何理解应用程序的行为并解决问题？
• 需求：
  • 外部监控只报告总体响应时间和调用次数，无法深入了解各个操作。
  • 任何解决方案都应该具有最小的运行时开销。
  • 请求的日志条目分散在许多日志中。
• 模式：记录单次请求范围以内的信息。
• 做法：
  • 为每个外部请求分配一个唯一的外部请求 ID。
  • 在提供可视化和分析的集中式服务器中记录请求如何从一个服务流向下一个服务。
  • 在所有日志消息中包含外部请求 ID。
  • 记录在集中服务中处理外部请求时执行的请求和操作的信息，例如开始时间、结束时间。
• 优点：提供了对系统行为的有用洞察，包括延迟的来源；开发人员可以通过在聚合日志中搜索外部请求 ID 来查看单个请求是如何处理的。
• 缺点：聚合和存储追踪数据可能需要大量的基础设施。

异常跟踪模式

• 上下文：处理请求时有时会发生错误。发生错误时，服务实例会抛出异常，其中包含错误消息和堆栈跟踪。
• 问题：如何理解应用程序的行为并解决问题？
• 需求：异常必须由开发人员去重、记录、调查并解决潜在问题；任何解决方案都应该具有最小的运行时开销。
• 模式：向集中式异常跟踪服务报告所有异常，该服务聚合和跟踪异常并通知开发人员。
• 优点：更容易查看异常并跟踪其解决方案。
• 缺点：异常跟踪服务是额外的基础设施。

健康检查 API 模式

• 问题：如何检测正在运行的服务实例无法处理请求？
• 需求：当服务实例失败时应生成警报，请求应该被路由到正常工作的服务实例。
• 模式：服务具有 /health 返回服务健康状况的健康检查 API 端点，执行检查：
  • 服务实例使用的基础设施服务的连接状态。
  • 主机的状态，例如磁盘空间。
  • 应用程序特定逻辑。
• 监控服务、服务注册表或负载均衡可以定期 “ping” 调用端点来检查服务实例的健康状况。
• 优点：定期测试服务实例的健康状况。
• 缺点：不够全面；服务实例可能在健康检查之间失败。

微服务面临的挑战

• 运维要求高：微服务数量多，部署与监控要求高。
• 发布复杂度高：部署环境多样化，还要面对网络性能、系统容错、分布式事务等挑战。
• 部署依赖强：服务间相互调用关系复杂，存在部署顺序依赖。
• 通信成本高：跨进程调用比进程内调用消耗更多资源。

对应往年题

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

架构模式演化

• 各架构的核心思想。
• 架构之间迁移的原因。
• 架构对质量属性的影响。
• 结合具体业务系统说明。

核心思想速记

架构	到底在组织什么
最早期	组织稳定执行：程序和数据组成作业，围绕批处理与调度运行
主机 / 终端	组织核心事务：事务、数据、权限集中在主机，终端主要输入与显示
C/S	组织交互能力：客户端承担 UI 与部分逻辑，服务器管理共享数据
三层 / 分层	组织职责边界：表示层、业务层、数据层分离，降低系统内部耦合
SOA	组织企业服务能力：通过服务契约暴露可复用能力，支撑跨系统整合
微服务	组织独立演进单元：围绕业务能力拆服务，使团队、代码和发布边界对齐
事件驱动 / 云原生	组织运行时协作：事件负责异步协作，平台负责部署、扩缩容、恢复和观测
AI 增强	组织语义增能：旧系统保主流程，AI 提供自然语言、知识增强和工具调用能力
AI 原生	组织机器认知：模型成为运行时主体，显式管理目标、工具、状态、评测和守护

质量属性取舍总览

不要只背优缺点，要说明这些优缺点为什么由结构产生。

架构	优先保障	相对牺牲 / 新复杂性
主机 / 终端	一致性、安全性、可靠性、可审计性	易用性、交互响应性、局部修改灵活性
C/S	易用性、响应性、桌面交互体验	可部署性、可维护性、版本一致性、统一治理
三层 / 分层	可维护性、可修改性、安全边界、部署治理	极致性能、跨系统复用、团队自治速度
SOA	互操作性、可复用性、可组合性、可治理性	简单性、响应性能、轻量部署、局部演进速度
微服务	可部署性、可扩展性、可修改性、演进速度	强一致性、运维简单性、故障定位、全局理解
事件 / 云原生	弹性、韧性、可扩展性、可用性、自动化运维	可理解性、可调试性、时序可预测性、强一致性

架构迁移原因

迁移不是“旧模式错了”，而是旧模式擅长解决的矛盾已经不再是系统最主要的矛盾。迁移逻辑通常来自规模、复杂度、维护成本和协作方式的变化。

架构	为什么旧架构“不够用了”
最早期	只适合固定任务和离线批处理，难以支撑多人共享核心事务
主机 / 终端	交互能力弱，终端灵活性低
C/S	客户端安装升级重，版本与兼容难治理
三层 / 分层	单系统可维护性提升，但跨系统复用不足
SOA	企业级整合增强，但治理与总线较重
微服务	局部发布更快，但分布式复杂度上升
事件 / 云原生	更适合高波动运行时，但时序与排障更难

最早期

核心思想：组织稳定执行。程序与数据组成作业，统一送入系统执行；执行围绕批处理与调度组织，强调吞吐和稳定。

迁移原因：最早期架构适合固定任务、离线作业和报表，但无法支撑大量用户持续在线访问同一数据，也缺少统一事务、权限和审计控制。因此系统需要从“执行任务”迁移到“服务一群用户”。

质量属性影响：

• 优先保障：吞吐量、稳定性、资源利用率。
• 相对牺牲：交互性、易用性、局部修改灵活性。

主机 / 终端

核心思想：组织核心事务。事务、数据、权限集中在主机，终端主要负责输入与显示。

迁移原因：批处理擅长固定任务的稳定执行，但无法支撑大量用户持续在线访问同一核心数据，也缺少统一事务、权限与审计控制。因此系统必须从“执行任务”转向“服务一群用户”。

质量属性影响：

• 优先保障：一致性、安全性、可靠性、可审计性。
• 相对牺牲：易用性、交互响应性、局部可修改性。

C / S 架构

核心思想：组织交互能力。客户端承担 UI 与部分逻辑，服务器管理共享数据。

迁移原因：主机 / 终端虽然能集中治理事务和数据，但终端太“瘦”，难以支持复杂 GUI 与本地交互；PC 算力已经可用，完全不下放逻辑变得不经济。因此系统开始把交互前移到客户端，把共享数据留在服务器。

质量属性影响：

• 优先保障：易用性、响应性、交互体验。
• 相对牺牲：可部署性、可维护性、版本一致性、统一治理。

三层 / 分层

核心思想：组织职责边界。表示层、业务层、数据层分离，降低系统内部耦合。

迁移原因：C/S 的客户端安装、升级、兼容成本随着规模上升而爆炸；客户端直接或强耦合访问数据层，不利于统一治理；一个系统里混杂了展示、业务和数据处理。因此重心从“前后分工”进一步转向“服务端内部清晰分层”。

质量属性影响：

• 优先保障：可维护性、可修改性、安全边界、部署治理。
• 相对牺牲：极致性能、跨系统复用、团队自治速度。

SOA

核心思想：组织企业服务能力。通过服务契约暴露可复用能力，支撑跨系统整合。

迁移原因：三层 / 分层擅长整理单个系统内部职责，但系统之间仍然割裂，集成常靠大量点对点接口；同一业务能力在不同系统中重复实现，跨系统流程变化时协调成本迅速上升。因此企业需要从“应用视角”上升到“服务能力视角”。

质量属性影响：

• 优先保障：互操作性、可复用性、可组合性、可治理性。
• 相对牺牲：简单性、响应性能、轻量部署、局部演进速度。

答题句：

SOA 通过契约 + 总线 + 编排 + 治理，把企业从孤岛系统集合拉向能力网络；它解决了企业整合，但也让服务粒度、治理体系和 ESB 成为新的重量级约束。

微服务

核心思想：组织独立演进单元。围绕业务能力拆服务，使团队、代码和发布边界对齐。

迁移原因：SOA 擅长企业级服务复用与流程编排，但服务边界偏粗，不易与快速变化的产品边界对齐；中心治理与总线容易形成变更瓶颈，跨团队依赖多，难以真正独立发布。因此服务必须更贴近业务能力、团队边界和发布节奏。

质量属性影响：

• 优先保障：可部署性、可扩展性、可修改性、演进速度。
• 相对牺牲：一致性、运维简单性、故障定位性、全局可理解性。

答题句：

微服务不是“服务更多”，而是“演进单位更小、交付链更短”；复杂度没有消失，而是从代码内部转移到分布式协作、数据一致性与运维层。

事件驱动 / 云原生

核心思想：组织运行时协作。事件负责异步协作，平台负责部署、扩缩容、恢复和观测。

迁移原因：微服务边界小、发布快、团队自治强，但全同步调用链会放大尾延迟和级联故障；服务变多后，发布、扩容、恢复、观测仍高度依赖人工。系统既要改变协作方式，也要改变运行方式。

质量属性影响：

• 优先保障：弹性、韧性、可扩展性、可用性、自动化运维能力。
• 相对牺牲：可理解性、可调试性、时序可预测性、强一致性。

AI 增强

核心思想：传统系统继续定义主流程，AI 负责语义增能而不接管全流程。现有业务系统保留主流程和主数据，新增模型调用层、Prompt / 路由、RAG / 知识、工具调用、审计和日志等组件。

迁移原因：用户开始直接用自然语言工作，传统软件擅长规则和流程，但不擅长开放式语义理解与知识处理。企业希望先把 AI 接到现有系统上，而不是推翻旧系统。

质量属性影响：

• 优先保障：易用性、语义适应性、知识获取效率、功能可扩展性。
• 相对牺牲：可预测性、可测试性、成本稳定性、安全边界清晰性。

AI 原生

核心思想：模型不再只是外部 API，而是系统运行时主体之一。Agent / 编排器负责目标理解、任务规划与执行流程组织；工具、知识、状态、记忆层成为模型可调用的运行时组件；评测、守护、权限和 HITL 用来治理非确定性。

迁移原因：AI 不只回答问题，还要完成任务；传统请求-响应式架构难以管理长链路、非确定性和多步协作，因此需要把上下文、工具、状态、评测和守护显式工程化。

质量属性影响：

• 优先保障：适应性、任务完成能力、人机协作效率、复杂工作流扩展能力。
• 相对牺牲：确定性、可验证性、成本可预测性、安全与责任边界清晰度。

结合业务系统说明模板

题目如果要求结合具体业务系统，可以用“选课系统 / 外卖系统 / 通知系统”套这个结构：

以选课系统为例：
最早期：选课名单、成绩统计等任务以批处理作业方式运行，适合稳定批量处理，但不能支持学生实时在线选课。
主机/终端：课程、名单、成绩等核心事务集中在主机，终端主要查询和录入，保障一致性和安全性，但交互弱。
C/S：客户端承担选课界面和部分逻辑，服务器管理共享课程数据，提升桌面交互体验，但客户端升级和版本治理变重。
三层/分层：浏览器统一入口，表示层、业务层、数据层分离，降低维护成本，但复杂度仍集中在单系统内。
SOA：把课程、成绩、支付等能力封装成服务，通过契约和治理支持跨系统整合，但 ESB 和治理体系较重。
微服务：按课程、选课、成绩、通知、用户等业务能力拆服务，使团队和发布边界对齐，但数据一致性和排障更复杂。
事件/云原生：抢课高峰通过事件和平台能力削峰、扩容、恢复和观测，提高弹性与可用性，但时序和调试更复杂。

Generic Design Strategy

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

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

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

Design Strategies 在 ADD 中的体现

策略	在 ADD 中如何体现
Decomposition	Step 3 选择元素并逐步分解
Abstraction	用模块、组件、接口抽象隐藏细节
Divide & conquer	Step 2 每次选择一组 drivers，拆成可处理的子问题
Generation & 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.

架构文档化补充

三种 Notation

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

趋势：

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

敏捷架构文档

原则：just enough documentation。

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

架构变化快于文档怎么办

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

微服务拆分大题

考试形式

往年微服务拆分题通常会给一个具体业务场景，例如外卖平台、电商平台、选课系统等，然后要求结合微服务架构进行设计分析。题目重点不是默写微服务定义，而是把 PPT 里的拆分模式应用到具体案例中。

常见问法：

• 为什么该系统适合使用微服务架构。
• 根据业务需求识别系统操作。
• 根据系统操作和业务能力划分微服务。
• 说明系统操作、微服务和服务协作之间的对应关系。
• 必要时画出微服务之间的简单结构图或说明 API / 事件协作方式。

答题要点

微服务拆分题可以直接套用 PPT 里的三步：

• 定义系统操作：从需求、用户故事或业务场景中找动词，识别系统要完成的业务动作。操作不是服务名，而是系统行为，例如“创建订单”“支付订单”“分配骑手”。
• 定义微服务：根据业务能力或子域拆分服务，使服务边界与业务边界一致。每个服务围绕一个稳定业务概念组织，目标是高内聚、低耦合。
• 定义服务 API 和协作方式：把系统操作分配给对应服务，并说明服务之间通过 API 调用或事件机制协作。

如果题目先问“为什么适合微服务”，不要只说“因为能拆服务”，要对应 PPT 中的微服务定义和主要特性来答：

• 微服务把应用功能分解为一组服务，每个服务由一组专注、内聚的功能职责组成。
• 微服务是细粒度服务，运行在独立进程中，服务之间采用轻量级通信机制，例如 HTTP RESTful API。
• 微服务围绕系统的业务能力构建，可以通过自动化部署机制独立部署。
• 微服务强调服务解耦组件化、非共享数据库、独立部署运行、独立扩展伸缩、去中心化协同管理。
• 微服务适合业务能力边界清楚、变化频繁、不同模块负载不同、需要快速交付和独立扩展的系统。

答题时可以按这个顺序组织：

• 先说明为什么适合微服务：业务边界清楚，可以拆成专注内聚的细粒度服务；服务可独立进程运行、轻量级通信、独立部署和扩展。
• 再列系统操作：从题干中提取动词。
• 再列微服务：按业务能力/子域拆分。
• 最后写对应关系：哪个操作由哪个服务负责，哪些服务需要协作。

注意：

• 不要把“操作”和“微服务”混在一起。“下单”是操作，“订单服务”才是微服务。
• 不要按技术层次拆成 controller、service、DAO，而要按业务能力拆。
• 不要让一个服务承担所有职责，例如订单服务不应该同时负责支付、配送、通知的全部逻辑。
• 要写微服务带来的代价：分布式一致性、运维复杂性、故障定位、服务调用链复杂度。

答题示例

题目：以 PPT 中 FTGO 外卖系统为例，说明如何将系统操作映射到服务。

FTGO 适合使用微服务架构，因为微服务架构可以把应用功能分解为一组细粒度服务，每个服务由一组专注、内聚的功能职责组成。FTGO 中消费者、订单、餐厅、厨房、配送等业务能力边界比较清晰，适合围绕业务能力拆分服务。拆分后，各服务运行在独立进程中，通过轻量级通信机制协作，并可以独立部署和扩展，从而支持业务变化、团队自治和快速交付。

PPT 中这一步叫作：将系统操作分配给服务。基本思路是先确定请求的初始入口服务；如果某个操作映射不清晰，就把它分配给最需要掌握该操作所需信息的服务。例如 noteUpdatedLocation() 与送餐员和配送都有关，但配送服务需要使用位置信息，所以分配给 Delivery Service；noteOrderReadyForPickup() 表示厨房已备餐完成，所以分配给 Kitchen Service。

FTGO 的系统操作可以这样映射：

Service	Operations
Consumer Service	createConsumer()
Order Service	createOrder()
Restaurant Service	findAvailableRestaurants()
Kitchen Service	acceptOrder()、noteOrderReadyForPickup()
Delivery Service	noteUpdatedLocation()、noteDeliveryPickedUp()、noteDeliveryDelivered()

这张表表达的是“哪个服务负责处理哪些系统操作”，不是完整调用链。真正实现时，一个操作可能还需要通过 API 调用或事件机制与其他服务协作，例如 createOrder() 的初始入口是 Order Service，但创建订单过程中可能还需要餐厅、厨房或配送相关服务提供信息。