软考-系统架构设计师笔记-真题解析-2023年真题

软考-系统架构设计师-2023年上午选择题真题

考试时间 8:30 ~ 11:00 150分钟

暂时未找到2023年上午的题库

todo 后续如果找到了再补上

软考-系统架构设计师-2023年下午案例真题

考试时间 14:30 ~18:00

案例最长答题时间 14:30 ~ 16:00

(第一题必答，二~五题选两个)

试题一 (25分)

某大型医院计划开发一套综合医疗信息管理系统，旨在提升医疗服务效率，加强患者数据管理和保护患者隐私。在系统需求分析与架构设计阶段，用户提出的部分需求和关键质量属性场景如下：

(a) 在高峰时段，系统响应时间不超过3秒，以支持快速挂号和就诊；

(b) 更新系统用户界面以同时适应老中青的操作习惯，必须在2周内完成；

(d)当主数据库服务器故障时，系统立即切换至备用服务器，切换时间不超过5分钟；

(e)系统需支持对新增子系统的无缝集成；

(f)系统必须能准确识别并提示患者药物过敏信息，以避免医疗事故；

(g)系统需具备快速恢复功能，在遭遇严重故障后，需在2小时内恢复服务；

(h)支持不小于100个门诊终端和20个取药终端。

在此基础上开发部门正在组织开发相关人员对系统架构进行评估。

问题1 (12分)

在架构评估过程中，质量属性效用树(utility tree)是对系统质量属性进行识别和优先级排序的重要工具。请给出合适的质量属性，

填入图1-1中(1)、(2)空白处；并选择题干描述中的(a) ~ (h)，将恰当的序号填入(3) ~ (6)空白处，完成该系统的效用树。

解析：

(1) 包含 C ,C是密码安全性相关，所以 (1) 是安全性。

(2) 包含 B , B是更新系统在规定时间内完成，所以是（2）可修改性。

(3) 是性能相关所以是 h

(4) 是安全相关所以是 f

(5) 是可用性相关所以是 g

(6) 是可修改性相关所以是 e

答案：安全性、可修改性、 (3) h 、 (4) f、(5) g 、(6) e

问题2 (4分)

基于软件系统的生命周期，可以将软件系统的质量属性分为开发期质量属性和运行期质量属性两部分，请把以上四个质量属性分

别归类。

答案：

开发期：可修改性

运行期：安全性、性能、可用性

问题3 (9分)

列举质量属性场景的6要素，并在(a)中找出至少3个要素。

答案：(重要☆☆☆☆☆、建议背诵理解记忆)

刺激源、刺激、环境、制品、响应、响应度量。

(a) 在高峰时段，系统响应时间不超过3秒，以支持快速挂号和就诊；

刺激源：用户请求

刺激：快速挂号和就诊

环境：高峰时段

制品：系统

响应：系统响应

响应度量：不超过3秒

试题二(25分)

一家图书馆计划开发一套图书管理系统，以提高图书借阅和管理的效率。该图书管理系统基本的需求包括：

(1)读者需通过身份验证登录系统，才能借阅图书；

(2)图书管理员管理图书的入库、出库、归还和分类；

(3)读者可以搜索图书信息、查看图书详情、预约图书、并查看借阅历史；

(4)系统自动记录图书的借阅情况，并生成借阅报告；

(5)图书管理员可以批量导入图书信息，并管理读者账户；

(6)系统支持读者在线续借图书；

(7)系统在图书归还时自动检查是否超时，如超时则记录违约情况。

项目组决定采用UML进行系统建模。

问题1 (10分)

请根据题目所述需求，说明图书管理系统中有哪些参与者，并列举所有实体类。

答案：

参与者：读者、图书管理员、系统时间。

实体类：读者、图书、图书管理员、借阅记录、违约记录。

问题2 (7分)

在UML 建模中，顺序图用于描述对象之间交互的顺序。在UML 建模中，顺序图中的消息有哪些类型?

对题目所述图书管理系统的需求建模时，"读者借阅图书"场景中的消息类型可能包括哪些?

答案：

顺序图中消息的类型包括：同步消息、异步消息、返回消息。

"读者借阅图书"场景中的消息类型可能包括：

同步消息(如读者提交借阅请求，系统响应借阅成功或失败)。

异步消息(如读者提交预约图书请求)。

返回消息(如系统返回图书的详情，或系统响应借阅成功)。

问题3 (8分)

请列举顺序图中常见的几种元素。

答案：

1.角色：可以是人或者其他系统、子系统。以一个小人图标表示。
2.对象：系统中具有特定职责或行为的实体，以一个矩形表示。
3.生命线：表示对象在交互过程中存在的时间线(对象的生命线)，以一条垂直的虚线表示。
4.控制焦点：表示在对象时间线上某段时期执行某个动作或处于活动状态。以一个很窄的瘦长矩形表示。
5.消息：表示对象之间发送的信息，用于触发接收对象的动作或状态变化。
6.交互片段：顺序图中的一组特殊交互，如循环、条件分支等

试题五(25分)

某电商平台计划开发一个面向全球消费者的在线购物系统，该系统需支持多语言、多货币及多地区配送。为应对未来用户量激增及高并发交易的需求，系统需具备高度可扩展性和高可用性。项目团队决定采用微服务架构进行系统设计，并计划使用Docker容器化技术部署服务。在架构设计过程中，需考虑以下关键因素：

(1)系统需支持分布式事务处理，确保数据一致性；

(2)采用微服务架构后，服务间的通信和数据共享需高效且安全；

(3)系统需集成多种支付方式，并符合不同地区的支付法规；

(4)考虑到全球访问，需部署CDN以优化用户体验。团队初步规划了用户服务、商品服务、订单服务、支付服务等几个核心微服务，并讨论了服务间的调用机制及数据同步方案。

问题1 (5分)

简述微服务架构相较于传统单体架构的优势。

解析：5分尽量回答5点。

答案：

1.高可伸缩性:微服务架构允许独立地伸缩各个服务，根据业务需求灵活调整资源，对整个应用进行调整。

2.技术栈灵活性:每个微服务可以使用最适合其需求的技术栈进行开发，无需受限于整的技术选择。

3.快速迭代和部署:由于服务之间的解耦，团队可以并行开发、测试和部署不同的服务，加快产品迭代速度。

4.故障隔离:单个服务的故障不会影响整个系统，提高了系统的稳定性和可靠性。

5.更好的团队协作:微服务架构促进了小型、自治的团队形成，每个团队可以专注于自己的服务，提高了开发效率和代码质量。

问题2 (12分)

在微服务架构下，服务间的通信和数据共享是核心问题之一。请比较常见的服务间通信方式RESTfuI API和gRPC，并基于电商平台的需求，推荐一种合适的通信方式并说明选择原因。

答案：

(1)RESTful API：基于HTTP协议，使用JSON或XML等格式进行数据传输，具有良好跨平台性和易用性。通过HTTP协议的GET/POST/DELETE等命令操作资源。

对于电商平台而言，RESTfuI API因其简单性和广泛的支持度，是一个很好的选择。

(2)gRPC: 基于远程过程调用（RPC）模型，支持多种语言，通过定义服务接口实现分布式系统通信。 gRPC在性能上略优于RESTful API，适合低延迟和高吞吐量的场景，但不如 RESTfuI API那样易于学习和使用，且对客户端的支持不如 RESTful API广泛。

基于电商平台的需求，推荐采用RESTfuI API作为服务间的通信方式。

原因包括:

(1)电商平台通常需要与多种客户端(如 Web端、移动应用、第三方服务等)进行交互，RESTfuI API支持度会更好。

(2)RESTful API的易用性和简单，有助于降低开发成本和提高开发效率。

(3)常见电商平台对实时性要求不是特别高，因此RESTful API的性能足以满足需求。

问题3 (8分)

在微服务架构下，如何确保各个微服务之间的数据一致性和服务的高可用性?请列举几种常见的策略或技术。

答案：

(1)分布式事务:使用两阶段提交(2PC)、三阶段提交(3PC)或基于SAGA 模式等分布式事务解决方案，确保跨多个服务的数据一致性。但分布式事务可能会引入额外的复杂性和性能开销，因此需要谨慎使用。

(2)最终一致性:在不需要强一致性的场景下，可以采用最终一致性模型。通过事件驱动架构或消息队列等方式，异步地更新数据，并在一段时间后达到一致状态。这种方式可以提高系统的可用性和性能。

(3)服务熔断与降级:为防止某个服务的故障影响整个系统，可实施服务熔断机制，当服务调用失败率达到一定阈值时，自动熔断该服务，防止失败扩散。同时，实施服务降级策略，在资源不足或系统负载过高时，提供简化的服务响应。

(4)服务注册与发现:使用服务注册中心(如Eureka、Consul、Nacos等)来管理服务的注册和发现。

软考-系统架构设计师-2023年下午论文真题

（注：所有论文仅供参考）

论文答题技巧

考试时间 14:30 ~18:00

论文建议答题时间 16:00 ~ 18:00

字数一定要够大概要写2500字左右。2024年开始是机考了，也就是打字。

解答应分摘要和正文两部分

要注意下面两点：

① 摘要字数应控制在400字以内，可以分条叙述。

② 正文字数为2000到3000 字，可以部分内容分条叙述，但不要全部内容都用分条叙述的方式。

系统架构设计师的论文考试给出四个题目，要求四选一。最好是选择自己最擅长的题目。

建议先列出提纲5-10分钟，字数100-200字主要是为后面写大量文字理清思路。

下面都是论文的内容了：

写摘要15-20分钟，300-400字

（摘要是对整个论文内容的精炼总结非常重要）

写正文80分钟，2000字以上

(写正文的模板大致分为3个阶段

①、系统(项目)介绍。这部分主要介绍系统背景、系统总体结构主要特点、自己担任的角色、主要工作等。这部分内容有400字左右，建议这部分内容在考前就准备好。因为稍微改改就能用在任何一篇上。

②、论述部分。这部分内容是核心内容，涉及到对论点进行展开和论述，大概1300字左右。一般是采用结构化的方式分几点进行论述，可以首先简要介绍下考题提到的技术或问题，然后按照要求去展开论述。注意不要全部都按点论述。

③、总结部分主要根据上述正文部分中，对系统（项目）实现过程中的开展情况进行汇总和分析，包括项目实施过程中成功的方面、可以改进的方面、失败的方面等。这部分300字。主要写成功的方面和总结，不建议写失败的方面，可以稍微提一下不足点和可改进点即可。)

对论文进行检查与修改10分钟

(通读一遍修改错别字和语句不通畅的地方)

从下列的4道试题(试题一至试题四) 中任选1道解答。

论多源数据集成及应用

在如今信息爆炸的时代，企业、组织和个人面临着大量的数据。这些数据来自不同的渠道和资源，包括传感器、社交媒体、销售记录等，它们各自具有不同的数据格式、分布和存储方式。因此如何收集、整理和清洗数据，以建立一个一致、完整的数据集尤为重要。多源数据集成可以提供更全面的数据视角，将来自不同渠道的数据结合起来，通过这种方式整合多个数据源，从而减少单一数据源带来的误差和不准确性。此外，多源数据集成还可以帮助识别和矫正数据中的错误和重复项，提高数据的质量。

请围绕"论多源数据集成及应用"论题，依次从以下三个方面进行论述。

1.概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。

2.结合项目实际，详细说明多源数据集成的策略有哪些。

3.具体阐述你参与管理和开发的项目如何基于多源数据集成进行设计与实现。

论多源数据集成及应用

摘要

2023年5月，我参与了某大型制造企业"数字化供应链协同管理平台"的建设工作，担任系统架构师与技术负责人。该项目旨在打破企业内部采购、库存、生产与销售部门之间的"信息烟囱"，实现跨部门的数据融合与业务协同。

由于各业务模块历史悠久，且由不同供应商采用独立的 MySQL 数据库进行存储，形成了典型的异构多源数据环境。本文以该项目为背景，深入探讨了多源数据集成的策略及其在微服务架构下的具体应用。针对实时业务操作，我们采用了基于中间件模式的动态数据源路由技术；针对跨库关联查询与报表分析，我们构建了基于 Canal 的准实时数据仓库模式。本文详细阐述了通过 Spring AOP 结合 AbstractRoutingDataSource 实现多库动态切换的细节，以及利用 Seata 解决多源集成下的分布式事务一致性问题。项目于2024年初成功上线，数据同步时延控制在秒级，支撑了日均百万级的业务调用，显著提升了企业的决策效率。

一、项目背景与主要工作

随着制造业数字化转型的深入，数据已成为企业的核心资产。然而，在实际工程中，数据往往分散在不同的物理节点和逻辑库中。我司承接的"数字化供应链协同管理平台"面临着严峻的集成挑战：采购模块（MySQL-A）负责管理数万家供应商，库存模块（MySQL-B）监控着分布在全国的 50 个仓储节点，而生产计划模块（MySQL-C）则运行着复杂的排程算法。作为架构师，我面临的首要问题是：如何在不重构原有数据库体系的前提下，在一个统一的微服务框架内实现对这些多源数据的透明访问与逻辑整合。我不仅负责了整体集成架构的方案选型，还深入一线主导了多数据源动态路由组件的封装、分布式事务框架（Seata）的调优以及基于 Canal 的异构数据增量同步链路的设计。

二、多源数据集成的策略分析

在系统架构设计层面，多源数据集成主要有三种经典策略，我们在项目中根据不同场景进行了复合应用：

联邦模式 (Federated Mode)联邦模式通过在各数据库之间建立逻辑映射，为上层应用提供一个统一的"全局模式"。它的优点是不需要物理搬运数据，实时性极佳。然而，在 MySQL 环境下，Federated 存储引擎对复杂查询（如多表 Join）的优化较差，且容易受到网络抖动的严重干扰。在本项目中，由于涉及的子系统超过 10 个，直接建立 n×(n−1)n \times (n-1)n×(n−1) 的映射规则会导致维护成本指数级上升，因此该模式仅用于个别极小规模的实时查询。
中间件模式 (Middleware Mode)这是本项目在业务交易层的核心策略。中间件位于应用逻辑与数据库之间，负责将应用的统一请求拆解、路由并分发到不同的目标库。在 Java 微服务体系下，我们通过在应用内部集成"数据访问中间件"逻辑，利用动态路由技术实现了对多个 MySQL 实例的平滑访问。该模式兼顾了开发的灵活性与系统的解耦性。
数据仓库模式 (Data Warehouse Mode)针对统计分析类需求，中间件模式的跨库查询性能往往难以接受。因此，我们引入了数据仓库模式。通过 ETL 流程将分散在各库的业务数据物理同步到统一的分析平台（如 ClickHouse）。该模式虽有一定时延，但极大释放了在线交易数据库的压力，为复杂的供应链决策分析提供了支持。

三、基于微服务架构的多源集成设计与实现

在本项目中，我们将"多源集成"拆解为三个技术维度进行深度实现。

基于 AOP 与 ThreadLocal 的动态路由设计由于本项目基于 Spring Boot 体系，我们没有采用厚重的 Proxy 型中间件（如 MyCat），而是选择了更加轻量级的应用端路由方案。核心机制：扩展 Spring 提供的 AbstractRoutingDataSource 抽象类。我们重写了 determineCurrentLookupKey() 方法。该方法从一个自定义的 DataSourceContextHolder 中读取当前线程所绑定的数据源标识。

上下文管理：利用 ThreadLocal 存储当前线程的数据源 Key。这确保了在多线程并发环境下，每个请求都能准确地指向其目标 MySQL 库，而不会发生串话。AOP 切面增强：封装自定义注解 @DS(value = "db_key")。通过 AspectJ 拦截 Service 层的方法执行，在执行前读取注解值并存入 ThreadLocal，在方法执行完毕（或抛出异常）后，通过 finally 块清除标识，防止内存泄漏和后续请求的干扰。
分布式事务的深度集成策略多源数据集成带来的最大痛点是"分布式事务"。例如，在"订单确认"流程中，系统需要同时扣减库存库（MySQL-B）并更新订单状态（MySQL-A）。Seata AT 模式的应用：考虑到业务开发效率，我们引入了 Seata 框架的 AT（Automatic Transaction）模式。其底层原理是：Seata 代理了数据源，在第一阶段（Prepare）自动解析业务 SQL，生成数据修改前后的"快照（Undo Log）"，并存入各子库的特定表中。二阶段提交与回滚：如果全局事务成功，Seata 异步清理 Undo Log；如果失败，则根据快照进行反向补偿，实现自动回滚。通过这种方式，我们在多源集成环境下依然保持了类似本地事务的开发体验。隔离性优化：针对分布式事务可能产生的写冲突，我们配置了 Seata 的全局行锁机制，确保在并发场景下数据的一致性。
基于 Canal 的数据联动与冗余优化在实际业务中，频繁的跨库路由会带来网络开销。为了优化性能，我们针对高频访问的"静态元数据"设计了数据冗余方案。增量监听：部署 Canal 集群作为 MySQL Binlog 的消费者。Canal 伪装成 MySQL 从库，实时感知采购库中供应商信息的变更。异步下发：将变更信息封装为 JSON 格式投递至 Kafka 消息队列。局部复制：消费端服务监听 Kafka，将必要的供应商字段同步更新至库存库的冗余表中。通过"空间换时间"的策略，将原本需要跨库的操作转化为本地库关联，查询效率提升了 300% 以上。

四、多源集成中的挑战与解决措施

在项目的实施与运维阶段，我们遇到了几个极具代表性的技术瓶颈：

连接池膨胀与资源争抢问题，在一个微服务集成 5 个以上 MySQL 数据源时，如果每个源都设置 100 个最大连接，单实例将消耗 500 个物理连接，这超出了 MySQL 默认的连接限制。对策：我们引入了 HikariCP 作为连接池，并针对不同权重的数据库实施了分级配置。核心库设置较大的池容量，辅助库（如日志库）设置较小的容量。同时，开启了连接池的监控指标，通过 Prometheus + Grafana 实时监控连接使用率，发现空闲超过 10 分钟的连接强制回收，有效平衡了资源消耗。
多源 Schema 漂移与数据质量管理，由于各数据源由不同供应商维护，经常出现一方修改了表结构（Schema）而集成方不知情导致系统崩溃的问题。对策：我们建立了一套基于微服务的"元数据治理体系"。利用 Information_Schema 编写了自动化校验脚本，每晚定时比对各源库的结构定义。同时，在 ETL 环节引入了数据清洗算法，利用正则表达式和标准字典对不规范的单位（如"kg"与"千克"）、缺失的编码进行预处理，确保了集成到数据仓库中的数据具有高度的一致性。
全局唯一 ID 冲突，在多源环境下，各库自增主键可能重复，导致集成到汇总表时发生主键冲突。对策：我们全面禁用了 MySQL 物理自增 ID，改用全局统一的雪花算法 (Snowflake) 生成器。每个微服务实例分配唯一的机器 ID，确保在多源并发写入时，生成的 ID 在整个集群范围内绝对唯一。

五、总结与展望

2024年初，该数字化供应链管理平台顺利通过验收。在长达一年的稳定运行中，系统成功支撑了企业跨库业务调用的高可用要求。通过**"业务层动态路由、分析层增量同步、一致性层分布式事务"**的立体化设计，我们不仅解决了数据孤岛问题，更在复杂的微服务环境下实现了高效的多源数据集成。回首项目历程，我深刻体会到：多源数据集成并非简单的"连通数据库"，而是一场关于性能、一致性与可扩展性的平衡艺术。虽然目前我们已解决了异构 MySQL 的集成，但在未来，随着非结构化数据的爆发，如何将图数据库（Neo4j）和时序数据库（InfluxDB）更优雅地融入现有的集成框架，将是我持续探索的方向。