模拟试题I 下午案例分析
软考系统架构设计师 | 模拟题 I 案例 形式:5 道案例题,每题 25 分,共 75 分 及格线:45 分 考试时间:与上午共用 150 分钟 必答:5 道全答(无选答)
试题一:数据架构与消息处理系统设计(25 分)
背景
某互联网公司拟开发用户通信软件系统,向用户提供即时通信服务。核心功能是做好消息内容识别与内容防护,防止恶意用户利用该软件进行非法内容传输:
- 对于正常消息:采用消息封装、正常转发等处理
- 对于一般有害的辱骂、恐吓消息:进行改写处理
- 对于重大危害消息:过滤处理并对用户封号
需求与质量属性(a~k 共 11 项),摘录如下:
| 编号 | 描述 |
|---|---|
| (a) | 管理员后台对用户封号/解封,设置后即可生效 |
| (b) | 完整的安全防护措施,支持恶意攻击行为检测与报警 |
| (c) | 正常负载下 0.3 秒内响应用户发送消息请求 |
| (d) | 消息体以汉字、英文字母、数字、标点为主,不超过 1024 字节 |
| (e) | 正常负载下,发送新消息后 1 秒内对方收到 |
| (f) | 主服务异常中断后 5 秒内重定向到备用服务 |
| (g) | 支持横向用户/消息存储扩展,2 人·天内完成扩展与测试 |
| (h) | 宕机后 10 秒内感知错误,自动启动热备份系统 |
| (i) | 对内提供接口函数,支持信息收集、功能调试、系统诊断 |
| (j) | 所有用户消息备份至少 7 天 |
| (k) | 聊天软件外观调整 4 人·天内完成 |
公司提出两种候选架构方案:李工(黑板系统风格)+ 王工(管道-过滤器风格),最终采用二者结合。
问题 1(12 分)
在架构评估过程中,质量属性效用树(Utility Tree)是对系统质量属性进行识别和优先级排序的重要工具。请将合适的质量属性名称填入图 1.1 中(1)、(2)空白处,并选择题干描述的(a)(k)填入(3)(6)空白处,完成该系统的效用树。
效用树结构示意:
| |
参考答案:
- (1)安全性
- (2)可修改性
- (3)(e)— 1 秒内对方收到(性能)
- (4)(j)— 消息备份 7 天(可修改性)
- (5)(h)— 10 秒内自动启动热备(可用性)
- (6)(k)— 4 人·天外观调整(可修改性)
问题 2(13 分)
针对该系统的有害信息过滤功能,李工建议采用黑板系统风格,王工认为李工的方案存在问题(即负责消息封装、正常转发的构件需要等待其他有害消息处理构件处理之后才能开始工作),提出采用管道-过滤器风格。 请针对王工和李工的方案,分析和对比黑板系统风格和管道-过滤器风格的各自优缺点,并说明如何综合两种风格,来更好地实现软件功能。
参考答案:
1)黑板风格。
- 优点:可用于非确定性问题求解,启发式解决过程;可维护性好;可重用性好。
- 缺点:不能确保期望结果,效率低下;回退;不支持并行;共享空间的访问需要同步。
2)管道-过滤器风格。
- 优点:简单性;支持复用;系统具有可扩展性;系统并发性(每个过滤器可以独立运行,不同子任务可以并行执行,提高效率)。
- 缺点:不适合用来设计交互式应用系统。
3)综合方式:在内容识别、有害信息处理的构件之间采用黑板风格;对于可转发的消息可以采用管道-过滤器风格,交给后续的消息封装、正常转发的构件。取长补短。
试题二:互联网商品交易平台架构设计(25 分)
背景
某互联网公司欲建设商品交易平台,平台邀请大牌商户入驻,后期承担较大全国用户请求流量与较高并发用户数。
性能需求:
- 平台承担较大全国用户请求流量与高并发用户数(最重要)
- 重要节日有秒杀促销活动,要承担流量尖峰,保证较低访问延时
- 平台需要达到一定的可用性
- 涉及金融支付领域,对订单及支付数据存储有较高的安全性、可靠性要求
方案对比:
| 角色 | 接入层 | 应用层 | 存储层 |
|---|---|---|---|
| 王工 | Nginx(7 层负载均衡) | SOA 整合可复用网络服务 | 传统 Oracle |
| 李工 | LVS(4 层负载均衡) | 微服务架构 | MySQL 主从 + 分库分表 + 读写分离 |
| 张工(补充) | 在全国设立 4 个机房分别部署一套平台服务 |
问题 1(10 分)
请用 200 字以内的文字简述王工的 SOA 方案和李工的微服务方案的不同点,根据该项目应该选择哪个方案?
参考答案:
SOA 与微服务的不同点:
- SOA 设计思路是把组件和服务通过服务总线组装成更大的应用(从小到大);微服务是把应用拆分成独立自治的小服务(从大到小)
- SOA 依赖基于 XML 的消息格式和基于 SOAP 的通信协议;微服务大量依赖 REST 和 JSON
- SOA 需要 ESB 总线负责服务间通信转发和接口适配;微服务强调更轻量级、更迅速、去中心化
- SOA 强调分层(展现/业务/总线/数据);微服务的服务更松散,更容易扩展
- SOA 中的服务不强调业务领域的自治性;微服务强调基于领域的服务自治性
选择:由于该平台业务规模体量较大,考虑到微服务的伸缩性、去中心化和自治性,采用李工的方案更容易提升性能,并能更好地适应研发团队的解耦。
问题 2(10 分)
经深入讨论公司支持了李工的方案,请阐述针对存储层采用 MySQL 来进行分库分表、主从结构的设计的原因。
参考答案:
- 采用 MySQL 开源组件本身可降低成本
- 两个 MySQL 设计成主从模式可提高平台要求的可用性:主节点异常,从节点可代替主节点继续提供服务
- 以主从模式为基础设计多套 MySQL 主从实现分库分表,每个节点平摊数据存储量,进一步提升总体性能和系统容量
问题 3(5 分)
公司也同时认可了张工补充的开设多个机房方案,但该方案需要依赖其他技术,请简述其中一种关键性技术,并说明其作用。
参考答案:
- DNS 解析:根据用户的 IP 解析到距离用户最近的机房,减少用户访问平台的时延和拥挤程度
试题三:服务型智能扫地机器人架构设计(25 分)
背景
服务型智能扫地机器人需要自主运动规划和导航功能,通过环境信息融合感知进行行为决策。
主要功能(8 项):
- 紧急状态感知:碰撞检测、跌落检测、离地检测
- 姿态感知:运动里程计数、航向测量
- 视觉感知:单目视觉避障系统、单目视觉定位系统(可结合红外测距)
- 自动充电:实时监控电量,低于阈值时自动返回充电
- 扫地及吸尘单元:电机控制刷子清扫 + 抽灰电机吸尘
- 运动执行:控制机器人运动
- 监控系统:无线网络传递状态/视频,PC + 手机客户端
- 信息处理中心:接收传感器和视觉信息,分析处理后控制运动,与后台通信
硬件采用 ARM+STM32 双核架构:
- STM32F103VET6:实现非图像以外的众多传感器的驱动及数据采集,控制车轮电机
- ARM S5PV210:摄像头图片采集、接入无线网络、综合处理 STM32 串口传过来的传感器数据 + 图像定位避障信息,生成运动决策发送给 STM32
问题 1(15 分)
图 3.1 是本题的服务型智能扫地机器人典型的功能结构图,请根据说明的描述,完成该功能结构图,将(1)~(5)的内容填在答题纸上相应的位置中。
参考答案:
- (1)紧急状态感知
- (2)跌落检测
- (3)航向测量
- (4)单目视觉避障系统
- (5)扫地及吸尘单元
问题 2(6 分)
请根据下表 3.1 中各传感器的功能描述,将(1)~(6)填入相应的位置。
| 序号 | 传感器类别 | 功能 | 参数 |
|---|---|---|---|
| 1 | (1) | 用于障碍物规避 | 输出模拟电压量 |
| 2 | (2) | 平台防跌落 | 输出数字量 |
| 3 | (3) | 车身离地检测 | 输出数字量 |
| 4 | (4) | 碰撞检测 | 输出数字量 |
| 5 | (5) | 检测航向角度 | 检测角度 ±180° |
| 6 | (6) | 测速和计里程 | 脉冲输出 |
| 7 | USB 摄像头 | 采集环境图像信息 | YUV 和 MJPG 格式 |
参考答案:
- (1)红外测距传感器
- (2)数字式防跌落传感器
- (3)开关式传感器
- (4)槽型光耦模块
- (5)GGPM01A 单轴角度陀螺仪
- (6)霍尔码盘传感器
问题 3(4 分)
硬件采用 ARM+STM32 双核架构,串口传输数据格式:8 位数据位 + 1 位起始位 + 1 位停止位,无校验位。 (1)当波特率为 9600b/s 时,每秒钟传送的有效数据是多少字节? (2)为保证数据收发正确(每个字节数据传输中的累计误差不大于 1/4 bit),分析发送方和接收方时钟允许的误差范围,并以百分比形式给出最大误差。
参考答案:
(1)有效数据计算:
- 9600 ÷ (8 + 1 + 1) = 960 字节/秒
(2)最大误差:
- 每个字节数据含 8+1+1 = 10 bit
- 每个 bit 的最大误差为 (1/4) ÷ 10 = 0.025
- 所以最大误差为 0.025 × 100% = 2.5%
试题四:分布式数据库与 NoSQL 方案(25 分)
背景
某软件企业开发了一套新闻社交类软件(新闻发布、用户关注、用户推荐、新闻点评、新闻推荐、热点新闻等),采用 MySQL 存储业务数据。系统上线后用户量增加,数据库服务器压力不断加大。
工作组的方案:
| 角色 | 方案 | 优缺点 |
|---|---|---|
| 张工 | MySQL 读写分离 + 主从复制 | 程序改动小、较快完成、后续可扩展到 MySQL 集群 |
| 李工 | 用 NoSQL 完全替代 MySQL | 工作量太大,短期无法完成 |
| 刘工 | Key-Value + MySQL 混合方案 | 综合二者优点 |
最终采用刘工方案(见张工方案的图 4.1)。
问题 1(8 分)
张工方案中采用了读写分离、主从复制策略。简述主从复制给系统带来的好处。
参考答案:
- 避免数据库单点故障:主服务器实时、异步复制数据到从服务器,当主数据库宕机时,可从从数据库中选择一个升级为主服务器
- 提高查询效率:主库进行数据插入、删除及更新等写操作,从库专门用来进行数据查询操作,将查询操作分担到不同的从服务器以提高数据库访问效率
问题 2(8 分)
MySQL 数据库中,主从复制通过 binary log 来实现主从服务器的数据同步。请简述主从复制的过程。
参考答案: 当在从库上启动复制时:
- 首先创建 I/O 线程连接主库
- 主库随后创建 Binlog Dump 线程读取数据库事件并发送给 I/O 线程
- I/O 线程获取到事件数据后更新到从库的中继日志 Relay Log 中去
- 之后从库上的 SQL 线程读取中继日志 Relay Log 中更新的数据库事件并应用
问题 3(9 分)
主从复制可以采用同步、异步、半同步复制。请简述每种复制技术的特点。
参考答案:
1)同步复制:主数据库需要等待所有备数据库均操作成功才可以响应用户,影响用户体验。这种方式保证了系统的一致性,但牺牲了数据的可用性。
2)异步复制:当用户请求更新数据时,主数据库处理完请求后可直接给用户响应,而不必等待备数据库完成同步,备数据库会异步进行数据的同步,用户的更新操作不会因为备数据库未完成数据同步而导致阻塞。这种方式保证了系统的可用性,但牺牲了数据的一致性。
3)半同步复制:用户发出写请求后,主数据库会执行写操作,并给备数据库发送同步请求,但主数据库不用等待所有备数据库回复数据同步成功便可响应用户,也就是说主数据库可以等待一部分备数据库同步完成后响应用户写操作执行成功。
试题五:金融交易信息系统微服务架构(25 分)
背景
某互联网金融集团依托微服务技术研发互联网金融交易信息系统,全面整合原分布于各省地方分公司的区域系统,实现统一用户账户管理、转账汇款、理财投资、贷款管理、网上交易、网上支付、财务共享、财务统计分析等。
方案讨论:
- 王工:采用 SOA,通过 ESB 充分整合现有业务,支持 Web、智能手机等多端接入相同后端服务
- 张工:采用分布式微服务架构,整合业务同时利用云服务提高性能、可用性、可扩展性、可变性、可维护性
最终结合使用,制定基于分布式微服务的前后端分离体系结构。
问题 1(8 分)
请简要叙述微服务架构的含义和关键原则。
参考答案: 微服务是一种软件开发技术,是面向服务的体系结构(SOA)架构风格的一种变体。微服务将应用程序构造为一组松散耦合的服务,微服务中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。
微服务风格的关键原则:
- 每一个 URI 代表 1 种资源
- 客户端使用 HTTP Verb 表示操作方式的动词对服务端资源进行操作
- 通过操作资源的表现形式来操作资源
- 资源的表现形式是 XML 或者 HTML
- 客户端与服务端之间的交互是无状态的,客户端每个请求必须包含理解请求所必需的所有信息
问题 2(8 分)
请从(a) ~ (n)中选择合适的内容填入图 5.1 的(1) ~ (8)中,补充完善体系结构设计图。
选项:
- (a) 页面缓存
- (b) 网关层
- (c) 数据层
- (d) 主数据库
- (e) Web 服务器
- (f) 反向代理服务器
- (g) 事务中心
- (h) 服务层
- (i) 数据访问组件
- (j) CDN
- (k) 展示层
- (l) 数据中心
- (m) 从数据库
- (n) 分布式数据缓存
参考答案:
- (1)(j)CDN
- (2)(e)Web 服务器
- (3)(n)分布式数据缓存
- (4)(l)数据中心
- (5)(d)主数据库
- (6)(m)从数据库
- (7)(h)服务层
- (8)(c)数据层
问题 3(9 分)
项目组进行需求调研时发现用户界面部分变动可能比较频繁,需要降低系统界面与业务逻辑之间的耦合度。MVVM 模式是由 MVC 模式派生出的一种设计模式,请从组件耦合度、组件分工及对开发工程化支持等 3 个方面说明 MVVM 模式与 MVC 模式的主要区别。
参考答案:
| 项目 | MVC | MVVM |
|---|---|---|
| 组件分工 | M:数据模型或仓库抽象;V:视图抽象;C:控制,处理控制逻辑 | M:数据模型或仓库抽象;V:视图抽象;VM:视图模型,双向绑定 |
| 组件耦合度 | 耦合度低 | 事件传递,逻辑下沉;耦合度低;Binder 双向绑定 |
| 对开发工程化支持 | 重用度高;通过模板引擎技术实现了代码工程的分离 | 提高可重用度;通过 Ajax 技术实现了静态工程与动态工程的分离 |
试题六:数据语言集成开发环境架构设计(25 分)
背景
某软件公司为新推出的数据处理软件设计了一种脚本语言,专门用于开发该处理软件的附加功能插件。为了提高该语言的编程效率,公司组织软件开发部门为脚本语言开发了一套集成开发环境。软件工具开发部门根据字处理软件的特点,对集成开发环境进行了需求分析,总结出以下3项核心需求:
(1) 集成开发环境需要提供对新脚本语言的编辑、语法检查、解释、执行和调试等功能的支持,并要实现各种功能的灵活组合,配置与替换。
(2) 集成开发环境需要提供一致可视化的编程界面,用户通过界面元素拖拽和代码块填充的方式就可以完成功能插件核心业务流程的编写与组织。
(3)在代码调试功能方面,集成开发环境需要实现在脚本语言编辑界面中的代码自动定位功能。具体来说,在调试过程中,编辑界面需要响应调试断点命中事件,并自动跳转到当前断点处所对应的代码。
针对上述需求,软件工具开发部阶门对集成开发环境的架构进行分析与设计,主工认为该集成开发环境应该采用管道-过滤器的架构风格实现,李工则认为该集成开发环境应该采用以数据存储为中心的架构风格来实现。公司组织专家对主工和李工的方案进行了评审,最终采用了李工的方案。
问题一
请用200字以内的文字解释什么是软件架构风格,并从集成开发环境与用户的交互方式、集成开发环境的扩展性、集成开发环境的数据管理三个方面说明为什么最终采用了李工的设计方案。
参考答案:
软件架构风格是描述某一特定领域中系统组织方式的惯用模式,它定义了一个构件与连接件类型的词汇表,以及一组约束这些构件和连接件如何组合的规则,是对一类系统结构的抽象。
李工选择的"以数据存储为中心"方案的三个优势:
(1) 用户交互方式:编辑、调试、可视化界面等构件围绕同一份代码与状态仓库进行读写,可提供需求(2)所要求的一致可视化编程界面,支持双向频繁交互。
(2) 扩展性:编辑、语法检查、解释、执行、调试等功能可作为独立构件接入共享仓库,灵活增删与替换,满足需求(1)“功能的灵活组合、配置与替换”。
(3) 数据管理:代码、语法树、断点状态等数据集中存储于中央仓库,多构件并发访问且数据一致,可支撑需求(3)的断点事件响应与代码自动定位。
💡 延伸学习:数据存储为中心架构的两个子风格
子风格 触发机制 典型应用 仓库风格(Repository) 构件主动查询仓库 IDE、Web 应用 黑板风格(Blackboard) 仓库状态变化时主动通知构件 语音识别、专家系统 📌 真题考点对比
软考案例分析常对比"数据存储为中心" vs “管道-过滤器”:
- 管道-过滤器适合单向数据流(编译器前后端、Unix shell 管道)
- 数据存储为中心适合多构件共享状态(IDE、CRM、版本控制系统)
问题二
在对软件系统架构进行设计时,要对架构需求进行分析,针对特定需求选择最为合适的架构风格,因此实际的软件系统通常会混合多种软件架构风格。请对核心需求进行分析,说明为了满足需求(2)和(3),分别应采用荷种架构风格,并概要说明采用相应架构风格后的架构设计过程。
参考答案:
需求 (2):面向对象架构风格
可视化编程界面与拖拽、代码块填充本质是对象的组合操作,应采用面向对象(Object-Oriented)架构风格。
架构设计过程:
- 识别核心对象:将界面元素(按钮、文本框、连接线)、代码块、画布、属性面板等抽象为独立的对象类
- 定义对象接口与属性:明确每个对象的属性(位置、外观、状态)和方法(拖拽、连接、填充、序列化)
- 设计对象交互关系:通过对象之间的方法调用与消息传递实现界面元素的协作(如父子关系、拖拽事件传递)
- 封装、继承、组合:利用封装隐藏实现细节,利用继承复用界面对象共性,利用对象组合实现复杂的可视化业务流程
需求 (3):基于事件的隐式调用架构风格
断点命中"自动跳转"是事件触发的隐式响应,应采用基于事件的隐式调用(Implicit Invocation / Event-Driven)架构风格。
架构设计过程:
- 识别事件源与订阅者:调试器作为事件源(发布"断点命中"事件),编辑界面作为订阅者
- 定义事件类型与数据:定义"断点命中事件",包含断点所在的脚本路径、行号、上下文等数据
- 建立事件注册机制:编辑器在启动时向事件总线注册对"断点命中事件"的监听
- 触发与响应:调试过程中调试器命中断点 → 发布事件 → 编辑器隐式接收 → 自动跳转到对应代码行
💡 延伸学习:面向对象 vs 隐式调用的关键差异
风格 构件 连接件 耦合度 面向对象 对象 方法调用(显式 + 双向引用) 较紧 隐式调用 事件源 / 订阅者 事件发布 / 订阅(异步、单向) 松散 🎯 易错点:为什么需求 (3) 不是显式调用?
“调试器跳转到编辑器的某行代码"看起来像显式调用,但调试器不需要知道有哪些订阅者——编辑器、控制台、变量监视面板、调用栈面板都可能监听同一个"断点命中"事件,本质是发布-订阅解耦,所以是事件驱动,不是显式调用(RPC)。
📌 混合架构思想
实际 IDE = 数据存储为中心(仓库存放代码、语法树、断点等共享数据) + 面向对象(可视化 UI 层) + 事件驱动(调试器与编辑器的断点通知机制)。本题印证了题干"实际的软件系统通常会混合多种软件架构风格"的论断。
🛑 常见误区
不要把需求 (2) 答成 MVC——MVC 强调"模型-视图-控制器"三件套的职责分离,但需求 (2) 的关键是"拖拽 + 代码块填充"这种对象组合式可视化编程,面向对象比 MVC 更贴合落点。