本页脑图：架构基础怎么串
风格
- 分层
- 事件驱动
- 管道过滤器
- 仓库/黑板
方法
- ABSD
- 需设文审实演
- 视角与视图
- 用例与质量场景
复用
- DSSA
- 领域分析
- 参考架构
- 组件复用
演化
- 单体
- 缓存/队列
- 微服务
- 云原生
经典架构风格
必考选择题论文理论架构风格是系统组织方式的“套路”。选择题考定义和适用场景，案例题考为什么选这个风格，论文考你能否把风格和业务痛点绑定。
| 风格 | 核心思想 | 优势 | 劣势 | 适用场景 | 考试记忆 |
|---|---|---|---|---|---|
| 分层 | 表示层、业务层、数据层等按职责分层。 | 职责清晰、便于维护、便于替换。 | 跨层调用会破坏结构，层层调用可能有性能损耗。 | 企业管理系统、传统 Web 应用。 | 像公司部门，各层只和相邻层协作。 |
| 管道-过滤器 | 数据依次经过多个过滤器处理。 | 组件复用好，处理链清晰。 | 不适合强交互，数据格式转换有成本。 | 编译器、日志清洗、ETL。 | 像流水线，每站只做一件事。 |
| 仓库/黑板 | 多个组件共享一个中心数据仓库。 | 数据共享方便，适合复杂协作。 | 仓库可能成为瓶颈，组件围绕数据耦合。 | 专家系统、数据平台、AI 推理。 | 像会议白板，所有人围着同一份信息。 |
| 事件驱动 | 事件发布者和消费者异步协作。 | 解耦、削峰、扩展性好。 | 调试复杂，要处理消息丢失、重复、乱序。 | 订单、审计、通知、日志处理。 | 看到“异步、解耦、事件”就想到它。 |
| 解释器 | 定义一套语言或规则，由解释器执行。 | 灵活，用户可配置规则。 | 性能较低，规则复杂后难维护。 | 规则引擎、脚本、游戏地图/行为定义。 | 用户自己定义规则或脚本，优先解释器。 |
| C/S 与 B/S | 客户端/服务器或浏览器/服务器。 | C/S 体验强，B/S 部署维护方便。 | C/S 升级麻烦，B/S 依赖网络和浏览器。 | 办公系统、管理平台、跨区域访问。 | 装客户端是 C/S，打开浏览器是 B/S。 |
考试细化：架构风格怎么判断
| 题干关键词 | 优先想到 | 为什么 | 常见干扰项 |
|---|---|---|---|
| 数据依次处理、每步独立、可组合 | 管道-过滤器 | 处理流程像流水线，每个过滤器只做一种转换。 | 分层也有层次，但分层强调职责依赖，不强调数据流。 |
| 大量组件共享同一份数据、中心数据结构 | 仓库/黑板 | 核心是共享数据中心，组件围绕它读写。 | 数据库不等于仓库风格，必须看是否是架构协作中心。 |
| 异步通知、解耦、削峰、发布订阅 | 事件驱动 | 生产者不直接调用消费者，通过事件或消息协作。 | 消息队列是实现技术，事件驱动是架构风格。 |
| 表现、业务、数据职责清晰，上层依赖下层 | 分层架构 | 按抽象层次组织系统，提升可维护性。 | 微服务也可内部使用分层，二者不是互斥。 |
| 规则可配置、脚本、语言解释执行 | 解释器风格 | 核心是定义语法/规则并解释执行。 | 策略模式是局部设计模式，不是完整架构风格。 |
论文细化：风格选型必须写取舍
架构风格题最怕“我采用了某风格”一句带过。架构师论文要体现决策过程：候选方案、为什么不用、为什么选、带来什么质量属性收益、有什么副作用。
风格选型句式：针对【业务痛点】，我比较了【方案A】和【方案B】。方案A优势是【优势】，但在【约束】下存在【问题】；最终选择【方案B】，因为它能提升【质量属性】，同时通过【补偿措施】控制【副作用】。
ABSD：基于架构的软件开发
ABSD 强调由商业需求、质量需求和功能需求共同驱动架构设计。它不是先写代码再补架构，而是先识别架构驱动力，再设计、评审、实现和演化。
六个阶段
- 需求：识别功能需求、质量属性和约束。
- 设计：选择架构风格，确定构件和连接件。
- 文档化：用视图、接口、约束记录架构。
- 复审：通过评审发现风险和权衡点。
- 实现：按架构约束开发构件。
- 演化：随着业务和技术变化调整架构。
怎么记
需、设、文、审、实、演
像盖楼：先明确用途和约束，再出结构图，再形成图纸，再找专家审，再施工，最后维护改造。
ABSD 各阶段输入/输出
| 阶段 | 输入 | 主要活动 | 输出 | 常考点 |
|---|---|---|---|---|
| 架构需求 | 业务目标、质量目标、功能需求、约束 | 需求获取、标识构件、识别质量属性场景 | 架构需求说明、初始构件 | 用例描述功能需求，质量场景描述质量需求。 |
| 架构设计 | 架构需求、候选风格、约束 | 选择风格、映射构件、定义连接件、分析相互作用 | 候选架构、接口、约束 | 设计构件关系，不是编码实现构件。 |
| 架构文档化 | 架构设计结果 | 用视图记录结构、行为、部署和约束 | 架构规格说明、质量属性说明 | 架构用视角与视图描述。 |
| 架构复审 | 架构文档、质量场景 | 评审风险、评估质量属性、发现缺陷 | 评审意见、风险清单 | 可与 ATAM 结合考。 |
| 架构实现 | 通过复审的架构 | 构件实现、组装、系统测试 | 可运行系统 | 实现阶段才真正写代码。 |
| 架构演化 | 变更需求、运行反馈 | 影响分析、更新构件和交互、回归验证 | 演化后的架构 | 演化要控制兼容性和风险。 |
架构设计活动：设计构件，但不实现构件
错题高频软件架构设计包括提出架构模型、产生架构设计、进行设计评审等活动，是迭代过程。这里很爱考“哪些属于架构设计，哪些已经进入实现”。
| 活动 | 是否属于架构设计 | 说明 |
|---|---|---|
| 选择合适架构风格 | 属于 | 早期需要根据质量属性和业务约束选择风格。 |
| 将已识别构件映射到架构并分析关系 | 属于 | 明确构件、连接件、依赖关系和接口。 |
| 设计构件 | 属于 | 架构设计会规定构件职责、接口、约束。 |
| 实现构件 | 不属于 | 实现是详细设计/编码阶段，不是架构设计活动本身。 |
| 邀请独立人员评审 | 属于 | 架构评审需要相对独立的视角发现风险。 |
相关错题归档
| 错题 | 归属知识点 | 记忆点 |
|---|---|---|
| 题 5 架构设计活动 | 架构设计活动边界 | 架构设计构件，不实现构件。 |
| 题 7 ABSD 描述方式 | ABSD、视角与视图 | 架构用视角与视图，需求用用例和质量场景。 |
视图与视角
架构不是一张图能讲清的。不同干系人关心不同问题，所以需要从多个视图描述同一系统。
逻辑视图
面向最终用户和分析人员，关注系统功能和核心抽象。
开发视图
面向程序员，关注模块划分、包结构、代码组织。
进程视图
面向性能和并发，关注线程、进程、通信和同步。
物理/部署视图
面向运维和系统工程师，关注节点、网络、部署拓扑。
场景视图
用关键用例串起其他视图，验证架构能否满足业务。
记忆
用户看功能，程序员看代码，运维看部署，性能人员看进程。
DSSA：特定领域软件架构
DSSA 是为某个特定应用领域提供的标准化、可复用架构。它适合论文，因为它天然可以写“领域分析、架构设计、组件复用、验证优化”。
三步理解
- 领域分析：找共性需求、变化点、领域对象。
- 领域设计：形成参考架构、标准组件、接口规范。
- 领域实现：把参考架构落到具体项目并复用组件。
用户认证系统例子
领域对象包括用户、角色、权限、资源、Token、审计事件。参考架构可拆成认证服务、权限服务、Token 服务、审计服务，并统一接口、日志格式和安全策略。
DSSA 深度记忆：三类角色与三类产物
角色
领域专家提供业务共性和变化点；领域分析师抽象领域模型；架构师/开发者把参考架构实现为可复用组件。
产物
领域模型描述核心概念；参考架构描述标准结构；组件库/框架支撑具体应用快速构建。
DSSA 论文句式：通过领域分析识别共性与变化点，形成参考架构和可复用组件，在具体项目中通过配置和扩展完成实例化。
架构演化：从能用到能扛
架构演化题要按时间线讲：每一步都是为了解决新的业务压力或质量属性问题。
- 单体阶段：开发快，适合早期业务，但模块耦合、部署慢。
- 分层优化：拆出表示层、业务层、数据层，提高可维护性。
- 缓存和读写分离：解决热点读和数据库压力。
- 消息队列：削峰填谷，异步处理审计、通知、积分等非主链路。
- 微服务拆分：按业务域独立部署和扩展，提高迭代效率。
- 云原生：用容器、K8s、CI/CD、可观测性提升交付和恢复能力。
架构演化论文：原架构问题 → 演化目标 → 分阶段改造 → 风险控制 → 量化效果 → 后续优化。