系统架构设计师 2024 年上半年真题与答案解析

2024 年 5 月 25 日这一场有个值得记一笔的背景：以前系统架构设计师一年只有下半年一次，这一年官方在 3 月宣布上半年也开考（我在搜索结果摘要里看到一位考生的心得写道“202405 是架构师改版以来的第二次考试，往年只能每年 11 月考试，今年官方 3 月突然宣布 5 月也可以直接考”，这句我没有打开原文核对，仅供参考）。于是这场成了架构师“上半年开考”的第一战，也是机考时代的第二战。监考很严，据考生说草稿纸不许带出考场，所以网上所有“真题”都是回忆版。这篇我做的事和前两篇一样：只用我真实读到的页面，有答案的给答案并写自己的解析，来源之间打架的标出来，找不到的老实写“待核实”。

版权与使用说明：真题版权归考试主办方所有。本文对每道题只做“题意概括 + 答案要点”，附我自己写的解析，不整页搬运原卷。回忆版的题干、选项和答案都可能有误（本文会指出我发现的几处），请以官方发布及正版真题为准。

一、场次概况

二、综合知识：回忆版答案速对与逐题解析

这一场的综合知识，我读到了三个相互有重叠的回忆版：CSDN 的 YooYee233（“完整版”，含选项与答案，共 60 多个条目）、rzleilei（“复原程度 90%”，条目与上一篇几乎相同，开头说明是群友提供加记忆整理）、Nanki_（40 条考点简记，带一部分自己的判断）。三者的题干与答案在大部分条目上互相一致，这是本场比 2023 下半年更可信的地方。但要注意：YooYee 与 rzleilei 的条目几乎是逐字相同的（应是转载或同源），真正独立的交叉验证主要来自 Nanki_（约 35 条与前者重合，答案一致）。另外我打开过一页标题带“2024 上半年综合知识真题（解析版）”的 CSDN 专栏文章，它只公开了 1–20 题的字母答案表（其余需付费），而且题号顺序与上面几个回忆版无法对应（机考题目顺序会打乱），所以我没有采用这张表。

2.1 答案速对表

第一部分（回忆版只记了要点，没有选项字母）：

第二部分（回忆版带选项，有选项字母；选项顺序以回忆版为准，不保证与考场一致）：

统计（我按上面两张表人工数的）：第一部分 23 个条目（其中 A17 无法还原，A10、A14 存在冲突，A22 有笔误），第二部分 40 个有答案的条目，加上有两个空的题目按题号展开，合计约 63 个小题有答案要点，约 12 题没有任何信息（含英语题）。此外 Nanki_ 还记了几条上面没出现的：第 17 条“UML：构件图不属于需求分析常用的图”、第 21 条“视角描述不同的架构”、第 26 条“不正确选项：架构设计一定要基于某个特定架构风格”、第 28 条“事件驱动不正确：一个事件的发生不会影响另一个事件”、第 15 条“线性规划”、第 24、25 条“管道”“应用服务器，客户机在表示层”等，我放在解析里一并说明，这些只有一个来源，标注为单源。

2.2 逐题解析（按知识块折叠）

2.3 综合知识小结

• 本场综合知识的重点很集中：构件组装（两题）、质量属性（多题）、架构评估、净室与测试、数据库与 OS。
• 出现了 4 处冲突或笔误：专利保护范围（A10）、OSI 无安全服务的层（A14）、灰度/灰盒（A22）、SOAL/SOAP（B12）。
• 出题有重复模式：同一个知识点常常拆成两个空出两题（安全性、可用性与互操作性、构件组装、质量属性场景各一组）。

三、案例分析：五题还原

案例这一科，我读到了三个回忆整理：YooYee233（案例一、二、三、五，以及论文）、m0_61635017（案例一至五，带较详细的答案，并注明“此处有争议”“仅供参考”“来源于网络”）、rzleilei（案例一、三、四、五的题干要点）。另外环球网校的“考点总结”页给出了五题的分类。五题的考点在各来源间基本一致，只有第 5 题“网络通信设计”与“系统设计/存储”的叫法不同。

注：环球网校页面把五题分类为“质量属性效用树与微服务架构 / 软件系统建模与 UML 交互图 / Web 系统架构设计 / 数据存储设计、分布式锁与 Redis 命令 / 网络通信设计”，与上面回忆顺序不完全对应（它把“Web 系统”和“网络通信设计”单列）。我判断这是对同五题的不同归类，题序以回忆者为准，但无法完全核实，列入冲突项。

3.1 案例 1（必答，25 分）：系统架构评估

问题 1（7 分）：微服务架构及其与单体的对比、优缺点

题意：简述微服务架构，对比单体架构与微服务架构，并说明微服务的优缺点。

参考答案要点（两份回忆的答案一致，下面用我自己的话整理）：

优点：独立部署与扩展、技术多样性、故障隔离、小团队自治、代码更聚焦。缺点：分布式系统复杂度（服务发现、治理、调用链）、数据一致性（分布式事务）、网络通信开销与延迟、部署与测试复杂、运维与监控成本高。答题时每条要写“现象 + 原因”，比如“数据一致性难：各服务独立库，跨服务事务要靠 Saga/最终一致”。

问题 2（6 分）：质量效用树填空

题目给了一棵质量效用树，挖了 6 个空。回忆者说“忘了挖了哪几个空”，只记得涉及安全性、可用性、功能性、可修改性几个质量属性。我不具体填，只讲做法：效用树从“效用”出发，分解到一级质量属性（性能、可用性、安全性、可修改性、易用性等），再细分为属性分类，叶子是具体的质量属性场景；做题时根据叶子场景的内容反推它属于哪个质量属性：比如“断电后 10 秒内重启”→可用性；“用户登录后数据加密传输”→安全性；“新增支付渠道只需修改一个模块”→可修改性。注意：来源里出现“功能性”作为一类，标准质量属性清单里功能性并不总是放在质量属性里，所以具体空位答案待核实。

问题 3（12 分）：用六要素描述两条可用性场景

题目给出一系列质量需求，其中 e)“可连续运行时间不少于 240h，断电或故障后 10s 内应重启”，h)“网络失效后，10s 内应发起重新连接”，要求用质量属性场景六要素描述。

参考答案（来源 YooYee233、m0_61635017 一致，下面是我改写并补充）：

两个来源对制品的写法略有不同（一个写“系统”，一个细化到模块），评分多半看六要素是否齐全、度量是否具体，我按更细的写法给出。回链：质量属性与 ATAM 见《综合知识精讲（上）》。

3.2 案例 2：UML（序列图与交互图）

回忆的小问：(1) 序列图的三种消息；(2) 序列图补全填空（图未还原，我不猜）；(3) 分析设计过程中两种交互图的选取原则；(4) 序列图中表示条件分支的组合片段有哪些。

(1) 三种消息：同步消息、异步消息、返回消息（两源一致）。同步消息发送方要等待返回；异步消息发送后继续执行；返回消息表示被调用方返回结果。此外还有创建消息、销毁消息、自调用等，答题以“同步/异步/返回”三种为准。

(3) 两种交互图的选取原则：交互图有两种，序列图（顺序图）与通信图（协作图）。回忆里的答案是“序列图用于分析阶段、协作图用于设计阶段”。我认为这个说法不够准确，更稳妥的答法是：强调消息的时间顺序，选序列图；强调参与交互的对象及其链接关系（结构、组织），选通信图。两者语义等价、可相互转换。这里的来源答案与我的答法有出入，请以你的教材为准。

(4) 条件分支的组合片段：答案（两源一致）：alt（选择，多分支互斥）、opt（可选，单分支）、loop（循环）、break（中断）、par（并行）。另一个来源还补充了 critical（临界区）、neg（否定，不应发生）、ref（引用）。严格来说，“表示条件分支”的主要是 alt 与 opt，loop、par 等是别的用途，评分时多写不扣分的可能性较大，但题目意图偏 alt/opt。

3.3 案例 3：分布式锁

问题 1（9 分）：基于 MySQL 实现分布式锁的缺点

来源答案（m0_61635017 注明“答对 5 项即可满分”，这是博主的说法，未必是官方评分规则）：性能瓶颈（高并发下大量加锁解锁请求压垮数据库）、单点故障、锁粒度问题、数据一致性问题（主从延迟等）、扩展性差、容错性差（不如 ZooKeeper 或 Redis 方案）。我补充实现层面的缺点：需要自己实现超时与死锁处理（行锁持有者宕机要靠定时清理）、不可重入需额外字段支持、不支持阻塞等待需轮询。

问题 2（10 分）：举一个 Redis 分布式锁死锁的场景

这一问两个来源给出了完全不同的场景：YooYee233 写的是“两个服务各持一把锁又互相等待”的循环等待；m0_61635017 写的是“客户端持锁时间过长、另一个客户端一直等待，交替获取造成死锁”。后者的描述其实不是严格意义上的死锁。我自己的答案（也是 Redis 分布式锁最典型的死锁）：

• 场景一：锁没有设置过期时间，客户端在持锁期间宕机或崩溃，锁永远不会被释放，其他客户端永远拿不到锁。对策：加锁时用 SET key value NX PX 30000 一条命令同时设值和过期时间；用唯一 value 标识持有者，释放时用 Lua 脚本校验 value 再删除，避免误删别人的锁。
• 场景二：多把锁的循环等待，服务 A 持 K1 等 K2，服务 B 持 K2 等 K1。对策：所有服务按统一顺序加多把锁、设置获取锁的超时并回退。
• 附带：锁过期但任务没做完会导致两个客户端同时持锁（不是死锁而是锁失效），对策是看门狗续期（Redisson 的 watchdog）。

评分多半看“场景描述清楚 + 给出对策”，两种写法大概都能得分，我建议用场景一。

问题 3（6 分）：基于 ZSet 的 Redis 命令（秒杀场景）

来源答案：存入秒杀分数：ZADD；获取某分数范围的成员：ZRANGE（严格说按分数范围取用 ZRANGEBYSCORE，Redis 6.2 之后 ZRANGE 加 BYSCORE 选项也可以）；获取成员分数：ZSCORE。常用命令速记：

m0_61635017 吐槽：“关于 NoSQL 平时都关注理论层面，没想到考实践层面的命令”。这也是这场案例题的风格：从概念题向“会用命令”靠拢。另一小问（rzleilei 记）还问了“除了数据库锁和 Redis 锁，还有哪些分布式锁的类型”，答案方向是 ZooKeeper（临时顺序节点 + Watch）、etcd（租约 + 事务）等，属于我的知识补充，不是来源答案。

3.4 案例 4：嵌入式（车载通信与规控）

这题只有 m0_61635017 与 rzleilei 提到，rzleilei 只写了“第四题嵌入式系统：略”。下面用 m0_61635017 的回忆，答案标注“来源于网络”，我自己补了知识讲解。

问题 1（9 分）：简要分析 SOME/IP 协议及特点

SOME/IP（Scalable service-Oriented MiddlewarE over IP）是 AUTOSAR 定义的面向服务的车载以太网中间件协议，位于应用层，基于 TCP/IP，支持 UDP 与 TCP。特点：面向服务架构 SOA（ECU 以服务提供者/消费者互动）、支持远程过程调用 RPC、服务发现（SOME/IP-SD）、事件通知与字段（field）、高伸缩性与灵活性，适合高带宽场景。

问题 2（6 分）：把 DDS 与 SOME/IP 填进框图

来源的分析：DDS 一般用于框架/模块内部之间通信，SOME/IP 用于与外部设备之间通信，图没有还原，我不做逐空解答。DDS（Data Distribution Service）是 OMG 的发布—订阅数据分发标准，去中心化、强调实时与丰富的 QoS 策略，ROS 2 底层默认用它。可记“DDS 重数据流与 QoS，SOME/IP 重服务与 RPC”。

问题 3（10 分）：规控（AP 模块）的流程框图

来源的分析：地图 → 定位 → 感知 → 预测（对环境中其他目标）→ 规划路径（考虑其他参与者）→ 控制决策 → 控制信息传递给交互界面/执行机构。这是自动驾驶软件常见的流水线：感知 → 预测 → 规划 → 控制。图没有还原，具体框图待核实。

3.5 案例 5：系统设计（存储架构、MongoDB、冷热数据）

问题 1（11 分）：系统架构图填空，7 个空

选项给出：接口层、处理层、数据层、MySQL、HDFS、HBase、ES 等。博主 m0_61635017 特别注明“此处有争议，答案仅供参考，以官方为准”：争议点是瓦片地图用 HDFS 还是 HBase 存储。他指出这题的原型来自华中科技大学的一篇硕士论文，标准答案可能按论文来；并解释：栅格瓦片（图片，大文件顺序读）适合 HDFS；矢量瓦片（JSON/MVT，小文件随机读写）适合 HBase。这是个很有价值的判断依据，我完全认同这种分析方法，但7 个空的正确答案我无法确认，待核实。可以背的选型逻辑：

问题 2（10 分）：MongoDB 如何存储非结构化数据、优点

来源答案（两源一致，我整理）：MongoDB 是文档型 NoSQL，以 BSON（二进制 JSON，支持日期、ObjectId 等更多类型）存储文档；无固定模式，同一集合里的文档可以有不同字段；字段可动态增删；支持对任意字段（含嵌套字段）建索引。优点：模型灵活、嵌套文档减少联表、易于扩展与演变、支持分片水平扩展与副本集高可用、聚合框架分析能力强。注意题面写的“矢量化存储”不是 MongoDB 的官方术语，来源也承认，按“处理复杂数据结构的能力”来答即可。

问题 3（4 分）：热、温、冷数据分级存储的原因

来源答案（任意 4 点，博主称）：资源优化、成本效率、性能提升、数据保护、扩展灵活。我的总结：按访问频率分层——热数据放内存/SSD 保证低延迟，温数据放普通磁盘，冷数据放对象存储/归档介质降成本；同时配合生命周期策略自动迁移。一句话：“把钱花在刀刃上，让快的存储只放常用的数据”。

回链：缓存、数据库与存储选型在《综合知识精讲（下）》；案例答题模板见《案例分析：题型拆解与答题模板》。

四、论文：四道题的考查方向与写作方案

四个题目方向（环球网校页面、YooYee233 各给出了完整的三问要求）：

一处冲突：rzleilei 把第 3 题记为“领域驱动开发”，其余来源（YooYee233、环球网校）均为“模型驱动架构”，且 YooYee 列出了完整三问；我采信多数来源，第 1 题为模型驱动架构，rzleilei 的“领域驱动开发”应是记混了（DDD 与 MDA 只差一个字母）。我没有找到官方标准范文，下面的写作方案是我自己整理的。通用骨架与自查清单见《论文写作：套路、模板与素材库》。

4.1 论模型驱动架构（MDA）设计方法及其应用

概念：MDA 是 OMG 提出的软件开发方法，核心思想是把“业务/功能规约”与“平台实现”分离，以模型为主要制品，通过模型转换生成代码。三类模型：CIM（计算无关模型，业务需求视角）、PIM（平台无关模型，系统功能但不含平台细节）、PSM（平台相关模型，绑定具体技术如 Java EE、.NET）；再由 PSM 生成代码。核心是模型转换（CIM→PIM→PSM→代码），依托 UML、MOF、OCL、XMI 等标准。

全过程：业务建模（CIM）→ 构建 PIM → 选择平台并制定映射规则 → PIM 到 PSM 转换 → PSM 到代码生成 → 手写补充与测试 → 模型与代码同步维护。特点：提高抽象层次、平台可移植、提高一致性与文档同步、减少重复劳动；局限：工具链成熟度、模型转换规则复杂、逆向同步难、对团队建模能力要求高。

提纲：摘要 → MDA 概述（CIM/PIM/PSM 与转换）→ 项目背景与我的职责 → 项目中的建模与转换实践（举例：用 UML 描述订单域 PIM，转换到 Spring Boot PSM 生成骨架代码）→ 难点（模型转换规则维护、与手写代码合并、团队接受度）与对策 → 效果（研发效率、缺陷率）→ 总结。

4.2 论云上自动化运维及其应用

概念：云上自动化运维（CloudOps/AIOps 方向）是把部署、监控、扩缩容、故障自愈等运维动作脚本化、流程化、平台化，依托云厂商 API 与 IaC（基础设施即代码）。衡量指标（第二问）可答：可用性/SLA、MTTR（平均恢复时间）、MTTD（平均检测时间）、变更成功率与变更失败率、部署频率与前置时间、自动化率（自动化处理的事件占比）、告警准确率与噪声比、资源利用率与成本、容量预测准确率。

实现手段：IaC（Terraform/Ansible）统一环境；CI/CD 流水线；可观测性（指标、日志、链路）+ 告警分级；弹性伸缩与自愈（健康检查、自动重启、跨可用区切换）；混沌演练；ChatOps 与工单联动；成本治理（标签、预算、闲置回收）。提纲：摘要 → 云上自动化运维概述与指标 → 项目背景 → 总体架构（采集、分析、决策、执行闭环）→ 落地过程与关键技术 → 难点（告警风暴、自动化误操作风险、多云差异）与对策（审批与灰度、熔断开关）→ 效果（MTTR、自动化率）→ 总结。

4.3 论大数据 Lambda 架构

这题与 2023 下半年案例第 1 题直接重合，三层的用途与特点务必背熟：

详细的对比与 Kappa 架构区别见本专栏 2023 下半年篇第三节（《2023 年下半年真题》）。写作要点：项目背景（日志分析、用户画像、风控）→ 三层技术选型（Kafka + Flink/Spark Streaming + HDFS/Hive + HBase/ClickHouse）→ 数据一致性与去重（以批视图为准修正实时视图）→ 难点：两套逻辑重复开发（可引入统一计算引擎或抽象层）、数据延迟对齐 → 效果 → 总结（可提 Kappa 作为演进方向）。

4.4 论单元测试及运用

静态测试：不运行被测程序，包括代码走查、评审、静态分析（规范检查、复杂度、潜在缺陷扫描）。动态测试：运行程序，包括黑盒（等价类、边界值、因果图、判定表）与白盒（逻辑覆盖）。白盒覆盖标准由弱到强：语句覆盖 < 判定（分支）覆盖 < 条件覆盖 < 判定/条件覆盖 < 条件组合覆盖 < 路径覆盖；实际项目常以语句覆盖 + 分支覆盖为基线（如 80%），关键模块提高到 MC/DC。回归测试：每次变更后重测受影响范围，组织方式：自动化用例库 + CI 触发 + 基于变更的选择与优先级；冒烟用例做守门。

提纲：摘要 → 单元测试概念与价值 → 项目背景 → 静/动态测试实践（工具：JUnit、Mockito、SonarQube、JaCoCo）→ 覆盖标准的确定（按模块风险分级）→ 回归测试组织（CI 流水线、用例分层）→ 问题（难以 Mock 依赖、遗留代码不可测）与对策 → 效果（缺陷逃逸率、覆盖率）→ 总结。

4.5 摘要示例（自写，仅供练手）

2023 年 8 月，我参与了某电商企业“实时经营分析平台”的建设，担任系统架构师，负责整体架构与技术选型。平台需要对秒级变化的交易数据做实时监控，同时保留全量历史数据做精确分析。本文结合该项目，论述了基于 Lambda 架构的大数据处理实践：批处理层基于 HDFS 与 Spark 对全量数据做预计算，加速层以 Kafka 加 Flink 处理增量数据，服务层合并两类视图并对外提供查询；针对两套逻辑重复开发与数据一致性的问题，采用统一指标口径与以批视图修正实时视图的机制。系统上线后，核心指标刷新延迟控制在秒级，历史查询结果与账务数据一致，验证了方案的有效性。

数字我故意没写死，请替换为真实项目的量化结果。论文最忌编造与项目不符的数据。

五、本场考点热度总结

复习建议：这场案例让我感受最深的是“实践化”——Redis 命令、存储选型、车载协议，都在问你“会不会用、能不能说出理由”。背概念不够，最好自己敲一遍命令、画一遍架构图。综合知识则要把构件、质量属性、评估这三块整理成表格反复过。

一句话备忘：2024 上半年这场：综合知识抓构件组装、质量属性、ATAM/SAAM、净室与测试；案例盯六要素场景、分布式锁与 Redis、存储选型的理由；论文备“模型驱动 / 云运维 / Lambda / 单元测试”；来源打架的地方（专利权利要求书、OSI 会话层、MDA 对 DDD）我都标了，不替你编。

六、答案冲突与待核实项

• 专利保护范围（A10）：YooYee/rzleilei 记“权利说明书”，Nanki_ 记“权利要求说明书”；依《专利法》应为权利要求书，以 Nanki_ 为准。
• OSI 不提供安全服务的层（A14）：两源“会话层”，一源“物理层”；我倾向会话层，原题以选项为准。
• 灰度/灰盒（A22）：来源笔误，应为灰盒测试。
• 净室（A20、B39）：两个条目一致，“不需要传统（模块）测试”被命题人视为错误说法。
• 案例 3 第 2 问：Redis 死锁场景两源写法完全不同，我给出了自己的标准答案。
• 案例 2 第 3 问：来源答案“序列图分析、协作图设计”与我认为的选取原则有出入。
• 案例 5 第 1 问：博主自己标注“有争议”，7 个空答案待核实。
• 论文第 1 题：MDA（多数来源）vs 领域驱动开发（rzleilei），采信多数。
• 案例五题的归类：环球网校与回忆者的叫法、顺序不完全相同，无法完全核实。
• 未采用的来源：一篇只公开 1–20 题字母答案、题序与其他回忆版无法对应的 CSDN 文章，以及仅含下载链接的环球网校/希赛网综合知识页面，均未用于答案。
• A17、B41 及其余约 12 题：没有信息，答案待核实；所有答案均为回忆版，不是官方答案。

参考资料

• CSDN YooYee233：2024 年 5 月份系统架构师考试真题完整版——综合知识带选项和答案、案例一/二/三/五要点、论文四题三问要求。
• CSDN rzleilei：2024 年上半年系统架构设计师真题-复原程度 90%——综合知识要点表、案例题干要点、论文题目（第 1 题为“领域驱动开发”，与其他来源冲突）。
• CSDN Nanki_：2024 年 5 月系统架构设计师综合知识真题——40 条考点简记，用于交叉核对（发现专利、OSI 的分歧）。
• CSDN m0_61635017：2024 年 5 月份架构师考试案例真题完整版——案例一至五的答案与解析，含案例四嵌入式、案例五存储争议说明。
• 环球网校：2024 年 5 月 25 日架构设计师考试考点内容（总结篇）——考试日期 5 月 25 日、综合知识考点、案例分类、论文四题。
• 环球网校：2024 年上半年系统架构设计师考试综合知识真题汇总——合格标准与成绩公布说明（题目正文为下载链接，未采用）。
• CSDN weixin_52894047：2024 年上半年综合知识真题（解析版）——只公开 1–20 题字母答案表，题序无法对应，未采用，列出仅为说明。

再次提醒：以上均为第三方回忆整理，可能存在遗漏或错误，请以考试主办方发布及正版真题为准；本文的解析与素材为个人整理，不代表官方评分标准。