软考——高级系统架构设计师

体系结构

在计算机流水线中，若一条指令分为取指、译码、执行、访存、写回5个阶段，每个阶段耗时1ns，不考虑冲突，则执行10条指令所需时间为： $T=( 10+5-1)*1=14ns$

单条指令耗时：5阶段 × 1ns = 5ns

流水线执行 n 条指令总时间公式： $T=(k+n−1)×Δt$ ，k是阶段数，Δt是阶段耗时，n是指令数

数据库

事务隔离级别中，能够防止不可重复读，但不能防止幻读的是：Repeatable Read

隔离级别	脏读	不可重复读	幻读	说明
Read Uncommitted （读未提交）	✅	✅	✅	最低级别，性能最高但数据一致性最差
Read Committed （读已提交）	❌	✅	✅	大多数数据库默认级别（如 Oracle）
Repeatable Read （可重复读）	❌	❌	✅标准SQL ❌MySQL、InnoDB	MySQL 默认级别
Serializable （串行化）	❌	❌	❌	最高级别，事务串行执行性能最差

MySQL中，实现可重复读隔离级别时，InnoDB通过 临键锁（Next-Key Lock） 防止幻读

临键锁（Next-Key Lock） = 行锁（Record Lock） + 间隙锁（Gap Lock）
锁住记录本身 + 索引之间的间隙，防止插入新记录造成幻读

在MySQL的InnoDB存储引擎中，用于实现多版本并发控制（MVCC）的关键机制是：undo log + 事务版本号

HBase 是基于 Hadoop 的 列式数据库

MySQL 查看事务隔离级别命令：SELECT @@transaction_isolation

网络

HTTPS协议中，用于加密传输数据的是：AES

非对称加密（如 RSA、ECDHE）→ 用于安全协商会话密钥
对称加密（如 AES）→ 用于加密实际传输的数据
哈希算法（如 SHA-256）→ 用于完整性校验
DH/ECDH → 密钥交换协议

软件架构

在 ATAM 方法中：

敏感点：一个小的架构决策变化可能显著影响某个质量属性。如：增加缓存 → 显著提升性能
风险点：已存在的设计缺陷，可能导致失败
权衡点：提升一个属性会牺牲另一个（如性能 vs 安全）
架构决策：是动作，不是ATAM术语

在基于架构的软件设计（ABSD）方法中，使用架构风格和模式来实现质量属性需求属于哪个阶段？架构设计

在架构文档中，4+1视图模型不包括哪个视图？数据视图

设计模式

安全

下列哪种技术可用于防止CSRF攻击？Anti-CSRF Token

HTTPS：防窃听，不防伪造请求
HttpOnly Cookie：防 XSS 读取 Cookie，不防 CSRF
Anti-CSRF Token：服务器生成 token，前端提交，验证来源
CORS：控制跨域资源访问，不是防 CSRF 的主要手段

网络攻击类型

类型	特点	示例
被动攻击	不修改数据，仅监听	窃听、流量分析
主动攻击	修改、伪造、中断数据	DoS（耗尽资源）、MITM（篡改通信）、重放、篡改

OAuth2 核心端点：

/authorize：用户授权，返回授权码（code）
/token：客户端用授权码换取 access_token
/userinfo：获取用户信息
/logout：非标准端点

中间人攻击（MITM）：攻击者在通信双方之间截获并可能篡改数据。

DNS欺骗：将域名解析到攻击者IP，是典型MITM手段
SQL注入：注入恶意SQL
XSS：跨站脚本，非中间人
文件上传：上传恶意文件

云计算

K8s 控制器用途

Deployment：管理无状态应用，支持滚动更新、扩缩容
StatefulSet：管理有状态应用，如数据库，每个实例有唯一的标识符
DaemonSet：在每个节点运行一个副本，如日志收集、监控代理
Job：运行完成后自动删除，如批量处理任务（一次性任务）
CronJob：定时运行任务，如备份、数据同步

Pod：最小运行单元
Service：用于暴露服务，支持 ClusterIP、NodePort、LoadBalancer
Deployment：管理Pod副本
ConfigMap：配置管理

软件工程

在Scrum框架中，负责“移除团队开发障碍”的角色是：Scrum Master（清除障碍、保障流程、促进团队协作）

在CMMI模型中，哪个级别开始引入“量化管理”？4级

2级：已管理级（项目级过程跟踪）
3级：已定义级（组织级标准过程）
4级：量化管理级（用数据量化过程性能）
5级：优化级（持续改进）

操作系统

下列调度算法中，可能导致饥饿现象的是 SJF

FCFS：先到先服务，不会饿死
RR：时间片轮转，公平
SJF：长作业可能一直被短作业插队
多级反馈队列：长任务可能被降级，但通常有老化机制防饿

在虚拟内存管理中，LRU页面置换算法的中文含义是：最近最少使用

FIFO：先进先出 First In First Out
LRU：最近最少使用 Least Recently Used
OPT：最佳置换 Optimistic
Clock：时钟算法，基于时间的替换策略

系统性能

某系统每秒处理1000个请求，平均响应时间为0.2秒，则其并发用户数约为：

并发用户数=吞吐量×平均响应时间=1000×0.2=200

新兴技术

在边缘计算（将数据处理从中心云下放到靠近数据源的边缘设备或边缘服务器）架构中，数据处理主要发生在：接近数据源的边缘节点

中心云数据中心：传统云计算
用户终端设备：端计算，资源有限
企业内网服务器：可能是私有云，不一定是边缘

在服务网格（Service Mesh）架构中，负责处理服务间通信的组件是：数据平面（Data Plane，如Sidecar代理）

控制平面：配置管理、策略下发
数据平面：实际处理服务间通信：负载均衡、熔断、加密、监控

在Lambda架构中，用于处理实时数据流的组件是：速度层

批处理层：处理全量历史数据，延迟高，精度高
速度层：处理实时数据流，低延迟，用于快速响应
服务层：合并批处理和速度层结果，对外提供查询

Serverless架构分类

FaaS：函数即服务，如 AWS Lambda、阿里云函数计算
BaaS：后端即服务，如 Firebase（数据库、认证）
IaaS：EC2
PaaS：Heroku

法律法规

根据《个人信息保护法》，处理敏感个人信息的前提是：取得个人的单独同意

根据《计算机软件保护条例》，软件著作权的保护期限为：50年

根据《信息安全等级保护管理办法》，各级信息系统应当至少多久进行一次等级测评

二级系统：建议两年一次
三级系统：每年至少一次等级测评
四级系统：每半年一次

案例分析

单体架构

某电商平台计划重构其单体架构系统。当前系统存在以下问题：
发布一次需停机2小时，影响用户购物
某个模块（如订单）性能瓶颈导致整体响应慢
团队协作困难，多人修改同一代码库易冲突
公司考虑采用 SOA 或微服务架构，请回答以下问题：
请说明 SOA 与微服务架构的主要区别（至少3点）。（6分）
针对上述问题，你建议采用哪种架构？并说明理由。（4分）
若采用微服务，如何保障服务间的数据一致性？请给出两种方案。（5分）

对比维度	SOA	微服务
服务粒度	粗粒度如订单服务、客户服务	细粒度如订单创建服务、订单支付服务
通信方式	常用 ESB（企业服务总线）中心化路由	去中心化常用 REST API 或轻量级消息（如 Kafka）
数据管理	多服务共享数据库	每个服务拥有独立数据库，避免共享
部署方式	通常集中部署在 ESB 容器中	独立部署，可使用 Docker + Kubernetes
团队组织	职能型团队（前端、后端）	全栈型小团队（一个团队负责一个服务）

建议采用微服务架构，理由如下：

解决发布停机问题：各服务独立部署，局部更新无需整体停机，支持灰度发布和滚动升级。
解决性能瓶颈问题：可通过横向扩展（scale-out）对高负载服务（如订单）单独扩容，而不影响其他服务。
改善团队协作：每个服务由独立团队负责，代码库分离，降低冲突，提升开发效率。

保障数据一致性

最终一致性 + 消息队列
TCC（Try-Confirm-Cancel）模式
- 分布式事务补偿机制：
  - Try：预留资源（如冻结库存）
  - Confirm：确认执行（扣减库存）
  - Cancel：取消操作（释放库存）
- 适用于高一致性场景（如支付）
Saga 模式
Seata 等分布式事务框架
- 在Seata框架中，AT模式实现分布式事务依赖于：全局事务ID + 每个分支事务的undo_log回滚日志（单独补充）

数据库分库分表

某电商平台原采用单体架构，数据库为 MySQL 单实例。随着业务增长，订单表（order_info）数据量已达 5000万条，主要问题如下：
订单查询响应时间从 200ms 上升到 2s 以上（尤其是按用户查询）；
大促期间数据库 CPU 使用率持续超过 90%，出现连接池耗尽；
单表数据增长迅速，预计半年后将突破 1 亿条，影响备份与维护。
公司决定对订单系统进行重构，采用分库分表方案提升性能和可扩展性。
请说明水平分表与垂直分表的区别，并结合本案例说明应优先采用哪种方式？（6分）
若采用水平分库分表，请给出一种合理的分片键设计方案，并说明理由。（5分）
分库分表后可能会带来哪些新的技术挑战（至少3项）？并简要说明应对策略。（9分）

本案例应优先采用水平分表，理由如下：
- 问题根源是数据量过大（5000万+）导致查询慢和性能瓶颈，属于典型的大表问题；
- 订单表字段相对固定，无明显冷热列分离需求，不适合垂直拆分；
- 水平分表可显著降低单表数据量，提升查询性能和并发能力。
- 水平分表：将同一张表的行数据按某种规则（如用户ID取模）分布到多个物理表中，每张表结构相同，数据不同
- 垂直分表：将一张表的列拆分到多个表中，通常将热点字段与冷数据分离（如主表保留核心字段，扩展表存详情）
建议以 user_id 为分片键，采用取模或一致性哈希策略。因用户查询是主要场景，可保证查询定位到单一分片，且数据分布均匀
以下这些技术挑战以及解决策略：
- 跨库分页查询：可通过应用层合并结果，或使用ES辅助查询
- 分布式事务：采用TCC模式或可靠消息最终一致性
- 全局ID生成：使用雪花算法生成不重复的订单ID
- 运维复杂度上升：引入数据库中间件

质量属性场景建模

某在线教育平台计划升级其直播系统，当前系统在高并发场景下存在以下问题：
大型公开课直播时，用户进入直播间延迟超过10秒
网络波动时，视频卡顿、音画不同步现象严重
系统日志显示，服务器CPU使用率经常达到100%，部分请求超时
运维反馈，扩容一台服务器需手动配置2小时，无法快速响应流量高峰
平台希望新架构能支持10万级并发用户，并提升系统稳定性。
请指出上述描述中涉及的4个质量属性，并分别对应到具体问题（8分）
针对用户进入直播间延迟高问题，请提出两种可行的架构优化方案并简要说明原理。（6分）
扩容需手动配置2小时反映了哪个质量属性不足？如何通过DevOps实践改进该问题。（6分）

涉及的质量属性包括：
- 性能：用户进入延迟高、CPU满载
- 可用性：网络波动时视频卡顿
- 可修改性：扩容需手动配置，变更成本高
- 可伸缩性：无法快速应对流量高峰
优化方案：
- 引入CDN，将直播流分发至边缘节点，降低接入延迟
- 使用Nginx负载均衡 + 微服务架构，支持水平扩展
该问题反映可修改性不足。可通过：
- Docker容器化服务
- Kubernetes实现自动扩缩容
- Jenkins构建CI/CD流水线，实现一键部署

质量属性	判断关键词	典型优化方案
性能	响应慢、延迟高、CPU高	缓存、异步、CDN、负载均衡
可用性	崩溃、卡顿、不可用	主从、集群、熔断、降级
可修改性	手动配置、发布慢	容器化、CI/CD、IaC
安全性	被攻击、数据泄露	防火墙、JWT、权限控制
可测试性	难以自动化测试	单元测试、Mock、微服务拆分
可伸缩性	无法扩容、并发低	水平扩展、K8s、消息队列

ATAM + 安全架构设计

某金融公司正在设计新一代移动支付平台，要求支持高并发、高安全、快速迭代。架构团队提出了基于微服务 + API网关 + OAuth2认证的架构方案。
在ATAM评估会议中，利益相关者提出了以下质量属性场景：
在双十一大促期间，系统应能支持每秒处理5万笔交易，平均响应时间不超过 200ms
即使某省数据中心发生故障，系统仍应继续提供服务，允许用户完成支付
第三方应用接入支付接口时，必须通过身份认证和权限审批，防止未授权访问
当订单服务不可用时，前端应能返回缓存结果或友好提示，避免页面崩溃
架构师初步设计如下：
使用 Spring Cloud 微服务架构
API网关统一入口，集成限流、鉴权
用户认证采用 OAuth2 + JWT
Redis 缓存热点数据
数据库主从复制 + 读写分离
部署在两地三中心云环境
回答以下问题
请将上述 4 个质量属性场景，分别对应到具体的质量属性（8分）
针对场景3，请说明 OAuth2 的核心角色有哪些？并简述其在本系统中的工作流程。（6分）
在ATAM评估中，常需识别风险点、敏感点和权衡点。请从上述架构中各举一例。（6分）
场景4体现了哪种设计思想？请说明 Redis 缓存在此场景中的作用与可能风险。（5分）

性能、可用性、安全性、可用性
OAuth2 的核心角色有：
- 资源所有者：客户或终端用户
- 客户端：app或者网页
- 授权服务器：负责验证客户身份，发放访问令牌
- 资源服务器：负责处理资源请求，返回结果
工作流程：
- 第三方应用引导用户跳转到授权服务器登录
- 用户同意授权后，授权服务器返回授权码
- 第三方应用用授权码向授权服务器换取访问令牌（Access Token）
- 第三方应用携带 Token 访问资源服务器（支付接口），资源服务器校验 Token 合法性后返回结果
风险点：若 Redis 缓存宕机，未设计降级策略，可能导致数据库雪崩
敏感点： API网关的限流阈值设置，直接影响系统性能和可用性
权衡点：启用 JWT 可提升性能（无状态），但一旦签发无法主动撤销，影响安全性
设计思想：容错设计或降级策略
Redis 缓存的作用：
- 提供兜底数据，保证用户仍能看到历史订单或提示信息
- 减轻后端服务压力，防止故障扩散
可能风险：
- 缓存雪崩：大量缓存同时失效，请求压向数据库
- 缓存穿透：恶意查询不存在的数据，绕过缓存
- 数据不一致：缓存与数据库不同步

微服务架构

请说明在微服务架构中，服务发现和配置中心各自的作用，并指出Spring Cloud中实现这两个功能的典型组件。

服务发现：实现服务的自动注册与发现，支持动态伸缩和负载均衡（如 Eureka、Nacos）
配置中心：集中管理微服务配置，支持环境隔离与热更新（如 Spring Cloud Config、Nacos Config）

请分析该系统中引入RabbitMQ带来的好处，并说明在“订单创建”与“库存扣减”场景中可能存在的问题及应对策略。

好处：解耦、异步、削峰、提高响应速度
问题：消息丢失、重复消费、库存超卖、事务不一致
策略：消息持久化、消费幂等、分布式事务、库存预扣+确认机制

为保障患者隐私数据的安全，除OAuth 2.0外，还应采取哪些安全措施？请从数据传输、数据存储、访问控制三个层面各列举一项措施。

数据传输：使用 HTTPS/TLS 加密
数据存储：敏感字段加密存储（如患者身份证、病历），使用 AES 或国密算法
访问控制：基于角色的访问控制（RBAC）、最小权限原则、审计日志

若该系统需与医保系统对接，可能采用哪些集成方式？请说明其适用场景和优缺点。

集成方式：
- API对接：通过 REST/HTTP 调用医保系统接口（最常见）
- WebService：适用于跨平台、跨系统（如政务系统常用）
- 消息中间件：异步集成，如 Kafka、RabbitMQ（适合高并发）
- ESB企业服务总线：统一集成平台，适合多系统对接
适用场景：
- 实时查询：用 API 或 WebService
- 异步上报：用消息队列
- 多系统协同：用 ESB

Hystrix实现熔断的三个状态是什么？请描述其转换机制

状态

Closed（关闭）：正常调用服务，记录失败率
Open（打开）：失败率超过阈值，停止调用，直接走降级逻辑
Half-Open（半开）：等待一段时间后，放行少量请求试探服务是否恢复

转换机制：

Closed → Open：失败率 > 阈值（如 50%）
Open → Half-Open：达到超时时间（如 5s）
Half-Open → Closed：试探请求成功
Half-Open → Open：试探请求失败

请说明Flink在该系统中的作用，并解释其与Storm、Spark Streaming的主要区别

Flink作用：实现低延迟、高吞吐的流式处理，支持事件时间（event time）、状态管理、精确一次（exactly-once）语义，适用于拥堵识别、异常检测等实时分析。
对比：
- Storm：纯流式，延迟最低，但无内置状态容错，开发复杂
- Spark Streaming：微批处理（micro-batch），延迟较高（秒级），适合准实时
- Flink：真正流式处理，毫秒级延迟，支持状态恢复和精确一次语义，更适合本系统

SkyWalking如何帮助提升系统的可观测性？请说明其核心功能

SkyWalking做分布式链路追踪，方便排查问题

调用链追踪：展示请求经过的微服务路径
性能监控：响应时间、QPS、错误率
服务拓扑图：可视化服务依赖关系
告警机制：异常自动通知

K8s的HPA（Horizontal Pod Autoscaler）依据哪些指标进行扩缩容？请列举至少三种，并说明其适用场景

HPA是基于Pod的资源使用指标进行扩缩容

CPU利用率（最常用，如 >80% 扩容）
内存使用率
自定义指标（如QPS、请求延迟，通过Prometheus+Adapter提供）

为何需要引入分布式事务？Seata的AT模式如何保证多服务间的数据一致性？

引入分布式事务确保一致性

一阶段：本地事务提交，记录before/after image到undo_log
二阶段成功：删除undo_log
二阶段失败：根据image反向生成SQL回滚
全局事务ID协调所有分支事务

全链路压测在系统高可用保障中起什么作用？应如何设计压测方案？

验证系统容量、发现瓶颈、验证容灾

流量构造：基于真实流量录制回放
环境隔离：影子库、影子表，避免影响生产数据
监控指标：TPS、RT、错误率、资源使用
渐进加压：从50% → 100% → 120%逐步加压

OpenTelemetry如何帮助定位性能瓶颈？请说明其核心组件与工作流程。

OpenTelemetry通过SDK在服务中注入探针，采集Span（调用链）、Metrics（指标）、Logs（日志），通过Collector汇总，帮助定位慢接口、高延迟服务、异常调用路径。

软考——高级系统架构设计师 ​

体系结构 ​

数据库 ​

网络 ​

软件架构 ​

设计模式 ​

安全 ​

云计算 ​

软件工程 ​

操作系统 ​

系统性能 ​

新兴技术 ​

法律法规 ​

案例分析 ​

单体架构 ​

数据库分库分表 ​

质量属性场景建模 ​

ATAM + 安全架构设计 ​

微服务架构 ​