大三下 软件系统设计期末复习 20260623

（AI辅助生成）

软件体系结构 考前速记（一天抢救版）

这门课的核心就一句话：架构是用来满足质量属性的，Pattern + Tactic 是你的工具，ADD 是你设计的方法，ASR 是你设计的靶子。

1. 基础三问（必考）

What is Software Architecture? 什么是软件架构？

The structures of a system, consisting of software elements, their externally visible properties, and relationships among them.

架构不是代码，不是某个类或函数。架构是高层面的东西 —— 系统有哪些部分（元素），每个部分对外暴露什么（外部可见属性），部分之间怎么配合（关系）。比如电商系统有用户模块、订单模块、支付模块，它们之间的调用关系和数据流向，这才是架构关心的。

速记：结构 + 元素 + 关系

What does a Software Architect do? 架构师做什么？

架构师不是只写代码的高级程序员，他/她要做五件事：

  1. Liaison（联络人） — 在客户、技术团队、业务分析师之间搭建桥梁。客户说"我要快"，技术人员说"快不了因为数据库慢"，架构师要把业务语言翻译成技术决策。
  2. Supervise（监督） — 确保开发过程遵循架构设计，别写着写着就跑偏了。
  3. Technical knowledge（技术知识） — 深入理解技术领域，知道什么技术能解决什么问题。
  4. Risk management（风险管理） — 技术选型、设计决策都有风险，架构师要识别和管理这些风险。
  5. Software engineering best practices（工程最佳实践） — 推广代码规范、测试、CI/CD 等工程实践。

速记口诀：联络 + 监督 + 技术 + 风控 + 实践

Where do architectures come from? 架构从哪来？

架构不是凭空想出来的，它有三个来源：

来源维度 具体内容 解释
需求面 NFRs / ASRs / Quality Requirements 系统不仅要"能用"（功能），还要"好用"（质量）。比如"查询订单要在 200ms 内返回"就是质量需求。
业务面 Stakeholders, Organizations, Business Goals 不同的人有不同的诉求。老板要低成本，用户要快，运维要好部署，安全团队要高安全——架构要在这些之间权衡。
技术面 Technical Environment, Constraints 现有技术栈、团队能力、预算/时间限制、法规要求等都会影响架构选择。

2. 4+1 Views（必考中的必考）

这是本课程最重要的概念之一。一个系统太复杂了，没法用一张图说清楚，所以 Kruchten 提出用 5 个视角来描述架构。

View 回答什么问题 对应 Style 画什么图
Logical (逻辑视图) 系统提供什么功能？各模块怎么分工？ — 类图、包图
Process (过程视图) 系统运行时各进程怎么并发和通信？ C&C 时序图、活动图
Development (开发视图) 代码怎么组织？模块怎么分包？ Module 包图、组件图
Physical (物理视图) 软件跑在哪些硬件/虚拟机上？ Allocation 部署图
Scenarios (+1) 用具体用例把上面四个视图串起来验证 — 用例图

为什么要 "4+1" 而不是 1 个？ 因为不同的涉众关心不同的东西 —— 开发者关心代码组织（Development View），运维关心部署在哪（Physical View），用户关心功能好不好用（Logical View），性能和安全人员关心运行时行为（Process View）。Scenarios 则是用实际用例来检验这四个视图是否一致。

记忆口诀：Logical → Process → Development → Physical + Scenarios
"老 (L) 婆 (P) 的 (D) 屁 (P) 事 (S)"

3. Architectural Process（架构流程四步走）

这不是一次性做完的，是循环迭代的：

识别 ASRs → 架构设计 → 架构文档化 → 架构评估
(Identifying) (Designing) (Documenting) (Evaluating)
     ↑                                              |
     └──────────────────────────────────────────────┘
                      (迭代循环)

每一步解释：

  1. 识别 ASRs：从一堆需求中找出对架构影响最大的那些（见第 10 章）。
  2. 架构设计：用 ADD 方法（见第 11 章），选择 Pattern 和 Tactic，画出架构草图。
  3. 架构文档化：把设计写成文档（见第 9 章 Views and Beyond），让其他人能理解。
  4. 架构评估：检查架构是否满足 ASR，不满足就回去改。

4. Architecture vs Design vs Structure（三个易混概念）

对比 关系 通俗理解
Architecture vs Design 所有 Architecture 都是 Design，反之不一定。Architecture 是 Design 的一个子集。 Design 包括了架构，也包括了代码细节。架构是 Design 中最高层次的部分。就像房子：建筑设计（Architecture）= 房间布局、承重墙、管道走向；详细设计（Design）= 用什么牌子的瓷砖、插座位置多高。
Architecture vs Structure Structure 是静态/逻辑的组成方式；Architecture 除了 Structure 还包括接口、动态行为、关系。 Structure 只是"骨头"（各部分怎么拼在一起），Architecture 还要加上"血液循环"（动态交互）和"神经系统"（接口和关系）。

5. Software Requirements（三类需求）

需求不只有"系统要做什么"，还有"要做多好"和"有什么限制"。

类型 英文 核心 举例
功能性需求 Functional Requirements 系统做什么 (What) "用户可以下单"、"可以查询库存"
质量需求 Quality Requirements = NFRs 系统做得多好 (How well) "下单响应 < 200ms"、"全年 99.99% 可用"
约束 Constraints 不能突破的限制 (Limits) "必须用 Java 开发"、"必须部署在阿里云"

关键理解：功能可以通过很多种结构实现（比如"用户下单"功能，你可以用单体架构实现，也可以用微服务实现），但质量属性才决定了你选哪种结构。这就是为什么架构设计主要是在满足质量需求。

Quality Attribute Scenario（质量属性场景，六要素）

考场上让你写一个质量属性场景，按这个模板填就行：

Source (谁) → Stimulus (做了什么) → Artifact (谁受影响) → Environment (什么条件下) → Response (系统怎么应对) → Measure (怎么衡量)

具体例子：

  • 可用性场景：用户(Source) 在高峰时段(Environment) 发起支付请求(Stimulus) → 支付服务(Artifact) 正常处理并返回结果(Response)，成功率 ≥ 99.9%(Measure)。
  • 性能场景：10000 个并发用户(Source) 在正常负载下(Environment) 同时发起查询请求(Stimulus) → 搜索服务(Artifact) 返回结果(Response)，平均延迟 < 100ms(Measure)。
  • 安全性场景：黑客(Source) 在网络传输中(Environment) 试图篡改请求数据(Stimulus) → 系统(Artifact) 检测篡改并拒绝请求(Response)，100% 检测率(Measure)。

6. 质量属性速查表

常用质量属性（建议全记，英文拼对就有分）

属性 含义 一句话理解
Availability 可用性 系统该能用的时候能用吗？99.99% = 一年只有 52 分钟不可用
Performance 性能 快不快？关注延迟(Latency)和吞吐量(Throughput)
Security 安全性 防得住攻击吗？包括机密性、完整性、可用性 (CIA 三要素)
Scalability 可扩展性 流量涨了加机器能不能扛住？水平扩展（加机器）vs 垂直扩展（换更好的机器）
Modifiability 可修改性 改一个功能成本高不高？改的地方多不多？
Testability 可测试性 好不好写测试？依赖越少越好测
Interoperability 互操作性 能跟其他系统配合吗？接口标准吗？
Reliability 可靠性 能不能长期稳定运行不出错？和可用性的区别：可靠性关注"不出错"，可用性关注"能访问"
Usability 易用性 用户用起来方不方便？
Portability 可移植性 换一个平台/环境好不好部署？
Reusability 可复用性 这些代码/模块能不能在别的项目复用？

重要！质量属性分类

外部属性 (执行时可观察) 内部属性 (执行时不可观察)
Performance, Security, Availability, Usability, Reliability, Scalability Modifiability, Portability, Reusability, Testability, Maintainability

为什么这么分？ 外部属性是系统跑起来才能观测的（比如快不快、会不会崩），内部属性是看代码就能判断的（比如模块划分清不清晰、好不好改）。外部属性直接影响用户体验，内部属性影响开发效率和长期维护成本。

7. 三类架构风格 + 模式（重中之重！整门课的骨架）

什么是 Style（风格）？什么是 Pattern（模式）？

  • Style = 元素类型 + 关系类型 + 约束。比如"所有 C&C 风格都使用 Component 和 Connector 作为元素"。
  • Pattern = 一个具体的解决方案，包含：Context（什么场景） + Problem（什么问题） + Solution（怎么解决，用的是某个 Style）。

简单说：Style 是"大类"，Pattern 是"具体配方"。

三大 Style 类别

Style 核心问题 典型 Patterns 怎么记
Module 代码怎么组织？ Layered 静态的、编译时的，关心的是代码文件/包的结构
Component-Connector (C&C) 运行时怎么交互？ Broker, MVC, Pipe-Filter, Client-Server, P2P, SOA, Publish-Subscribe, Shared-Data 动态的、运行时的，关心的是进程/服务之间的通信
Allocation 怎么映射到硬件/团队？ Map-Reduce, Multi-Tier 部署的、组织的，关心的是软件放哪、谁负责

这是选择题/归类题的送分点： 题目给一个 Pattern 名字，判断属于 Module / C&C / Allocation。记住：除了 Layered 是 Module，Map-Reduce 和 Multi-Tier 是 Allocation，其余几乎全是 C&C。

各 Pattern 详解

Module Patterns

Layered Pattern（分层模式）

  • 核心思想：把系统分成 N 层，每一层只能调用它下面那一层的服务。比如典型的三层架构：Presentation（界面）→ Business Logic（业务逻辑）→ Data Access（数据访问）。不能反向调用，也不能跨层调用。
  • 元素：Layer（层）
  • 关系：Allowed to use（允许使用），单向向下
  • 约束：每个组件只能属于一个层；至少两层；层间依赖不可循环。
  • 弱点：
    1. 层多了系统变复杂（前期成本高）
    2. 层间调用有性能损耗（多一层调用就慢一点）
    3. 有时候一层里只是转发，没干实际的事
  • 适用场景：企业应用、Web 应用等需要清晰职责分离的系统。

Component-Connector Patterns

Broker Pattern（代理模式）

  • 核心思想：客户端不直接找服务器，而是通过 Broker（中介）来找到合适的服务器。就像房产中介：你想租房子（客户端），房东要出租（服务器），中介撮合你们。
  • 元素：Client, Server, Broker, Client-side Proxy, Server-side Proxy
  • 弱点：Broker 是单点故障（它挂了整个系统就挂了）；多了一层增加延迟；可能成为性能瓶颈；安全性风险（攻击 Broker 可以影响所有通信）。

MVC Pattern（模型-视图-控制器）

  • 核心思想：把系统分成三部分 —— Model 管数据和业务逻辑，View 管界面展示，Controller 管用户输入和调度。用户点了一个按钮 → Controller 收到事件 → Controller 更新 Model → Model 通知 View 刷新。
  • 元素：Model, View, Controller
  • 关系：Model 通知 View（发布-订阅），Model 响应 Controller（方法调用），View 通知 Controller（事件）
  • 约束：Model 不能直接和 Controller 交互
  • 弱点：简单界面用 MVC 是过度设计；有些 UI 框架不太适配 MVC 的抽象方式。

Pipe-Filter Pattern（管道-过滤器）

  • 核心思想：数据像水流一样经过一个又一个 Filter，每个 Filter 做一次转换，Filter 之间用 Pipe 连接。Unix 命令行就是最经典的例子：cat file.txt | grep "error" | sort | uniq。
  • 元素：Filter（过滤器，转换数据），Pipe（管道，传输数据）
  • 约束：Pipe 连接 Filter 的输出到另一个 Filter 的输入；连接的 Filter 必须约定好数据格式。
  • 优点：每个 Filter 独立，可复用，可并发执行，可增量处理数据。
  • 弱点：不适合交互式系统（用户要点来点去的那种）；Filter 太多 → 计算开销大；不太适合长时间运行计算。

Client-Server Pattern（客户端-服务器）

  • 核心思想：客户端发起请求，服务器处理并返回结果。网站就是典型的 C-S：浏览器（客户端）→ Web 服务器。
  • 元素：Client, Server, Request/Reply Connector
  • 弱点：服务器是性能瓶颈和单点故障；功能放在客户端还是服务器端不好决定（放错了后面改成本高）。

Peer-to-Peer Pattern（P2P）

  • 核心思想：没有中心服务器，每个节点既是客户端也是服务器，相互协作。BT 下载就是 P2P。
  • 元素：Peer（对等节点），Request/Reply Connector
  • 约束：连接关系可以动态变化
  • 弱点：安全管理复杂（没有中心控制）；数据一致性难保证；小规模时性能/可用性不好。

SOA Pattern（面向服务架构）

  • 核心思想：把系统拆成独立服务，通过 ESB（企业服务总线）来路由和转换消息。每个服务通过标准接口对外提供功能。SOA 有 7 个原则：服务解耦、服务契约、服务封装、服务重用、服务组合、服务自治、服务无状态。
  • 元素：Service Provider, Service Consumer, ESB, Registry, Orchestration Server
  • 弱点：构建复杂；ESB 重且可能成瓶颈；无法控制独立服务的演进；中间件有性能开销。
  • SOA 对质量属性的影响：
    • 互操作性 ↑（符合开放标准）
    • 可伸缩性 ↑（服务间松耦合）
    • 安全性 ↓（ESB 成为攻击目标，多服务使攻击溯源困难）
  • SOA 怎么从 Broker 演变而来：Broker 是单点中介，SOA 把单一 Broker 扩展为一套基础设施（ESB + Registry + Orchestration），解决了单点失效问题。随着互联网普及、参与者规模扩大，服务粒度可以更细，需要更高的互操作性和伸缩性。

Publish-Subscribe Pattern（发布-订阅）

  • 核心思想：发布者发布事件，订阅者订阅感兴趣的事件，中间的事件总线负责分发。就像微博：你关注了一个博主（订阅），博主发微博（发布），你就能收到。
  • 元素：Publisher, Subscriber, Publish-Subscribe Connector
  • 弱点：增加延迟；消息顺序不可控；不保证消息一定送达（可能丢消息）。

Shared-Data Pattern（共享数据）

  • 核心思想：多个数据访问者通过一个共享的数据存储来交换数据。比如多个微服务共享一个数据库。
  • 元素：Shared Data Store, Data Accessor, Data Reading/Writing Connector
  • 弱点：数据库成为性能瓶颈和单点故障；生产者和消费者之间可能强耦合。

Allocation Patterns

Map-Reduce Pattern（映射-归约）

  • 核心思想：Map 阶段把大数据集拆分成小块并行处理（提取和转换），Reduce 阶段把结果汇总（加载）。对应 ETL 流程：Extract → Transform → Load。
  • 元素：Map Function（多个实例，无状态，互不通信），Reduce Function，Infrastructure
  • 约束：数据必须是文件集；Map 函数无状态且不通信；Map 和 Reduce 之间只能用 <key, value> 对传数据。
  • 弱点：数据量不大时不划算；数据如果不能均匀分割，并行优势就没了；需要多次 Reduce 的操作编排复杂。

Multi-Tier Pattern（多层部署）

  • 核心思想：把系统的不同组件分组部署到不同的计算平台上。比如 Web 服务器部署在一组机器上，数据库部署在另一组机器上。注意：Tier 是物理概念（部署在哪），Layer 是逻辑概念（代码怎么分）。
  • 元素：Tier（层），计算平台
  • 弱点：前期成本高，复杂度高。

常考混淆点

Layered vs Multi-Tier（高频对比题！）

Layered Multi-Tier
Style 类别 Module（逻辑的） Allocation（物理的）
核心 代码的职责分层 软件部署到不同机器
依赖关系 严格单向，上层依赖下层 没有强依赖，只是部署分组
举例 三层架构：Presentation → Logic → Data Web 层放一台机器，DB 层放另一台机器

一句话区分： Layered 关心"代码怎么写"，Multi-Tier 关心"软件部署到哪"。

SOA vs Microservices（高频对比题！）

SOA 微服务
通信方式 重！ESB 企业服务总线 轻！REST / 消息队列
数据管理 全局共享数据库 每个服务有自己的数据库
服务粒度 粗（一个大服务管很多事） 细（一个服务只管一件事）
部署方式 传统部署 DevOps 自动化（CI/CD，容器化）
特色组件 ESB, Registry, Orchestration Server API Gateway（统一入口）, Circuit Breaker（熔断器）, Service Registry
设计理念 企业级集成，强调复用 围绕业务能力，强调独立自治

速记口诀：单体"简而僵"，SOA"重而通"，微服务"活而繁"

为什么微服务去掉了 ESB？
ESB 太重了，在微服务架构中，ESB 的智能路由逻辑被移到了各个服务端点（Smart Endpoints）。微服务追求"Dumb pipes, smart endpoints"（管道要笨，端点要聪明），而 SOA 的 ESB 恰恰相反——管道很聪明，但带来了复杂度和性能瓶颈。

8. Patterns vs Tactics（高频简答题）

Pattern（模式） Tactic（战术/策略）
粒度 大，多个 tactics 的组合 小，单一的结构或机制
目标 解决一类问题，包含上下文、问题、解决方案 应对一个特定的质量属性
关系 Pattern = 多个 Tactic 的有机组合 Tactic 是 Pattern 的组成零件
举例 MVC Pattern 针对 Modifiability 的 Tactic：抽象接口、分离关注点

例：你想实现高可用性（Availability），你可以选择：

  • Tactic 层面：心跳检测、主动冗余、故障转移
  • Pattern 层面：把这些 Tactic 组合成 Broker Pattern 或 Client-Server Pattern 来实现

9. Views and Beyond（文档化）

为什么需要 "Beyond"？

光给几张 UML 图是不够的 —— 看图的人不知道图里每个元素是什么，不知道为什么这么设计，不知道多个图之间怎么对应。所以文档包 = Views（图）+ Beyond（解释）。

View 内部的 6 个要素（给你一张图，你要提供这 6 样东西）

要素 是什么 怎么理解
Primary Presentation 主图 用 UML 等画的核心图示
Element Catalog 元素目录 解释图里的 A、B、C 分别是什么，职责是什么
Context Diagram 上下文图 系统与外部的边界和交互
Variability Guide 变异性指南 哪些地方未来可能变化，怎么应对
Rationale 设计理由 解释"为什么不那么设计"，记录关键决策的 trade-off
Glossary 等 术语表等 统一术语，避免沟通误解

Beyond Views（视图之外）

  • 文档路线图：介绍文档的组织结构，指引读者怎么阅读。
  • 视图间的映射：解释 Logical View 里的 A 组件对应 Physical View 里的哪台机器。
  • 全局设计决策理由：为什么选微服务不选单体？为什么用 Kafka 不用 RabbitMQ？
  • 术语表 (Glossary)：全局术语统一。

3-Step 选择视图（你怎么决定画哪些图？）

  1. 构建涉众/视图表：列出所有涉众（用户、开发者、运维...），他们各自关心什么视图。
  2. 合并边缘视图：有些视图只有很少人关心（边缘视图），把它合并到更重要的视图里，减少文档量。
  3. 确定优先级（80/20 原则）：画最重要的 20% 的视图，覆盖 80% 的需求。不要面面俱到。

10. ASRs（架构攸关需求）— 必考大题

什么是 ASR？

ASR = Architecturally Significant Requirement，是对架构有深远影响的需求。如果这个需求变了或者缺失了，整个架构都要跟着大改。

举个例子："系统要支持 10000 个并发用户" 如果是真的且很难实现，它就是一个 ASR。"登录页面的按钮是蓝色的" 显然不是 ASR。

ASR 的三个来源

  1. 重要的质量属性 — 难度越高越可能是 ASR。比如"支付成功率 ≥ 99.999%"比"响应时间 < 2s"更可能成为 ASR。
  2. 核心/复杂的功能需求 — 比如"实时推荐引擎"比"用户信息展示"更具架构影响。
  3. 影响全局的约束 — 比如"整个系统必须基于国产化技术栈"。

怎么获取 ASR？（四种方法，简答题常考）

方法 具体做法
需求文档分析 用 MoSCoW 方法（Must/Should/Could/Won't）筛选出 Must 需求，结合用户故事提取 ASR
采访涉众 通过 QA (Quality Attribute Workshop) 质量属性工作坊，让涉众表达真实的质量诉求
了解业务目标 从业务目标反推：公司要做中国最大电商平台 → 极高性能、极高可用性 → 这些就是 ASR
Utility Tree（质量属性实体树） 把质量属性从抽象到具体逐层分解，直到可量化为止（最重要方法！）

Utility Tree 结构（画图/填空常考）

根节点：系统 Utility（效用）
  ├── 质量属性 1：Performance（性能）
  │     ├── 细化：Response Time（响应时间）
  │     │     └── 量化场景：(H, H) 页面加载 < 2s
  │     └── 细化：Throughput（吞吐量）
  │           └── 量化场景：(M, H) 支持 10000 QPS
  ├── 质量属性 2：Availability（可用性）
  │     └── 细化：Fault Recovery（故障恢复）
  │           └── 量化场景：(H, M) 故障恢复时间 < 5min
  └── ...

注：(H, H) = (业务重要性高, 技术难度高)
    (H, M) = (业务重要性高, 技术难度中)

SR、QA、ASR 三者的关系（简答/名词解释常考）

Software Requirements（软件需求）
  ├── Functional Requirements（功能性需求：系统做什么）
  └── Non-Functional Requirements = NFRs（非功能性需求）
        ├── Quality Attributes（质量属性：做得多好）
        └── Constraints（约束：有什么限制）

ASR（架构攸关需求） ⊂ Software Requirements
ASR 是对架构影响最深的那部分需求，包含三方面：
  1. 重要的质量属性（越重要越难 → ASR）
  2. 核心功能性需求
  3. 影响全局的约束

关键结论：不是所有需求都是 ASR，但所有 ASR 都是需求。QA 越重要越难实现，越可能成为 ASR。

11. Designing Architecture（设计方法）

六大通用设计策略（ADD 3.0 的底层逻辑）

ADD 3.0 本质上是这六大策略的循环运用。理解这六个，更复杂的 ADD 也只是它们的系统化组合。

策略 中文 通俗理解 在 ADD 中的应用
Decomposition 分解 把大象放进冰箱分三步。大系统拆成小模块，每个模块再拆成小组件。 每一轮 ADD 迭代都在做分解：选一个元素，把它拆开
Abstraction 抽象 你不需要知道手机内部怎么运作，你只需要知道按开机键就行。隐藏实现细节，只暴露接口。 定义组件接口时就是抽象：比如定义 PriceService 接口，隔离具体实现
Divide & Conquer 分而治之 递归地把问题拆到每个小问题都能独立解决为止。 迭代 1 定结构，迭代 2 填功能，迭代 3 优质量
Generate & Test 生成与测试 先提出一个设计方案（假设），然后验证它是否满足要求。 提出 CQRS 微服务架构 → 性能测试是否能达到 100ms → 不行就换方案
Iteration 迭代 一次做不完，多做几轮，每轮比上一轮更详细。 ADD 的核心就是迭代：Step 7 不满足就回 Step 2，直到所有 ASR 被满足
Reuse 复用 不要重新发明轮子。Kafka 能做消息队列，就别自己写一个。 复用现有架构模式、成熟组件（Kafka/Redis）、已验证的设计决策

ADD 3.0（属性驱动设计）— 核心设计方法，7 步循环

ADD 3.0 是本课程最重要的设计方法论。它的核心理念：不是一次性完成设计，而是通过多轮迭代，每一轮聚焦一个或几个驱动因素。

Step 1: Review Inputs
         审查输入（需求、ASRs、约束）
              ↓
Step 2: Identify Drivers & Iteration Goal
         选定本轮要解决的驱动因素（选最重要的 1-2 个 ASR）
              ↓
Step 3: Choose System Element(s) to Refine
         选一个要细化设计的部分（先整体，再局部）
              ↓
Step 4: Choose Design Concepts
         选设计概念/模式/策略来满足驱动因素
              ↓
Step 5: Instantiate Elements, Allocate Responsibilities, Define Interfaces
         把抽象的设计变成具体元素，分配职责，定义接口
              ↓
Step 6: Create Views & Record Design Decisions
         用 UML 等画图，记录为什么这么设计
              ↓
Step 7: Analyze & Review → 不满足就回 Step 2
         检查是否满足本轮目标，是否还需要下一轮迭代

ADD 3.0 和往年的区别： 往年版本强调"分解系统元素"作为核心步骤，3.0 版本更强调设计概念的选择和驱动因素的聚焦。如果试卷问旧版，按 8 步答（见你笔记）。

ADD 3.0 中的设计概念（Design Concepts）

在 Step 4 中，你可以选择的设计概念包括：

  • 参考架构 (Reference Architectures)：微服务架构、分层架构、事件驱动架构
  • 部署模式 (Deployment Patterns)：多区域冗余、Kubernetes 容器编排
  • 设计模式 (Design Patterns)：CQRS、观察者模式、策略模式
  • 战术 (Tactics)：针对具体质量属性的手段（心跳检测 → 可用性，缓存 → 性能）

七类设计决策（Categories of Design Decisions）

每次做架构设计时，你在这七个方面都在做决策：

  1. 职责分配 (Responsibilities)：哪个模块负责什么功能？
  2. 协调模型 (Coordination)：模块之间怎么协同工作？同步还是异步？
  3. 数据模型 (Data)：数据怎么组织？持久化还是内存存储？
  4. 资源管理 (Resources)：CPU、内存、网络等资源怎么分配？
  5. 架构元素间映射 (Elements Mapping)：逻辑组件和物理部署怎么对应？
  6. 绑定时间 (Binding Time)：某个决策是编译时确定还是运行时确定？
  7. 技术选择 (Technology)：选什么技术栈？Java 还是 Python？MySQL 还是 MongoDB？

12. 微服务架构（Microservices Architecture）

六大核心特征（列举题，每个都能用一句话说清楚）

  1. Componentization via Services（通过服务组件化）
    把系统拆成一个个独立的服务，每个服务可以独立开发、部署、升级、替换。服务就是一个可以独立替换的软件单元。

  2. Organized around Business Capabilities（围绕业务能力组织）
    传统单体按技术层分（前端团队、后端团队、数据库团队）。微服务按业务分（订单团队管订单的所有层，库存团队管库存的所有层），每个团队是产品的 owner，全栈负责。

  3. Smart Endpoints, Dumb Pipes（端点聪明，管道笨）
    服务内部高内聚——一个服务管好自己的事。服务间低耦合——通过简单的 REST/消息通信，不依赖复杂的中间件。和 SOA 的 ESB（智能管道）正好相反。

  4. Decentralized Governance & Data（去中心化治理和数据）
    每个服务有自己的技术栈（你可以用 Java，我用 Go）、自己的数据库（绝不共享数据库）、自己的决策权。没有中央架构委员会管所有事。

  5. Infrastructure Automation（基础设施自动化）
    CI/CD 自动化测试和部署、容器化（Docker）、编排（Kubernetes），因为服务太多手动管不过来。

  6. Design for Failure（容错设计）
    服务多了，总会有某个服务挂掉。系统必须能容忍局部失败——熔断、降级、重试、超时。不能因为一个服务挂了导致整个系统雪崩。

微服务 vs SOA（完整对比）

对比维度 SOA 微服务
通信中间件 企业服务总线 (ESB)，重且复杂 轻量协议 (REST, gRPC, 消息队列)
数据管理 全局共享数据库 每个服务独立数据库
服务粒度 粗（一个大服务包含很多功能） 细（单一职责，只做一件事）
部署方式 传统部署，手动或半自动 DevOps 全自动化 CI/CD，容器化
治理模式 集中式治理，统一标准 去中心化，团队自治
特色组件 ESB, Registry, Orchestration Server API Gateway, Circuit Breaker, Service Registry
设计重点 服务重用、集成 业务能力、独立自治
开发效率 中等（认知门槛中等） 低（认知门槛高，分布式复杂性）
运维复杂度 中等 高（服务多，需高度自动化）
灵活性 高（支持跨平台） 最高（技术栈完全自由）
扩展性 中（ESB 可能成为瓶颈） 高（细粒度独立扩展）

速记口诀：单体"简而僵"，SOA"重而通"，微服务"活而繁"

微服务四大类设计模式

1. 拆分模式（Decomposition）— 怎么拆？

模式 核心思想 适用场景
按业务能力拆分 按商业活动划分（订单服务、库存服务、支付服务） 业务稳定的新系统
按子域拆分（DDD） 限界上下文 = 服务边界 领域复杂系统
按调用关系拆分 分析代码/运行时依赖聚类 遗留系统重构（棕地）

重构策略：策略 1 — 新功能用微服务实现；策略 2 — 逐步提取现有业务能力到独立服务。

2. 通信模式（Communication）— 怎么通信？

  • API Gateway：统一入口，负责路由、认证、限流、聚合。客户端只和网关打交道，不直接访问各服务。
  • Circuit Breaker（熔断器）：当某个下游服务连续失败，熔断器自动断开，快速失败而不是一直等待。三状态循环：Closed(正常) → Open(熔断) → Half-Open(试探) → Closed/Open...
  • Service Registry & Discovery（服务注册发现）：服务启动时注册自己，调用时从注册中心找到目标服务地址。自注册（Eureka）vs 平台注册（K8s）。

3. 部署模式（Deployment）— 怎么部署？

  • 单服务单容器：一个服务打成一个 Docker 镜像，Kubernetes 编排管理。
  • Serverless：连容器都不用管，直接上传代码，平台自动扩缩。

4. 可观测性模式（Observability）— 怎么监控？

  • 日志聚合 (Log Aggregation)：所有服务的日志集中收集（ELK 技术栈）。
  • 分布式追踪 (Distributed Tracing)：一个请求经过多个服务，追踪全链路。
  • 应用指标 (Application Metrics)：CPU、内存、QPS、延迟等指标监控和告警。

13. DDD（领域驱动设计）— 核心要点

DDD 和微服务是黄金搭档。DDD 帮你找到服务的边界（怎么拆），微服务帮你实现。

核心概念速记

概念 英文 解释 通俗比喻
统一语言 Ubiquitous Language 开发团队和业务专家用同一种语言沟通，代码里的类名、方法名直接用业务术语 不翻译——业务说"订单"，代码就叫 Order，不要搞个 TradeOrder 又搞个 SalesRecord
限界上下文 Bounded Context 一个模型在特定范围内有明确的含义，这个边界就是限界上下文 "用户"在订单系统里代表买家，在会员系统里代表会员——两个上下文中"用户"含义不同，需要分开
实体 Entity 有唯一标识的对象，ID 不变，属性可改变 一个人，改名字改地址还是同一个人（身份证号不变）
值对象 Value Object 没有唯一标识，不可变，相等取决于值 钱——10 块钱和另一个 10 块钱完全等价，不存在"编号为 001 的 10 块钱"
聚合 Aggregate 一组对象的集合，通过聚合根（Aggregate Root）访问 订单是聚合根，订单项是聚合内部对象——外部只能通过订单来操作订单项
领域事件 Domain Event 领域中发生的有业务意义的事件 "订单已支付"——触发库存扣减和物流通知

DDD 核心逻辑

业务驱动，不是数据驱动。 先深入理解业务领域，构建准确的业务模型，再根据模型设计软件。不是先把数据库表建好再反过来写代码。

DDD 战略设计流程

  1. 分析业务领域 → 划分子域（核心域、支撑域、通用域）
  2. 识别限界上下文 → 定义模型边界
  3. 建立上下文映射 → 定义上下文之间的交互关系（共享内核、客户-供应商、防腐层等）

DDD 和微服务的关系

限界上下文 ≈ 微服务边界。DDD 帮你找到"在哪拆"，微服务帮你"拆开来跑"。

14. UML 速查

UML 图对应关系（看图识图题）

UML 图 属于哪类 View 用途 识图关键特征
Package Diagram（包图） Module View 展示代码组织、模块分组 文件夹/包图标 + 虚线箭头（依赖）
Class Diagram（类图） Module View 展示类的静态结构 方框分三格（类名、属性、方法）+ 各种线（继承△、关联→、聚合◇、组合◆）
Component Diagram（组件图） C&C View 展示组件和接口关系 组件方框 + 棒棒糖（提供接口）+ 插座（需要接口）
Sequence Diagram（时序图） C&C View 展示时间顺序的消息交互 顶部矩形（生命线）+ 竖虚线 + 横向箭头（消息）+ 时间从上到下
Deployment Diagram（部署图） Allocation View 展示软件部署到哪些硬件节点 立方体（节点/硬件）+ 内部组件 + 连接线（通信协议）
Use Case Diagram（用例图） Scenarios (+1) 展示用户和系统的交互 火柴人（Actor）+ 椭圆（Use Case）+ 线

关系符号速记（类图 + 组件图）

依赖 (Dependency): - - - →   "我用到了你，但你不是我的一部分"
关联 (Association): ————→    "我知道你"
聚合 (Aggregation): ◇————→  "我包含你，但你可以独立存在"（整体-部分，弱关系）
组合 (Composition): ◆————→  "我包含你，我死了你也得死"  （整体-部分，强关系）
继承 (Inheritance): ————▷   "我是你的子类"
实现 (Realization): - - -▷  "我实现了你的接口"

15. AI 原生应用与企业架构

AI 原生应用

AI 原生应用不只是"在应用里加个 AI 功能"，而是整个应用围绕 AI 能力设计。核心特点：

  • 以模型为核心（不是以业务规则为核心）
  • 数据驱动 + 反馈循环（用户使用 → 数据回流 → 模型优化）
  • 不确定性管理（AI 输出不是 100% 确定的，需要处理这种情况）

企业架构（Enterprise Architecture）

企业架构的核心：通过结构化方法，对企业的业务、数据、应用和技术进行系统性规划和整合，实现战略目标并支持数字化转型。

四个架构域（从上到下）：

  1. 业务架构 (Business Architecture)：业务流程、组织结构、业务能力
  2. 数据架构 (Data Architecture)：数据资产、数据流、数据治理
  3. 应用架构 (Application Architecture)：应用系统、接口、集成
  4. 技术架构 (Technology Architecture)：基础设施、平台、技术标准

企业架构解决的核心问题：打破信息孤岛、消除重复建设、让 IT 和业务对齐。

16. 通用答题模板（背下来套公式）

问 "某 Pattern 是什么，举例说明" 时：

1. Context（什么情况下出现）：在需要...的场景下
2. Problem（解决什么问题）：存在...的问题
3. Solution（方案）：
   - Elements：有哪些元素，分别是什么角色
   - Relations：元素之间怎么交互
   - Constraints：有哪些限制
4. Weaknesses（弱点）：至少 2 个（单点故障、性能瓶颈、复杂度...）
5. Example（举例）：比如...系统用了这个 Pattern

问 "某质量属性怎么保证" 时：

1. 写一个质量属性场景（六要素）
2. 选择合适的 Tactic（比如 Availability → 心跳检测 + 冗余）
3. 选择合适 Pattern 来实现（比如用 Broker Pattern）
4. 说明 Trade-off（比如提高 Availability 会增加成本和复杂度）

问 "比较 A vs B" 时（如 SOA vs MSA、Layered vs Multi-Tier）：

1. 各自一句话定义
2. 相同点（至少 2 个）
3. 不同点（列表对比，至少 3 个维度）
4. 各自的适用场景（什么时候用 A，什么时候用 B）

问 "怎么设计某系统" 时（用 ADD 3.0 回答）：

Step 1：分析需求，识别 ASR（哪些质量属性最重要？）
Step 2：选定本轮驱动因素（比如优先解决 Performance）
Step 3：选要细化的元素（先整体架构）
Step 4：选设计概念（比如用微服务 + CQRS + 缓存策略）
Step 5：实例化元素、分配职责、定义接口
Step 6：画架构视图 + 记录设计决策和理由
Step 7：评估是否满足 ASR → 不满足则下一轮迭代（比如下一轮解决 Availability）

17. 最后一小时救命重点（按重要性排序）

优先级 内容 大概率考法 最少记住
⭐⭐⭐⭐⭐ 4+1 Views 填空/简答/给场景选 View 5 个 View 名字 + 回答什么问题 + 对应什么 Style
⭐⭐⭐⭐⭐ ASR + Utility Tree + 获取方法 简答/分析题 ASR 定义 + 四种获取方法 + Utility Tree 结构
⭐⭐⭐⭐⭐ ADD 3.0 步骤 简答/设计题 7 步的名称和顺序
⭐⭐⭐⭐⭐ Patterns 三类 Style 归类 选择题/归类 Module(Layered) / C&C(其余大部分) / Allocation(Map-Reduce, Multi-Tier)
⭐⭐⭐⭐ SOA vs Microservices 对比题 ESB vs API Gateway，共享数据库 vs 独立数据库
⭐⭐⭐⭐ QA Scenario 六要素 填空/应用 Source, Stimulus, Artifact, Environment, Response, Measure
⭐⭐⭐⭐ Patterns vs Tactics 简答 Pattern 大(Tactics 组合)，Tactic 小(零件)
⭐⭐⭐⭐ Views and Beyond 文档包 简答 View 内 6 要素 + Beyond 内容
⭐⭐⭐ Layered vs Multi-Tier 对比 Module vs Allocation，逻辑 vs 物理
⭐⭐⭐ 微服务六大特征 列举题 记前 4 个也行
⭐⭐⭐ UML 图识别 识图 6 种图 + 属于哪个 View
⭐⭐ 六大设计策略 匹配题 记名字 + 一句话
⭐⭐ DDD 核心概念 名词解释 Bounded Context, Ubiquitous Language, Entity vs Value Object
⭐⭐ 七类设计决策 列举/填空 至少记住 3-4 个

附：常见英文术语速查

English 中文 English 中文
Architecture 体系结构/架构 Stakeholder 涉众
Quality Attribute 质量属性 NFR 非功能性需求
ASR 架构攸关需求 Tactic 战术/策略
Concern 关注点 Trade-off 权衡
Coupling 耦合 Cohesion 内聚
Scalability 可扩展性 Availability 可用性
Modifiability 可修改性 Interoperability 互操作性
Reliability 可靠性 Portability 可移植性
Latency 延迟 Throughput 吞吐量
Redundancy 冗余 Fault Tolerance 容错
Circuit Breaker 熔断器 API Gateway API 网关
Bounded Context 限界上下文 Ubiquitous Language 统一语言
Aggregate Root 聚合根 Ubiquitous Language 统一语言
ESB 企业服务总线 Orchestration 编排
DevOps 开发运维一体化 CI/CD 持续集成/持续部署
posted @ 2026-06-23 20:55  陆舟LandBoat  阅读(20)  评论(0)    收藏  举报