【软考架构】2025H2系统架构设计师考试复习.jpg（软件架构、软件工程、数据库、Web开发、高项）

【软考架构】2025H2系统架构设计师考后复习.jpg（软件架构、软件工程、数据库、Web开发、高项）

背景

接上回【软考架构】2025系统架构设计师开坑指南------后端开发（科目选择，考试大纲，真题分析），因为没怎么花时间复习，当时只是考前大概看了1-2天，本身也就是当第一次考试去体验一下的 ，没指望能过，没想到题目意外的感觉能做，最后居然是只差三四分就能过，虽然没过是预期之内，但还是感觉非常可惜。当时立志下次一定过。

奈何还是算不准，考前这段时间实在太忙了。忙到几乎每天十点多才能到家，睡一觉第二天又得出门，所以直到考试的最后一个晚上，也抽不出哪怕1个小时的时间看，所以只能又当做捐款了。本篇只是记录下今年的考试经历，在考后的周日，写忏悔式的复习笔记，大致梳理下复习重点。因为下次考试还挺远，所以暂时也不能算完整的启动复习计划。仅此。

成年人的世界，就是这样的。人在江湖，身不由己。日常生活的琐碎，很多不得不面对的事情。很多时候都不再能像学生时代那样全情投入的去做一件事情了。身后都有着许多不得不牵挂的事情。

文章目录

- [1、选择题 75](#1、选择题 75)
- - [1.1 软件架构知识 20](#1.1 软件架构知识 20)
  - [1.2 软件工程+面向对象+数据库 25](#1.2 软件工程+面向对象+数据库 25)
  - [1.3 408（系统+计网+计组, 无DS） 10](#1.3 408（系统+计网+计组, 无DS） 10)
  - [1.4 高项（信息系统+信息安全+软件可靠+未来科技+知产+数字经济） 15](#1.4 高项（信息系统+信息安全+软件可靠+未来科技+知产+数字经济） 15)
  - [1.5 英语 5](#1.5 英语 5)
- [2、大题 75](#2、大题 75)
- - [2.1 软件架构（架构风格、架构质量、架构风险） 25](#2.1 软件架构（架构风格、架构质量、架构风险） 25)
  - [2.2 软件工程（UML建模，数据流图，需求建模） 25](#2.2 软件工程（UML建模，数据流图，需求建模） 25)
  - [2.3 Web系统（架构分层、协议选择、高并发方案） 25](#2.3 Web系统（架构分层、协议选择、高并发方案） 25)
  - [2.4 数据库（缓存问题，分布式锁，数据库设计） 25](#2.4 数据库（缓存问题，分布式锁，数据库设计） 25)
  - [2.5 嵌入式 25](#2.5 嵌入式 25)
- [3、论文 75](#3、论文 75)
- - [3.1 软件架构-私有云（架构风格、架构评估，八大架构，云原生、微服务、安全架构）](#3.1 软件架构-私有云（架构风格、架构评估，八大架构，云原生、微服务、安全架构）)
  - [3.2 软件工程-AI测试（全生命周期，开发方法、开发模型，需求分析、设计、测试、运维）](#3.2 软件工程-AI测试（全生命周期，开发方法、开发模型，需求分析、设计、测试、运维）)
  - [3.3 高项-代码治理（系统可靠性、安全性、容错技术，项目管理，企业应用集成、企业集成平台）](#3.3 高项-代码治理（系统可靠性、安全性、容错技术，项目管理，企业应用集成、企业集成平台）)

1、选择题 75

选择题 ：不确定时选"更抽象、更具扩展性 "的选项（如优先选"微服务""分布式"而非具体技术）

1.1 软件架构知识 20

1. 架构风格（题干关键词→答案匹配）

题干提"物联网/分层解耦"→选分层架构
题干提"实时规则/动态政策（如社保计算）"→选规则系统（虚拟机风格）
题干提"数据流式处理（如日志分析）"→选管道-过滤器
题干提"独立服务/弹性扩展/小团队开发"→选微服务
题干提"企业级服务集成/ESB"→选SOA
题干提"事件触发/异步通信（如实时通知）"→选事件驱动架构

2. 质量属性（场景→答案）

场景"双机热备/主备切换/心跳检测"→质量属性选可用性 ，架构策略选主动冗余/心跳
场景"响应时间≤1s/并发10万用户"→质量属性选性能，架构策略选资源调度/负载均衡
场景"防黑客攻击/数据加密/访问控制"→质量属性选安全性 ，架构策略选权限控制/检测攻击
场景"少量功能修改≤10人·月"→质量属性选可修改性 ，架构策略选模块化/低耦合

3. 架构评估（题干关键词→答案）

题干提"性能/可用性/安全性/可修改性多属性权衡"→选ATAM
题干提"需求+架构描述输入，单场景评估"→选SAAM
题干提"加密级别影响安全与性能"→选权衡点（多属性影响）
题干提"某构件特性影响单一属性（如缓存影响性能）"→选敏感点

4. 设计模式（功能→答案）

题干提"确保一个类只有一个实例"→选Singleton（单例）
题干提"复杂对象构建与表示分离（如复杂文档生成）"→选Builder（构建者）
题干提"不明确类时创建对象（如插件扩展）"→选AbstractFactory（抽象工厂）
题干提"简化复杂系统接口（如子系统统一入口）"→选Facade（外观）

1.2 软件工程+面向对象+数据库 25

一、软件工程（题干→答案）

1. 开发模型

题干提"需求稳定/顺序开发（如传统管理系统）"→选瀑布模型
题干提"风险驱动/迭代+原型（如复杂系统）"→选螺旋模型
题干提"适应变化/以人为本/迭代增量"→选敏捷开发
题干提"需求不明确/快速验证（如新品原型）"→选原型法

2. 测试

题干提"不运行程序，人工查代码/文档"→选静态测试
题干提"运行程序，不看内部结构（如功能验证）"→选黑盒测试
题干提"运行程序，看内部逻辑（如路径覆盖）"→选白盒测试
题干提"修改后验证不影响原有功能"→选回归测试

3. 需求变更

题干提"需求变更审批主体"→选CCB（配置控制委员会）
题干提"需求变更流程（问题分析→？→变更实现）"→选变更分析和成本计算
题干提"需求变更对项目'有利无弊'"→判断错误（变更有风险，需控制）

二、面向对象（题干→答案）

题干提"描述对象间消息交互顺序"→选顺序图
题干提"描述用例间'包含/扩展'关系"→选用例图
题干提"描述对象生命周期状态迁移（如订单状态）"→选状态图
题干提"类间'整体-部分'（如汽车-轮胎，部分可独立）"→选聚合关系
题干提"类间'整体-部分'（如人与心脏，部分不可独立）"→选组合关系

三、数据库（题干→答案）

1. 范式与函数依赖

题干提"属性可由其他属性推导（如年龄由出生日期推导）"→选派生属性 ，需删除以满足3NF
题干提"无部分依赖（主键→所有非主属性）"→选2NF
题干提"无传递依赖（无'主键→A→B'）"→选3NF
题干提"求属性闭包（如AD→所有属性）"→选候选关键字（AD）

2. 分布式数据库

题干提"用户无需知道数据物理位置"→选位置透明
题干提"用户无需知道数据分片"→选分片透明

3. 事务与安全

题干提"事务ACID特性，原子性/一致性/隔离性/持久性"→缺失项选对应特性（如"崩溃后数据不丢"→选持久性）
题干提"防SQL注入"→选PreparedStatement/输入验证/存储过程

1.3 408（系统+计网+计组, 无DS） 10

一、操作系统（题干→答案）

1. 进程与线程

题干提"资源分配最小单位"→选进程
题干提"调度最小单位，共享进程资源（如文件）"→选线程
题干提"同一进程内线程私有资源"→选栈指针

2. 内存管理

题干提"页面大小4KB（2^12B），逻辑地址5148H→物理地址"→步骤：页内偏移12位（148H），页号5→查页表得页帧3→物理地址3148H
题干提"'段+页'结合，逻辑地址=段号+页号+页内偏移"→选段页式
题干提"页面置换，选最近最少使用"→选LRU

3. 磁盘调度

题干提"优先访问最近柱面（如当前20号柱面，优先21号）"→选最短移臂调度

二、计算机网络（题干→答案）

题干提"DNS配置文件（Linux）"→选**/etc/resolv.conf**
题干提"邮件发送协议/端口"→选SMTP/25
题干提"邮件接收协议/端口"→选POP3/110
题干提"HTTPS端口"→选443 ；"HTTP端口"→选80
题干提"Internet核心交换方式"→选分组交换

三、计算机组成（题干→答案）

题干提"位示图大小计算（300GB磁盘，4MB物理块，32位字长）"→步骤：总块数=300*1024/4=76800→位示图字数=76800/32=2400
题干提"虚拟地址→物理地址，页表查询"→选页式内存管理

1.4 高项（信息系统+信息安全+软件可靠+未来科技+知产+数字经济） 15

1. 信息系统

题干提"企业数字化转型阶段（初始→单元→流程→网络→生态）"→选对应阶段（如"部门级数字化"→选单元级）
题干提"EAI四层服务（从下到上）"→选通信→信息传递与转化→应用连接→流程控制

2. 信息安全

题干提"信息不泄露给未授权者"→选机密性
题干提"信息不被篡改"→选完整性
题干提"系统正常运行时间比例"→选可用性
题干提"5G虚拟网络隔离"→选网络切片技术
题干提"WiFi高安全加密（AES）"→选WPA2

3. 软件可靠

题干提"失效率恒定，修复时间短，MTTF与MTBF关系"→选几乎相等
题干提"双机热备/故障检测"→选心跳机制

4. 知识产权

题干提"软件著作权生效时间"→选软件开发完成之日
题干提"职务作品著作权归属"→选单位（开发者仅署名权）
题干提"保护期不受限制的著作权"→选署名权
题干提"修改源程序标识符后销售"→选侵犯软件著作权

5. 未来科技

题干提"物联网三层架构"→选感知层→网络传输层→应用层
题干提"云计算服务（软件即服务）"→选SaaS ；"平台即服务"→选PaaS ；"基础设施即服务"→选IaaS
题干提"区块链'挖矿'本质"→选工作量证明机制

1.5 英语 5

高频词汇+句型（题干→答案）

题干提"微服务架构"→选microservice architecture
题干提"软件生命周期"→选software lifecycle
题干提"需求分析"→选requirements analysis
题干提"数据库服务器"→选database server
题干提"Web服务器"→选Web server
句型"The purpose of...is to..."→填"describe the system architecture"（描述系统架构）等符合语境的短语
句型"...enables...to..."→填"achieve high availability"（实现高可用）等符合语境的短语

2、大题 75

案例题：分点作答，用 "问题→原因→方案 " 结构，多写关键词（如 "微服务拆分""Redis 缓存""数据平衡"）

2.1 软件架构（架构风格、架构质量、架构风险） 25

高频小题及分值

架构风格对比分析（7-13分）：如微服务vs单体、解释器vs面向对象等
架构质量属性效用树填空（6-12分）：性能、可用性、安全性、可修改性相关
架构风险/敏感点/权衡点识别（6-9分）
架构模式应用（如Lambda/Kappa架构）（8-10分）

解题套路

架构风格对比：先明确核心需求（如"灵活性优先""性能优先"），再从"灵活性、可扩展性、性能、维护成本"4个维度套用模板，最后给出结论。
- 例：微服务vs单体：微服务灵活性/扩展性强、技术多样，但复杂性/运维成本高；单体部署简单、性能好，但扩展性差，适合业务简单场景。
效用树填空：先归类质量属性（性能=响应时间/吞吐量；可用性=容错/恢复；安全性=防护/审计；可修改性=扩容/界面调整），再匹配题干描述关键词。
风险/敏感点/权衡点：风险=潜在隐患（如需求未达成共识）；敏感点=影响单个质量属性的设计点；权衡点=影响多个质量属性的设计点。

架构风格对比（必考，7-13分）

架构风格	核心特点	适用场景	优缺点对比（高频问答）
单体架构	所有功能打包为一个单元，部署简单，依赖少	业务简单、用户量小（如小型管理系统）	优点：部署快、性能好、运维简单；缺点：扩展性差、技术栈固定、修改影响全局
微服务架构	拆分独立服务（按业务功能），轻量级通信（HTTP/RPC），独立部署	高并发、业务复杂（如电商、社交）	优点：灵活性强（独立扩展）、技术多样、易维护；缺点：分布式复杂性（事务/服务治理）、运维成本高
管道-过滤器	数据流式传递，过滤器处理数据，管道传输，高内聚低耦合	数据处理（如编译器、日志分析）	优点：支持并发、易重用；缺点：不适合交互场景、数据格式转换开销大
仓库（数据仓储）	数据集中存储，工具通过仓库间接交互，无直接依赖	集成开发环境（IDE）、数据分析系统	优点：数据共享好、易扩展；缺点：并发差、对仓库依赖性强
解释器	定义规则语法，通过解释器执行，灵活度高	规则多变场景（如折扣计算、规则引擎）	优点：规则修改无需改代码、个性化强；缺点：实时执行效率低

质量属性效用树（6-12分，填空/匹配）

质量属性	核心关键词	题干匹配示例（文档高频）
性能	响应时间、吞吐量、并发量、分辨率/帧率	"0.3秒内响应""1024×768分辨率，40帧/秒""支持50个终端并发"
可用性	容错、故障恢复、重定向、热备份	"断电5秒内重定向备用站点""10秒内启动热备份""连续运行240小时"
安全性	攻击检测、加密、审计日志、权限控制	"检测恶意攻击""用户操作全程记录""密码加密传输""用户名唯一且符合格式"
可修改性	扩容时间、界面调整时间、模块扩展难度	"2人天内完成存储扩展""4人周内修改Web界面""支持新增消息中间件"

架构风险评估（ATAM/效用树，6-9分）

风险点 ：潜在隐患（如"养护报告业务逻辑未达成共识，影响可修改性"）
敏感点 ：影响单个质量属性的设计点（如"查询处理时间影响数据传输协议设计"）
权衡点 ：影响多个质量属性的设计点（如"更改加密级别同时影响安全性和性能"）

微服务vs单体架构（题干问"对比优缺点"直接写）

微服务架构定义：分布式架构，将应用拆分为小型独立服务，围绕业务功能构建，通过轻量级通信（如HTTP/RPC）交互；单体架构是将整个应用作为单一单元构建部署。
微服务优点 ：
1. 灵活性/可扩展性：单个服务独立部署扩展，系统弹性强；
2. 技术多样性：各服务可选不同技术栈（如用户服务用Java，推荐服务用Python）；
3. 易维护：服务小型化，代码易理解、开发维护成本低。
微服务缺点 ：
1. 复杂性：需处理分布式事务、服务发现、服务治理（如熔断、降级）；
2. 部署测试难：服务数量多，部署脚本、测试用例复杂度增加；
3. 运维成本高：需额外监控（如Prometheus）、日志收集（如ELK）、故障排查。

解释器vs面向对象架构（题干问"选哪种+对比"直接写）

选解释器架构 （适合"规则多变"场景，如折扣规则、用户筛选）：

维度	解释器架构	面向对象架构
规则可修改性	规则独立成语法，改规则不用改代码，灵活性强	需修改具体类（如新增折扣类），修改成本高
个性化灵活性	支持"千人千面"规则（如不同用户不同折扣）	固定对象逻辑，个性化需新增子类
性能	运行时动态解释，性能较差	编译后执行，性能好

结论：若需求强调"灵活性"（如题干"动态调整折扣"），选解释器；若强调"性能"，选面向对象。

质量属性效用树（6-12分，直接填对应关系）

质量属性	题干描述关键词	直接填的答案示例
性能	响应时间、吞吐量、并发量、分辨率/帧率	（c）0.3秒响应、（e）3秒确认支付、（h）1024×768分辨率
可用性	容错、恢复、重定向、热备份	（f）5秒重定向备用站点、（h）10秒启动热备份
安全性	攻击检测、加密、审计日志、权限	（b）检测恶意攻击、（j）记录用户操作日志
可修改性	扩容时间、界面调整、模块扩展	（g）2人天完成存储扩展、（k）4人天调整外观

架构风险/敏感点/权衡点（6-9分，直接匹配）

风险点 （潜在隐患）：题干中"未达成共识""可能矛盾 "→如"养护报告生成业务逻辑未达成共识，导致模块规则矛盾，影响可修改性"。
敏感点 （影响单个质量属性）：题干中"XX影响XX设计 "→如"查询处理时间要求影响数据传输协议和处理过程设计"。
权衡点 （影响多个质量属性）：题干中"改XX影响A和B"→如"更改系统加密级别会对安全性和性能产生影响"。

2.2 软件工程（UML建模，数据流图，需求建模） 25

递增背诵，包含重复内容不同形式

高频小题及分值

UML建模（用例图/序列图/类图）（6-12分）：填空或补充元素
数据流图（DFD）相关（8-9分）：补充外部实体/加工/数据流，数据平衡原则
需求建模（SysML需求图vs UML用例图）（6-9分）：定义、区别、关系识别

解题套路

UML建模：
- 用例图：参与者=用户/系统角色；用例=核心功能；关系（包含=必须执行；扩展=可选执行；泛化=特殊化）。
- 序列图：按"请求→处理→响应"时序补充对象和消息，重点抓"获取信息→处理→返回结果"流程。
DFD：数据平衡原则（父图与子图数据流一致；加工有入有出），外部实体=系统外交互对象，加工=核心功能，数据存储=文件/数据库。
需求建模：需求图偏"内部功能/流程"，用例图偏"用户交互"，按定义直接匹配题干描述。

UML建模（6-12分，填空/画图）

UML图类型	核心元素	解题套路
用例图	参与者（用户/系统）、用例（核心功能）、关系（包含/扩展/泛化）	参与者=题干中"XX角色"（如管理员、学生）；包含=必须执行（如"登录"包含于"注册课程"）；扩展=可选（如"补考"扩展"考试"）
序列图	对象、消息（同步/异步/返回）、时序（从上到下）	按"请求→处理→响应"补全：如"预约人员→预约界面：发起预约请求""数据库访问类→医生列表：获取医生信息"
类图	类、属性、方法、关系（关联/聚集/组合/泛化）	聚集=整体-部分（如"大学-学生"，生命周期独立）；组合=整体-部分（如"大学-院系"，生命周期一致）

数据流图（DFD，8-9分）

核心原则：数据平衡（父图与子图数据流一致；加工有入有出，无黑洞/奇迹）
高频填空 ：
- 外部实体：系统外交互对象（如"客户""厨房""供应商"）
- 加工：核心功能（如"订餐""备餐""生成报表"）
- 数据存储：文件/数据库（如"订单信息表""食材库存表"）

用例图（补充参与者+用例）

参与者：题干中"XX角色"→如**"管理员""学生""教师""打印机"**（设备也是参与者）。
用例关系 ：
- 包含（必须执行）："登录系统"包含于"注册课程""查询成绩"；
- 扩展（可选执行）："参加补考"扩展"参加考试"（只有考试不及格才触发）；
填空示例：若题干是"预约挂号系统"，参与者（1）=系统管理员，（2）=患者；用例（3）=注册登录，（4）=账号管理，（5）=预约挂号。

序列图（补充对象+消息）

对象：按"请求流转"→如"预约人员（患者）"→"预约界面"→"数据库访问类"→"医生列表"。
消息：按"发起请求→获取数据→返回结果"→如：
1. （2）=发起预约挂号请求；
2. （3）=显示医生出诊时段；
3. （4）=显示预约成功/失败。

数据流图（DFD，8-9分，填元素+写原则）

补充元素 （直接对应题干功能）：

元素类型	题干功能→答案示例
外部实体	与系统交互的人/设备→E1=客户，E2=厨房，E3=供应商
加工	核心功能→P1=订餐，P2=备餐，P3=生成报表
数据存储	存储文件→D1=订单信息表，D2=食材库存表

数据平衡原则 （直接写）：
1. 父图与子图平衡：子图边界数据流=父图对应加工的数据流（个数、方向一致）；
2. 子图内平衡：每个加工必须有入有出，无"黑洞"（有入无出）、"奇迹"（有出无入）。

2.3 Web系统（架构分层、协议选择、高并发方案） 25

高频小题及分值

架构分层设计（14分左右）：补充表现层/业务层/数据层组件
协议应用（HTTP/MQTT）（5-6分）：协议特点及场景匹配
高并发/高可用方案（4-6分）：CDN、负载均衡、缓存等

解题套路

架构分层：表现层=JSP/HTML/前端框架；业务层=Spring MVC/Servlet/Service；数据层=DAO/数据库/缓存，按"请求流转路径"补充组件。
协议选择：HTTP用于"客户端-服务端交互"（如Web页面、API）；MQTT用于"物联网设备通信"（如边缘设备、低带宽场景）。
高并发方案：高频关键词（CDN=静态资源加速；负载均衡=分流；缓存=Redis/MemCache；分布式文件系统=FastDFS），按场景直接套用。

架构分层设计（14分，直接填组件）

分层	题干场景→直接填的组件
表现层	Web页面、前端框架→（1）JSP，（2）HTML/CSS/JS
业务层	控制/服务→（3）Spring MVC，（4）Service，（5）Controller
数据层	缓存/数据库→（6）Redis，（7）MySQL，（8）DAO

实例：若题干是"智能门禁系统"，架构填空（7）=端侧识别模块，（8）=模型训练模块，（9）=设备调度平台模块，（10）=访客注册模块。

协议选择（5-6分，直接匹配场景）

场景	直接选的协议	理由（直接写）
Web页面请求、API调用	HTTP	支持客户端-服务端交互，适合Web场景
边缘设备、物联网通信	MQTT	轻量级、低带宽，支持发布/订阅，适合设备通信

填空示例 ：若题干架构图有"小程序前端→云平台"，填HTTP；"边缘设备→云平台"，填MQTT。

高并发方案（4-6分，直接写关键词+步骤）

问题场景	直接写的方案	实施步骤（直接填）
静态资源加载慢	CDN+分布式文件系统	（1）用CDN加速CSS/JS/图片；（2）用FastDFS存储静态文件
请求量大、分流	负载均衡（Nginx/LVS）	（1）部署Nginx集群；（2）配置轮询/IP哈希策略分流
数据库压力大	缓存（Redis）+读写分离	（1）Redis缓存热点数据（如商品信息）；（2）MySQL主库写、从库读

高频答案：题干"秒杀/限时促销"→方案=Redis预减库存+Kafka削峰+MySQL主从分离。

2.4 数据库（缓存问题，分布式锁，数据库设计） 25

高频小题及分值

缓存相关（Redis/MemCache）（7-10分）：数据类型、持久化、一致性方案
分布式锁/事务（6-9分）：MySQL/Redis分布式锁优缺点、死锁场景
数据库设计（反规范化/ER图）（6-8分）：反规范化方法、ER图实体/关系补充

解题套路

缓存问题：
- Redis数据类型：ZSet=排序（如热销排名）；Hash=对象存储；String=计数器。
- 一致性方案：读=先缓存后数据库；写=先数据库后缓存（更新/失效）。
- 持久化：RDB=备份/快速恢复；AOF=数据不丢失。
分布式锁：MySQL缺点=性能瓶颈/单点故障/一致性问题；Redis死锁=未设超时/释放失败，需加超时机制。
数据库设计：反规范化=增加冗余列/派生列（提高查询性能）；ER图实体=业务核心对象（如用户、订单），关系=关联类型（一对一/一对多）。

分布式锁与事务（6-9分）

MySQL分布式锁缺点：性能瓶颈、单点故障、锁粒度问题、数据一致性差、扩展性差（答对5项即满分）
Redis死锁场景：两客户端同时抢锁，一方超时未释放，另一方等待，交替阻塞（需说明"超时机制缺失""释放不及时"）

数据库设计（6-8分）

反规范化方法：增加冗余列（如"药品表加供应商名称"）、增加派生列（如"订单表加总金额"）、重新组表（合并多表减少关联）
ER图：实体=业务核心对象（如"用户""订单""商品"），关系=关联类型（如"用户-订单：一对多"）

缓存问题（7-10分，直接答Redis）
数据类型选择（填空）

业务场景	直接选的数据类型	理由（直接写）
热销商品排名、排行榜	ZSet	支持按分数排序，分数=销量/热度值
用户信息、商品详情	Hash	适合存储对象，字段=属性（如用户ID、姓名）
播放量、计数器	String	支持原子自增（INCR命令），适合计数

缓存一致性方案（直接写步骤）

读数据 （直接写）：
1. 先查Redis缓存，命中则返回；
2. 未命中则查MySQL数据库；
3. 将MySQL查询结果写入Redis（设置过期时间），返回结果。
写数据 （直接写）：
1. 先更新MySQL数据库；
2. 再更新Redis（或删除Redis对应Key，让下次读时自动更新）；
3. 避免"先更缓存再更数据库"（防止缓存更新成功、数据库更新失败导致不一致）。

缓存问题解决（直接写方案）

问题	直接写的解决方法
缓存穿透（查不存在的Key）	布隆过滤器（过滤不存在的Key）+缓存空值（设置短过期）
缓存雪崩（大量Key同时过期）	过期时间随机（如+/-10秒）+热点数据永不过期
缓存击穿（热点Key过期）	互斥锁（如Redis的SETNX命令）+热点数据永不过期

MySQL分布式锁缺点（直接写5点）

性能瓶颈：高并发下，锁请求/释放导致数据库CPU/IO升高；
单点故障：MySQL单点宕机，整个分布式锁失效；
锁粒度问题：锁粒度太大（如表锁）降低并发，太小（如行锁）增加冲突；
数据一致性：分布式环境中，MySQL节点同步延迟导致锁状态不一致；
扩展性差：扩容需分库分表，增加复杂度。

Redis死锁场景（直接写）

场景：两个客户端同时请求同一把锁，客户端A获取锁后执行超时（未设过期时间），客户端B一直等待；A执行完释放锁，B获取锁，A又请求锁，双方交替等待→死锁。
解决：给Redis锁设置超时时间（如EX 30），并加"看门狗"机制（超时前自动续期）。

反规范化方法（直接写+选方法）

常见方法 （直接写）：
1. 增加冗余列：在表中增加其他表的列（如药品表加"供应商名称"）；
2. 增加派生列：增加可计算的列（如订单表加"总金额=单价×数量"）；
3. 重新组表：合并多表为一个（如合并用户表和地址表）；
选方法：题干"查询商品需显示药品+供应商+库存"→选"增加冗余列"（药品表加供应商名称、当前库存）。

R图补充（直接填实体）

题干业务→实体答案：如"电商系统"→实体（1）=用户，（2）=商品，（3）=订单，（4）=供应商。

2.5 嵌入式 25

高频小题及分值

协议/架构（SOME/IP/DDS/FACE）（9分左右）：协议特点及场景
故障检测（心跳/超时探测）（8分）：原理及特点
实时系统特性（6-8分）：实时性、任务通信、可靠性

解题套路

协议应用：SOME/IP=车载外部设备通信；DDS=模块内部通信；FACE=宇航开放式架构。
故障检测：心跳=固定频率发信号，快速响应但易误判；超时探测=主动PING+响应，结果详细但周期长。
实时系统：核心关键词（时间敏感性、并发、可靠性、预测性），按定义匹配题干描述。

协议与架构（9分左右）

协议/架构	核心特点	适用场景
SOME/IP	应用层协议，基于TCP/UDP，支持SOA、RPC，高吞吐量	"车载外部设备通信""车辆ECU交互"
DDS	实时性高，适合模块内部通信	"框架模块内部通信""高实时性场景（如宇航设备）"
FACE架构	五层结构（操作系统、I/O服务、平台服务、传输服务、可移植组件），支持跨平台	"宇航嵌入式系统""开放式软件架构"

故障检测（8分）

检测技术	原理	特点
心跳检测	节点固定频率发"心跳"信号，超时未收到则判定失效	优点：快速响应；缺点：易误判（网络延迟）
超时探测	主动发送PING信号，等待ECHO响应，超时则判定失效	优点：结果详细（可附状态信息）；缺点：判断周期长

3、论文 75

基本原则:

不能口语化、每段不宜太长;
字数一般在 300+2200 左右，机试时有实时字数统计，多注意把握;
写正文时，不要生硬的回答问题，要根据问题要点组合成一篇通顺的文章;
论点分开论述，没必要全写编号。
要复用构件**(摘要+项目背景+结尾)**

3.1 软件架构-私有云（架构风格、架构评估，八大架构，云原生、微服务、安全架构）

摘要

2023年3月，我参与了公司私有云平台的升级项目，担任系统架构设计师，负责架构重构与核心模块设计。该项目总投入860w元，历时10个月，旨在解决原有单体架构扩展性不足、运维效率低的问题，支撑公司100+业务系统的稳定部署。本文结合项目实践，论述微服务架构在私有云平台中的应用，通过服务拆分、网关路由、容器化部署等技术，实现了资源弹性伸缩、故障隔离的目标。项目上线后运行稳定，资源利用率提升40%，获业务部门一致好评。

项目背景

随着公司业务扩张，原有私有云平台采用单体架构，存在三大痛点：一是业务耦合度高，单个模块升级需整体停机；二是资源分配僵化，无法根据业务峰值动态调整；三是故障影响范围大，局部问题易引发整体瘫痪。为解决这些问题，公司启动私有云平台升级项目，明确要求架构具备高可用、可扩展、易运维的特性。我作为架构设计师，主导微服务架构落地，核心需求包括服务拆分、统一调度、安全管控等，项目团队共25人，涵盖开发、测试、运维等角色。

正文
一、微服务架构设计原则与核心方案

微服务架构的核心是"分而治之"，结合项目需求，我们遵循四大设计原则：服务高内聚低耦合、接口标准化、故障隔离、独立部署。具体方案如下：

服务拆分：按业务域将原有单体拆分为6大核心微服务，包括资源调度服务、容器管理服务、权限管控服务、监控告警服务、日志分析服务、API网关服务。每个服务独立数据库，通过RESTful API通信，避免跨服务强依赖。
技术选型：采用Spring Cloud Alibaba作为微服务框架，Nacos实现服务注册与配置中心，Sentinel进行流量控制与熔断，Docker+Kubernetes实现容器化部署，统一管理服务实例。
网关路由：引入Spring Cloud Gateway作为API网关，集中处理请求路由、权限校验、限流熔断，屏蔽后端服务细节，简化客户端访问。

二、关键问题与解决方案

服务通信一致性问题：跨服务调用存在数据不一致风险，采用Seata实现分布式事务，通过TCC模式保证核心业务（如资源分配、权限变更）的数据一致性。
运维复杂度问题：微服务实例增多导致运维难度上升，开发自动化部署流水线（Jenkins+GitLab），实现代码提交、测试、部署全流程自动化，同时通过Prometheus+Grafana监控服务状态，告警响应时间缩短至5分钟内。
安全管控问题：私有云平台涉及敏感业务数据，通过OAuth2.0实现统一身份认证，API网关层增加接口签名校验，数据传输采用HTTPS加密，满足公司安全合规要求。

结尾

该私有云平台升级项目于2024年1月正式上线，至今稳定运行11个月，成功支撑了3次业务峰值（最高并发请求10万+/秒），未出现重大故障。通过微服务架构重构，不仅解决了原有架构的痛点，还为后续业务扩展预留了灵活空间。项目实施中也发现不足：部分服务拆分颗粒度偏粗，导致个别模块仍存在耦合。后续计划通过服务再拆分、引入服务网格（Istio）进一步优化架构。此次实践让我深刻体会到，微服务架构的落地需结合业务实际，平衡扩展性与运维成本，才能真正发挥其价值。

3.2 软件工程-AI测试（全生命周期，开发方法、开发模型，需求分析、设计、测试、运维）

摘要

2022年9月，我主导了公司AI接入测试平台的开发项目，担任技术负责人，负责项目全生命周期管理与测试方案设计。该项目投入520w元，历时8个月，旨在为公司内部AI接口提供自动化测试、性能评估、兼容性验证的一体化解决方案。本文围绕软件工程全生命周期，论述需求分析、设计、测试、运维各阶段的核心工作，重点阐述自动化测试框架的设计与实施。项目上线后，AI接口测试效率提升60%，测试覆盖率从75%提升至92%，有效保障了AI业务的稳定落地。

项目背景

公司近年大力推进AI技术落地，涉及图像识别、自然语言处理等10+类AI接口，但原有测试方式存在明显短板：人工测试效率低、回归测试成本高、性能瓶颈难以发现。为解决这些问题，公司启动AI接入测试平台项目，要求支持接口自动化测试、性能压测、多环境兼容性验证，同时具备测试报告自动生成、缺陷跟踪功能。我作为技术负责人，牵头项目团队（18人）完成从需求分析到运维交付的全流程工作，项目核心难点在于AI接口的多样性、高并发场景的性能测试设计。

正文
一、软件工程全生命周期核心工作

需求分析阶段：采用面向对象分析方法，通过用户访谈、场景梳理，明确核心需求，输出需求规格说明书。将需求划分为功能需求（自动化测试、性能测试等）、非功能需求（支持1000+接口并发测试、响应时间≤3秒）、设计约束（兼容HTTP/GRPC协议）三类，用UML用例图梳理用户交互场景。
设计阶段：架构采用分层设计模式，分为表现层（Web前端+API接口）、业务逻辑层（测试用例管理、测试任务调度等模块）、数据层（MySQL+Redis）。核心设计自动化测试框架，支持脚本录制、用例参数化、断言配置，兼容主流AI接口协议。
测试阶段：实施全流程测试策略，单元测试覆盖核心业务逻辑（覆盖率≥85%），集成测试验证模块间交互，系统测试重点验证功能完整性与性能指标。性能测试采用LoadRunner模拟高并发场景，发现并优化3处性能瓶颈（如数据库连接池不足、接口序列化效率低）。
运维阶段：部署Docker容器化环境，通过ELK栈收集日志，建立监控告警机制（针对测试任务失败、系统资源占用过高触发告警），同时提供用户反馈渠道，持续迭代优化功能。

二、关键技术与实施效果

核心技术为自动化测试框架，基于Python+Selenium开发，支持：①用例可视化编辑，非技术人员也可配置测试流程；②批量执行测试任务，支持定时调度；③自动生成测试报告，标注缺陷等级与复现步骤。实施后，AI接口回归测试时间从每天4小时缩短至1小时，缺陷发现周期提前，重大缺陷零遗漏。

结尾

该AI接入测试平台项目圆满交付后，已支撑公司20+AI业务系统的测试工作，显著降低了测试成本，提升了AI接口上线质量。项目实施过程中，也遇到需求变更频繁的问题，通过采用敏捷开发模式，每2周迭代一次，及时响应需求调整。后续计划扩展AI生成测试用例功能，进一步提升测试效率。此次项目让我深刻认识到，软件工程全生命周期管理的核心是"需求驱动、迭代优化、质量第一"，只有把控好每个阶段的关键节点，才能确保项目成功交付。

3.3 高项-代码治理（系统可靠性、安全性、容错技术，项目管理，企业应用集成、企业集成平台）

摘要

2023年6月，我参与了公司代码风险治理平台的建设项目，担任系统架构设计师，负责安全架构设计与企业应用集成方案落地。该项目总投入780w元，历时12个月，旨在整合公司代码管理、漏洞扫描、权限管控等系统，实现代码全生命周期的风险检测与治理。本文论述系统安全性设计与企业应用集成技术的应用，通过身份认证、数据加密、跨系统接口集成等手段，构建安全可靠的集成平台。项目上线后，代码漏洞检出率提升55%，跨系统数据交互效率提升40%，满足公司安全合规与高效协同需求。

项目背景

公司原有代码管理相关系统分散（包括GitLab代码仓库、自研漏洞扫描工具、第三方安全审计系统），存在三大问题：一是数据孤岛，各系统数据不互通，无法形成完整的风险治理链路；二是安全性不足，代码传输与存储存在泄露风险，权限管控粒度粗；三是操作繁琐，开发人员需在多个系统间切换，效率低下。为解决这些问题，公司启动代码风险治理平台项目，核心需求包括：整合多系统数据、实现代码风险全流程检测、强化安全管控、简化操作流程。我作为架构设计师，主导安全架构与集成方案设计，项目团队涵盖开发、安全、运维等22名成员。

正文
一、系统安全性设计方案

身份认证与权限管控：采用RBAC（基于角色的访问控制）模型，整合公司统一身份认证系统（SSO），实现单点登录，避免多系统重复登录。权限细分为系统级、模块级、操作级，根据用户角色自动分配权限，关键操作（如漏洞修复审批）需多人复核。
数据安全防护：代码数据传输采用SSH加密，存储采用AES-256加密，敏感信息（如漏洞详情）脱敏展示。建立数据备份机制，每日全量备份+实时增量备份，备份数据异地存储，保障数据可靠性。
风险检测与防护：集成静态代码扫描工具（SonarQube）与动态漏洞扫描工具，实现代码提交、编译、部署全流程风险检测，支持漏洞分级（高、中、低）告警与自动推送修复建议，高风险漏洞阻断上线流程。

二、企业应用集成实施

采用面向服务的架构（SOA）实现跨系统集成，核心方案如下：

接口集成：通过ESB（企业服务总线）封装各系统接口，统一接口协议（RESTful）与数据格式（JSON），实现GitLab代码仓库、漏洞扫描工具、安全审计系统的数据互通。例如，代码提交后，GitLab通过WebHook触发ESB接口，同步代码信息至风险治理平台，自动启动静态扫描。
数据集成：采用ETL工具（DataX）抽取各系统数据，清洗转换后存储至数据仓库，构建统一的风险治理数据模型，支持风险统计分析与可视化展示（如漏洞趋势图、部门风险排名）。
流程集成：通过工作流引擎（Activiti）整合跨系统流程，例如漏洞修复流程：风险治理平台检出漏洞→自动推送至开发人员→开发人员修复后提交审核→安全人员复核→漏洞闭环，全流程线上化，可追溯。

结尾

该代码风险治理平台项目于2024年6月上线，至今运行稳定，已累计检测代码风险1200+个，修复率达98%，有效降低了公司代码安全风险。项目实施中，遇到跨系统接口兼容性问题，通过制定统一的接口规范、开发适配适配器，成功解决了集成难题。后续计划引入AI辅助漏洞修复功能，进一步提升风险治理效率。此次实践让我认识到，系统安全性与企业应用集成是大型项目的核心，只有将安全设计贯穿全流程，采用标准化的集成技术，才能实现系统的高效协同与安全可靠。