先把丑话说在前面：这一篇是“诚实版”真题复盘。2025 年下半年这一场，我能在公开网页上逐字读到并交叉确认的内容，远没有 2026 年上半年那一场多——各培训机构的综合知识、案例分析大多是图片或 PDF，正文页只放“样题”，下载还要留资料。所以我不打算拿一堆“听说答案是 X”的东西把 75 题填满，那样对备考的人是坑。这篇的原则很简单：有可靠来源的，给答案并写自己的解析；找不到的，明确标“答案待核实”，再用大量篇幅把这一场暴露出来的考点（尤其是四道论文题）讲透，让你哪怕拿不到原卷，也能靠这场的“题眼”复习。
版权与使用说明：真题版权归考试主办方所有。本文对每道题只做“题意概括 + 选项要点”，并附我自己写的解析，不整页搬运原卷。请以人社部/工信部官方发布及正版真题为准。文中所有“答案”均来自我真实打开读过的公开页面，来源见文末；单一来源的我都会标出来。
一、场次概况：先确认考试真的存在、在哪天
系统架构设计师属于计算机技术与软件专业技术资格（水平）考试的高级科目，通常一年两考（上半年 5 月、下半年 11 月）。2025 年下半年这一场我核实到的信息如下：
| 项目 | 内容 | 来源与说明 |
|---|---|---|
| 考试日期 | 2025 年 11 月 8 日（周六） | 环球网校考试信息页（2025-11 汇总页）写明“11 月 8 日举行”；其论文真题页也标注“2025 年 11 月 8 日”。 |
| 科目一 | 综合知识，75 题选择题，满分 75 分 | 多个机构页面一致。 |
| 科目二 | 案例分析，5 道大题做 3 道（机构页面称第一题必做，其余四题选二），满分 75 分 | 机构页面称“第一题必做，后面四选二”，与历年高级科目惯例一致；具体以准考证/考场说明为准。 |
| 科目三 | 论文，4 选 1，满分 75 分 | 希赛网、环球网校论文页均列出 4 道题。 |
| 合格标准 | 各科目为满分的 60%，即 45 分，需一次通过全部科目 | 环球网校页面引用人社部通知：自 2022 年度起各科合格标准为试卷满分的 60%。 |
| 成绩公布 | 考后约 1 个月 | 机构页面表述，具体以各省人社/考试机构公告为准。 |
一处小冲突：希赛网的“2025 下半年论文真题”页面正文里出现了“9 月”的字样，与 11 月 8 日的考试日期对不上；我判断这是页面模板/整理时的笔误（该页面发布在下半年备考期，且四道论文题与环球网校 11 月 8 日论文页一致），日期以 11 月 8 日为准。这也提醒我们：机构页面里的日期不要盲信，报名和考试时间永远以官方公告为准。
二、综合知识：能确认的 8 道题
综合知识这一科，我找到的公开正文资料主要有两类：一是培训机构的“回忆版”页面（多数以图片/PDF 形式提供，正文不给逐题文字）；二是个人博主的解析专栏。后者里有一位博主（CSDN “蓝天居士”的系统架构设计师专栏，付费专栏，但每篇开头第一题公开可读）明确标注了“本题是 2025 年 11 月最近一次软考系统架构设计师综合知识中的一道真题”。我把公开可读的 8 道整理在下面。注意：该博主的题号是他整个专栏的连续编号，并不是这次考试的题号，所以本文不标注考场题号，只按主题编号。这些题全部是单一来源，我用自己的知识逐题做了核对（核对结论写在每题解析里），没有发现冲突。
2.1 答案速对表
| 编号 | 主题 | 参考答案 | 来源数 | 我的核对 |
|---|---|---|---|---|
| A1 | 提前 3 天完成，日工作量需增加多少 | C（25%） | 1 | 已自行验算，一致 |
| A2 | MVP 模式说法错误的是 | A（View 可直接访问 Model） | 1 | 符合 MVP 定义 |
| A3 | CBAM 主要关注 | B（投资回报，收益与成本平衡） | 1 | 符合教材 |
| A4 | 电子签名说法错误的是 | A（签名的数字化图像） | 1 | 符合《电子签名法》概念 |
| A5 | 属于创建型设计模式的是 | A（抽象工厂） | 1 | 正确 |
| A6 | 判定树/判定表分析的对象 | B（加工） | 1 | 符合结构化分析 |
| A7 | “共享同一输入文件”属于何种内聚 | B（通信内聚） | 1 | 符合内聚分类 |
| A8 | 进程通信（消息传递）体系结构说法错误的是 | D（构件之间不是独立的） | 1 | 符合进程通信风格 |
2.2 逐题解析
A1：提前完工的工作量增幅（项目管理计算）
题意概括：某项目预计 15 天完成，现在要求提前 3 天、即 12 天完成，每天的工作量需要比原计划增加多少？选项是 10%、20%、25%、30%。
参考答案：C（25%）。
解析：把总工作量设为 1。原计划每天做 1/15；现在每天要做 1/12。增幅 =（1/12 − 1/15）÷（1/15）=（1/60）÷（1/15）= 1/4 = 25%。易错点：很多人会拿“3 ÷ 15 = 20%”选 B，这是把“天数少了 20%”当成了“效率要提高 20%”。工作量固定时，天数与日工作量成反比：天数减 20% 后剩 80%，要保持总量不变，日工作量必须是原来的 1/0.8 = 1.25 倍。口诀：“时间缩 a，效率涨 a/(1−a)”，缩 20% 涨 25%，缩 50% 涨 100%。
回链：进度类计算（PERT、关键路径、赶工）在本专栏综合知识（上）里有专门整理，见《综合知识精讲（上）：架构基础与软件工程》。
A2：MVP 模式（软件架构 / 表现层模式）
题意概括：关于 MVP（Model-View-Presenter）模式，四个说法里“错误”的是哪一个：View 可以直接访问 Model；MVP 常用于移动端；M/V/P 分别表示数据实体/展示/处理逻辑；一个 Presenter 可以对应多个页面。
参考答案：A。
解析：MVP 的核心就是把 View 和 Model 彻底隔开：View 只负责展示和采集用户输入，所有数据的读取、修改都要经过 Presenter，Presenter 再去调 Model，并把结果回填给 View。这样 View 变成“被动视图”（Passive View），Presenter 可以脱离界面做单元测试。对比记忆：
| 模式 | View 与 Model 关系 | 中间层 | 典型场景 |
|---|---|---|---|
| MVC | View 可以观察 Model（经典 MVC 中 View 从 Model 取数据） | Controller 接收输入并选择视图 | Web 服务端框架、桌面应用 |
| MVP | 完全隔离，只经 Presenter | Presenter 双向沟通 | Android 早期架构、WinForms |
| MVVM | 通过数据绑定，View 绑定 ViewModel | ViewModel 暴露可绑定状态 | WPF、Vue、SwiftUI 等 |
“一个 Presenter 可以对应多个页面”是可行的（复用业务逻辑），B、C、D 都是对的。这类“找错误说法”的题，在软考里几乎年年有一道模式对比题。
A3：CBAM（架构评估）
题意概括：CBAM（成本效益分析方法）主要关注什么？选项分别是干系人主观感受、投资回报（收益与成本的平衡）、从干系人角度评估实现成本、从架构师角度评估实现难度。
参考答案：B。
解析：CBAM 是 SEI 在 ATAM 基础上发展出来的经济性评估方法：ATAM 找出架构决策的风险点、敏感点、权衡点，CBAM 则进一步对不同架构策略量化“收益（Benefit）、成本（Cost）、投资回报率 ROI”，帮助在预算有限的情况下决定先做哪些架构改进。架构评估三兄弟的对比，是这类题的固定套路：
| 方法 | 全称 | 侧重 | 一句话 |
|---|---|---|---|
| SAAM | Software Architecture Analysis Method | 基于场景，最早形成文档并广泛使用，侧重可修改性等 | “最早、场景驱动” |
| ATAM | Architecture Tradeoff Analysis Method | 多质量属性权衡，识别敏感点、权衡点、风险点 | “权衡” |
| CBAM | Cost Benefit Analysis Method | 经济性：成本、收益、ROI | “算钱” |
回链：架构评估的完整知识在《综合知识精讲（上）》。
A4：电子签名（信息安全与法规）
题意概括：关于电子签名（Electronic Signature），下列说法“错误”的是：A 是签名的数字化图像之类；B 是电子认证的通用说法；C 是电子印章；D 是电子码。
参考答案：A。
解析：这道题我读到的博主解析，思路是“手写签名扫描图像只是普通电子标识，不满足可靠电子签名的技术要求”。我补充自己的理解：按我国《电子签名法》，电子签名是指数据电文中以电子形式所含、所附用于识别签名人身份并表明签名人认可其中内容的数据。关键词是“可识别身份、表明认可、与数据电文相关联”，并不等于“把手写签名拍成图片贴上去”。图片形式的签名很容易被复制粘贴，不具备可靠性。技术实现上，可靠的电子签名通常基于数字签名：用签名人的私钥对报文摘要加密，验证方用公钥解密并比对摘要，再配合 CA 颁发的数字证书证明公钥归属。
顺带复习一个高频结论：数字签名 = 非对称加密 + 数字摘要（哈希），可提供完整性、不可否认性和身份认证，但不提供机密性。
回链：数字签名/PKI/加密体系，见《综合知识精讲（下）：数据库、网络安全、嵌入式与新技术》。
A5：创建型设计模式
题意概括：下列哪个属于创建型设计模式：抽象工厂、观察者、桥接、装饰器。
参考答案：A（抽象工厂）。
解析：23 种 GoF 模式分三类，最稳的背法是先背创建型 5 个，其余按“结构型 7 个、行为型 11 个”分。
| 类别 | 成员 | 记忆 |
|---|---|---|
| 创建型（5） | 抽象工厂、工厂方法、单例、建造者、原型 | “创建对象怎么创” |
| 结构型（7） | 适配器、桥接、组合、装饰器、外观、享元、代理 | “类和对象怎么拼” |
| 行为型（11） | 责任链、命令、解释器、迭代器、中介者、备忘录、观察者、状态、策略、模板方法、访问者 | “对象之间怎么协作” |
观察者是行为型，桥接、装饰器是结构型，所以答案唯一。抽象工厂的关键词是“一系列相关或相互依赖对象的创建接口，无需指定具体类”（换皮肤、跨平台控件族）。
A6：判定表与判定树（结构化分析）
题意概括：判定树和判定表是用来分析（描述）什么的？数据流、加工、数据存储、外部实体。
参考答案：B（加工）。
解析：结构化分析里，数据流图（DFD）描述“数据怎么流”，数据字典描述“数据是什么”，而加工（处理）内部的逻辑用“结构化语言、判定表、判定树”三种工具来细化。判定表适合条件多、组合多的场景（条件桩、条件项、动作桩、动作项），判定树适合条件层次清楚的场景。备考时把“加工逻辑三件套”和“数据字典四类条目（数据流、数据项、数据存储、加工）”分开记，别混。
A7：模块内聚类型
题意概括：某模块读取生产线上传递的文件，通过文件系统计算出工作量排前三的工人名单及其工作量，问这个模块属于哪种内聚：功能、通信、偶然、逻辑。
参考答案：B（通信内聚）。
解析：内聚从强到弱：功能内聚 > 顺序内聚 > 通信内聚 > 过程内聚 > 时间内聚 > 逻辑内聚 > 偶然内聚。通信内聚的判据是模块内的多个操作使用同一份输入数据或产生同一份输出数据；顺序内聚则是前一个操作的输出是后一个操作的输入。本题里读取、计算、排序都围绕“同一个文件数据”，所以判通信内聚。备考建议：这道题的“判据词”比故事重要——看见“同一数据/同一文件/同一数据结构”就想到通信内聚；看见“前者输出作后者输入”想顺序内聚；看见“通过参数选择执行哪个功能”想逻辑内聚。
A8：进程通信体系结构
题意概括：关于进程通信体系结构中“消息传递”方式的描述，哪项是错误的：支持异步通信；支持连续的消息传递；构件间通过消息通信；构件之间不是独立的。
参考答案：D。
解析：进程通信风格里，构件是独立的进程，连接件是消息传递（同步或异步、点对点或广播）。它最大的特点就是构件独立、只通过消息交互，所以“构件之间不是独立的”一定是错的。这一场的姊妹题可以放在一起记：“构件为独立过程，连接件为消息传递 ⇒ 进程通信”，在 2026 年上半年的场次里也出现了几乎同款考法（见《2026 年上半年真题》）。
2.3 其余 67 题：答案待核实
除了上面 8 道，这一场其余综合知识题我没有找到可交叉验证的文字版答案。环球网校、希赛网都有“回忆版”入口，但正文页只放图片样题或指向下载页；知乎的“网友回忆版”页面我打开后被要求登录验证，无法读取。所以：这 67 道题我一概标“答案待核实”，不给猜测。如果你手上有正版真题，建议自己对着做一遍，再用下面第五节的“考点热度”去反查薄弱章节。
三、案例分析：只能确认的考点线索
案例分析这一科，我能读到的文字信息只有一位博主在考后写的“题目回忆”：他记下的案例题涉及嵌入式系统、Petri 网建模工具的意义与用法、Web 系统中的限界上下文（DDD）相关理论；另外两题他没有记（原文留空）。环球网校的案例分析入口标的是“考后更新”，没有正文。因此：
- 具体设问、分值、参考答案：答案待核实，我不编。
- 下面三个考点，我按自己的理解写“知识点讲解”，明确不是原题答案，只用来帮你补这三块知识。
3.1 嵌入式系统（考法线索）
软考架构师的嵌入式题，历年常见的设问方向有：嵌入式软件的特点与分层（硬件抽象层 HAL、板级支持包 BSP、RTOS、应用层）、实时性（硬实时 / 软实时，调度算法如 RMS、EDF）、可靠性与容错（看门狗、冗余、双机热备）、低功耗、中断与任务优先级（优先级反转与优先级继承 / 天花板协议）、DO-178C / 安全关键软件。强实时设计一般采用表驱动与静态调度（可预测性强），弱实时才多用动态调度。做这类题的通用答题模板：先答“特点/约束”，再答“设计手段”，最后答“如何验证”。
回链：嵌入式知识在《综合知识精讲（下）》里有专门一节，案例答题套路见《案例分析：题型拆解与答题模板》。
3.2 Petri 网（考法线索）
Petri 网是一种用于描述并发、异步、分布式系统的图形化建模与分析工具。你需要掌握的最小集合：
- 基本元素：库所（Place，圆圈，表示状态/条件/资源）、变迁（Transition，方块，表示事件/动作）、弧（Arc，连接库所和变迁，不能库所连库所）、令牌（Token，库所里的黑点，表示资源/控制流位置）。
- 变迁发生规则：一个变迁使能（enabled）当且仅当它所有输入库所里的令牌数都满足输入弧权重；发生后从输入库所消耗令牌，向输出库所产生令牌。
- 可分析性质：可达性（能否到达某状态）、有界性（库所令牌数是否有上限）、活性（是否不会死锁）、可逆性、冲突与并发。
- 用途：验证并发协议、工作流建模、死锁检测、性能评价（随机 Petri 网）。
- 建模工具的“意义”：图形化、有严格数学语义，可自动分析可达图 / 死锁；缺点是状态空间爆炸，规模大时要靠着色 Petri 网（CPN）或分层建模。
典型练习：用 Petri 网表示“两个进程互斥访问临界资源”：一个“互斥锁”库所初始放 1 个令牌，两个进程的“进入临界区”变迁都以该库所为输入，一个进程占用令牌后另一个进程的变迁就不使能，直到退出临界区把令牌放回。这也是你在操作系统里学 P/V 操作的图形版。
3.3 限界上下文（考法线索）
限界上下文（Bounded Context）来自领域驱动设计（DDD）的战略设计部分，与微服务划分强相关。要点：
- 定义：一个显式的语义边界，在边界内，通用语言（Ubiquitous Language）中的每个术语含义唯一。同一个词（如“客户”“订单”）在不同上下文里可以有不同模型，这是合理的。
- 上下文映射（Context Map）：描述上下文之间的关系，常见模式有共享内核、客户-供应商、遵奉者、防腐层（ACL）、开放主机服务、发布语言、分离方式等。
- 与微服务的关系：限界上下文是划分微服务边界的重要依据，“一个微服务 ≈ 一个限界上下文”是常见起点，但不是铁律。
- 其他战略设计概念：领域、子域（核心域 / 支撑域 / 通用域）；战术设计：实体、值对象、聚合、聚合根、领域服务、领域事件、仓储。
一个好用的答题句式：“按业务能力划分限界上下文，上下文之间通过防腐层/领域事件解耦，聚合内部保证强一致、跨聚合采用最终一致。”
四、论文：四道题的考查方向与写作方案
论文这一科是本场信息最完整的部分。希赛网与环球网校的论文页面都列出了同样的 4 道题（论文题目内容我读到了，下文用自己的话概括要求，不照抄原文）：
| 题号 | 题目方向 | 核心考查 | 难度感受（我的判断） |
|---|---|---|---|
| 1 | 论无服务器（Serverless）架构 | 项目背景与角色；Serverless 核心组成（FaaS、BaaS）如何实现降本增效、弹性伸缩；选型依据、实施难点、落地效果 | 需要真实用过或深入研究，容易写虚 |
| 2 | 论基于云原生数据库的企业信息系统架构 | 企业系统背景与职责；云原生数据库的技术优势（容器化、K8s 编排、存算分离等）；选型思路、实施难点、成效 | 云原生数据库项目经验少的人会吃力 |
| 3 | 软件性能测试技术及其应用 | 性能测试类型（负载、压力、并发等）、关键指标（响应时间、吞吐量、资源利用率）与流程；设计思路、遇到的困难、优化效果 | 相对“通用”，多数人有素材 |
| 4 | 秒杀场景的设计与解决方案 | 秒杀项目背景；技术挑战与对策：扩容、动静分离、缓存、服务降级、限流；落地效果 | 技术点集中，套路化程度高 |
说明：性能测试与秒杀这两题在考后回忆里也被博主提到（关键词与上表一致）；Serverless 与云原生数据库两题在希赛网页面里有较完整的要求描述。我没有找到官方给出的“标准范文”，下面的写作方案都是我自己整理的思路，不是评分标准。
4.1 论文通用骨架（回顾）
软考论文评分主要看：摘要（约 300–400 字）+ 正文（约 2000–3000 字），三段式：项目背景与角色 → 技术论述（原理 + 选型 + 设计）→ 实施难点与效果。摘要要写清项目、你的角色、采用了什么技术、取得了什么效果，正文要与摘要一致。详细模板见《论文写作：套路、模板与素材库》。下面四道题我各给一个“可直接套”的提纲和素材点。
4.2 论 Serverless 架构
概念与要点：Serverless 并不是“没有服务器”，而是开发者不再管理服务器，由云平台负责资源分配、扩缩容和运维。核心组成是两类服务：
- FaaS（Function as a Service）：以函数为单位部署，事件驱动，按调用次数和执行时长计费，如 AWS Lambda、阿里云函数计算、腾讯云 SCF。
- BaaS（Backend as a Service）：把认证、数据库、对象存储、消息队列等后端能力做成托管服务，前端或函数直接调用。
降本增效与弹性：按需分配、按量付费（低流量时接近零成本）；自动弹性伸缩（从 0 到 N 个实例）；运维职责上移到云厂商，团队聚焦业务。
典型挑战与对策（这是评分点）：
| 挑战 | 说明 | 对策 |
|---|---|---|
| 冷启动 | 实例空闲后首次调用需要初始化，延迟增加 | 预留并发 / 预热、减小依赖包、选择启动更快的运行时 |
| 无状态 | 函数实例不保证复用，本地状态会丢 | 状态外置到 Redis、数据库、对象存储 |
| 执行时长与资源限制 | 函数有超时时间和内存上限 | 长任务拆分、用工作流编排（Step Functions / 工作流服务） |
| 可观测性与调试 | 分布式函数调用链难追踪 | 接入链路追踪、结构化日志、统一监控 |
| 供应商锁定 | 函数接口与平台强相关 | 抽象适配层、采用开放标准（如 CloudEvents）或 Knative 等开源方案 |
| 并发与下游压力 | 函数自动扩容可能压垮数据库 | 限制并发上限、连接池代理、队列削峰 |
提纲示例：
- 摘要：某电商营销活动/图片处理/IoT 数据接入平台，我担任架构师，采用 FaaS + BaaS，事件驱动，解决了突发流量与成本问题，峰值处理能力提升 X 倍、成本下降 Y%。
- Serverless 概述：定义、FaaS/BaaS、事件驱动、按需计费。
- 项目背景与选型：为什么选 Serverless 而不是微服务 / 虚机（流量波动大、运维人手不足）；选型对比。
- 架构设计：API 网关 → 函数 → 消息队列 → 托管数据库 / 对象存储；鉴权与日志。
- 实施难点：冷启动、无状态、下游压力、调试，逐条给对策。
- 效果与总结：性能指标、成本对比、不足与改进（锁定、复杂编排）。
写作提醒：数字要有量级感但不必过分精确；不要把 Serverless 写成“万能药”，评卷老师喜欢看到你说出适用场景与不适用场景（长时间运行、强状态、极低延迟要求的场景就不适合）。
4.3 论基于云原生数据库的企业信息系统架构
概念要点：云原生数据库是专为云环境设计的数据库，典型特征是存储与计算分离、共享存储、弹性伸缩、高可用多副本、按需计费、容器化 / 可用 K8s 编排、Serverless 形态。代表产品如 Amazon Aurora、阿里云 PolarDB、腾讯云 TDSQL-C、华为 GaussDB、OceanBase 等（写论文时选你真实接触过的一个即可）。
相对传统数据库的优势：
- 存算分离：计算节点无状态或轻状态，可以秒级扩缩；存储层分布式多副本，容量线性扩展。
- 读写分离与只读节点：多个只读节点共享同一份存储，主从复制延迟极低（不再需要传输整份数据）。
- 高可用与快速恢复：计算节点故障可快速切换，备份基于存储快照，恢复快。
- 运维自动化：自动备份、自动扩缩容、监控告警集成。
- 成本弹性：存储按用量、计算按需，可结合 Serverless 形态进一步降本。
实施难点与对策：
| 难点 | 对策 |
|---|---|
| 从传统库迁移（数据量大、停机窗口短） | 全量 + 增量同步（如 DTS 类工具）、灰度切流、可回滚方案 |
| SQL 与功能兼容性 | 迁移前做兼容性评估与回归测试，改写不兼容语法与存储过程 |
| 多节点读一致性 | 读写分离时对强一致读走主节点，或使用一致性读路由 |
| 成本失控 | 监控用量，按业务峰谷设置弹性策略与预留资源 |
| 云厂商锁定 | 选兼容 MySQL / PostgreSQL 协议的产品，保留出云路径 |
提纲示例：摘要 → 企业信息系统背景（例如某集团 ERP / 订单中心）→ 云原生数据库概述与优势 → 选型（自建 MySQL 主从 vs 云原生）→ 架构设计（应用层 / 连接代理 / 主节点 + 只读节点 / 共享存储 / 备份）→ 迁移与落地 → 难点与对策 → 效果（QPS、故障恢复时间、扩容时长、成本）→ 总结。
4.4 论软件性能测试技术及其应用
类型与指标：
| 测试类型 | 目的 | 做法要点 |
|---|---|---|
| 基准测试 | 建立性能基线 | 单用户 / 低并发下测各接口指标 |
| 负载测试 | 确认在预期负载下满足指标 | 逐步加压到目标并发，观察指标 |
| 压力测试 | 找极限与崩溃点 | 持续加压超过设计容量，看降级 / 恢复行为 |
| 并发（同步）测试 | 暴露竞态、锁与资源争用 | 多用户同一时刻操作同一资源 |
| 稳定性（浸泡）测试 | 发现内存泄漏、连接泄漏 | 长时间中等负载运行 |
| 容量测试 | 确定最大承载与扩容点 | 结合数据量增长做规划 |
关键指标：响应时间（平均、P90/P95/P99）、吞吐量（TPS/QPS）、并发用户数、错误率、资源利用率（CPU、内存、磁盘 IO、网络）。经典关系：TPS ≈ 并发数 ÷ 平均响应时间（Little 定律的简化）。
流程：需求分析与指标制定 → 环境准备（尽量与生产一致）→ 场景与脚本设计（业务比例、思考时间、参数化）→ 数据准备 → 执行与监控 → 结果分析与瓶颈定位 → 调优与回归 → 报告。
瓶颈定位与调优思路：自顶向下：先看应用响应时间分布，再到线程池 / 连接池、JVM（GC）、数据库（慢 SQL、索引、锁）、缓存命中率、网络与操作系统。工具可写：JMeter、LoadRunner、Gatling 做压测，Prometheus + Grafana 监控，Arthas / async-profiler 做诊断，慢查询日志与执行计划分析 SQL。
提纲示例：摘要 → 项目背景（如订单系统上线前压测）→ 性能测试理论（类型、指标、流程）→ 测试方案设计（场景、数据、环境）→ 执行与瓶颈分析（例如发现连接池过小、慢 SQL 缺索引、缓存穿透）→ 优化（索引、缓存、异步化、线程池调整）→ 效果（P99 从 X ms 降到 Y ms，TPS 从 A 提到 B）→ 总结。
4.5 论秒杀场景的设计与解决方案
这一题的题干本身就把“武器库”给你了：扩容、动静分离、缓存、服务降级、限流。我把它整理成一个“分流—提速—减压—兜底”的四段式，写作时按这个逻辑串起来会很顺。
| 阶段 | 手段 | 要点 |
|---|---|---|
| 分流 | 限流、排队、验证码 / 答题、按用户维度限频 | 把 99% 的无效请求挡在最外层（网关、CDN、Nginx），只放少量请求进入后端 |
| 提速 | 动静分离、CDN、页面静态化、本地缓存 + Redis 多级缓存 | 商品详情等静态内容走 CDN；库存等热点数据放 Redis |
| 减压 | 扩容、消息队列削峰填谷、异步下单、库存预扣减 | Redis 原子操作（DECR / Lua）预扣库存，成功者进入队列异步落库 |
| 兜底 | 服务降级、熔断、超时与重试策略、数据库乐观锁 / 唯一约束防超卖 | 非核心功能（推荐、评论）直接关闭；DB 层用 UPDATE ... WHERE stock > 0 做最后防线 |
关键技术点，写论文时至少讲清三个：
- 防超卖：Redis 预扣库存（DECR 或 Lua 脚本保证原子性），数据库更新使用条件更新或乐观锁（version 字段），最终一致。
- 防重复下单：用户 + 商品维度的幂等键（唯一索引或 Redis SETNX），订单号预生成。
- 热点数据：热点库存 Key 拆分为多个分片（如 stock:1 ~ stock:N），请求随机路由，减少单 Key 压力。
- 削峰：请求进入 MQ（Kafka / RocketMQ），后端按能力消费，用户侧展示“排队中”。
- 降级与熔断：核心链路只保留“校验 → 扣库存 → 下单”，其他服务出问题时快速失败并返回友好提示。
提纲示例：摘要 → 项目背景（大促秒杀，瞬时 QPS 数十倍于平日）→ 技术挑战（高并发读、热点写、超卖、系统雪崩）→ 总体架构（CDN → 网关限流 → 秒杀服务 → Redis → MQ → 订单服务 → DB）→ 关键设计（上述五点）→ 实施难点（热点 Key、缓存与 DB 一致性、消息堆积）与对策 → 效果（峰值 QPS、错误率、无超卖）→ 总结。
回链：分布式与高并发的知识背景在《综合知识精讲（上）》的架构章节，摘要与正文的写法见《论文写作》。
4.6 摘要示例（自写，仅供练手）
2024 年 3 月，我参与了某零售企业“会员营销活动平台”的建设，担任系统架构师，负责整体架构设计与关键技术选型。平台面临秒杀活动期间瞬时流量为平日数十倍、且极易出现超卖与系统雪崩的挑战。本文结合该项目，论述了秒杀场景的设计与解决方案：在接入层通过 CDN 与动静分离降低静态资源压力，在网关层采用令牌桶限流与排队机制削峰，在业务层使用 Redis 预扣库存与消息队列异步下单，在数据层以条件更新兜底防超卖，并以服务降级和熔断保护核心链路。系统上线后，在多次大促中稳定运行，峰值请求平稳承载，未出现超卖与整体宕机，验证了方案的有效性。
上面这段摘要的“数字”我故意没写死，你自己写时请替换为真实项目的量化结果。论文最忌讳编造与项目不符的数据，评卷老师会通过前后逻辑一致性来判断真伪。
4.7 论文评分点自查清单（自写）
软考论文没有公开的官方评分细则，但从历年考生分享和培训机构的讲解中，可以归纳出大家普遍认同的几个得分维度。下面是我整理的自查清单，写完一篇练笔后按条打勾：
| 维度 | 自查问题 | 常见失分 |
|---|---|---|
| 切题 | 正文是否围绕题干给出的三个设问展开？有没有偏题写成“技术科普”？ | 只讲概念，没有落到自己的项目 |
| 项目真实性 | 项目背景、你的角色、团队规模、周期是否前后一致？ | 摘要说“主导设计”，正文又像“参与测试” |
| 技术深度 | 是否讲清“为什么这样选、比别的方案好在哪”，而不只是“我用了 X”？ | 罗列名词，没有对比与取舍 |
| 问题与对策 | 难点是否具体（现象 + 原因 + 对策 + 结果）？ | “遇到了性能问题，后来优化了”这类空话 |
| 效果量化 | 有没有指标变化（响应时间、吞吐量、成本、故障恢复时间）？ | 只有“效果良好” |
| 结构规范 | 摘要字数、分段、小标题是否清晰？ | 摘要写成正文缩写，或过长过短 |
| 文字与字迹 | 无错别字，卷面整洁；机考则注意保存与字数统计 | 时间不够导致结尾仓促 |
时间分配上，我的建议是：审题选题 5 分钟，列提纲 10 分钟，摘要 25 分钟，正文 80 分钟，检查 10 分钟，总计约两小时（考试时长以准考证为准）。摘要要先写，因为它是评卷老师最先看的部分，也是你梳理思路的过程。
4.8 案例分析拓展：嵌入式系统设计表（自写）
由于这一场案例中嵌入式系统出现了，这里补一张我整理的“嵌入式架构设计速查表”，用来快速回答“应该关注什么”类设问，同样不是原题答案：
| 关注点 | 要点 | 常用手段 |
|---|---|---|
| 实时性 | 硬实时错过截止时间即失败；软实时可降低质量 | 抢占式优先级调度、RMS、EDF、中断响应时间控制、表驱动静态调度 |
| 可靠性 | 长时间无人值守运行 | 看门狗、冗余设计、故障检测与恢复、内存保护、越界检查 |
| 资源受限 | CPU、内存、Flash、功耗有限 | 裁剪 RTOS、静态分配内存、避免动态内存碎片、代码体积优化 |
| 可移植性 | 硬件更换成本高 | 硬件抽象层 HAL、BSP 分层、统一驱动接口 |
| 安全性 | 固件被篡改、通信被窃听 | 安全启动、固件签名与加密、OTA 校验、最小权限 |
| 可测试性 | 软硬件联调困难 | 软件在环 / 硬件在环仿真、日志与诊断接口、JTAG 调试 |
如果案例里给的是“某智能设备的软件架构”，答题的稳妥顺序是：先分层（应用 / 中间件 / RTOS / HAL / 硬件），再逐层说明职责，再点出实时性与可靠性的设计策略，最后补充升级与安全。
4.9 案例分析拓展：DDD 上下文映射关系速查（自写）
| 关系模式 | 含义 | 典型场景 |
|---|---|---|
| 共享内核（Shared Kernel） | 两个上下文共享一部分模型与代码，需共同维护 | 紧密协作的小团队 |
| 客户-供应商（Customer-Supplier） | 上游提供，下游消费，下游需求影响上游计划 | 订单上下文依赖库存上下文 |
| 遵奉者（Conformist） | 下游完全遵从上游模型，不做转换 | 对接强势外部系统且无议价权 |
| 防腐层（Anticorruption Layer） | 下游在边界加转换层，避免被上游/遗留模型污染 | 新系统对接老系统 |
| 开放主机服务 + 发布语言 | 上游提供标准化协议供多方使用 | 对外开放 API、事件契约 |
| 各行其道（Separate Ways） | 两者没有集成必要 | 彼此无关的业务 |
案例题如果问“如何避免微服务之间的模型耦合”，答“通过防腐层与发布语言隔离，领域事件异步集成，各上下文拥有独立的数据存储”基本能踩到点。
五、本场考点热度总结
把能确认的信息汇总成一张图表，帮助你判断复习优先级（这是我基于已读资料的定性判断，不是官方统计）：
| 科目 | 已确认出现的考点 | 建议优先级 |
|---|---|---|
| 综合知识 | 项目管理计算、MVP 与表现层模式、架构评估（CBAM）、电子签名与数字签名、设计模式分类、结构化分析（判定表 / 树）、模块内聚、进程通信风格 | 架构风格、评估方法、设计模式、内聚耦合：必背；计算题：必练 |
| 案例分析 | 嵌入式系统、Petri 网、限界上下文（DDD） | DDD 与微服务划分、并发建模、嵌入式实时性：建议补课 |
| 论文 | Serverless、云原生数据库、性能测试、秒杀 | 云原生 / 高并发 / 性能三条主线，各准备一篇“通用素材” |
复习建议：不必把四道题各背一篇，而是把三条主线写成三篇“素材文”，考场上根据题目重组：云原生弹性（含 Serverless、云原生数据库）、高并发（含秒杀、缓存、限流、降级）、性能测试与调优。这样无论考哪个方向，你的“项目背景 + 技术论述 + 难点对策”都有现成砖头。
一句话备忘：2025 下半年这一场，综合知识要重点巩固“模式 / 评估 / 结构化分析 / 内聚”，案例盯住 DDD 限界上下文、Petri 网与嵌入式，论文押“云原生 + 高并发 + 性能测试”三条主线；凡是公开资料里没有可靠答案的题，我都不替你编。
六、答案冲突与待核实项
- 希赛网论文页的“9 月”字样与 11 月 8 日考试日期冲突，判断为页面笔误，以 11 月 8 日为准。
- 案例分析科目：具体设问、分值与参考答案未找到，全部“答案待核实”。
- 综合知识 67 题“答案待核实”；已确认的 8 题均为单一来源，仅经我个人知识核对。
- 案例分析“第一题必做，其余选做”的具体规则，请以当年考试说明为准。
参考资料
- 环球网校：2025 年下半年系统架构设计师真题及答案解析汇总——确认考试日期 11 月 8 日、合格标准 45 分、各科入口。
- 环球网校：2025 年 11 月 8 日系统架构设计师论文真题——论文题目与考查方向（Serverless、云原生数据库）。
- 希赛网：2025 下半年系统架构设计师下午论文真题及答案——四道论文题的要求描述。
- 博客园：2025 下半年软考系统架构设计师题目回忆版——案例分析考点线索与论文题目关键词。
- CSDN 蓝天居士专栏：2025 年 11 月真题（工作量增幅）、（MVP）、（CBAM）、（电子签名）、（抽象工厂）、（判定表）、（内聚）、（消息传递）——本文 8 道综合知识题的题意与答案来源，博主明确标注为 2025 年 11 月真题。
再次提醒：以上均为第三方整理，可能存在遗漏或错误，请以考试主办方发布及正版真题为准；本文的解析与素材为个人整理，不代表官方评分标准。
一起聊聊