2026年软考-系统架构设计师应用技术真题

2026年软考-系统架构设计师应用技术真题试题一：论软件架构风格与基于架构的软件开发阅读以下关于软件架构风格的叙述，根据要求回答问题。【背景描述】某科技公司承接了一项“智慧城市交通流量实时监控系统”的开发项目。该系统旨在通过部署在城市各主要路口的高清摄像头、地磁感应器和雷达传感器，实时采集车流量、车速、排队长度等数据，经过初步处理后传输至云端数据中心。云端系统需对海量数据进行融合分析，识别拥堵点，优化信号灯配时方案，并将控制指令下发给路侧单元（RSU），同时将路况信息发布给导航APP终端。项目组在架构设计阶段，针对系统的不同模块特性，经过深入讨论，决定采用多种架构风格组合的方式进行设计。对于传感器数据的采集与预处理模块，系统需要将采集到的原始图像数据依次进行去噪、增强、车牌识别、特征提取等操作，且这些操作之间有严格的顺序依赖关系。对于云端的数据融合与信号灯控制模块，系统需要接收来自不同区域的感知数据，根据不同的业务规则（如高峰期策略、平峰期策略、突发事件策略）触发相应的控制算法，且未来可能需要新增针对特定天气（如暴雨、大雪）的控制策略。对于路况信息发布模块，系统需要将处理后的路况信息同时推送给多个第三方导航服务商（如高德、百度、腾讯）以及私家车用户的移动端APP。【问题1】（6分）在软件架构设计中，数据流风格是一种非常常见的架构风格。请用200字以内文字说明数据流风格的基本思想，并指出常见的两种数据流风格变体。【问题2】（10分）根据背景描述，请分析并回答以下问题：（1）传感器数据的采集与预处理模块最适合采用哪种架构风格？请说明理由。（2）云端的数据融合与信号灯控制模块最适合采用哪种架构风格？请说明理由。（3）路况信息发布模块最适合采用哪种架构风格？请说明理由。【问题3】（9分）在系统开发过程中，架构师李工建议在信号灯控制模块引入“规则引擎”来管理复杂的业务逻辑。请列举使用规则引擎的三个主要优点，并简述在引入规则引擎时可能带来的两个潜在风险。试题二：论微服务架构设计与演进阅读以下关于微服务架构的叙述，根据要求回答问题。【背景描述】“云创电商”平台是一家大型B2C电商平台，随着业务量的飞速增长，原有的单体应用架构逐渐暴露出诸多问题：代码库庞大导致编译部署耗时过长，模块间耦合度高导致牵一发而动全身，技术栈被锁定难以扩展，系统扩展性差无法应对“双十一”等高并发场景。为此，公司决定对核心交易系统进行微服务架构重构。重构后的系统包含用户服务、商品服务、订单服务、库存服务、营销服务、支付服务等。为了保证系统的高可用性和数据一致性，架构师采用了SpringCloudAlibaba生态作为技术栈，并引入了Seata分布式事务框架。系统部署在Kubernetes集群上，通过Nacos作为注册中心和配置中心，使用Sentinel进行流量控制与熔断降级。在架构演进过程中，团队面临了诸多挑战。例如，在订单创建流程中，需要同时调用库存服务扣减库存、营销服务计算优惠、支付服务冻结资金。一旦某个环节失败，如何保证数据回滚是一个难题。此外，服务拆分后，链路追踪变得异常困难，排查一个跨服务的故障往往耗费大量时间。【问题1】（7分）在微服务架构中，服务拆分是至关重要的一步。请列举服务拆分的四个基本原则，并结合背景描述，简要说明“订单服务”与“库存服务”拆分的合理性。【问题2】（8分）分布式事务是微服务架构中的难点。请解释CAP定理的含义，并用LaTex公式表示CAP定理中关于一致性和可用性在分区容错性存在时的约束关系。在背景描述中，Seata框架支持AT模式和TCC模式，请从实现复杂度和性能两个维度对这两种模式进行比较。【问题3】（10分）为了解决微服务环境下的故障排查难题，系统引入了全链路追踪技术。请简述全链路追踪的核心原理（包括TraceId,SpanId等概念），并说明在微服务架构中，如何实现服务之间的上下文传递（ContextPropagation）。此外，请列举两个常见的分布式链路追踪开源工具。试题三：论系统建模与UML设计阅读以下关于系统建模的叙述，根据要求回答问题。【背景描述】某软件开发公司正在为一家银行开发“新一代个人信贷管理系统”。该系统涵盖了客户信息管理、贷款申请、审批、放款、贷后管理及还款等全流程业务。系统分析员采用面向对象分析与设计（OOAD）方法，使用UML进行系统建模。在贷款审批流程中，系统首先根据客户的信用评分和贷款产品规则进行自动初审。如果自动初审通过，则转入人工复核环节；如果自动初审不通过，则直接拒绝。人工复核由信贷员进行，信贷员可以批准、拒绝或转交给更高级别的信贷主管进行终审。信贷主管拥有最终审批权，只能选择批准或拒绝。为了提高系统的灵活性和可扩展性，架构师决定使用设计模式来处理不同类型的贷款产品（如房贷、车贷、信用贷）的审批逻辑差异。对于每种贷款产品，虽然审批流程大体相同，但具体的额度计算公式、风控规则校验逻辑各不相同。【问题1】（6分）在UML建模中，状态机图对于描述对象的生命周期非常有用。请根据背景描述，绘制（或用文字详细描述）“贷款申请单”对象的状态机图。要求包含状态、事件以及状态迁移。【问题2】（9分）为了处理不同贷款产品的审批逻辑差异，架构师采用了“策略模式”与“工厂模式”相结合的设计方案。（1）请画出策略模式的结构类图（包含Strategy接口、ConcreteStrategy、Context等关键角色）。（2）请说明策略模式的主要适用场景。（3）结合背景，说明工厂模式在此处的作用是什么。【问题3】（10分）在系统详细设计阶段，需要定义类之间的交互关系。假设系统需要查询客户在银行的资产情况以计算信用分，该过程需要调用“核心账务系统”的接口。由于核心账务系统是遗留系统，接口较为复杂且不稳定。请说明采用哪种设计模式可以隔离该接口的不稳定性，并画出该模式的结构类图，解释其如何实现解耦。试题四：论软件系统质量属性与架构评估阅读以下关于系统质量属性的叙述，根据要求回答问题。【背景描述】某航空航天研究所正在开发“飞行器远程遥测与健康管理（PHM）系统”。该系统负责接收飞行器在飞行过程中下传的海量遥测数据，对发动机、机翼、航电系统等关键部件的健康状态进行实时监测和故障预测。由于飞行任务的特殊性，系统对可靠性、实时性和安全性有着极高的要求。系统架构师王工在架构设计阶段，重点关注了系统的质量属性。为了确保系统的高可靠性，硬件层面采用了双机热备，软件层面在关键计算节点引入了冗余机制。为了满足实时性要求，系统采用了实时操作系统（RTOS），并对关键数据路径进行了优化。针对安全性，系统实施了严格的访问控制和数据加密措施。在架构评估阶段，团队采用了基于场景的架构评估方法（ATAM）。评估过程中，利益相关者提出了多个关注点，例如：“在传感器数据突发性增长30%的情况下，系统是否能在100ms内完成故障诊断？”以及“当主数据库服务器发生宕机时，系统能否在5秒内自动切换并保证数据不丢失？”【问题1】（7分）请解释什么是“架构权衡”？并列举在PHM系统设计中，为了提高“可靠性”通常需要在哪些方面做出权衡（至少列举两个）。【问题2】（10分）ATAM（架构权衡分析方法）是一种系统化的架构评估方法。请简述ATAM评估过程中的主要步骤（按顺序列出前5个关键步骤）。针对背景描述中提到的场景：“在传感器数据突发性增长30%的情况下，系统是否能在100ms内完成故障诊断？”，请说明该场景属于哪种质量属性，并列举两个针对该质量属性的架构战术。【问题3】（8分）系统的“安全性”是PHM系统的核心关注点。请从“抵御外部攻击”和“保证数据完整性”两个角度，各列举两个具体的架构战术。此外，请解释“最小特权原则”在系统设计中的应用。试题五：论数据架构与数据库设计阅读以下关于数据架构的叙述，根据要求回答问题。【背景描述】“全民阅读”APP是一款拥有亿级用户的电子书阅读与社交平台。平台产生的数据主要包括用户画像数据、电子书元数据、用户阅读行为日志（如翻页、笔记、时长）、社交互动数据（评论、点赞、书评）等。随着业务的发展，原始的单机MySQL数据库已无法支撑海量数据的存储与查询需求。技术团队决定对数据架构进行重构，采用“专库专用、分库分表、读写分离”的策略。对于用户的阅读行为日志，数据量极大且写入频繁，但查询模式相对单一（主要是按用户ID和时间范围查询），团队决定使用MongoDB文档型数据库进行存储。对于核心的交易订单数据，为了保证强一致性，仍采用MySQL集群，并按用户ID进行水平分片。对于热门书籍的排行榜数据，读写比例极高且对实时性要求强，团队引入了Redis缓存层。在分库分表实施过程中，架构师需要考虑分片键的选择、数据迁移方案以及跨分片查询的处理。【问题1】（8分）数据库分库分表是解决海量数据存储的有效手段。请分别解释“水平分片”和“垂直分片”的含义及适用场景。结合背景描述，说明为什么订单数据适合采用按“用户ID”进行水平分片。【问题2】（8分）在分布式数据库架构中，分布式主键ID的生成至关重要。请解释为什么不能简单依赖数据库的自增ID（AutoIncrement）来生成分布式主键。请列举两种常见的分布式主键生成算法，并简述其中一种算法的基本原理（可用LaTex公式辅助说明）。【问题3】（9分）对于阅读行为日志，团队选择了MongoDB。请说明MongoDB相对于关系型数据库（RDBMS）的三个主要优势。在引入Redis缓存时，通常会面临缓存穿透、缓存击穿和缓存雪崩的问题。请分别解释这三个问题的含义，并给出针对“缓存雪崩”的一种解决方案。答案与解析试题一解析【问题1】数据流风格的基本思想：在数据流架构中，输入数据经过一系列特定的处理步骤（组件）的转换和操作，最终形成输出。每个处理步骤都作为一个独立的过滤器，只关注数据的输入和输出，不依赖数据的全局状态。常见的两种变体：批处理序列和管道-过滤器。【问题2】（1）最适合采用：管道-过滤器架构风格。理由：该模块需要将原始图像数据依次进行去噪、增强、识别、特征提取等操作，这些操作具有明确的先后顺序，且每个处理步骤相对独立，输出即为下一步的输入，符合管道-过滤器中“数据流通过一系列处理单元”的特性。（2）最适合采用：黑板架构风格。理由：该模块需要接收多种类型的感知数据（车流、排队、天气等），并根据不同的业务规则（策略）进行触发和处理。黑板架构包含一个共享的知识源（黑板）和多个独立的知识源（策略算法），当黑板中的数据状态发生变化时，会触发相应的算法进行工作，非常适合解决此类数据驱动且解耦不确定性的问题。（3）最适合采用：发布-订阅架构风格。理由：该模块需要将路况信息同时推送给多个不同的第三方服务商和用户终端。发布-订阅模式将消息的发布者（路况中心）与订阅者（导航APP、用户）解耦，发布者无需知道具体有多少订阅者，只需将消息发布到主题，所有订阅该主题的客户端都能收到，实现了高效的一对多广播。【问题3】使用规则引擎的三个主要优点：1.业务逻辑与代码分离：将复杂的业务规则从硬编码中剥离出来，存储在外部文件或数据库中，便于非技术人员维护。2.灵活性和可扩展性高：修改规则无需重新编译部署代码，系统可以动态加载和更新规则，适应业务快速变化。3.集中管理：统一的规则库便于版本控制、测试和审计。引入规则引擎的两个潜在风险：1.性能开销：规则引擎的解析和执行通常比直接的硬编码逻辑要慢，可能成为系统瓶颈。2.复杂性增加：规则定义语言（如DRL）可能具有学习曲线，且规则之间的冲突和依赖关系管理不当可能导致逻辑错误，难以调试。试题二解析【问题1】服务拆分的四个基本原则：1.单一职责原则（SRP）：每个微服务只负责一个特定的业务功能。2.高内聚低耦合：服务内部组件紧密关联，服务之间尽量减少依赖。3.业务边界清晰：通常基于领域驱动设计（DDD）中的限界上下文进行拆分。4.自治性：服务可以独立部署、升级和扩展。“订单服务”与“库存服务”拆分的合理性：订单和库存属于两个不同的业务领域（限界上下文）。订单关注交易流程、状态管理和用户履约记录；库存关注物品的数量管理、仓库调度和占用情况。两者的生命周期不同，且随着业务发展，库存管理可能会演变为复杂的WMS系统，独立拆分有利于系统的独立扩展和技术选型，降低耦合度。【问题2】CAP定理含义：在一个分布式系统中，一致性、可用性、分区容错性这三者最多只能同时实现两点。约束关系公式：当分区容错性（P）发生时，必须在一致性（C）和可用性（A）之间做出选择，即C+AT模式与TCC模式的比较：1.实现复杂度：AT模式相对简单，对业务代码侵入性小，只需在接口上加注解即可，由框架自动生成回滚SQL；TCC模式复杂度高，需要业务开发者手动编写Prepare、Confirm、Cancel三个阶段的接口。2.性能：AT模式利用前镜像+后镜像机制，锁粒度较粗，性能相对略低；TCC模式由于业务自己控制锁粒度，且无需生成大量回滚日志，性能通常优于AT模式，但开发成本高。【问题3】全链路追踪核心原理：系统为每一个外部请求生成一个全局唯一的TraceId。当请求在微服务间调用时，通过上下文传递将TraceId传递下去。在每个服务内部，通过SpanId标识具体的操作单元（如一个数据库查询或一次RPC调用）。SpanId通常呈树状结构（如父SpanId为1，子SpanId为1.1,1.2）。通过收集这些TraceId和SpanId构成的调用树，可以还原出完整的调用链路。上下文传递实现：在服务间调用（如HTTP或RPC）时，将TraceId和当前SpanId放入请求的Header中（如X-Trace-Id,X-Span-Id）。服务接收请求后，从Header中提取这些ID，并初始化本地的日志上下文，从而保证日志记录归属于同一个Trace。常见的开源工具：Zipkin,Jaeger,SkyWalking。试题三解析【问题1】“贷款申请单”对象的状态机图描述：1.初始状态->[提交申请]->待初审2.待初审->[自动初审通过]->待人工复核3.待初审->[自动初审拒绝]->已拒绝4.待人工复核->[信贷员批准]->已批准5.待人工复核->[信贷员拒绝]->已拒绝6.待人工复核->[信贷员转交]->待终审7.待终审->[主管批准]->已批准8.待终审->[主管拒绝]->已拒绝9.已批准/已拒绝->[归档]->结束状态【问题2】（1）策略模式结构类图（文字描述）：Strategy（策略接口）：定义所有支持的算法的公共接口，如`calculateLoan()`。ConcreteStrategy（具体策略）：实现了Strategy接口的具体算法类，如`HouseLoanStrategy`,`CarLoanStrategy`。Context（上下文）：维护一个对Strategy对象的引用，通过`setStrategy()`方法切换策略，通过`contextInterface()`调用策略算法。（2）策略模式适用场景：当一个系统需要动态地在几种算法中选择一种时。当一个对象有很多行为，且这些行为在不同情况下表现为不同形式，需要使用多态来避免使用多重条件转移语句时。算法使用客户不应该知道的数据时。（3）工厂模式的作用：根据贷款类型（如“房贷”、“车贷”），工厂模式负责创建对应的ConcreteStrategy对象（如HouseLoanStrategy实例）。这样客户端代码只需依赖工厂和策略接口，而不需要知道具体策略类的创建细节，进一步降低耦合。【问题3】采用的设计模式：适配器模式或外观模式。此处适配器模式更为贴切，用于将遗留系统的接口转换为客户期望的接口。结构类图描述：Target（目标抽象类）：定义客户所需的接口，如`getAssets()`。Adapter（适配器类）：内部持有一个Adaptee的实例，实现Target接口，在`getAssets()`方法中调用Adaptee的复杂接口并进行数据转换。Adaptee（适配者）：遗留系统的接口，如`queryCoreSystemData()`。解耦实现：适配器类封装了与遗留系统交互的复杂性。当遗留系统接口发生变化时，只需修改Adapter类的内部实现，而客户端代码（调用方）只需调用Target接口，无需修改，从而实现了隔离和解耦。试题四解析【问题1】架构权衡：在软件架构设计中，由于资源（硬件、时间、人力）有限，无法同时最大化所有的质量属性。提升某个属性往往会导致另一个属性的下降，架构师需要在相互冲突的质量属性之间做出取舍。为了提高“可靠性”通常做出的权衡：1.性能：例如通过增加冗余计算、数据校验、持久化日志来提高可靠性，会增加处理延迟，降低性能。2.成本：例如采用双机热备、集群部署、昂贵的硬件设备来提高可靠性，会显著增加系统的经济成本。3.易用性/简洁性：为了提高可靠性，系统可能会增加复杂的确认机制（如两阶段提交），降低了系统的易用性或开发效率。【问题2】ATAM评估主要步骤（前5步）：1.收集场景：收集利益相关者关注的场景。2.架构描述：获取或生成架构的概要描述。3.架构分析：对架构风格进行分析，识别敏感点和权衡点。4.场景评估：将收集到的场景与架构元素进行映射，评估架构对场景的支持程度。5.敏感点权衡分析：分析敏感点之间的相互作用，识别架构权衡。场景属性：该场景属于“性能”质量属性。针对“性能”的架构战术：1.资源管理：引入资源池（如线程池、连接池）来减少资源获取的开销。2.资源调度：采用优先级队列，确保高优先级任务（如故障诊断）优先获得CPU资源。3.数据复制：通过缓存数据副本减少计算时间或I/O等待。【问题3】“抵御外部攻击”的架构战术：1.认证与授权：对用户进行身份验证，并基于角色或策略控制其访问权限。2.限制访问：通过防火墙、DMZ隔离、IP白名单等手段限制网络层的访问。“保证数据完整性”的架构战术：1.校验和/哈希：在数据传输或存储时生成校验码，验证数据是否被篡改。2.数字签名：对关键数据进行非对称加密签名，确保数据来源可信且未被篡改。“最小特权原则”应用：在系统设计中，每个进程、用户或组件仅被授予完成其功能所必需的最小权限集，绝不授予超出其职责范围的权限。例如，日志服务只应拥有“写日志”的权限，而不应拥有“读取数据库”或“修改配置”的权限。这样即使该服务被攻破，攻击者能造成的破坏也被限制在最小范围内。试题五解析【问题1】水平分片：根据数据的某个字段（如用户ID）的值或哈希范围，将同一张表中的数据行分散存储到不同的数据库或表中。适用场景：数据量极大，单表数据行数过多，导致查询性能下降时。垂直分片：根据业务模块或表之间