软考专题 · 架构风格对比与选型（选择题 20 + 案例答题套路 + 模拟题 + 论文提纲）

发表于2026-05-10|更新于2026-05-10|软考

|浏览量:

架构风格是系统架构设计师综合知识里的第一大户——每年 4-6 道选择题，案例分析约两年一道选型大题，论文也是经典主题。这篇把高频选择题（带 ✅ 答案 + 解析）、案例选型答题套路、1 道完整模拟题、论文万能提纲打包在一起。内容来自开源仓库 PeterGuy326/senior-software-architect-review。回到软考导览页看完整专题清单。

一、必背：核心风格速查表

风格	核心概念	代表	优点	缺点	适用
管道-过滤器	数据流线性处理	UNIX / 编译器	可重用、并行	交互弱、性能一般	批处理、ETL
分层	逐层调用	OS / OSI	解耦、可替换	性能损失（穿透多层）	复杂业务系统
C/S	客户端-服务器	传统应用	管控集中	客户端升级难	企业内网
B/S	浏览器-服务器	Web 应用	零客户端	富交互弱	互联网
事件驱动	事件发布订阅	GUI / MQ	松耦合、可扩展	调试难、顺序难保	实时通知、异步
黑板 / 数据仓库	共享数据中心	AI 推理 / 编译器符号表	数据一致	瓶颈、单点	专家系统、语音识别
解释器 / 虚拟机	解释执行	JVM / 规则引擎	灵活	性能一般	脚本、DSL、SQL 引擎
MVC / MVP / MVVM	UI 层分离	Spring / Vue	职责清晰、多视图同步	中小场景略重	Web / GUI
微内核	核心 + 插件	Eclipse / VSCode	可扩展、可定制	插件管理复杂	IDE、平台型软件
P2P	节点对等、去中心化	BitTorrent / 区块链	抗单点、可扩展	一致性弱、带宽	文件分发、区块链
SOA	粗粒度服务 + ESB	企业集成	跨系统集成、互操作	治理复杂、ESB 单点	企业级集成
微服务	细粒度自治	Spring Cloud	独立部署、故障隔离	分布式复杂	互联网规模
REST	资源 + HTTP（无状态/统一接口/分层/可缓存）	OpenAPI	通用、可缓存	实时差	Web API

五大经典分类：数据流（批处理、管道-过滤器）｜调用-返回（主程序-子程序、OO、分层、C/S）｜独立构件（进程通信、事件驱动）｜虚拟机（解释器、规则系统）｜数据中心（数据库仓库、黑板）。

二、高频选择题（20 题，✅ 为正确选项）

1. 下列属于数据流风格的是：

✅ A. 管道-过滤器　B. 面向对象　C. 黑板　D. 解释器

数据流代表 = 批处理 + 管道-过滤器；编译器各阶段是典型应用。

2. 架构风格与经典案例对应错误的是：

A. 管道-过滤器 — UNIX Shell　B. 分层 — OSI 七层　C. C/S — Web 浏览器访问　✅ D. 黑板 — 电商订单处理

黑板用于语音识别、AI 推理；电商订单是事件驱动 / 微服务。

3. MVC 的核心价值是：

A. 提升性能　✅ B. 视图、模型、控制器职责分离，支持多视图同步　C. 减少代码量　D. 提升数据库吞吐

4. 下列关于黑板风格描述错误的是：

A. 适合解空间复杂、无固定算法的场景　B. 各知识源通过共享数据结构交互　C. 控制组件决定哪个知识源激活　✅ D. 典型用于事务型业务系统

5. 关于事件驱动架构（EDA）描述正确的是：

A. 紧耦合、同步调用　✅ B. 生产者与消费者解耦，事件异步传播　C. 不适合分布式系统　D. 只能用 Kafka 实现

6. 分层架构的最大问题是：

A. 无法复用　✅ B. 性能问题：请求需穿透多层　C. 层次无法隔离　D. 不支持并发

一般通过缓存 + 直连优化。

7. 下列属于仓库风格的有：

✅ A. 数据库系统、编译器符号表　B. 管道-过滤器　C. 客户端-服务器　D. 解释器

仓库风格以中央数据结构为核心，多组件共享访问。

8. 微内核架构的核心思想是：

A. 所有功能集中在一个核心　✅ B. 核心只保留必要功能，其他以插件方式扩展　C. 无需分层　D. 只用于操作系统

如 Eclipse、VSCode。

9. P2P 架构最大特点是：

A. 中心服务器控制　✅ B. 节点既是客户端又是服务器，去中心化　C. 单点故障　D. 带宽浪费

如 BitTorrent、区块链。

10. 下列风格中最适合编译器的是：

✅ A. 管道-过滤器　B. 黑板　C. MVC　D. 主从

词法→语法→语义→中间代码→优化→目标代码，顺序流动。

11. 解释器架构风格的主要场景：

A. 视频编码　✅ B. 脚本语言执行、规则引擎、虚拟机　C. 实时数据采集　D. 密集 IO

如 SQL 引擎、Drools、JVM。

12. 下列关于 SOA 描述错误的是：

A. 面向服务，服务通过协议通信　B. 服务复用和互操作是核心　C. ESB 是典型基础设施　✅ D. SOA 与微服务完全等价

SOA 重企业级集成、粗粒度、依赖 ESB；微服务轻量、细粒度、去中心化。

13. CORBA / RMI 属于哪种架构风格的典型代表：

A. 数据流　✅ B. 分布式对象 / RPC　C. 黑板　D. 管道

CORBA/RMI/Dubbo/gRPC 均属分布式对象或 RPC 风格。

14. 下列不属于调用返回风格的是：

A. 主程序/子程序　B. 面向对象　C. 分层　✅ D. 批处理

批处理属数据流风格。

15. 关于云原生架构核心特征不包括：

A. 容器化　B. 微服务　C. DevOps　✅ D. 大型单体

云原生四要素 = 容器 + 微服务 + DevOps + 持续交付。

16. 下列场景最适合微服务架构的是：

A. 小型单团队 MVP　✅ B. 业务领域清晰、团队规模较大、需独立部署发布　C. 数据强一致的金融清算　D. 计算密集型科学计算

小团队用单体反而更高效。

17. 下列关于 Serverless (FaaS) 描述错误的是：

A. 按调用次数计费　B. 无需管理服务器　C. 冷启动是已知性能问题　✅ D. 适合所有业务场景

不适合长连接、状态保持、极低延迟场景。

18. 面向对象架构风格的核心关注点是：

A. 数据流动　✅ B. 对象封装和消息传递　C. 层次调用　D. 中央数据共享

19. REST 风格的核心约束不包括：

A. 无状态　B. 统一接口　✅ C. 有状态会话　D. 分层系统

REST 六大约束 = Client-Server + Stateless + Cacheable + Uniform Interface + Layered + Code on Demand（可选）。

20. 下列架构风格对比正确的是：

A. 分层比管道-过滤器性能更好　✅ B. 事件驱动比同步调用耦合度更低　C. 微服务比单体一致性更强　D. SOA 比微服务粒度更细

EDA 异步事件解耦是低耦合典范；微服务粒度细于 SOA；微服务通常牺牲强一致换可用性。

原文 + 解析：exam-bank/10-architecture-styles.md

三、案例答题套路（选型大题，25 分）

问题 1：从场景选择风格 —— 四步法

识别关键需求（高并发？强交互？实时？批处理？强一致？）
列候选风格（2-3 个）
对比优缺点
给结论 + 理由（必须贴合题干的数字 / 场景）

标准答法示例：

“系统需处理每日 10 亿条日志的 ETL，关键需求为吞吐量和可扩展性。候选：管道-过滤器 vs 事件驱动。管道-过滤器线性流处理、易并行、适合批处理；事件驱动异步解耦但调试复杂。最终选管道-过滤器，因为日志处理是顺序数据流，可通过 Flume → Kafka → Flink 管道完成，吞吐可达百万 QPS。”

问题 2：填表对比

交互方式：同步 / 异步 / 事件
耦合度：紧 / 松
数据流：推 / 拉
扩展性：水平 / 垂直

问题 3：混合架构（多数真实系统都是混合的）

分层 + 微服务：每层内部是微服务
事件驱动 + 微服务：服务间通过 MQ 通信
MVC + REST：后端 MVC 输出 REST
SOA 主干 + 微服务边缘 + 事件驱动旁路：跨组织编排走 SOA，自身运营服务走微服务，高并发查询走 CQRS

万能高分句

“针对高并发和实时响应需求，选用事件驱动 + 发布订阅风格，基于 Kafka 实现服务间松耦合”
“管道-过滤器天然支持并行处理和构件复用，适合本系统的 ETL 批处理场景”
“分层将系统划为表现 / 业务 / 数据访问三层，各层通过接口解耦，任一层可独立替换”
“综合采用**微服务（业务层）+ 事件驱动（通信层）+ 分层（服务内部）**混合架构”
提”康威定律“对应”组织结构 → 架构选择”，体现方法论高度

常见陷阱

❌	✅
只选一个风格	现实系统多风格混合
没有对比	明确”为什么不选 X”
不结合题干数据	引用题干的 QPS / 用户量
优缺点平均着墨	突出最关键的 1-2 点

四、完整模拟案例题（25 分）

⚠️ 自主命题改编，建议严格 25 分钟限时作答。另一道”实时风控引擎管道-过滤器 vs 事件驱动”模拟题见 case-types/03-style-comparison.md。

【题干】 某省级政务服务平台”通办云”承接全省 17 地市 158 区县、16 委办厅局共 2300 项事项。年访问 8.2 亿次，日均申报 180 万件，复工首日峰值 QPS 1.6 万，可用性 99.95%，等保三级 + 政务云。团队 65 人（含 18 厅局对接专员，A 公司主导 + B/C 分包），周期 22 个月。现状：老系统是集中式 SOA（Oracle SOA Suite ESB + WebService），新厅局接入超 4 个月、ESB 日均 12 万 TPS 近瓶颈；厅局数据绝对不允许跨域共享、禁建中心化大库；”开办企业一件事”涉及市场监管→公安刻章→税务→银行开户→社保 5 个跨厅局环节，需事务编排 + 失败补偿；厅局系统异构严重（8 家 Java、3 家 .NET、2 家 Python、1 家信创 ARM+麒麟，协议 SOAP/REST/JSON-RPC/Thrift 混杂）；事项每季度约 40% 流程要重配；全链路调用日志保留 10 年。两个候选方案：A 升级 SOA（Apache ServiceMix + Camel），B 重构微服务（Spring Cloud Alibaba + Nacos + Sentinel + Seata）。

问 1（10 分）：从服务粒度、技术异构性、流程编排、数据一致性、团队组织、运维复杂度 6 个维度对比 SOA vs 微服务，给本场景每维度适配评分（1-5）及依据。
问 2（8 分）：给最终选型——纯 SOA / 纯微服务 / 混合架构，明确（1）整体风格定位（2）关键技术组件清单。
问 3（7 分）：针对”开办企业一件事”5 厅局编排，对比 ESB 集中编排 vs Saga 分布式编排，给推荐方案及落地序列图。

【参考答案要点】

问 1 6 维度评分（加权 SOA ≈ 4.2 > 微服务 ≈ 3.3）：

服务粒度：SOA 3 / 微服务 4（2300 事项需细粒度）
技术异构性：SOA 5 / 微服务 3（8 厅局协议异构 → ESB 适配天然支持，微服务需每厅局加 Sidecar 反增复杂度）
流程编排：SOA 5 / 微服务 3（5 厅局链长 → SOA 的”业务流程层”设计原意，Saga 跨厅局补偿权限难协调）
数据一致性：SOA 4 / 微服务 3（政务零容忍丢单 → 强一致更稳）
团队组织：SOA 3 / 微服务 5（65 人跨 3 公司 + 18 厅局自治 → 微服务去中心化对齐康威定律）
运维复杂度：SOA 5 / 微服务 2（政务运维能力有限 → 单 ESB 易监控）

问 2 混合架构 = SOA 主干 + 微服务边缘 + 事件驱动旁路：跨厅局编排（强协议适配 + 流程编排 + 强一致）走 SOA 主干；省级”通办云”自身运营服务（用户中心、消息中心、申报模板、智能客服）走微服务；高并发查询（事项查询、办件进度、电子证照核验）走事件驱动 CQRS 读写分离。关键组件：接入层 Spring Cloud Gateway + Nacos｜协议适配层 Apache ServiceMix + Camel + WSO2｜流程编排层 Camel BPEL / Activiti BPMN｜业务服务层 Spring Boot + Dubbo（信创 ARM 兼容）｜事件总线 RocketMQ｜治理层 Sentinel + SkyWalking + ELK（10 年日志）｜数据层各厅局保留原库（绝不集中）。

问 3 推荐 ESB 集中编排（BPMN 流程引擎）：① 政务跨厅局变更走文件审批，让 5 厅局同时改 Saga 接口几乎不可行；② 集中编排可由省政务局统一管控统一审计，符合”10 年日志”；③ 季度调整 40% 事项时只改 BPMN 图，无需厅局配合发版。落地：申请人 → 通办云网关 → ESB 流程编排引擎依次调用市场监管(企业登记)→公安(印章刻制)→税务(税务登记)→银行(开立基本户)→社保(参保登记)，任一步失败反向触发已成功步骤补偿，全链路 traceId 贯穿。

五、论文万能提纲（约 2500 字）

典型题目：论软件架构风格及其应用 / 论 ABSD（基于架构的软件开发）/ 论软件架构的多视图建模。

摘要（300 字，直接给"项目+角色+成果+量化"四要素）
1. 项目背景（350 字）— 业务定位、用户规模、团队、周期、关键质量属性
2. 核心理论（400 字）— 5 大经典风格分类 + 4+1 视图 + ABSD 6 步 + 风格 vs 模式
3. 实践论述（1500+ 字，分 4 节）⭐⭐⭐⭐⭐
   (1) 风格候选与选型决策（单体分层 vs SOA+ESB vs 微服务+事件驱动，3 选 1 + 决策点）
   (2) 微服务风格落地（DDD 限界上下文、gRPC/REST/MQ、Database Per Service）
   (3) 事件驱动风格落地（状态变更走事件总线、本地消息表 + TCC 补偿）
   (4) 风险与应对（分布式事务 → TCC+对账兜底 / 链路过长 → 多级缓存+SkyWalking / 促销过热 → 保留单体+Sentinel）
4. 总结与展望（250 字）— QPS 6.2 万、P99 178ms、可用性 99.995%、零 P0；教训：风格不是教条、保留合理单体、ATAM 闭环验证

4+1 视图：逻辑视图、开发视图、进程视图、物理视图 + 场景视图（论文里选 2-3 个重点展开，推荐逻辑 + 进程 + 物理，别每个都画）。ABSD 6 步：架构需求 → 架构设计 → 文档化 → 复审 → 实现 → 演化。

加分关键词：架构风格、4+1 视图、ABSD、ATAM、限界上下文、康威定律、DDD、TCC、本地消息表、Cache Aside、Database Per Service、CQRS、绞杀者模式；业界对标：阿里订单中台、美团交易中台、京东弹性云、Netflix Hystrix。

避坑：①罗列所有风格不分主次 → 只讲选中的 + 备选理由（3 选 1 的决策过程）；②4+1 视图每个都画 → 选 2-3 个重点深入；③不提评估方法 → 必写 ATAM 四类点识别，体现决策闭环；④风格名词堆砌无业务上下文 → 每种风格落到本项目具体模块；⑤摘要写成”本文将介绍” → 摘要直接给”项目+角色+成果+量化”。