软考高级系统架构设计师备考，写着方便自己看，如果有发现不对或少得的地方可以多多指正，谢谢各位兄弟。

一、软件架构核心基础

1. 软件架构的定义

架构是需求分析到软件设计的过渡产物，不是可运行的软件，包含「软件构件、构件外部可见属性、构件间交互关系」三部分。

核心作用：提前分析设计是否满足需求、在早期低成本调整方案、降低开发风险，同时也是项目干系人的沟通载体，直接决定系统的质量属性。

例子：做电商系统时，架构师不用写代码，先画架构图就能和产品确认「下单流程是否覆盖极速退款」，和开发对齐「微服务拆分粒度是否合理」，提前规避后期大规模改代码的风险。

2. 架构全生命周期6阶段

阶段	核心要点	实战示例
需求分析	问题空间→解空间转换，保障需求可追溯	用户提「双11下单不崩」的需求，架构师直接对应到「流量削峰+Redis缓存+服务熔断」的架构设计，每个决策都能回溯到原始需求
设计	核心是4+1视图模型（多视图体现「关注点分离」思想）	逻辑视图（面向用户，如电商的商品、下单、支付模块划分） 进程视图（面向运维，如下单服务的线程池配置、熔断规则） 开发视图（面向程序员，如Maven模块拆分、代码目录结构） 物理视图（面向部署，如订单服务部署在8核16G云服务器、Redis集群独立部署） 统一场景（串联所有视图，如「用户下单」场景能把逻辑层模块、进程层线程、开发层代码包、物理层服务器全部串起，验证架构合理性）
实现	SA设计向代码转换，支持基于架构的测试	用Spring Cloud框架落地微服务架构，按照架构定义的接口规范做单元测试
构件组装	用可复用构件拼接系统，需规避「架构失配」	直接引入支付宝SDK实现支付功能，无需自研；如果SDK要求Java8以上但现有系统是Java7，就会出现兼容性的架构失配
部署	基于架构的高层视图选择最优部署方案	按照物理视图规划，把前端部署在CDN，后端部署在多可用区的K8s集群，保障大促期间高可用
后开发	维护演化，包含动态架构、架构重建两个方向	大促期间动态调整服务实例数是「动态架构」；老系统没留架构文档，通过日志、代码反推架构就是「架构重建」

真题演练：多视图设计体现了（）思想，4+1模型中的“1”指（）。

A.关注点分离 B.面向对象 C.模型驱动 D.统一场景

答案：A、D

二、构件与主流构件标准

1. 构件核心特性

构件是面向架构的可复用功能单元，三大核心特征：①独立部署单元，具有原子性不可拆分；②可作为第三方组装单元；③无外部可见状态。

易混区分：模块是不带单独资源的原子构件（如Java里的工具类）；对象是有唯一标识、状态对外可见的实例（如User对象）。

例子：微信支付SDK就是一个典型构件，不用拆开单独部署某个类，直接引入项目就能调用支付接口，内部状态完全对外屏蔽。

2. 构件接口标准化

不是把接口定义为参数化操作集合，而是对输入输出的消息格式、模式、协议做标准化，保障跨系统、跨语言的互操作性。

例子：HTTP的Restful规范就是典型的接口标准化，不管后端用Java、Go还是Python开发，只要符合Restful的消息格式和协议，就能正常调用接口。

3. 三大主流构件标准

标准	所属厂商	典型应用场景
EJB	Sun（Java系）	Session Bean做用户登录会话管理，消息驱动Bean做订单消息异步处理
COM/DCOM/COM+	微软	Windows的ActiveX控件、Office插件都是COM/COM+构件
CORBA	OMG（跨平台）	银行核心系统用CORBA的ORB（软总线）实现不同语言开发的服务之间互操作

真题演练：以下关于构件特征的说法，不正确的是（）。

A.构件是独立的部署单元 B.构件可作为第三方的组装单元 C.构件没有外部的可见状态 D.构件作为部署单元是可拆分的

答案：D

三、ABSD基于架构的软件开发方法

ABSD是架构师考试的核心考点，案例和论文常考。

1. 核心逻辑

架构由「商业需求+质量需求+功能需求」三者共同驱动：用例描述功能需求，质量属性场景描述非功能需求（如性能、安全性），设计可以在需求还没完全收尾时启动，是自顶向下、递归迭代的开发方法。

例子：做政务办公系统时，不需要等所有审批流程的需求都确认完，先根据「公文流转要符合保密要求」（质量需求）、「支持多部门协同」（商业需求）、「起草公文」（功能需求）先搭好分层架构，再逐步细化。

2. ABSD三大基础

① 功能分解（使用内聚、耦合技术）；② 选择合适的架构风格实现质量和商业需求；③ 使用软件模板（复用成熟的结构设计）。

例子：做电商系统最顶层先拆分为「交易子系统、商品子系统、用户子系统」3个概念子系统，再配套通用的监控模板、日志模板，就是典型的ABSD分层拆解。

3. ABSD六大开发流程

架构需求→架构设计→架构文档化→架构复审→架构实现→架构演化

• 架构需求三大来源：系统质量目标、系统商业目标、开发人员商业目标

• 文档化核心产出：架构规格说明、测试架构需求的质量设计说明书

• 架构复审：必须邀请外部人员（用户代表、领域专家）参与，不通过则返回设计阶段重造

  例子：某团队做医疗系统时，复审发现「患者隐私数据加密」的质量需求没落地，立刻返回设计阶段增加数据脱敏模块。

真题演练：

1. ABSD方法的三个基础是对系统进行（）分解、采用合适架构风格实现质量与商业需求、采用软件模板设计结构。

   A.系统 B.模块 C.子系统 D.功能

   答案：D

2. 架构需求的三个来源不包括以下哪项？（）

   A.系统质量目标 B.系统商业目标 C.公司经济目标 D.开发人员商业目标

   答案：C

四、六大经典软件架构风格

架构风格是案例题的高频考点，重点区分不同风格的适用场景：

1. 数据流风格

• 批处理：步骤固定顺序执行，前一步完成才能开始后一步，数据整体传递。

  例子：银行夜间跑批，先把当天所有交易流水汇总成完整文件，再批量计算利息、生成账单，不能边汇总边计算。

• 管道-过滤器：过滤器（处理单元）通过管道传输数据，前一步的输出直接作为后一步的输入，支持流式处理。

  例子：传统编译器的「预处理→词法分析→语法分析→语义分析→生成目标码」流程；网络报文的拆包、校验、解析流程。

2. 调用/返回风格

• 主程序/子程序：单线程控制，通过过程调用交互，适合小型简单系统。

  例子：早期C语言写的成绩管理系统，main函数调用输入子程序、排序子程序、输出子程序。

• 面向对象：构件是对象，通过函数/过程调用交互。

  例子：Java写的图书管理系统，Book对象调用Library对象的借书方法。

• 层次型：分层结构，每层只和相邻层交互，修改最多影响两层，复用性强。

  例子：OSI七层网络模型、Web开发的三层架构（表现层→业务层→持久层）。

• C/S&B/S：C/S是胖客户端（如早期QQ、网游）；三层C/S是瘦客户端（如银行柜面系统，界面在客户端，业务逻辑在应用服务器，数据在数据库）；B/S是零客户端（如网页邮箱、在线文档，客户端用浏览器，服务端是Web服务器+数据库），缺点是动态交互性差、响应速度慢，不适合OLTP场景。

3. 以数据为中心的风格

• 仓库风格：中央数据存储+独立操作构件，所有构件围绕中央数据工作。

  例子：现代IDE的代码仓库，代码是中央数据，代码补全、语法检查、重构工具都是独立构件，围绕代码仓库运行。

• 黑板风格：由「知识源+黑板（全局数据库）+控制模块」组成，适合复杂非结构化问题。

  例子：语音识别系统，声学模型、语言模型是不同的知识源，黑板存储当前语音信号和识别中间结果，控制模块调度知识源逐步优化识别结果；还常用于编译器优化、信号处理系统。

4. 虚拟机风格

• 解释器：自定义规则解析执行，灵活但执行效率低。

  例子：Python解释器逐行解析执行Python代码；专家系统。

• 规则系统：由规则集+规则解释器+工作内存组成，适合决策类场景。

  例子：保险理赔审核系统，规则集是「重疾险理赔需要确诊证明+保单在有效期」，规则解释器根据用户提交的材料匹配规则，在工作内存中存储当前审核状态，最终输出审核结果。

5. 独立构件风格

• 进程通信：构件是独立进程，通过消息传递交互。

  例子：微服务的订单服务和库存服务，通过RPC调用或者消息队列传递数据。

• 事件系统（隐式调用）：构件触发事件，其他构件注册监听事件，构件间无显式调用，耦合极低。

  例子：IDE的快捷键功能，用户按下「保存」按钮触发保存事件，编辑器、自动备份模块、版本管理模块都监听了该事件，各自执行对应逻辑，互相无需感知对方存在。

真题演练：以下属于数据流风格的是（），属于虚拟机风格的是（），图中分层调用的属于（）风格。

A.面向对象 B.事件系统 C.规则系统 D.批处理

答案：D、C、层次型

五、软件架构复用

架构复用是降本增效的核心手段，也是论文题的高频素材。

1. 复用分类

• 机会复用：开发过程中遇到可复用资产就直接使用，比如写代码时发现之前项目的日志模块可以直接复用。

• 系统复用：开发前就规划好复用内容，比如公司提前统一所有内部系统的权限架构，新项目直接复用。

2. 复用三阶段

① 构造/获取可复用资产（比如沉淀通用权限构件）；② 管理可复用资产（搭建构件库，支持检索、版本管理）；③ 使用可复用资产（检索到构件后，根据当前需求配置、扩展后集成）。

真题演练：软件复用三个主要阶段是？（）

A.分析、管理、使用 B.构造/获取、管理、使用 C.构造、分析、使用 D.获取、管理、分析

答案：B

六、DSSA特定领域软件架构

DSSA是针对特定领域的标准化参考架构，目标是支撑同领域多个应用快速生成，是案例和论文的高频考点。

1. 领域分类

• 垂直域：特定系统族的通用架构，覆盖整个系统族的所有共性需求。

  例子：电商领域的通用架构，包含商品、订单、支付、物流等核心模块，淘宝、京东、拼多多等所有电商平台都可以基于这个架构开发。

• 水平域：多个系统族共用的子系统，仅覆盖部分通用功能。

  例子：电商、教育、医疗系统都需要收费模块，这个通用的收费模块就是水平域。

2. DSSA三大核心活动

① 领域分析：获取领域模型（领域共性需求），比如收集淘宝、京东、拼多多的共性需求，得到「商品搜索、购物车、秒杀」等通用需求；② 领域设计：产出DSSA（通用架构设计方案）；③ 领域实现：开发可复用构件，比如通用的商品SKU构件、支付对接构件。

3. DSSA四类参与角色

领域专家（提供行业经验）、领域分析人员（梳理领域模型）、领域设计人员（设计DSSA）、领域实现人员（开发可复用构件）。

真题演练：

1. 从功能覆盖范围看，定义特定系统族的通用架构的是（），定义多个系统族共用功能的是（）。

   A.垂直域 B.水平域 C.功能域 D.属性域

   答案：A、B

2. DSSA中，主要目标是获得领域模型的活动是（）。

   A.领域实现 B.领域设计 C.领域建模 D.领域分析

   答案：D